From xen-users-bounces@lists.xen.org Fri Mar 01 05:39:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 05:39: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 1UBIfI-0000nL-RI; Fri, 01 Mar 2013 05:37:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBIfH-0000nG-O3 for xen-users@lists.xen.org; Fri, 01 Mar 2013 05:37:51 +0000 Received: from [193.109.254.147:8282] by server-9.bemta-14.messagelabs.com id 65/43-30867-EAE30315; Fri, 01 Mar 2013 05:37:50 +0000 X-Env-Sender: studyfordo@163.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1362116268!9378368!1 X-Originating-IP: [220.181.13.123] X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMjAuMTgxLjEzLjEyMyA9PiA0NTky\n,sa_preprocessor: QmFkIElQOiAyMjAuMTgxLjEzLjEyMyA9PiA0NTky\n,HTML_40_50,HTML_MESSAGE, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23348 invoked from network); 1 Mar 2013 05:37:49 -0000 Received: from m13-123.163.com (HELO m13-123.163.com) (220.181.13.123) by server-8.tower-27.messagelabs.com with SMTP; 1 Mar 2013 05:37:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Subject:Content-Type: MIME-Version:Message-ID; bh=7f2MCQ8DJyReMvHC9cOqljbm2vDYGygvWCkP 0WGhkM4=; b=gx4JZTShs01rW79hzxCjXxi9XuF/OfnfYV7hKudnSxg7rRInBaw1 qtupRLbXaPakOYURJnlQ9TBEo5GiyhcVllsmgV6zU8f5hnGQNQMdItWHCjjBDkJG L9DdYaLK2H7h3bK+FcxrTCeUbN1hs7iRKmIhI5C5gju8Nb9djk26BTE= Received: from studyfordo$163.com ( [192.168.29.124, 116.6.78.178] ) by ajax-webmail-wmsvr123 (Coremail) ; Fri, 1 Mar 2013 13:37:45 +0800 (CST) X-Originating-IP: [192.168.29.124, 116.6.78.178] Date: Fri, 1 Mar 2013 13:37:45 +0800 (CST) From: studyfordo To: xen-users@lists.xen.org X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20130201(21528.5249.5248) Copyright (c) 2002-2013 www.mailtech.cn 163com X-CM-CTRLDATA: ulNc3WZvb3Rlcl9odG09NDIxOjgx MIME-Version: 1.0 Message-ID: <257c1ec5.6f84.13d2474c473.Coremail.studyfordo@163.com> X-CM-TRANSID: e8GowEAJm0KqPjBRdt9NAA--.404W X-CM-SenderInfo: xvwxv5xiruv0i6rwjhhfrp/1tbi6wTSYVEAA+X6qgABs6 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Subject: [Xen-users] hvm is required for this operation X-BeenThere: xen-users@lists.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="===============9123624247345007104==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9123624247345007104== Content-Type: multipart/alternative; boundary="----=_Part_105311_580229882.1362116265075" ------=_Part_105311_580229882.1362116265075 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit Hi,all I just install xenserver6.1 in vcenter(esx4.1). esx is installed in hpDL68cG7. and modify premiscuous mode. and when I start xp vm in xenserver, it hint error like "HVM is required for this operation". the same error in esx5.1. an advice, thanks ------=_Part_105311_580229882.1362116265075 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit
Hi,all
   I just install xenserver6.1 in vcenter(esx4.1). esx is installed in hpDL68cG7.
and modify premiscuous mode. and when I start xp vm in xenserver, it  hint error like "HVM is required for this operation".
 the same error in esx5.1. an advice, thanks
 


------=_Part_105311_580229882.1362116265075-- --===============9123624247345007104== 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 --===============9123624247345007104==-- From xen-users-bounces@lists.xen.org Fri Mar 01 05:39:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 05:39: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 1UBIfI-0000nL-RI; Fri, 01 Mar 2013 05:37:52 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBIfH-0000nG-O3 for xen-users@lists.xen.org; Fri, 01 Mar 2013 05:37:51 +0000 Received: from [193.109.254.147:8282] by server-9.bemta-14.messagelabs.com id 65/43-30867-EAE30315; Fri, 01 Mar 2013 05:37:50 +0000 X-Env-Sender: studyfordo@163.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1362116268!9378368!1 X-Originating-IP: [220.181.13.123] X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMjAuMTgxLjEzLjEyMyA9PiA0NTky\n,sa_preprocessor: QmFkIElQOiAyMjAuMTgxLjEzLjEyMyA9PiA0NTky\n,HTML_40_50,HTML_MESSAGE, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23348 invoked from network); 1 Mar 2013 05:37:49 -0000 Received: from m13-123.163.com (HELO m13-123.163.com) (220.181.13.123) by server-8.tower-27.messagelabs.com with SMTP; 1 Mar 2013 05:37:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Subject:Content-Type: MIME-Version:Message-ID; bh=7f2MCQ8DJyReMvHC9cOqljbm2vDYGygvWCkP 0WGhkM4=; b=gx4JZTShs01rW79hzxCjXxi9XuF/OfnfYV7hKudnSxg7rRInBaw1 qtupRLbXaPakOYURJnlQ9TBEo5GiyhcVllsmgV6zU8f5hnGQNQMdItWHCjjBDkJG L9DdYaLK2H7h3bK+FcxrTCeUbN1hs7iRKmIhI5C5gju8Nb9djk26BTE= Received: from studyfordo$163.com ( [192.168.29.124, 116.6.78.178] ) by ajax-webmail-wmsvr123 (Coremail) ; Fri, 1 Mar 2013 13:37:45 +0800 (CST) X-Originating-IP: [192.168.29.124, 116.6.78.178] Date: Fri, 1 Mar 2013 13:37:45 +0800 (CST) From: studyfordo To: xen-users@lists.xen.org X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20130201(21528.5249.5248) Copyright (c) 2002-2013 www.mailtech.cn 163com X-CM-CTRLDATA: ulNc3WZvb3Rlcl9odG09NDIxOjgx MIME-Version: 1.0 Message-ID: <257c1ec5.6f84.13d2474c473.Coremail.studyfordo@163.com> X-CM-TRANSID: e8GowEAJm0KqPjBRdt9NAA--.404W X-CM-SenderInfo: xvwxv5xiruv0i6rwjhhfrp/1tbi6wTSYVEAA+X6qgABs6 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Subject: [Xen-users] hvm is required for this operation X-BeenThere: xen-users@lists.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="===============9123624247345007104==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9123624247345007104== Content-Type: multipart/alternative; boundary="----=_Part_105311_580229882.1362116265075" ------=_Part_105311_580229882.1362116265075 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit Hi,all I just install xenserver6.1 in vcenter(esx4.1). esx is installed in hpDL68cG7. and modify premiscuous mode. and when I start xp vm in xenserver, it hint error like "HVM is required for this operation". the same error in esx5.1. an advice, thanks ------=_Part_105311_580229882.1362116265075 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit
Hi,all
   I just install xenserver6.1 in vcenter(esx4.1). esx is installed in hpDL68cG7.
and modify premiscuous mode. and when I start xp vm in xenserver, it  hint error like "HVM is required for this operation".
 the same error in esx5.1. an advice, thanks
 


------=_Part_105311_580229882.1362116265075-- --===============9123624247345007104== 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 --===============9123624247345007104==-- From xen-users-bounces@lists.xen.org Fri Mar 01 08:53:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 08:53: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 1UBLhF-0005eh-RA; Fri, 01 Mar 2013 08:52:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBLhD-0005eS-Hf for Xen-users@lists.xen.org; Fri, 01 Mar 2013 08:52:03 +0000 Received: from [85.158.137.99:51369] by server-16.bemta-3.messagelabs.com id 41/43-20692-23C60315; Fri, 01 Mar 2013 08:52:02 +0000 X-Env-Sender: mk@theipcompany.nl X-Msg-Ref: server-15.tower-217.messagelabs.com!1362127919!16359075!1 X-Originating-IP: [209.85.220.45] 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.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9911 invoked from network); 1 Mar 2013 08:52:01 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2013 08:52:01 -0000 Received: by mail-pa0-f45.google.com with SMTP id kl14so1694389pab.18 for ; Fri, 01 Mar 2013 00:51:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Pd6GnAEWtKit/Kd4D9qCMXLDH9ddXubI7xFDGKGP/Cc=; b=R1yuMJ1tiA/+frAgaF7iGfoGS7H23won97LsvZ65Eg2jG1reRaMFCC34cnU4QLroCc vr+24rqXjPywxT+X+HaeAvpNBA5SiL+gfChpS/XIbYSSYHs2ahIAAs7zmYqBGQsbMz40 hsdmbXjU9xVRtI3nRu+GC+jgX3eTlB1wxlKDc2WDR9ovCmeSzGOVxQ0Ns7kf4QoIeM65 WFCU7rZqbnrwWxJ5FuHtbwcY3liUjd8lZNDQm4X3N91pWVH0REbDUk2s2+8fjzgtVFgw 4OxNfOe6MR0wDEtwIv/7eMS4Z2lyVxu4K546AUqnaWqF1t296uZRBcVHKtntVaB/ISRH C0+g== MIME-Version: 1.0 X-Received: by 10.66.10.106 with SMTP id h10mr18043221pab.35.1362127918945; Fri, 01 Mar 2013 00:51:58 -0800 (PST) Received: by 10.68.121.108 with HTTP; Fri, 1 Mar 2013 00:51:58 -0800 (PST) Date: Fri, 1 Mar 2013 09:51:58 +0100 Message-ID: From: Mustafa Karci To: Xen-users@lists.xen.org X-Gm-Message-State: ALoCoQka7pjHGi6BBCYnD23EMDX0o+EbuH8/SvqlkeQhX4UfH9F37hXnv/IsAdPVm6FLnoqLEcOl Subject: [Xen-users] =?windows-1252?q?XCP_1=2E6_don=92t_pass_throug_all_tr?= =?windows-1252?q?affic_to_=28tpcdump=29_snort?= X-BeenThere: xen-users@lists.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="===============1727329669576362841==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1727329669576362841== Content-Type: multipart/alternative; boundary=bcaec51f90afbf698504d6d91e03 --bcaec51f90afbf698504d6d91e03 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, I have been troubled with the traffic flow on the XCP 1.6 and XCP 0.5. - I have 4 servers in VLAN2 on port b12,b13,b14,b15 (these servers work on a XCP 0.5) - on port a3 have have mirrort al ports from a1,a2,a4-b24 - have a other HP server with XCP1.6 with (Debian 6.0.6 as host) and install snort. this has 2 eth carts in it. Eth0 is plugt in the VLAN2 network and configured with ip andn eth1 is in the a3 mirror port. The e= th1 is not configured with any IP address. This is only for listing. - have a AP in VLAN 4 on port a13 - And other 8 VLAN for other purpose. a1 | a3 a13 b12 b14 b23 |--------------------------------------------------------------------------= ------------------------| | VLAN1 LAN3 VLAN2 | |--------------------------------------------------------------------------= ------------------------| HP switch | VLAN2 | |--------------------------------------------------------------------------= ------------------------| a2 | a4 b13 b15 b24 Now the problem: When I install snort on the a3 mirror port I do not get ICMP packet=92s. I tried tcpdum -n -i eth1 proto ICMP en ping in de VLAN 2 from one server to the other but without success. I tried the tcpdump also on de XCP1.6 host 'tcpdump -n -i eth1 proto ICMP' no success , also i tried this with the xenbr1 and vif2.5 but still not getting any ICMP packets through. So i tried the XEN bridge - promiscous mode brctl setageing xenbr1 0 ifconfig eth1 promisc Still not working. I tried this also on pif-param-set uuid=3Dxxxxxxxx other-config:promiscous=3D=B4on=B4 and the vif-param-set uuid =3D xxxxxxx other-config:promiscous=3D=B4on=B4 still I can not see any ICMP packet getting through the XCP1.6 server. I plug in a laptop with Ubuntu 12.04 and give the same tcpdump -n -i eth1 proto ICMP and with this I see all the ICMP packet=92s coming through. What is see is the next. When I ping in the VLAN 2 network from one server tot the other I do not get any ICMP packets on the XCP1.6 but when I ping from the VLAN 2 server to the switch I get only the request from the x.x.x.x -> x.x.x.x whit my own pc I`m in the companys network i have added a route to this testing servers. But when i ping from the VLAN 2 server to my own pc i see the ICMP request and replay. output of brctl show : xenbr0 0000.e4115b0db5b4 no eth0 vif2.3 xenbr1 0000.e4115b0db5b5 no eth1 vif2.5 output pif-param-list uud=3Dxxxxxxxx device ( RO): eth1 MAC ( RO): xx:xx:xx:xx:xx: physical ( RO): true currently-attached ( RO): true MTU ( RO): 1500 VLAN ( RO): -1 bond-master-of ( RO): bond-slave-of ( RO): tunnel-access-PIF-of ( RO): tunnel-transport-PIF-of ( RO): management ( RO): false network-uuid ( RO): xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx network-name-label ( RO): Pool-wide network associated with eth1 host-uuid ( RO): xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx host-name-label ( RO): test IP-configuration-mode ( RO): None IP ( RO): netmask ( RO): gateway ( RO): IPv6-configuration-mode ( RO): None IPv6 ( RO): IPv6-gateway ( RO): Primary-address-type ( RO): IPv4 DNS ( RO): io_read_kbs ( RO): 7.491 io_write_kbs ( RO): 0.000 carrier ( RO): true vendor-id ( RO): 8086 vendor-name ( RO): Intel Corporation device-id ( RO): 10d3 device-name ( RO): 82574L Gigabit Network Connection speed ( RO): 1000 Mbit/s duplex ( RO): full disallow-unplug ( RW): false pci-bus-path ( RO): 0000:03:00.0 other-config (MRW): promiscous=3Don on the interface vif2.5 i see lot of packet lost vif2.5 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx UP BROADCAST RUNNING NOARP PROMISC MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:2199450 errors:0 *dropped:32233* overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:384 (384.0 b) TX bytes:327882492 (312.6 MiB) So what am I doing wrong? kind regards MK --bcaec51f90afbf698504d6d91e03 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi all,

I have been troubled with t= he traffic flow on the XCP 1.6 and XCP 0.5.

  • I hav= e 4 servers in VLAN2 on port b12,b13,b14,b15 (these servers work on a XCP 0= .5)
  • on port a3 have have mirrort al ports from a1,a2,a4= -b24
  • have a other HP server with XCP1.6 with (D= ebian 6.0.6 as host) and install snort. this has 2 eth carts in it. Eth0 is= plugt in the VLAN2 network and configured with ip andn eth1 is in the a3 m= irror port. The eth1 is not configured with any IP address. This is only fo= r listing.
  • have a AP in VLAN 4 on port a13
  • And other 8 VLAN for other purpose.


= =A0a1 | a3=A0=A0=A0=A0=A0=A0 =A0 =A0=A0 a13=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b12=A0 b14=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b23
|---------------------------------------------------------------= -----------------------------------|
|=A0=A0=A0 VLAN1=A0=A0= =A0=A0=A0=A0=A0 LAN3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 VLAN2=A0 =A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
|--------------------------------------------------------------------------= ------------------------|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 HP switch
|=A0=A0=A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VLAN2=A0 =A0=A0 =A0 =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
|---------------------------------------------------------------= -----------------------------------|
=A0a2 | a4=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b13 =A0 b15=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b24

Now the problem:
When I install snort on the a3 mi= rror port I do not get ICMP packet=92s. I tried tcpdum -n -i eth1 proto ICM= P en ping in de VLAN 2 from one server to the other but without success.
I tried the tcpdump also on de XCP1.6 host 'tcpdump -n -= i eth1 proto ICMP' no success
, also i tried this with th= e xenbr1 and vif2.5 but still not getting any ICMP packets through. So i tr= ied the XEN bridge - promiscous mode
brctl setageing xenbr1 0
ifconfig eth1 promisc
Still not working.

I tried this also on pif-param-set u= uid=3Dxxxxxxxx other-config:promiscous=3D=B4on=B4
and the vif= -param-set uuid =3D xxxxxxx other-config:promiscous=3D=B4on=B4

still I can not see any ICMP packet getting through the XCP1= .6 server.

I plug in a laptop with Ubuntu 12.04 and give= the same tcpdump -n -i eth1 proto ICMP and with this I see all the ICMP pa= cket=92s coming through.

What is see is the next. When I ping in the VLAN 2 network f= rom one server tot the other I do not get any ICMP packets on the XCP1.6 bu= t when I ping from the VLAN 2 server to the switch I get only the request f= rom the x.x.x.x -> x.x.x.x
whit my own pc I`m in the companys network i have added a route = to this testing servers. But when i ping from the VLAN 2 server to my own p= c i see the ICMP request and replay.

output of brctl show= :

xenbr0=A0=A0=A0 =A0=A0=A0 0000.e4115b0db5b4=A0=A0=A0 no=A0=A0=A0 =A0=A0= =A0 eth0
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = vif2.3
xenbr1=A0=A0=A0 =A0=A0=A0 0000.e4115b0db5b5=A0=A0=A0 no=A0=A0=A0 = =A0=A0=A0 eth1
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0= =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vif2.5

output pif-param-list uud=3Dxxxxxxxx

device ( RO): et= h1
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MAC ( RO): xx:xx:xx:= xx:xx:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 physical ( RO): = true
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 currently-attached= ( RO): true
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MTU ( RO):= 1500
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VLAN ( RO): -1
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bond-master-of ( RO):
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bond-slave-of ( RO): <not in = database>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 tunnel-acc= ess-PIF-of ( RO):
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 tunn= el-transport-PIF-of ( RO):
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 management ( RO): false=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 network-uuid ( RO): xxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxx
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 network-name-label ( RO): Pool-wide network associated with eth1
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 host-uuid ( RO): xxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxx
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 host-name-label ( RO): tes= t
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP-configuration-mode= ( RO): None
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP ( RO): =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 netmask ( RO):
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 gateway ( RO):
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPv6-configuration-mode ( RO): None=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPv6 ( RO):
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPv6-gateway ( RO):
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Primary-address-type ( RO): IPv4=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DNS ( RO):
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 io_read_kbs ( RO): 7.491
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 io_write_kbs ( RO): 0.000
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 carrier ( RO): true
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vendor-id ( RO): 8086
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vendor-name ( RO): Intel Corp= oration
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 device-id ( RO)= : 10d3
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 device-name ( RO= ): 82574L Gigabit Network Connection
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 speed ( RO): 1000 Mbit/s=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 duplex ( RO): full
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 disallow-unplug ( RW): fal= se
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pci-bus-path ( RO): = 0000:03:00.0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 other-conf= ig (MRW): promiscous=3Don

on the interface vif2.5 i see lot of packet lost

vif2= .5=A0 Link encap:Ethernet=A0 HWaddr xx:xx:xx:xx:xx
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 UP BROADCAST RUNNING NOARP PROMISC=A0 MTU:1500=A0 Metric:1
=A0=A0= =A0=A0=A0=A0=A0=A0=A0 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 TX packets:2199450 errors:0 dropped:32233 overruns:0 carrier:0
=A0=A0=A0=A0=A0=A0=A0=A0=A0 collisions:0 txqueuel= en:32
=A0=A0=A0=A0=A0=A0=A0=A0=A0 RX bytes:384 (384.0 b)=A0 TX bytes:32= 7882492 (312.6 MiB)

So what am I doing wrong?

kind regards

MK

<= div>


=A0=A0

--bcaec51f90afbf698504d6d91e03-- --===============1727329669576362841== 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 --===============1727329669576362841==-- From xen-users-bounces@lists.xen.org Fri Mar 01 08:53:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 08:53: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 1UBLhF-0005eh-RA; Fri, 01 Mar 2013 08:52:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBLhD-0005eS-Hf for Xen-users@lists.xen.org; Fri, 01 Mar 2013 08:52:03 +0000 Received: from [85.158.137.99:51369] by server-16.bemta-3.messagelabs.com id 41/43-20692-23C60315; Fri, 01 Mar 2013 08:52:02 +0000 X-Env-Sender: mk@theipcompany.nl X-Msg-Ref: server-15.tower-217.messagelabs.com!1362127919!16359075!1 X-Originating-IP: [209.85.220.45] 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.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9911 invoked from network); 1 Mar 2013 08:52:01 -0000 Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com) (209.85.220.45) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2013 08:52:01 -0000 Received: by mail-pa0-f45.google.com with SMTP id kl14so1694389pab.18 for ; Fri, 01 Mar 2013 00:51:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Pd6GnAEWtKit/Kd4D9qCMXLDH9ddXubI7xFDGKGP/Cc=; b=R1yuMJ1tiA/+frAgaF7iGfoGS7H23won97LsvZ65Eg2jG1reRaMFCC34cnU4QLroCc vr+24rqXjPywxT+X+HaeAvpNBA5SiL+gfChpS/XIbYSSYHs2ahIAAs7zmYqBGQsbMz40 hsdmbXjU9xVRtI3nRu+GC+jgX3eTlB1wxlKDc2WDR9ovCmeSzGOVxQ0Ns7kf4QoIeM65 WFCU7rZqbnrwWxJ5FuHtbwcY3liUjd8lZNDQm4X3N91pWVH0REbDUk2s2+8fjzgtVFgw 4OxNfOe6MR0wDEtwIv/7eMS4Z2lyVxu4K546AUqnaWqF1t296uZRBcVHKtntVaB/ISRH C0+g== MIME-Version: 1.0 X-Received: by 10.66.10.106 with SMTP id h10mr18043221pab.35.1362127918945; Fri, 01 Mar 2013 00:51:58 -0800 (PST) Received: by 10.68.121.108 with HTTP; Fri, 1 Mar 2013 00:51:58 -0800 (PST) Date: Fri, 1 Mar 2013 09:51:58 +0100 Message-ID: From: Mustafa Karci To: Xen-users@lists.xen.org X-Gm-Message-State: ALoCoQka7pjHGi6BBCYnD23EMDX0o+EbuH8/SvqlkeQhX4UfH9F37hXnv/IsAdPVm6FLnoqLEcOl Subject: [Xen-users] =?windows-1252?q?XCP_1=2E6_don=92t_pass_throug_all_tr?= =?windows-1252?q?affic_to_=28tpcdump=29_snort?= X-BeenThere: xen-users@lists.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="===============1727329669576362841==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1727329669576362841== Content-Type: multipart/alternative; boundary=bcaec51f90afbf698504d6d91e03 --bcaec51f90afbf698504d6d91e03 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, I have been troubled with the traffic flow on the XCP 1.6 and XCP 0.5. - I have 4 servers in VLAN2 on port b12,b13,b14,b15 (these servers work on a XCP 0.5) - on port a3 have have mirrort al ports from a1,a2,a4-b24 - have a other HP server with XCP1.6 with (Debian 6.0.6 as host) and install snort. this has 2 eth carts in it. Eth0 is plugt in the VLAN2 network and configured with ip andn eth1 is in the a3 mirror port. The e= th1 is not configured with any IP address. This is only for listing. - have a AP in VLAN 4 on port a13 - And other 8 VLAN for other purpose. a1 | a3 a13 b12 b14 b23 |--------------------------------------------------------------------------= ------------------------| | VLAN1 LAN3 VLAN2 | |--------------------------------------------------------------------------= ------------------------| HP switch | VLAN2 | |--------------------------------------------------------------------------= ------------------------| a2 | a4 b13 b15 b24 Now the problem: When I install snort on the a3 mirror port I do not get ICMP packet=92s. I tried tcpdum -n -i eth1 proto ICMP en ping in de VLAN 2 from one server to the other but without success. I tried the tcpdump also on de XCP1.6 host 'tcpdump -n -i eth1 proto ICMP' no success , also i tried this with the xenbr1 and vif2.5 but still not getting any ICMP packets through. So i tried the XEN bridge - promiscous mode brctl setageing xenbr1 0 ifconfig eth1 promisc Still not working. I tried this also on pif-param-set uuid=3Dxxxxxxxx other-config:promiscous=3D=B4on=B4 and the vif-param-set uuid =3D xxxxxxx other-config:promiscous=3D=B4on=B4 still I can not see any ICMP packet getting through the XCP1.6 server. I plug in a laptop with Ubuntu 12.04 and give the same tcpdump -n -i eth1 proto ICMP and with this I see all the ICMP packet=92s coming through. What is see is the next. When I ping in the VLAN 2 network from one server tot the other I do not get any ICMP packets on the XCP1.6 but when I ping from the VLAN 2 server to the switch I get only the request from the x.x.x.x -> x.x.x.x whit my own pc I`m in the companys network i have added a route to this testing servers. But when i ping from the VLAN 2 server to my own pc i see the ICMP request and replay. output of brctl show : xenbr0 0000.e4115b0db5b4 no eth0 vif2.3 xenbr1 0000.e4115b0db5b5 no eth1 vif2.5 output pif-param-list uud=3Dxxxxxxxx device ( RO): eth1 MAC ( RO): xx:xx:xx:xx:xx: physical ( RO): true currently-attached ( RO): true MTU ( RO): 1500 VLAN ( RO): -1 bond-master-of ( RO): bond-slave-of ( RO): tunnel-access-PIF-of ( RO): tunnel-transport-PIF-of ( RO): management ( RO): false network-uuid ( RO): xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx network-name-label ( RO): Pool-wide network associated with eth1 host-uuid ( RO): xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx host-name-label ( RO): test IP-configuration-mode ( RO): None IP ( RO): netmask ( RO): gateway ( RO): IPv6-configuration-mode ( RO): None IPv6 ( RO): IPv6-gateway ( RO): Primary-address-type ( RO): IPv4 DNS ( RO): io_read_kbs ( RO): 7.491 io_write_kbs ( RO): 0.000 carrier ( RO): true vendor-id ( RO): 8086 vendor-name ( RO): Intel Corporation device-id ( RO): 10d3 device-name ( RO): 82574L Gigabit Network Connection speed ( RO): 1000 Mbit/s duplex ( RO): full disallow-unplug ( RW): false pci-bus-path ( RO): 0000:03:00.0 other-config (MRW): promiscous=3Don on the interface vif2.5 i see lot of packet lost vif2.5 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx UP BROADCAST RUNNING NOARP PROMISC MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:2199450 errors:0 *dropped:32233* overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:384 (384.0 b) TX bytes:327882492 (312.6 MiB) So what am I doing wrong? kind regards MK --bcaec51f90afbf698504d6d91e03 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi all,

I have been troubled with t= he traffic flow on the XCP 1.6 and XCP 0.5.

  • I hav= e 4 servers in VLAN2 on port b12,b13,b14,b15 (these servers work on a XCP 0= .5)
  • on port a3 have have mirrort al ports from a1,a2,a4= -b24
  • have a other HP server with XCP1.6 with (D= ebian 6.0.6 as host) and install snort. this has 2 eth carts in it. Eth0 is= plugt in the VLAN2 network and configured with ip andn eth1 is in the a3 m= irror port. The eth1 is not configured with any IP address. This is only fo= r listing.
  • have a AP in VLAN 4 on port a13
  • And other 8 VLAN for other purpose.


= =A0a1 | a3=A0=A0=A0=A0=A0=A0 =A0 =A0=A0 a13=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b12=A0 b14=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b23
|---------------------------------------------------------------= -----------------------------------|
|=A0=A0=A0 VLAN1=A0=A0= =A0=A0=A0=A0=A0 LAN3=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 VLAN2=A0 =A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
|--------------------------------------------------------------------------= ------------------------|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 HP switch
|=A0=A0=A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VLAN2=A0 =A0=A0 =A0 =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
|---------------------------------------------------------------= -----------------------------------|
=A0a2 | a4=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b13 =A0 b15=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 b24

Now the problem:
When I install snort on the a3 mi= rror port I do not get ICMP packet=92s. I tried tcpdum -n -i eth1 proto ICM= P en ping in de VLAN 2 from one server to the other but without success.
I tried the tcpdump also on de XCP1.6 host 'tcpdump -n -= i eth1 proto ICMP' no success
, also i tried this with th= e xenbr1 and vif2.5 but still not getting any ICMP packets through. So i tr= ied the XEN bridge - promiscous mode
brctl setageing xenbr1 0
ifconfig eth1 promisc
Still not working.

I tried this also on pif-param-set u= uid=3Dxxxxxxxx other-config:promiscous=3D=B4on=B4
and the vif= -param-set uuid =3D xxxxxxx other-config:promiscous=3D=B4on=B4

still I can not see any ICMP packet getting through the XCP1= .6 server.

I plug in a laptop with Ubuntu 12.04 and give= the same tcpdump -n -i eth1 proto ICMP and with this I see all the ICMP pa= cket=92s coming through.

What is see is the next. When I ping in the VLAN 2 network f= rom one server tot the other I do not get any ICMP packets on the XCP1.6 bu= t when I ping from the VLAN 2 server to the switch I get only the request f= rom the x.x.x.x -> x.x.x.x
whit my own pc I`m in the companys network i have added a route = to this testing servers. But when i ping from the VLAN 2 server to my own p= c i see the ICMP request and replay.

output of brctl show= :

xenbr0=A0=A0=A0 =A0=A0=A0 0000.e4115b0db5b4=A0=A0=A0 no=A0=A0=A0 =A0=A0= =A0 eth0
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = vif2.3
xenbr1=A0=A0=A0 =A0=A0=A0 0000.e4115b0db5b5=A0=A0=A0 no=A0=A0=A0 = =A0=A0=A0 eth1
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0= =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vif2.5

output pif-param-list uud=3Dxxxxxxxx

device ( RO): et= h1
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MAC ( RO): xx:xx:xx:= xx:xx:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 physical ( RO): = true
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 currently-attached= ( RO): true
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MTU ( RO):= 1500
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 VLAN ( RO): -1
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bond-master-of ( RO):
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bond-slave-of ( RO): <not in = database>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 tunnel-acc= ess-PIF-of ( RO):
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 tunn= el-transport-PIF-of ( RO):
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 management ( RO): false=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 network-uuid ( RO): xxxxx= xxxxxxxxxxxxxxxxxxxxxxxxxxx
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 network-name-label ( RO): Pool-wide network associated with eth1
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 host-uuid ( RO): xxxxxxxx= xxxxxxxxxxxxxxxxxxxxxxxx
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 host-name-label ( RO): tes= t
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP-configuration-mode= ( RO): None
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IP ( RO): =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 netmask ( RO):
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 gateway ( RO):
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPv6-configuration-mode ( RO): None=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPv6 ( RO):
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPv6-gateway ( RO):
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Primary-address-type ( RO): IPv4=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DNS ( RO):
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 io_read_kbs ( RO): 7.491
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 io_write_kbs ( RO): 0.000
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 carrier ( RO): true
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vendor-id ( RO): 8086
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 vendor-name ( RO): Intel Corp= oration
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 device-id ( RO)= : 10d3
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 device-name ( RO= ): 82574L Gigabit Network Connection
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 speed ( RO): 1000 Mbit/s=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 duplex ( RO): full
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 disallow-unplug ( RW): fal= se
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pci-bus-path ( RO): = 0000:03:00.0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 other-conf= ig (MRW): promiscous=3Don

on the interface vif2.5 i see lot of packet lost

vif2= .5=A0 Link encap:Ethernet=A0 HWaddr xx:xx:xx:xx:xx
=A0=A0=A0=A0=A0=A0=A0= =A0=A0 UP BROADCAST RUNNING NOARP PROMISC=A0 MTU:1500=A0 Metric:1
=A0=A0= =A0=A0=A0=A0=A0=A0=A0 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 =A0=A0=A0=A0=A0=A0=A0=A0=A0 TX packets:2199450 errors:0 dropped:32233 overruns:0 carrier:0
=A0=A0=A0=A0=A0=A0=A0=A0=A0 collisions:0 txqueuel= en:32
=A0=A0=A0=A0=A0=A0=A0=A0=A0 RX bytes:384 (384.0 b)=A0 TX bytes:32= 7882492 (312.6 MiB)

So what am I doing wrong?

kind regards

MK

<= div>


=A0=A0

--bcaec51f90afbf698504d6d91e03-- --===============1727329669576362841== 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 --===============1727329669576362841==-- From xen-users-bounces@lists.xen.org Fri Mar 01 09:32:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 09:32: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 1UBMJU-0006gu-Vq; Fri, 01 Mar 2013 09:31:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBMJT-0006gp-SP for xen-users@lists.xensource.com; Fri, 01 Mar 2013 09:31:36 +0000 Received: from [85.158.137.99:34357] by server-11.bemta-3.messagelabs.com id DC/A2-01263-17570315; Fri, 01 Mar 2013 09:31:29 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-7.tower-217.messagelabs.com!1362130217!13607311!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14429 invoked from network); 1 Mar 2013 09:30:18 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-7.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 1 Mar 2013 09:30:18 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UBMHF-0006Ql-A1 for xen-users@lists.xensource.com; Fri, 01 Mar 2013 01:29:17 -0800 Date: Fri, 1 Mar 2013 01:29:17 -0800 (PST) From: Fantu To: xen-users@lists.xensource.com Message-ID: <1362130157287-5714599.post@n5.nabble.com> In-Reply-To: References: MIME-Version: 1.0 Subject: Re: [Xen-users] xen 4.3 unstable and spice protocol X-BeenThere: xen-users@lists.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 To enable spice building on upstream qemu on xen-unstable this changes is needed: --- a/tools/Makefile +++ b/tools/Makefile @@ -197,6 +197,8 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find --bindir=$(LIBEXEC) \ --datadir=$(SHAREDIR)/qemu-xen \ --disable-kvm \ + --enable-spice \ + --enable-usb-redir \ --disable-docs \ --python=$(PYTHON) \ $(IOEMU_CONFIGURE_CROSS); \ The usbredir line is optional, only if you want have also usbredirection. You need also the prerequisite packages of spice-server spice-protocol and all other dependencies, or qemu configure will show the missed prerequisite. You can also use the qemu build of your distro if have xen and spice support, debian experimental for example has it, I already test it. To use system qemu add in xl cfg this line (based on debian experimental qemu): device_model_override="/usr/bin/qemu-system-x86_64" Note: do not use the i386 build that have spice-server with known bugs, seem problem of all distributions, not only of debian. The experimental qemu must be recompiled (working also on Wheezy), after install of xen-unstable: - Download the git and switch to debian-experimental branch: http://anonscm.debian.org/gitweb/?p=pkg-qemu/qemu.git - Comment this line on debian/control: #libxen-dev [linux-amd64 linux-i386], Build qemu: debuild -i -b -us -uc Install qemu-system-x86 package and its dependencies (-common and -keymap) -- View this message in context: http://xen.1045712.n5.nabble.com/xen-4-3-unstable-and-spice-protocol-tp5714588p5714599.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 Fri Mar 01 09:32:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 09:32: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 1UBMJU-0006gu-Vq; Fri, 01 Mar 2013 09:31:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBMJT-0006gp-SP for xen-users@lists.xensource.com; Fri, 01 Mar 2013 09:31:36 +0000 Received: from [85.158.137.99:34357] by server-11.bemta-3.messagelabs.com id DC/A2-01263-17570315; Fri, 01 Mar 2013 09:31:29 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-7.tower-217.messagelabs.com!1362130217!13607311!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14429 invoked from network); 1 Mar 2013 09:30:18 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-7.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 1 Mar 2013 09:30:18 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UBMHF-0006Ql-A1 for xen-users@lists.xensource.com; Fri, 01 Mar 2013 01:29:17 -0800 Date: Fri, 1 Mar 2013 01:29:17 -0800 (PST) From: Fantu To: xen-users@lists.xensource.com Message-ID: <1362130157287-5714599.post@n5.nabble.com> In-Reply-To: References: MIME-Version: 1.0 Subject: Re: [Xen-users] xen 4.3 unstable and spice protocol X-BeenThere: xen-users@lists.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 To enable spice building on upstream qemu on xen-unstable this changes is needed: --- a/tools/Makefile +++ b/tools/Makefile @@ -197,6 +197,8 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find --bindir=$(LIBEXEC) \ --datadir=$(SHAREDIR)/qemu-xen \ --disable-kvm \ + --enable-spice \ + --enable-usb-redir \ --disable-docs \ --python=$(PYTHON) \ $(IOEMU_CONFIGURE_CROSS); \ The usbredir line is optional, only if you want have also usbredirection. You need also the prerequisite packages of spice-server spice-protocol and all other dependencies, or qemu configure will show the missed prerequisite. You can also use the qemu build of your distro if have xen and spice support, debian experimental for example has it, I already test it. To use system qemu add in xl cfg this line (based on debian experimental qemu): device_model_override="/usr/bin/qemu-system-x86_64" Note: do not use the i386 build that have spice-server with known bugs, seem problem of all distributions, not only of debian. The experimental qemu must be recompiled (working also on Wheezy), after install of xen-unstable: - Download the git and switch to debian-experimental branch: http://anonscm.debian.org/gitweb/?p=pkg-qemu/qemu.git - Comment this line on debian/control: #libxen-dev [linux-amd64 linux-i386], Build qemu: debuild -i -b -us -uc Install qemu-system-x86 package and its dependencies (-common and -keymap) -- View this message in context: http://xen.1045712.n5.nabble.com/xen-4-3-unstable-and-spice-protocol-tp5714588p5714599.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 Fri Mar 01 16:12:51 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 16:12: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 1UBSYe-0006TC-Qp; Fri, 01 Mar 2013 16:11:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBSYd-0006Sw-5b for xen-users@lists.xen.org; Fri, 01 Mar 2013 16:11:39 +0000 Received: from [85.158.137.99:14143] by server-3.bemta-3.messagelabs.com id D1/19-26934-A33D0315; Fri, 01 Mar 2013 16:11:38 +0000 X-Env-Sender: pkchouhan@gmail.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1362154238!17957841!1 X-Originating-IP: [209.85.220.52] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5050 invoked from network); 1 Mar 2013 16:10:44 -0000 Received: from mail-pa0-f52.google.com (HELO mail-pa0-f52.google.com) (209.85.220.52) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2013 16:10:44 -0000 Received: by mail-pa0-f52.google.com with SMTP id fb1so1896257pad.11 for ; Fri, 01 Mar 2013 08:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=VL1ZnKFSuULKDUgXklGCKN66q2Nr7CqSAE00rUSp4Og=; b=PHhthuYhwEUekLMKybilDdxha0ra4npWq50+TqqHz+2IKh0VmxQ2KsfBSa4jNQuOAH uS4RGtECHTjk9ACfMiKRAUNaw+DAWrGsYlsZtnj9YYOmNyIHWDoBI9JM35nkfWeEMqdt P97cQoI1pT7vicN/8lG2kXIRix00HWvVTokfDVAZVHQG4KAY9G7e57BznW727WLzdgsU 7l/rgzOfBN2lNFNI8RK3eZKNY4+6umhxSXXnRc47/+tR55sPBDhr1ZuzotArkqvJpVY9 q+jNgDKz8G77HlWYCAbWNxxwOk8jVEDckP8Lpy2dIDRXtxCGDaxnuKLvDp5dI3My1/Hr 1Z9w== MIME-Version: 1.0 X-Received: by 10.66.83.232 with SMTP id t8mr19454326pay.73.1362154238121; Fri, 01 Mar 2013 08:10:38 -0800 (PST) Received: by 10.69.0.138 with HTTP; Fri, 1 Mar 2013 08:10:37 -0800 (PST) Date: Fri, 1 Mar 2013 16:10:37 +0000 Message-ID: From: Pushpinder Chouhan To: xen-users@lists.xen.org Subject: [Xen-users] powerCLI equivalent X-BeenThere: xen-users@lists.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="===============8749556772410522012==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8749556772410522012== Content-Type: multipart/alternative; boundary=f46d042f95467ed46c04d6df3f1f --f46d042f95467ed46c04d6df3f1f Content-Type: text/plain; charset=ISO-8859-1 As PowerCLI is for VMware to collect the detail information about VMs and Host, is there any tool/script available for Xen VMs? --f46d042f95467ed46c04d6df3f1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As PowerCLI is for VMware=A0 to collect the detail information about VMs an= d Host, is there any tool/script available for Xen VMs?

--f46d042f95467ed46c04d6df3f1f-- --===============8749556772410522012== 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 --===============8749556772410522012==-- From xen-users-bounces@lists.xen.org Fri Mar 01 16:12:51 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 16:12: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 1UBSYe-0006TC-Qp; Fri, 01 Mar 2013 16:11:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBSYd-0006Sw-5b for xen-users@lists.xen.org; Fri, 01 Mar 2013 16:11:39 +0000 Received: from [85.158.137.99:14143] by server-3.bemta-3.messagelabs.com id D1/19-26934-A33D0315; Fri, 01 Mar 2013 16:11:38 +0000 X-Env-Sender: pkchouhan@gmail.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1362154238!17957841!1 X-Originating-IP: [209.85.220.52] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5050 invoked from network); 1 Mar 2013 16:10:44 -0000 Received: from mail-pa0-f52.google.com (HELO mail-pa0-f52.google.com) (209.85.220.52) by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2013 16:10:44 -0000 Received: by mail-pa0-f52.google.com with SMTP id fb1so1896257pad.11 for ; Fri, 01 Mar 2013 08:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=VL1ZnKFSuULKDUgXklGCKN66q2Nr7CqSAE00rUSp4Og=; b=PHhthuYhwEUekLMKybilDdxha0ra4npWq50+TqqHz+2IKh0VmxQ2KsfBSa4jNQuOAH uS4RGtECHTjk9ACfMiKRAUNaw+DAWrGsYlsZtnj9YYOmNyIHWDoBI9JM35nkfWeEMqdt P97cQoI1pT7vicN/8lG2kXIRix00HWvVTokfDVAZVHQG4KAY9G7e57BznW727WLzdgsU 7l/rgzOfBN2lNFNI8RK3eZKNY4+6umhxSXXnRc47/+tR55sPBDhr1ZuzotArkqvJpVY9 q+jNgDKz8G77HlWYCAbWNxxwOk8jVEDckP8Lpy2dIDRXtxCGDaxnuKLvDp5dI3My1/Hr 1Z9w== MIME-Version: 1.0 X-Received: by 10.66.83.232 with SMTP id t8mr19454326pay.73.1362154238121; Fri, 01 Mar 2013 08:10:38 -0800 (PST) Received: by 10.69.0.138 with HTTP; Fri, 1 Mar 2013 08:10:37 -0800 (PST) Date: Fri, 1 Mar 2013 16:10:37 +0000 Message-ID: From: Pushpinder Chouhan To: xen-users@lists.xen.org Subject: [Xen-users] powerCLI equivalent X-BeenThere: xen-users@lists.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="===============8749556772410522012==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8749556772410522012== Content-Type: multipart/alternative; boundary=f46d042f95467ed46c04d6df3f1f --f46d042f95467ed46c04d6df3f1f Content-Type: text/plain; charset=ISO-8859-1 As PowerCLI is for VMware to collect the detail information about VMs and Host, is there any tool/script available for Xen VMs? --f46d042f95467ed46c04d6df3f1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As PowerCLI is for VMware=A0 to collect the detail information about VMs an= d Host, is there any tool/script available for Xen VMs?

--f46d042f95467ed46c04d6df3f1f-- --===============8749556772410522012== 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 --===============8749556772410522012==-- From xen-users-bounces@lists.xen.org Fri Mar 01 16:47:03 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 16:47: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 1UBT5g-0008D7-NO; Fri, 01 Mar 2013 16:45:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBT5f-0008Cz-8H for xen-users@lists.xen.org; Fri, 01 Mar 2013 16:45:47 +0000 Received: from [85.158.139.211:39074] by server-5.bemta-5.messagelabs.com id F3/0E-02762-A3BD0315; Fri, 01 Mar 2013 16:45:46 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1362156345!18310578!1 X-Originating-IP: [74.125.82.174] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4362 invoked from network); 1 Mar 2013 16:45:45 -0000 Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com) (74.125.82.174) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2013 16:45:45 -0000 Received: by mail-we0-f174.google.com with SMTP id r6so2691084wey.19 for ; Fri, 01 Mar 2013 08:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=29dTTJlSt87Kgy1uuMPRCbecyU/0VUlXpT5pMzg6U2c=; b=oQUQA3ERklNWdRt62IEn0C3enPa/DC1KaLYPsCZ7uXZPaSg4JOJOGLkDQRbudwFP6R FX24dJGEC+s16xqyPfN/9scrxFcIrgpkiau35WzPUw+MN7I0V7iOV/WN3MW6ao8CDWID WzqnFgqokYFRo2NnVEvRbKKUdvIpGr3Y79jzb6uOh7wBCtUQiIUPixyPhqmkxQXkI7SL xi3ojW+q9+RsAU+ZxONzP3klNb0VGNlky9jA6gE6c9FU/aT+JJUz2b2iIZNUV6rlmGQ1 dGymwQ06aEN2lkA5rWC09nNMgrwQHLZ7NBePjyKwM0W/T0CGIY4lbzKB6NbHfdLVltLB UHjw== X-Received: by 10.180.79.133 with SMTP id j5mr5057426wix.27.1362156345580; Fri, 01 Mar 2013 08:45:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Fri, 1 Mar 2013 08:45:25 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Fri, 1 Mar 2013 11:45:25 -0500 Message-ID: To: Pushpinder Chouhan Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] powerCLI equivalent X-BeenThere: xen-users@lists.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="===============5212059565989833485==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5212059565989833485== Content-Type: multipart/alternative; boundary=f46d04428cfc1b644504d6dfbda7 --f46d04428cfc1b644504d6dfbda7 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 1, 2013 at 11:10 AM, Pushpinder Chouhan wrote: > As PowerCLI is for VMware to collect the detail information about VMs and > Host, is there any tool/script available for Xen VMs? > > > It depends on what info you're looking for. "xl info" will give you what domains (Xen lexicon for VMs) are currently running and their respective RAM and CPU allocations. "xl sched-credit" will give you scheduler credit allotments for each domain. "xl top" will give you a top-esque display of a bunch of stats. Is there something else you're looking for? -- --Zootboy Sent from some sort of computing device. --f46d04428cfc1b644504d6dfbda7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 1, 2013 at 11:10 AM, Pushpin= der Chouhan <pkchouhan@gmail.com> wrote:
As PowerCLI is for VMware=C2=A0 to collect the detail information about VMs= and Host, is there any tool/script available for Xen VMs?


It depends on what info you're looking for. &quo= t;xl info" will give you what domains (Xen lexicon for VMs) are curren= tly running and their respective RAM and CPU allocations. "xl sched-cr= edit" will give you scheduler credit allotments for each domain. "= ;xl top" will give you a top-esque display of a bunch of stats.

Is there something else you're looking for?

--=
--Zootboy

Sent from some sort of computing device.
<= /div> --f46d04428cfc1b644504d6dfbda7-- --===============5212059565989833485== 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 --===============5212059565989833485==-- From xen-users-bounces@lists.xen.org Fri Mar 01 16:47:03 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 16:47: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 1UBT5g-0008D7-NO; Fri, 01 Mar 2013 16:45:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBT5f-0008Cz-8H for xen-users@lists.xen.org; Fri, 01 Mar 2013 16:45:47 +0000 Received: from [85.158.139.211:39074] by server-5.bemta-5.messagelabs.com id F3/0E-02762-A3BD0315; Fri, 01 Mar 2013 16:45:46 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1362156345!18310578!1 X-Originating-IP: [74.125.82.174] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4362 invoked from network); 1 Mar 2013 16:45:45 -0000 Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com) (74.125.82.174) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2013 16:45:45 -0000 Received: by mail-we0-f174.google.com with SMTP id r6so2691084wey.19 for ; Fri, 01 Mar 2013 08:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=29dTTJlSt87Kgy1uuMPRCbecyU/0VUlXpT5pMzg6U2c=; b=oQUQA3ERklNWdRt62IEn0C3enPa/DC1KaLYPsCZ7uXZPaSg4JOJOGLkDQRbudwFP6R FX24dJGEC+s16xqyPfN/9scrxFcIrgpkiau35WzPUw+MN7I0V7iOV/WN3MW6ao8CDWID WzqnFgqokYFRo2NnVEvRbKKUdvIpGr3Y79jzb6uOh7wBCtUQiIUPixyPhqmkxQXkI7SL xi3ojW+q9+RsAU+ZxONzP3klNb0VGNlky9jA6gE6c9FU/aT+JJUz2b2iIZNUV6rlmGQ1 dGymwQ06aEN2lkA5rWC09nNMgrwQHLZ7NBePjyKwM0W/T0CGIY4lbzKB6NbHfdLVltLB UHjw== X-Received: by 10.180.79.133 with SMTP id j5mr5057426wix.27.1362156345580; Fri, 01 Mar 2013 08:45:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Fri, 1 Mar 2013 08:45:25 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Fri, 1 Mar 2013 11:45:25 -0500 Message-ID: To: Pushpinder Chouhan Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] powerCLI equivalent X-BeenThere: xen-users@lists.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="===============5212059565989833485==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5212059565989833485== Content-Type: multipart/alternative; boundary=f46d04428cfc1b644504d6dfbda7 --f46d04428cfc1b644504d6dfbda7 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 1, 2013 at 11:10 AM, Pushpinder Chouhan wrote: > As PowerCLI is for VMware to collect the detail information about VMs and > Host, is there any tool/script available for Xen VMs? > > > It depends on what info you're looking for. "xl info" will give you what domains (Xen lexicon for VMs) are currently running and their respective RAM and CPU allocations. "xl sched-credit" will give you scheduler credit allotments for each domain. "xl top" will give you a top-esque display of a bunch of stats. Is there something else you're looking for? -- --Zootboy Sent from some sort of computing device. --f46d04428cfc1b644504d6dfbda7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 1, 2013 at 11:10 AM, Pushpin= der Chouhan <pkchouhan@gmail.com> wrote:
As PowerCLI is for VMware=C2=A0 to collect the detail information about VMs= and Host, is there any tool/script available for Xen VMs?


It depends on what info you're looking for. &quo= t;xl info" will give you what domains (Xen lexicon for VMs) are curren= tly running and their respective RAM and CPU allocations. "xl sched-cr= edit" will give you scheduler credit allotments for each domain. "= ;xl top" will give you a top-esque display of a bunch of stats.

Is there something else you're looking for?

--=
--Zootboy

Sent from some sort of computing device.
<= /div> --f46d04428cfc1b644504d6dfbda7-- --===============5212059565989833485== 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 --===============5212059565989833485==-- From xen-users-bounces@lists.xen.org Fri Mar 01 22:57:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 22:57: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 1UBYrz-00006L-3l; Fri, 01 Mar 2013 22:56:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBYrx-00006G-93 for xen-users@lists.xen.org; Fri, 01 Mar 2013 22:56:01 +0000 Received: from [85.158.143.99:55230] by server-1.bemta-4.messagelabs.com id 41/6E-06203-00231315; Fri, 01 Mar 2013 22:56:00 +0000 X-Env-Sender: dsmhood@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1362178557!26804205!1 X-Originating-IP: [209.85.128.175] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25179 invoked from network); 1 Mar 2013 22:55:58 -0000 Received: from mail-ve0-f175.google.com (HELO mail-ve0-f175.google.com) (209.85.128.175) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2013 22:55:58 -0000 Received: by mail-ve0-f175.google.com with SMTP id cy12so3398936veb.34 for ; Fri, 01 Mar 2013 14:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=75+XXM8+0SYiAuEUiA7r80V1hX2OE3STOefwixAsVYo=; b=SpwoImtaiXJlTspsDJB22CtquIf2Ka9LjP3fYleftBnuky6kj1yOmwSriFSI0WImhP ZWPdG/X/0c/FNlOsq+43EoXYXkgJLqCXn1kUFYhHn1dvMGAc7oPUwiFmteYNVCpdC/xQ k8jwnDr9XBjWq1U2EuIZzzb+UZ4tff4JRwP04Q4DOkjZy73QbhdQaJ3wvO3pCA15iC/p W9CF+Y46T1jFEvTgCvaC7kzS9zdKTW5H0w1b4m6ih2PPQhF9V95xo6u/YUoL7OMT79Rb PRKYnW9WuoYNCAbZwewpRq6LpnBd0okRkv+RUlKPyjuInG5mDBJlCufvKBEaK8dBhlg5 xQhg== MIME-Version: 1.0 X-Received: by 10.58.161.41 with SMTP id xp9mr4750976veb.56.1362178556590; Fri, 01 Mar 2013 14:55:56 -0800 (PST) Received: by 10.220.173.130 with HTTP; Fri, 1 Mar 2013 14:55:56 -0800 (PST) Date: Sat, 2 Mar 2013 09:55:56 +1100 Message-ID: From: Daniel Hood To: xen-users@lists.xen.org Subject: [Xen-users] Some kind of hardware issue X-BeenThere: xen-users@lists.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, First time posting. So the story goes I bought a dedicated box from a hosting company. Opteron 1218 and MSI motherboard (Not sure which model exactly, LSPCI output is below). I've tried installing Debian 6, Ubuntu 12.04 and CentOS 6 then install Xen 4 hypervisor on them at different stages of this issue. All three boot their normal kernels perfectly. Can't seem to find any errors related. I then try to boot into my Xen kernel and these are the errors I'm getting: http://i.imgur.com/LHq7KCH.png http://i.imgur.com/fEfnm0I.png I've tried booting back into the normal kernel's and shit works. I've tried adding 'noacpi', 'acpi=off' and 'libata.force=noncq' on both the kernel and the module lines. No idea what else to try. Any ideas anyone? Here is the outputs from the CentOS attempts: ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [root@virt-host01 init.d]# cat /boot/grub/grub.conf # # Hetzner Online AG - installimage # GRUB bootloader configuration file # timeout 5 default 0 title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel /xen.gz dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin module /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=de module /boot/initramfs-3.7.10-1.el6xen.x86_64.img title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=de initrd /boot/initramfs-3.7.10-1.el6xen.x86_64.img title CentOS (2.6.32-279.22.1.el6.x86_64) root (hd0,1) kernel /boot/vmlinuz-2.6.32-279.22.1.el6.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_DM nomodeset initrd /boot/initramfs-2.6.32-279.22.1.el6.x86_64.img ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ LSPCI output: 00:00.0 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: NVIDIA Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: NVIDIA Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: NVIDIA Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: NVIDIA Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: NVIDIA Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: NVIDIA Corporation C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:05.0 VGA compatible controller: NVIDIA Corporation C51 [Quadro NVS 210S/GeForce 6150LE] (rev a2) 00:09.0 RAM memory: NVIDIA Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: NVIDIA Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: NVIDIA Corporation MCP51 SMBus (rev a3) 00:0b.0 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE interface: NVIDIA Corporation MCP51 IDE (rev a1) 00:0e.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev a1) 00:0f.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev a1) 00:10.0 PCI bridge: NVIDIA Corporation MCP51 PCI Bridge (rev a2) 00:14.0 Bridge: NVIDIA Corporation MCP51 Ethernet Controller (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Smartctl output: root@rescue ~ # smartctl -a /dev/sda smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.4.28] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint T166 Device Model: SAMSUNG HD321KJ Serial Number: S0MQJDQP603258 LU WWN Device Id: 5 0000f0 0db603258 Firmware Version: CP100-10 User Capacity: 320,072,933,376 bytes [320 GB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Fri Mar 1 23:50:44 2013 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 41) The self-test routine was interrupted by the host with a hard or soft reset. Total time to complete Offline data collection: ( 5746) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off supp ort. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 97) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_ FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 1 3 Spin_Up_Time 0x0007 100 100 015 Pre-fail Always - 5696 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 6877 10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 253 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21 187 Reported_Uncorrect 0x0032 253 253 000 Old_age Always - 0 188 Command_Timeout 0x0032 253 253 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 064 060 000 Old_age Always - 36 194 Temperature_Celsius 0x0022 130 118 000 Old_age Always - 36 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 461965997 196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 197 Total_Pending_Sectors 0x0012 253 253 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 202 Data_Address_Mark_Errs 0x0032 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA _of_first_error # 1 Extended offline Interrupted (host reset) 90% 6876 - # 2 Extended offline Interrupted (host reset) 90% 6869 - # 3 Extended offline Interrupted (host reset) 90% 6868 - # 4 Extended offline Completed without error 00% 6499 - Note: selective self-test log revision number (0) not 1 implies that no selectiv e self-test has ever been run SMART Selective self-test log data structure revision number 0 Note: revision number not 1 implies that no selective self-test has ever been ru n SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 01 22:57:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 01 Mar 2013 22:57: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 1UBYrz-00006L-3l; Fri, 01 Mar 2013 22:56:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBYrx-00006G-93 for xen-users@lists.xen.org; Fri, 01 Mar 2013 22:56:01 +0000 Received: from [85.158.143.99:55230] by server-1.bemta-4.messagelabs.com id 41/6E-06203-00231315; Fri, 01 Mar 2013 22:56:00 +0000 X-Env-Sender: dsmhood@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1362178557!26804205!1 X-Originating-IP: [209.85.128.175] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25179 invoked from network); 1 Mar 2013 22:55:58 -0000 Received: from mail-ve0-f175.google.com (HELO mail-ve0-f175.google.com) (209.85.128.175) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 1 Mar 2013 22:55:58 -0000 Received: by mail-ve0-f175.google.com with SMTP id cy12so3398936veb.34 for ; Fri, 01 Mar 2013 14:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=75+XXM8+0SYiAuEUiA7r80V1hX2OE3STOefwixAsVYo=; b=SpwoImtaiXJlTspsDJB22CtquIf2Ka9LjP3fYleftBnuky6kj1yOmwSriFSI0WImhP ZWPdG/X/0c/FNlOsq+43EoXYXkgJLqCXn1kUFYhHn1dvMGAc7oPUwiFmteYNVCpdC/xQ k8jwnDr9XBjWq1U2EuIZzzb+UZ4tff4JRwP04Q4DOkjZy73QbhdQaJ3wvO3pCA15iC/p W9CF+Y46T1jFEvTgCvaC7kzS9zdKTW5H0w1b4m6ih2PPQhF9V95xo6u/YUoL7OMT79Rb PRKYnW9WuoYNCAbZwewpRq6LpnBd0okRkv+RUlKPyjuInG5mDBJlCufvKBEaK8dBhlg5 xQhg== MIME-Version: 1.0 X-Received: by 10.58.161.41 with SMTP id xp9mr4750976veb.56.1362178556590; Fri, 01 Mar 2013 14:55:56 -0800 (PST) Received: by 10.220.173.130 with HTTP; Fri, 1 Mar 2013 14:55:56 -0800 (PST) Date: Sat, 2 Mar 2013 09:55:56 +1100 Message-ID: From: Daniel Hood To: xen-users@lists.xen.org Subject: [Xen-users] Some kind of hardware issue X-BeenThere: xen-users@lists.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, First time posting. So the story goes I bought a dedicated box from a hosting company. Opteron 1218 and MSI motherboard (Not sure which model exactly, LSPCI output is below). I've tried installing Debian 6, Ubuntu 12.04 and CentOS 6 then install Xen 4 hypervisor on them at different stages of this issue. All three boot their normal kernels perfectly. Can't seem to find any errors related. I then try to boot into my Xen kernel and these are the errors I'm getting: http://i.imgur.com/LHq7KCH.png http://i.imgur.com/fEfnm0I.png I've tried booting back into the normal kernel's and shit works. I've tried adding 'noacpi', 'acpi=off' and 'libata.force=noncq' on both the kernel and the module lines. No idea what else to try. Any ideas anyone? Here is the outputs from the CentOS attempts: ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [root@virt-host01 init.d]# cat /boot/grub/grub.conf # # Hetzner Online AG - installimage # GRUB bootloader configuration file # timeout 5 default 0 title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel /xen.gz dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin module /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=de module /boot/initramfs-3.7.10-1.el6xen.x86_64.img title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=de initrd /boot/initramfs-3.7.10-1.el6xen.x86_64.img title CentOS (2.6.32-279.22.1.el6.x86_64) root (hd0,1) kernel /boot/vmlinuz-2.6.32-279.22.1.el6.x86_64 ro root=/dev/md1 rd_NO_LUKS rd_NO_DM nomodeset initrd /boot/initramfs-2.6.32-279.22.1.el6.x86_64.img ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ LSPCI output: 00:00.0 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: NVIDIA Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: NVIDIA Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: NVIDIA Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: NVIDIA Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: NVIDIA Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: NVIDIA Corporation C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:05.0 VGA compatible controller: NVIDIA Corporation C51 [Quadro NVS 210S/GeForce 6150LE] (rev a2) 00:09.0 RAM memory: NVIDIA Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: NVIDIA Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: NVIDIA Corporation MCP51 SMBus (rev a3) 00:0b.0 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE interface: NVIDIA Corporation MCP51 IDE (rev a1) 00:0e.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev a1) 00:0f.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev a1) 00:10.0 PCI bridge: NVIDIA Corporation MCP51 PCI Bridge (rev a2) 00:14.0 Bridge: NVIDIA Corporation MCP51 Ethernet Controller (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Smartctl output: root@rescue ~ # smartctl -a /dev/sda smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.4.28] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint T166 Device Model: SAMSUNG HD321KJ Serial Number: S0MQJDQP603258 LU WWN Device Id: 5 0000f0 0db603258 Firmware Version: CP100-10 User Capacity: 320,072,933,376 bytes [320 GB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Fri Mar 1 23:50:44 2013 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 41) The self-test routine was interrupted by the host with a hard or soft reset. Total time to complete Offline data collection: ( 5746) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off supp ort. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 97) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_ FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 1 3 Spin_Up_Time 0x0007 100 100 015 Pre-fail Always - 5696 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 6877 10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 253 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21 187 Reported_Uncorrect 0x0032 253 253 000 Old_age Always - 0 188 Command_Timeout 0x0032 253 253 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 064 060 000 Old_age Always - 36 194 Temperature_Celsius 0x0022 130 118 000 Old_age Always - 36 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 461965997 196 Reallocated_Event_Count 0x0032 253 253 000 Old_age Always - 0 197 Total_Pending_Sectors 0x0012 253 253 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 253 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 202 Data_Address_Mark_Errs 0x0032 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA _of_first_error # 1 Extended offline Interrupted (host reset) 90% 6876 - # 2 Extended offline Interrupted (host reset) 90% 6869 - # 3 Extended offline Interrupted (host reset) 90% 6868 - # 4 Extended offline Completed without error 00% 6499 - Note: selective self-test log revision number (0) not 1 implies that no selectiv e self-test has ever been run SMART Selective self-test log data structure revision number 0 Note: revision number not 1 implies that no selective self-test has ever been ru n SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 02 01:53:49 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2013 01: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 1UBbcb-0000nU-6u; Sat, 02 Mar 2013 01:52:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBbcZ-0000nM-BX; Sat, 02 Mar 2013 01:52:19 +0000 Received: from [85.158.143.99:37012] by server-2.bemta-4.messagelabs.com id 9C/66-12656-25B51315; Sat, 02 Mar 2013 01:52:18 +0000 X-Env-Sender: ajlill@ajlc.waterloo.on.ca X-Msg-Ref: server-2.tower-216.messagelabs.com!1362189135!23160498!1 X-Originating-IP: [64.7.134.25] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19149 invoked from network); 2 Mar 2013 01:52:16 -0000 Received: from ajlill.sentex.ca (HELO mail.ajlc.waterloo.on.ca) (64.7.134.25) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Mar 2013 01:52:16 -0000 Received: from [10.19.61.4] (gloria.ajlc.waterloo.on.ca [10.19.61.4]) (authenticated bits=0) by mail.ajlc.waterloo.on.ca (8.14.3/8.14.3/Debian-9.4) with ESMTP id r221pxiU032520; Fri, 1 Mar 2013 20:52:00 -0500 Message-ID: <51315B3F.9080900@ajlc.waterloo.on.ca> Date: Fri, 01 Mar 2013 20:51:59 -0500 From: Tony Lill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: X-Enigmail-Version: 1.4.6 X-Spam-Status: No, score=-101.5 required=5.0 tests=ALL_TRUSTED,AWL, RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.ajlc.waterloo.on.ca Cc: xen-devel@lists.xen.org Subject: Re: [Xen-users] Some kind of hardware issue X-BeenThere: xen-users@lists.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I ran into strange disk issues when I tried to upgrade to the pvops kernels on two on my amd motherboards. On one of them, all I had to do was try to copy a large file and I'd get a slew of disk errors. I went back to xen-3.x and a xenified kernel (from opensuse) and all was well. See http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1806 On 03/01/2013 05:55 PM, Daniel Hood wrote: > Hi all, > > First time posting. > > So the story goes I bought a dedicated box from a hosting company. > Opteron 1218 and MSI motherboard (Not sure which model exactly, > LSPCI output is below). I've tried installing Debian 6, Ubuntu > 12.04 and CentOS 6 then install Xen 4 hypervisor on them at > different stages of this issue. All three boot their normal kernels > perfectly. Can't seem to find any errors related. > > I then try to boot into my Xen kernel and these are the errors I'm > getting: http://i.imgur.com/LHq7KCH.png > http://i.imgur.com/fEfnm0I.png > > I've tried booting back into the normal kernel's and shit works. > I've tried adding 'noacpi', 'acpi=off' and 'libata.force=noncq' on > both the kernel and the module lines. No idea what else to try. Any > ideas anyone? > > Here is the outputs from the CentOS attempts: > > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > [root@virt-host01 init.d]# cat /boot/grub/grub.conf # # Hetzner > Online AG - installimage # GRUB bootloader configuration file # > > timeout 5 default 0 > > title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel /xen.gz > dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin module > /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS > rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 > KEYTABLE=de module /boot/initramfs-3.7.10-1.el6xen.x86_64.img > > title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel > /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS > rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 > KEYTABLE=de initrd /boot/initramfs-3.7.10-1.el6xen.x86_64.img > > title CentOS (2.6.32-279.22.1.el6.x86_64) root (hd0,1) kernel > /boot/vmlinuz-2.6.32-279.22.1.el6.x86_64 ro root=/dev/md1 > rd_NO_LUKS rd_NO_DM nomodeset initrd > /boot/initramfs-2.6.32-279.22.1.el6.x86_64.img > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > LSPCI output: > > 00:00.0 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2) > 00:00.1 RAM memory: NVIDIA Corporation C51 Memory Controller 0 (rev > a2) 00:00.2 RAM memory: NVIDIA Corporation C51 Memory Controller 1 > (rev a2) 00:00.3 RAM memory: NVIDIA Corporation C51 Memory > Controller 5 (rev a2) 00:00.4 RAM memory: NVIDIA Corporation C51 > Memory Controller 4 (rev a2) 00:00.5 RAM memory: NVIDIA Corporation > C51 Host Bridge (rev a2) 00:00.6 RAM memory: NVIDIA Corporation C51 > Memory Controller 3 (rev a2) 00:00.7 RAM memory: NVIDIA Corporation > C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: NVIDIA > Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: > NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI > bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:05.0 > VGA compatible controller: NVIDIA Corporation C51 [Quadro NVS > 210S/GeForce 6150LE] (rev a2) 00:09.0 RAM memory: NVIDIA > Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: NVIDIA > Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: NVIDIA > Corporation MCP51 SMBus (rev a3) 00:0b.0 USB controller: NVIDIA > Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB controller: > NVIDIA Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE > interface: NVIDIA Corporation MCP51 IDE (rev a1) 00:0e.0 IDE > interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev a1) > 00:0f.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA > Controller (rev a1) 00:10.0 PCI bridge: NVIDIA Corporation MCP51 > PCI Bridge (rev a2) 00:14.0 Bridge: NVIDIA Corporation MCP51 > Ethernet Controller (rev a3) 00:18.0 Host bridge: Advanced Micro > Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology > Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 > [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro > Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host > bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Smartctl output: > > root@rescue ~ # smartctl -a /dev/sda smartctl 5.41 2011-06-09 r3365 > [x86_64-linux-3.4.28] (local build) Copyright (C) 2002-11 by Bruce > Allen, http://smartmontools.sourceforge.net > > === START OF INFORMATION SECTION === Model Family: SAMSUNG > SpinPoint T166 Device Model: SAMSUNG HD321KJ Serial Number: > S0MQJDQP603258 LU WWN Device Id: 5 0000f0 0db603258 Firmware > Version: CP100-10 User Capacity: 320,072,933,376 bytes [320 GB] > Sector Size: 512 bytes logical/physical Device is: In > smartctl database [for details use: -P show] ATA Version is: 8 > ATA Standard is: ATA-8-ACS revision 3b Local Time is: Fri Mar > 1 23:50:44 2013 CET SMART support is: Available - device has SMART > capability. SMART support is: Enabled > > === START OF READ SMART DATA SECTION === SMART overall-health > self-assessment test result: PASSED > > General SMART Values: Offline data collection status: (0x00) > Offline data collection activity was never started. Auto Offline > Data Collection: Disabled. Self-test execution status: ( 41) > The self-test routine was interrupted by the host with a hard or > soft reset. Total time to complete Offline data collection: > ( 5746) seconds. Offline data collection capabilities: > (0x5b) SMART execute Offline immediate. Auto Offline data > collection on/off supp ort. Suspend Offline collection upon new > command. Offline surface scan supported. Self-test supported. No > Conveyance Self-test supported. Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before > entering power-saving mode. Supports SMART auto save timer. Error > logging capability: (0x01) Error logging supported. General > Purpose Logging supported. Short self-test routine recommended > polling time: ( 2) minutes. Extended self-test routine > recommended polling time: ( 97) minutes. SCT capabilities: > (0x003f) SCT Status supported. SCT Error Recovery Control > supported. SCT Feature Control supported. SCT Data Table > supported. > > SMART Attributes Data Structure revision number: 16 Vendor Specific > SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG > VALUE WORST THRESH TYPE UPDATED WHEN_ FAILED RAW_VALUE 1 > Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always > - 1 3 Spin_Up_Time 0x0007 100 100 015 Pre-fail > Always - 5696 4 Start_Stop_Count 0x0032 100 100 > 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 > 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate > 0x000f 253 253 051 Pre-fail Always - 0 8 > Seek_Time_Performance 0x0025 253 253 015 Pre-fail > Offline - 0 9 Power_On_Hours 0x0032 100 100 000 > Old_age Always - 6877 10 Spin_Retry_Count 0x0033 253 > 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count > 0x0012 253 253 000 Old_age Always - 0 12 > Power_Cycle_Count 0x0032 100 100 000 Old_age Always > - 21 187 Reported_Uncorrect 0x0032 253 253 000 > Old_age Always - 0 188 Command_Timeout 0x0032 253 > 253 000 Old_age Always - 0 190 Airflow_Temperature_Cel > 0x0022 064 060 000 Old_age Always - 36 194 > Temperature_Celsius 0x0022 130 118 000 Old_age Always > - 36 195 Hardware_ECC_Recovered 0x001a 100 100 000 > Old_age Always - 461965997 196 Reallocated_Event_Count 0x0032 > 253 253 000 Old_age Always - 0 197 > Total_Pending_Sectors 0x0012 253 253 000 Old_age Always > - 0 198 Offline_Uncorrectable 0x0030 253 253 000 > Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 > 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate > 0x000a 100 100 000 Old_age Always - 0 201 > Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always > - 0 202 Data_Address_Mark_Errs 0x0032 253 253 000 > Old_age Always - 0 > > SMART Error Log Version: 1 No Errors Logged > > SMART Self-test log structure revision number 1 Num > Test_Description Status Remaining > LifeTime(hours) LBA _of_first_error # 1 Extended offline > Interrupted (host reset) 90% 6876 - # 2 Extended > offline Interrupted (host reset) 90% 6869 - # > 3 Extended offline Interrupted (host reset) 90% 6868 > - # 4 Extended offline Completed without error 00% > 6499 - > > Note: selective self-test log revision number (0) not 1 implies > that no selectiv e self-test has ever been run SMART Selective > self-test log data structure revision number 0 Note: revision > number not 1 implies that no selective self-test has ever been ru > n SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 > Not_testing 2 0 0 Not_testing 3 0 0 > Not_testing 4 0 0 Not_testing 5 0 0 > Not_testing Selective self-test flags (0x0): After scanning > selected spans, do NOT read-scan remainder of disk. If Selective > self-test is pending on power-up, resume after 0 minute delay. > > _______________________________________________ Xen-users mailing > list Xen-users@lists.xen.org http://lists.xen.org/xen-users > - -- Tony Lill, OCT, Tony.Lill@AJLC.Waterloo.ON.CA President, A. J. Lill Consultants (519) 650 0660 539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461 - --------------- http://www.ajlc.waterloo.on.ca/ ---------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlExWz8ACgkQGS8yZq1uvxA6RACePHzUrdXxFElp2IllVxvx86ej 3IEAn1CNRtuV5Dv6oBwPtK5j7VHopdOl =HrpZ -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 02 01:53:49 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2013 01: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 1UBbcb-0000nU-6u; Sat, 02 Mar 2013 01:52:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBbcZ-0000nM-BX; Sat, 02 Mar 2013 01:52:19 +0000 Received: from [85.158.143.99:37012] by server-2.bemta-4.messagelabs.com id 9C/66-12656-25B51315; Sat, 02 Mar 2013 01:52:18 +0000 X-Env-Sender: ajlill@ajlc.waterloo.on.ca X-Msg-Ref: server-2.tower-216.messagelabs.com!1362189135!23160498!1 X-Originating-IP: [64.7.134.25] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19149 invoked from network); 2 Mar 2013 01:52:16 -0000 Received: from ajlill.sentex.ca (HELO mail.ajlc.waterloo.on.ca) (64.7.134.25) by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Mar 2013 01:52:16 -0000 Received: from [10.19.61.4] (gloria.ajlc.waterloo.on.ca [10.19.61.4]) (authenticated bits=0) by mail.ajlc.waterloo.on.ca (8.14.3/8.14.3/Debian-9.4) with ESMTP id r221pxiU032520; Fri, 1 Mar 2013 20:52:00 -0500 Message-ID: <51315B3F.9080900@ajlc.waterloo.on.ca> Date: Fri, 01 Mar 2013 20:51:59 -0500 From: Tony Lill User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: X-Enigmail-Version: 1.4.6 X-Spam-Status: No, score=-101.5 required=5.0 tests=ALL_TRUSTED,AWL, RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.ajlc.waterloo.on.ca Cc: xen-devel@lists.xen.org Subject: Re: [Xen-users] Some kind of hardware issue X-BeenThere: xen-users@lists.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I ran into strange disk issues when I tried to upgrade to the pvops kernels on two on my amd motherboards. On one of them, all I had to do was try to copy a large file and I'd get a slew of disk errors. I went back to xen-3.x and a xenified kernel (from opensuse) and all was well. See http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1806 On 03/01/2013 05:55 PM, Daniel Hood wrote: > Hi all, > > First time posting. > > So the story goes I bought a dedicated box from a hosting company. > Opteron 1218 and MSI motherboard (Not sure which model exactly, > LSPCI output is below). I've tried installing Debian 6, Ubuntu > 12.04 and CentOS 6 then install Xen 4 hypervisor on them at > different stages of this issue. All three boot their normal kernels > perfectly. Can't seem to find any errors related. > > I then try to boot into my Xen kernel and these are the errors I'm > getting: http://i.imgur.com/LHq7KCH.png > http://i.imgur.com/fEfnm0I.png > > I've tried booting back into the normal kernel's and shit works. > I've tried adding 'noacpi', 'acpi=off' and 'libata.force=noncq' on > both the kernel and the module lines. No idea what else to try. Any > ideas anyone? > > Here is the outputs from the CentOS attempts: > > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > [root@virt-host01 init.d]# cat /boot/grub/grub.conf # # Hetzner > Online AG - installimage # GRUB bootloader configuration file # > > timeout 5 default 0 > > title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel /xen.gz > dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin module > /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS > rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 > KEYTABLE=de module /boot/initramfs-3.7.10-1.el6xen.x86_64.img > > title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel > /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS > rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 > KEYTABLE=de initrd /boot/initramfs-3.7.10-1.el6xen.x86_64.img > > title CentOS (2.6.32-279.22.1.el6.x86_64) root (hd0,1) kernel > /boot/vmlinuz-2.6.32-279.22.1.el6.x86_64 ro root=/dev/md1 > rd_NO_LUKS rd_NO_DM nomodeset initrd > /boot/initramfs-2.6.32-279.22.1.el6.x86_64.img > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > LSPCI output: > > 00:00.0 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2) > 00:00.1 RAM memory: NVIDIA Corporation C51 Memory Controller 0 (rev > a2) 00:00.2 RAM memory: NVIDIA Corporation C51 Memory Controller 1 > (rev a2) 00:00.3 RAM memory: NVIDIA Corporation C51 Memory > Controller 5 (rev a2) 00:00.4 RAM memory: NVIDIA Corporation C51 > Memory Controller 4 (rev a2) 00:00.5 RAM memory: NVIDIA Corporation > C51 Host Bridge (rev a2) 00:00.6 RAM memory: NVIDIA Corporation C51 > Memory Controller 3 (rev a2) 00:00.7 RAM memory: NVIDIA Corporation > C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: NVIDIA > Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: > NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI > bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:05.0 > VGA compatible controller: NVIDIA Corporation C51 [Quadro NVS > 210S/GeForce 6150LE] (rev a2) 00:09.0 RAM memory: NVIDIA > Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: NVIDIA > Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: NVIDIA > Corporation MCP51 SMBus (rev a3) 00:0b.0 USB controller: NVIDIA > Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB controller: > NVIDIA Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE > interface: NVIDIA Corporation MCP51 IDE (rev a1) 00:0e.0 IDE > interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev a1) > 00:0f.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA > Controller (rev a1) 00:10.0 PCI bridge: NVIDIA Corporation MCP51 > PCI Bridge (rev a2) 00:14.0 Bridge: NVIDIA Corporation MCP51 > Ethernet Controller (rev a3) 00:18.0 Host bridge: Advanced Micro > Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology > Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 > [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro > Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host > bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Smartctl output: > > root@rescue ~ # smartctl -a /dev/sda smartctl 5.41 2011-06-09 r3365 > [x86_64-linux-3.4.28] (local build) Copyright (C) 2002-11 by Bruce > Allen, http://smartmontools.sourceforge.net > > === START OF INFORMATION SECTION === Model Family: SAMSUNG > SpinPoint T166 Device Model: SAMSUNG HD321KJ Serial Number: > S0MQJDQP603258 LU WWN Device Id: 5 0000f0 0db603258 Firmware > Version: CP100-10 User Capacity: 320,072,933,376 bytes [320 GB] > Sector Size: 512 bytes logical/physical Device is: In > smartctl database [for details use: -P show] ATA Version is: 8 > ATA Standard is: ATA-8-ACS revision 3b Local Time is: Fri Mar > 1 23:50:44 2013 CET SMART support is: Available - device has SMART > capability. SMART support is: Enabled > > === START OF READ SMART DATA SECTION === SMART overall-health > self-assessment test result: PASSED > > General SMART Values: Offline data collection status: (0x00) > Offline data collection activity was never started. Auto Offline > Data Collection: Disabled. Self-test execution status: ( 41) > The self-test routine was interrupted by the host with a hard or > soft reset. Total time to complete Offline data collection: > ( 5746) seconds. Offline data collection capabilities: > (0x5b) SMART execute Offline immediate. Auto Offline data > collection on/off supp ort. Suspend Offline collection upon new > command. Offline surface scan supported. Self-test supported. No > Conveyance Self-test supported. Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before > entering power-saving mode. Supports SMART auto save timer. Error > logging capability: (0x01) Error logging supported. General > Purpose Logging supported. Short self-test routine recommended > polling time: ( 2) minutes. Extended self-test routine > recommended polling time: ( 97) minutes. SCT capabilities: > (0x003f) SCT Status supported. SCT Error Recovery Control > supported. SCT Feature Control supported. SCT Data Table > supported. > > SMART Attributes Data Structure revision number: 16 Vendor Specific > SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG > VALUE WORST THRESH TYPE UPDATED WHEN_ FAILED RAW_VALUE 1 > Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always > - 1 3 Spin_Up_Time 0x0007 100 100 015 Pre-fail > Always - 5696 4 Start_Stop_Count 0x0032 100 100 > 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 > 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate > 0x000f 253 253 051 Pre-fail Always - 0 8 > Seek_Time_Performance 0x0025 253 253 015 Pre-fail > Offline - 0 9 Power_On_Hours 0x0032 100 100 000 > Old_age Always - 6877 10 Spin_Retry_Count 0x0033 253 > 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count > 0x0012 253 253 000 Old_age Always - 0 12 > Power_Cycle_Count 0x0032 100 100 000 Old_age Always > - 21 187 Reported_Uncorrect 0x0032 253 253 000 > Old_age Always - 0 188 Command_Timeout 0x0032 253 > 253 000 Old_age Always - 0 190 Airflow_Temperature_Cel > 0x0022 064 060 000 Old_age Always - 36 194 > Temperature_Celsius 0x0022 130 118 000 Old_age Always > - 36 195 Hardware_ECC_Recovered 0x001a 100 100 000 > Old_age Always - 461965997 196 Reallocated_Event_Count 0x0032 > 253 253 000 Old_age Always - 0 197 > Total_Pending_Sectors 0x0012 253 253 000 Old_age Always > - 0 198 Offline_Uncorrectable 0x0030 253 253 000 > Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 > 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate > 0x000a 100 100 000 Old_age Always - 0 201 > Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always > - 0 202 Data_Address_Mark_Errs 0x0032 253 253 000 > Old_age Always - 0 > > SMART Error Log Version: 1 No Errors Logged > > SMART Self-test log structure revision number 1 Num > Test_Description Status Remaining > LifeTime(hours) LBA _of_first_error # 1 Extended offline > Interrupted (host reset) 90% 6876 - # 2 Extended > offline Interrupted (host reset) 90% 6869 - # > 3 Extended offline Interrupted (host reset) 90% 6868 > - # 4 Extended offline Completed without error 00% > 6499 - > > Note: selective self-test log revision number (0) not 1 implies > that no selectiv e self-test has ever been run SMART Selective > self-test log data structure revision number 0 Note: revision > number not 1 implies that no selective self-test has ever been ru > n SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 > Not_testing 2 0 0 Not_testing 3 0 0 > Not_testing 4 0 0 Not_testing 5 0 0 > Not_testing Selective self-test flags (0x0): After scanning > selected spans, do NOT read-scan remainder of disk. If Selective > self-test is pending on power-up, resume after 0 minute delay. > > _______________________________________________ Xen-users mailing > list Xen-users@lists.xen.org http://lists.xen.org/xen-users > - -- Tony Lill, OCT, Tony.Lill@AJLC.Waterloo.ON.CA President, A. J. Lill Consultants (519) 650 0660 539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461 - --------------- http://www.ajlc.waterloo.on.ca/ ---------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlExWz8ACgkQGS8yZq1uvxA6RACePHzUrdXxFElp2IllVxvx86ej 3IEAn1CNRtuV5Dv6oBwPtK5j7VHopdOl =HrpZ -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 02 10:57:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2013 10:57: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 1UBk76-0001Ew-JI; Sat, 02 Mar 2013 10:56:24 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBk75-0001Eo-2J; Sat, 02 Mar 2013 10:56:23 +0000 Received: from [85.158.137.99:12531] by server-7.bemta-3.messagelabs.com id 95/3B-06591-1DAD1315; Sat, 02 Mar 2013 10:56:17 +0000 X-Env-Sender: dsmhood@gmail.com X-Msg-Ref: server-12.tower-217.messagelabs.com!1362221774!15472311!1 X-Originating-IP: [209.85.128.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2352 invoked from network); 2 Mar 2013 10:56:16 -0000 Received: from mail-ve0-f173.google.com (HELO mail-ve0-f173.google.com) (209.85.128.173) by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Mar 2013 10:56:16 -0000 Received: by mail-ve0-f173.google.com with SMTP id oz10so3604872veb.18 for ; Sat, 02 Mar 2013 02:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aX+ipxCc/WZJJ/V6wnHgVlLw1fvdQmldt1MmaFGLFVw=; b=qpsU0tSyaO2VBexvxz88nVk5ILNWrClWext3X1NHh8hUHRbLS61K3VcD7Awewe9kyD w/o1y2R3ZLWm3SDHIPgyoipbRherCRfB6a54wrdHgWCWoanMwxAhP9FgXKCHclQrR7c1 l4P1TJe5EV09VlNry445b+FAodnxUOg25EStkgPkYfaXnmIVhiJJ9Le4x4C8IvQSF8cu vaJ8sW4SwNHciUPfW2l26FEljZg3KkNmDyAISAob/c24+Uz/u4MepmoHdGTJG58FKHQ9 B4zDSXwgy6ZIMaq+m/YTz8c3vDil5jkC5pXtzQdg7juMe1YYOEphVMMY3u/vvwTvInc9 yrPQ== MIME-Version: 1.0 X-Received: by 10.52.21.175 with SMTP id w15mr4573146vde.100.1362221774518; Sat, 02 Mar 2013 02:56:14 -0800 (PST) Received: by 10.220.173.130 with HTTP; Sat, 2 Mar 2013 02:56:14 -0800 (PST) In-Reply-To: <51315B3F.9080900@ajlc.waterloo.on.ca> References: <51315B3F.9080900@ajlc.waterloo.on.ca> Date: Sat, 2 Mar 2013 21:56:14 +1100 Message-ID: From: Daniel Hood To: Tony Lill Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-users] Some kind of hardware issue X-BeenThere: xen-users@lists.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 my answer. The hosting company has stated that both disks are defected. It seems like every time I've cried hardware failure before its always been something else and having both disks with issues seemed stupid but, according to the hosting company I have two defective disks. Thanks for the help all. Regards, Daniel On Sat, Mar 2, 2013 at 12:51 PM, Tony Lill wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I ran into strange disk issues when I tried to upgrade to the pvops > kernels on two on my amd motherboards. On one of them, all I had to > do was try to copy a large file and I'd get a slew of disk errors. I > went back to xen-3.x and a xenified kernel (from opensuse) and all was > well. > > See http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1806 > > On 03/01/2013 05:55 PM, Daniel Hood wrote: >> Hi all, >> >> First time posting. >> >> So the story goes I bought a dedicated box from a hosting company. >> Opteron 1218 and MSI motherboard (Not sure which model exactly, >> LSPCI output is below). I've tried installing Debian 6, Ubuntu >> 12.04 and CentOS 6 then install Xen 4 hypervisor on them at >> different stages of this issue. All three boot their normal kernels >> perfectly. Can't seem to find any errors related. >> >> I then try to boot into my Xen kernel and these are the errors I'm >> getting: http://i.imgur.com/LHq7KCH.png >> http://i.imgur.com/fEfnm0I.png >> >> I've tried booting back into the normal kernel's and shit works. >> I've tried adding 'noacpi', 'acpi=off' and 'libata.force=noncq' on >> both the kernel and the module lines. No idea what else to try. Any >> ideas anyone? >> >> Here is the outputs from the CentOS attempts: >> >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> [root@virt-host01 init.d]# cat /boot/grub/grub.conf # # Hetzner >> Online AG - installimage # GRUB bootloader configuration file # >> >> timeout 5 default 0 >> >> title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel /xen.gz >> dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin module >> /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS >> rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 >> KEYTABLE=de module /boot/initramfs-3.7.10-1.el6xen.x86_64.img >> >> title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel >> /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS >> rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 >> KEYTABLE=de initrd /boot/initramfs-3.7.10-1.el6xen.x86_64.img >> >> title CentOS (2.6.32-279.22.1.el6.x86_64) root (hd0,1) kernel >> /boot/vmlinuz-2.6.32-279.22.1.el6.x86_64 ro root=/dev/md1 >> rd_NO_LUKS rd_NO_DM nomodeset initrd >> /boot/initramfs-2.6.32-279.22.1.el6.x86_64.img >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> >> LSPCI output: >> >> 00:00.0 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2) >> 00:00.1 RAM memory: NVIDIA Corporation C51 Memory Controller 0 (rev >> a2) 00:00.2 RAM memory: NVIDIA Corporation C51 Memory Controller 1 >> (rev a2) 00:00.3 RAM memory: NVIDIA Corporation C51 Memory >> Controller 5 (rev a2) 00:00.4 RAM memory: NVIDIA Corporation C51 >> Memory Controller 4 (rev a2) 00:00.5 RAM memory: NVIDIA Corporation >> C51 Host Bridge (rev a2) 00:00.6 RAM memory: NVIDIA Corporation C51 >> Memory Controller 3 (rev a2) 00:00.7 RAM memory: NVIDIA Corporation >> C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: NVIDIA >> Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: >> NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI >> bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:05.0 >> VGA compatible controller: NVIDIA Corporation C51 [Quadro NVS >> 210S/GeForce 6150LE] (rev a2) 00:09.0 RAM memory: NVIDIA >> Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: NVIDIA >> Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: NVIDIA >> Corporation MCP51 SMBus (rev a3) 00:0b.0 USB controller: NVIDIA >> Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB controller: >> NVIDIA Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE >> interface: NVIDIA Corporation MCP51 IDE (rev a1) 00:0e.0 IDE >> interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev a1) >> 00:0f.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA >> Controller (rev a1) 00:10.0 PCI bridge: NVIDIA Corporation MCP51 >> PCI Bridge (rev a2) 00:14.0 Bridge: NVIDIA Corporation MCP51 >> Ethernet Controller (rev a3) 00:18.0 Host bridge: Advanced Micro >> Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology >> Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 >> [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro >> Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host >> bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] >> Miscellaneous Control >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> Smartctl output: >> >> root@rescue ~ # smartctl -a /dev/sda smartctl 5.41 2011-06-09 r3365 >> [x86_64-linux-3.4.28] (local build) Copyright (C) 2002-11 by Bruce >> Allen, http://smartmontools.sourceforge.net >> >> === START OF INFORMATION SECTION === Model Family: SAMSUNG >> SpinPoint T166 Device Model: SAMSUNG HD321KJ Serial Number: >> S0MQJDQP603258 LU WWN Device Id: 5 0000f0 0db603258 Firmware >> Version: CP100-10 User Capacity: 320,072,933,376 bytes [320 GB] >> Sector Size: 512 bytes logical/physical Device is: In >> smartctl database [for details use: -P show] ATA Version is: 8 >> ATA Standard is: ATA-8-ACS revision 3b Local Time is: Fri Mar >> 1 23:50:44 2013 CET SMART support is: Available - device has SMART >> capability. SMART support is: Enabled >> >> === START OF READ SMART DATA SECTION === SMART overall-health >> self-assessment test result: PASSED >> >> General SMART Values: Offline data collection status: (0x00) >> Offline data collection activity was never started. Auto Offline >> Data Collection: Disabled. Self-test execution status: ( 41) >> The self-test routine was interrupted by the host with a hard or >> soft reset. Total time to complete Offline data collection: >> ( 5746) seconds. Offline data collection capabilities: >> (0x5b) SMART execute Offline immediate. Auto Offline data >> collection on/off supp ort. Suspend Offline collection upon new >> command. Offline surface scan supported. Self-test supported. No >> Conveyance Self-test supported. Selective Self-test supported. >> SMART capabilities: (0x0003) Saves SMART data before >> entering power-saving mode. Supports SMART auto save timer. Error >> logging capability: (0x01) Error logging supported. General >> Purpose Logging supported. Short self-test routine recommended >> polling time: ( 2) minutes. Extended self-test routine >> recommended polling time: ( 97) minutes. SCT capabilities: >> (0x003f) SCT Status supported. SCT Error Recovery Control >> supported. SCT Feature Control supported. SCT Data Table >> supported. >> >> SMART Attributes Data Structure revision number: 16 Vendor Specific >> SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG >> VALUE WORST THRESH TYPE UPDATED WHEN_ FAILED RAW_VALUE 1 >> Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always >> - 1 3 Spin_Up_Time 0x0007 100 100 015 Pre-fail >> Always - 5696 4 Start_Stop_Count 0x0032 100 100 >> 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 >> 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate >> 0x000f 253 253 051 Pre-fail Always - 0 8 >> Seek_Time_Performance 0x0025 253 253 015 Pre-fail >> Offline - 0 9 Power_On_Hours 0x0032 100 100 000 >> Old_age Always - 6877 10 Spin_Retry_Count 0x0033 253 >> 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count >> 0x0012 253 253 000 Old_age Always - 0 12 >> Power_Cycle_Count 0x0032 100 100 000 Old_age Always >> - 21 187 Reported_Uncorrect 0x0032 253 253 000 >> Old_age Always - 0 188 Command_Timeout 0x0032 253 >> 253 000 Old_age Always - 0 190 Airflow_Temperature_Cel >> 0x0022 064 060 000 Old_age Always - 36 194 >> Temperature_Celsius 0x0022 130 118 000 Old_age Always >> - 36 195 Hardware_ECC_Recovered 0x001a 100 100 000 >> Old_age Always - 461965997 196 Reallocated_Event_Count 0x0032 >> 253 253 000 Old_age Always - 0 197 >> Total_Pending_Sectors 0x0012 253 253 000 Old_age Always >> - 0 198 Offline_Uncorrectable 0x0030 253 253 000 >> Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 >> 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate >> 0x000a 100 100 000 Old_age Always - 0 201 >> Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always >> - 0 202 Data_Address_Mark_Errs 0x0032 253 253 000 >> Old_age Always - 0 >> >> SMART Error Log Version: 1 No Errors Logged >> >> SMART Self-test log structure revision number 1 Num >> Test_Description Status Remaining >> LifeTime(hours) LBA _of_first_error # 1 Extended offline >> Interrupted (host reset) 90% 6876 - # 2 Extended >> offline Interrupted (host reset) 90% 6869 - # >> 3 Extended offline Interrupted (host reset) 90% 6868 >> - # 4 Extended offline Completed without error 00% >> 6499 - >> >> Note: selective self-test log revision number (0) not 1 implies >> that no selectiv e self-test has ever been run SMART Selective >> self-test log data structure revision number 0 Note: revision >> number not 1 implies that no selective self-test has ever been ru >> n SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 >> Not_testing 2 0 0 Not_testing 3 0 0 >> Not_testing 4 0 0 Not_testing 5 0 0 >> Not_testing Selective self-test flags (0x0): After scanning >> selected spans, do NOT read-scan remainder of disk. If Selective >> self-test is pending on power-up, resume after 0 minute delay. >> >> _______________________________________________ Xen-users mailing >> list Xen-users@lists.xen.org http://lists.xen.org/xen-users >> > > - -- > Tony Lill, OCT, Tony.Lill@AJLC.Waterloo.ON.CA > President, A. J. Lill Consultants (519) 650 0660 > 539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461 > - --------------- http://www.ajlc.waterloo.on.ca/ ---------------- > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlExWz8ACgkQGS8yZq1uvxA6RACePHzUrdXxFElp2IllVxvx86ej > 3IEAn1CNRtuV5Dv6oBwPtK5j7VHopdOl > =HrpZ > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Sat Mar 02 10:57:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2013 10:57: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 1UBk76-0001Ew-JI; Sat, 02 Mar 2013 10:56:24 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBk75-0001Eo-2J; Sat, 02 Mar 2013 10:56:23 +0000 Received: from [85.158.137.99:12531] by server-7.bemta-3.messagelabs.com id 95/3B-06591-1DAD1315; Sat, 02 Mar 2013 10:56:17 +0000 X-Env-Sender: dsmhood@gmail.com X-Msg-Ref: server-12.tower-217.messagelabs.com!1362221774!15472311!1 X-Originating-IP: [209.85.128.173] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2352 invoked from network); 2 Mar 2013 10:56:16 -0000 Received: from mail-ve0-f173.google.com (HELO mail-ve0-f173.google.com) (209.85.128.173) by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 2 Mar 2013 10:56:16 -0000 Received: by mail-ve0-f173.google.com with SMTP id oz10so3604872veb.18 for ; Sat, 02 Mar 2013 02:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aX+ipxCc/WZJJ/V6wnHgVlLw1fvdQmldt1MmaFGLFVw=; b=qpsU0tSyaO2VBexvxz88nVk5ILNWrClWext3X1NHh8hUHRbLS61K3VcD7Awewe9kyD w/o1y2R3ZLWm3SDHIPgyoipbRherCRfB6a54wrdHgWCWoanMwxAhP9FgXKCHclQrR7c1 l4P1TJe5EV09VlNry445b+FAodnxUOg25EStkgPkYfaXnmIVhiJJ9Le4x4C8IvQSF8cu vaJ8sW4SwNHciUPfW2l26FEljZg3KkNmDyAISAob/c24+Uz/u4MepmoHdGTJG58FKHQ9 B4zDSXwgy6ZIMaq+m/YTz8c3vDil5jkC5pXtzQdg7juMe1YYOEphVMMY3u/vvwTvInc9 yrPQ== MIME-Version: 1.0 X-Received: by 10.52.21.175 with SMTP id w15mr4573146vde.100.1362221774518; Sat, 02 Mar 2013 02:56:14 -0800 (PST) Received: by 10.220.173.130 with HTTP; Sat, 2 Mar 2013 02:56:14 -0800 (PST) In-Reply-To: <51315B3F.9080900@ajlc.waterloo.on.ca> References: <51315B3F.9080900@ajlc.waterloo.on.ca> Date: Sat, 2 Mar 2013 21:56:14 +1100 Message-ID: From: Daniel Hood To: Tony Lill Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-users] Some kind of hardware issue X-BeenThere: xen-users@lists.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 my answer. The hosting company has stated that both disks are defected. It seems like every time I've cried hardware failure before its always been something else and having both disks with issues seemed stupid but, according to the hosting company I have two defective disks. Thanks for the help all. Regards, Daniel On Sat, Mar 2, 2013 at 12:51 PM, Tony Lill wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I ran into strange disk issues when I tried to upgrade to the pvops > kernels on two on my amd motherboards. On one of them, all I had to > do was try to copy a large file and I'd get a slew of disk errors. I > went back to xen-3.x and a xenified kernel (from opensuse) and all was > well. > > See http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1806 > > On 03/01/2013 05:55 PM, Daniel Hood wrote: >> Hi all, >> >> First time posting. >> >> So the story goes I bought a dedicated box from a hosting company. >> Opteron 1218 and MSI motherboard (Not sure which model exactly, >> LSPCI output is below). I've tried installing Debian 6, Ubuntu >> 12.04 and CentOS 6 then install Xen 4 hypervisor on them at >> different stages of this issue. All three boot their normal kernels >> perfectly. Can't seem to find any errors related. >> >> I then try to boot into my Xen kernel and these are the errors I'm >> getting: http://i.imgur.com/LHq7KCH.png >> http://i.imgur.com/fEfnm0I.png >> >> I've tried booting back into the normal kernel's and shit works. >> I've tried adding 'noacpi', 'acpi=off' and 'libata.force=noncq' on >> both the kernel and the module lines. No idea what else to try. Any >> ideas anyone? >> >> Here is the outputs from the CentOS attempts: >> >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> [root@virt-host01 init.d]# cat /boot/grub/grub.conf # # Hetzner >> Online AG - installimage # GRUB bootloader configuration file # >> >> timeout 5 default 0 >> >> title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel /xen.gz >> dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin module >> /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS >> rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 >> KEYTABLE=de module /boot/initramfs-3.7.10-1.el6xen.x86_64.img >> >> title CentOS (3.7.10-1.el6xen.x86_64) root (hd0,1) kernel >> /boot/vmlinuz-3.7.10-1.el6xen.x86_64 ro root=/dev/md1 rd_NO_LUKS >> rd_NO_DM nomodeset SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 >> KEYTABLE=de initrd /boot/initramfs-3.7.10-1.el6xen.x86_64.img >> >> title CentOS (2.6.32-279.22.1.el6.x86_64) root (hd0,1) kernel >> /boot/vmlinuz-2.6.32-279.22.1.el6.x86_64 ro root=/dev/md1 >> rd_NO_LUKS rd_NO_DM nomodeset initrd >> /boot/initramfs-2.6.32-279.22.1.el6.x86_64.img >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> >> LSPCI output: >> >> 00:00.0 RAM memory: NVIDIA Corporation C51 Host Bridge (rev a2) >> 00:00.1 RAM memory: NVIDIA Corporation C51 Memory Controller 0 (rev >> a2) 00:00.2 RAM memory: NVIDIA Corporation C51 Memory Controller 1 >> (rev a2) 00:00.3 RAM memory: NVIDIA Corporation C51 Memory >> Controller 5 (rev a2) 00:00.4 RAM memory: NVIDIA Corporation C51 >> Memory Controller 4 (rev a2) 00:00.5 RAM memory: NVIDIA Corporation >> C51 Host Bridge (rev a2) 00:00.6 RAM memory: NVIDIA Corporation C51 >> Memory Controller 3 (rev a2) 00:00.7 RAM memory: NVIDIA Corporation >> C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: NVIDIA >> Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: >> NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI >> bridge: NVIDIA Corporation C51 PCI Express Bridge (rev a1) 00:05.0 >> VGA compatible controller: NVIDIA Corporation C51 [Quadro NVS >> 210S/GeForce 6150LE] (rev a2) 00:09.0 RAM memory: NVIDIA >> Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: NVIDIA >> Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: NVIDIA >> Corporation MCP51 SMBus (rev a3) 00:0b.0 USB controller: NVIDIA >> Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB controller: >> NVIDIA Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE >> interface: NVIDIA Corporation MCP51 IDE (rev a1) 00:0e.0 IDE >> interface: NVIDIA Corporation MCP51 Serial ATA Controller (rev a1) >> 00:0f.0 IDE interface: NVIDIA Corporation MCP51 Serial ATA >> Controller (rev a1) 00:10.0 PCI bridge: NVIDIA Corporation MCP51 >> PCI Bridge (rev a2) 00:14.0 Bridge: NVIDIA Corporation MCP51 >> Ethernet Controller (rev a3) 00:18.0 Host bridge: Advanced Micro >> Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology >> Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 >> [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro >> Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host >> bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] >> Miscellaneous Control >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> Smartctl output: >> >> root@rescue ~ # smartctl -a /dev/sda smartctl 5.41 2011-06-09 r3365 >> [x86_64-linux-3.4.28] (local build) Copyright (C) 2002-11 by Bruce >> Allen, http://smartmontools.sourceforge.net >> >> === START OF INFORMATION SECTION === Model Family: SAMSUNG >> SpinPoint T166 Device Model: SAMSUNG HD321KJ Serial Number: >> S0MQJDQP603258 LU WWN Device Id: 5 0000f0 0db603258 Firmware >> Version: CP100-10 User Capacity: 320,072,933,376 bytes [320 GB] >> Sector Size: 512 bytes logical/physical Device is: In >> smartctl database [for details use: -P show] ATA Version is: 8 >> ATA Standard is: ATA-8-ACS revision 3b Local Time is: Fri Mar >> 1 23:50:44 2013 CET SMART support is: Available - device has SMART >> capability. SMART support is: Enabled >> >> === START OF READ SMART DATA SECTION === SMART overall-health >> self-assessment test result: PASSED >> >> General SMART Values: Offline data collection status: (0x00) >> Offline data collection activity was never started. Auto Offline >> Data Collection: Disabled. Self-test execution status: ( 41) >> The self-test routine was interrupted by the host with a hard or >> soft reset. Total time to complete Offline data collection: >> ( 5746) seconds. Offline data collection capabilities: >> (0x5b) SMART execute Offline immediate. Auto Offline data >> collection on/off supp ort. Suspend Offline collection upon new >> command. Offline surface scan supported. Self-test supported. No >> Conveyance Self-test supported. Selective Self-test supported. >> SMART capabilities: (0x0003) Saves SMART data before >> entering power-saving mode. Supports SMART auto save timer. Error >> logging capability: (0x01) Error logging supported. General >> Purpose Logging supported. Short self-test routine recommended >> polling time: ( 2) minutes. Extended self-test routine >> recommended polling time: ( 97) minutes. SCT capabilities: >> (0x003f) SCT Status supported. SCT Error Recovery Control >> supported. SCT Feature Control supported. SCT Data Table >> supported. >> >> SMART Attributes Data Structure revision number: 16 Vendor Specific >> SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG >> VALUE WORST THRESH TYPE UPDATED WHEN_ FAILED RAW_VALUE 1 >> Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always >> - 1 3 Spin_Up_Time 0x0007 100 100 015 Pre-fail >> Always - 5696 4 Start_Stop_Count 0x0032 100 100 >> 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 >> 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate >> 0x000f 253 253 051 Pre-fail Always - 0 8 >> Seek_Time_Performance 0x0025 253 253 015 Pre-fail >> Offline - 0 9 Power_On_Hours 0x0032 100 100 000 >> Old_age Always - 6877 10 Spin_Retry_Count 0x0033 253 >> 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count >> 0x0012 253 253 000 Old_age Always - 0 12 >> Power_Cycle_Count 0x0032 100 100 000 Old_age Always >> - 21 187 Reported_Uncorrect 0x0032 253 253 000 >> Old_age Always - 0 188 Command_Timeout 0x0032 253 >> 253 000 Old_age Always - 0 190 Airflow_Temperature_Cel >> 0x0022 064 060 000 Old_age Always - 36 194 >> Temperature_Celsius 0x0022 130 118 000 Old_age Always >> - 36 195 Hardware_ECC_Recovered 0x001a 100 100 000 >> Old_age Always - 461965997 196 Reallocated_Event_Count 0x0032 >> 253 253 000 Old_age Always - 0 197 >> Total_Pending_Sectors 0x0012 253 253 000 Old_age Always >> - 0 198 Offline_Uncorrectable 0x0030 253 253 000 >> Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 >> 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate >> 0x000a 100 100 000 Old_age Always - 0 201 >> Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always >> - 0 202 Data_Address_Mark_Errs 0x0032 253 253 000 >> Old_age Always - 0 >> >> SMART Error Log Version: 1 No Errors Logged >> >> SMART Self-test log structure revision number 1 Num >> Test_Description Status Remaining >> LifeTime(hours) LBA _of_first_error # 1 Extended offline >> Interrupted (host reset) 90% 6876 - # 2 Extended >> offline Interrupted (host reset) 90% 6869 - # >> 3 Extended offline Interrupted (host reset) 90% 6868 >> - # 4 Extended offline Completed without error 00% >> 6499 - >> >> Note: selective self-test log revision number (0) not 1 implies >> that no selectiv e self-test has ever been run SMART Selective >> self-test log data structure revision number 0 Note: revision >> number not 1 implies that no selective self-test has ever been ru >> n SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 >> Not_testing 2 0 0 Not_testing 3 0 0 >> Not_testing 4 0 0 Not_testing 5 0 0 >> Not_testing Selective self-test flags (0x0): After scanning >> selected spans, do NOT read-scan remainder of disk. If Selective >> self-test is pending on power-up, resume after 0 minute delay. >> >> _______________________________________________ Xen-users mailing >> list Xen-users@lists.xen.org http://lists.xen.org/xen-users >> > > - -- > Tony Lill, OCT, Tony.Lill@AJLC.Waterloo.ON.CA > President, A. J. Lill Consultants (519) 650 0660 > 539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461 > - --------------- http://www.ajlc.waterloo.on.ca/ ---------------- > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlExWz8ACgkQGS8yZq1uvxA6RACePHzUrdXxFElp2IllVxvx86ej > 3IEAn1CNRtuV5Dv6oBwPtK5j7VHopdOl > =HrpZ > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Sat Mar 02 16:04:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2013 16:04: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 1UBotl-00067I-1j; Sat, 02 Mar 2013 16:02:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBoti-00067D-TR for xen-users@lists.xen.org; Sat, 02 Mar 2013 16:02:55 +0000 Received: from [85.158.138.51:50975] by server-16.bemta-3.messagelabs.com id 20/E4-20692-DA222315; Sat, 02 Mar 2013 16:02:53 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1362240172!23976141!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4354 invoked from network); 2 Mar 2013 16:02:52 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-10.tower-174.messagelabs.com with SMTP; 2 Mar 2013 16:02:52 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r22G2nh2013065; Sat, 2 Mar 2013 10:02:50 -0600 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r22G2nTB013064; Sat, 2 Mar 2013 10:02:49 -0600 Date: Sat, 2 Mar 2013 10:02:49 -0600 From: "Dr. Greg Wettstein" Message-Id: <201303021602.r22G2nTB013064@wind.enjellic.com> In-Reply-To: povder "[Xen-users] VGA passthrough radeon 4850 as primary card" (Feb 27, 1:14pm) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: povder , xen-users@lists.xen.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Sat, 02 Mar 2013 10:02:50 -0600 (CST) Subject: Re: [Xen-users] VGA passthrough radeon 4850 as primary card X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: greg@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Feb 27, 1:14pm, povder wrote: } Subject: [Xen-users] VGA passthrough radeon 4850 as primary card > Hi all Good morning, hope the weekend is going well for everyone. I posted the availability of the following to xen-devel but have just recently started to following xen-users as well. Since there seemed to be generic interest in this I thought it may be worthwhile to re-post here. > I'm trying to enable VGA passthrough in linux domU without > success. I want to pass through AMD Radeon HD 4850 - 03:00.0 VGA > compatible controller: Advanced Micro Devices [AMD] nee ATI RV770 > [Radeon HD 4850] as a _primary_ VGA for the VM. Nothing is showing > up on the monitor that I have connected to graphics card's HDMI > port. I have IOMMU enabled. I searched mailing lists and I don't > know what to think about it. There is some information about ATI > cards passthrough as primary VGA, some patches were posted but that > was long time ago so my first question is: > > Is passthrough of ATI devices as primary VGA supposed to work now in > Xen 4.2.1 without patches? We have run thousands of sessions of primary VGA pass-through using ATI cards. We currently use stock Windows 7 with no additional drivers. Patches are needed to QEMU in order to support primary pass-through. The following URL references patches which will work for the 4.1.x and 4.2.x releases: ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.ati-passthrough.patch ftp://ftp.enjellic.com/pub/xen/xen-4.2.0.ati-passthrough.patch The patches can be applied and the updated qemu-dm can be dropped into place, canonically in the /usr/lib/xen/bin directory. The following is a sample configuration: --------------------------------------------------------------------------- builder='hvm' memory = 3072 name = "Windows" viridian = 1 vif = [ 'type=ioemu, bridge=bridge0, model=e1000' ] acpi = 1 apic = 1 disk = [ 'phy:/dev/localvg1/winsnap,hda,w' ] boot="c" sdl=0 vnc=0 soundhw='ac97' stdvga=1 gfx_passthru=1 pci=[ '01:00.0', '00:1a.0' ] --------------------------------------------------------------------------- The BDF definitions for the pci pass-through directive are for the ATI card and the USB host controller which drives the keyboard and mouse. The trick to getting this right is to automate the detach and re-attachment of the PCI devices to dom0. The following script provides a framework for doing this: ftp://ftp.enjellic.com/pub/xen/run-passthrough It should be salted according to the flavor of your particular installation. Access to the vbetool utility, which most distribution include to support suspend/resume, is desirable in order to run the BIOS-post initialization functions so the graphics card works properly upon return of control to dom0. You will want to have an SSH session open from an alternate location to whatever platform you are testing this all on. It will be the only way to control the system if something goes awry during the setup/teardown of the pass-through session. Hope the above is helpful. Have a good weekend. Greg }-- End of excerpt from povder As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "One uses power by grasping it lightly. To grasp with too much force is to be taken over by power, thus becoming its victim." -- Bene Gesserit Axiom _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 02 16:04:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 02 Mar 2013 16:04: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 1UBotl-00067I-1j; Sat, 02 Mar 2013 16:02:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBoti-00067D-TR for xen-users@lists.xen.org; Sat, 02 Mar 2013 16:02:55 +0000 Received: from [85.158.138.51:50975] by server-16.bemta-3.messagelabs.com id 20/E4-20692-DA222315; Sat, 02 Mar 2013 16:02:53 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1362240172!23976141!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4354 invoked from network); 2 Mar 2013 16:02:52 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-10.tower-174.messagelabs.com with SMTP; 2 Mar 2013 16:02:52 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r22G2nh2013065; Sat, 2 Mar 2013 10:02:50 -0600 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r22G2nTB013064; Sat, 2 Mar 2013 10:02:49 -0600 Date: Sat, 2 Mar 2013 10:02:49 -0600 From: "Dr. Greg Wettstein" Message-Id: <201303021602.r22G2nTB013064@wind.enjellic.com> In-Reply-To: povder "[Xen-users] VGA passthrough radeon 4850 as primary card" (Feb 27, 1:14pm) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: povder , xen-users@lists.xen.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Sat, 02 Mar 2013 10:02:50 -0600 (CST) Subject: Re: [Xen-users] VGA passthrough radeon 4850 as primary card X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: greg@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Feb 27, 1:14pm, povder wrote: } Subject: [Xen-users] VGA passthrough radeon 4850 as primary card > Hi all Good morning, hope the weekend is going well for everyone. I posted the availability of the following to xen-devel but have just recently started to following xen-users as well. Since there seemed to be generic interest in this I thought it may be worthwhile to re-post here. > I'm trying to enable VGA passthrough in linux domU without > success. I want to pass through AMD Radeon HD 4850 - 03:00.0 VGA > compatible controller: Advanced Micro Devices [AMD] nee ATI RV770 > [Radeon HD 4850] as a _primary_ VGA for the VM. Nothing is showing > up on the monitor that I have connected to graphics card's HDMI > port. I have IOMMU enabled. I searched mailing lists and I don't > know what to think about it. There is some information about ATI > cards passthrough as primary VGA, some patches were posted but that > was long time ago so my first question is: > > Is passthrough of ATI devices as primary VGA supposed to work now in > Xen 4.2.1 without patches? We have run thousands of sessions of primary VGA pass-through using ATI cards. We currently use stock Windows 7 with no additional drivers. Patches are needed to QEMU in order to support primary pass-through. The following URL references patches which will work for the 4.1.x and 4.2.x releases: ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.ati-passthrough.patch ftp://ftp.enjellic.com/pub/xen/xen-4.2.0.ati-passthrough.patch The patches can be applied and the updated qemu-dm can be dropped into place, canonically in the /usr/lib/xen/bin directory. The following is a sample configuration: --------------------------------------------------------------------------- builder='hvm' memory = 3072 name = "Windows" viridian = 1 vif = [ 'type=ioemu, bridge=bridge0, model=e1000' ] acpi = 1 apic = 1 disk = [ 'phy:/dev/localvg1/winsnap,hda,w' ] boot="c" sdl=0 vnc=0 soundhw='ac97' stdvga=1 gfx_passthru=1 pci=[ '01:00.0', '00:1a.0' ] --------------------------------------------------------------------------- The BDF definitions for the pci pass-through directive are for the ATI card and the USB host controller which drives the keyboard and mouse. The trick to getting this right is to automate the detach and re-attachment of the PCI devices to dom0. The following script provides a framework for doing this: ftp://ftp.enjellic.com/pub/xen/run-passthrough It should be salted according to the flavor of your particular installation. Access to the vbetool utility, which most distribution include to support suspend/resume, is desirable in order to run the BIOS-post initialization functions so the graphics card works properly upon return of control to dom0. You will want to have an SSH session open from an alternate location to whatever platform you are testing this all on. It will be the only way to control the system if something goes awry during the setup/teardown of the pass-through session. Hope the above is helpful. Have a good weekend. Greg }-- End of excerpt from povder As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "One uses power by grasping it lightly. To grasp with too much force is to be taken over by power, thus becoming its victim." -- Bene Gesserit Axiom _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 03 06:52:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 06:52:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UC2kn-0006dP-JF; Sun, 03 Mar 2013 06:50:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UC2kl-0006dK-DC for xen-users@lists.xen.org; Sun, 03 Mar 2013 06:50:35 +0000 Received: from [85.158.143.99:49846] by server-3.bemta-4.messagelabs.com id 5F/81-02186-AB2F2315; Sun, 03 Mar 2013 06:50:34 +0000 X-Env-Sender: ghariharan@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1362293433!26714892!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32689 invoked from network); 3 Mar 2013 06:50:33 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 06:50:33 -0000 Received: by mail-wg0-f48.google.com with SMTP id 16so3416355wgi.3 for ; Sat, 02 Mar 2013 22:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=80qih1kw+040X22WXqnMJu6/XO8Adwp6Qk5TV8NiSB4=; b=YFk8e/0nXoQgvSSt9JjVMZ1Mkk+5NW3Lf81D6DfoP+3LNjhoS7p5wYRzQzH2Wa7f5a DvWYhUtmA7m6tGTHjwB7m00sls+llVON2KM1C0d0GW9xvUzu6XG+Athhinu06OFEToMx lcNwCwsCunr+9griGuWkmguMe2xEU/drcwzLk0uzcWSMegIDD3mLWv/yumAO1U0Rh+4A bLkszu+csmZa47rvzrKu78NmtIfJYCFSQypYccZerGff4Jt9q4XJeyonffadAhpdHsHC J4hj00uBJjbJO1RgYU4uC8D4mN9Cqv96SFApxxfAeAGi+2NL5XqfyFKpeC251qg2ftIL 9KPw== MIME-Version: 1.0 X-Received: by 10.194.123.130 with SMTP id ma2mr17520759wjb.46.1362293433713; Sat, 02 Mar 2013 22:50:33 -0800 (PST) Received: by 10.194.78.129 with HTTP; Sat, 2 Mar 2013 22:50:33 -0800 (PST) Date: Sun, 3 Mar 2013 12:20:33 +0530 Message-ID: From: Ganesh Hariharan To: xen-users@lists.xen.org Subject: [Xen-users] Mismatch between Xen and DOM0 kernel X-BeenThere: xen-users@lists.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="===============6929986533305986409==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6929986533305986409== Content-Type: multipart/alternative; boundary=089e012287de324b4804d6ffa87b --089e012287de324b4804d6ffa87b Content-Type: text/plain; charset=ISO-8859-1 Hi All, I installed 4.2.1 for x86 on Ubuntu 12.10 desktop and did the essential grub configs after install now while rebooting, I get the Mismatch message, and it keeps rebooting please guide me to fix this Regards, GHH --089e012287de324b4804d6ffa87b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0
I installed 4.2.1 for= x86 on Ubuntu 12.10 desktop and did the essential grub configs after insta= ll
=A0
now while rebooting, I get the Mismatch message,= and it keeps rebooting
=A0
please guide me to fix this
=A0
Rega= rds,
GHH
--089e012287de324b4804d6ffa87b-- --===============6929986533305986409== 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 --===============6929986533305986409==-- From xen-users-bounces@lists.xen.org Sun Mar 03 06:52:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 06:52:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UC2kn-0006dP-JF; Sun, 03 Mar 2013 06:50:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UC2kl-0006dK-DC for xen-users@lists.xen.org; Sun, 03 Mar 2013 06:50:35 +0000 Received: from [85.158.143.99:49846] by server-3.bemta-4.messagelabs.com id 5F/81-02186-AB2F2315; Sun, 03 Mar 2013 06:50:34 +0000 X-Env-Sender: ghariharan@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1362293433!26714892!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32689 invoked from network); 3 Mar 2013 06:50:33 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 06:50:33 -0000 Received: by mail-wg0-f48.google.com with SMTP id 16so3416355wgi.3 for ; Sat, 02 Mar 2013 22:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=80qih1kw+040X22WXqnMJu6/XO8Adwp6Qk5TV8NiSB4=; b=YFk8e/0nXoQgvSSt9JjVMZ1Mkk+5NW3Lf81D6DfoP+3LNjhoS7p5wYRzQzH2Wa7f5a DvWYhUtmA7m6tGTHjwB7m00sls+llVON2KM1C0d0GW9xvUzu6XG+Athhinu06OFEToMx lcNwCwsCunr+9griGuWkmguMe2xEU/drcwzLk0uzcWSMegIDD3mLWv/yumAO1U0Rh+4A bLkszu+csmZa47rvzrKu78NmtIfJYCFSQypYccZerGff4Jt9q4XJeyonffadAhpdHsHC J4hj00uBJjbJO1RgYU4uC8D4mN9Cqv96SFApxxfAeAGi+2NL5XqfyFKpeC251qg2ftIL 9KPw== MIME-Version: 1.0 X-Received: by 10.194.123.130 with SMTP id ma2mr17520759wjb.46.1362293433713; Sat, 02 Mar 2013 22:50:33 -0800 (PST) Received: by 10.194.78.129 with HTTP; Sat, 2 Mar 2013 22:50:33 -0800 (PST) Date: Sun, 3 Mar 2013 12:20:33 +0530 Message-ID: From: Ganesh Hariharan To: xen-users@lists.xen.org Subject: [Xen-users] Mismatch between Xen and DOM0 kernel X-BeenThere: xen-users@lists.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="===============6929986533305986409==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6929986533305986409== Content-Type: multipart/alternative; boundary=089e012287de324b4804d6ffa87b --089e012287de324b4804d6ffa87b Content-Type: text/plain; charset=ISO-8859-1 Hi All, I installed 4.2.1 for x86 on Ubuntu 12.10 desktop and did the essential grub configs after install now while rebooting, I get the Mismatch message, and it keeps rebooting please guide me to fix this Regards, GHH --089e012287de324b4804d6ffa87b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0
I installed 4.2.1 for= x86 on Ubuntu 12.10 desktop and did the essential grub configs after insta= ll
=A0
now while rebooting, I get the Mismatch message,= and it keeps rebooting
=A0
please guide me to fix this
=A0
Rega= rds,
GHH
--089e012287de324b4804d6ffa87b-- --===============6929986533305986409== 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 --===============6929986533305986409==-- From xen-users-bounces@lists.xen.org Sun Mar 03 07:47:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 07:47: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 1UC3ck-0007r6-Hk; Sun, 03 Mar 2013 07:46:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UC3cj-0007r1-0u for xen-users@lists.xen.org; Sun, 03 Mar 2013 07:46:21 +0000 Received: from [85.158.139.83:17780] by server-11.bemta-5.messagelabs.com id 9A/02-27486-CCFF2315; Sun, 03 Mar 2013 07:46:20 +0000 X-Env-Sender: povder@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1362296777!22690123!1 X-Originating-IP: [209.85.128.179] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16995 invoked from network); 3 Mar 2013 07:46:18 -0000 Received: from mail-ve0-f179.google.com (HELO mail-ve0-f179.google.com) (209.85.128.179) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 07:46:18 -0000 Received: by mail-ve0-f179.google.com with SMTP id da11so3879949veb.24 for ; Sat, 02 Mar 2013 23:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WWDfavKAORXYY64MuYwLvBY/XyZ6Fm8Rp56XlInvYRc=; b=UzxLz/JuBttu+UJvtxJcCxyy0gvYXQ61a36maH/wkGTqXUiCP4wO6SxYN4yFlyPBCA ATqd+ABDf4LvXbY4JAeBz9BmDnKPNjAMo10k8A90o0zLfEUhgnmhZfVHqcy0FuxwGSZT ch+UOuxaLPcqKIxqxV3gESg3yKzqbT4NeK8dMxjelXRky+JnQ8huVBW++fuyr9+01YUm CsBtNvUYTnl7gEqSHb2WHLW/hVhImWcbftHvauwa+sZemSj1bEkEd65KVA6hov1zh5WW PRBdKzpJjoIDxPFjiDOcJbW/KGdpxcTM3fCEiYGnNW67r1TgTzF+7pZeHP1ySsb7Uu86 ZqKg== X-Received: by 10.52.98.5 with SMTP id ee5mr5449971vdb.102.1362296776961; Sat, 02 Mar 2013 23:46:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.203.106 with HTTP; Sat, 2 Mar 2013 23:45:56 -0800 (PST) In-Reply-To: <201303021602.r22G2nTB013064@wind.enjellic.com> References: <201303021602.r22G2nTB013064@wind.enjellic.com> From: povder Date: Sun, 3 Mar 2013 08:45:56 +0100 Message-ID: To: greg@enjellic.com Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA passthrough radeon 4850 as primary card X-BeenThere: xen-users@lists.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 2013/3/2 Dr. Greg Wettstein : > > We have run thousands of sessions of primary VGA pass-through using > ATI cards. We currently use stock Windows 7 with no additional > drivers. > > Patches are needed to QEMU in order to support primary pass-through. > The following URL references patches which will work for the 4.1.x and > 4.2.x releases: > > ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.ati-passthrough.patch > > ftp://ftp.enjellic.com/pub/xen/xen-4.2.0.ati-passthrough.patch > > The patches can be applied and the updated qemu-dm can be dropped into > place, canonically in the /usr/lib/xen/bin directory. > > The following is a sample configuration: > --------------------------------------------------------------------------- > builder='hvm' > memory = 3072 > name = "Windows" > viridian = 1 > vif = [ 'type=ioemu, bridge=bridge0, model=e1000' ] > acpi = 1 > apic = 1 > disk = [ 'phy:/dev/localvg1/winsnap,hda,w' ] > boot="c" > sdl=0 > vnc=0 > soundhw='ac97' > stdvga=1 > gfx_passthru=1 > pci=[ '01:00.0', '00:1a.0' ] > --------------------------------------------------------------------------- > > The BDF definitions for the pci pass-through directive are for the ATI > card and the USB host controller which drives the keyboard and mouse. > > The trick to getting this right is to automate the detach and > re-attachment of the PCI devices to dom0. The following script > provides a framework for doing this: > > ftp://ftp.enjellic.com/pub/xen/run-passthrough > > It should be salted according to the flavor of your particular > installation. Access to the vbetool utility, which most distribution > include to support suspend/resume, is desirable in order to run the > BIOS-post initialization functions so the graphics card works properly > upon return of control to dom0. > > You will want to have an SSH session open from an alternate location > to whatever platform you are testing this all on. It will be the only > way to control the system if something goes awry during the > setup/teardown of the pass-through session. > > Hope the above is helpful. > Thank you for this valuable information. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 03 07:47:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 07:47: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 1UC3ck-0007r6-Hk; Sun, 03 Mar 2013 07:46:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UC3cj-0007r1-0u for xen-users@lists.xen.org; Sun, 03 Mar 2013 07:46:21 +0000 Received: from [85.158.139.83:17780] by server-11.bemta-5.messagelabs.com id 9A/02-27486-CCFF2315; Sun, 03 Mar 2013 07:46:20 +0000 X-Env-Sender: povder@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1362296777!22690123!1 X-Originating-IP: [209.85.128.179] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16995 invoked from network); 3 Mar 2013 07:46:18 -0000 Received: from mail-ve0-f179.google.com (HELO mail-ve0-f179.google.com) (209.85.128.179) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 07:46:18 -0000 Received: by mail-ve0-f179.google.com with SMTP id da11so3879949veb.24 for ; Sat, 02 Mar 2013 23:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WWDfavKAORXYY64MuYwLvBY/XyZ6Fm8Rp56XlInvYRc=; b=UzxLz/JuBttu+UJvtxJcCxyy0gvYXQ61a36maH/wkGTqXUiCP4wO6SxYN4yFlyPBCA ATqd+ABDf4LvXbY4JAeBz9BmDnKPNjAMo10k8A90o0zLfEUhgnmhZfVHqcy0FuxwGSZT ch+UOuxaLPcqKIxqxV3gESg3yKzqbT4NeK8dMxjelXRky+JnQ8huVBW++fuyr9+01YUm CsBtNvUYTnl7gEqSHb2WHLW/hVhImWcbftHvauwa+sZemSj1bEkEd65KVA6hov1zh5WW PRBdKzpJjoIDxPFjiDOcJbW/KGdpxcTM3fCEiYGnNW67r1TgTzF+7pZeHP1ySsb7Uu86 ZqKg== X-Received: by 10.52.98.5 with SMTP id ee5mr5449971vdb.102.1362296776961; Sat, 02 Mar 2013 23:46:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.203.106 with HTTP; Sat, 2 Mar 2013 23:45:56 -0800 (PST) In-Reply-To: <201303021602.r22G2nTB013064@wind.enjellic.com> References: <201303021602.r22G2nTB013064@wind.enjellic.com> From: povder Date: Sun, 3 Mar 2013 08:45:56 +0100 Message-ID: To: greg@enjellic.com Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA passthrough radeon 4850 as primary card X-BeenThere: xen-users@lists.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 2013/3/2 Dr. Greg Wettstein : > > We have run thousands of sessions of primary VGA pass-through using > ATI cards. We currently use stock Windows 7 with no additional > drivers. > > Patches are needed to QEMU in order to support primary pass-through. > The following URL references patches which will work for the 4.1.x and > 4.2.x releases: > > ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.ati-passthrough.patch > > ftp://ftp.enjellic.com/pub/xen/xen-4.2.0.ati-passthrough.patch > > The patches can be applied and the updated qemu-dm can be dropped into > place, canonically in the /usr/lib/xen/bin directory. > > The following is a sample configuration: > --------------------------------------------------------------------------- > builder='hvm' > memory = 3072 > name = "Windows" > viridian = 1 > vif = [ 'type=ioemu, bridge=bridge0, model=e1000' ] > acpi = 1 > apic = 1 > disk = [ 'phy:/dev/localvg1/winsnap,hda,w' ] > boot="c" > sdl=0 > vnc=0 > soundhw='ac97' > stdvga=1 > gfx_passthru=1 > pci=[ '01:00.0', '00:1a.0' ] > --------------------------------------------------------------------------- > > The BDF definitions for the pci pass-through directive are for the ATI > card and the USB host controller which drives the keyboard and mouse. > > The trick to getting this right is to automate the detach and > re-attachment of the PCI devices to dom0. The following script > provides a framework for doing this: > > ftp://ftp.enjellic.com/pub/xen/run-passthrough > > It should be salted according to the flavor of your particular > installation. Access to the vbetool utility, which most distribution > include to support suspend/resume, is desirable in order to run the > BIOS-post initialization functions so the graphics card works properly > upon return of control to dom0. > > You will want to have an SSH session open from an alternate location > to whatever platform you are testing this all on. It will be the only > way to control the system if something goes awry during the > setup/teardown of the pass-through session. > > Hope the above is helpful. > Thank you for this valuable information. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 03 08:55:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 08:55: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 1UC4fw-0000xZ-Vv; Sun, 03 Mar 2013 08:53:44 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UC4fv-0000xS-1G for xen-users@lists.xen.org; Sun, 03 Mar 2013 08:53:43 +0000 Received: from [85.158.137.99:43645] by server-4.bemta-3.messagelabs.com id 7F/CE-21470-69F03315; Sun, 03 Mar 2013 08:53:42 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1362300820!17872503!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDIxNjI=\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31031 invoked from network); 3 Mar 2013 08:53:41 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 08:53:41 -0000 X-IronPort-AV: E=Sophos;i="4.84,772,1355097600"; d="scan'208";a="10793751" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 03 Mar 2013 08:53:39 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Sun, 3 Mar 2013 03:53:39 -0500 Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UC4fq-0004N9-Pb; Sun, 03 Mar 2013 08:53:39 +0000 Message-ID: <1362300660.4198.61.camel@hastur.hellion.org.uk> From: Ian Campbell To: Ganesh Hariharan Date: Sun, 3 Mar 2013 08:51:00 +0000 In-Reply-To: References: X-Mailer: Evolution 3.4.4-2 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Mismatch between Xen and DOM0 kernel X-BeenThere: xen-users@lists.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, 2013-03-03 at 06:50 +0000, Ganesh Hariharan wrote: > Hi All, > > I installed 4.2.1 for x86 on Ubuntu 12.10 desktop and did the > essential grub configs after install Installed from packages or from source? What actual changes did you make to your grub configuration? Please describe what you've done rather than just hinting at it -- this will help us to help you. > now while rebooting, I get the Mismatch message, and it keeps > rebooting What is "the Mismatch message"? Please add "noreboot" to your hypervisor command line and either transcribe the exact errors or use a serial console http://wiki.xen.org/wiki/XenSerialConsole. Or you could take a digital photograph. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 03 08:55:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 08:55: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 1UC4fw-0000xZ-Vv; Sun, 03 Mar 2013 08:53:44 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UC4fv-0000xS-1G for xen-users@lists.xen.org; Sun, 03 Mar 2013 08:53:43 +0000 Received: from [85.158.137.99:43645] by server-4.bemta-3.messagelabs.com id 7F/CE-21470-69F03315; Sun, 03 Mar 2013 08:53:42 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1362300820!17872503!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDIxNjI=\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31031 invoked from network); 3 Mar 2013 08:53:41 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 08:53:41 -0000 X-IronPort-AV: E=Sophos;i="4.84,772,1355097600"; d="scan'208";a="10793751" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 03 Mar 2013 08:53:39 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Sun, 3 Mar 2013 03:53:39 -0500 Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UC4fq-0004N9-Pb; Sun, 03 Mar 2013 08:53:39 +0000 Message-ID: <1362300660.4198.61.camel@hastur.hellion.org.uk> From: Ian Campbell To: Ganesh Hariharan Date: Sun, 3 Mar 2013 08:51:00 +0000 In-Reply-To: References: X-Mailer: Evolution 3.4.4-2 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Mismatch between Xen and DOM0 kernel X-BeenThere: xen-users@lists.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, 2013-03-03 at 06:50 +0000, Ganesh Hariharan wrote: > Hi All, > > I installed 4.2.1 for x86 on Ubuntu 12.10 desktop and did the > essential grub configs after install Installed from packages or from source? What actual changes did you make to your grub configuration? Please describe what you've done rather than just hinting at it -- this will help us to help you. > now while rebooting, I get the Mismatch message, and it keeps > rebooting What is "the Mismatch message"? Please add "noreboot" to your hypervisor command line and either transcribe the exact errors or use a serial console http://wiki.xen.org/wiki/XenSerialConsole. Or you could take a digital photograph. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 03 20:07:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 20:07: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 1UCFAA-0001pO-BH; Sun, 03 Mar 2013 20:05:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCFA8-0001pJ-9O for xen-users@lists.xen.org; Sun, 03 Mar 2013 20:05:36 +0000 Received: from [85.158.139.83:45760] by server-7.bemta-5.messagelabs.com id 57/54-12441-F0DA3315; Sun, 03 Mar 2013 20:05:35 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1362341134!29937061!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7122 invoked from network); 3 Mar 2013 20:05:34 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 20:05:34 -0000 Received: by mail-wi0-f170.google.com with SMTP id hm11so1332042wib.3 for ; Sun, 03 Mar 2013 12:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=tEe+h1ZXKTlMstJw6rXYs7ecdJzEyAftH6Hl3qgLddo=; b=fF1gaMj/qIqPLMmT3D7IwW5Jq0GFescr7kqx6tEF31xbh8LyR2K3cI20/jEFnuy5tB Q9WezuDmS8Vpi+uzobG15awYX+Q7MkeLRQ7lC5wc2NN5kK6KRtZTcEg4ulNgedoRXLnz wY4VjKdfcWy8IWyEspYtk0V4cVTv23b/rFbBtzi2p23O6s6ZKKcQfw3TLdkTB79xfd4d c1x5HfGsdctI6xywVuupzMgs1aW30M3ISLjR+ej/iRDXy9TmFMwFUSm/02YivkEFMTzf 7f/hgUeZxliv0jGJaNEEOywT9Nwxt+tZ6fsv3alsWxCNoVaW6CTZoBn4zvRCO4poINGj X/nA== X-Received: by 10.194.20.40 with SMTP id k8mr28041856wje.16.1362341134347; Sun, 03 Mar 2013 12:05:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Sun, 3 Mar 2013 12:05:14 -0800 (PST) From: Matthias Date: Sun, 3 Mar 2013 21:05:14 +0100 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] Debugging Xen Freezes / Kdump not working X-BeenThere: xen-users@lists.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 Because I have some freezes because of vga passthrough lately, I tried to debug this but unfortunatly didn't really found a working way: 1) Watching screen output for kernel messages That obviously didn't work because i passed all my vgas to domUs and therefor didn't see anything from dom0 / kernel. 2) Serial console In general a good idea, but i don't have any serial connectors on my mainboard so this is not an option either. 3) Kdump I tried setting up kexec/kdump but a crashkernel part never showes up in /proc/iomem so kexec/kdump do not work. There is a line in xl dmesg saying: (XEN) Kdump: 128MB (131072kB) at 0x1000000 but despite that i don't see any indication that crashkernel is working in any way.. I read somewhere that that kdump doesn't work with newer pvops dom0 kernels at all, and i have read somewhere else that this is only an issue that the crashkernel space doesn't show up in /proc/iomem but this the point kexec looks for.. So what I would like to know is a) if anyone got kdump working on a newer kernel with a newer xen and maybe what i am missing in my configuration b) if there is an other working way of debugging xen freezes or similar My system is a debian wheezy with a 3.7.4 vanilla kernel and latest xen-unstable. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 03 20:07:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 20:07: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 1UCFAA-0001pO-BH; Sun, 03 Mar 2013 20:05:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCFA8-0001pJ-9O for xen-users@lists.xen.org; Sun, 03 Mar 2013 20:05:36 +0000 Received: from [85.158.139.83:45760] by server-7.bemta-5.messagelabs.com id 57/54-12441-F0DA3315; Sun, 03 Mar 2013 20:05:35 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1362341134!29937061!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7122 invoked from network); 3 Mar 2013 20:05:34 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 20:05:34 -0000 Received: by mail-wi0-f170.google.com with SMTP id hm11so1332042wib.3 for ; Sun, 03 Mar 2013 12:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=tEe+h1ZXKTlMstJw6rXYs7ecdJzEyAftH6Hl3qgLddo=; b=fF1gaMj/qIqPLMmT3D7IwW5Jq0GFescr7kqx6tEF31xbh8LyR2K3cI20/jEFnuy5tB Q9WezuDmS8Vpi+uzobG15awYX+Q7MkeLRQ7lC5wc2NN5kK6KRtZTcEg4ulNgedoRXLnz wY4VjKdfcWy8IWyEspYtk0V4cVTv23b/rFbBtzi2p23O6s6ZKKcQfw3TLdkTB79xfd4d c1x5HfGsdctI6xywVuupzMgs1aW30M3ISLjR+ej/iRDXy9TmFMwFUSm/02YivkEFMTzf 7f/hgUeZxliv0jGJaNEEOywT9Nwxt+tZ6fsv3alsWxCNoVaW6CTZoBn4zvRCO4poINGj X/nA== X-Received: by 10.194.20.40 with SMTP id k8mr28041856wje.16.1362341134347; Sun, 03 Mar 2013 12:05:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Sun, 3 Mar 2013 12:05:14 -0800 (PST) From: Matthias Date: Sun, 3 Mar 2013 21:05:14 +0100 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] Debugging Xen Freezes / Kdump not working X-BeenThere: xen-users@lists.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 Because I have some freezes because of vga passthrough lately, I tried to debug this but unfortunatly didn't really found a working way: 1) Watching screen output for kernel messages That obviously didn't work because i passed all my vgas to domUs and therefor didn't see anything from dom0 / kernel. 2) Serial console In general a good idea, but i don't have any serial connectors on my mainboard so this is not an option either. 3) Kdump I tried setting up kexec/kdump but a crashkernel part never showes up in /proc/iomem so kexec/kdump do not work. There is a line in xl dmesg saying: (XEN) Kdump: 128MB (131072kB) at 0x1000000 but despite that i don't see any indication that crashkernel is working in any way.. I read somewhere that that kdump doesn't work with newer pvops dom0 kernels at all, and i have read somewhere else that this is only an issue that the crashkernel space doesn't show up in /proc/iomem but this the point kexec looks for.. So what I would like to know is a) if anyone got kdump working on a newer kernel with a newer xen and maybe what i am missing in my configuration b) if there is an other working way of debugging xen freezes or similar My system is a debian wheezy with a 3.7.4 vanilla kernel and latest xen-unstable. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 03 20:12:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 20:12: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 1UCFFD-00020B-9u; Sun, 03 Mar 2013 20:10:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCFFC-000203-0d for xen-users@lists.xen.org; Sun, 03 Mar 2013 20:10:50 +0000 Received: from [85.158.139.83:59565] by server-8.bemta-5.messagelabs.com id 4C/41-05790-94EA3315; Sun, 03 Mar 2013 20:10:49 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1362341448!24711270!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14626 invoked from network); 3 Mar 2013 20:10:48 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 20:10:48 -0000 Received: by mail-wi0-f173.google.com with SMTP id hq4so1185066wib.12 for ; Sun, 03 Mar 2013 12:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=/kSh2B1ChhJ9A4ZHYAqjEzGgtO8vkLwbzWNtlcTOAvw=; b=vH0VdVk4CwE3MqlmFBZ1uwjbmnbOBEeAqs0W0qiwIhLRrdNGGMVWzY3A2FXq7MZ9jI WRIYwKuOIpi8Buc2nFBp8n2ujwwoGiCDD/RqyvLfXs2d/jjKBT3E5r6JZ8AvymSEuf2W w+prPmH0JoeC/cFwXSr7dAfEAIRd2Yru686Ql4WZPnrNu2NP8AfTIMgllMY+I5sjEyBK BR3tFGbdb1o5L4BH1dq5vf4tFGKfdtYbd2YicYwIMSk6VR6w07tXzlQADXjVwScgL8fR qHbfb5qI2pWGbBdYMoKY9RLd5Z/VIXxoSlAqN12eqw0U2+f9U1WLmKCJucQKIc8xr+e4 4jxg== X-Received: by 10.180.84.162 with SMTP id a2mr7698566wiz.14.1362341448452; Sun, 03 Mar 2013 12:10:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Sun, 3 Mar 2013 12:10:28 -0800 (PST) From: Matthias Date: Sun, 3 Mar 2013 21:10:28 +0100 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] dual vga passthrough issue in xen unstable X-BeenThere: xen-users@lists.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 have the following problem: I have two vga cards, an AMD HD5450 and a HD5700.. When I hide both via pciback.hide at boot time, start a win7 domU passing through one of the cards, vga passthrough works fine, but when i then shutdown the win7 domU, the whole dom0 hangs and i have to reset the whole server. When I do the same with only one vga hidden and one for the dom0, it works without problems. Logs don't show something suspiciously and i don't know how i can debug this, so unfortunatly i'm in a bit of a dead end here. Does anyone have an idea what can cause this or how i can resolve this? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 03 20:12:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 03 Mar 2013 20:12: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 1UCFFD-00020B-9u; Sun, 03 Mar 2013 20:10:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCFFC-000203-0d for xen-users@lists.xen.org; Sun, 03 Mar 2013 20:10:50 +0000 Received: from [85.158.139.83:59565] by server-8.bemta-5.messagelabs.com id 4C/41-05790-94EA3315; Sun, 03 Mar 2013 20:10:49 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1362341448!24711270!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14626 invoked from network); 3 Mar 2013 20:10:48 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 3 Mar 2013 20:10:48 -0000 Received: by mail-wi0-f173.google.com with SMTP id hq4so1185066wib.12 for ; Sun, 03 Mar 2013 12:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=/kSh2B1ChhJ9A4ZHYAqjEzGgtO8vkLwbzWNtlcTOAvw=; b=vH0VdVk4CwE3MqlmFBZ1uwjbmnbOBEeAqs0W0qiwIhLRrdNGGMVWzY3A2FXq7MZ9jI WRIYwKuOIpi8Buc2nFBp8n2ujwwoGiCDD/RqyvLfXs2d/jjKBT3E5r6JZ8AvymSEuf2W w+prPmH0JoeC/cFwXSr7dAfEAIRd2Yru686Ql4WZPnrNu2NP8AfTIMgllMY+I5sjEyBK BR3tFGbdb1o5L4BH1dq5vf4tFGKfdtYbd2YicYwIMSk6VR6w07tXzlQADXjVwScgL8fR qHbfb5qI2pWGbBdYMoKY9RLd5Z/VIXxoSlAqN12eqw0U2+f9U1WLmKCJucQKIc8xr+e4 4jxg== X-Received: by 10.180.84.162 with SMTP id a2mr7698566wiz.14.1362341448452; Sun, 03 Mar 2013 12:10:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Sun, 3 Mar 2013 12:10:28 -0800 (PST) From: Matthias Date: Sun, 3 Mar 2013 21:10:28 +0100 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] dual vga passthrough issue in xen unstable X-BeenThere: xen-users@lists.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 have the following problem: I have two vga cards, an AMD HD5450 and a HD5700.. When I hide both via pciback.hide at boot time, start a win7 domU passing through one of the cards, vga passthrough works fine, but when i then shutdown the win7 domU, the whole dom0 hangs and i have to reset the whole server. When I do the same with only one vga hidden and one for the dom0, it works without problems. Logs don't show something suspiciously and i don't know how i can debug this, so unfortunatly i'm in a bit of a dead end here. Does anyone have an idea what can cause this or how i can resolve this? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 05:35:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 05:35: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 1UCO2S-0004bz-Cn; Mon, 04 Mar 2013 05:34:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCO2Q-0004bk-6y; Mon, 04 Mar 2013 05:34:14 +0000 Received: from [85.158.139.83:36887] by server-15.bemta-5.messagelabs.com id 57/AD-22815-55234315; Mon, 04 Mar 2013 05:34:13 +0000 X-Env-Sender: mailinglists.tech@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1362375251!22773637!1 X-Originating-IP: [209.85.215.172] X-SpamReason: No, hits=0.2 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_ILLEGAL_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23102 invoked from network); 4 Mar 2013 05:34:11 -0000 Received: from mail-ea0-f172.google.com (HELO mail-ea0-f172.google.com) (209.85.215.172) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 05:34:11 -0000 Received: by mail-ea0-f172.google.com with SMTP id f13so734634eaa.3 for ; Sun, 03 Mar 2013 21:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Sl0zhMZwEKmA+TR/hiE8NdDpa16Dx//2oieLTwxVCig=; b=YqHYrjIB+U2UPiH+yvnBLZl0ozlnAVjLvtoXWgMJqIhkJIm7xefgV+SQ2DKayRZfoX 5A2xpoXHY0hy+FR4J3ke/rz4PpdYXOClZX98iawjvTN5occ9qwi1Gwj6PrsET5IC75/S TJoJV6deJtm3Xak4UMocW8R2kg44FTAwQywiYnBflUtGcc+JwUATzvz72qBoyAfU5zHR N+c9T2eElfNtF2YcG/FnPM/0pC+mstdqAqW0uKxU2PIZXd5iR5lWhs4ZmDmkhUDtHT9P L8BA+/kcCxZyLYc1LNpR19UVMqVmZlwF0lAG5HI0tKNDGfTryUaiEoCGZz5d6nEjKbUl Xr1w== X-Received: by 10.14.179.194 with SMTP id h42mr22056843eem.46.1362375251217; Sun, 03 Mar 2013 21:34:11 -0800 (PST) Received: from [127.0.0.1] (ashlynn.lippux.de. [5.9.218.242]) by mx.google.com with ESMTPS id a1sm30153263eep.2.2013.03.03.21.34.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 21:34:10 -0800 (PST) Message-ID: <5134324F.6060300@gmail.com> Date: Mon, 04 Mar 2013 06:34:07 +0100 From: tech mailinglists User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users , "xen-devel@lists.xen.org" Subject: [Xen-users] Actual method to compile Xen with vtpm on Linux and NetBSD X-BeenThere: xen-users@lists.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, I have a question about the implementation of vTPM in Xen. I want to setup vTPM in the next time on my Xen infrastructure and so I read a little bit about it. I actually have compiled Xen with the configure option --enable-vtpm. I read that this option is more or less "deprecated" and I was never able to compile Xen with vTPM on NetBSD because of the fact that libgmp seems to be not available on NetBSD. So I have two question about this: Is --enable-vtpm still the way to go in Xen 4.2.1 or is there another method to compile Xen with vTPM (I read that a reimplementation is work in progress) And is it possible to compile Xen with vTPM on NetBSD with the old or new way? I found just a little bit about this but no definitiv answer. Best Regards _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 05:35:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 05:35: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 1UCO2S-0004bz-Cn; Mon, 04 Mar 2013 05:34:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCO2Q-0004bk-6y; Mon, 04 Mar 2013 05:34:14 +0000 Received: from [85.158.139.83:36887] by server-15.bemta-5.messagelabs.com id 57/AD-22815-55234315; Mon, 04 Mar 2013 05:34:13 +0000 X-Env-Sender: mailinglists.tech@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1362375251!22773637!1 X-Originating-IP: [209.85.215.172] X-SpamReason: No, hits=0.2 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_ILLEGAL_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23102 invoked from network); 4 Mar 2013 05:34:11 -0000 Received: from mail-ea0-f172.google.com (HELO mail-ea0-f172.google.com) (209.85.215.172) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 05:34:11 -0000 Received: by mail-ea0-f172.google.com with SMTP id f13so734634eaa.3 for ; Sun, 03 Mar 2013 21:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Sl0zhMZwEKmA+TR/hiE8NdDpa16Dx//2oieLTwxVCig=; b=YqHYrjIB+U2UPiH+yvnBLZl0ozlnAVjLvtoXWgMJqIhkJIm7xefgV+SQ2DKayRZfoX 5A2xpoXHY0hy+FR4J3ke/rz4PpdYXOClZX98iawjvTN5occ9qwi1Gwj6PrsET5IC75/S TJoJV6deJtm3Xak4UMocW8R2kg44FTAwQywiYnBflUtGcc+JwUATzvz72qBoyAfU5zHR N+c9T2eElfNtF2YcG/FnPM/0pC+mstdqAqW0uKxU2PIZXd5iR5lWhs4ZmDmkhUDtHT9P L8BA+/kcCxZyLYc1LNpR19UVMqVmZlwF0lAG5HI0tKNDGfTryUaiEoCGZz5d6nEjKbUl Xr1w== X-Received: by 10.14.179.194 with SMTP id h42mr22056843eem.46.1362375251217; Sun, 03 Mar 2013 21:34:11 -0800 (PST) Received: from [127.0.0.1] (ashlynn.lippux.de. [5.9.218.242]) by mx.google.com with ESMTPS id a1sm30153263eep.2.2013.03.03.21.34.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 21:34:10 -0800 (PST) Message-ID: <5134324F.6060300@gmail.com> Date: Mon, 04 Mar 2013 06:34:07 +0100 From: tech mailinglists User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users , "xen-devel@lists.xen.org" Subject: [Xen-users] Actual method to compile Xen with vtpm on Linux and NetBSD X-BeenThere: xen-users@lists.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, I have a question about the implementation of vTPM in Xen. I want to setup vTPM in the next time on my Xen infrastructure and so I read a little bit about it. I actually have compiled Xen with the configure option --enable-vtpm. I read that this option is more or less "deprecated" and I was never able to compile Xen with vTPM on NetBSD because of the fact that libgmp seems to be not available on NetBSD. So I have two question about this: Is --enable-vtpm still the way to go in Xen 4.2.1 or is there another method to compile Xen with vTPM (I read that a reimplementation is work in progress) And is it possible to compile Xen with vTPM on NetBSD with the old or new way? I found just a little bit about this but no definitiv answer. Best Regards _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 11:20:38 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 11:20: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 1UCTQW-0004FK-2v; Mon, 04 Mar 2013 11:19:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCTQU-0004F7-Db for xen-users@lists.xen.org; Mon, 04 Mar 2013 11:19:26 +0000 Received: from [85.158.139.211:43720] by server-10.bemta-5.messagelabs.com id 67/6C-23714-D3384315; Mon, 04 Mar 2013 11:19:25 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1362395940!17751578!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6193 invoked from network); 4 Mar 2013 11:19:00 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 11:19:00 -0000 Received: by mail-wi0-f170.google.com with SMTP id hm11so2007157wib.1 for ; Mon, 04 Mar 2013 03:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=E6IVinMhNQ5iStOdxROddJDGFZVstoSjERcYYwnhjbw=; b=YgMGf/Uu8zBKksJ66WuRx+4HdvT9HVeOBp1AQrIcC5lsjnTpG7uTZ6eutLOIzFj/H+ o+Q+HoKZ+mpcHI2dasL2d7CDNc2B3EHebP3paraUWha+80ZHOYVq12SB6FJx7XzZIUN5 TUElFpO+zh5+fDzh5/LDjPFy5JTDIum4bsfE/N9qDafalrtshOXMZVBfZpG8Cvd9KuoU ygCXPyYcgD2nxx+QY+4W2l6o1Rig3YprjXqocYrWSdsHDUvxxRhA9u+GchrsAUE/n+GG vwJ1C1dnlUPDo++ubEsdA8DQ7889+G9/3JXFZQSlbTr0Pxa5DCA7/oneJcXIW1ED6ne7 l2WA== MIME-Version: 1.0 X-Received: by 10.194.63.240 with SMTP id j16mr30812311wjs.45.1362395940226; Mon, 04 Mar 2013 03:19:00 -0800 (PST) Received: by 10.216.236.13 with HTTP; Mon, 4 Mar 2013 03:19:00 -0800 (PST) Date: Mon, 4 Mar 2013 12:19:00 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: [Xen-users] Error: /usr/lib/xen/bin/xc_save 22 6 0 0 0 failed X-BeenThere: xen-users@lists.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="===============1529976139308666873==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1529976139308666873== Content-Type: multipart/alternative; boundary=047d7ba97b720f8e5b04d717863b --047d7ba97b720f8e5b04d717863b Content-Type: text/plain; charset=ISO-8859-1 Hi All, Does anybody have this problem when try to migrate DomU : Error: /usr/lib/xen/bin/xc_save 22 6 0 0 0 failed I use xen 4.2.2-pre compiled from sources and my machine is Ubuntu 12.04 Linux with kernel 3.2.0-29-generic. Its working perfectly, even remus with drbd support migration was running successfully before. However today after I kill the remus process with command pkill -USR1 remus The remus process was terminated but when I re-tried to run the remus again its failed even basic function like migration without live migration is failed with error above. I try to restart the xen service but its still had the problem. Cpuld any body have the clue? Regards, Agya --047d7ba97b720f8e5b04d717863b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

Does anybody have this problem when try to migra= te DomU :

Error: /usr/lib/xen/bin/xc_save 22 6 0 0= 0 failed

I use xen 4.2.2-pre compiled from source= s and my machine is Ubuntu 12.04=A0Linux with kernel 3.2.0-29-generic.
Its working perfectly, even remus with drbd support migration was runn= ing successfully before. However today after I kill the remus process with = command=A0

pkill -USR1 remus

The remus process was terminated but when I re-tried to run the remus = again its failed even basic function like migration without live migration = is failed with error above. I try to restart the xen service but its still = had the problem. Cpuld any body have the clue?=A0

Regards,

Agya
--047d7ba97b720f8e5b04d717863b-- --===============1529976139308666873== 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 --===============1529976139308666873==-- From xen-users-bounces@lists.xen.org Mon Mar 04 11:20:38 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 11:20: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 1UCTQW-0004FK-2v; Mon, 04 Mar 2013 11:19:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCTQU-0004F7-Db for xen-users@lists.xen.org; Mon, 04 Mar 2013 11:19:26 +0000 Received: from [85.158.139.211:43720] by server-10.bemta-5.messagelabs.com id 67/6C-23714-D3384315; Mon, 04 Mar 2013 11:19:25 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1362395940!17751578!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6193 invoked from network); 4 Mar 2013 11:19:00 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 11:19:00 -0000 Received: by mail-wi0-f170.google.com with SMTP id hm11so2007157wib.1 for ; Mon, 04 Mar 2013 03:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=E6IVinMhNQ5iStOdxROddJDGFZVstoSjERcYYwnhjbw=; b=YgMGf/Uu8zBKksJ66WuRx+4HdvT9HVeOBp1AQrIcC5lsjnTpG7uTZ6eutLOIzFj/H+ o+Q+HoKZ+mpcHI2dasL2d7CDNc2B3EHebP3paraUWha+80ZHOYVq12SB6FJx7XzZIUN5 TUElFpO+zh5+fDzh5/LDjPFy5JTDIum4bsfE/N9qDafalrtshOXMZVBfZpG8Cvd9KuoU ygCXPyYcgD2nxx+QY+4W2l6o1Rig3YprjXqocYrWSdsHDUvxxRhA9u+GchrsAUE/n+GG vwJ1C1dnlUPDo++ubEsdA8DQ7889+G9/3JXFZQSlbTr0Pxa5DCA7/oneJcXIW1ED6ne7 l2WA== MIME-Version: 1.0 X-Received: by 10.194.63.240 with SMTP id j16mr30812311wjs.45.1362395940226; Mon, 04 Mar 2013 03:19:00 -0800 (PST) Received: by 10.216.236.13 with HTTP; Mon, 4 Mar 2013 03:19:00 -0800 (PST) Date: Mon, 4 Mar 2013 12:19:00 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: [Xen-users] Error: /usr/lib/xen/bin/xc_save 22 6 0 0 0 failed X-BeenThere: xen-users@lists.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="===============1529976139308666873==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1529976139308666873== Content-Type: multipart/alternative; boundary=047d7ba97b720f8e5b04d717863b --047d7ba97b720f8e5b04d717863b Content-Type: text/plain; charset=ISO-8859-1 Hi All, Does anybody have this problem when try to migrate DomU : Error: /usr/lib/xen/bin/xc_save 22 6 0 0 0 failed I use xen 4.2.2-pre compiled from sources and my machine is Ubuntu 12.04 Linux with kernel 3.2.0-29-generic. Its working perfectly, even remus with drbd support migration was running successfully before. However today after I kill the remus process with command pkill -USR1 remus The remus process was terminated but when I re-tried to run the remus again its failed even basic function like migration without live migration is failed with error above. I try to restart the xen service but its still had the problem. Cpuld any body have the clue? Regards, Agya --047d7ba97b720f8e5b04d717863b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

Does anybody have this problem when try to migra= te DomU :

Error: /usr/lib/xen/bin/xc_save 22 6 0 0= 0 failed

I use xen 4.2.2-pre compiled from source= s and my machine is Ubuntu 12.04=A0Linux with kernel 3.2.0-29-generic.
Its working perfectly, even remus with drbd support migration was runn= ing successfully before. However today after I kill the remus process with = command=A0

pkill -USR1 remus

The remus process was terminated but when I re-tried to run the remus = again its failed even basic function like migration without live migration = is failed with error above. I try to restart the xen service but its still = had the problem. Cpuld any body have the clue?=A0

Regards,

Agya
--047d7ba97b720f8e5b04d717863b-- --===============1529976139308666873== 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 --===============1529976139308666873==-- From xen-users-bounces@lists.xen.org Mon Mar 04 11:28:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 11:28: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 1UCTYR-0004p0-No; Mon, 04 Mar 2013 11:27:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCTYQ-0004oq-8P for xen-users@lists.xensource.com; Mon, 04 Mar 2013 11:27:38 +0000 Received: from [85.158.137.99:35891] by server-2.bemta-3.messagelabs.com id 02/01-05208-92584315; Mon, 04 Mar 2013 11:27:37 +0000 X-Env-Sender: pkchouhan@gmail.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1362396448!18273413!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5109 invoked from network); 4 Mar 2013 11:27:30 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-11.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 4 Mar 2013 11:27:30 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UCTYF-0003gs-VI for xen-users@lists.xensource.com; Mon, 04 Mar 2013 03:27:27 -0800 Date: Mon, 4 Mar 2013 03:27:27 -0800 (PST) From: pkchouhan To: xen-users@lists.xensource.com Message-ID: <1362396447939-5714617.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-users] Peth0 missing X-BeenThere: xen-users@lists.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 installed Xen 4.1.2-2 ubuntu2.6 through Synaptic Manager on Ubuntu12.04. I followed the steps from https://help.ubuntu.com/community/Xen. However, I do not have a peth0, when I issue an "ifconfig -a". Only eth0, lo and xenbr0 are displayed. I have checked /etc/xen/xend-config.sxp and uncommented "(network-script network-bridge)". Still peth0 is not displayed. Thanks for your replies. -- View this message in context: http://xen.1045712.n5.nabble.com/Peth0-missing-tp5714617.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 Mon Mar 04 11:28:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 11:28: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 1UCTYR-0004p0-No; Mon, 04 Mar 2013 11:27:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCTYQ-0004oq-8P for xen-users@lists.xensource.com; Mon, 04 Mar 2013 11:27:38 +0000 Received: from [85.158.137.99:35891] by server-2.bemta-3.messagelabs.com id 02/01-05208-92584315; Mon, 04 Mar 2013 11:27:37 +0000 X-Env-Sender: pkchouhan@gmail.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1362396448!18273413!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5109 invoked from network); 4 Mar 2013 11:27:30 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-11.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 4 Mar 2013 11:27:30 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UCTYF-0003gs-VI for xen-users@lists.xensource.com; Mon, 04 Mar 2013 03:27:27 -0800 Date: Mon, 4 Mar 2013 03:27:27 -0800 (PST) From: pkchouhan To: xen-users@lists.xensource.com Message-ID: <1362396447939-5714617.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-users] Peth0 missing X-BeenThere: xen-users@lists.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 installed Xen 4.1.2-2 ubuntu2.6 through Synaptic Manager on Ubuntu12.04. I followed the steps from https://help.ubuntu.com/community/Xen. However, I do not have a peth0, when I issue an "ifconfig -a". Only eth0, lo and xenbr0 are displayed. I have checked /etc/xen/xend-config.sxp and uncommented "(network-script network-bridge)". Still peth0 is not displayed. Thanks for your replies. -- View this message in context: http://xen.1045712.n5.nabble.com/Peth0-missing-tp5714617.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 Mon Mar 04 13:11:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 13:11: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 1UCV9T-0000z7-8K; Mon, 04 Mar 2013 13:09:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCV9R-0000yz-FG for xen-users@lists.xen.org; Mon, 04 Mar 2013 13:09:57 +0000 Received: from [85.158.143.99:31153] by server-2.bemta-4.messagelabs.com id D0/22-12656-42D94315; Mon, 04 Mar 2013 13:09:56 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1362402595!22597254!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4844 invoked from network); 4 Mar 2013 13:09:56 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 13:09:56 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so4026531wgb.0 for ; Mon, 04 Mar 2013 05:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=gEJ1fdh+yh1i+g51QOhjp7vygdNklonaEPXfdMGlhus=; b=ZVb82ZoVu6MWyLfXF1i3wrRGGowlgZXSVemYsqUpgVEKRbr6uRwtP+ChBKyN+at4Ds M/xQDNPCb8vPQqLh0qZw6QxjNkoEv7LREn9+rDLzxwCILVt5NRP25DOwz8Rq4LLGZ/WH H+mhJYWWlXGcAU+fqAsEgRQksn0npQso5nQiYSRu4Ru51txn4HZecWfQvY7Is+9LV957 2E1Aza3BY0J7kX6lslIOrh+gdipNaMd2TL98/3IYaRUsSwOLkmayOqWeShkOFhK2II9Z LVTIkJqmE/UJ8YhP2oLlMRba0UNU8+p1zs8GqnbsyUbuUHPADCZKvCTC+a2itz6jdmWI DKWw== MIME-Version: 1.0 X-Received: by 10.194.63.240 with SMTP id j16mr31500079wjs.45.1362402595822; Mon, 04 Mar 2013 05:09:55 -0800 (PST) Received: by 10.216.236.13 with HTTP; Mon, 4 Mar 2013 05:09:55 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 14:09:55 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: Re: [Xen-users] Error: /usr/lib/xen/bin/xc_save 22 6 0 0 0 failed X-BeenThere: xen-users@lists.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="===============2487915524640684042==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2487915524640684042== Content-Type: multipart/alternative; boundary=047d7ba97b72c4ad1d04d71912d7 --047d7ba97b72c4ad1d04d71912d7 Content-Type: text/plain; charset=ISO-8859-1 Ok, solve it. It seem I have exact domu running on backup server. Regards, Agya On Mon, Mar 4, 2013 at 12:19 PM, agya naila wrote: > Hi All, > > Does anybody have this problem when try to migrate DomU : > > Error: /usr/lib/xen/bin/xc_save 22 6 0 0 0 failed > > I use xen 4.2.2-pre compiled from sources and my machine is Ubuntu > 12.04 Linux with kernel 3.2.0-29-generic. > Its working perfectly, even remus with drbd support migration was running > successfully before. However today after I kill the remus process with > command > > pkill -USR1 remus > > The remus process was terminated but when I re-tried to run the remus > again its failed even basic function like migration without live migration > is failed with error above. I try to restart the xen service but its still > had the problem. Cpuld any body have the clue? > > Regards, > > Agya > --047d7ba97b72c4ad1d04d71912d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, solve it. It seem I have exact domu running on backup server.

<= /div>
Regards,

Agya

On Mon, Mar 4, 2013 at 12:19 PM, agya naila <<= a href=3D"mailto:agya.naila@gmail.com" target=3D"_blank">agya.naila@gmail.c= om> wrote:
Hi All,

Does anybody have= this problem when try to migrate DomU :

Error: /u= sr/lib/xen/bin/xc_save 22 6 0 0 0 failed

I use xen 4.2.2-pre compiled from sources and my machin= e is Ubuntu 12.04=A0Linux with kernel 3.2.0-29-generic.
Its working perfectly, even remus with drbd support migration was runn= ing successfully before. However today after I kill the remus process with = command=A0

pkill -USR1 remus

The remus process was terminated but when I re-tried to run the remus = again its failed even basic function like migration without live migration = is failed with error above. I try to restart the xen service but its still = had the problem. Cpuld any body have the clue?=A0

Regards,

Agya

--047d7ba97b72c4ad1d04d71912d7-- --===============2487915524640684042== 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 --===============2487915524640684042==-- From xen-users-bounces@lists.xen.org Mon Mar 04 13:11:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 13:11: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 1UCV9T-0000z7-8K; Mon, 04 Mar 2013 13:09:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCV9R-0000yz-FG for xen-users@lists.xen.org; Mon, 04 Mar 2013 13:09:57 +0000 Received: from [85.158.143.99:31153] by server-2.bemta-4.messagelabs.com id D0/22-12656-42D94315; Mon, 04 Mar 2013 13:09:56 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1362402595!22597254!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4844 invoked from network); 4 Mar 2013 13:09:56 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 13:09:56 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so4026531wgb.0 for ; Mon, 04 Mar 2013 05:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=gEJ1fdh+yh1i+g51QOhjp7vygdNklonaEPXfdMGlhus=; b=ZVb82ZoVu6MWyLfXF1i3wrRGGowlgZXSVemYsqUpgVEKRbr6uRwtP+ChBKyN+at4Ds M/xQDNPCb8vPQqLh0qZw6QxjNkoEv7LREn9+rDLzxwCILVt5NRP25DOwz8Rq4LLGZ/WH H+mhJYWWlXGcAU+fqAsEgRQksn0npQso5nQiYSRu4Ru51txn4HZecWfQvY7Is+9LV957 2E1Aza3BY0J7kX6lslIOrh+gdipNaMd2TL98/3IYaRUsSwOLkmayOqWeShkOFhK2II9Z LVTIkJqmE/UJ8YhP2oLlMRba0UNU8+p1zs8GqnbsyUbuUHPADCZKvCTC+a2itz6jdmWI DKWw== MIME-Version: 1.0 X-Received: by 10.194.63.240 with SMTP id j16mr31500079wjs.45.1362402595822; Mon, 04 Mar 2013 05:09:55 -0800 (PST) Received: by 10.216.236.13 with HTTP; Mon, 4 Mar 2013 05:09:55 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 14:09:55 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: Re: [Xen-users] Error: /usr/lib/xen/bin/xc_save 22 6 0 0 0 failed X-BeenThere: xen-users@lists.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="===============2487915524640684042==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2487915524640684042== Content-Type: multipart/alternative; boundary=047d7ba97b72c4ad1d04d71912d7 --047d7ba97b72c4ad1d04d71912d7 Content-Type: text/plain; charset=ISO-8859-1 Ok, solve it. It seem I have exact domu running on backup server. Regards, Agya On Mon, Mar 4, 2013 at 12:19 PM, agya naila wrote: > Hi All, > > Does anybody have this problem when try to migrate DomU : > > Error: /usr/lib/xen/bin/xc_save 22 6 0 0 0 failed > > I use xen 4.2.2-pre compiled from sources and my machine is Ubuntu > 12.04 Linux with kernel 3.2.0-29-generic. > Its working perfectly, even remus with drbd support migration was running > successfully before. However today after I kill the remus process with > command > > pkill -USR1 remus > > The remus process was terminated but when I re-tried to run the remus > again its failed even basic function like migration without live migration > is failed with error above. I try to restart the xen service but its still > had the problem. Cpuld any body have the clue? > > Regards, > > Agya > --047d7ba97b72c4ad1d04d71912d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, solve it. It seem I have exact domu running on backup server.

<= /div>
Regards,

Agya

On Mon, Mar 4, 2013 at 12:19 PM, agya naila <<= a href=3D"mailto:agya.naila@gmail.com" target=3D"_blank">agya.naila@gmail.c= om> wrote:
Hi All,

Does anybody have= this problem when try to migrate DomU :

Error: /u= sr/lib/xen/bin/xc_save 22 6 0 0 0 failed

I use xen 4.2.2-pre compiled from sources and my machin= e is Ubuntu 12.04=A0Linux with kernel 3.2.0-29-generic.
Its working perfectly, even remus with drbd support migration was runn= ing successfully before. However today after I kill the remus process with = command=A0

pkill -USR1 remus

The remus process was terminated but when I re-tried to run the remus = again its failed even basic function like migration without live migration = is failed with error above. I try to restart the xen service but its still = had the problem. Cpuld any body have the clue?=A0

Regards,

Agya

--047d7ba97b72c4ad1d04d71912d7-- --===============2487915524640684042== 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 --===============2487915524640684042==-- From xen-users-bounces@lists.xen.org Mon Mar 04 15:37:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 15:37: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 1UCXR1-0004pt-Dd; Mon, 04 Mar 2013 15:36:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCXQz-0004pn-VP for xen-users@lists.xen.org; Mon, 04 Mar 2013 15:36:14 +0000 Received: from [85.158.137.99:2733] by server-14.bemta-3.messagelabs.com id B1/48-27076-D6FB4315; Mon, 04 Mar 2013 15:36:13 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1362411370!13682969!1 X-Originating-IP: [209.85.160.53] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16845 invoked from network); 4 Mar 2013 15:36:12 -0000 Received: from mail-pb0-f53.google.com (HELO mail-pb0-f53.google.com) (209.85.160.53) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 15:36:12 -0000 Received: by mail-pb0-f53.google.com with SMTP id un1so3130724pbc.26 for ; Mon, 04 Mar 2013 07:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=gKlEhXknRYjsF5yK3dJPAgwEgRhvVH5I8sCuAZ4mtDA=; b=qQdWqDKIx2E09m4obvQPUUuumbs0gya5eSp17pUX9IXw5Uwq0FTYyi7pco4EOZ6ueQ PETIVfDtgh33rE2w4GEkazJX42aXeRlVPwFvcR/+GFqcsjtuO91vgT4635o3FN20vJKi FhYvDWXdZoQPcFx6nTgrSdCyIQWn3et+aZ7K11qQykq+FKIVJ/FKckGIEKF8IX44Uqt9 rz1uYxuuvGOLdHz8op/S+Jz0CH0M+/glI5xMGUWzF2mKEblLJUvT1/2D85KK1ZSXCb4w 3u5ifJyMmJROIi/m9DsUHZqYaJNzZjcpP6QVgCmvJXgwncfRykPzkZyzxfuNSCfWi1s9 vtsw== MIME-Version: 1.0 X-Received: by 10.68.241.225 with SMTP id wl1mr28803422pbc.170.1362411369968; Mon, 04 Mar 2013 07:36:09 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 07:36:09 -0800 (PST) Date: Mon, 4 Mar 2013 12:36:09 -0300 Message-ID: From: Guilherme Suzuki To: xen-users@lists.xen.org Subject: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============3880123719355423975==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3880123719355423975== Content-Type: multipart/alternative; boundary=047d7b33971bbebc5f04d71b1d61 --047d7b33971bbebc5f04d71b1d61 Content-Type: text/plain; charset=ISO-8859-1 Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really interested in xen-vga-passthru. Lately, I bought a brand new Saphire HD 7950 (OC Boost) because I saw in a wiki somewhere that users have been able to passthru these VGA devices to domU (win7, win-xp and so on). But, after I installed it, I executed *lspci -vv* to check if FLR in DevCap was present (which it's *not*). I've managed, though, to put my virtual machine to work out with the HD 7950 as a secondary device. Sometimes, I have to reboot dom0 to make things work. So, here's my question: is there any patch to help me out and solve this problem? Here's a short description about my equipment: *fedora 18*, kernel 3.6-10 rebuilt with xen-kernel features (instead of kernel modules), *xen-unstable*rev *26667*, *saphire HD 7950 11196-16-20G*! Thanks a lot, ** *Guilherme Suzuki* Consultor em TI para projetos Microsoft *http://www.guilhermesuzuki.com* 11 - 992360535 11 - 20990757 --047d7b33971bbebc5f04d71b1d61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, everyone. I'm Guilherme Suzuki= (brazillian, by the way) and really interested in xen-vga-passthru.
Lately, I bought a brand new Saphire HD 7950 (OC Boost) because I sa= w in a wiki somewhere that users have been able to passthru these VGA devic= es to domU (win7, win-xp and so on).

But, after I installed it, I executed lspci -vv to check i= f FLR in DevCap was present (which it's not).

I= 9;ve managed, though, to put my virtual machine to work out with the HD 795= 0 as a secondary device. Sometimes, I have to reboot dom0 to make things wo= rk.

So, here's my question: is there any patch to help me out and= solve this problem?

Here's a short description about my equipm= ent: fedora 18, kernel 3.6-10 rebuilt with xen-kernel features (inst= ead of kernel modules), xen-unstable rev 26667, saphire HD= 7950 11196-16-20G!

Thanks a lot,
Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=A0
--047d7b33971bbebc5f04d71b1d61-- --===============3880123719355423975== 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 --===============3880123719355423975==-- From xen-users-bounces@lists.xen.org Mon Mar 04 15:37:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 15:37: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 1UCXR1-0004pt-Dd; Mon, 04 Mar 2013 15:36:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCXQz-0004pn-VP for xen-users@lists.xen.org; Mon, 04 Mar 2013 15:36:14 +0000 Received: from [85.158.137.99:2733] by server-14.bemta-3.messagelabs.com id B1/48-27076-D6FB4315; Mon, 04 Mar 2013 15:36:13 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1362411370!13682969!1 X-Originating-IP: [209.85.160.53] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16845 invoked from network); 4 Mar 2013 15:36:12 -0000 Received: from mail-pb0-f53.google.com (HELO mail-pb0-f53.google.com) (209.85.160.53) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 15:36:12 -0000 Received: by mail-pb0-f53.google.com with SMTP id un1so3130724pbc.26 for ; Mon, 04 Mar 2013 07:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=gKlEhXknRYjsF5yK3dJPAgwEgRhvVH5I8sCuAZ4mtDA=; b=qQdWqDKIx2E09m4obvQPUUuumbs0gya5eSp17pUX9IXw5Uwq0FTYyi7pco4EOZ6ueQ PETIVfDtgh33rE2w4GEkazJX42aXeRlVPwFvcR/+GFqcsjtuO91vgT4635o3FN20vJKi FhYvDWXdZoQPcFx6nTgrSdCyIQWn3et+aZ7K11qQykq+FKIVJ/FKckGIEKF8IX44Uqt9 rz1uYxuuvGOLdHz8op/S+Jz0CH0M+/glI5xMGUWzF2mKEblLJUvT1/2D85KK1ZSXCb4w 3u5ifJyMmJROIi/m9DsUHZqYaJNzZjcpP6QVgCmvJXgwncfRykPzkZyzxfuNSCfWi1s9 vtsw== MIME-Version: 1.0 X-Received: by 10.68.241.225 with SMTP id wl1mr28803422pbc.170.1362411369968; Mon, 04 Mar 2013 07:36:09 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 07:36:09 -0800 (PST) Date: Mon, 4 Mar 2013 12:36:09 -0300 Message-ID: From: Guilherme Suzuki To: xen-users@lists.xen.org Subject: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============3880123719355423975==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3880123719355423975== Content-Type: multipart/alternative; boundary=047d7b33971bbebc5f04d71b1d61 --047d7b33971bbebc5f04d71b1d61 Content-Type: text/plain; charset=ISO-8859-1 Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really interested in xen-vga-passthru. Lately, I bought a brand new Saphire HD 7950 (OC Boost) because I saw in a wiki somewhere that users have been able to passthru these VGA devices to domU (win7, win-xp and so on). But, after I installed it, I executed *lspci -vv* to check if FLR in DevCap was present (which it's *not*). I've managed, though, to put my virtual machine to work out with the HD 7950 as a secondary device. Sometimes, I have to reboot dom0 to make things work. So, here's my question: is there any patch to help me out and solve this problem? Here's a short description about my equipment: *fedora 18*, kernel 3.6-10 rebuilt with xen-kernel features (instead of kernel modules), *xen-unstable*rev *26667*, *saphire HD 7950 11196-16-20G*! Thanks a lot, ** *Guilherme Suzuki* Consultor em TI para projetos Microsoft *http://www.guilhermesuzuki.com* 11 - 992360535 11 - 20990757 --047d7b33971bbebc5f04d71b1d61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, everyone. I'm Guilherme Suzuki= (brazillian, by the way) and really interested in xen-vga-passthru.
Lately, I bought a brand new Saphire HD 7950 (OC Boost) because I sa= w in a wiki somewhere that users have been able to passthru these VGA devic= es to domU (win7, win-xp and so on).

But, after I installed it, I executed lspci -vv to check i= f FLR in DevCap was present (which it's not).

I= 9;ve managed, though, to put my virtual machine to work out with the HD 795= 0 as a secondary device. Sometimes, I have to reboot dom0 to make things wo= rk.

So, here's my question: is there any patch to help me out and= solve this problem?

Here's a short description about my equipm= ent: fedora 18, kernel 3.6-10 rebuilt with xen-kernel features (inst= ead of kernel modules), xen-unstable rev 26667, saphire HD= 7950 11196-16-20G!

Thanks a lot,
Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=A0
--047d7b33971bbebc5f04d71b1d61-- --===============3880123719355423975== 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 --===============3880123719355423975==-- From xen-users-bounces@lists.xen.org Mon Mar 04 16:12:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:12: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 1UCXyh-00069B-6a; Mon, 04 Mar 2013 16:11:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCXyf-000696-BG for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:11:01 +0000 Received: from [85.158.143.99:44639] by server-3.bemta-4.messagelabs.com id AA/45-02186-497C4315; Mon, 04 Mar 2013 16:11:00 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1362413459!21189583!1 X-Originating-IP: [74.125.82.179] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3314 invoked from network); 4 Mar 2013 16:10:59 -0000 Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com) (74.125.82.179) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:10:59 -0000 Received: by mail-we0-f179.google.com with SMTP id p43so4773281wea.10 for ; Mon, 04 Mar 2013 08:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KQEuLQZj986wJk9JqcVwMUjAWDvFTMFN2H2BGjBRdk4=; b=MyL8QCgp9/LE3+MdyBWa0khAbtI+onIZi92/3cgUYrqTaQhhhWumgU7oPR9jKP50SJ YRVAl3zYibZJLRdxrAhlbdf+1xPYNsNInKyiNBH9Q3k92jLhSucHCE5Fs2Udf4XTYjII 0+4NjPandNzGuzQJLlGIipbB5FKqQj8vqrw6eqrBI3c0bcSBccpGBbrjutVYUupy8eK9 xdKxSNzXxSeToNGZ6KairDakji80rIFUc265BHcpWZoYI3hiumFskACWaRRQnjk16axT Rmo25wZs6G5r6I1235jfLaWpcTn833HuckZ+SH8pslAs1fAy3KDvsZOyE9jGH/czLUBM 1Byg== X-Received: by 10.180.84.162 with SMTP id a2mr12637608wiz.14.1362413459091; Mon, 04 Mar 2013 08:10:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 08:10:38 -0800 (PST) In-Reply-To: References: From: Matthias Date: Mon, 4 Mar 2013 17:10:38 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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, ehm, I may be missing something, but what exactly is your problem? Or better phrased: Do you have any functional problems like BSODs or something? Also, what distro and kernel are you using? 2013/3/4 Guilherme Suzuki : > Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really > interested in xen-vga-passthru. > > Lately, I bought a brand new Saphire HD 7950 (OC Boost) because I saw in a > wiki somewhere that users have been able to passthru these VGA devices to > domU (win7, win-xp and so on). > > But, after I installed it, I executed lspci -vv to check if FLR in DevCap > was present (which it's not). > > I've managed, though, to put my virtual machine to work out with the HD 7950 > as a secondary device. Sometimes, I have to reboot dom0 to make things work. > > So, here's my question: is there any patch to help me out and solve this > problem? > > Here's a short description about my equipment: fedora 18, kernel 3.6-10 > rebuilt with xen-kernel features (instead of kernel modules), xen-unstable > rev 26667, saphire HD 7950 11196-16-20G! > > Thanks a lot, > > Guilherme Suzuki > Consultor em TI para projetos Microsoft > http://www.guilhermesuzuki.com > 11 - 992360535 > 11 - 20990757 > > > > _______________________________________________ > 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 Mar 04 16:12:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:12: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 1UCXyh-00069B-6a; Mon, 04 Mar 2013 16:11:03 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCXyf-000696-BG for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:11:01 +0000 Received: from [85.158.143.99:44639] by server-3.bemta-4.messagelabs.com id AA/45-02186-497C4315; Mon, 04 Mar 2013 16:11:00 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1362413459!21189583!1 X-Originating-IP: [74.125.82.179] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3314 invoked from network); 4 Mar 2013 16:10:59 -0000 Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com) (74.125.82.179) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:10:59 -0000 Received: by mail-we0-f179.google.com with SMTP id p43so4773281wea.10 for ; Mon, 04 Mar 2013 08:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KQEuLQZj986wJk9JqcVwMUjAWDvFTMFN2H2BGjBRdk4=; b=MyL8QCgp9/LE3+MdyBWa0khAbtI+onIZi92/3cgUYrqTaQhhhWumgU7oPR9jKP50SJ YRVAl3zYibZJLRdxrAhlbdf+1xPYNsNInKyiNBH9Q3k92jLhSucHCE5Fs2Udf4XTYjII 0+4NjPandNzGuzQJLlGIipbB5FKqQj8vqrw6eqrBI3c0bcSBccpGBbrjutVYUupy8eK9 xdKxSNzXxSeToNGZ6KairDakji80rIFUc265BHcpWZoYI3hiumFskACWaRRQnjk16axT Rmo25wZs6G5r6I1235jfLaWpcTn833HuckZ+SH8pslAs1fAy3KDvsZOyE9jGH/czLUBM 1Byg== X-Received: by 10.180.84.162 with SMTP id a2mr12637608wiz.14.1362413459091; Mon, 04 Mar 2013 08:10:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 08:10:38 -0800 (PST) In-Reply-To: References: From: Matthias Date: Mon, 4 Mar 2013 17:10:38 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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, ehm, I may be missing something, but what exactly is your problem? Or better phrased: Do you have any functional problems like BSODs or something? Also, what distro and kernel are you using? 2013/3/4 Guilherme Suzuki : > Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really > interested in xen-vga-passthru. > > Lately, I bought a brand new Saphire HD 7950 (OC Boost) because I saw in a > wiki somewhere that users have been able to passthru these VGA devices to > domU (win7, win-xp and so on). > > But, after I installed it, I executed lspci -vv to check if FLR in DevCap > was present (which it's not). > > I've managed, though, to put my virtual machine to work out with the HD 7950 > as a secondary device. Sometimes, I have to reboot dom0 to make things work. > > So, here's my question: is there any patch to help me out and solve this > problem? > > Here's a short description about my equipment: fedora 18, kernel 3.6-10 > rebuilt with xen-kernel features (instead of kernel modules), xen-unstable > rev 26667, saphire HD 7950 11196-16-20G! > > Thanks a lot, > > Guilherme Suzuki > Consultor em TI para projetos Microsoft > http://www.guilhermesuzuki.com > 11 - 992360535 > 11 - 20990757 > > > > _______________________________________________ > 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 Mar 04 16:15:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:15: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 1UCY2K-0006YD-3N; Mon, 04 Mar 2013 16:14:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCY2I-0006Y6-VC for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:14:47 +0000 Received: from [85.158.139.211:12964] by server-12.bemta-5.messagelabs.com id 6E/33-11486-678C4315; Mon, 04 Mar 2013 16:14:46 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1362413683!19482776!1 X-Originating-IP: [209.85.160.46] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19326 invoked from network); 4 Mar 2013 16:14:45 -0000 Received: from mail-pb0-f46.google.com (HELO mail-pb0-f46.google.com) (209.85.160.46) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:14:45 -0000 Received: by mail-pb0-f46.google.com with SMTP id uo15so3165902pbc.33 for ; Mon, 04 Mar 2013 08:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mdoD73sbelwSspnGhiMlklUURfigBW+IbV6gV3E2Z2o=; b=vY7graHlURuQcDa1jzMxKIiXqQZoGHPbLZLqrdNISQz2lCTF09mWyu8BLYrZmisQa2 o4K3uWzUBT+SyQr/Su4NPOXoOajmMEqMlLqRywpuHiGsPr1giv1UdGKy5d0uNERjDlJw zLXITo+pixARxBwp63Dy+tCeOmZmEu/04kHf4RQVmYQOXUeorhJVuBZ8yu+aJR5MWFy2 PXgVNobFdZ32T2hgwnSbTHOvC/f6631BIxoNFymnzG64otFtrrR6pnk3Bn8urR+oDLAL t1DIfNvYGdkK6LkMLQOodI8VaSuUws27/3+TEN+BbBHCWD99Xiet5KQL1YDgUFcydZhx vJGQ== MIME-Version: 1.0 X-Received: by 10.68.202.3 with SMTP id ke3mr28948080pbc.98.1362413682593; Mon, 04 Mar 2013 08:14:42 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:14:42 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:14:42 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 13:14:42 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============4858176763868954876==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4858176763868954876== Content-Type: multipart/alternative; boundary=047d7b15b06196967504d71ba7f1 --047d7b15b06196967504d71ba7f1 Content-Type: text/plain; charset=ISO-8859-1 Hey matthias, nice to meet you, buddy. My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru work properly. On Mar 4, 2013 1:10 PM, "Matthias" wrote: Hi, ehm, I may be missing something, but what exactly is your problem? Or better phrased: Do you have any functional problems like BSODs or something? Also, what distro and kernel are you using? 2013/3/4 Guilherme Suzuki : > Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really > interested in xen-vga-pas... > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --047d7b15b06196967504d71ba7f1 Content-Type: text/html; charset=ISO-8859-1

Hey matthias, nice to meet you, buddy.

My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru work properly.

On Mar 4, 2013 1:10 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

ehm, I may be missing something, but what exactly is your problem? Or
better phrased: Do you have any functional problems like BSODs or
something?

Also, what distro and kernel are you using?

2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really
> interested in xen-vga-pas...

> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users

--047d7b15b06196967504d71ba7f1-- --===============4858176763868954876== 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 --===============4858176763868954876==-- From xen-users-bounces@lists.xen.org Mon Mar 04 16:15:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:15: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 1UCY2K-0006YD-3N; Mon, 04 Mar 2013 16:14:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCY2I-0006Y6-VC for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:14:47 +0000 Received: from [85.158.139.211:12964] by server-12.bemta-5.messagelabs.com id 6E/33-11486-678C4315; Mon, 04 Mar 2013 16:14:46 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1362413683!19482776!1 X-Originating-IP: [209.85.160.46] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19326 invoked from network); 4 Mar 2013 16:14:45 -0000 Received: from mail-pb0-f46.google.com (HELO mail-pb0-f46.google.com) (209.85.160.46) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:14:45 -0000 Received: by mail-pb0-f46.google.com with SMTP id uo15so3165902pbc.33 for ; Mon, 04 Mar 2013 08:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mdoD73sbelwSspnGhiMlklUURfigBW+IbV6gV3E2Z2o=; b=vY7graHlURuQcDa1jzMxKIiXqQZoGHPbLZLqrdNISQz2lCTF09mWyu8BLYrZmisQa2 o4K3uWzUBT+SyQr/Su4NPOXoOajmMEqMlLqRywpuHiGsPr1giv1UdGKy5d0uNERjDlJw zLXITo+pixARxBwp63Dy+tCeOmZmEu/04kHf4RQVmYQOXUeorhJVuBZ8yu+aJR5MWFy2 PXgVNobFdZ32T2hgwnSbTHOvC/f6631BIxoNFymnzG64otFtrrR6pnk3Bn8urR+oDLAL t1DIfNvYGdkK6LkMLQOodI8VaSuUws27/3+TEN+BbBHCWD99Xiet5KQL1YDgUFcydZhx vJGQ== MIME-Version: 1.0 X-Received: by 10.68.202.3 with SMTP id ke3mr28948080pbc.98.1362413682593; Mon, 04 Mar 2013 08:14:42 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:14:42 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:14:42 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 13:14:42 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============4858176763868954876==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4858176763868954876== Content-Type: multipart/alternative; boundary=047d7b15b06196967504d71ba7f1 --047d7b15b06196967504d71ba7f1 Content-Type: text/plain; charset=ISO-8859-1 Hey matthias, nice to meet you, buddy. My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru work properly. On Mar 4, 2013 1:10 PM, "Matthias" wrote: Hi, ehm, I may be missing something, but what exactly is your problem? Or better phrased: Do you have any functional problems like BSODs or something? Also, what distro and kernel are you using? 2013/3/4 Guilherme Suzuki : > Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really > interested in xen-vga-pas... > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --047d7b15b06196967504d71ba7f1 Content-Type: text/html; charset=ISO-8859-1

Hey matthias, nice to meet you, buddy.

My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru work properly.

On Mar 4, 2013 1:10 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

ehm, I may be missing something, but what exactly is your problem? Or
better phrased: Do you have any functional problems like BSODs or
something?

Also, what distro and kernel are you using?

2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really
> interested in xen-vga-pas...

> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users

--047d7b15b06196967504d71ba7f1-- --===============4858176763868954876== 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 --===============4858176763868954876==-- From xen-users-bounces@lists.xen.org Mon Mar 04 16:19:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:19: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 1UCY6L-0006wt-2E; Mon, 04 Mar 2013 16:18:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCY6J-0006we-M5 for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:18:55 +0000 Received: from [85.158.137.99:61910] by server-14.bemta-3.messagelabs.com id FC/27-27076-E69C4315; Mon, 04 Mar 2013 16:18:54 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1362413931!17791056!1 X-Originating-IP: [209.85.160.53] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24203 invoked from network); 4 Mar 2013 16:18:53 -0000 Received: from mail-pb0-f53.google.com (HELO mail-pb0-f53.google.com) (209.85.160.53) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:18:53 -0000 Received: by mail-pb0-f53.google.com with SMTP id un1so3158389pbc.26 for ; Mon, 04 Mar 2013 08:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3C9sAlc8+om7H5RWlASDpPFI0V2MPNImCqpai78CPKY=; b=BpmbFrnd2zotnef4g/LnKTKcFO10xbLZ9qKqXl+R9Rw1oZE0pUKlL8ktoXDPg0PpBi GjTITaSh7Dq4FBNi6KVeshwc6p9uOnYNqWjiOmag1Jlbo1P/xJWmkumd0SUGpPLCHf9O 124TEa6kd8/Z/WSnFlIstd5L8ERPz916TfVhNUErg0XiAkuyZkW2NOGTyZRcj27US4El D0plSH++IX3UcHWtGTixNFy2Bid6cvHi3yjKO5yjw1TfApuz9ztTCkNNMGU3/VZg+GzH SrfTtiuI7twlprkSmEJ8nETVlDrgEdnUFHUEeng4gkuNL7pXZtAezi/FjOddAtBk/mar vdDQ== MIME-Version: 1.0 X-Received: by 10.68.189.8 with SMTP id ge8mr8510406pbc.166.1362413931222; Mon, 04 Mar 2013 08:18:51 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:18:51 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:18:51 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 13:18:51 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============6654140163381143766==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6654140163381143766== Content-Type: multipart/alternative; boundary=e89a8ff1c99c685d6704d71bb613 --e89a8ff1c99c685d6704d71bb613 Content-Type: text/plain; charset=ISO-8859-1 My kernel version: 3.6-10 and fedora 18 On Mar 4, 2013 1:14 PM, "Guilherme Suzuki" wrote: Hey matthias, nice to meet you, buddy. My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru work properly. > > On Mar 4, 2013 1:10 PM, "Matthias" wrote: > > Hi, > > ehm,... > > > Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really > interested in xen-vga-pas... > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@list... --e89a8ff1c99c685d6704d71bb613 Content-Type: text/html; charset=ISO-8859-1

My kernel version: 3.6-10 and fedora 18

On Mar 4, 2013 1:14 PM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Hey matthias, nice to meet you, buddy.

My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru work properly.


>
> On Mar 4, 2013 1:10 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:
>
> Hi,
>
> ehm,...

>
> > Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really

> interested in xen-vga-pas...


>
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@list...

--e89a8ff1c99c685d6704d71bb613-- --===============6654140163381143766== 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 --===============6654140163381143766==-- From xen-users-bounces@lists.xen.org Mon Mar 04 16:19:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:19: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 1UCY6L-0006wt-2E; Mon, 04 Mar 2013 16:18:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCY6J-0006we-M5 for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:18:55 +0000 Received: from [85.158.137.99:61910] by server-14.bemta-3.messagelabs.com id FC/27-27076-E69C4315; Mon, 04 Mar 2013 16:18:54 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1362413931!17791056!1 X-Originating-IP: [209.85.160.53] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24203 invoked from network); 4 Mar 2013 16:18:53 -0000 Received: from mail-pb0-f53.google.com (HELO mail-pb0-f53.google.com) (209.85.160.53) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:18:53 -0000 Received: by mail-pb0-f53.google.com with SMTP id un1so3158389pbc.26 for ; Mon, 04 Mar 2013 08:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3C9sAlc8+om7H5RWlASDpPFI0V2MPNImCqpai78CPKY=; b=BpmbFrnd2zotnef4g/LnKTKcFO10xbLZ9qKqXl+R9Rw1oZE0pUKlL8ktoXDPg0PpBi GjTITaSh7Dq4FBNi6KVeshwc6p9uOnYNqWjiOmag1Jlbo1P/xJWmkumd0SUGpPLCHf9O 124TEa6kd8/Z/WSnFlIstd5L8ERPz916TfVhNUErg0XiAkuyZkW2NOGTyZRcj27US4El D0plSH++IX3UcHWtGTixNFy2Bid6cvHi3yjKO5yjw1TfApuz9ztTCkNNMGU3/VZg+GzH SrfTtiuI7twlprkSmEJ8nETVlDrgEdnUFHUEeng4gkuNL7pXZtAezi/FjOddAtBk/mar vdDQ== MIME-Version: 1.0 X-Received: by 10.68.189.8 with SMTP id ge8mr8510406pbc.166.1362413931222; Mon, 04 Mar 2013 08:18:51 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:18:51 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:18:51 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 13:18:51 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============6654140163381143766==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6654140163381143766== Content-Type: multipart/alternative; boundary=e89a8ff1c99c685d6704d71bb613 --e89a8ff1c99c685d6704d71bb613 Content-Type: text/plain; charset=ISO-8859-1 My kernel version: 3.6-10 and fedora 18 On Mar 4, 2013 1:14 PM, "Guilherme Suzuki" wrote: Hey matthias, nice to meet you, buddy. My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru work properly. > > On Mar 4, 2013 1:10 PM, "Matthias" wrote: > > Hi, > > ehm,... > > > Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really > interested in xen-vga-pas... > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@list... --e89a8ff1c99c685d6704d71bb613 Content-Type: text/html; charset=ISO-8859-1

My kernel version: 3.6-10 and fedora 18

On Mar 4, 2013 1:14 PM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Hey matthias, nice to meet you, buddy.

My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru work properly.


>
> On Mar 4, 2013 1:10 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:
>
> Hi,
>
> ehm,...

>
> > Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really

> interested in xen-vga-pas...


>
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@list...

--e89a8ff1c99c685d6704d71bb613-- --===============6654140163381143766== 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 --===============6654140163381143766==-- From xen-users-bounces@lists.xen.org Mon Mar 04 16:27:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:27: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 1UCYEE-0007R0-8n; Mon, 04 Mar 2013 16:27:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYEC-0007Ql-N7 for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:27:04 +0000 Received: from [85.158.143.99:7213] by server-1.bemta-4.messagelabs.com id 35/E4-06203-85BC4315; Mon, 04 Mar 2013 16:27:04 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1362414423!27544628!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3621 invoked from network); 4 Mar 2013 16:27:03 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:27:03 -0000 Received: by mail-wi0-f173.google.com with SMTP id hq4so2252994wib.12 for ; Mon, 04 Mar 2013 08:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=NEBKe7Opg/0Di129FwcL7WpWcbv4Sok+uc7IJhgVByM=; b=S6PFeymgvFd5QDZpJEJhKCToCx5C1RZ2AjtHdy7UNgWRurKYHz7eAT1kXwKzz849f7 1V9btcwdt8WtS7fHLGnEKmW/ULriG4CZxZhBXIc1ppfhTVl6N8pSCEO0XPJMhKLkWHcA HtJixeRl6tH81LGd2EfsxGf9ErUZAIWSkszAqjeqHm2CeuHKzDMrJuWRCbUkqcQ+VzPZ lUNHeyicgX9pQNEFpuZuZWeldrE93JsxR/pjfTuL8j8JpFMESV43aZPgLgPwIPlz/ei8 zt4QvFT2rBSrjAUAxOApweDRdxvCxc5/U5xsxYGn5SfMGIyvlPiDQtNcO+OhGFKTlIE8 WfIQ== X-Received: by 10.180.84.162 with SMTP id a2mr12749175wiz.14.1362414422903; Mon, 04 Mar 2013 08:27:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 08:26:42 -0800 (PST) In-Reply-To: References: From: Matthias Date: Mon, 4 Mar 2013 17:26:42 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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 there, I fear you have to be a bit more specific because with only that information, this could be a lot.. But alright, let's start at the beginning: I assume you installed your dom0, installed your windows domU via the vnc vga, then installed latest catalyst drivers and at this point vga passthrough should work.. So now let's assume you have a freshly booted dom0 and try to start your domU. Does vga passthrough works every time on a freshly booted dom0? Lets further assume it have worked the first time.. does it always does not work when booting a second time? What in general happens when you say vga passthrough doesn't work? Do you get a BSOD? or do you get your graphic output on the vnc vga and your main vga has a error 14 or error 43 in device manager? Also, next to distro and kernel information, your domU config would be interesting (especially the acpi, api, pci_whatever parts).. 2013/3/4 Guilherme Suzuki : > Hey matthias, nice to meet you, buddy. > > My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru > work properly. > > On Mar 4, 2013 1:10 PM, "Matthias" > wrote: > > Hi, > > ehm, I may be missing something, but what exactly is your problem? Or > better phrased: Do you have any functional problems like BSODs or > something? > > Also, what distro and kernel are you using? > > 2013/3/4 Guilherme Suzuki : > >> Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really >> interested in xen-vga-pas... > >> _______________________________________________ >> 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 Mar 04 16:27:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:27: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 1UCYEE-0007R0-8n; Mon, 04 Mar 2013 16:27:06 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYEC-0007Ql-N7 for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:27:04 +0000 Received: from [85.158.143.99:7213] by server-1.bemta-4.messagelabs.com id 35/E4-06203-85BC4315; Mon, 04 Mar 2013 16:27:04 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1362414423!27544628!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3621 invoked from network); 4 Mar 2013 16:27:03 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:27:03 -0000 Received: by mail-wi0-f173.google.com with SMTP id hq4so2252994wib.12 for ; Mon, 04 Mar 2013 08:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=NEBKe7Opg/0Di129FwcL7WpWcbv4Sok+uc7IJhgVByM=; b=S6PFeymgvFd5QDZpJEJhKCToCx5C1RZ2AjtHdy7UNgWRurKYHz7eAT1kXwKzz849f7 1V9btcwdt8WtS7fHLGnEKmW/ULriG4CZxZhBXIc1ppfhTVl6N8pSCEO0XPJMhKLkWHcA HtJixeRl6tH81LGd2EfsxGf9ErUZAIWSkszAqjeqHm2CeuHKzDMrJuWRCbUkqcQ+VzPZ lUNHeyicgX9pQNEFpuZuZWeldrE93JsxR/pjfTuL8j8JpFMESV43aZPgLgPwIPlz/ei8 zt4QvFT2rBSrjAUAxOApweDRdxvCxc5/U5xsxYGn5SfMGIyvlPiDQtNcO+OhGFKTlIE8 WfIQ== X-Received: by 10.180.84.162 with SMTP id a2mr12749175wiz.14.1362414422903; Mon, 04 Mar 2013 08:27:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 08:26:42 -0800 (PST) In-Reply-To: References: From: Matthias Date: Mon, 4 Mar 2013 17:26:42 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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 there, I fear you have to be a bit more specific because with only that information, this could be a lot.. But alright, let's start at the beginning: I assume you installed your dom0, installed your windows domU via the vnc vga, then installed latest catalyst drivers and at this point vga passthrough should work.. So now let's assume you have a freshly booted dom0 and try to start your domU. Does vga passthrough works every time on a freshly booted dom0? Lets further assume it have worked the first time.. does it always does not work when booting a second time? What in general happens when you say vga passthrough doesn't work? Do you get a BSOD? or do you get your graphic output on the vnc vga and your main vga has a error 14 or error 43 in device manager? Also, next to distro and kernel information, your domU config would be interesting (especially the acpi, api, pci_whatever parts).. 2013/3/4 Guilherme Suzuki : > Hey matthias, nice to meet you, buddy. > > My problem: sometimes I have to reboot the dom0 (lame) to see VGA passthru > work properly. > > On Mar 4, 2013 1:10 PM, "Matthias" > wrote: > > Hi, > > ehm, I may be missing something, but what exactly is your problem? Or > better phrased: Do you have any functional problems like BSODs or > something? > > Also, what distro and kernel are you using? > > 2013/3/4 Guilherme Suzuki : > >> Hi, everyone. I'm Guilherme Suzuki (brazillian, by the way) and really >> interested in xen-vga-pas... > >> _______________________________________________ >> 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 Mar 04 16:38:09 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:38: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 1UCYOJ-0008De-PC; Mon, 04 Mar 2013 16:37:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYOJ-0008DV-6Y for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:37:31 +0000 Received: from [85.158.139.83:10898] by server-6.bemta-5.messagelabs.com id AA/75-21466-ACDC4315; Mon, 04 Mar 2013 16:37:30 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1362415047!30322098!1 X-Originating-IP: [209.85.210.44] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1656 invoked from network); 4 Mar 2013 16:37:29 -0000 Received: from mail-da0-f44.google.com (HELO mail-da0-f44.google.com) (209.85.210.44) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:37:29 -0000 Received: by mail-da0-f44.google.com with SMTP id z20so2626654dae.17 for ; Mon, 04 Mar 2013 08:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ht4TF45NlmpOhu8W828jrMh7NNLFF4TOCXZg6vUHL50=; b=JBO21VEGXw5FSEEwHGNjJEjUOxChshGbu8IPIddoTGyxj3wjHss4x3DxDDoCcPH+WV 7vf7ebReFMecsZUE27ESCFpJEvy7jy37b4bjlZsA+egDcP4vyWw83F5XheH9pvHE5WPz IaqX3Z8zSjmdfmpv7IFyJ1pGrf0i5kl9i+5T3ZWXoQTskt4/JKs3ffDCY/dlurt972QP uHzN46he0drcIUQEn7Q+Zn4PoJo7kpXnt3Phat5bIhrv39rrBkwSA16i222TwZsYaYcO nYaLXKKgbadiFfXv9/XkoAEOONZqdiHHelOBMBB9FHgENI3rRmYTvFQEMX5k82O6DWWL sDnA== MIME-Version: 1.0 X-Received: by 10.68.189.199 with SMTP id gk7mr28532585pbc.164.1362415047306; Mon, 04 Mar 2013 08:37:27 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:37:27 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:37:27 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 13:37:27 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5954189711756712636==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5954189711756712636== Content-Type: multipart/alternative; boundary=e89a8ff1c8e8ee770a04d71bf8b1 --e89a8ff1c8e8ee770a04d71bf8b1 Content-Type: text/plain; charset=ISO-8859-1 Alright! First question: yes, it does work everytime I start the dom0 with my HD 7950 freshly booted as the secondary VGA (it never worked as primary though). Using windows 7 ultimate 64bits, after rebooting due to windows update, the VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, the cirrus device seems to be okay, the radeon device tells me it co Using Windows XP sp3 I managed to reboot the VM several times and everything worked. On Mar 4, 2013 1:27 PM, "Matthias" wrote: Hi there, I fear you have to be a bit more specific because with only that information, this could be a lot.. But alright, let's start at the beginning: I assume you installed your dom0, installed your windows domU via the vnc vga, then installed latest catalyst drivers and at this point vga passthrough should work.. So now let's assume you have a freshly booted dom0 and try to start your domU. Does vga passthrough works every time on a freshly booted dom0? Lets further assume it have worked the first time.. does it always does not work when booting a second time? What in general happens when you say vga passthrough doesn't work? Do you get a BSOD? or do you get your graphic output on the vnc vga and your main vga has a error 14 or error 43 in device manager? Also, next to distro and kernel information, your domU config would be interesting (especially the acpi, api, pci_whatever parts).. 2013/3/4 Guilherme Suzuki : > Hey matthias, nice to meet you, buddy. > > My problem: sometimes I have to reboot the dom0 (lame) ... --e89a8ff1c8e8ee770a04d71bf8b1 Content-Type: text/html; charset=ISO-8859-1

Alright!

First question: yes, it does work everytime I start the dom0 with my HD 7950 freshly booted as the secondary VGA (it never worked as primary though).

Using windows 7 ultimate 64bits, after rebooting due to windows update, the VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, the cirrus device seems to be okay, the radeon device tells me it co

Using Windows XP sp3 I managed to reboot the VM several times and everything worked.

On Mar 4, 2013 1:27 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi there,

I fear you have to be a bit more specific because with only that
information, this could be a lot..

But alright, let's start at the beginning:

I assume you installed your dom0, installed your windows domU via the
vnc vga, then installed latest catalyst drivers and at this point vga
passthrough should work..

So now let's assume you have a freshly booted dom0 and try to start
your domU. Does vga passthrough works every time on a freshly booted
dom0?
Lets further assume it have worked the first time.. does it always
does not work when booting a second time?
What in general happens when you say vga passthrough doesn't work? Do
you get a BSOD? or do you get your graphic output on the vnc vga and
your main vga has a error 14 or error 43 in device manager?

Also, next to distro and kernel information, your domU config would be
interesting (especially the acpi, api, pci_whatever parts)..

2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Hey matthias, nice to meet you, buddy.
>
> My problem: sometimes I have to reboot the dom0 (lame) ...

--e89a8ff1c8e8ee770a04d71bf8b1-- --===============5954189711756712636== 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 --===============5954189711756712636==-- From xen-users-bounces@lists.xen.org Mon Mar 04 16:38:09 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:38: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 1UCYOJ-0008De-PC; Mon, 04 Mar 2013 16:37:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYOJ-0008DV-6Y for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:37:31 +0000 Received: from [85.158.139.83:10898] by server-6.bemta-5.messagelabs.com id AA/75-21466-ACDC4315; Mon, 04 Mar 2013 16:37:30 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1362415047!30322098!1 X-Originating-IP: [209.85.210.44] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1656 invoked from network); 4 Mar 2013 16:37:29 -0000 Received: from mail-da0-f44.google.com (HELO mail-da0-f44.google.com) (209.85.210.44) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:37:29 -0000 Received: by mail-da0-f44.google.com with SMTP id z20so2626654dae.17 for ; Mon, 04 Mar 2013 08:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ht4TF45NlmpOhu8W828jrMh7NNLFF4TOCXZg6vUHL50=; b=JBO21VEGXw5FSEEwHGNjJEjUOxChshGbu8IPIddoTGyxj3wjHss4x3DxDDoCcPH+WV 7vf7ebReFMecsZUE27ESCFpJEvy7jy37b4bjlZsA+egDcP4vyWw83F5XheH9pvHE5WPz IaqX3Z8zSjmdfmpv7IFyJ1pGrf0i5kl9i+5T3ZWXoQTskt4/JKs3ffDCY/dlurt972QP uHzN46he0drcIUQEn7Q+Zn4PoJo7kpXnt3Phat5bIhrv39rrBkwSA16i222TwZsYaYcO nYaLXKKgbadiFfXv9/XkoAEOONZqdiHHelOBMBB9FHgENI3rRmYTvFQEMX5k82O6DWWL sDnA== MIME-Version: 1.0 X-Received: by 10.68.189.199 with SMTP id gk7mr28532585pbc.164.1362415047306; Mon, 04 Mar 2013 08:37:27 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:37:27 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:37:27 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 13:37:27 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5954189711756712636==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5954189711756712636== Content-Type: multipart/alternative; boundary=e89a8ff1c8e8ee770a04d71bf8b1 --e89a8ff1c8e8ee770a04d71bf8b1 Content-Type: text/plain; charset=ISO-8859-1 Alright! First question: yes, it does work everytime I start the dom0 with my HD 7950 freshly booted as the secondary VGA (it never worked as primary though). Using windows 7 ultimate 64bits, after rebooting due to windows update, the VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, the cirrus device seems to be okay, the radeon device tells me it co Using Windows XP sp3 I managed to reboot the VM several times and everything worked. On Mar 4, 2013 1:27 PM, "Matthias" wrote: Hi there, I fear you have to be a bit more specific because with only that information, this could be a lot.. But alright, let's start at the beginning: I assume you installed your dom0, installed your windows domU via the vnc vga, then installed latest catalyst drivers and at this point vga passthrough should work.. So now let's assume you have a freshly booted dom0 and try to start your domU. Does vga passthrough works every time on a freshly booted dom0? Lets further assume it have worked the first time.. does it always does not work when booting a second time? What in general happens when you say vga passthrough doesn't work? Do you get a BSOD? or do you get your graphic output on the vnc vga and your main vga has a error 14 or error 43 in device manager? Also, next to distro and kernel information, your domU config would be interesting (especially the acpi, api, pci_whatever parts).. 2013/3/4 Guilherme Suzuki : > Hey matthias, nice to meet you, buddy. > > My problem: sometimes I have to reboot the dom0 (lame) ... --e89a8ff1c8e8ee770a04d71bf8b1 Content-Type: text/html; charset=ISO-8859-1

Alright!

First question: yes, it does work everytime I start the dom0 with my HD 7950 freshly booted as the secondary VGA (it never worked as primary though).

Using windows 7 ultimate 64bits, after rebooting due to windows update, the VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, the cirrus device seems to be okay, the radeon device tells me it co

Using Windows XP sp3 I managed to reboot the VM several times and everything worked.

On Mar 4, 2013 1:27 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi there,

I fear you have to be a bit more specific because with only that
information, this could be a lot..

But alright, let's start at the beginning:

I assume you installed your dom0, installed your windows domU via the
vnc vga, then installed latest catalyst drivers and at this point vga
passthrough should work..

So now let's assume you have a freshly booted dom0 and try to start
your domU. Does vga passthrough works every time on a freshly booted
dom0?
Lets further assume it have worked the first time.. does it always
does not work when booting a second time?
What in general happens when you say vga passthrough doesn't work? Do
you get a BSOD? or do you get your graphic output on the vnc vga and
your main vga has a error 14 or error 43 in device manager?

Also, next to distro and kernel information, your domU config would be
interesting (especially the acpi, api, pci_whatever parts)..

2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Hey matthias, nice to meet you, buddy.
>
> My problem: sometimes I have to reboot the dom0 (lame) ...

--e89a8ff1c8e8ee770a04d71bf8b1-- --===============5954189711756712636== 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 --===============5954189711756712636==-- From xen-users-bounces@lists.xen.org Mon Mar 04 16:40:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:40:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYQE-0008SX-7Y; Mon, 04 Mar 2013 16:39:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYQC-0008SH-H1 for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:39:28 +0000 Received: from [85.158.137.99:18973] by server-15.bemta-3.messagelabs.com id 56/E3-23142-F3EC4315; Mon, 04 Mar 2013 16:39:27 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1362415164!17794787!1 X-Originating-IP: [209.85.210.44] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4939 invoked from network); 4 Mar 2013 16:39:26 -0000 Received: from mail-da0-f44.google.com (HELO mail-da0-f44.google.com) (209.85.210.44) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:39:26 -0000 Received: by mail-da0-f44.google.com with SMTP id z20so2627787dae.17 for ; Mon, 04 Mar 2013 08:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HsLW0PSpRNgAdECpw4xeLdNEqR8vJk1Sxc1dNVC/nD0=; b=HhGF+gVJ8Ue427+Z1umG4lhRa5cHf0mEaLLlaa5zfIqrjKpMIs+zQJunYQIk+bsN8U 7QX2GV6m5X2j8hv37gNVcDqVjNtEyX1uYsq1CzaTkUbXIvGOZEZ2atTnyIAdi1mircnv ERRcPu3n6p21SWO8YwNUcni6UMHwYdjPDz6PbMlheZadN01bwph6uvqSxLMHKsECfPuV 8sHgD1JVti2vFWBtnwkmU8zj/d4QFPUhpRvDpBumIcyuB219kVtw+KSIyrb0/XmONchh lZpXhqDgqRDWn8Woc4E+MhVRLS9mJsldmO5Ud3pwn8qxFnJ3rNSFBHBzhSYK9WXG7pMO FLHw== MIME-Version: 1.0 X-Received: by 10.68.202.3 with SMTP id ke3mr29112455pbc.98.1362415164573; Mon, 04 Mar 2013 08:39:24 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:39:24 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:39:24 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 13:39:24 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5523002999227340754==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5523002999227340754== Content-Type: multipart/alternative; boundary=047d7b15b061ebd05404d71bff1b --047d7b15b061ebd05404d71bff1b Content-Type: text/plain; charset=ISO-8859-1 Sorry (hit send). So, the radeon device tells it couldnt start itself (code 10) and cirrus device take over. On Mar 4, 2013 1:37 PM, "Guilherme Suzuki" wrote: Alright! First question: yes, it does work everytime I start the dom0 with my HD 7950 freshly booted as the secondary VGA (it never worked as primary though). Using windows 7 ultimate 64bits, after rebooting due to windows update, the VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, the cirrus device seems to be okay, the radeon device tells me it co Using Windows XP sp3 I managed to reboot the VM several times and everything worked. > > On Mar 4, 2013 1:27 PM, "Matthias" wrote: > > Hi there, > ... > > > Hey matthias, nice to meet you, buddy. > > > My problem: sometimes I have to reboot the dom0 (lame) ... --047d7b15b061ebd05404d71bff1b Content-Type: text/html; charset=ISO-8859-1

Sorry (hit send).

So, the radeon device tells it couldnt start itself (code 10) and cirrus device take over.

On Mar 4, 2013 1:37 PM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Alright!

First question: yes, it does work everytime I start the dom0 with my HD 7950 freshly booted as the secondary VGA (it never worked as primary though).

Using windows 7 ultimate 64bits, after rebooting due to windows update, the VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, the cirrus device seems to be okay, the radeon device tells me it co

Using Windows XP sp3 I managed to reboot the VM several times and everything worked.


>
> On Mar 4, 2013 1:27 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:
>
> Hi there,
>
...

>
> > Hey matthias, nice to meet you, buddy.
> >

> My problem: sometimes I have to reboot the dom0 (lame) ...

--047d7b15b061ebd05404d71bff1b-- --===============5523002999227340754== 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 --===============5523002999227340754==-- From xen-users-bounces@lists.xen.org Mon Mar 04 16:40:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:40:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYQE-0008SX-7Y; Mon, 04 Mar 2013 16:39:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYQC-0008SH-H1 for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:39:28 +0000 Received: from [85.158.137.99:18973] by server-15.bemta-3.messagelabs.com id 56/E3-23142-F3EC4315; Mon, 04 Mar 2013 16:39:27 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1362415164!17794787!1 X-Originating-IP: [209.85.210.44] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4939 invoked from network); 4 Mar 2013 16:39:26 -0000 Received: from mail-da0-f44.google.com (HELO mail-da0-f44.google.com) (209.85.210.44) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:39:26 -0000 Received: by mail-da0-f44.google.com with SMTP id z20so2627787dae.17 for ; Mon, 04 Mar 2013 08:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HsLW0PSpRNgAdECpw4xeLdNEqR8vJk1Sxc1dNVC/nD0=; b=HhGF+gVJ8Ue427+Z1umG4lhRa5cHf0mEaLLlaa5zfIqrjKpMIs+zQJunYQIk+bsN8U 7QX2GV6m5X2j8hv37gNVcDqVjNtEyX1uYsq1CzaTkUbXIvGOZEZ2atTnyIAdi1mircnv ERRcPu3n6p21SWO8YwNUcni6UMHwYdjPDz6PbMlheZadN01bwph6uvqSxLMHKsECfPuV 8sHgD1JVti2vFWBtnwkmU8zj/d4QFPUhpRvDpBumIcyuB219kVtw+KSIyrb0/XmONchh lZpXhqDgqRDWn8Woc4E+MhVRLS9mJsldmO5Ud3pwn8qxFnJ3rNSFBHBzhSYK9WXG7pMO FLHw== MIME-Version: 1.0 X-Received: by 10.68.202.3 with SMTP id ke3mr29112455pbc.98.1362415164573; Mon, 04 Mar 2013 08:39:24 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:39:24 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 08:39:24 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 13:39:24 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5523002999227340754==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5523002999227340754== Content-Type: multipart/alternative; boundary=047d7b15b061ebd05404d71bff1b --047d7b15b061ebd05404d71bff1b Content-Type: text/plain; charset=ISO-8859-1 Sorry (hit send). So, the radeon device tells it couldnt start itself (code 10) and cirrus device take over. On Mar 4, 2013 1:37 PM, "Guilherme Suzuki" wrote: Alright! First question: yes, it does work everytime I start the dom0 with my HD 7950 freshly booted as the secondary VGA (it never worked as primary though). Using windows 7 ultimate 64bits, after rebooting due to windows update, the VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, the cirrus device seems to be okay, the radeon device tells me it co Using Windows XP sp3 I managed to reboot the VM several times and everything worked. > > On Mar 4, 2013 1:27 PM, "Matthias" wrote: > > Hi there, > ... > > > Hey matthias, nice to meet you, buddy. > > > My problem: sometimes I have to reboot the dom0 (lame) ... --047d7b15b061ebd05404d71bff1b Content-Type: text/html; charset=ISO-8859-1

Sorry (hit send).

So, the radeon device tells it couldnt start itself (code 10) and cirrus device take over.

On Mar 4, 2013 1:37 PM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Alright!

First question: yes, it does work everytime I start the dom0 with my HD 7950 freshly booted as the secondary VGA (it never worked as primary though).

Using windows 7 ultimate 64bits, after rebooting due to windows update, the VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, the cirrus device seems to be okay, the radeon device tells me it co

Using Windows XP sp3 I managed to reboot the VM several times and everything worked.


>
> On Mar 4, 2013 1:27 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:
>
> Hi there,
>
...

>
> > Hey matthias, nice to meet you, buddy.
> >

> My problem: sometimes I have to reboot the dom0 (lame) ...

--047d7b15b061ebd05404d71bff1b-- --===============5523002999227340754== 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 --===============5523002999227340754==-- From xen-users-bounces@lists.xen.org Mon Mar 04 16:43:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:43: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 1UCYU0-0000Ri-AE; Mon, 04 Mar 2013 16:43:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYTy-0000RU-EP for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:43:22 +0000 Received: from [85.158.139.211:7940] by server-5.bemta-5.messagelabs.com id 4F/5B-02762-92FC4315; Mon, 04 Mar 2013 16:43:21 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1362415399!18698808!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11865 invoked from network); 4 Mar 2013 16:43:20 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Mar 2013 16:43:20 -0000 Received: from [201.122.115.101] (port=55062 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UCYTv-0002V3-B0 for xen-users@lists.xen.org; Mon, 04 Mar 2013 10:43:19 -0600 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id F042DA209 for ; Mon, 4 Mar 2013 10:38:38 -0600 (CST) Message-ID: <5134CF25.5010200@ondore.com> Date: Mon, 04 Mar 2013 10:43:17 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <1362396447939-5714617.post@n5.nabble.com> In-Reply-To: <1362396447939-5714617.post@n5.nabble.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Peth0 missing X-BeenThere: xen-users@lists.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 Hello. El 04/03/13 05:27, pkchouhan escribi=F3: > I have installed Xen 4.1.2-2 ubuntu2.6 through Synaptic Manager on > Ubuntu12.04. > > I followed the steps from https://help.ubuntu.com/community/Xen. This tutorial does not mentions peth0 or network-bridge script. Maybe = you are mixing instructions from different tutorials, that applies = different and incompatible approaches? > However, I do not have a peth0, when I issue an "ifconfig -a". Only eth0, > lo and xenbr0 are displayed. This a confusing matter. Maybe this reference might clarify something: http://www.thogan.com/site2/archives/13 The general recommendation is to stop using network-bridge script, and = create the necessary bridge(s) using your OS native tools, just as your = tutorial suggests. In case of Debian or Ubuntu, describe the bridge in = /etc/network/interfaces file. Then the old naming ("eth0" for the bridge = and "peth0" for the physical interface) looses the sense. Keeping the = native descriptive names ("xenbr0" for the bridge and "eth0" for the = physical interface) helps to reduce confusion. In case you still wish, for some reason, to manage your networking = configuration via Xen's tools, it seems like = /etc/xen/scripts/network-bridge script needs to be debugged. Make sure = nobody else is messing with the networking configuration (like = interfaces file) and try to call network-bridge manually. Check the = file's content, it's heavily commented about the usage and syntax. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 16:43:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:43: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 1UCYU0-0000Ri-AE; Mon, 04 Mar 2013 16:43:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYTy-0000RU-EP for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:43:22 +0000 Received: from [85.158.139.211:7940] by server-5.bemta-5.messagelabs.com id 4F/5B-02762-92FC4315; Mon, 04 Mar 2013 16:43:21 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1362415399!18698808!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11865 invoked from network); 4 Mar 2013 16:43:20 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Mar 2013 16:43:20 -0000 Received: from [201.122.115.101] (port=55062 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UCYTv-0002V3-B0 for xen-users@lists.xen.org; Mon, 04 Mar 2013 10:43:19 -0600 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id F042DA209 for ; Mon, 4 Mar 2013 10:38:38 -0600 (CST) Message-ID: <5134CF25.5010200@ondore.com> Date: Mon, 04 Mar 2013 10:43:17 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <1362396447939-5714617.post@n5.nabble.com> In-Reply-To: <1362396447939-5714617.post@n5.nabble.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Peth0 missing X-BeenThere: xen-users@lists.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 Hello. El 04/03/13 05:27, pkchouhan escribi=F3: > I have installed Xen 4.1.2-2 ubuntu2.6 through Synaptic Manager on > Ubuntu12.04. > > I followed the steps from https://help.ubuntu.com/community/Xen. This tutorial does not mentions peth0 or network-bridge script. Maybe = you are mixing instructions from different tutorials, that applies = different and incompatible approaches? > However, I do not have a peth0, when I issue an "ifconfig -a". Only eth0, > lo and xenbr0 are displayed. This a confusing matter. Maybe this reference might clarify something: http://www.thogan.com/site2/archives/13 The general recommendation is to stop using network-bridge script, and = create the necessary bridge(s) using your OS native tools, just as your = tutorial suggests. In case of Debian or Ubuntu, describe the bridge in = /etc/network/interfaces file. Then the old naming ("eth0" for the bridge = and "peth0" for the physical interface) looses the sense. Keeping the = native descriptive names ("xenbr0" for the bridge and "eth0" for the = physical interface) helps to reduce confusion. In case you still wish, for some reason, to manage your networking = configuration via Xen's tools, it seems like = /etc/xen/scripts/network-bridge script needs to be debugged. Make sure = nobody else is messing with the networking configuration (like = interfaces file) and try to call network-bridge manually. Check the = file's content, it's heavily commented about the usage and syntax. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 16:54:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:54: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 1UCYe6-00016s-5k; Mon, 04 Mar 2013 16:53:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYe4-00016l-7B for xen-users@lists.xensource.com; Mon, 04 Mar 2013 16:53:48 +0000 Received: from [85.158.139.211:15092] by server-4.bemta-5.messagelabs.com id 0D/F4-01980-B91D4315; Mon, 04 Mar 2013 16:53:47 +0000 X-Env-Sender: dsmhood@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1362416025!16339446!1 X-Originating-IP: [209.85.128.178] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6018 invoked from network); 4 Mar 2013 16:53:46 -0000 Received: from mail-ve0-f178.google.com (HELO mail-ve0-f178.google.com) (209.85.128.178) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:53:46 -0000 Received: by mail-ve0-f178.google.com with SMTP id db10so4834392veb.23 for ; Mon, 04 Mar 2013 08:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=viDJTcMrV2k9BQOBks+vsMGyZ7xWOEyVPDU4id6Z1To=; b=TmMh3IbRcJUDHJuWDaOhb/bw2p7I3Oii+KAIk5Vq0UQOtvALC7+ZQT9l/K1MFvJAEt g9fgbru9PVp3ccNG3A/5nCR1K0yprh33SY7TIaCNmjCknnk+t3cfVp9LofWBIrKqDkX0 cc1YhvrSTF5JzeuQkmc9N8vXMvmzjlBLRHbn0FpqTT2RQbJOzlSzbtif6mRca/0Iv+Zg y/2vB93b2Y5Fzvg/4J4RA0N8n6l9TJZBD4ZjYZGRe5K8u8CyWZPwLjrSdt1kFm6OH+mu hoLggKMM+9c5gbgP49hOb2gCJNUnFvmuQgHMcxPi6+DfQ5P8l0A1NCUmdn0bIZ4SY7nm v3Aw== MIME-Version: 1.0 X-Received: by 10.52.21.175 with SMTP id w15mr6969645vde.100.1362416025020; Mon, 04 Mar 2013 08:53:45 -0800 (PST) Received: by 10.220.173.130 with HTTP; Mon, 4 Mar 2013 08:53:44 -0800 (PST) In-Reply-To: <1362396447939-5714617.post@n5.nabble.com> References: <1362396447939-5714617.post@n5.nabble.com> Date: Tue, 5 Mar 2013 03:53:44 +1100 Message-ID: From: Daniel Hood To: pkchouhan Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Peth0 missing X-BeenThere: xen-users@lists.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 Is there any reason you need a peth0? Can't you use the bridge named xenbr0 for networking? Regards, Daniel On Mon, Mar 4, 2013 at 10:27 PM, pkchouhan wrote: > I have installed Xen 4.1.2-2 ubuntu2.6 through Synaptic Manager on > Ubuntu12.04. > > I followed the steps from https://help.ubuntu.com/community/Xen. > > However, I do not have a peth0, when I issue an "ifconfig -a". Only eth0, > lo and xenbr0 are displayed. > > I have checked /etc/xen/xend-config.sxp and uncommented "(network-script > network-bridge)". > > Still peth0 is not displayed. > > Thanks for your replies. > > > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Peth0-missing-tp5714617.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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 16:54:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:54: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 1UCYe6-00016s-5k; Mon, 04 Mar 2013 16:53:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYe4-00016l-7B for xen-users@lists.xensource.com; Mon, 04 Mar 2013 16:53:48 +0000 Received: from [85.158.139.211:15092] by server-4.bemta-5.messagelabs.com id 0D/F4-01980-B91D4315; Mon, 04 Mar 2013 16:53:47 +0000 X-Env-Sender: dsmhood@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1362416025!16339446!1 X-Originating-IP: [209.85.128.178] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6018 invoked from network); 4 Mar 2013 16:53:46 -0000 Received: from mail-ve0-f178.google.com (HELO mail-ve0-f178.google.com) (209.85.128.178) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:53:46 -0000 Received: by mail-ve0-f178.google.com with SMTP id db10so4834392veb.23 for ; Mon, 04 Mar 2013 08:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=viDJTcMrV2k9BQOBks+vsMGyZ7xWOEyVPDU4id6Z1To=; b=TmMh3IbRcJUDHJuWDaOhb/bw2p7I3Oii+KAIk5Vq0UQOtvALC7+ZQT9l/K1MFvJAEt g9fgbru9PVp3ccNG3A/5nCR1K0yprh33SY7TIaCNmjCknnk+t3cfVp9LofWBIrKqDkX0 cc1YhvrSTF5JzeuQkmc9N8vXMvmzjlBLRHbn0FpqTT2RQbJOzlSzbtif6mRca/0Iv+Zg y/2vB93b2Y5Fzvg/4J4RA0N8n6l9TJZBD4ZjYZGRe5K8u8CyWZPwLjrSdt1kFm6OH+mu hoLggKMM+9c5gbgP49hOb2gCJNUnFvmuQgHMcxPi6+DfQ5P8l0A1NCUmdn0bIZ4SY7nm v3Aw== MIME-Version: 1.0 X-Received: by 10.52.21.175 with SMTP id w15mr6969645vde.100.1362416025020; Mon, 04 Mar 2013 08:53:45 -0800 (PST) Received: by 10.220.173.130 with HTTP; Mon, 4 Mar 2013 08:53:44 -0800 (PST) In-Reply-To: <1362396447939-5714617.post@n5.nabble.com> References: <1362396447939-5714617.post@n5.nabble.com> Date: Tue, 5 Mar 2013 03:53:44 +1100 Message-ID: From: Daniel Hood To: pkchouhan Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Peth0 missing X-BeenThere: xen-users@lists.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 Is there any reason you need a peth0? Can't you use the bridge named xenbr0 for networking? Regards, Daniel On Mon, Mar 4, 2013 at 10:27 PM, pkchouhan wrote: > I have installed Xen 4.1.2-2 ubuntu2.6 through Synaptic Manager on > Ubuntu12.04. > > I followed the steps from https://help.ubuntu.com/community/Xen. > > However, I do not have a peth0, when I issue an "ifconfig -a". Only eth0, > lo and xenbr0 are displayed. > > I have checked /etc/xen/xend-config.sxp and uncommented "(network-script > network-bridge)". > > Still peth0 is not displayed. > > Thanks for your replies. > > > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/Peth0-missing-tp5714617.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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 16:55:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:55: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 1UCYf7-0001CB-SS; Mon, 04 Mar 2013 16:54:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYf6-0001Bv-9L for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:54:52 +0000 Received: from [85.158.138.51:10491] by server-11.bemta-3.messagelabs.com id F2/99-01263-BD1D4315; Mon, 04 Mar 2013 16:54:51 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1362416086!28491357!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13723 invoked from network); 4 Mar 2013 16:54:46 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:54:46 -0000 Received: by mail-wg0-f51.google.com with SMTP id 8so4228630wgl.18 for ; Mon, 04 Mar 2013 08:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uWnFvk3otsPGY0MOdmqnuXFhKBB9Q4ETpqSBBQtDyC0=; b=p3NOajOEq4ZPGukPu7ndXT8u+f8Zww0FGGw2CFree/Qjr5avhTbPIeFZzB5flunbMZ 5iQ8NAj+GTrAvKMcEP/KijW0NYoD0/w3NPIAEpyB34Fy30Hx1ahetZozPsWNw68+kobo iEZlNCPYmngR/Ymw2CKSW5fzMC2SzJJJZmK3YF/X8Bt3HkP+dlIz5pc1eeG6z35UJfBD GzaKBGByoL0UMZIRK+iCqEQN6u08EV5PlDMlO4c+n4fySU6cmFnJnPy7ADudxyzLsgcI IVCG7AHp6qMKG+MErhr2e0ZjJYvtYpR+qF00mNv+nBvI+Ra1C7Bt3ZQHgfCyj4C9f97Y ja0g== X-Received: by 10.194.172.71 with SMTP id ba7mr24443286wjc.26.1362416085707; Mon, 04 Mar 2013 08:54:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 08:54:25 -0800 (PST) In-Reply-To: References: <201303021602.r22G2nTB013064@wind.enjellic.com> From: Matthias Date: Mon, 4 Mar 2013 17:54:25 +0100 Message-ID: To: greg@enjellic.com Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA passthrough radeon 4850 as primary card X-BeenThere: xen-users@lists.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 Greg, I'm actually pretty impressed by your patch! It didn't worked for me with primary passthrough (boot got stuck at windows loading screen after the first things like boot select displayed on primary card well), but it actually seemed to have fixed my BSOD (the atikmdag.sys 0x0116 one many people have) issue in secondary passthrough I had for a while and therefor did more for my system stability then the last like 200 unstable changesets combined ;) So in my opinion this patch should be cleaned up and definitely be included in xen-unstable (or better to say in xen-qemu) cause it really improves vga passthrough stability, which more and more people using xen for. One issue I had with this patch, though: You do an additional "#include " in pt-graphics.c which actually breaks the stubdom build (which is included when you do a 'make world') because the stubdom build doesn't uses the system's include path but it's own where io.h simply isn't included. I don't know much about the stubdom build process and how to fix this issue but other then this the patch (i had to clean it up a bit but this was only correcting paths for xen-unstable, i can provide my version if you want) seems fine for me. I would really like to see this beeing included in at least the unstable branches as soon as possible :) 2013/3/3 povder : > 2013/3/2 Dr. Greg Wettstein : >> >> We have run thousands of sessions of primary VGA pass-through using >> ATI cards. We currently use stock Windows 7 with no additional >> drivers. >> >> Patches are needed to QEMU in order to support primary pass-through. >> The following URL references patches which will work for the 4.1.x and >> 4.2.x releases: >> >> ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.ati-passthrough.patch >> >> ftp://ftp.enjellic.com/pub/xen/xen-4.2.0.ati-passthrough.patch >> >> The patches can be applied and the updated qemu-dm can be dropped into >> place, canonically in the /usr/lib/xen/bin directory. >> >> The following is a sample configuration: >> --------------------------------------------------------------------------- >> builder='hvm' >> memory = 3072 >> name = "Windows" >> viridian = 1 >> vif = [ 'type=ioemu, bridge=bridge0, model=e1000' ] >> acpi = 1 >> apic = 1 >> disk = [ 'phy:/dev/localvg1/winsnap,hda,w' ] >> boot="c" >> sdl=0 >> vnc=0 >> soundhw='ac97' >> stdvga=1 >> gfx_passthru=1 >> pci=[ '01:00.0', '00:1a.0' ] >> --------------------------------------------------------------------------- >> >> The BDF definitions for the pci pass-through directive are for the ATI >> card and the USB host controller which drives the keyboard and mouse. >> >> The trick to getting this right is to automate the detach and >> re-attachment of the PCI devices to dom0. The following script >> provides a framework for doing this: >> >> ftp://ftp.enjellic.com/pub/xen/run-passthrough >> >> It should be salted according to the flavor of your particular >> installation. Access to the vbetool utility, which most distribution >> include to support suspend/resume, is desirable in order to run the >> BIOS-post initialization functions so the graphics card works properly >> upon return of control to dom0. >> >> You will want to have an SSH session open from an alternate location >> to whatever platform you are testing this all on. It will be the only >> way to control the system if something goes awry during the >> setup/teardown of the pass-through session. >> >> Hope the above is helpful. >> > > Thank you for this valuable information. > > _______________________________________________ > 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 Mar 04 16:55:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 16:55: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 1UCYf7-0001CB-SS; Mon, 04 Mar 2013 16:54:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYf6-0001Bv-9L for xen-users@lists.xen.org; Mon, 04 Mar 2013 16:54:52 +0000 Received: from [85.158.138.51:10491] by server-11.bemta-3.messagelabs.com id F2/99-01263-BD1D4315; Mon, 04 Mar 2013 16:54:51 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1362416086!28491357!1 X-Originating-IP: [74.125.82.51] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13723 invoked from network); 4 Mar 2013 16:54:46 -0000 Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 16:54:46 -0000 Received: by mail-wg0-f51.google.com with SMTP id 8so4228630wgl.18 for ; Mon, 04 Mar 2013 08:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uWnFvk3otsPGY0MOdmqnuXFhKBB9Q4ETpqSBBQtDyC0=; b=p3NOajOEq4ZPGukPu7ndXT8u+f8Zww0FGGw2CFree/Qjr5avhTbPIeFZzB5flunbMZ 5iQ8NAj+GTrAvKMcEP/KijW0NYoD0/w3NPIAEpyB34Fy30Hx1ahetZozPsWNw68+kobo iEZlNCPYmngR/Ymw2CKSW5fzMC2SzJJJZmK3YF/X8Bt3HkP+dlIz5pc1eeG6z35UJfBD GzaKBGByoL0UMZIRK+iCqEQN6u08EV5PlDMlO4c+n4fySU6cmFnJnPy7ADudxyzLsgcI IVCG7AHp6qMKG+MErhr2e0ZjJYvtYpR+qF00mNv+nBvI+Ra1C7Bt3ZQHgfCyj4C9f97Y ja0g== X-Received: by 10.194.172.71 with SMTP id ba7mr24443286wjc.26.1362416085707; Mon, 04 Mar 2013 08:54:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 08:54:25 -0800 (PST) In-Reply-To: References: <201303021602.r22G2nTB013064@wind.enjellic.com> From: Matthias Date: Mon, 4 Mar 2013 17:54:25 +0100 Message-ID: To: greg@enjellic.com Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA passthrough radeon 4850 as primary card X-BeenThere: xen-users@lists.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 Greg, I'm actually pretty impressed by your patch! It didn't worked for me with primary passthrough (boot got stuck at windows loading screen after the first things like boot select displayed on primary card well), but it actually seemed to have fixed my BSOD (the atikmdag.sys 0x0116 one many people have) issue in secondary passthrough I had for a while and therefor did more for my system stability then the last like 200 unstable changesets combined ;) So in my opinion this patch should be cleaned up and definitely be included in xen-unstable (or better to say in xen-qemu) cause it really improves vga passthrough stability, which more and more people using xen for. One issue I had with this patch, though: You do an additional "#include " in pt-graphics.c which actually breaks the stubdom build (which is included when you do a 'make world') because the stubdom build doesn't uses the system's include path but it's own where io.h simply isn't included. I don't know much about the stubdom build process and how to fix this issue but other then this the patch (i had to clean it up a bit but this was only correcting paths for xen-unstable, i can provide my version if you want) seems fine for me. I would really like to see this beeing included in at least the unstable branches as soon as possible :) 2013/3/3 povder : > 2013/3/2 Dr. Greg Wettstein : >> >> We have run thousands of sessions of primary VGA pass-through using >> ATI cards. We currently use stock Windows 7 with no additional >> drivers. >> >> Patches are needed to QEMU in order to support primary pass-through. >> The following URL references patches which will work for the 4.1.x and >> 4.2.x releases: >> >> ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.ati-passthrough.patch >> >> ftp://ftp.enjellic.com/pub/xen/xen-4.2.0.ati-passthrough.patch >> >> The patches can be applied and the updated qemu-dm can be dropped into >> place, canonically in the /usr/lib/xen/bin directory. >> >> The following is a sample configuration: >> --------------------------------------------------------------------------- >> builder='hvm' >> memory = 3072 >> name = "Windows" >> viridian = 1 >> vif = [ 'type=ioemu, bridge=bridge0, model=e1000' ] >> acpi = 1 >> apic = 1 >> disk = [ 'phy:/dev/localvg1/winsnap,hda,w' ] >> boot="c" >> sdl=0 >> vnc=0 >> soundhw='ac97' >> stdvga=1 >> gfx_passthru=1 >> pci=[ '01:00.0', '00:1a.0' ] >> --------------------------------------------------------------------------- >> >> The BDF definitions for the pci pass-through directive are for the ATI >> card and the USB host controller which drives the keyboard and mouse. >> >> The trick to getting this right is to automate the detach and >> re-attachment of the PCI devices to dom0. The following script >> provides a framework for doing this: >> >> ftp://ftp.enjellic.com/pub/xen/run-passthrough >> >> It should be salted according to the flavor of your particular >> installation. Access to the vbetool utility, which most distribution >> include to support suspend/resume, is desirable in order to run the >> BIOS-post initialization functions so the graphics card works properly >> upon return of control to dom0. >> >> You will want to have an SSH session open from an alternate location >> to whatever platform you are testing this all on. It will be the only >> way to control the system if something goes awry during the >> setup/teardown of the pass-through session. >> >> Hope the above is helpful. >> > > Thank you for this valuable information. > > _______________________________________________ > 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 Mar 04 17:07:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 17:07: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 1UCYqy-0001mH-CE; Mon, 04 Mar 2013 17:07:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYqx-0001m7-Au for xen-users@lists.xen.org; Mon, 04 Mar 2013 17:07:07 +0000 Received: from [85.158.137.99:45284] by server-3.bemta-3.messagelabs.com id B9/8B-26934-AB4D4315; Mon, 04 Mar 2013 17:07:06 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1362416825!18078967!1 X-Originating-IP: [209.85.212.181] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12432 invoked from network); 4 Mar 2013 17:07:05 -0000 Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com) (209.85.212.181) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 17:07:05 -0000 Received: by mail-wi0-f181.google.com with SMTP id hm6so2335835wib.14 for ; Mon, 04 Mar 2013 09:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=B1Xydnaj99WxN8Cyf7iCGWanroW8h+OgqWsSvutEclc=; b=IJB2w+jd7OOSbu66MjM0pG8a4K9k2WGWgWjoQ4royAMU3s0CIjsCK+4QGsClLB9n0c apzDd8eGb2zzbuieBepYs2nHs64uJ+ZYUe5HZVv8bV+A+aTEsUc01b7PeqV4FlCgbDom +V5t4SAhKj7A1jP2A2rqPDkVzqR2Mnadq1O2fURuSRWJ1T9pto+cySMIznUjhucv4G8n LtbdHBekfaSIcqvm2AtEsY32Izhk/c6QoZLGKtu8g7M4NHnCAZbaoKi+cZWcFrxmR+2t VNSMcdEv2HkSULPNOKrD4I+dGbP1mujBhNFATKS7wxB+56nqUEH7Fo2S8kkbaG3IZ8RO p9jw== X-Received: by 10.180.183.193 with SMTP id eo1mr12945399wic.19.1362416823636; Mon, 04 Mar 2013 09:07:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 09:06:43 -0800 (PST) In-Reply-To: References: From: Matthias Date: Mon, 4 Mar 2013 18:06:43 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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, good news, since you said your winxp was able to boot with vga passthrough just fine, your FLR seems to work fine and this might 'only' be a driver-related problem. What you can do is deinstall your catalyst drivers. After rebooting, Win7 will fallback on a windows-standard driver for the vga but when it correctly says the vga name (like ATI Radeion HD whatever Series), it actually is falling back to an older catalyst version which is shipped per default with windows. I have found this much more stable on reboots then the newest driver. Also, deinstall Catalyst / Vision control center and at best everything the catalyst installer lets you deinstall. If vga passthrough works without all the drivers and you really want the latest and greatest catalyst, i recommend not using the latest 13-1 because it creates a similar behavior you mentioned on my machine. But catalyst 12-10 seems to work fine, so i would advice you trying that one. If it still doesn't work with deinstalled drivers, we can try a patch i'm currently testing.. But this the patch is somewhat complicated to install, let's stick with the simple things for the moment. Also, your domU config still would be of help ruling out some misconfiguration there.. 2013/3/4 Guilherme Suzuki : > Sorry (hit send). > > So, the radeon device tells it couldnt start itself (code 10) and cirrus > device take over. > > On Mar 4, 2013 1:37 PM, "Guilherme Suzuki" wrote: > > Alright! > > First question: yes, it does work everytime I start the dom0 with my HD 7950 > freshly booted as the secondary VGA (it never worked as primary though). > > Using windows 7 ultimate 64bits, after rebooting due to windows update, the > VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, > the cirrus device seems to be okay, the radeon device tells me it co > > Using Windows XP sp3 I managed to reboot the VM several times and everything > worked. > > >> >> On Mar 4, 2013 1:27 PM, "Matthias" >> wrote: >> >> Hi there, >> > ... > >> >> > Hey matthias, nice to meet you, buddy. >> > > >> My problem: sometimes I have to reboot the dom0 (lame) ... _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 17:07:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 17:07: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 1UCYqy-0001mH-CE; Mon, 04 Mar 2013 17:07:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYqx-0001m7-Au for xen-users@lists.xen.org; Mon, 04 Mar 2013 17:07:07 +0000 Received: from [85.158.137.99:45284] by server-3.bemta-3.messagelabs.com id B9/8B-26934-AB4D4315; Mon, 04 Mar 2013 17:07:06 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1362416825!18078967!1 X-Originating-IP: [209.85.212.181] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12432 invoked from network); 4 Mar 2013 17:07:05 -0000 Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com) (209.85.212.181) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 17:07:05 -0000 Received: by mail-wi0-f181.google.com with SMTP id hm6so2335835wib.14 for ; Mon, 04 Mar 2013 09:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=B1Xydnaj99WxN8Cyf7iCGWanroW8h+OgqWsSvutEclc=; b=IJB2w+jd7OOSbu66MjM0pG8a4K9k2WGWgWjoQ4royAMU3s0CIjsCK+4QGsClLB9n0c apzDd8eGb2zzbuieBepYs2nHs64uJ+ZYUe5HZVv8bV+A+aTEsUc01b7PeqV4FlCgbDom +V5t4SAhKj7A1jP2A2rqPDkVzqR2Mnadq1O2fURuSRWJ1T9pto+cySMIznUjhucv4G8n LtbdHBekfaSIcqvm2AtEsY32Izhk/c6QoZLGKtu8g7M4NHnCAZbaoKi+cZWcFrxmR+2t VNSMcdEv2HkSULPNOKrD4I+dGbP1mujBhNFATKS7wxB+56nqUEH7Fo2S8kkbaG3IZ8RO p9jw== X-Received: by 10.180.183.193 with SMTP id eo1mr12945399wic.19.1362416823636; Mon, 04 Mar 2013 09:07:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 09:06:43 -0800 (PST) In-Reply-To: References: From: Matthias Date: Mon, 4 Mar 2013 18:06:43 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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, good news, since you said your winxp was able to boot with vga passthrough just fine, your FLR seems to work fine and this might 'only' be a driver-related problem. What you can do is deinstall your catalyst drivers. After rebooting, Win7 will fallback on a windows-standard driver for the vga but when it correctly says the vga name (like ATI Radeion HD whatever Series), it actually is falling back to an older catalyst version which is shipped per default with windows. I have found this much more stable on reboots then the newest driver. Also, deinstall Catalyst / Vision control center and at best everything the catalyst installer lets you deinstall. If vga passthrough works without all the drivers and you really want the latest and greatest catalyst, i recommend not using the latest 13-1 because it creates a similar behavior you mentioned on my machine. But catalyst 12-10 seems to work fine, so i would advice you trying that one. If it still doesn't work with deinstalled drivers, we can try a patch i'm currently testing.. But this the patch is somewhat complicated to install, let's stick with the simple things for the moment. Also, your domU config still would be of help ruling out some misconfiguration there.. 2013/3/4 Guilherme Suzuki : > Sorry (hit send). > > So, the radeon device tells it couldnt start itself (code 10) and cirrus > device take over. > > On Mar 4, 2013 1:37 PM, "Guilherme Suzuki" wrote: > > Alright! > > First question: yes, it does work everytime I start the dom0 with my HD 7950 > freshly booted as the secondary VGA (it never worked as primary though). > > Using windows 7 ultimate 64bits, after rebooting due to windows update, the > VGA won't work (only if I reboot dom0 as I said). Reaching the VM with VNC, > the cirrus device seems to be okay, the radeon device tells me it co > > Using Windows XP sp3 I managed to reboot the VM several times and everything > worked. > > >> >> On Mar 4, 2013 1:27 PM, "Matthias" >> wrote: >> >> Hi there, >> > ... > >> >> > Hey matthias, nice to meet you, buddy. >> > > >> My problem: sometimes I have to reboot the dom0 (lame) ... _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 17:15:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 17:15: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 1UCYyj-0002CJ-W5; Mon, 04 Mar 2013 17:15:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYyi-0002C3-SJ for xen-users@lists.xen.org; Mon, 04 Mar 2013 17:15:09 +0000 Received: from [85.158.139.211:56675] by server-14.bemta-5.messagelabs.com id B0/30-13158-C96D4315; Mon, 04 Mar 2013 17:15:08 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1362417304!19493960!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16969 invoked from network); 4 Mar 2013 17:15:06 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 17:15:06 -0000 Received: by mail-pb0-f43.google.com with SMTP id md12so3252934pbc.16 for ; Mon, 04 Mar 2013 09:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iUSV73pbHIAZkTBiyBkOI93NX00kNsM5BWkmdWMV8Sw=; b=aedbD1xVsYTGe8DxMsuvERhig/Zb3BxUAsUVYdMV+tkcNdQzvpx4am2M0W9l1zT4KV /efi4Nc9IWu8VovWArYh+Bko612m5ufLPJPG4hyJYxLPBPWrXOQQiSuk+25dN2OtEW70 f1QgXCebwa4L6+WzerdgQ5D04THum9Hkn2Usc3yWHAXz/rASVkKuzy9OWCR+KwY1FmjB bXaDranJ/JVzA+zirENAEvsIuhA4/4XQSJHulzUPRi9geMO32VSoah4ytfw/rnDQRa6x GpAKE8zp3V8NHnXGypCpjJlJNSxNqrlZeyO7c4lZW1ZmjddZGA0pzHrEq7YvXe/1lPvL n1pA== MIME-Version: 1.0 X-Received: by 10.68.129.9 with SMTP id ns9mr29997802pbb.16.1362417303739; Mon, 04 Mar 2013 09:15:03 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 09:15:03 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 09:15:03 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 14:15:03 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============6747740137957428487==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6747740137957428487== Content-Type: multipart/alternative; boundary=047d7b15afdb6ce3c304d71c7f8f --047d7b15afdb6ce3c304d71c7f8f Content-Type: text/plain; charset=ISO-8859-1 Alright! I'm gonna try catalyst 12-10 (after deinstalling and checking if the passthru works rebooting and so on). I'll send my domU config as soon as I get home. One more question: does it matter if I use intel onboard graphics with the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason primary VGA passthru did not work... Thx, xen guys are awesome! =D On Mar 4, 2013 2:07 PM, "Matthias" wrote: Hi, good news, since you said your winxp was able to boot with vga passthrough just fine, your FLR seems to work fine and this might 'only' be a driver-related problem. What you can do is deinstall your catalyst drivers. After rebooting, Win7 will fallback on a windows-standard driver for the vga but when it correctly says the vga name (like ATI Radeion HD whatever Series), it actually is falling back to an older catalyst version which is shipped per default with windows. I have found this much more stable on reboots then the newest driver. Also, deinstall Catalyst / Vision control center and at best everything the catalyst installer lets you deinstall. If vga passthrough works without all the drivers and you really want the latest and greatest catalyst, i recommend not using the latest 13-1 because it creates a similar behavior you mentioned on my machine. But catalyst 12-10 seems to work fine, so i would advice you trying that one. If it still doesn't work with deinstalled drivers, we can try a patch i'm currently testing.. But this the patch is somewhat complicated to install, let's stick with the simple things for the moment. Also, your domU config still would be of help ruling out some misconfiguration there.. 2013/3/4 Guilherme Suzuki : > Sorry (hit send). > > So, the radeon device tells it couldnt start itself (code 10) and cirrus > d... --047d7b15afdb6ce3c304d71c7f8f Content-Type: text/html; charset=ISO-8859-1

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason primary VGA passthru did not work...

Thx, xen guys are awesome! =D

On Mar 4, 2013 2:07 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch
i'm currently testing.. But this the patch is somewhat complicated to
install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Sorry (hit send).
>
> So, the radeon device tells it couldnt start itself (code 10) and cirrus
> d...

--047d7b15afdb6ce3c304d71c7f8f-- --===============6747740137957428487== 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 --===============6747740137957428487==-- From xen-users-bounces@lists.xen.org Mon Mar 04 17:15:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 17:15: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 1UCYyj-0002CJ-W5; Mon, 04 Mar 2013 17:15:09 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYyi-0002C3-SJ for xen-users@lists.xen.org; Mon, 04 Mar 2013 17:15:09 +0000 Received: from [85.158.139.211:56675] by server-14.bemta-5.messagelabs.com id B0/30-13158-C96D4315; Mon, 04 Mar 2013 17:15:08 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1362417304!19493960!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16969 invoked from network); 4 Mar 2013 17:15:06 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 17:15:06 -0000 Received: by mail-pb0-f43.google.com with SMTP id md12so3252934pbc.16 for ; Mon, 04 Mar 2013 09:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iUSV73pbHIAZkTBiyBkOI93NX00kNsM5BWkmdWMV8Sw=; b=aedbD1xVsYTGe8DxMsuvERhig/Zb3BxUAsUVYdMV+tkcNdQzvpx4am2M0W9l1zT4KV /efi4Nc9IWu8VovWArYh+Bko612m5ufLPJPG4hyJYxLPBPWrXOQQiSuk+25dN2OtEW70 f1QgXCebwa4L6+WzerdgQ5D04THum9Hkn2Usc3yWHAXz/rASVkKuzy9OWCR+KwY1FmjB bXaDranJ/JVzA+zirENAEvsIuhA4/4XQSJHulzUPRi9geMO32VSoah4ytfw/rnDQRa6x GpAKE8zp3V8NHnXGypCpjJlJNSxNqrlZeyO7c4lZW1ZmjddZGA0pzHrEq7YvXe/1lPvL n1pA== MIME-Version: 1.0 X-Received: by 10.68.129.9 with SMTP id ns9mr29997802pbb.16.1362417303739; Mon, 04 Mar 2013 09:15:03 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 09:15:03 -0800 (PST) Received: by 10.68.217.103 with HTTP; Mon, 4 Mar 2013 09:15:03 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 14:15:03 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============6747740137957428487==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6747740137957428487== Content-Type: multipart/alternative; boundary=047d7b15afdb6ce3c304d71c7f8f --047d7b15afdb6ce3c304d71c7f8f Content-Type: text/plain; charset=ISO-8859-1 Alright! I'm gonna try catalyst 12-10 (after deinstalling and checking if the passthru works rebooting and so on). I'll send my domU config as soon as I get home. One more question: does it matter if I use intel onboard graphics with the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason primary VGA passthru did not work... Thx, xen guys are awesome! =D On Mar 4, 2013 2:07 PM, "Matthias" wrote: Hi, good news, since you said your winxp was able to boot with vga passthrough just fine, your FLR seems to work fine and this might 'only' be a driver-related problem. What you can do is deinstall your catalyst drivers. After rebooting, Win7 will fallback on a windows-standard driver for the vga but when it correctly says the vga name (like ATI Radeion HD whatever Series), it actually is falling back to an older catalyst version which is shipped per default with windows. I have found this much more stable on reboots then the newest driver. Also, deinstall Catalyst / Vision control center and at best everything the catalyst installer lets you deinstall. If vga passthrough works without all the drivers and you really want the latest and greatest catalyst, i recommend not using the latest 13-1 because it creates a similar behavior you mentioned on my machine. But catalyst 12-10 seems to work fine, so i would advice you trying that one. If it still doesn't work with deinstalled drivers, we can try a patch i'm currently testing.. But this the patch is somewhat complicated to install, let's stick with the simple things for the moment. Also, your domU config still would be of help ruling out some misconfiguration there.. 2013/3/4 Guilherme Suzuki : > Sorry (hit send). > > So, the radeon device tells it couldnt start itself (code 10) and cirrus > d... --047d7b15afdb6ce3c304d71c7f8f Content-Type: text/html; charset=ISO-8859-1

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason primary VGA passthru did not work...

Thx, xen guys are awesome! =D

On Mar 4, 2013 2:07 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch
i'm currently testing.. But this the patch is somewhat complicated to
install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Sorry (hit send).
>
> So, the radeon device tells it couldnt start itself (code 10) and cirrus
> d...

--047d7b15afdb6ce3c304d71c7f8f-- --===============6747740137957428487== 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 --===============6747740137957428487==-- From xen-users-bounces@lists.xen.org Mon Mar 04 17:24:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 17:24: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 1UCZ6m-0002kS-4m; Mon, 04 Mar 2013 17:23:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCZ6k-0002kA-U5 for xen-users@lists.xen.org; Mon, 04 Mar 2013 17:23:27 +0000 Received: from [85.158.143.99:11849] by server-2.bemta-4.messagelabs.com id 66/A7-12656-E88D4315; Mon, 04 Mar 2013 17:23:26 +0000 X-Env-Sender: fiala@mfiala.net X-Msg-Ref: server-9.tower-216.messagelabs.com!1362417805!30301679!1 X-Originating-IP: [194.79.52.12] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29798 invoked from network); 4 Mar 2013 17:23:25 -0000 Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12) by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 4 Mar 2013 17:23:25 -0000 Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232] helo=[192.168.95.34]) by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UCZ6i-0004k8-Oc for xen-users@lists.xen.org; Mon, 04 Mar 2013 18:23:24 +0100 Message-ID: <5134D887.5010401@mfiala.net> Date: Mon, 04 Mar 2013 18:23:19 +0100 From: Michal Fiala User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: xen-users@lists.xen.org X-Enigmail-Version: 1.5 Subject: [Xen-users] Exactly set dom0/U memory, increase vcpu count X-BeenThere: xen-users@lists.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 hallo, I have updated xen server to xen-4.2.1-r2 xen-tools-4.2.1-r1 kernel gentoo-sources-3.2.39 I have found 2 problems 1) Can not exactly set dom0, domU memory I dedicate 4G of memory to dom0 via kernel parameter: dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin Bud the real total memory is set to 2618M after reboot. I have found article describing this behavior (http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone), so I have run echo $((4*1024*1024)) > /sys/devices/system/xen_memory/xen_memory0/target_kb The total memory was se to 3687M. This is better, but not enough. I have tested kernel 3.7, there is not such problem. I would like to use longterm kernel 3.2 so I would like to stay with 3.2. Similar problem exists with domU, config looks like kernel = '/etc/xen/kernels/linux-3.2.39-gentoo' name = 'test1' memory = '4000' maxmem = '12000' vcpus = '8' cpus = '^0,^1,^2,^3' extra = 'elevator=noop gentoo=nodevfs' root = '/dev/xvda1 ro' disk = [ 'phy:/dev/vg1/test1_root,xvda1,w', 'phy:/dev/vg1/test1_var,xvda2,w', ] vif = [ 'mac=00:16:3e:24:11:38,bridge=br0', ] After boot, test1 domain has 3704M total memory (free -m), xm list test1 shows 4000M. When I increase memory amount via xm mem-set test1 8000, then xm list test1 really shows 8000M, but domU has 7704M total memory (free -m). from xend.log [2013-03-04 18:10:18 4627] DEBUG (XendDomainInfo:1467) Setting memory target of domain test1 (1) to 8000 MiB. 2) I am not able to increase vcpu count to domU. After boot domU test1, it has really 8 vcpus, I am able to decrease vcpus by xm vcpu-set test1 4. Cpus count inside test1 really decreases to 4. Now I would like to increase vcpu count via xm vcpu-list test1 6, but unsuccessfully. rajvir3 configs # xm vcpu-list test1 Name ID VCPU CPU State Time(s) CPU Affinity test1 1 0 15 -b- 3.7 12-23 test1 1 1 23 -b- 2.8 12-23 test1 1 2 18 -b- 1.2 12-23 test1 1 3 20 -b- 1.2 12-23 test1 1 4 16 -b- 1.0 12-23 test1 1 5 12 -b- 3.5 12-23 test1 1 6 19 -b- 0.9 12-23 test1 1 7 14 -b- 0.9 12-23 rajvir3 configs # xm vcpu-set test1 4 rajvir3 configs # xm vcpu-list test1 Name ID VCPU CPU State Time(s) CPU Affinity test1 1 0 15 -b- 3.7 12-23 test1 1 1 23 -b- 2.9 12-23 test1 1 2 18 -b- 1.3 12-23 test1 1 3 20 -b- 1.2 12-23 test1 1 4 - --p 1.0 12-23 test1 1 5 - --p 3.5 12-23 test1 1 6 - --p 1.0 12-23 test1 1 7 - --p 0.9 12-23 rajvir3 configs # xm vcpu-set test1 6 rajvir3 configs # xm vcpu-list test1 Name ID VCPU CPU State Time(s) CPU Affinity test1 1 0 15 -b- 3.8 12-23 test1 1 1 23 -b- 2.9 12-23 test1 1 2 18 -b- 1.3 12-23 test1 1 3 20 -b- 1.3 12-23 test1 1 4 - --p 1.0 12-23 test1 1 5 - --p 3.5 12-23 test1 1 6 - --p 1.0 12-23 test1 1 7 - --p 0.9 12-23 from xend.log [2013-03-04 18:12:58 4627] INFO (XendDomainInfo:1978) Set VCPU count on domain test1 to 4 [2013-03-04 18:14:51 4627] INFO (XendDomainInfo:1978) Set VCPU count on domain test1 to 6 I was not able to increase vcpu count also in kernel 3.7. Where could be the problem? Thanks Michal _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 17:24:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 17:24: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 1UCZ6m-0002kS-4m; Mon, 04 Mar 2013 17:23:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCZ6k-0002kA-U5 for xen-users@lists.xen.org; Mon, 04 Mar 2013 17:23:27 +0000 Received: from [85.158.143.99:11849] by server-2.bemta-4.messagelabs.com id 66/A7-12656-E88D4315; Mon, 04 Mar 2013 17:23:26 +0000 X-Env-Sender: fiala@mfiala.net X-Msg-Ref: server-9.tower-216.messagelabs.com!1362417805!30301679!1 X-Originating-IP: [194.79.52.12] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29798 invoked from network); 4 Mar 2013 17:23:25 -0000 Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12) by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 4 Mar 2013 17:23:25 -0000 Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232] helo=[192.168.95.34]) by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UCZ6i-0004k8-Oc for xen-users@lists.xen.org; Mon, 04 Mar 2013 18:23:24 +0100 Message-ID: <5134D887.5010401@mfiala.net> Date: Mon, 04 Mar 2013 18:23:19 +0100 From: Michal Fiala User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: xen-users@lists.xen.org X-Enigmail-Version: 1.5 Subject: [Xen-users] Exactly set dom0/U memory, increase vcpu count X-BeenThere: xen-users@lists.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 hallo, I have updated xen server to xen-4.2.1-r2 xen-tools-4.2.1-r1 kernel gentoo-sources-3.2.39 I have found 2 problems 1) Can not exactly set dom0, domU memory I dedicate 4G of memory to dom0 via kernel parameter: dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin Bud the real total memory is set to 2618M after reboot. I have found article describing this behavior (http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone), so I have run echo $((4*1024*1024)) > /sys/devices/system/xen_memory/xen_memory0/target_kb The total memory was se to 3687M. This is better, but not enough. I have tested kernel 3.7, there is not such problem. I would like to use longterm kernel 3.2 so I would like to stay with 3.2. Similar problem exists with domU, config looks like kernel = '/etc/xen/kernels/linux-3.2.39-gentoo' name = 'test1' memory = '4000' maxmem = '12000' vcpus = '8' cpus = '^0,^1,^2,^3' extra = 'elevator=noop gentoo=nodevfs' root = '/dev/xvda1 ro' disk = [ 'phy:/dev/vg1/test1_root,xvda1,w', 'phy:/dev/vg1/test1_var,xvda2,w', ] vif = [ 'mac=00:16:3e:24:11:38,bridge=br0', ] After boot, test1 domain has 3704M total memory (free -m), xm list test1 shows 4000M. When I increase memory amount via xm mem-set test1 8000, then xm list test1 really shows 8000M, but domU has 7704M total memory (free -m). from xend.log [2013-03-04 18:10:18 4627] DEBUG (XendDomainInfo:1467) Setting memory target of domain test1 (1) to 8000 MiB. 2) I am not able to increase vcpu count to domU. After boot domU test1, it has really 8 vcpus, I am able to decrease vcpus by xm vcpu-set test1 4. Cpus count inside test1 really decreases to 4. Now I would like to increase vcpu count via xm vcpu-list test1 6, but unsuccessfully. rajvir3 configs # xm vcpu-list test1 Name ID VCPU CPU State Time(s) CPU Affinity test1 1 0 15 -b- 3.7 12-23 test1 1 1 23 -b- 2.8 12-23 test1 1 2 18 -b- 1.2 12-23 test1 1 3 20 -b- 1.2 12-23 test1 1 4 16 -b- 1.0 12-23 test1 1 5 12 -b- 3.5 12-23 test1 1 6 19 -b- 0.9 12-23 test1 1 7 14 -b- 0.9 12-23 rajvir3 configs # xm vcpu-set test1 4 rajvir3 configs # xm vcpu-list test1 Name ID VCPU CPU State Time(s) CPU Affinity test1 1 0 15 -b- 3.7 12-23 test1 1 1 23 -b- 2.9 12-23 test1 1 2 18 -b- 1.3 12-23 test1 1 3 20 -b- 1.2 12-23 test1 1 4 - --p 1.0 12-23 test1 1 5 - --p 3.5 12-23 test1 1 6 - --p 1.0 12-23 test1 1 7 - --p 0.9 12-23 rajvir3 configs # xm vcpu-set test1 6 rajvir3 configs # xm vcpu-list test1 Name ID VCPU CPU State Time(s) CPU Affinity test1 1 0 15 -b- 3.8 12-23 test1 1 1 23 -b- 2.9 12-23 test1 1 2 18 -b- 1.3 12-23 test1 1 3 20 -b- 1.3 12-23 test1 1 4 - --p 1.0 12-23 test1 1 5 - --p 3.5 12-23 test1 1 6 - --p 1.0 12-23 test1 1 7 - --p 0.9 12-23 from xend.log [2013-03-04 18:12:58 4627] INFO (XendDomainInfo:1978) Set VCPU count on domain test1 to 4 [2013-03-04 18:14:51 4627] INFO (XendDomainInfo:1978) Set VCPU count on domain test1 to 6 I was not able to increase vcpu count also in kernel 3.7. Where could be the problem? Thanks Michal _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 18:09:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 18:09: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 1UCZog-0005Lw-D5; Mon, 04 Mar 2013 18:08:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCZod-0005Lh-Vt for xen-users@lists.xen.org; Mon, 04 Mar 2013 18:08:48 +0000 Received: from [85.158.139.211:53248] by server-15.bemta-5.messagelabs.com id E2/E9-22815-F23E4315; Mon, 04 Mar 2013 18:08:47 +0000 X-Env-Sender: jh@excello.cz X-Msg-Ref: server-16.tower-206.messagelabs.com!1362420525!18384677!1 X-Originating-IP: [188.138.126.15] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15366 invoked from network); 4 Mar 2013 18:08:46 -0000 Received: from out2.virusfree.cz (HELO out2.virusfree.cz) (188.138.126.15) by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Mar 2013 18:08:46 -0000 Received: (qmail 25679 invoked by uid 1000); 4 Mar 2013 19:08:45 +0100 Received: from posta.excello.cz by out2 (envelope-from , uid 201) with VF-scanner-2.08VF (www.virusfree.cz | out1.virusfree.cz OUT2 Clear:RC:1(188.138.126.10):SA:0(-10.6/5.0):. Processed in 2.373954 secs); 04 Mar 2013 18:08:45 -0000 X-Spam-Status: No, hits=-10.6 required=5.0 X-Spam-Report: SA TESTS 0.1 MAILBODYHTTPLINK RAW: http:// v body 0.5 WORD_UPGRADE RAW: Including upgrade word -4.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -1.5 INREPLYTO0 INREPLYTO0 -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -2.0 MFH_PKCS7_4 FULL: S/MIME Header -2.0 MFH_PKCS7_5 FULL: S/MIME Header -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=excello.cz; h= date:message-id:from:to:subject:reply-to; q=dns/txt; s=default; t=1362420522; n=Test; bh=fwuGn83giaC9Lfb6CaRGHy5DEOHTuvpDXv6zNx Z+O8g=; b=F7XEcSm0eWkGTqjrge3qnqXVzSypmCANjD4k2waOdti6pwexN1CxQX GOUK2ZRi0PXkALdjGuyrs7x2VW9A4jhhw3Zlo1bU5RXEWgdVQEbRIqldEo9hwvZb +4KYRyEsQX DomainKey-Signature: a=rsa-sha1; c=nofws; d=excello.cz; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type; q=dns; s=default; b=DnwTbTcKCMROOgqKegX792Vvc+ixr JXeiEGwQui4Ecn8ue0XI/CKR5rJuclVUndOzN2GLnHyzZUtQY9EELf7Y3xAt6fTa 2pE1GrIcSHVeWlPU5YXH3/RUutf9V5oGi6X Received: from posta.excello.cz (188.138.126.10) by out2.virusfree.cz with SMTP; 4 Mar 2013 19:08:42 +0100 Received: from [192.168.1.119] (unknown [37.77.238.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by posta.excello.cz (Postfix) with ESMTPSA id 5E87A2C0EB2 for ; Mon, 4 Mar 2013 19:08:38 +0100 (CET) Message-ID: <5134E323.5080506@excello.cz> Date: Mon, 04 Mar 2013 19:08:35 +0100 From: Jan Hejl User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5134D887.5010401@mfiala.net> In-Reply-To: <5134D887.5010401@mfiala.net> Subject: Re: [Xen-users] Exactly set dom0/U memory, increase vcpu count X-BeenThere: xen-users@lists.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="===============1751465906492275811==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============1751465906492275811== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010808000700010802030302" This is a cryptographically signed message in MIME format. --------------ms010808000700010802030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Michal, 1) Could you please post your dom0 kernel config options related to XEN? = Simply with "zgrep XEN /proc/config.gz" or "grep XEN=20 /usr/src/linux/.config" ? 2) Is CONFIG_HOTPLUG_CPU enabled in your kernel image? Thanks Jan On 03/04/2013 06:23 PM, Michal Fiala wrote: > hallo, > > I have updated xen server to > > xen-4.2.1-r2 > xen-tools-4.2.1-r1 > kernel gentoo-sources-3.2.39 > > I have found 2 problems > > 1) Can not exactly set dom0, domU memory > > I dedicate 4G of memory to dom0 via kernel parameter: > > dom0_mem=3D4G,max:4G dom0_max_vcpus=3D4 dom0_vcpus_pin > > Bud the real total memory is set to 2618M after reboot. I have found > article describing this behavior > (http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_N= ot_Gone), > so I have run > > echo $((4*1024*1024)) > /sys/devices/system/xen_memory/xen_memory0/targ= et_kb > > The total memory was se to 3687M. This is better, but not enough. > > I have tested kernel 3.7, there is not such problem. I would like to us= e > longterm kernel 3.2 so I would like to stay with 3.2. > > Similar problem exists with domU, config looks like > > kernel =3D '/etc/xen/kernels/linux-3.2.39-gentoo' > name =3D 'test1' > memory =3D '4000' > maxmem =3D '12000' > vcpus =3D '8' > cpus =3D '^0,^1,^2,^3' > extra =3D 'elevator=3Dnoop gentoo=3Dnodevfs' > root =3D '/dev/xvda1 ro' > disk =3D [ > 'phy:/dev/vg1/test1_root,xvda1,w', > 'phy:/dev/vg1/test1_var,xvda2,w', > ] > vif =3D [ > 'mac=3D00:16:3e:24:11:38,bridge=3Dbr0', > ] > > After boot, test1 domain has 3704M total memory (free -m), xm list test= 1 > shows 4000M. > > When I increase memory amount via xm mem-set test1 8000, then xm list > test1 really shows 8000M, but domU has 7704M total memory (free -m). > > from xend.log > [2013-03-04 18:10:18 4627] DEBUG (XendDomainInfo:1467) Setting memory > target of domain test1 (1) to 8000 MiB. > > 2) I am not able to increase vcpu count to domU. > After boot domU test1, it has really 8 vcpus, I am able to decrease > vcpus by xm vcpu-set test1 4. Cpus count inside test1 really decreases > to 4. Now I would like to increase vcpu count via xm vcpu-list test1 6,= > but unsuccessfully. > > rajvir3 configs # xm vcpu-list test1 > Name ID VCPU CPU State Time(s) CPU > Affinity > test1 1 0 15 -b- 3.7 12-2= 3 > test1 1 1 23 -b- 2.8 12-2= 3 > test1 1 2 18 -b- 1.2 12-2= 3 > test1 1 3 20 -b- 1.2 12-2= 3 > test1 1 4 16 -b- 1.0 12-2= 3 > test1 1 5 12 -b- 3.5 12-2= 3 > test1 1 6 19 -b- 0.9 12-2= 3 > test1 1 7 14 -b- 0.9 12-2= 3 > > rajvir3 configs # xm vcpu-set test1 4 > > rajvir3 configs # xm vcpu-list test1 > Name ID VCPU CPU State Time(s) CPU > Affinity > test1 1 0 15 -b- 3.7 12-2= 3 > test1 1 1 23 -b- 2.9 12-2= 3 > test1 1 2 18 -b- 1.3 12-2= 3 > test1 1 3 20 -b- 1.2 12-2= 3 > test1 1 4 - --p 1.0 12-2= 3 > test1 1 5 - --p 3.5 12-2= 3 > test1 1 6 - --p 1.0 12-2= 3 > test1 1 7 - --p 0.9 12-2= 3 > > rajvir3 configs # xm vcpu-set test1 6 > > rajvir3 configs # xm vcpu-list test1 > Name ID VCPU CPU State Time(s) CPU > Affinity > test1 1 0 15 -b- 3.8 12-2= 3 > test1 1 1 23 -b- 2.9 12-2= 3 > test1 1 2 18 -b- 1.3 12-2= 3 > test1 1 3 20 -b- 1.3 12-2= 3 > test1 1 4 - --p 1.0 12-2= 3 > test1 1 5 - --p 3.5 12-2= 3 > test1 1 6 - --p 1.0 12-2= 3 > test1 1 7 - --p 0.9 12-2= 3 > > from xend.log > > [2013-03-04 18:12:58 4627] INFO (XendDomainInfo:1978) Set VCPU count on= > domain test1 to 4 > [2013-03-04 18:14:51 4627] INFO (XendDomainInfo:1978) Set VCPU count on= > domain test1 to 6 > > I was not able to increase vcpu count also in kernel 3.7. > > Where could be the problem? > > Thanks > > Michal > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --------------ms010808000700010802030302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMOzCC BUUwggQtoAMCAQICEBT4W4g+LpxVCvoVs2BeaAUwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjA4MjEwMDAwMDBaFw0xMzA4MjEyMzU5NTlaMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMREwDwYDVQQDFAhKYW4gSGVqbDEc MBoGCSqGSIb3DQEJARYNamhAZXhjZWxsby5jejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKZYfrag8UJ0JgrVdujHsmcxbgdXnbVZuWxIuJ6rY9Y3JBUfOTRODhMkaoxQDYTq pzG/JUNNZW1nF6QIYuPMcwzhEWAfoWhnhvm03KohNVKNID3A1SghW8bV3mRtaoyFHSIfiiFF DH7+BvSsIXP8slIzBi4wXvidDw1ui0MVA6Wy0mSSHLZdGHOpO8CswWXK6YQ87nG7a28QTCi6 HycFwbdhsPm4NADD7zrqnRkLVmWdnZWpA6CHkngGuR+0LpovAlmyiKUMLK4GkMOIMz24Pawk icIGI/AqrUmYpj8IwM4F0BGI1O1rZSUK72SV11eRuriqskzpcY1FVW0VmR1XNg0CAwEAAaOB 0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYw FAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRp Z2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNybDANBgkq hkiG9w0BAQUFAAOCAQEAh/RUK66OYfOqJdnHSSP5U+FpIFb+Wd6Xb03Yca7Shq3G1xHdKosm WK8+MAYg1FwlpVLf3Y7lg5QbPoplGchUC5QFa1xzJc88Pxrd0kYIDdshxd2HyNWhBCLdKPPU iU10VzwFZ6mR7/nD0pWv0mxyrNd+f+BU7mM1mOQsr+GvHpWCStlPxUrQBXKKH1hcCS8NWIXU M3WXQSXWyYCEhmu0/m220BPFRjJL39nwCALgZ+LlDJHaM65hmZ4VXO75YWWjOHpuJMNJZE65 nhXX2x5my+TzazAe9z5Xxly3ZWZ2iCQP6GbGduGMGVkS2V8Y6fpFUEcqx3nucCqM7Jnf5Sfn xjCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoX DTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2Yg dXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpM dD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlW CjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+ n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUm pSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOCArkwggK1 MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBWMCgGCCsG AQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4aHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEM BGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4myms SweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3 DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNa Z/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ik NXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn22 2egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW +JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIE +TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMwIQFPhbiD4unFUK+hWzYF5oBTAJBgUrDgMCGgUAoIIC2zAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAzMDQxODA4MzVa MCMGCSqGSIb3DQEJBDEWBBTdSX3WpgODkfFwAI2aUrRfFgZBQDBsBgkqhkiG9w0BCQ8xXzBd MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5v dCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJz Y3JpYmVyIENBIC0gRzMCEBT4W4g+LpxVCvoVs2BeaAUwggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEczAhAU+FuIPi6cVQr6FbNgXmgFMA0GCSqGSIb3DQEBAQUABIIBADHfeVcUd1JQ NV0JAs0cSZknbHxdjvryGovViBtfn8t7uPBwB+VvfMIgyG+bvho5LHzppx00O2H7czeAYQjw adbiz/66aL933v1ih0gfjMI65myin/EC1j61MEdh74Ak17R4HHPTMzkh/yf8Fo5Z/y+fjDFi SbGNcZmzVbblQ8Pghgp+RxG79WBgfpKAuwnD2pa6jB+keEt8+La/THu8svflDbffXH92EhQX FFvVIOWnneqZs7LBXKDHvQ8BTcYYNxyC7PtAZ3qD+UcgHSAn4Aq/GuseC6OpxZ2lwwf19Uoj cW27Z5Tiw3oLO3bG5RY9mK3NCbW/E/uOCEBmZRMx5moAAAAAAAA= --------------ms010808000700010802030302-- --===============1751465906492275811== 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 --===============1751465906492275811==-- From xen-users-bounces@lists.xen.org Mon Mar 04 18:09:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 18:09: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 1UCZog-0005Lw-D5; Mon, 04 Mar 2013 18:08:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCZod-0005Lh-Vt for xen-users@lists.xen.org; Mon, 04 Mar 2013 18:08:48 +0000 Received: from [85.158.139.211:53248] by server-15.bemta-5.messagelabs.com id E2/E9-22815-F23E4315; Mon, 04 Mar 2013 18:08:47 +0000 X-Env-Sender: jh@excello.cz X-Msg-Ref: server-16.tower-206.messagelabs.com!1362420525!18384677!1 X-Originating-IP: [188.138.126.15] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG, UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15366 invoked from network); 4 Mar 2013 18:08:46 -0000 Received: from out2.virusfree.cz (HELO out2.virusfree.cz) (188.138.126.15) by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Mar 2013 18:08:46 -0000 Received: (qmail 25679 invoked by uid 1000); 4 Mar 2013 19:08:45 +0100 Received: from posta.excello.cz by out2 (envelope-from , uid 201) with VF-scanner-2.08VF (www.virusfree.cz | out1.virusfree.cz OUT2 Clear:RC:1(188.138.126.10):SA:0(-10.6/5.0):. Processed in 2.373954 secs); 04 Mar 2013 18:08:45 -0000 X-Spam-Status: No, hits=-10.6 required=5.0 X-Spam-Report: SA TESTS 0.1 MAILBODYHTTPLINK RAW: http:// v body 0.5 WORD_UPGRADE RAW: Including upgrade word -4.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -1.5 INREPLYTO0 INREPLYTO0 -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -2.0 MFH_PKCS7_4 FULL: S/MIME Header -2.0 MFH_PKCS7_5 FULL: S/MIME Header -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=excello.cz; h= date:message-id:from:to:subject:reply-to; q=dns/txt; s=default; t=1362420522; n=Test; bh=fwuGn83giaC9Lfb6CaRGHy5DEOHTuvpDXv6zNx Z+O8g=; b=F7XEcSm0eWkGTqjrge3qnqXVzSypmCANjD4k2waOdti6pwexN1CxQX GOUK2ZRi0PXkALdjGuyrs7x2VW9A4jhhw3Zlo1bU5RXEWgdVQEbRIqldEo9hwvZb +4KYRyEsQX DomainKey-Signature: a=rsa-sha1; c=nofws; d=excello.cz; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type; q=dns; s=default; b=DnwTbTcKCMROOgqKegX792Vvc+ixr JXeiEGwQui4Ecn8ue0XI/CKR5rJuclVUndOzN2GLnHyzZUtQY9EELf7Y3xAt6fTa 2pE1GrIcSHVeWlPU5YXH3/RUutf9V5oGi6X Received: from posta.excello.cz (188.138.126.10) by out2.virusfree.cz with SMTP; 4 Mar 2013 19:08:42 +0100 Received: from [192.168.1.119] (unknown [37.77.238.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by posta.excello.cz (Postfix) with ESMTPSA id 5E87A2C0EB2 for ; Mon, 4 Mar 2013 19:08:38 +0100 (CET) Message-ID: <5134E323.5080506@excello.cz> Date: Mon, 04 Mar 2013 19:08:35 +0100 From: Jan Hejl User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5134D887.5010401@mfiala.net> In-Reply-To: <5134D887.5010401@mfiala.net> Subject: Re: [Xen-users] Exactly set dom0/U memory, increase vcpu count X-BeenThere: xen-users@lists.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="===============1751465906492275811==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a cryptographically signed message in MIME format. --===============1751465906492275811== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010808000700010802030302" This is a cryptographically signed message in MIME format. --------------ms010808000700010802030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Michal, 1) Could you please post your dom0 kernel config options related to XEN? = Simply with "zgrep XEN /proc/config.gz" or "grep XEN=20 /usr/src/linux/.config" ? 2) Is CONFIG_HOTPLUG_CPU enabled in your kernel image? Thanks Jan On 03/04/2013 06:23 PM, Michal Fiala wrote: > hallo, > > I have updated xen server to > > xen-4.2.1-r2 > xen-tools-4.2.1-r1 > kernel gentoo-sources-3.2.39 > > I have found 2 problems > > 1) Can not exactly set dom0, domU memory > > I dedicate 4G of memory to dom0 via kernel parameter: > > dom0_mem=3D4G,max:4G dom0_max_vcpus=3D4 dom0_vcpus_pin > > Bud the real total memory is set to 2618M after reboot. I have found > article describing this behavior > (http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_N= ot_Gone), > so I have run > > echo $((4*1024*1024)) > /sys/devices/system/xen_memory/xen_memory0/targ= et_kb > > The total memory was se to 3687M. This is better, but not enough. > > I have tested kernel 3.7, there is not such problem. I would like to us= e > longterm kernel 3.2 so I would like to stay with 3.2. > > Similar problem exists with domU, config looks like > > kernel =3D '/etc/xen/kernels/linux-3.2.39-gentoo' > name =3D 'test1' > memory =3D '4000' > maxmem =3D '12000' > vcpus =3D '8' > cpus =3D '^0,^1,^2,^3' > extra =3D 'elevator=3Dnoop gentoo=3Dnodevfs' > root =3D '/dev/xvda1 ro' > disk =3D [ > 'phy:/dev/vg1/test1_root,xvda1,w', > 'phy:/dev/vg1/test1_var,xvda2,w', > ] > vif =3D [ > 'mac=3D00:16:3e:24:11:38,bridge=3Dbr0', > ] > > After boot, test1 domain has 3704M total memory (free -m), xm list test= 1 > shows 4000M. > > When I increase memory amount via xm mem-set test1 8000, then xm list > test1 really shows 8000M, but domU has 7704M total memory (free -m). > > from xend.log > [2013-03-04 18:10:18 4627] DEBUG (XendDomainInfo:1467) Setting memory > target of domain test1 (1) to 8000 MiB. > > 2) I am not able to increase vcpu count to domU. > After boot domU test1, it has really 8 vcpus, I am able to decrease > vcpus by xm vcpu-set test1 4. Cpus count inside test1 really decreases > to 4. Now I would like to increase vcpu count via xm vcpu-list test1 6,= > but unsuccessfully. > > rajvir3 configs # xm vcpu-list test1 > Name ID VCPU CPU State Time(s) CPU > Affinity > test1 1 0 15 -b- 3.7 12-2= 3 > test1 1 1 23 -b- 2.8 12-2= 3 > test1 1 2 18 -b- 1.2 12-2= 3 > test1 1 3 20 -b- 1.2 12-2= 3 > test1 1 4 16 -b- 1.0 12-2= 3 > test1 1 5 12 -b- 3.5 12-2= 3 > test1 1 6 19 -b- 0.9 12-2= 3 > test1 1 7 14 -b- 0.9 12-2= 3 > > rajvir3 configs # xm vcpu-set test1 4 > > rajvir3 configs # xm vcpu-list test1 > Name ID VCPU CPU State Time(s) CPU > Affinity > test1 1 0 15 -b- 3.7 12-2= 3 > test1 1 1 23 -b- 2.9 12-2= 3 > test1 1 2 18 -b- 1.3 12-2= 3 > test1 1 3 20 -b- 1.2 12-2= 3 > test1 1 4 - --p 1.0 12-2= 3 > test1 1 5 - --p 3.5 12-2= 3 > test1 1 6 - --p 1.0 12-2= 3 > test1 1 7 - --p 0.9 12-2= 3 > > rajvir3 configs # xm vcpu-set test1 6 > > rajvir3 configs # xm vcpu-list test1 > Name ID VCPU CPU State Time(s) CPU > Affinity > test1 1 0 15 -b- 3.8 12-2= 3 > test1 1 1 23 -b- 2.9 12-2= 3 > test1 1 2 18 -b- 1.3 12-2= 3 > test1 1 3 20 -b- 1.3 12-2= 3 > test1 1 4 - --p 1.0 12-2= 3 > test1 1 5 - --p 3.5 12-2= 3 > test1 1 6 - --p 1.0 12-2= 3 > test1 1 7 - --p 0.9 12-2= 3 > > from xend.log > > [2013-03-04 18:12:58 4627] INFO (XendDomainInfo:1978) Set VCPU count on= > domain test1 to 4 > [2013-03-04 18:14:51 4627] INFO (XendDomainInfo:1978) Set VCPU count on= > domain test1 to 6 > > I was not able to increase vcpu count also in kernel 3.7. > > Where could be the problem? > > Thanks > > Michal > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --------------ms010808000700010802030302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMOzCC BUUwggQtoAMCAQICEBT4W4g+LpxVCvoVs2BeaAUwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjA4MjEwMDAwMDBaFw0xMzA4MjEyMzU5NTlaMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMREwDwYDVQQDFAhKYW4gSGVqbDEc MBoGCSqGSIb3DQEJARYNamhAZXhjZWxsby5jejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKZYfrag8UJ0JgrVdujHsmcxbgdXnbVZuWxIuJ6rY9Y3JBUfOTRODhMkaoxQDYTq pzG/JUNNZW1nF6QIYuPMcwzhEWAfoWhnhvm03KohNVKNID3A1SghW8bV3mRtaoyFHSIfiiFF DH7+BvSsIXP8slIzBi4wXvidDw1ui0MVA6Wy0mSSHLZdGHOpO8CswWXK6YQ87nG7a28QTCi6 HycFwbdhsPm4NADD7zrqnRkLVmWdnZWpA6CHkngGuR+0LpovAlmyiKUMLK4GkMOIMz24Pawk icIGI/AqrUmYpj8IwM4F0BGI1O1rZSUK72SV11eRuriqskzpcY1FVW0VmR1XNg0CAwEAAaOB 0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYw FAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRp Z2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNybDANBgkq hkiG9w0BAQUFAAOCAQEAh/RUK66OYfOqJdnHSSP5U+FpIFb+Wd6Xb03Yca7Shq3G1xHdKosm WK8+MAYg1FwlpVLf3Y7lg5QbPoplGchUC5QFa1xzJc88Pxrd0kYIDdshxd2HyNWhBCLdKPPU iU10VzwFZ6mR7/nD0pWv0mxyrNd+f+BU7mM1mOQsr+GvHpWCStlPxUrQBXKKH1hcCS8NWIXU M3WXQSXWyYCEhmu0/m220BPFRjJL39nwCALgZ+LlDJHaM65hmZ4VXO75YWWjOHpuJMNJZE65 nhXX2x5my+TzazAe9z5Xxly3ZWZ2iCQP6GbGduGMGVkS2V8Y6fpFUEcqx3nucCqM7Jnf5Sfn xjCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoX DTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5j LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2Yg dXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpM dD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlW CjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+ n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUm pSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOCArkwggK1 MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBWMCgGCCsG AQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4aHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEM BGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4myms SweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREE JzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3 DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNa Z/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ik NXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn22 2egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW +JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIE +TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMwIQFPhbiD4unFUK+hWzYF5oBTAJBgUrDgMCGgUAoIIC2zAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAzMDQxODA4MzVa MCMGCSqGSIb3DQEJBDEWBBTdSX3WpgODkfFwAI2aUrRfFgZBQDBsBgkqhkiG9w0BCQ8xXzBd MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5v dCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJz Y3JpYmVyIENBIC0gRzMCEBT4W4g+LpxVCvoVs2BeaAUwggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6 Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEczAhAU+FuIPi6cVQr6FbNgXmgFMA0GCSqGSIb3DQEBAQUABIIBADHfeVcUd1JQ NV0JAs0cSZknbHxdjvryGovViBtfn8t7uPBwB+VvfMIgyG+bvho5LHzppx00O2H7czeAYQjw adbiz/66aL933v1ih0gfjMI65myin/EC1j61MEdh74Ak17R4HHPTMzkh/yf8Fo5Z/y+fjDFi SbGNcZmzVbblQ8Pghgp+RxG79WBgfpKAuwnD2pa6jB+keEt8+La/THu8svflDbffXH92EhQX FFvVIOWnneqZs7LBXKDHvQ8BTcYYNxyC7PtAZ3qD+UcgHSAn4Aq/GuseC6OpxZ2lwwf19Uoj cW27Z5Tiw3oLO3bG5RY9mK3NCbW/E/uOCEBmZRMx5moAAAAAAAA= --------------ms010808000700010802030302-- --===============1751465906492275811== 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 --===============1751465906492275811==-- From xen-users-bounces@lists.xen.org Mon Mar 04 18:27:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 18:27: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 1UCa6G-0005tP-0E; Mon, 04 Mar 2013 18:27:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCa6E-0005tE-8g for xen-users@lists.xen.org; Mon, 04 Mar 2013 18:26:58 +0000 Received: from [85.158.143.99:17747] by server-2.bemta-4.messagelabs.com id C2/1C-12656-177E4315; Mon, 04 Mar 2013 18:26:57 +0000 X-Env-Sender: fiala@mfiala.net X-Msg-Ref: server-12.tower-216.messagelabs.com!1362421616!24976346!1 X-Originating-IP: [194.79.52.12] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5955 invoked from network); 4 Mar 2013 18:26:56 -0000 Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 4 Mar 2013 18:26:56 -0000 Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232] helo=[192.168.95.34]) by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UCa5h-0008Iz-1v; Mon, 04 Mar 2013 19:26:25 +0100 Message-ID: <5134E74B.6020409@mfiala.net> Date: Mon, 04 Mar 2013 19:26:19 +0100 From: Michal Fiala User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jan Hejl References: <5134D887.5010401@mfiala.net> <5134E323.5080506@excello.cz> In-Reply-To: <5134E323.5080506@excello.cz> X-Enigmail-Version: 1.5 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Exactly set dom0/U memory, increase vcpu count X-BeenThere: xen-users@lists.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 03/04/2013 07:08 PM, Jan Hejl wrote: > Hi Michal, Hi > > 1) Could you please post your dom0 kernel config options related to XEN? > Simply with "zgrep XEN /proc/config.gz" or "grep XEN > /usr/src/linux/.config" ? rajvir3 dom0 # grep XEN .config CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=128 CONFIG_XEN_SAVE_RESTORE=y # CONFIG_XEN_DEBUG_FS is not set CONFIG_PCI_XEN=y CONFIG_XEN_PCIDEV_FRONTEND=y CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_XEN_BLKDEV_BACKEND=y CONFIG_XEN_NETDEV_FRONTEND=y CONFIG_XEN_NETDEV_BACKEND=y CONFIG_HVC_XEN=y # CONFIG_XEN_WDT is not set CONFIG_XEN_BALLOON=y CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=y CONFIG_XEN_BACKEND=y CONFIG_XENFS=y CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_XEN_XENBUS_FRONTEND=y CONFIG_XEN_GNTDEV=m CONFIG_XEN_GRANT_DEV_ALLOC=m CONFIG_SWIOTLB_XEN=y CONFIG_XEN_PCIDEV_BACKEND=m > > 2) Is CONFIG_HOTPLUG_CPU enabled in your kernel image? Yes rajvir3 dom0 # grep CONFIG_HOTPLUG_CPU .config CONFIG_HOTPLUG_CPU=y Michal > > Thanks > Jan > > On 03/04/2013 06:23 PM, Michal Fiala wrote: >> hallo, >> >> I have updated xen server to >> >> xen-4.2.1-r2 >> xen-tools-4.2.1-r1 >> kernel gentoo-sources-3.2.39 >> >> I have found 2 problems >> >> 1) Can not exactly set dom0, domU memory >> >> I dedicate 4G of memory to dom0 via kernel parameter: >> >> dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin >> >> Bud the real total memory is set to 2618M after reboot. I have found >> article describing this behavior >> (http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone), >> >> so I have run >> >> echo $((4*1024*1024)) > >> /sys/devices/system/xen_memory/xen_memory0/target_kb >> >> The total memory was se to 3687M. This is better, but not enough. >> >> I have tested kernel 3.7, there is not such problem. I would like to use >> longterm kernel 3.2 so I would like to stay with 3.2. >> >> Similar problem exists with domU, config looks like >> >> kernel = '/etc/xen/kernels/linux-3.2.39-gentoo' >> name = 'test1' >> memory = '4000' >> maxmem = '12000' >> vcpus = '8' >> cpus = '^0,^1,^2,^3' >> extra = 'elevator=noop gentoo=nodevfs' >> root = '/dev/xvda1 ro' >> disk = [ >> 'phy:/dev/vg1/test1_root,xvda1,w', >> 'phy:/dev/vg1/test1_var,xvda2,w', >> ] >> vif = [ >> 'mac=00:16:3e:24:11:38,bridge=br0', >> ] >> >> After boot, test1 domain has 3704M total memory (free -m), xm list test1 >> shows 4000M. >> >> When I increase memory amount via xm mem-set test1 8000, then xm list >> test1 really shows 8000M, but domU has 7704M total memory (free -m). >> >> from xend.log >> [2013-03-04 18:10:18 4627] DEBUG (XendDomainInfo:1467) Setting memory >> target of domain test1 (1) to 8000 MiB. >> >> 2) I am not able to increase vcpu count to domU. >> After boot domU test1, it has really 8 vcpus, I am able to decrease >> vcpus by xm vcpu-set test1 4. Cpus count inside test1 really decreases >> to 4. Now I would like to increase vcpu count via xm vcpu-list test1 6, >> but unsuccessfully. >> >> rajvir3 configs # xm vcpu-list test1 >> Name ID VCPU CPU State Time(s) CPU >> Affinity >> test1 1 0 15 -b- 3.7 12-23 >> test1 1 1 23 -b- 2.8 12-23 >> test1 1 2 18 -b- 1.2 12-23 >> test1 1 3 20 -b- 1.2 12-23 >> test1 1 4 16 -b- 1.0 12-23 >> test1 1 5 12 -b- 3.5 12-23 >> test1 1 6 19 -b- 0.9 12-23 >> test1 1 7 14 -b- 0.9 12-23 >> >> rajvir3 configs # xm vcpu-set test1 4 >> >> rajvir3 configs # xm vcpu-list test1 >> Name ID VCPU CPU State Time(s) CPU >> Affinity >> test1 1 0 15 -b- 3.7 12-23 >> test1 1 1 23 -b- 2.9 12-23 >> test1 1 2 18 -b- 1.3 12-23 >> test1 1 3 20 -b- 1.2 12-23 >> test1 1 4 - --p 1.0 12-23 >> test1 1 5 - --p 3.5 12-23 >> test1 1 6 - --p 1.0 12-23 >> test1 1 7 - --p 0.9 12-23 >> >> rajvir3 configs # xm vcpu-set test1 6 >> >> rajvir3 configs # xm vcpu-list test1 >> Name ID VCPU CPU State Time(s) CPU >> Affinity >> test1 1 0 15 -b- 3.8 12-23 >> test1 1 1 23 -b- 2.9 12-23 >> test1 1 2 18 -b- 1.3 12-23 >> test1 1 3 20 -b- 1.3 12-23 >> test1 1 4 - --p 1.0 12-23 >> test1 1 5 - --p 3.5 12-23 >> test1 1 6 - --p 1.0 12-23 >> test1 1 7 - --p 0.9 12-23 >> >> from xend.log >> >> [2013-03-04 18:12:58 4627] INFO (XendDomainInfo:1978) Set VCPU count on >> domain test1 to 4 >> [2013-03-04 18:14:51 4627] INFO (XendDomainInfo:1978) Set VCPU count on >> domain test1 to 6 >> >> I was not able to increase vcpu count also in kernel 3.7. >> >> Where could be the problem? >> >> Thanks >> >> Michal >> >> _______________________________________________ >> 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 > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 18:27:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 18:27: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 1UCa6G-0005tP-0E; Mon, 04 Mar 2013 18:27:00 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCa6E-0005tE-8g for xen-users@lists.xen.org; Mon, 04 Mar 2013 18:26:58 +0000 Received: from [85.158.143.99:17747] by server-2.bemta-4.messagelabs.com id C2/1C-12656-177E4315; Mon, 04 Mar 2013 18:26:57 +0000 X-Env-Sender: fiala@mfiala.net X-Msg-Ref: server-12.tower-216.messagelabs.com!1362421616!24976346!1 X-Originating-IP: [194.79.52.12] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5955 invoked from network); 4 Mar 2013 18:26:56 -0000 Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 4 Mar 2013 18:26:56 -0000 Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232] helo=[192.168.95.34]) by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UCa5h-0008Iz-1v; Mon, 04 Mar 2013 19:26:25 +0100 Message-ID: <5134E74B.6020409@mfiala.net> Date: Mon, 04 Mar 2013 19:26:19 +0100 From: Michal Fiala User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jan Hejl References: <5134D887.5010401@mfiala.net> <5134E323.5080506@excello.cz> In-Reply-To: <5134E323.5080506@excello.cz> X-Enigmail-Version: 1.5 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Exactly set dom0/U memory, increase vcpu count X-BeenThere: xen-users@lists.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 03/04/2013 07:08 PM, Jan Hejl wrote: > Hi Michal, Hi > > 1) Could you please post your dom0 kernel config options related to XEN? > Simply with "zgrep XEN /proc/config.gz" or "grep XEN > /usr/src/linux/.config" ? rajvir3 dom0 # grep XEN .config CONFIG_XEN=y CONFIG_XEN_DOM0=y CONFIG_XEN_PRIVILEGED_GUEST=y CONFIG_XEN_PVHVM=y CONFIG_XEN_MAX_DOMAIN_MEMORY=128 CONFIG_XEN_SAVE_RESTORE=y # CONFIG_XEN_DEBUG_FS is not set CONFIG_PCI_XEN=y CONFIG_XEN_PCIDEV_FRONTEND=y CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_XEN_BLKDEV_BACKEND=y CONFIG_XEN_NETDEV_FRONTEND=y CONFIG_XEN_NETDEV_BACKEND=y CONFIG_HVC_XEN=y # CONFIG_XEN_WDT is not set CONFIG_XEN_BALLOON=y CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=y CONFIG_XEN_BACKEND=y CONFIG_XENFS=y CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_XEN_XENBUS_FRONTEND=y CONFIG_XEN_GNTDEV=m CONFIG_XEN_GRANT_DEV_ALLOC=m CONFIG_SWIOTLB_XEN=y CONFIG_XEN_PCIDEV_BACKEND=m > > 2) Is CONFIG_HOTPLUG_CPU enabled in your kernel image? Yes rajvir3 dom0 # grep CONFIG_HOTPLUG_CPU .config CONFIG_HOTPLUG_CPU=y Michal > > Thanks > Jan > > On 03/04/2013 06:23 PM, Michal Fiala wrote: >> hallo, >> >> I have updated xen server to >> >> xen-4.2.1-r2 >> xen-tools-4.2.1-r1 >> kernel gentoo-sources-3.2.39 >> >> I have found 2 problems >> >> 1) Can not exactly set dom0, domU memory >> >> I dedicate 4G of memory to dom0 via kernel parameter: >> >> dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin >> >> Bud the real total memory is set to 2618M after reboot. I have found >> article describing this behavior >> (http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone), >> >> so I have run >> >> echo $((4*1024*1024)) > >> /sys/devices/system/xen_memory/xen_memory0/target_kb >> >> The total memory was se to 3687M. This is better, but not enough. >> >> I have tested kernel 3.7, there is not such problem. I would like to use >> longterm kernel 3.2 so I would like to stay with 3.2. >> >> Similar problem exists with domU, config looks like >> >> kernel = '/etc/xen/kernels/linux-3.2.39-gentoo' >> name = 'test1' >> memory = '4000' >> maxmem = '12000' >> vcpus = '8' >> cpus = '^0,^1,^2,^3' >> extra = 'elevator=noop gentoo=nodevfs' >> root = '/dev/xvda1 ro' >> disk = [ >> 'phy:/dev/vg1/test1_root,xvda1,w', >> 'phy:/dev/vg1/test1_var,xvda2,w', >> ] >> vif = [ >> 'mac=00:16:3e:24:11:38,bridge=br0', >> ] >> >> After boot, test1 domain has 3704M total memory (free -m), xm list test1 >> shows 4000M. >> >> When I increase memory amount via xm mem-set test1 8000, then xm list >> test1 really shows 8000M, but domU has 7704M total memory (free -m). >> >> from xend.log >> [2013-03-04 18:10:18 4627] DEBUG (XendDomainInfo:1467) Setting memory >> target of domain test1 (1) to 8000 MiB. >> >> 2) I am not able to increase vcpu count to domU. >> After boot domU test1, it has really 8 vcpus, I am able to decrease >> vcpus by xm vcpu-set test1 4. Cpus count inside test1 really decreases >> to 4. Now I would like to increase vcpu count via xm vcpu-list test1 6, >> but unsuccessfully. >> >> rajvir3 configs # xm vcpu-list test1 >> Name ID VCPU CPU State Time(s) CPU >> Affinity >> test1 1 0 15 -b- 3.7 12-23 >> test1 1 1 23 -b- 2.8 12-23 >> test1 1 2 18 -b- 1.2 12-23 >> test1 1 3 20 -b- 1.2 12-23 >> test1 1 4 16 -b- 1.0 12-23 >> test1 1 5 12 -b- 3.5 12-23 >> test1 1 6 19 -b- 0.9 12-23 >> test1 1 7 14 -b- 0.9 12-23 >> >> rajvir3 configs # xm vcpu-set test1 4 >> >> rajvir3 configs # xm vcpu-list test1 >> Name ID VCPU CPU State Time(s) CPU >> Affinity >> test1 1 0 15 -b- 3.7 12-23 >> test1 1 1 23 -b- 2.9 12-23 >> test1 1 2 18 -b- 1.3 12-23 >> test1 1 3 20 -b- 1.2 12-23 >> test1 1 4 - --p 1.0 12-23 >> test1 1 5 - --p 3.5 12-23 >> test1 1 6 - --p 1.0 12-23 >> test1 1 7 - --p 0.9 12-23 >> >> rajvir3 configs # xm vcpu-set test1 6 >> >> rajvir3 configs # xm vcpu-list test1 >> Name ID VCPU CPU State Time(s) CPU >> Affinity >> test1 1 0 15 -b- 3.8 12-23 >> test1 1 1 23 -b- 2.9 12-23 >> test1 1 2 18 -b- 1.3 12-23 >> test1 1 3 20 -b- 1.3 12-23 >> test1 1 4 - --p 1.0 12-23 >> test1 1 5 - --p 3.5 12-23 >> test1 1 6 - --p 1.0 12-23 >> test1 1 7 - --p 0.9 12-23 >> >> from xend.log >> >> [2013-03-04 18:12:58 4627] INFO (XendDomainInfo:1978) Set VCPU count on >> domain test1 to 4 >> [2013-03-04 18:14:51 4627] INFO (XendDomainInfo:1978) Set VCPU count on >> domain test1 to 6 >> >> I was not able to increase vcpu count also in kernel 3.7. >> >> Where could be the problem? >> >> Thanks >> >> Michal >> >> _______________________________________________ >> 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 > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 21:09:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 21:09: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 1UCccM-0000ji-9r; Mon, 04 Mar 2013 21:08:18 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCccK-0000jd-F3 for xen-users@lists.xen.org; Mon, 04 Mar 2013 21:08:16 +0000 Received: from [193.109.254.147:54302] by server-6.bemta-14.messagelabs.com id 20/ED-31180-F3D05315; Mon, 04 Mar 2013 21:08:15 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1362431294!8460193!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27163 invoked from network); 4 Mar 2013 21:08:14 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 21:08:14 -0000 Received: by mail-wg0-f50.google.com with SMTP id es5so4688070wgb.5 for ; Mon, 04 Mar 2013 13:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=71wXKFMvy6QnrwMbLMmWKqgKbXxBSHjFeoRaOI0pjgo=; b=VbhD+2NX2yQNw3cigd54JxbcTXdUOSLSJRuOI+P5txB6XLV8HlmmbvAeFXxdNGZ/8l KAMi4lLZ9N7ZD0PaxmR0pbHRu9BL4d1cnwIgs22pIllEzALtUpbKLhuowzFOxTEJu7oC ZTWjj/T8m8LX6WhHW66pRgqI1t1JN2AIFBtg8n+RsjQYDVqOz1OH6k/Hu+8AyTQyYuC8 Ez3zihGmlLNgvYsEtyFXBv+UdbhXMNOjysOjjSy87rj2p1glQ55Q4CxytycXOldAn2YY Q2JxK6h9uXVwP2Ra5U3Jnt5YnEhx58bkVjvttSP6y/hqLCU14ceFw2yKhUFSrGZqbF0X fu+A== X-Received: by 10.194.20.40 with SMTP id k8mr35041519wje.16.1362431294199; Mon, 04 Mar 2013 13:08:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 13:07:54 -0800 (PST) From: Matthias Date: Mon, 4 Mar 2013 22:07:54 +0100 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] Qemu confusion X-BeenThere: xen-users@lists.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 everybody, I'm currently a little confused about the status of the different qemu trees for xen unstable.. from what I've gathered so far, there are 3 different trees: 1) Qemu-Xen-Unstable (Repo: http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-unstable.git;a=shortlog;h=refs/heads/master ) This is the default repository which is download while xen-unstable is build 2) Qemu-Upstream-Unstable (Repo: http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-unstable.git;a=shortlog;h=refs/heads/master ) I don't really know what this is. 3) Qemu Upstream (Repo: git://git.qemu.org/qemu.git ) This is the 'real' Qemu repository from the Qemu project. Details and capabilities are described here, I think: http://wiki.xen.org/wiki/QEMU_Upstream Now I would really appreciate if somebody could shed some light into what repository to use for what situations, what the different capabilities are and especially what the status for vga passthrough is. Thanks! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 21:09:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 21:09: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 1UCccM-0000ji-9r; Mon, 04 Mar 2013 21:08:18 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCccK-0000jd-F3 for xen-users@lists.xen.org; Mon, 04 Mar 2013 21:08:16 +0000 Received: from [193.109.254.147:54302] by server-6.bemta-14.messagelabs.com id 20/ED-31180-F3D05315; Mon, 04 Mar 2013 21:08:15 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1362431294!8460193!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27163 invoked from network); 4 Mar 2013 21:08:14 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 21:08:14 -0000 Received: by mail-wg0-f50.google.com with SMTP id es5so4688070wgb.5 for ; Mon, 04 Mar 2013 13:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=71wXKFMvy6QnrwMbLMmWKqgKbXxBSHjFeoRaOI0pjgo=; b=VbhD+2NX2yQNw3cigd54JxbcTXdUOSLSJRuOI+P5txB6XLV8HlmmbvAeFXxdNGZ/8l KAMi4lLZ9N7ZD0PaxmR0pbHRu9BL4d1cnwIgs22pIllEzALtUpbKLhuowzFOxTEJu7oC ZTWjj/T8m8LX6WhHW66pRgqI1t1JN2AIFBtg8n+RsjQYDVqOz1OH6k/Hu+8AyTQyYuC8 Ez3zihGmlLNgvYsEtyFXBv+UdbhXMNOjysOjjSy87rj2p1glQ55Q4CxytycXOldAn2YY Q2JxK6h9uXVwP2Ra5U3Jnt5YnEhx58bkVjvttSP6y/hqLCU14ceFw2yKhUFSrGZqbF0X fu+A== X-Received: by 10.194.20.40 with SMTP id k8mr35041519wje.16.1362431294199; Mon, 04 Mar 2013 13:08:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Mon, 4 Mar 2013 13:07:54 -0800 (PST) From: Matthias Date: Mon, 4 Mar 2013 22:07:54 +0100 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] Qemu confusion X-BeenThere: xen-users@lists.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 everybody, I'm currently a little confused about the status of the different qemu trees for xen unstable.. from what I've gathered so far, there are 3 different trees: 1) Qemu-Xen-Unstable (Repo: http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-unstable.git;a=shortlog;h=refs/heads/master ) This is the default repository which is download while xen-unstable is build 2) Qemu-Upstream-Unstable (Repo: http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-unstable.git;a=shortlog;h=refs/heads/master ) I don't really know what this is. 3) Qemu Upstream (Repo: git://git.qemu.org/qemu.git ) This is the 'real' Qemu repository from the Qemu project. Details and capabilities are described here, I think: http://wiki.xen.org/wiki/QEMU_Upstream Now I would really appreciate if somebody could shed some light into what repository to use for what situations, what the different capabilities are and especially what the status for vga passthrough is. Thanks! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 04 21:09:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 21:09: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 1UCccx-0000mA-B7; Mon, 04 Mar 2013 21:08:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCccw-0000lw-B0 for xen-users@lists.xen.org; Mon, 04 Mar 2013 21:08:54 +0000 Received: from [85.158.139.83:26384] by server-7.bemta-5.messagelabs.com id E9/B8-12441-56D05315; Mon, 04 Mar 2013 21:08:53 +0000 X-Env-Sender: ecosoft13@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1362431331!30121720!1 X-Originating-IP: [209.85.220.175] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28961 invoked from network); 4 Mar 2013 21:08:52 -0000 Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 21:08:52 -0000 Received: by mail-vc0-f175.google.com with SMTP id p1so3089605vcq.20 for ; Mon, 04 Mar 2013 13:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rih0iHU/XgbaddnfP5qPnLTIoDAM9CXz8lS2riw0v38=; b=GmF4rTU+VY49i9P6IYCMz2tBErlS4A65GUNVWaIi1Pr4jXkKbmy1jJF+9YAC8TUqYD HaaGFJzD+3zD40YoOJuarrk7dGZxhnIwpD71W1jdd1WbEcq++0yATfMlDD8srI78aLTK VjhrcxaRtQEPOrJXT7x4QnpNdD4cd7eerZ64twPO6U40Zoy0b7pzQalOuzKcJMP/fE+k CfdYitggHloGTy02praaScVXcSD3NA0ojZKzQ+wxwzzkOC98KIlxuLWQvCpbNEkyOMFJ dqCyRqvCJlX2TPQturN4idRuQIqRpJch6c4K8vm0eAqCqlKUSSdTPOr7LuByl/qheVZc Z9wQ== MIME-Version: 1.0 X-Received: by 10.52.100.5 with SMTP id eu5mr7294734vdb.66.1362431331066; Mon, 04 Mar 2013 13:08:51 -0800 (PST) Received: by 10.221.13.194 with HTTP; Mon, 4 Mar 2013 13:08:50 -0800 (PST) In-Reply-To: <1362034566.23384.10.camel@dagon.hellion.org.uk> References: <1361874116.26546.256.camel@zakaz.uk.xensource.com> <1362034566.23384.10.camel@dagon.hellion.org.uk> Date: Mon, 4 Mar 2013 15:08:50 -0600 Message-ID: From: Yaodong Yang To: Ian Campbell Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Xen Domain U can not install (on 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="===============0419136501147282509==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0419136501147282509== Content-Type: multipart/alternative; boundary=20cf3071cf9a84e95604d71fc30a --20cf3071cf9a84e95604d71fc30a Content-Type: text/plain; charset=ISO-8859-1 Hello Ian and others, Thanks for your help! After several days working on it. I solved the problem and have a working system now. It turned out that I did not understand well about the network bridge model, when I run across this issue. Thanks again! On Thu, Feb 28, 2013 at 12:56 AM, Ian Campbell wrote: > On Thu, 2013-02-28 at 04:43 +0000, Yaodong Yang wrote: > > > > I download the following disk images. > > sudo wget > http://mirror.anl.gov/pub/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/initrd.gz > > sudo wget > http://mirror.anl.gov/pub/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/vmlinuz > > These are not disks, they are a netboot kernel and initrd. There are no > actual Ubuntu packages included with these so to install you will also > need access to a mirror. > > > I think it's related to the bridge network setting. I searched online > > and still have no idea about it. > > Please see: > http://wiki.xen.org/wiki/Xen_Networking > http://wiki.xen.org/wiki/Host_Configuration/Networking > > If you think bridge networking is an issue then it would have been > useful to provide your host networking configuration, e.g. the output of > "brctl show" and the content of /etc/network/interfaces. > > Ian. > > > --20cf3071cf9a84e95604d71fc30a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Ian and others,

Thanks for your h= elp!=A0

After several days working on it. I = solved the problem and have a working system now. It turned out that I did = not understand well about the network bridge model, when I run across this = issue.=A0

Thanks again!


On Thu, Feb 28, 2013 at 12:56 A= M, Ian Campbell <Ian.Campbell@citrix.com> wrote:
On Thu, 2013-02-28 at 04:4= 3 +0000, Yaodong Yang wrote:


> I download the following disk images.
> sudo wget = http://mirror.anl.gov/pub/ubuntu/dists/precise/main/installer-amd64/current= /images/netboot/xen/initrd.gz
> sudo wget ht= tp://mirror.anl.gov/pub/ubuntu/dists/precise/main/installer-amd64/current/i= mages/netboot/xen/vmlinuz

These are not disks, they are a netboot kernel and initrd. There are = no
actual Ubuntu packages included with these so to install you will also
need access to a mirror.

> I think it's related to the bridge network setting. I searched onl= ine
> and still have no idea about it.

Please see:
http:= //wiki.xen.org/wiki/Xen_Networking
http://wiki.xen.org/wiki/Host_Configuration/Networking

If you think bridge networking is an issue then it would have been
useful to provide your host networking configuration, e.g. the output of "brctl show" and the content of /etc/network/interfaces.

Ian.



--20cf3071cf9a84e95604d71fc30a-- --===============0419136501147282509== 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 --===============0419136501147282509==-- From xen-users-bounces@lists.xen.org Mon Mar 04 21:09:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 21:09: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 1UCccx-0000mA-B7; Mon, 04 Mar 2013 21:08:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCccw-0000lw-B0 for xen-users@lists.xen.org; Mon, 04 Mar 2013 21:08:54 +0000 Received: from [85.158.139.83:26384] by server-7.bemta-5.messagelabs.com id E9/B8-12441-56D05315; Mon, 04 Mar 2013 21:08:53 +0000 X-Env-Sender: ecosoft13@gmail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1362431331!30121720!1 X-Originating-IP: [209.85.220.175] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28961 invoked from network); 4 Mar 2013 21:08:52 -0000 Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 4 Mar 2013 21:08:52 -0000 Received: by mail-vc0-f175.google.com with SMTP id p1so3089605vcq.20 for ; Mon, 04 Mar 2013 13:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rih0iHU/XgbaddnfP5qPnLTIoDAM9CXz8lS2riw0v38=; b=GmF4rTU+VY49i9P6IYCMz2tBErlS4A65GUNVWaIi1Pr4jXkKbmy1jJF+9YAC8TUqYD HaaGFJzD+3zD40YoOJuarrk7dGZxhnIwpD71W1jdd1WbEcq++0yATfMlDD8srI78aLTK VjhrcxaRtQEPOrJXT7x4QnpNdD4cd7eerZ64twPO6U40Zoy0b7pzQalOuzKcJMP/fE+k CfdYitggHloGTy02praaScVXcSD3NA0ojZKzQ+wxwzzkOC98KIlxuLWQvCpbNEkyOMFJ dqCyRqvCJlX2TPQturN4idRuQIqRpJch6c4K8vm0eAqCqlKUSSdTPOr7LuByl/qheVZc Z9wQ== MIME-Version: 1.0 X-Received: by 10.52.100.5 with SMTP id eu5mr7294734vdb.66.1362431331066; Mon, 04 Mar 2013 13:08:51 -0800 (PST) Received: by 10.221.13.194 with HTTP; Mon, 4 Mar 2013 13:08:50 -0800 (PST) In-Reply-To: <1362034566.23384.10.camel@dagon.hellion.org.uk> References: <1361874116.26546.256.camel@zakaz.uk.xensource.com> <1362034566.23384.10.camel@dagon.hellion.org.uk> Date: Mon, 4 Mar 2013 15:08:50 -0600 Message-ID: From: Yaodong Yang To: Ian Campbell Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Xen Domain U can not install (on 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="===============0419136501147282509==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0419136501147282509== Content-Type: multipart/alternative; boundary=20cf3071cf9a84e95604d71fc30a --20cf3071cf9a84e95604d71fc30a Content-Type: text/plain; charset=ISO-8859-1 Hello Ian and others, Thanks for your help! After several days working on it. I solved the problem and have a working system now. It turned out that I did not understand well about the network bridge model, when I run across this issue. Thanks again! On Thu, Feb 28, 2013 at 12:56 AM, Ian Campbell wrote: > On Thu, 2013-02-28 at 04:43 +0000, Yaodong Yang wrote: > > > > I download the following disk images. > > sudo wget > http://mirror.anl.gov/pub/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/initrd.gz > > sudo wget > http://mirror.anl.gov/pub/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/vmlinuz > > These are not disks, they are a netboot kernel and initrd. There are no > actual Ubuntu packages included with these so to install you will also > need access to a mirror. > > > I think it's related to the bridge network setting. I searched online > > and still have no idea about it. > > Please see: > http://wiki.xen.org/wiki/Xen_Networking > http://wiki.xen.org/wiki/Host_Configuration/Networking > > If you think bridge networking is an issue then it would have been > useful to provide your host networking configuration, e.g. the output of > "brctl show" and the content of /etc/network/interfaces. > > Ian. > > > --20cf3071cf9a84e95604d71fc30a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Ian and others,

Thanks for your h= elp!=A0

After several days working on it. I = solved the problem and have a working system now. It turned out that I did = not understand well about the network bridge model, when I run across this = issue.=A0

Thanks again!


On Thu, Feb 28, 2013 at 12:56 A= M, Ian Campbell <Ian.Campbell@citrix.com> wrote:
On Thu, 2013-02-28 at 04:4= 3 +0000, Yaodong Yang wrote:


> I download the following disk images.
> sudo wget = http://mirror.anl.gov/pub/ubuntu/dists/precise/main/installer-amd64/current= /images/netboot/xen/initrd.gz
> sudo wget ht= tp://mirror.anl.gov/pub/ubuntu/dists/precise/main/installer-amd64/current/i= mages/netboot/xen/vmlinuz

These are not disks, they are a netboot kernel and initrd. There are = no
actual Ubuntu packages included with these so to install you will also
need access to a mirror.

> I think it's related to the bridge network setting. I searched onl= ine
> and still have no idea about it.

Please see:
http:= //wiki.xen.org/wiki/Xen_Networking
http://wiki.xen.org/wiki/Host_Configuration/Networking

If you think bridge networking is an issue then it would have been
useful to provide your host networking configuration, e.g. the output of "brctl show" and the content of /etc/network/interfaces.

Ian.



--20cf3071cf9a84e95604d71fc30a-- --===============0419136501147282509== 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 --===============0419136501147282509==-- From xen-users-bounces@lists.xen.org Mon Mar 04 23:04:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 23:04: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 1UCePO-0003Gu-V3; Mon, 04 Mar 2013 23:03:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBifo-0000CF-71 for xen-users@lists.xen.org; Sat, 02 Mar 2013 09:24:08 +0000 Received: from [85.158.138.51:21319] by server-5.bemta-3.messagelabs.com id 34/09-30636-735C1315; Sat, 02 Mar 2013 09:24:07 +0000 X-Env-Sender: mr.gerami@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1362216246!28194514!1 X-Originating-IP: [209.85.217.180] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5626 invoked from network); 2 Mar 2013 09:24:06 -0000 Received: from mail-lb0-f180.google.com (HELO mail-lb0-f180.google.com) (209.85.217.180) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Mar 2013 09:24:06 -0000 Received: by mail-lb0-f180.google.com with SMTP id q12so2791799lbc.39 for ; Sat, 02 Mar 2013 01:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=MbnPO8Yp5L+7AaWFb62pOEfqNUB6kQA8fks4wP1E7eU=; b=TcqI6WY7p3sTHN5J1vNQmniQIz7VmtcGza7B0MsPpc66PfHpdKvwsb1Iip8ud2Rfsl oFG3phy9LE142XjoSe8N6Ca4N70kVRI3KCkrm+92b59I5LfxI1b6AOtBaAEKZO4UciQ8 kwKc4lQYuOvPPyNJhLW/0nyNp0sBYMSo4r0Z+A1l62pKJfVKkhazSXS6P4CZvvpUGcW7 S8QPDzhGZRtBuVRpmaWfRtxtRNV+6sVavB7q9beb7Zy5Ruuqfem9NKlQs2tRBZyxk4UH ET56yV4yrY8fbebhxyytmy+rowMn6YwdUYUOSlBNnx6bNw4W4gZn45dNYjoPSaX9ESps Milw== X-Received: by 10.152.111.67 with SMTP id ig3mr11639978lab.41.1362216246099; Sat, 02 Mar 2013 01:24:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.29.70 with HTTP; Sat, 2 Mar 2013 01:23:46 -0800 (PST) From: Mohammad Reza Gerami Date: Sat, 2 Mar 2013 12:53:46 +0330 Message-ID: To: xen-users@lists.xen.org X-Mailman-Approved-At: Mon, 04 Mar 2013 23:03:00 +0000 Subject: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============8341758692492617588==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8341758692492617588== Content-Type: multipart/alternative; boundary=f46d04088f1774c5fb04d6edaf7c --f46d04088f1774c5fb04d6edaf7c Content-Type: text/plain; charset=UTF-8 Dear Friends I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I have 64 I installed CentOS 6.3 64 bit and install my software but when I run job and check, Maximum 16 core use in my system what is your idea? thank you --f46d04088f1774c5fb04d6edaf7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear=C2=A0Friends

I have a server with 4 * 8 (core) CPU, all 32 core with= hyper threat I have 64
I installed CentOS 6.3 64 bit and install= my software
but when I run =C2=A0job and check, Maximum =C2=A016= core use in my system

what is your idea?

thank you --f46d04088f1774c5fb04d6edaf7c-- --===============8341758692492617588== 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 --===============8341758692492617588==-- From xen-users-bounces@lists.xen.org Mon Mar 04 23:04:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 04 Mar 2013 23:04: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 1UCePO-0003Gu-V3; Mon, 04 Mar 2013 23:03:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UBifo-0000CF-71 for xen-users@lists.xen.org; Sat, 02 Mar 2013 09:24:08 +0000 Received: from [85.158.138.51:21319] by server-5.bemta-3.messagelabs.com id 34/09-30636-735C1315; Sat, 02 Mar 2013 09:24:07 +0000 X-Env-Sender: mr.gerami@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1362216246!28194514!1 X-Originating-IP: [209.85.217.180] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5626 invoked from network); 2 Mar 2013 09:24:06 -0000 Received: from mail-lb0-f180.google.com (HELO mail-lb0-f180.google.com) (209.85.217.180) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 2 Mar 2013 09:24:06 -0000 Received: by mail-lb0-f180.google.com with SMTP id q12so2791799lbc.39 for ; Sat, 02 Mar 2013 01:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=MbnPO8Yp5L+7AaWFb62pOEfqNUB6kQA8fks4wP1E7eU=; b=TcqI6WY7p3sTHN5J1vNQmniQIz7VmtcGza7B0MsPpc66PfHpdKvwsb1Iip8ud2Rfsl oFG3phy9LE142XjoSe8N6Ca4N70kVRI3KCkrm+92b59I5LfxI1b6AOtBaAEKZO4UciQ8 kwKc4lQYuOvPPyNJhLW/0nyNp0sBYMSo4r0Z+A1l62pKJfVKkhazSXS6P4CZvvpUGcW7 S8QPDzhGZRtBuVRpmaWfRtxtRNV+6sVavB7q9beb7Zy5Ruuqfem9NKlQs2tRBZyxk4UH ET56yV4yrY8fbebhxyytmy+rowMn6YwdUYUOSlBNnx6bNw4W4gZn45dNYjoPSaX9ESps Milw== X-Received: by 10.152.111.67 with SMTP id ig3mr11639978lab.41.1362216246099; Sat, 02 Mar 2013 01:24:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.29.70 with HTTP; Sat, 2 Mar 2013 01:23:46 -0800 (PST) From: Mohammad Reza Gerami Date: Sat, 2 Mar 2013 12:53:46 +0330 Message-ID: To: xen-users@lists.xen.org X-Mailman-Approved-At: Mon, 04 Mar 2013 23:03:00 +0000 Subject: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============8341758692492617588==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8341758692492617588== Content-Type: multipart/alternative; boundary=f46d04088f1774c5fb04d6edaf7c --f46d04088f1774c5fb04d6edaf7c Content-Type: text/plain; charset=UTF-8 Dear Friends I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I have 64 I installed CentOS 6.3 64 bit and install my software but when I run job and check, Maximum 16 core use in my system what is your idea? thank you --f46d04088f1774c5fb04d6edaf7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear=C2=A0Friends

I have a server with 4 * 8 (core) CPU, all 32 core with= hyper threat I have 64
I installed CentOS 6.3 64 bit and install= my software
but when I run =C2=A0job and check, Maximum =C2=A016= core use in my system

what is your idea?

thank you --f46d04088f1774c5fb04d6edaf7c-- --===============8341758692492617588== 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 --===============8341758692492617588==-- From xen-users-bounces@lists.xen.org Tue Mar 05 02:44:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 02:44: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 1UChqS-0000ru-RA; Tue, 05 Mar 2013 02:43:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UChqQ-0000rp-OK for xen-users@lists.xen.org; Tue, 05 Mar 2013 02:43:11 +0000 Received: from [85.158.138.51:44671] by server-6.bemta-3.messagelabs.com id E8/F0-11048-DBB55315; Tue, 05 Mar 2013 02:43:09 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1362451385!30234345!1 X-Originating-IP: [209.85.210.178] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11354 invoked from network); 5 Mar 2013 02:43:07 -0000 Received: from mail-ia0-f178.google.com (HELO mail-ia0-f178.google.com) (209.85.210.178) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 02:43:07 -0000 Received: by mail-ia0-f178.google.com with SMTP id y26so5500864iab.37 for ; Mon, 04 Mar 2013 18:43:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZMKD73s4Y6TuPbKUF2z82R5kSohcg1ldji7HOh/Hpwo=; b=F9QZ7+G/gTEPedjOjAaCGzXcUWSQQsxMTGvQdsKv+Ncpx9wOQrZ726zrUJ0pGfed0n j2EMPzqQFvWDdHVUfddmFaNifDZFaNnf+KBhw5bUf+X9uejIS0mHLigWOPXSTlVpIzvp 6uUfhGp2KHRV3HRiHp7jX2Pa530c8uwGjKNSP7eXshTd/oLiXyqFyik5flggs0UhYVl7 cWqdidKlTGQTs76L17S/GLpqYxbBUVo3MtVTVmtz5ge/3/TTmwPiOPh//4k/9nJS7uJ5 rwIs/c1OHJJstImzft1V9COn6kUNe+DIXS2kn1tA7S1zcb5zNGgz6oz85eZE4FFASKeV dcqg== MIME-Version: 1.0 X-Received: by 10.50.183.233 with SMTP id ep9mr4726819igc.87.1362451385131; Mon, 04 Mar 2013 18:43:05 -0800 (PST) Received: by 10.64.92.198 with HTTP; Mon, 4 Mar 2013 18:43:04 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 23:43:04 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Content-Type: multipart/mixed; boundary=14dae9340959d5aa6f04d7246e42 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@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 --14dae9340959d5aa6f04d7246e42 Content-Type: multipart/alternative; boundary=14dae9340959d5aa6a04d7246e40 --14dae9340959d5aa6a04d7246e40 Content-Type: text/plain; charset=ISO-8859-1 Matthias, hi! I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the same on and on (*VGA passthru worked only as secondary device and dom0 freshly rebooted*). As requested, I'm sending you the hvm configuration files from windows-xp and windows-7, my lspci -vv, uname and the kernel configuration file. Do you have any idea how I can make this work? 2013/3/4 Guilherme Suzuki > Alright! > > I'm gonna try catalyst 12-10 (after deinstalling and checking if the > passthru works rebooting and so on). > > I'll send my domU config as soon as I get home. > > One more question: does it matter if I use intel onboard graphics with the > dom0 and xen-pciback(radeon device pci)? Cause that would be the reason > primary VGA passthru did not work... > > Thx, xen guys are awesome! =D > > On Mar 4, 2013 2:07 PM, "Matthias" > wrote: > > Hi, > > good news, since you said your winxp was able to boot with vga > passthrough just fine, your FLR seems to work fine and this might > 'only' be a driver-related problem. > > What you can do is deinstall your catalyst drivers. After rebooting, > Win7 will fallback on a windows-standard driver for the vga but when > it correctly says the vga name (like ATI Radeion HD whatever Series), > it actually is falling back to an older catalyst version which is > shipped per default with windows. I have found this much more stable > on reboots then the newest driver. Also, deinstall Catalyst / Vision > control center and at best everything the catalyst installer lets you > deinstall. > > If vga passthrough works without all the drivers and you really want > the latest and greatest catalyst, i recommend not using the latest > 13-1 because it creates a similar behavior you mentioned on my > machine. But catalyst 12-10 seems to work fine, so i would advice you > trying that one. > > > If it still doesn't work with deinstalled drivers, we can try a patch > i'm currently testing.. But this the patch is somewhat complicated to > install, let's stick with the simple things for the moment. > > Also, your domU config still would be of help ruling out some > misconfiguration there.. > > > > 2013/3/4 Guilherme Suzuki : > > > Sorry (hit send). > > > > So, the radeon device tells it couldnt start itself (code 10) and cirrus > > d... > > -- Grato, ** *Guilherme Suzuki* Consultor em TI para projetos Microsoft *http://www.guilhermesuzuki.com* 11 - 992360535 11 - 20990757 --14dae9340959d5aa6a04d7246e40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Matthias, hi!

I've tried Cataly= st 12.10 and even 12.1, but xen behavior kept the same on and on (VGA pa= ssthru worked only as secondary device and dom0 freshly rebooted). As r= equested, I'm sending you the hvm configuration files from windows-xp a= nd windows-7, my lspci -vv, uname and the kernel configuration file.

Do you have any idea how I can make this work?

=


2013/3/= 4 Guilherme Suzuki <suzuki.gui@gmail.com>

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the= passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with t= he dom0 and xen-pciback(radeon device pci)? Cause that would be the reason = primary VGA passthru did not work...

Thx, xen guys are awesome! =3DD

On Mar 4, 2013 2:07= PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote= :

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch i'm currently testing.. But this the patch is somewhat complicated to install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Sorry (hit send).
>
> So, the radeon= device tells it couldnt start itself (code 10) and cirrus
=
> d...




--
Grato,
Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=A0
--14dae9340959d5aa6a04d7246e40-- --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name="windows-xp.hvm" Content-Disposition: attachment; filename="windows-xp.hvm" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1uw0 ICAgI2tlcm5lbCA9ICJodm1sb2FkZXIiCiAgIGJ1aWxkZXI9J2h2bScKICAgbWVtb3J5ID00MDk2 IAogICB2Y3B1cz0yCiAgIG5hbWUgPSAid2luZG93cy14cCIKICAgI3ZpZiA9IFsnYnJpZGdlPXhl bmJyMCddCiAgIGRpc2sgPSBbCgkjIyBwZW4tZHJpdmUKCSMncGh5Oi9kZXYvc2RnLGhkYix3JywK CSdwaHk6L2Rldi92ZzEveHAsaGRhLHcnLAoJJ2ZpbGU6L2hvbWUvc3V6dWtpLmd1aWxoZXJtZS9W TXMvTWljcm9zb2Z0LldpbmRvd3MuWFAuUHJvZmVzc2lvbmFsLlNQMy5JbnRlZ3JhdGVkLkp1bHku MjAxMS5TQVRBLmlzbyxoZGM6Y2Ryb20sciddCiAgIGFjcGkgPSAxCiAgICNkZXZpY2VfbW9kZWwg PSAncWVtdS1kbScKICAgYm9vdD0iZGMiCiAgIHNkbD0wCiAgIHNlcmlhbD0ncHR5JwogICB2bmM9 MQogICB2bmNsaXN0ZW49IiIKICAgdm5jZGlzcGxheT0wCiAgIHZuY3VudXNlZD0xCiAgIHZuY3Bh c3N3ZD0iIgogICBnZnhfcGFzc3RocnU9MAogICBwY2k9WycwMTowMC4wJywnMDE6MDAuMScsJzAw OjFkLjAnXQogICAjdXNiPTEKICAgI3VzYmRldmljZT0iaG9zdDowM2YwOjAwMjQiCiAgICN1c2Jk ZXZpY2U9Imhvc3Q6MDQ2MTo0ZDIwIgo= --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name="windows.hvm" Content-Disposition: attachment; filename="windows.hvm" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1v81 ICAgI2tlcm5lbCA9ICJodm1sb2FkZXIiCiAgIGJ1aWxkZXI9J2h2bScKICAgbWVtb3J5PTgxOTIg CiAgIHZjcHVzPTQKICAgbmFtZSA9ICJ3aW5kb3dzLTciCiAgICN2aWYgPSBbJ2JyaWRnZT14ZW5i cjAnXQogICBkaXNrID0gWwoJJ3BoeTovZGV2L3ZnMS93aW5kb3dzLGhkYSx3JywKCSMncGh5Oi9k ZXYvc2RoLGhkYix3JywKCSdmaWxlOi9ob21lL3N1enVraS5ndWlsaGVybWUvVk1zL2VuX3dpbmRv d3NfN191bHRpbWF0ZV9uX3dpdGhfc3AxX3g2NF9kdmRfdV82Nzc1NDMuaXNvLGhkYzpjZHJvbSxy J10KICAgYWNwaT0xCiAgIGFwaWM9MQogICB4ZW5fZXh0ZW5kZWRfcG93ZXJfbWdtdD0xCiAgICNk ZXZpY2VfbW9kZWwgPSAncWVtdS1kbScKICAgYXJjaD0neDg2XzY0JwogICBocGV0ID0gMQogICBo YXAgPSAxCiAgIHZpcmlkaWFuID0gMQogICBtb25pdG9yPTEKICAgYXVkaW89Im9uIgogICBib290 PSJkYyIKICAgc2RsPTAKICAgc2VyaWFsPSdwdHknCiAgIHZuYz0xCiAgIHZuY2xpc3Rlbj0iIgog ICB2bmNkaXNwbGF5PTAKICAgdm5jdW51c2VkPTEKICAgdm5jcGFzc3dkPSIiCiAgICN4ZW5fcGxh dGZvcm1fcGNpPTEKICAgZ2Z4X3Bhc3N0aHJ1PTAKICAgcGNpPVsnMDE6MDAuMCcsJzAxOjAwLjEn LCcwMDoxZC4wJ10KICAgcGNpX21zaXRyYW5zbGF0ZSA9IDEKICAgcGNpX3Bvd2VyX21nbXQgPSAx CiAgIGFjcGlfczMgPSAxCiAgIGFjcGlfczQgPSAxCiAgICN1c2I9MQogICAjdXNiZGV2aWNlPSJ0 YWJsZXQiCiAgICN1c2JkZXZpY2U9Imhvc3Q6MDNmMDowMDI0IgogICAjdXNiZGV2aWNlPSJob3N0 OjA0NjE6NGQyMCIK --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name=lspci-txt Content-Disposition: attachment; filename=lspci-txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1vi2 MDA6MDAuMCBIb3N0IGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24gMm5kIEdlbmVyYXRpb24gQ29y ZSBQcm9jZXNzb3IgRmFtaWx5IERSQU0gQ29udHJvbGxlciAocmV2IDA5KQoJU3Vic3lzdGVtOiBH aWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgNTAwMAoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01h c3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VS Ui0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCKyBQ YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVS Ui0gSU5UeC0KCUxhdGVuY3k6IDAKCUNhcGFiaWxpdGllczogW2UwXSBWZW5kb3IgU3BlY2lmaWMg SW5mb3JtYXRpb246IExlbj0wYyA8Pz4KCjAwOjAxLjAgUENJIGJyaWRnZTogSW50ZWwgQ29ycG9y YXRpb24gWGVvbiBFMy0xMjAwLzJuZCBHZW5lcmF0aW9uIENvcmUgUHJvY2Vzc29yIEZhbWlseSBQ Q0kgRXhwcmVzcyBSb290IFBvcnQgKHJldiAwOSkgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVd KQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czog Q2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENhY2hlIExp bmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTAxLCBzdWJvcmRp bmF0ZT0wMSwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlkZ2U6IDAwMDBlMDAwLTAwMDBl ZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjdiMDAwMDAtZjdiZmZmZmYKCVByZWZldGNoYWJs ZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBlMDAwMDAwMC0wMDAwMDAwMGVmZmZmZmZm CglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+ VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0 eS0gU0VSUi0gTm9JU0EtIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rt ci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6 IFs4OF0gU3Vic3lzdGVtOiBHaWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgNTAwMAoJQ2FwYWJp bGl0aWVzOiBbODBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0g RFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xk KykKCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBN RS0KCUNhcGFiaWxpdGllczogWzkwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2 NGJpdC0KCQlBZGRyZXNzOiBmZWUwMDI5OCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0aWVzOiBbYTBd IEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3QrKSwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXls b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzCgkJ CUV4dFRhZy0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFi bGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkLSBFeHRUYWctIFBo YW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVh ZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVu c3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICMyLCBTcGVlZCA1R1Qv cywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MjU2bnMsIEwxIDw0dXMKCQkJ Q2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdCsKCQlMbmtDdGw6CUFTUE0gRGlzYWJs ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gt IENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41 R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQr IEFCV01nbXQrCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3cklu ZC0gSG90UGx1Zy0gU3VycHJpc2UtCgkJCVNsb3QgIzEsIFBvd2VyTGltaXQgNzUuMDAwVzsgSW50 ZXJsb2NrLSBOb0NvbXBsKwoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0g UHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5r bm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stCgkJU2x0U3RhOglTdGF0dXM6 IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0KCQkJ Q2hhbmdlZDogTVJMLSBQcmVzRGV0LSBMaW5rU3RhdGUtCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFi bGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290 Q2FwOiBDUlNWaXNpYmxlLQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBN RVBlbmRpbmctCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBU aW1lb3V0RGlzLSwgTFRSKywgT0JGRiBOb3QgU3VwcG9ydGVkIEFSSUZ3ZC0KCQlEZXZDdGwyOiBD b21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0sIExUUi0sIE9CRkYg RGlzYWJsZWQgQVJJRndkLQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50 ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJh dGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBD b21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNp cyBMZXZlbDogLTZkQiwgRXF1YWxpemF0aW9uQ29tcGxldGUtLCBFcXVhbGl6YXRpb25QaGFzZTEt CgkJCSBFcXVhbGl6YXRpb25QaGFzZTItLCBFcXVhbGl6YXRpb25QaGFzZTMtLCBMaW5rRXF1YWxp emF0aW9uUmVxdWVzdC0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmlydHVhbCBDaGFubmVsCgkJ Q2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTEKCQlBcmI6CUZpeGVkLSBX UlIzMi0gV1JSNjQtIFdSUjEyOC0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQKCQlTdGF0dXM6CUlu UHJvZ3Jlc3MtCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25v b3BUcmFucy0KCQkJQXJiOglGaXhlZCsgV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdS UjI1Ni0KCQkJQ3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZgoJCQlT dGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQoJQ2FwYWJpbGl0aWVzOiBbMTQwIHYxXSBS b290IENvbXBsZXggTGluawoJCURlc2M6CVBvcnROdW1iZXI9MDIgQ29tcG9uZW50SUQ9MDEgRWx0 VHlwZT1Db25maWcKCQlMaW5rMDoJRGVzYzoJVGFyZ2V0UG9ydD0wMCBUYXJnZXRDb21wb25lbnQ9 MDEgQXNzb2NSQ1JCLSBMaW5rVHlwZT1NZW1NYXBwZWQgTGlua1ZhbGlkKwoJCQlBZGRyOgkwMDAw MDAwMGZlZDE5MDAwCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCjAwOjAyLjAgVkdB IGNvbXBhdGlibGUgY29udHJvbGxlcjogSW50ZWwgQ29ycG9yYXRpb24gMm5kIEdlbmVyYXRpb24g Q29yZSBQcm9jZXNzb3IgRmFtaWx5IEludGVncmF0ZWQgR3JhcGhpY3MgQ29udHJvbGxlciAocmV2 IDA5KSAocHJvZy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQoJU3Vic3lzdGVtOiBHaWdhLWJ5dGUg VGVjaG5vbG9neSBEZXZpY2UgZDAwMAoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlci0gU3Bl Y0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy Qi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCKyBQYXJFcnItIERF VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0K CUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxNgoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm NzQwMDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00TV0KCVJlZ2lvbiAyOiBN ZW1vcnkgYXQgZDAwMDAwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZNXQoJUmVn aW9uIDQ6IEkvTyBwb3J0cyBhdCBmMDAwIFtzaXplPTY0XQoJRXhwYW5zaW9uIFJPTSBhdCA8dW5h c3NpZ25lZD4gW2Rpc2FibGVkXQoJQ2FwYWJpbGl0aWVzOiBbOTBdIE1TSTogRW5hYmxlLSBDb3Vu dD0xLzEgTWFza2FibGUtIDY0Yml0LQoJCUFkZHJlc3M6IDAwMDAwMDAwICBEYXRhOiAwMDAwCglD YXBhYmlsaXRpZXM6IFtkMF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFnczogUE1F Q2xrLSBEU0krIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxE M2NvbGQtKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxl PTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbYTRdIFBDSSBBZHZhbmNlZCBGZWF0dXJlcwoJCUFGQ2Fw OiBUUCsgRkxSKwoJCUFGQ3RybDogRkxSLQoJCUFGU3RhdHVzOiBUUC0KCjAwOjE0LjAgVVNCIGNv bnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIDcgU2VyaWVzL0MyMTAgU2VyaWVzIENoaXBzZXQg RmFtaWx5IFVTQiB4SENJIEhvc3QgQ29udHJvbGxlciAocmV2IDA0KSAocHJvZy1pZiAzMCBbWEhD SV0pCglTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSA1MDA3CglDb250cm9s OiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6 LSBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8 TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwCglJbnRlcnJ1cHQ6IHBpbiBB IHJvdXRlZCB0byBJUlEgOTQKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjdjMDAwMDAgKDY0LWJpdCwg bm9uLXByZWZldGNoYWJsZSkgW3NpemU9NjRLXQoJQ2FwYWJpbGl0aWVzOiBbNzBdIFBvd2VyIE1h bmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJl bnQ9Mzc1bUEgUE1FKEQwLSxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9T b2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBb ODBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzggTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAw MDAwMDAwZmVlMDAyZjggIERhdGE6IDAwMDAKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiB4aGNpX2hj ZAoKMDA6MTYuMCBDb21tdW5pY2F0aW9uIGNvbnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIDcg U2VyaWVzL0MyMTAgU2VyaWVzIENoaXBzZXQgRmFtaWx5IE1FSSBDb250cm9sbGVyICMxIChyZXYg MDQpCglTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSAxYzNhCglDb250cm9s OiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6 LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1B Ym9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJSW50ZXJydXB0OiBwaW4gQSBy b3V0ZWQgdG8gSVJRIDk2CglSZWdpb24gMDogTWVtb3J5IGF0IGY3YzFhMDAwICg2NC1iaXQsIG5v bi1wcmVmZXRjaGFibGUpIFtzaXplPTE2XQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFn ZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9 MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIE5vU29mdFJz dCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzhjXSBN U0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsKCQlBZGRyZXNzOiAwMDAwMDAw MGZlZTAwMzM4ICBEYXRhOiAwMDAwCglLZXJuZWwgZHJpdmVyIGluIHVzZTogbWVpCgowMDoxYS4w IFVTQiBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlvbiA3IFNlcmllcy9DMjEwIFNlcmllcyBD aGlwc2V0IEZhbWlseSBVU0IgRW5oYW5jZWQgSG9zdCBDb250cm9sbGVyICMyIChyZXYgMDQpIChw cm9nLWlmIDIwIFtFSENJXSkKCVN1YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xvZ3kgRGV2aWNl IDUwMDYKCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0g VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0 dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJv cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCUlu dGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxNgoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmN2Mx ODAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xS10KCUNhcGFiaWxpdGllczog WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt IEQyLSBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlT dGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNh cGFiaWxpdGllczogWzU4XSBEZWJ1ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBhMAoJQ2FwYWJpbGl0 aWVzOiBbOThdIFBDSSBBZHZhbmNlZCBGZWF0dXJlcwoJCUFGQ2FwOiBUUCsgRkxSKwoJCUFGQ3Ry bDogRkxSLQoJCUFGU3RhdHVzOiBUUCsKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZAoK MDA6MWIuMCBBdWRpbyBkZXZpY2U6IEludGVsIENvcnBvcmF0aW9uIDcgU2VyaWVzL0MyMTAgU2Vy aWVzIENoaXBzZXQgRmFtaWx5IEhpZ2ggRGVmaW5pdGlvbiBBdWRpbyBDb250cm9sbGVyIChyZXYg MDQpCglTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSBhMDE0CglDb250cm9s OiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6 LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1B Ym9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2 NCBieXRlcwoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDMKCVJlZ2lvbiAwOiBNZW1v cnkgYXQgZjdjMTAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MTZLXQoJQ2Fw YWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNs ay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9NTVtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQz Y29sZCspCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9 MCBQTUUtCglDYXBhYmlsaXRpZXM6IFs2MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJs ZS0gNjRiaXQrCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMAoJQ2FwYWJp bGl0aWVzOiBbNzBdIEV4cHJlc3MgKHYxKSBSb290IENvbXBsZXggSW50ZWdyYXRlZCBFbmRwb2lu dCwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExh dGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzCgkJCUV4dFRhZy0gUkJFLSBGTFJlc2V0KwoJCURldkN0 bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y dGVkLQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlN YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNvcnJF cnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyKyBUcmFuc1BlbmQtCgkJ TG5rQ2FwOglQb3J0ICMwLCBTcGVlZCB1bmtub3duLCBXaWR0aCB4MCwgQVNQTSB1bmtub3duLCBM YXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0g QndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs ay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxu a1N0YToJU3BlZWQgdW5rbm93biwgV2lkdGggeDAsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExB Y3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmlydHVhbCBD aGFubmVsCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTEKCQlBcmI6 CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQKCQlT dGF0dXM6CUluUHJvZ3Jlc3MtCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3Rz PTEgUmVqU25vb3BUcmFucy0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRX UlIxMjgtIFdSUjI1Ni0KCQkJQ3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9W Qz0wMQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQoJCVZDMToJQ2FwczoJUEFU T2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtCgkJCUFyYjoJRml4ZWQtIFdS UjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtCgkJCUN0cmw6CUVuYWJsZSsgSUQ9 MSBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9MjIKCQkJU3RhdHVzOglOZWdvUGVuZGluZy0gSW5Qcm9n cmVzcy0KCUNhcGFiaWxpdGllczogWzEzMCB2MV0gUm9vdCBDb21wbGV4IExpbmsKCQlEZXNjOglQ b3J0TnVtYmVyPTBmIENvbXBvbmVudElEPTAwIEVsdFR5cGU9Q29uZmlnCgkJTGluazA6CURlc2M6 CVRhcmdldFBvcnQ9MDAgVGFyZ2V0Q29tcG9uZW50PTAwIEFzc29jUkNSQi0gTGlua1R5cGU9TWVt TWFwcGVkIExpbmtWYWxpZCsKCQkJQWRkcjoJMDAwMDAwMDBmZWQxYzAwMAoKMDA6MWMuMCBQQ0kg YnJpZGdlOiBJbnRlbCBDb3Jwb3JhdGlvbiA3IFNlcmllcy9DMjEwIFNlcmllcyBDaGlwc2V0IEZh bWlseSBQQ0kgRXhwcmVzcyBSb290IFBvcnQgMSAocmV2IGM0KSAocHJvZy1pZiAwMCBbTm9ybWFs IGRlY29kZV0pCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJ U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwg Q2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDIs IHN1Ym9yZGluYXRlPTAyLCBzZWMtbGF0ZW5jeT0wCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0g RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0KyA8 U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eS0gU0VSUi0gTm9JU0EtIFZHQS0gTUFib3J0 LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQt IERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjIpIFJvb3QgUG9y dCAoU2xvdCspLCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1 bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFnLSBSQkUrIEZMUmVzZXQt CgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0g VW5zdXBwb3J0ZWQtCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25v b3AtCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJCURldlN0 YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3IrIFRyYW5z UGVuZC0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtu b3duLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDwxNnVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFj dFJlcCsgQndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs ZWQtIFJldHJhaW4tIENvbW1DbGstCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJX SW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgwLCBUckVyci0g VHJhaW4rIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtCgkJU2x0Q2FwOglBdHRu QnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtCgkJ CVNsb3QgIzAsIFBvd2VyTGltaXQgMTAuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKwoJCVNsdEN0 bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEt IExpbmtDaGctCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBv d2VyLSBJbnRlcmxvY2stCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwt IENtZENwbHQtIFByZXNEZXQtIEludGVybG9jay0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0LSBM aW5rU3RhdGUtCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0 YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQoJCVJvb3RT dGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctCgkJRGV2Q2FwMjogQ29t cGxldGlvbiBUaW1lb3V0OiBSYW5nZSBCQywgVGltZW91dERpcyssIExUUi0sIE9CRkYgTm90IFN1 cHBvcnRlZCBBUklGd2QtCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVzIHRvIDUw bXMsIFRpbWVvdXREaXMtLCBMVFItLCBPQkZGIERpc2FibGVkIEFSSUZ3ZC0KCQlMbmtDdGwyOiBU YXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0KCQkJ IFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENv bXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC CgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCLCBFcXVhbGl6YXRp b25Db21wbGV0ZS0sIEVxdWFsaXphdGlvblBoYXNlMS0KCQkJIEVxdWFsaXphdGlvblBoYXNlMi0s IEVxdWFsaXphdGlvblBoYXNlMy0sIExpbmtFcXVhbGl6YXRpb25SZXF1ZXN0LQoJQ2FwYWJpbGl0 aWVzOiBbODBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQoJCUFkZHJl c3M6IDAwMDAwMDAwICBEYXRhOiAwMDAwCglDYXBhYmlsaXRpZXM6IFs5MF0gU3Vic3lzdGVtOiBH aWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgNTAwMQoJQ2FwYWJpbGl0aWVzOiBbYTBdIFBvd2Vy IE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1 cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIE5v U29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUtlcm5lbCBkcml2ZXIg aW4gdXNlOiBwY2llcG9ydAoKMDA6MWMuNCBQQ0kgYnJpZGdlOiBJbnRlbCBDb3Jwb3JhdGlvbiA3 IFNlcmllcy9DMjEwIFNlcmllcyBDaGlwc2V0IEZhbWlseSBQQ0kgRXhwcmVzcyBSb290IFBvcnQg NSAocmV2IGM0KSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pCglDb250cm9sOiBJL08rIE1l bSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBw aW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZh c3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF UlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJ QnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDMsIHN1Ym9yZGluYXRlPTAzLCBzZWMtbGF0ZW5j eT0wCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjdhMDAwMDAtZjdhZmZmZmYKCVNlY29uZGFyeSBz dGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv cnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5LSBTRVJSLSBOb0lT QS0gVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1y LSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNz ICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjgg Ynl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlFeHRUYWct IFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24t RmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMt IEF1eFB3ci0gTm9Tbm9vcC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4 IGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt IEF1eFB3cisgVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgNUdUL3MsIFdpZHRo IHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDUxMm5zLCBMMSA8MTZ1cwoJCQlDbG9ja1BN LSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQ TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCA1R1QvcywgV2lk dGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdCsK CQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVn LSBTdXJwcmlzZS0KCQkJU2xvdCAjNCwgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2stIE5v Q29tcGwrCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBD bWRDcGx0LSBIUElycS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJ bmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0g UG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJCQlDaGFuZ2VkOiBN UkwtIFByZXNEZXQtIExpbmtTdGF0ZS0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9u LUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQoJCVJvb3RDYXA6IENSU1Zp c2libGUtCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0K CQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEJDLCBUaW1lb3V0RGlzKywgTFRS LSwgT0JGRiBOb3QgU3VwcG9ydGVkIEFSSUZ3ZC0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVv dXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0sIExUUi0sIE9CRkYgRGlzYWJsZWQgQVJJRndk LQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBT cGVlZERpcy0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50 ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVt cGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQiwg RXF1YWxpemF0aW9uQ29tcGxldGUtLCBFcXVhbGl6YXRpb25QaGFzZTEtCgkJCSBFcXVhbGl6YXRp b25QaGFzZTItLCBFcXVhbGl6YXRpb25QaGFzZTMtLCBMaW5rRXF1YWxpemF0aW9uUmVxdWVzdC0K CUNhcGFiaWxpdGllczogWzgwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJp dC0KCQlBZGRyZXNzOiAwMDAwMDAwMCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0aWVzOiBbOTBdIFN1 YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xvZ3kgRGV2aWNlIDUwMDEKCUNhcGFiaWxpdGllczog W2EwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspCgkJU3Rh dHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglLZXJu ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCjAwOjFjLjUgUENJIGJyaWRnZTogSW50ZWwgQ29y cG9yYXRpb24gODI4MDEgUENJIEJyaWRnZSAocmV2IGM0KSAocHJvZy1pZiAwMSBbU3VidHJhY3Rp dmUgZGVjb2RlXSkKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+ VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAw LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0w NCwgc3Vib3JkaW5hdGU9MDUsIHNlYy1sYXRlbmN5PTAKCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6 LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQr IDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5LSBTRVJSLSBOb0lTQS0gVkdBLSBNQWJv cnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNjVG1yU3Rh dC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNzICh2MikgUm9vdCBQ b3J0IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50 RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlFeHRUYWctIFJCRSsgRkxSZXNl dC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs LSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T bm9vcC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzCgkJRGV2 U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3cisgVHJh bnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjNiwgU3BlZWQgNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVu a25vd24sIExhdGVuY3kgTDAgPDF1cywgTDEgPDE2dXMKCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExM QWN0UmVwKyBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNh YmxlZC0gUmV0cmFpbi0gQ29tbUNsay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g QldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy LSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0KCQlTbHRDYXA6CUF0 dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0K CQkJU2xvdCAjNSwgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrCgkJU2x0 Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUEly cS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwg UG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1S TC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQt IExpbmtTdGF0ZS0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJG YXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQoJCVJvb3RDYXA6IENSU1Zpc2libGUtCgkJUm9v dFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0KCQlEZXZDYXAyOiBD b21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEJDLCBUaW1lb3V0RGlzKywgTFRSLSwgT0JGRiBOb3Qg U3VwcG9ydGVkIEFSSUZ3ZC0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8g NTBtcywgVGltZW91dERpcy0sIExUUi0sIE9CRkYgRGlzYWJsZWQgQVJJRndkLQoJCUxua0N0bDI6 IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0KCQkJ IFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENv bXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC CgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCLCBFcXVhbGl6YXRp b25Db21wbGV0ZS0sIEVxdWFsaXphdGlvblBoYXNlMS0KCQkJIEVxdWFsaXphdGlvblBoYXNlMi0s IEVxdWFsaXphdGlvblBoYXNlMy0sIExpbmtFcXVhbGl6YXRpb25SZXF1ZXN0LQoJQ2FwYWJpbGl0 aWVzOiBbODBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQoJCUFkZHJl c3M6IDAwMDAwMDAwICBEYXRhOiAwMDAwCglDYXBhYmlsaXRpZXM6IFs5MF0gU3Vic3lzdGVtOiBH aWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgNTAwMQoJQ2FwYWJpbGl0aWVzOiBbYTBdIFBvd2Vy IE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1 cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIE5v U29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCjAwOjFjLjYgUENJIGJy aWRnZTogSW50ZWwgQ29ycG9yYXRpb24gNyBTZXJpZXMvQzIxMCBTZXJpZXMgQ2hpcHNldCBGYW1p bHkgUENJIEV4cHJlc3MgUm9vdCBQb3J0IDcgKHJldiBjNCkgKHByb2ctaWYgMDAgW05vcm1hbCBk ZWNvZGVdKQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0 YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENh Y2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA2LCBz dWJvcmRpbmF0ZT0wNiwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlkZ2U6IDAwMDBkMDAw LTAwMDBkZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjc5MDAwMDAtZjc5ZmZmZmYKCVNlY29u ZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQt IDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5LSBTRVJS LSBOb0lTQS0gVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNE aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzQwXSBF eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9h ZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlF eHRUYWctIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFu dEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRS ZXEgMTI4IGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1 cHBSZXEtIEF1eFB3cisgVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjNywgU3BlZWQgNUdUL3Ms IFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDUxMm5zLCBMMSA8MTZ1cwoJCQlD bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxl ZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0g Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVH VC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210KyBB QldNZ210LQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQt IEhvdFBsdWctIFN1cnByaXNlLQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDEwLjAwMFc7IEludGVy bG9jay0gTm9Db21wbCsKCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFBy ZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25v d24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQoJCVNsdFN0YToJU3RhdHVzOiBB dHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stCgkJCUNo YW5nZWQ6IE1STC0gUHJlc0RldC0gTGlua1N0YXRlLQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxl LSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtCgkJUm9vdENh cDogQ1JTVmlzaWJsZS0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQ ZW5kaW5nLQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQkMsIFRpbWVvdXRE aXMrLCBMVFItLCBPQkZGIE5vdCBTdXBwb3J0ZWQgQVJJRndkLQoJCURldkN0bDI6IENvbXBsZXRp b24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLSwgTFRSLSwgT0JGRiBEaXNhYmxl ZCBBUklGd2QtCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBs aWFuY2UtIFNwZWVkRGlzLQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJh bmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFu Y2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVs OiAtMy41ZEIsIEVxdWFsaXphdGlvbkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkg RXF1YWxpemF0aW9uUGhhc2UyLSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlv blJlcXVlc3QtCglDYXBhYmlsaXRpZXM6IFs4MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNr YWJsZS0gNjRiaXQtCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGll czogWzkwXSBTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSA1MDAxCglDYXBh YmlsaXRpZXM6IFthMF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFnczogUE1FQ2xr LSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2Nv bGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg UE1FLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0CgowMDoxYy43IFBDSSBicmlkZ2U6 IEludGVsIENvcnBvcmF0aW9uIDcgU2VyaWVzL0MyMTAgU2VyaWVzIENoaXBzZXQgRmFtaWx5IFBD SSBFeHByZXNzIFJvb3QgUG9ydCA4IChyZXYgYzQpIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVjb2Rl XSkKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6 IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8 VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBM aW5lIFNpemU6IDY0IGJ5dGVzCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wNywgc3Vib3Jk aW5hdGU9MDcsIHNlYy1sYXRlbmN5PTAKCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw Y2ZmZgoJTWVtb3J5IGJlaGluZCBicmlkZ2U6IGY3ODAwMDAwLWY3OGZmZmZmCglTZWNvbmRhcnkg c3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFi b3J0LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eS0gU0VSUi0gTm9J U0EtIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rt ci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVz cyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4 IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFn LSBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9u LUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5j LSBBdXhQd3ItIE5vU25vb3AtCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEy OCBieXRlcwoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVx LSBBdXhQd3IrIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzgsIFNwZWVkIDVHVC9zLCBXaWR0 aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw1MTJucywgTDEgPDE2dXMKCQkJQ2xvY2tQ TS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJD QiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gtIENsb2Nr UE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgNUdUL3MsIFdp ZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQt CgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1 Zy0gU3VycHJpc2UtCgkJCVNsb3QgIzcsIFBvd2VyTGltaXQgMTAuMDAwVzsgSW50ZXJsb2NrLSBO b0NvbXBsKwoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0g Q21kQ3BsdC0gSFBJcnEtIExpbmtDaGctCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdy SW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4t IFBvd2VyRmx0LSBNUkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0KCQkJQ2hhbmdlZDog TVJMLSBQcmVzRGV0LSBMaW5rU3RhdGUtCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5v bi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290Q2FwOiBDUlNW aXNpYmxlLQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmct CgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBCQywgVGltZW91dERpcyssIExU Ui0sIE9CRkYgTm90IFN1cHBvcnRlZCBBUklGd2QtCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1l b3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtLCBMVFItLCBPQkZGIERpc2FibGVkIEFSSUZ3 ZC0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0g U3BlZWREaXMtCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVu dGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBEZS1l bXBoYXNpczogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEIs IEVxdWFsaXphdGlvbkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkgRXF1YWxpemF0 aW9uUGhhc2UyLSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlvblJlcXVlc3Qt CglDYXBhYmlsaXRpZXM6IFs4MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi aXQtCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzkwXSBT dWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSA1MDAxCglDYXBhYmlsaXRpZXM6 IFthMF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx LSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQoJCVN0 YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJS2Vy bmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0CgowMDoxZC4wIFVTQiBjb250cm9sbGVyOiBJbnRl bCBDb3Jwb3JhdGlvbiA3IFNlcmllcy9DMjEwIFNlcmllcyBDaGlwc2V0IEZhbWlseSBVU0IgRW5o YW5jZWQgSG9zdCBDb250cm9sbGVyICMxIChyZXYgMDQpIChwcm9nLWlmIDIwIFtFSENJXSkKCVN1 YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xvZ3kgRGV2aWNlIDUwMDYKCUNvbnRyb2w6IEkvTy0g TWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3Rl cHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g RmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt ID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCUludGVycnVwdDogcGluIEEgcm91dGVk IHRvIElSUSAyMwoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmN2MxNzAwMCAoMzItYml0LCBub24tcHJl ZmV0Y2hhYmxlKSBbc2l6ZT0xS10KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50 IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTM3NW1B IFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0g UE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzU4XSBEZWJ1 ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBhMAoJQ2FwYWJpbGl0aWVzOiBbOThdIFBDSSBBZHZhbmNl ZCBGZWF0dXJlcwoJCUFGQ2FwOiBUUCsgRkxSKwoJCUFGQ3RybDogRkxSLQoJCUFGU3RhdHVzOiBU UC0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrCgowMDoxZi4wIElTQSBicmlkZ2U6IElu dGVsIENvcnBvcmF0aW9uIFo3NyBFeHByZXNzIENoaXBzZXQgTFBDIENvbnRyb2xsZXIgKHJldiAw NCkKCVN1YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xvZ3kgRGV2aWNlIDUwMDEKCUNvbnRyb2w6 IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVy ci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHot IFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxN QWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCUNhcGFiaWxpdGllczogW2Uw XSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IExlbj0wYyA8Pz4KCUtlcm5lbCBkcml2ZXIg aW4gdXNlOiBscGNfaWNoCgowMDoxZi4yIFJBSUQgYnVzIGNvbnRyb2xsZXI6IEludGVsIENvcnBv cmF0aW9uIDgyODAxIFNBVEEgQ29udHJvbGxlciBbUkFJRCBtb2RlXSAocmV2IDA0KQoJU3Vic3lz dGVtOiBHaWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgYjAwNQoJQ29udHJvbDogSS9PKyBNZW0r IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGlu Zy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0 QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF UlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8g SVJRIDkyCglSZWdpb24gMDogSS9PIHBvcnRzIGF0IGYwYjAgW3NpemU9OF0KCVJlZ2lvbiAxOiBJ L08gcG9ydHMgYXQgZjBhMCBbc2l6ZT00XQoJUmVnaW9uIDI6IEkvTyBwb3J0cyBhdCBmMDkwIFtz aXplPThdCglSZWdpb24gMzogSS9PIHBvcnRzIGF0IGYwODAgW3NpemU9NF0KCVJlZ2lvbiA0OiBJ L08gcG9ydHMgYXQgZjA2MCBbc2l6ZT0zMl0KCVJlZ2lvbiA1OiBNZW1vcnkgYXQgZjdjMTYwMDAg KDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MktdCglDYXBhYmlsaXRpZXM6IFs4MF0g TVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCgkJQWRkcmVzczogZmVlMDAy YjggIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzcwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNp b24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDAt LEQxLSxEMi0sRDNob3QrLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFi bGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFthOF0gU0FUQSBIQkEgdjEu MCBCQVI0IE9mZnNldD0wMDAwMDAwNAoJQ2FwYWJpbGl0aWVzOiBbYjBdIFBDSSBBZHZhbmNlZCBG ZWF0dXJlcwoJCUFGQ2FwOiBUUCsgRkxSKwoJCUFGQ3RybDogRkxSLQoJCUFGU3RhdHVzOiBUUC0K CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNpCgowMDoxZi4zIFNNQnVzOiBJbnRlbCBDb3Jwb3Jh dGlvbiA3IFNlcmllcy9DMjEwIFNlcmllcyBDaGlwc2V0IEZhbWlseSBTTUJ1cyBDb250cm9sbGVy IChyZXYgMDQpCglTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSA1MDAxCglD b250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29w LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAt IDY2TUh6LSBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFi b3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRl ZCB0byBJUlEgMTgKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjdjMTUwMDAgKDY0LWJpdCwgbm9uLXBy ZWZldGNoYWJsZSkgW3NpemU9MjU2XQoJUmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBmMDQwIFtzaXpl PTMyXQoKMDE6MDAuMCBWR0EgY29tcGF0aWJsZSBjb250cm9sbGVyOiBBZHZhbmNlZCBNaWNybyBE ZXZpY2VzIFtBTURdIG5lZSBBVEkgVGFoaXRpIFBSTyBbUmFkZW9uIEhEIDc5NTBdIChwcm9nLWlm IDAwIFtWR0EgY29udHJvbGxlcl0pCglTdWJzeXN0ZW06IFBDIFBhcnRuZXIgTGltaXRlZCBEZXZp Y2UgMzAwMAoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0 YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENh Y2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAx NgoJUmVnaW9uIDA6IE1lbW9yeSBhdCBlMDAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtz aXplPTI1Nk1dCglSZWdpb24gMjogTWVtb3J5IGF0IGY3YjAwMDAwICg2NC1iaXQsIG5vbi1wcmVm ZXRjaGFibGUpIFtzaXplPTI1NktdCglSZWdpb24gNDogSS9PIHBvcnRzIGF0IGUwMDAgW3NpemU9 MjU2XQoJRXhwYW5zaW9uIFJPTSBhdCBmN2I0MDAwMCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdCglD YXBhYmlsaXRpZXM6IFs0OF0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBMZW49MDggPD8+ CglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczog UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMSssRDIrLEQzaG90 KyxEM2NvbGQtKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj YWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdhY3kgRW5kcG9p bnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBM YXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0ZWQKCQkJRXh0VGFnKyBBdHRuQnRuLSBBdHRuSW5k LSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3Rh YmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnKyBQ aGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJl YWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBV bnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgOEdU L3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMKCQkJ Q2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gt IENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41 R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQt IEFCV01nbXQtCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBU aW1lb3V0RGlzLSwgTFRSLSwgT0JGRiBOb3QgU3VwcG9ydGVkCgkJRGV2Q3RsMjogQ29tcGxldGlv biBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtLCBMVFItLCBPQkZGIERpc2FibGVk CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDhHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNw ZWVkRGlzLQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRl ck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1w aGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEIs IEVxdWFsaXphdGlvbkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkgRXF1YWxpemF0 aW9uUGhhc2UyLSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlvblJlcXVlc3Qt CglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi aXQrCgkJQWRkcmVzczogMDAwMDAwMDBmZWUwMDM1OCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0aWVz OiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVu PTAxMCA8Pz4KCUNhcGFiaWxpdGllczogWzE1MCB2Ml0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5n CgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21w bHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCVVFTXNrOglETFAt IFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxm VExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRVN2cnQ6CURMUCsgU0RFUysgVExQLSBG Q1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVu c3VwUmVxLSBBQ1NWaW9sLQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zl ci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAt IFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisKCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBv aW50ZXI6IDAwLCBHZW5DYXArIENHZW5Fbi0gQ2hrQ2FwKyBDaGtFbi0KCUNhcGFiaWxpdGllczog WzI3MCB2MV0gIzE5CglDYXBhYmlsaXRpZXM6IFsyYjAgdjFdIEFkZHJlc3MgVHJhbnNsYXRpb24g U2VydmljZSAoQVRTKQoJCUFUU0NhcDoJSW52YWxpZGF0ZSBRdWV1ZSBEZXB0aDogMDAKCQlBVFND dGw6CUVuYWJsZS0sIFNtYWxsZXN0IFRyYW5zbGF0aW9uIFVuaXQ6IDAwCglDYXBhYmlsaXRpZXM6 IFsyYzAgdjFdICMxMwoJQ2FwYWJpbGl0aWVzOiBbMmQwIHYxXSAjMWIKCUtlcm5lbCBkcml2ZXIg aW4gdXNlOiBwY2liYWNrCgowMTowMC4xIEF1ZGlvIGRldmljZTogQWR2YW5jZWQgTWljcm8gRGV2 aWNlcyBbQU1EXSBuZWUgQVRJIFRhaGl0aSBYVCBIRE1JIEF1ZGlvIFtSYWRlb24gSEQgNzk3MCBT ZXJpZXNdCglTdWJzeXN0ZW06IFBDIFBhcnRuZXIgTGltaXRlZCBEZXZpY2UgYWFhMAoJQ29udHJv bDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFy RXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1I ei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxN QWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog NjQgYnl0ZXMKCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAxNwoJUmVnaW9uIDA6IE1l bW9yeSBhdCBmN2I2MDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNktdCglD YXBhYmlsaXRpZXM6IFs0OF0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBMZW49MDggPD8+ CglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczog UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90 LSxEM2NvbGQtKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj YWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdhY3kgRW5kcG9p bnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBM YXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0ZWQKCQkJRXh0VGFnKyBBdHRuQnRuLSBBdHRuSW5k LSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3Rh YmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQ aGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJl YWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJyLSBV bnN1cHBSZXErIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgOEdU L3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMKCQkJ Q2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gt IENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41 R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQt IEFCV01nbXQtCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBU aW1lb3V0RGlzLSwgTFRSLSwgT0JGRiBOb3QgU3VwcG9ydGVkCgkJRGV2Q3RsMjogQ29tcGxldGlv biBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtLCBMVFItLCBPQkZGIERpc2FibGVk CgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCLCBFcXVhbGl6YXRp b25Db21wbGV0ZS0sIEVxdWFsaXphdGlvblBoYXNlMS0KCQkJIEVxdWFsaXphdGlvblBoYXNlMi0s IEVxdWFsaXphdGlvblBoYXNlMy0sIExpbmtFcXVhbGl6YXRpb25SZXF1ZXN0LQoJQ2FwYWJpbGl0 aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJl c3M6IDAwMDAwMDAwZmVlMDAzNzggIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzEwMCB2MV0g VmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglD YXBhYmlsaXRpZXM6IFsxNTAgdjJdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3RhOglE TFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBN YWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAt IEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0g VW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0gRkNQKyBDbXBsdFRP LSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBVbnN1cFJlcS0gQUNT VmlvbC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQt IE5vbkZhdGFsRXJyKwoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0g VGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwg R2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4tCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp YmFjawoKMDM6MDAuMCBVU0IgY29udHJvbGxlcjogVklBIFRlY2hub2xvZ2llcywgSW5jLiBEZXZp Y2UgMzQzMiAocmV2IDAzKSAocHJvZy1pZiAzMCBbWEhDSV0pCglTdWJzeXN0ZW06IEdpZ2EtYnl0 ZSBUZWNobm9sb2d5IERldmljZSA1MDA3CglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBT cGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0 QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0g REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4 LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50ZXJydXB0OiBwaW4g QSByb3V0ZWQgdG8gSVJRIDk1CglSZWdpb24gMDogTWVtb3J5IGF0IGY3YTAwMDAwICgzMi1iaXQs IG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQoJQ2FwYWJpbGl0aWVzOiBbODBdIFBvd2VyIE1h bmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJl bnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9T b2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBb OTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAw MDAwMDAwZmVlMDAzMTggIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogW2M0XSBFeHByZXNzICh2 MikgRW5kcG9pbnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50 RnVuYyAwLCBMYXRlbmN5IEwwcyA8MXVzLCBMMSA8MTZ1cwoJCQlFeHRUYWctIEF0dG5CdG4tIEF0 dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29y cmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkLSBFeHRU YWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg TWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxF cnItIFVuc3VwcFJlcS0gQXV4UHdyKyBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVl ZCA1R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8MnVzLCBMMSA8MTZ1 cwoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBE aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQoJCQlFeHRT eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVl ZCA1R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdt dC0gQUJXTWdtdC0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEIsIFRpbWVv dXREaXMrLCBMVFItLCBPQkZGIE5vdCBTdXBwb3J0ZWQKCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRp bWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0sIExUUi0sIE9CRkYgRGlzYWJsZWQKCQlM bmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWRE aXMtCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9k aWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNp czogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEIsIEVxdWFs aXphdGlvbkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkgRXF1YWxpemF0aW9uUGhh c2UyLSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlvblJlcXVlc3QtCglDYXBh YmlsaXRpZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3RhOglETFAt IFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxm VExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAtIEZD UC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5z dXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0gRkNQKyBDbXBsdFRPLSBD bXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlv bC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5v bkZhdGFsRXJyLQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGlt ZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2Vu Q2FwLSBDR2VuRW4tIENoa0NhcC0gQ2hrRW4tCglLZXJuZWwgZHJpdmVyIGluIHVzZTogeGhjaV9o Y2QKCjA0OjAwLjAgUENJIGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24gODI4MDEgUENJIEJyaWRn ZSAocmV2IDQxKSAocHJvZy1pZiAwMSBbU3VidHJhY3RpdmUgZGVjb2RlXSkKCUNvbnRyb2w6IEkv TysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0g U3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVE Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0 LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5 dGVzCglCdXM6IHByaW1hcnk9MDQsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1s YXRlbmN5PTMyCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1IeisgRmFzdEIyQi0gUGFyRXJyLSBERVZT RUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrIDxTRVJSLSA8UEVSUi0KCUJyaWRn ZUN0bDogUGFyaXR5LSBTRVJSLSBOb0lTQS0gVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0K CQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yKyBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNh cGFiaWxpdGllczogWzkwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVD bGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTU1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxE M2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxl PTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbYTBdIFN1YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xv Z3kgRGV2aWNlIDg4OTIKCjA2OjAwLjAgRXRoZXJuZXQgY29udHJvbGxlcjogQXRoZXJvcyBDb21t dW5pY2F0aW9ucyBJbmMuIEFSODE2MSBHaWdhYml0IEV0aGVybmV0IChyZXYgMTApCglTdWJzeXN0 ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSBlMDAwCglDb250cm9sOiBJL08rIE1lbSsg QnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5n LSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RC MkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt IDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50 ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDExCglSZWdpb24gMDogTWVtb3J5IGF0IGY3OTAw MDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1NktdCglSZWdpb24gMjogSS9P IHBvcnRzIGF0IGQwMDAgW3NpemU9MTI4XQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFn ZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9 Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0 UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThd IEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDQwOTYg Ynl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZAoJ CQlFeHRUYWctIEF0dG5CdG4rIEF0dG5JbmQrIFB3ckluZCsgUkJFKyBGTFJlc2V0LQoJCURldkN0 bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y dGVkLQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQoJCQlN YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJF cnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyKyBUcmFuc1BlbmQtCgkJ TG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh dGVuY3kgTDAgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQKCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExM QWN0UmVwLSBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNh YmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g QldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy LSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCUNhcGFiaWxpdGll czogW2MwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xNiBNYXNrYWJsZSsgNjRiaXQrCgkJQWRkcmVz czogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMAoJCU1hc2tpbmc6IDAwMDAwMDAwICBQZW5k aW5nOiAwMDAwMDAwMAoJQ2FwYWJpbGl0aWVzOiBbZDhdIE1TSS1YOiBFbmFibGUtIENvdW50PTE2 IE1hc2tlZC0KCQlWZWN0b3IgdGFibGU6IEJBUj0wIG9mZnNldD0wMDAwMjAwMAoJCVBCQTogQkFS PTAgb2Zmc2V0PTAwMDAzMDAwCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9y IFJlcG9ydGluZwoJCVVFU3RhOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFi cnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlV RU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0g UnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNE RVMrIFRMUC0gRkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQ KyBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExM UC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyLQoJCUNFTXNrOglSeEVyci0gQmFkVExQ LSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglGaXJz dCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4tCglDYXBh YmlsaXRpZXM6IFsxODAgdjFdIERldmljZSBTZXJpYWwgTnVtYmVyIGZmLTVjLTg1LWQxLTkwLTJi LTM0LWZmCgowNzowMC4wIElERSBpbnRlcmZhY2U6IE1hcnZlbGwgVGVjaG5vbG9neSBHcm91cCBM dGQuIDg4U0U5MTcyIFNBVEEgSUlJIDZHYi9zIFJBSUQgQ29udHJvbGxlciAocmV2IDExKSAocHJv Zy1pZiA4ZiBbTWFzdGVyIFNlY1AgU2VjTyBQcmlQIFByaU9dKQoJU3Vic3lzdGVtOiBHaWdhLWJ5 dGUgVGVjaG5vbG9neSBEZXZpY2UgYjAwMAoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFz dEIyQi0gRGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U eC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGlu IEEgcm91dGVkIHRvIElSUSA5MwoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBjMDQwIFtzaXplPThd CglSZWdpb24gMTogSS9PIHBvcnRzIGF0IGMwMzAgW3NpemU9NF0KCVJlZ2lvbiAyOiBJL08gcG9y dHMgYXQgYzAyMCBbc2l6ZT04XQoJUmVnaW9uIDM6IEkvTyBwb3J0cyBhdCBjMDEwIFtzaXplPTRd CglSZWdpb24gNDogSS9PIHBvcnRzIGF0IGMwMDAgW3NpemU9MTZdCglSZWdpb24gNTogTWVtb3J5 IGF0IGY3ODEwMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTUxMl0KCUV4cGFu c2lvbiBST00gYXQgZjc4MDAwMDAgW2Rpc2FibGVkXSBbc2l6ZT02NEtdCglDYXBhYmlsaXRpZXM6 IFs0MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx LSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90KyxEM2NvbGQtKQoJCVN0 YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2Fw YWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQoJ CUFkZHJlc3M6IGZlZTAwMmQ4ICBEYXRhOiAwMDAwCglDYXBhYmlsaXRpZXM6IFs3MF0gRXhwcmVz cyAodjIpIExlZ2FjeSBFbmRwb2ludCwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDUxMiBi eXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDwxdXMsIEwxIDw4dXMKCQkJRXh0VGFnLSBB dHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBl cnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4 ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcC0KCQkJTWF4UGF5bG9hZCAx MjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJF cnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9y dCAjMCwgU3BlZWQgNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEy bnMsIEwxIDw2NHVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtCgkJTG5r Q3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1D bGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0KCQlM bmtTdGE6CVNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj dGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90 IFN1cHBvcnRlZCwgVGltZW91dERpcyssIExUUi0sIE9CRkYgTm90IFN1cHBvcnRlZAoJCURldkN0 bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLSwgTFRSLSwg T0JGRiBEaXNhYmxlZAoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJD b21wbGlhbmNlLSBTcGVlZERpcy0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21w bGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBM ZXZlbDogLTZkQiwgRXF1YWxpemF0aW9uQ29tcGxldGUtLCBFcXVhbGl6YXRpb25QaGFzZTEtCgkJ CSBFcXVhbGl6YXRpb25QaGFzZTItLCBFcXVhbGl6YXRpb25QaGFzZTMtLCBMaW5rRXF1YWxpemF0 aW9uUmVxdWVzdC0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0 aW5nCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54 Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCVVFTXNrOglE TFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBN YWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRVN2cnQ6CURMUCsgU0RFUysgVExQ LSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMt IFVuc3VwUmVxLSBBQ1NWaW9sLQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xs b3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnItCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERM TFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisKCQlBRVJDYXA6CUZpcnN0IEVycm9y IFBvaW50ZXI6IDAwLCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2FwLSBDaGtFbi0KCUtlcm5lbCBkcml2 ZXIgaW4gdXNlOiBhaGNpCgo= --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name=uname-txt Content-Disposition: attachment; filename=uname-txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1vq3 TGludXggbG9jYWxob3N0LmxvY2FsZG9tYWluIDMuNi4xMC00LmZjMTgueDg2XzY0ICMxIFNNUCBU dWUgRmViIDE5IDIxOjEyOjE0IEJSVCAyMDEzIHg4Nl82NCB4ODZfNjQgeDg2XzY0IEdOVS9MaW51 eAo= --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name="config-3.6.10-4.fc18.x86_64" Content-Disposition: attachment; filename="config-3.6.10-4.fc18.x86_64" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1vz4 IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4L3g4 Nl82NCAzLjYuMTAtNC5mYzE4Lng4Nl82NCBLZXJuZWwgQ29uZmlndXJhdGlvbgojCkNPTkZJR182 NEJJVD15CiMgQ09ORklHX1g4Nl8zMiBpcyBub3Qgc2V0CkNPTkZJR19YODZfNjQ9eQpDT05GSUdf WDg2PXkKQ09ORklHX0lOU1RSVUNUSU9OX0RFQ09ERVI9eQpDT05GSUdfT1VUUFVUX0ZPUk1BVD0i ZWxmNjQteDg2LTY0IgpDT05GSUdfQVJDSF9ERUZDT05GSUc9ImFyY2gveDg2L2NvbmZpZ3MveDg2 XzY0X2RlZmNvbmZpZyIKQ09ORklHX0xPQ0tERVBfU1VQUE9SVD15CkNPTkZJR19TVEFDS1RSQUNF X1NVUFBPUlQ9eQpDT05GSUdfSEFWRV9MQVRFTkNZVE9QX1NVUFBPUlQ9eQpDT05GSUdfTU1VPXkK Q09ORklHX05FRURfRE1BX01BUF9TVEFURT15CkNPTkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpD T05GSUdfR0VORVJJQ19JU0FfRE1BPXkKQ09ORklHX0dFTkVSSUNfQlVHPXkKQ09ORklHX0dFTkVS SUNfQlVHX1JFTEFUSVZFX1BPSU5URVJTPXkKQ09ORklHX0dFTkVSSUNfSFdFSUdIVD15CkNPTkZJ R19BUkNIX01BWV9IQVZFX1BDX0ZEQz15CiMgQ09ORklHX1JXU0VNX0dFTkVSSUNfU1BJTkxPQ0sg aXMgbm90IHNldApDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklUSE09eQpDT05GSUdfR0VORVJJ Q19DQUxJQlJBVEVfREVMQVk9eQpDT05GSUdfQVJDSF9IQVNfQ1BVX1JFTEFYPXkKQ09ORklHX0FS Q0hfSEFTX0RFRkFVTFRfSURMRT15CkNPTkZJR19BUkNIX0hBU19DQUNIRV9MSU5FX1NJWkU9eQpD T05GSUdfQVJDSF9IQVNfQ1BVX0FVVE9QUk9CRT15CkNPTkZJR19IQVZFX1NFVFVQX1BFUl9DUFVf QVJFQT15CkNPTkZJR19ORUVEX1BFUl9DUFVfRU1CRURfRklSU1RfQ0hVTks9eQpDT05GSUdfTkVF RF9QRVJfQ1BVX1BBR0VfRklSU1RfQ0hVTks9eQpDT05GSUdfQVJDSF9ISUJFUk5BVElPTl9QT1NT SUJMRT15CkNPTkZJR19BUkNIX1NVU1BFTkRfUE9TU0lCTEU9eQpDT05GSUdfWk9ORV9ETUEzMj15 CkNPTkZJR19BVURJVF9BUkNIPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfT1BUSU1JWkVEX0lOTElO SU5HPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfREVCVUdfUEFHRUFMTE9DPXkKQ09ORklHX0hBVkVf SU5URUxfVFhUPXkKQ09ORklHX1g4Nl82NF9TTVA9eQpDT05GSUdfWDg2X0hUPXkKQ09ORklHX0FS Q0hfSFdFSUdIVF9DRkxBR1M9Ii1mY2FsbC1zYXZlZC1yZGkgLWZjYWxsLXNhdmVkLXJzaSAtZmNh bGwtc2F2ZWQtcmR4IC1mY2FsbC1zYXZlZC1yY3ggLWZjYWxsLXNhdmVkLXI4IC1mY2FsbC1zYXZl ZC1yOSAtZmNhbGwtc2F2ZWQtcjEwIC1mY2FsbC1zYXZlZC1yMTEiCkNPTkZJR19BUkNIX0NQVV9Q Uk9CRV9SRUxFQVNFPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfVVBST0JFUz15CkNPTkZJR19ERUZD T05GSUdfTElTVD0iL2xpYi9tb2R1bGVzLyRVTkFNRV9SRUxFQVNFLy5jb25maWciCkNPTkZJR19I QVZFX0lSUV9XT1JLPXkKQ09ORklHX0lSUV9XT1JLPXkKQ09ORklHX0JVSUxEVElNRV9FWFRBQkxF X1NPUlQ9eQoKIwojIEdlbmVyYWwgc2V0dXAKIwpDT05GSUdfRVhQRVJJTUVOVEFMPXkKQ09ORklH X0lOSVRfRU5WX0FSR19MSU1JVD0zMgpDT05GSUdfQ1JPU1NfQ09NUElMRT0iIgpDT05GSUdfTE9D QUxWRVJTSU9OPSIiCiMgQ09ORklHX0xPQ0FMVkVSU0lPTl9BVVRPIGlzIG5vdCBzZXQKQ09ORklH X0hBVkVfS0VSTkVMX0daSVA9eQpDT05GSUdfSEFWRV9LRVJORUxfQlpJUDI9eQpDT05GSUdfSEFW RV9LRVJORUxfTFpNQT15CkNPTkZJR19IQVZFX0tFUk5FTF9YWj15CkNPTkZJR19IQVZFX0tFUk5F TF9MWk89eQpDT05GSUdfS0VSTkVMX0daSVA9eQojIENPTkZJR19LRVJORUxfQlpJUDIgaXMgbm90 IHNldAojIENPTkZJR19LRVJORUxfTFpNQSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9YWiBp cyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9MWk8gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9I T1NUTkFNRT0iKG5vbmUpIgpDT05GSUdfU1dBUD15CkNPTkZJR19TWVNWSVBDPXkKQ09ORklHX1NZ U1ZJUENfU1lTQ1RMPXkKQ09ORklHX1BPU0lYX01RVUVVRT15CkNPTkZJR19QT1NJWF9NUVVFVUVf U1lTQ1RMPXkKQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1Q9eQpDT05GSUdfQlNEX1BST0NFU1NfQUND VF9WMz15CkNPTkZJR19GSEFORExFPXkKQ09ORklHX1RBU0tTVEFUUz15CkNPTkZJR19UQVNLX0RF TEFZX0FDQ1Q9eQpDT05GSUdfVEFTS19YQUNDVD15CkNPTkZJR19UQVNLX0lPX0FDQ09VTlRJTkc9 eQpDT05GSUdfQVVESVQ9eQpDT05GSUdfQVVESVRTWVNDQUxMPXkKQ09ORklHX0FVRElUX1dBVENI PXkKQ09ORklHX0FVRElUX1RSRUU9eQojIENPTkZJR19BVURJVF9MT0dJTlVJRF9JTU1VVEFCTEUg aXMgbm90IHNldApDT05GSUdfSEFWRV9HRU5FUklDX0hBUkRJUlFTPXkKCiMKIyBJUlEgc3Vic3lz dGVtCiMKQ09ORklHX0dFTkVSSUNfSEFSRElSUVM9eQpDT05GSUdfR0VORVJJQ19JUlFfUFJPQkU9 eQpDT05GSUdfR0VORVJJQ19JUlFfU0hPVz15CkNPTkZJR19HRU5FUklDX1BFTkRJTkdfSVJRPXkK Q09ORklHX0lSUV9ET01BSU49eQojIENPTkZJR19JUlFfRE9NQUlOX0RFQlVHIGlzIG5vdCBzZXQK Q09ORklHX0lSUV9GT1JDRURfVEhSRUFESU5HPXkKQ09ORklHX1NQQVJTRV9JUlE9eQpDT05GSUdf Q0xPQ0tTT1VSQ0VfV0FUQ0hET0c9eQpDT05GSUdfQVJDSF9DTE9DS1NPVVJDRV9EQVRBPXkKQ09O RklHX0dFTkVSSUNfVElNRV9WU1lTQ0FMTD15CkNPTkZJR19HRU5FUklDX0NMT0NLRVZFTlRTPXkK Q09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfQlVJTEQ9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VW RU5UU19CUk9BRENBU1Q9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UU19NSU5fQURKVVNUPXkK Q09ORklHX0dFTkVSSUNfQ01PU19VUERBVEU9eQoKIwojIFRpbWVycyBzdWJzeXN0ZW0KIwpDT05G SUdfVElDS19PTkVTSE9UPXkKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVSUz15 CgojCiMgUkNVIFN1YnN5c3RlbQojCkNPTkZJR19UUkVFX1JDVT15CiMgQ09ORklHX1BSRUVNUFRf UkNVIGlzIG5vdCBzZXQKQ09ORklHX1JDVV9GQU5PVVQ9NjQKQ09ORklHX1JDVV9GQU5PVVRfTEVB Rj0xNgojIENPTkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUkNVX0ZB U1RfTk9fSFogaXMgbm90IHNldAojIENPTkZJR19UUkVFX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMg Q09ORklHX0lLQ09ORklHIGlzIG5vdCBzZXQKQ09ORklHX0xPR19CVUZfU0hJRlQ9MTgKQ09ORklH X0hBVkVfVU5TVEFCTEVfU0NIRURfQ0xPQ0s9eQpDT05GSUdfQ0dST1VQUz15CiMgQ09ORklHX0NH Uk9VUF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19DR1JPVVBfRlJFRVpFUj15CkNPTkZJR19DR1JP VVBfREVWSUNFPXkKQ09ORklHX0NQVVNFVFM9eQpDT05GSUdfUFJPQ19QSURfQ1BVU0VUPXkKQ09O RklHX0NHUk9VUF9DUFVBQ0NUPXkKQ09ORklHX1JFU09VUkNFX0NPVU5URVJTPXkKQ09ORklHX01F TUNHPXkKQ09ORklHX01FTUNHX1NXQVA9eQojIENPTkZJR19NRU1DR19TV0FQX0VOQUJMRUQgaXMg bm90IHNldApDT05GSUdfTUVNQ0dfS01FTT15CiMgQ09ORklHX0NHUk9VUF9IVUdFVExCIGlzIG5v dCBzZXQKQ09ORklHX0NHUk9VUF9QRVJGPXkKQ09ORklHX0NHUk9VUF9TQ0hFRD15CkNPTkZJR19G QUlSX0dST1VQX1NDSEVEPXkKQ09ORklHX0NGU19CQU5EV0lEVEg9eQpDT05GSUdfUlRfR1JPVVBf U0NIRUQ9eQpDT05GSUdfQkxLX0NHUk9VUD15CiMgQ09ORklHX0RFQlVHX0JMS19DR1JPVVAgaXMg bm90IHNldAojIENPTkZJR19DSEVDS1BPSU5UX1JFU1RPUkUgaXMgbm90IHNldApDT05GSUdfTkFN RVNQQUNFUz15CkNPTkZJR19VVFNfTlM9eQpDT05GSUdfSVBDX05TPXkKQ09ORklHX1BJRF9OUz15 CkNPTkZJR19ORVRfTlM9eQpDT05GSUdfU0NIRURfQVVUT0dST1VQPXkKQ09ORklHX01NX09XTkVS PXkKIyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0CkNPTkZJR19SRUxBWT15CkNP TkZJR19CTEtfREVWX0lOSVRSRD15CkNPTkZJR19JTklUUkFNRlNfU09VUkNFPSIiCkNPTkZJR19S RF9HWklQPXkKQ09ORklHX1JEX0JaSVAyPXkKQ09ORklHX1JEX0xaTUE9eQpDT05GSUdfUkRfWFo9 eQpDT05GSUdfUkRfTFpPPXkKIyBDT05GSUdfQ0NfT1BUSU1JWkVfRk9SX1NJWkUgaXMgbm90IHNl dApDT05GSUdfU1lTQ1RMPXkKQ09ORklHX0FOT05fSU5PREVTPXkKIyBDT05GSUdfRVhQRVJUIGlz IG5vdCBzZXQKQ09ORklHX1VJRDE2PXkKIyBDT05GSUdfU1lTQ1RMX1NZU0NBTEwgaXMgbm90IHNl dApDT05GSUdfS0FMTFNZTVM9eQpDT05GSUdfS0FMTFNZTVNfQUxMPXkKQ09ORklHX0hPVFBMVUc9 eQpDT05GSUdfUFJJTlRLPXkKQ09ORklHX0JVRz15CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJR19Q Q1NQS1JfUExBVEZPUk09eQpDT05GSUdfSEFWRV9QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfQkFT RV9GVUxMPXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0VQT0xMPXkKQ09ORklHX1NJR05BTEZEPXkK Q09ORklHX1RJTUVSRkQ9eQpDT05GSUdfRVZFTlRGRD15CkNPTkZJR19TSE1FTT15CkNPTkZJR19B SU89eQojIENPTkZJR19FTUJFRERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZfRVZFTlRT PXkKCiMKIyBLZXJuZWwgUGVyZm9ybWFuY2UgRXZlbnRzIEFuZCBDb3VudGVycwojCkNPTkZJR19Q RVJGX0VWRU5UUz15CiMgQ09ORklHX0RFQlVHX1BFUkZfVVNFX1ZNQUxMT0MgaXMgbm90IHNldApD T05GSUdfVk1fRVZFTlRfQ09VTlRFUlM9eQpDT05GSUdfUENJX1FVSVJLUz15CkNPTkZJR19TTFVC X0RFQlVHPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NMQUIgaXMg bm90IHNldApDT05GSUdfU0xVQj15CkNPTkZJR19QUk9GSUxJTkc9eQpDT05GSUdfVFJBQ0VQT0lO VFM9eQpDT05GSUdfT1BST0ZJTEU9bQpDT05GSUdfT1BST0ZJTEVfRVZFTlRfTVVMVElQTEVYPXkK Q09ORklHX0hBVkVfT1BST0ZJTEU9eQpDT05GSUdfT1BST0ZJTEVfTk1JX1RJTUVSPXkKQ09ORklH X0tQUk9CRVM9eQpDT05GSUdfSlVNUF9MQUJFTD15CkNPTkZJR19PUFRQUk9CRVM9eQpDT05GSUdf VVBST0JFUz15CkNPTkZJR19IQVZFX0VGRklDSUVOVF9VTkFMSUdORURfQUNDRVNTPXkKQ09ORklH X0tSRVRQUk9CRVM9eQpDT05GSUdfVVNFUl9SRVRVUk5fTk9USUZJRVI9eQpDT05GSUdfSEFWRV9J T1JFTUFQX1BST1Q9eQpDT05GSUdfSEFWRV9LUFJPQkVTPXkKQ09ORklHX0hBVkVfS1JFVFBST0JF Uz15CkNPTkZJR19IQVZFX09QVFBST0JFUz15CkNPTkZJR19IQVZFX0FSQ0hfVFJBQ0VIT09LPXkK Q09ORklHX0hBVkVfRE1BX0FUVFJTPXkKQ09ORklHX1VTRV9HRU5FUklDX1NNUF9IRUxQRVJTPXkK Q09ORklHX0dFTkVSSUNfU01QX0lETEVfVEhSRUFEPXkKQ09ORklHX0hBVkVfUkVHU19BTkRfU1RB Q0tfQUNDRVNTX0FQST15CkNPTkZJR19IQVZFX0RNQV9BUElfREVCVUc9eQpDT05GSUdfSEFWRV9I V19CUkVBS1BPSU5UPXkKQ09ORklHX0hBVkVfTUlYRURfQlJFQUtQT0lOVFNfUkVHUz15CkNPTkZJ R19IQVZFX1VTRVJfUkVUVVJOX05PVElGSUVSPXkKQ09ORklHX0hBVkVfUEVSRl9FVkVOVFNfTk1J PXkKQ09ORklHX0hBVkVfQVJDSF9KVU1QX0xBQkVMPXkKQ09ORklHX0FSQ0hfSEFWRV9OTUlfU0FG RV9DTVBYQ0hHPXkKQ09ORklHX0hBVkVfQUxJR05FRF9TVFJVQ1RfUEFHRT15CkNPTkZJR19IQVZF X0NNUFhDSEdfTE9DQUw9eQpDT05GSUdfSEFWRV9DTVBYQ0hHX0RPVUJMRT15CkNPTkZJR19BUkNI X1dBTlRfQ09NUEFUX0lQQ19QQVJTRV9WRVJTSU9OPXkKQ09ORklHX0FSQ0hfV0FOVF9PTERfQ09N UEFUX0lQQz15CkNPTkZJR19IQVZFX0FSQ0hfU0VDQ09NUF9GSUxURVI9eQpDT05GSUdfU0VDQ09N UF9GSUxURVI9eQoKIwojIEdDT1YtYmFzZWQga2VybmVsIHByb2ZpbGluZwojCiMgQ09ORklHX0dD T1ZfS0VSTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfSEFWRV9HRU5FUklDX0RNQV9DT0hFUkVOVCBp cyBub3Qgc2V0CkNPTkZJR19TTEFCSU5GTz15CkNPTkZJR19SVF9NVVRFWEVTPXkKQ09ORklHX0JB U0VfU01BTEw9MApDT05GSUdfTU9EVUxFUz15CiMgQ09ORklHX01PRFVMRV9GT1JDRV9MT0FEIGlz IG5vdCBzZXQKQ09ORklHX01PRFVMRV9VTkxPQUQ9eQojIENPTkZJR19NT0RVTEVfRk9SQ0VfVU5M T0FEIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9EVkVSU0lPTlMgaXMgbm90IHNldAojIENPTkZJR19N T0RVTEVfU1JDVkVSU0lPTl9BTEwgaXMgbm90IHNldApDT05GSUdfTU9EVUxFX1NJRz15CiMgQ09O RklHX01PRFVMRV9TSUdfRk9SQ0UgaXMgbm90IHNldApDT05GSUdfTU9EVUxFX1NJR19CTEFDS0xJ U1Q9eQpDT05GSUdfTU9EVUxFX1NJR19VRUZJPXkKIyBDT05GSUdfTU9EVUxFX1NJR19TSEExIGlz IG5vdCBzZXQKIyBDT05GSUdfTU9EVUxFX1NJR19TSEEyMjQgaXMgbm90IHNldApDT05GSUdfTU9E VUxFX1NJR19TSEEyNTY9eQojIENPTkZJR19NT0RVTEVfU0lHX1NIQTM4NCBpcyBub3Qgc2V0CiMg Q09ORklHX01PRFVMRV9TSUdfU0hBNTEyIGlzIG5vdCBzZXQKQ09ORklHX1NUT1BfTUFDSElORT15 CkNPTkZJR19CTE9DSz15CkNPTkZJR19CTEtfREVWX0JTRz15CkNPTkZJR19CTEtfREVWX0JTR0xJ Qj15CkNPTkZJR19CTEtfREVWX0lOVEVHUklUWT15CkNPTkZJR19CTEtfREVWX1RIUk9UVExJTkc9 eQoKIwojIFBhcnRpdGlvbiBUeXBlcwojCkNPTkZJR19QQVJUSVRJT05fQURWQU5DRUQ9eQojIENP TkZJR19BQ09STl9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfT1NGX1BBUlRJVElPTj15CkNP TkZJR19BTUlHQV9QQVJUSVRJT049eQojIENPTkZJR19BVEFSSV9QQVJUSVRJT04gaXMgbm90IHNl dApDT05GSUdfTUFDX1BBUlRJVElPTj15CkNPTkZJR19NU0RPU19QQVJUSVRJT049eQpDT05GSUdf QlNEX0RJU0tMQUJFTD15CkNPTkZJR19NSU5JWF9TVUJQQVJUSVRJT049eQpDT05GSUdfU09MQVJJ U19YODZfUEFSVElUSU9OPXkKQ09ORklHX1VOSVhXQVJFX0RJU0tMQUJFTD15CiMgQ09ORklHX0xE TV9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfU0dJX1BBUlRJVElPTj15CiMgQ09ORklHX1VM VFJJWF9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfU1VOX1BBUlRJVElPTj15CkNPTkZJR19L QVJNQV9QQVJUSVRJT049eQpDT05GSUdfRUZJX1BBUlRJVElPTj15CiMgQ09ORklHX1NZU1Y2OF9Q QVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfQkxPQ0tfQ09NUEFUPXkKCiMKIyBJTyBTY2hlZHVs ZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15CkNPTkZJR19JT1NDSEVEX0RFQURMSU5FPXkKQ09O RklHX0lPU0NIRURfQ0ZRPXkKQ09ORklHX0NGUV9HUk9VUF9JT1NDSEVEPXkKIyBDT05GSUdfREVG QVVMVF9ERUFETElORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0NGUT15CiMgQ09ORklHX0RF RkFVTFRfTk9PUCBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPU0NIRUQ9ImNmcSIKQ09ORklH X1BSRUVNUFRfTk9USUZJRVJTPXkKQ09ORklHX1BBREFUQT15CkNPTkZJR19BU04xPXkKIyBDT05G SUdfSU5MSU5FX1NQSU5fVFJZTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX1RS WUxPQ0tfQkggaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9MT0NLIGlzIG5vdCBzZXQK IyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9T UElOX0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19JUlFTQVZF IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQSU5fVU5MT0NLX0JIIGlzIG5vdCBzZXQKQ09O RklHX0lOTElORV9TUElOX1VOTE9DS19JUlE9eQojIENPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tf SVJRUkVTVE9SRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX1RSWUxPQ0sgaXMgbm90 IHNldAojIENPTkZJR19JTkxJTkVfUkVBRF9MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5F X1JFQURfTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xPQ0tfSVJRIGlz IG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfTE9DS19JUlFTQVZFIGlzIG5vdCBzZXQKQ09O RklHX0lOTElORV9SRUFEX1VOTE9DSz15CiMgQ09ORklHX0lOTElORV9SRUFEX1VOTE9DS19CSCBp cyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfUkVBRF9VTkxPQ0tfSVJRPXkKIyBDT05GSUdfSU5MSU5F X1JFQURfVU5MT0NLX0lSUVJFU1RPUkUgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVf VFJZTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9MT0NLIGlzIG5vdCBzZXQK IyBDT05GSUdfSU5MSU5FX1dSSVRFX0xPQ0tfQkggaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVf V1JJVEVfTE9DS19JUlEgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVfTE9DS19JUlFT QVZFIGlzIG5vdCBzZXQKQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0s9eQojIENPTkZJR19JTkxJ TkVfV1JJVEVfVU5MT0NLX0JIIGlzIG5vdCBzZXQKQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0tf SVJRPXkKIyBDT05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19JUlFSRVNUT1JFIGlzIG5vdCBzZXQK Q09ORklHX01VVEVYX1NQSU5fT05fT1dORVI9eQpDT05GSUdfRlJFRVpFUj15CgojCiMgUHJvY2Vz c29yIHR5cGUgYW5kIGZlYXR1cmVzCiMKQ09ORklHX1pPTkVfRE1BPXkKQ09ORklHX1NNUD15CkNP TkZJR19YODZfWDJBUElDPXkKQ09ORklHX1g4Nl9NUFBBUlNFPXkKQ09ORklHX1g4Nl9FWFRFTkRF RF9QTEFURk9STT15CiMgQ09ORklHX1g4Nl9OVU1BQ0hJUCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4 Nl9WU01QIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X1VWIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9T VVBQT1JUU19NRU1PUllfRkFJTFVSRT15CkNPTkZJR19TQ0hFRF9PTUlUX0ZSQU1FX1BPSU5URVI9 eQpDT05GSUdfUEFSQVZJUlRfR1VFU1Q9eQpDT05GSUdfUEFSQVZJUlRfVElNRV9BQ0NPVU5USU5H PXkKQ09ORklHX1hFTj15CkNPTkZJR19YRU5fRE9NMD15CkNPTkZJR19YRU5fUFJJVklMRUdFRF9H VUVTVD15CkNPTkZJR19YRU5fUFZIVk09eQpDT05GSUdfWEVOX01BWF9ET01BSU5fTUVNT1JZPTUw MApDT05GSUdfWEVOX1NBVkVfUkVTVE9SRT15CiMgQ09ORklHX1hFTl9ERUJVR19GUyBpcyBub3Qg c2V0CkNPTkZJR19LVk1fQ0xPQ0s9eQpDT05GSUdfS1ZNX0dVRVNUPXkKQ09ORklHX1BBUkFWSVJU PXkKIyBDT05GSUdfUEFSQVZJUlRfU1BJTkxPQ0tTIGlzIG5vdCBzZXQKQ09ORklHX1BBUkFWSVJU X0NMT0NLPXkKIyBDT05GSUdfUEFSQVZJUlRfREVCVUcgaXMgbm90IHNldApDT05GSUdfTk9fQk9P VE1FTT15CiMgQ09ORklHX01FTVRFU1QgaXMgbm90IHNldAojIENPTkZJR19NSzggaXMgbm90IHNl dAojIENPTkZJR19NUFNDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUNPUkUyIGlzIG5vdCBzZXQKIyBD T05GSUdfTUFUT00gaXMgbm90IHNldApDT05GSUdfR0VORVJJQ19DUFU9eQpDT05GSUdfWDg2X0lO VEVSTk9ERV9DQUNIRV9TSElGVD02CkNPTkZJR19YODZfQ01QWENIRz15CkNPTkZJR19YODZfTDFf Q0FDSEVfU0hJRlQ9NgpDT05GSUdfWDg2X1hBREQ9eQpDT05GSUdfWDg2X1dQX1dPUktTX09LPXkK Q09ORklHX1g4Nl9UU0M9eQpDT05GSUdfWDg2X0NNUFhDSEc2ND15CkNPTkZJR19YODZfQ01PVj15 CkNPTkZJR19YODZfTUlOSU1VTV9DUFVfRkFNSUxZPTY0CkNPTkZJR19YODZfREVCVUdDVExNU1I9 eQpDT05GSUdfQ1BVX1NVUF9JTlRFTD15CkNPTkZJR19DUFVfU1VQX0FNRD15CkNPTkZJR19DUFVf U1VQX0NFTlRBVVI9eQpDT05GSUdfSFBFVF9USU1FUj15CkNPTkZJR19IUEVUX0VNVUxBVEVfUlRD PXkKQ09ORklHX0RNST15CkNPTkZJR19HQVJUX0lPTU1VPXkKIyBDT05GSUdfQ0FMR0FSWV9JT01N VSBpcyBub3Qgc2V0CkNPTkZJR19TV0lPVExCPXkKQ09ORklHX0lPTU1VX0hFTFBFUj15CiMgQ09O RklHX01BWFNNUCBpcyBub3Qgc2V0CkNPTkZJR19OUl9DUFVTPTEyOApDT05GSUdfU0NIRURfU01U PXkKQ09ORklHX1NDSEVEX01DPXkKQ09ORklHX0lSUV9USU1FX0FDQ09VTlRJTkc9eQojIENPTkZJ R19QUkVFTVBUX05PTkUgaXMgbm90IHNldApDT05GSUdfUFJFRU1QVF9WT0xVTlRBUlk9eQojIENP TkZJR19QUkVFTVBUIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9MT0NBTF9BUElDPXkKQ09ORklHX1g4 Nl9JT19BUElDPXkKQ09ORklHX1g4Nl9SRVJPVVRFX0ZPUl9CUk9LRU5fQk9PVF9JUlFTPXkKQ09O RklHX1g4Nl9NQ0U9eQpDT05GSUdfWDg2X01DRV9JTlRFTD15CkNPTkZJR19YODZfTUNFX0FNRD15 CkNPTkZJR19YODZfTUNFX1RIUkVTSE9MRD15CiMgQ09ORklHX1g4Nl9NQ0VfSU5KRUNUIGlzIG5v dCBzZXQKQ09ORklHX1g4Nl9USEVSTUFMX1ZFQ1RPUj15CkNPTkZJR19JOEs9bQpDT05GSUdfTUlD Uk9DT0RFPW0KQ09ORklHX01JQ1JPQ09ERV9JTlRFTD15CkNPTkZJR19NSUNST0NPREVfQU1EPXkK Q09ORklHX01JQ1JPQ09ERV9PTERfSU5URVJGQUNFPXkKQ09ORklHX1g4Nl9NU1I9eQpDT05GSUdf WDg2X0NQVUlEPXkKQ09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9E TUFfQUREUl9UXzY0QklUPXkKQ09ORklHX0RJUkVDVF9HQlBBR0VTPXkKQ09ORklHX05VTUE9eQpD T05GSUdfQU1EX05VTUE9eQpDT05GSUdfWDg2XzY0X0FDUElfTlVNQT15CkNPTkZJR19OT0RFU19T UEFOX09USEVSX05PREVTPXkKIyBDT05GSUdfTlVNQV9FTVUgaXMgbm90IHNldApDT05GSUdfTk9E RVNfU0hJRlQ9OQpDT05GSUdfQVJDSF9TUEFSU0VNRU1fRU5BQkxFPXkKQ09ORklHX0FSQ0hfU1BB UlNFTUVNX0RFRkFVTFQ9eQpDT05GSUdfQVJDSF9TRUxFQ1RfTUVNT1JZX01PREVMPXkKQ09ORklH X0FSQ0hfUFJPQ19LQ09SRV9URVhUPXkKQ09ORklHX0lMTEVHQUxfUE9JTlRFUl9WQUxVRT0weGRl YWQwMDAwMDAwMDAwMDAKQ09ORklHX1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdfU1BBUlNF TUVNX01BTlVBTD15CkNPTkZJR19TUEFSU0VNRU09eQpDT05GSUdfTkVFRF9NVUxUSVBMRV9OT0RF Uz15CkNPTkZJR19IQVZFX01FTU9SWV9QUkVTRU5UPXkKQ09ORklHX1NQQVJTRU1FTV9FWFRSRU1F PXkKQ09ORklHX1NQQVJTRU1FTV9WTUVNTUFQX0VOQUJMRT15CkNPTkZJR19TUEFSU0VNRU1fQUxM T0NfTUVNX01BUF9UT0dFVEhFUj15CkNPTkZJR19TUEFSU0VNRU1fVk1FTU1BUD15CkNPTkZJR19I QVZFX01FTUJMT0NLPXkKQ09ORklHX0hBVkVfTUVNQkxPQ0tfTk9ERV9NQVA9eQpDT05GSUdfQVJD SF9ESVNDQVJEX01FTUJMT0NLPXkKQ09ORklHX01FTU9SWV9JU09MQVRJT049eQojIENPTkZJR19N RU1PUllfSE9UUExVRyBpcyBub3Qgc2V0CkNPTkZJR19QQUdFRkxBR1NfRVhURU5ERUQ9eQpDT05G SUdfU1BMSVRfUFRMT0NLX0NQVVM9NApDT05GSUdfQ09NUEFDVElPTj15CkNPTkZJR19NSUdSQVRJ T049eQpDT05GSUdfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfWk9ORV9ETUFfRkxBRz0xCkNP TkZJR19CT1VOQ0U9eQpDT05GSUdfVklSVF9UT19CVVM9eQpDT05GSUdfTU1VX05PVElGSUVSPXkK Q09ORklHX0tTTT15CkNPTkZJR19ERUZBVUxUX01NQVBfTUlOX0FERFI9NDA5NgpDT05GSUdfQVJD SF9TVVBQT1JUU19NRU1PUllfRkFJTFVSRT15CkNPTkZJR19NRU1PUllfRkFJTFVSRT15CkNPTkZJ R19IV1BPSVNPTl9JTkpFQ1Q9bQpDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0U9eQpDT05GSUdf VFJBTlNQQVJFTlRfSFVHRVBBR0VfQUxXQVlTPXkKIyBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBB R0VfTUFEVklTRSBpcyBub3Qgc2V0CkNPTkZJR19DUk9TU19NRU1PUllfQVRUQUNIPXkKQ09ORklH X0NMRUFOQ0FDSEU9eQpDT05GSUdfRlJPTlRTV0FQPXkKQ09ORklHX1g4Nl9DSEVDS19CSU9TX0NP UlJVUFRJT049eQojIENPTkZJR19YODZfQk9PVFBBUkFNX01FTU9SWV9DT1JSVVBUSU9OX0NIRUNL IGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9SRVNFUlZFX0xPVz02NApDT05GSUdfTVRSUj15CkNPTkZJ R19NVFJSX1NBTklUSVpFUj15CkNPTkZJR19NVFJSX1NBTklUSVpFUl9FTkFCTEVfREVGQVVMVD0x CkNPTkZJR19NVFJSX1NBTklUSVpFUl9TUEFSRV9SRUdfTlJfREVGQVVMVD0xCkNPTkZJR19YODZf UEFUPXkKQ09ORklHX0FSQ0hfVVNFU19QR19VTkNBQ0hFRD15CkNPTkZJR19BUkNIX1JBTkRPTT15 CkNPTkZJR19FRkk9eQpDT05GSUdfRUZJX1NUVUI9eQpDT05GSUdfU0VDQ09NUD15CkNPTkZJR19D Q19TVEFDS1BST1RFQ1RPUj15CiMgQ09ORklHX0haXzEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ha XzI1MCBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzMwMCBpcyBub3Qgc2V0CkNPTkZJR19IWl8xMDAw PXkKQ09ORklHX0haPTEwMDAKQ09ORklHX1NDSEVEX0hSVElDSz15CkNPTkZJR19LRVhFQz15CkNP TkZJR19DUkFTSF9EVU1QPXkKQ09ORklHX0tFWEVDX0pVTVA9eQpDT05GSUdfUEhZU0lDQUxfU1RB UlQ9MHgxMDAwMDAwCkNPTkZJR19SRUxPQ0FUQUJMRT15CkNPTkZJR19QSFlTSUNBTF9BTElHTj0w eDEwMDAwMDAKQ09ORklHX0hPVFBMVUdfQ1BVPXkKIyBDT05GSUdfQ09NUEFUX1ZEU08gaXMgbm90 IHNldAojIENPTkZJR19DTURMSU5FX0JPT0wgaXMgbm90IHNldApDT05GSUdfQVJDSF9FTkFCTEVf TUVNT1JZX0hPVFBMVUc9eQpDT05GSUdfVVNFX1BFUkNQVV9OVU1BX05PREVfSUQ9eQoKIwojIFBv d2VyIG1hbmFnZW1lbnQgYW5kIEFDUEkgb3B0aW9ucwojCkNPTkZJR19BUkNIX0hJQkVSTkFUSU9O X0hFQURFUj15CkNPTkZJR19TVVNQRU5EPXkKQ09ORklHX1NVU1BFTkRfRlJFRVpFUj15CkNPTkZJ R19ISUJFUk5BVEVfQ0FMTEJBQ0tTPXkKQ09ORklHX0hJQkVSTkFUSU9OPXkKQ09ORklHX1BNX1NU RF9QQVJUSVRJT049IiIKQ09ORklHX1BNX1NMRUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CiMg Q09ORklHX1BNX0FVVE9TTEVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BNX1dBS0VMT0NLUyBpcyBu b3Qgc2V0CkNPTkZJR19QTV9SVU5USU1FPXkKQ09ORklHX1BNPXkKQ09ORklHX1BNX0RFQlVHPXkK Q09ORklHX1BNX0FEVkFOQ0VEX0RFQlVHPXkKIyBDT05GSUdfUE1fVEVTVF9TVVNQRU5EIGlzIG5v dCBzZXQKQ09ORklHX1BNX1NMRUVQX0RFQlVHPXkKQ09ORklHX1BNX1RSQUNFPXkKQ09ORklHX1BN X1RSQUNFX1JUQz15CkNPTkZJR19BQ1BJPXkKQ09ORklHX0FDUElfU0xFRVA9eQpDT05GSUdfQUNQ SV9QUk9DRlM9eQojIENPTkZJR19BQ1BJX1BST0NGU19QT1dFUiBpcyBub3Qgc2V0CkNPTkZJR19B Q1BJX0VDX0RFQlVHRlM9bQojIENPTkZJR19BQ1BJX1BST0NfRVZFTlQgaXMgbm90IHNldApDT05G SUdfQUNQSV9BQz15CkNPTkZJR19BQ1BJX0JBVFRFUlk9eQpDT05GSUdfQUNQSV9CVVRUT049eQpD T05GSUdfQUNQSV9WSURFTz1tCkNPTkZJR19BQ1BJX0ZBTj15CkNPTkZJR19BQ1BJX0RPQ0s9eQpD T05GSUdfQUNQSV9QUk9DRVNTT1I9eQpDT05GSUdfQUNQSV9JUE1JPW0KQ09ORklHX0FDUElfSE9U UExVR19DUFU9eQpDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUj1tCkNPTkZJR19BQ1BJ X1RIRVJNQUw9eQpDT05GSUdfQUNQSV9OVU1BPXkKIyBDT05GSUdfQUNQSV9DVVNUT01fRFNEVCBp cyBub3Qgc2V0CkNPTkZJR19BQ1BJX0JMQUNLTElTVF9ZRUFSPTAKIyBDT05GSUdfQUNQSV9ERUJV RyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX1BDSV9TTE9UPXkKQ09ORklHX1g4Nl9QTV9USU1FUj15 CkNPTkZJR19BQ1BJX0NPTlRBSU5FUj15CkNPTkZJR19BQ1BJX1NCUz1tCkNPTkZJR19BQ1BJX0hF RD15CkNPTkZJR19BQ1BJX0NVU1RPTV9NRVRIT0Q9bQpDT05GSUdfQUNQSV9CR1JUPXkKQ09ORklH X0FDUElfQVBFST15CkNPTkZJR19BQ1BJX0FQRUlfR0hFUz15CkNPTkZJR19BQ1BJX0FQRUlfUENJ RUFFUj15CkNPTkZJR19BQ1BJX0FQRUlfTUVNT1JZX0ZBSUxVUkU9eQojIENPTkZJR19BQ1BJX0FQ RUlfRUlOSiBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfQVBFSV9FUlNUX0RFQlVHIGlzIG5vdCBz ZXQKQ09ORklHX1NGST15CgojCiMgQ1BVIEZyZXF1ZW5jeSBzY2FsaW5nCiMKQ09ORklHX0NQVV9G UkVRPXkKQ09ORklHX0NQVV9GUkVRX1RBQkxFPXkKQ09ORklHX0NQVV9GUkVRX1NUQVQ9bQpDT05G SUdfQ1BVX0ZSRVFfU1RBVF9ERVRBSUxTPXkKIyBDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1Zf UEVSRk9STUFOQ0UgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9VU0VS U1BBQ0UgaXMgbm90IHNldApDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfT05ERU1BTkQ9eQoj IENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9DT05TRVJWQVRJVkUgaXMgbm90IHNldApDT05G SUdfQ1BVX0ZSRVFfR09WX1BFUkZPUk1BTkNFPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9QT1dFUlNB VkU9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX1VTRVJTUEFDRT15CkNPTkZJR19DUFVfRlJFUV9HT1Zf T05ERU1BTkQ9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTlNFUlZBVElWRT15CgojCiMgeDg2IENQ VSBmcmVxdWVuY3kgc2NhbGluZyBkcml2ZXJzCiMKQ09ORklHX1g4Nl9QQ0NfQ1BVRlJFUT15CkNP TkZJR19YODZfQUNQSV9DUFVGUkVRPXkKQ09ORklHX1g4Nl9QT1dFUk5PV19LOD15CiMgQ09ORklH X1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk8gaXMgbm90IHNldApDT05GSUdfWDg2X1A0X0NMT0NLTU9E PXkKCiMKIyBzaGFyZWQgb3B0aW9ucwojCkNPTkZJR19YODZfU1BFRURTVEVQX0xJQj15CkNPTkZJ R19DUFVfSURMRT15CkNPTkZJR19DUFVfSURMRV9HT1ZfTEFEREVSPXkKQ09ORklHX0NQVV9JRExF X0dPVl9NRU5VPXkKIyBDT05GSUdfQVJDSF9ORUVEU19DUFVfSURMRV9DT1VQTEVEIGlzIG5vdCBz ZXQKQ09ORklHX0lOVEVMX0lETEU9eQoKIwojIE1lbW9yeSBwb3dlciBzYXZpbmdzCiMKQ09ORklH X0k3MzAwX0lETEVfSU9BVF9DSEFOTkVMPXkKQ09ORklHX0k3MzAwX0lETEU9bQoKIwojIEJ1cyBv cHRpb25zIChQQ0kgZXRjLikKIwpDT05GSUdfUENJPXkKQ09ORklHX1BDSV9ESVJFQ1Q9eQpDT05G SUdfUENJX01NQ09ORklHPXkKQ09ORklHX1BDSV9YRU49eQpDT05GSUdfUENJX0RPTUFJTlM9eQoj IENPTkZJR19QQ0lfQ05CMjBMRV9RVUlSSyBpcyBub3Qgc2V0CkNPTkZJR19QQ0lFUE9SVEJVUz15 CkNPTkZJR19IT1RQTFVHX1BDSV9QQ0lFPXkKQ09ORklHX1BDSUVBRVI9eQpDT05GSUdfUENJRV9F Q1JDPXkKQ09ORklHX1BDSUVBRVJfSU5KRUNUPW0KQ09ORklHX1BDSUVBU1BNPXkKIyBDT05GSUdf UENJRUFTUE1fREVCVUcgaXMgbm90IHNldApDT05GSUdfUENJRUFTUE1fREVGQVVMVD15CiMgQ09O RklHX1BDSUVBU1BNX1BPV0VSU0FWRSBpcyBub3Qgc2V0CiMgQ09ORklHX1BDSUVBU1BNX1BFUkZP Uk1BTkNFIGlzIG5vdCBzZXQKQ09ORklHX1BDSUVfUE1FPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNf TVNJPXkKQ09ORklHX1BDSV9NU0k9eQojIENPTkZJR19QQ0lfREVCVUcgaXMgbm90IHNldAojIENP TkZJR19QQ0lfUkVBTExPQ19FTkFCTEVfQVVUTyBpcyBub3Qgc2V0CkNPTkZJR19QQ0lfU1RVQj15 CkNPTkZJR19YRU5fUENJREVWX0ZST05URU5EPXkKQ09ORklHX0hUX0lSUT15CkNPTkZJR19QQ0lf QVRTPXkKQ09ORklHX1BDSV9JT1Y9eQpDT05GSUdfUENJX1BSST15CkNPTkZJR19QQ0lfUEFTSUQ9 eQpDT05GSUdfUENJX0lPQVBJQz15CkNPTkZJR19QQ0lfTEFCRUw9eQpDT05GSUdfSVNBX0RNQV9B UEk9eQpDT05GSUdfQU1EX05CPXkKQ09ORklHX1BDQ0FSRD15CkNPTkZJR19QQ01DSUE9eQpDT05G SUdfUENNQ0lBX0xPQURfQ0lTPXkKQ09ORklHX0NBUkRCVVM9eQoKIwojIFBDLWNhcmQgYnJpZGdl cwojCkNPTkZJR19ZRU5UQT1tCkNPTkZJR19ZRU5UQV9PMj15CkNPTkZJR19ZRU5UQV9SSUNPSD15 CkNPTkZJR19ZRU5UQV9UST15CkNPTkZJR19ZRU5UQV9FTkVfVFVORT15CkNPTkZJR19ZRU5UQV9U T1NISUJBPXkKQ09ORklHX1BENjcyOT1tCkNPTkZJR19JODIwOTI9bQpDT05GSUdfUENDQVJEX05P TlNUQVRJQz15CkNPTkZJR19IT1RQTFVHX1BDST15CkNPTkZJR19IT1RQTFVHX1BDSV9GQUtFPW0K Q09ORklHX0hPVFBMVUdfUENJX0FDUEk9eQpDT05GSUdfSE9UUExVR19QQ0lfQUNQSV9JQk09bQoj IENPTkZJR19IT1RQTFVHX1BDSV9DUENJIGlzIG5vdCBzZXQKQ09ORklHX0hPVFBMVUdfUENJX1NI UEM9bQojIENPTkZJR19SQVBJRElPIGlzIG5vdCBzZXQKCiMKIyBFeGVjdXRhYmxlIGZpbGUgZm9y bWF0cyAvIEVtdWxhdGlvbnMKIwpDT05GSUdfQklORk1UX0VMRj15CkNPTkZJR19DT01QQVRfQklO Rk1UX0VMRj15CkNPTkZJR19BUkNIX0JJTkZNVF9FTEZfUkFORE9NSVpFX1BJRT15CkNPTkZJR19D T1JFX0RVTVBfREVGQVVMVF9FTEZfSEVBREVSUz15CiMgQ09ORklHX0hBVkVfQU9VVCBpcyBub3Qg c2V0CkNPTkZJR19CSU5GTVRfTUlTQz1tCkNPTkZJR19JQTMyX0VNVUxBVElPTj15CiMgQ09ORklH X0lBMzJfQU9VVCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9YMzIgaXMgbm90IHNldApDT05GSUdf Q09NUEFUPXkKQ09ORklHX0NPTVBBVF9GT1JfVTY0X0FMSUdOTUVOVD15CkNPTkZJR19TWVNWSVBD X0NPTVBBVD15CkNPTkZJR19LRVlTX0NPTVBBVD15CkNPTkZJR19IQVZFX1RFWFRfUE9LRV9TTVA9 eQpDT05GSUdfWDg2X0RFVl9ETUFfT1BTPXkKQ09ORklHX05FVD15CkNPTkZJR19DT01QQVRfTkVU TElOS19NRVNTQUdFUz15CgojCiMgTmV0d29ya2luZyBvcHRpb25zCiMKQ09ORklHX1BBQ0tFVD15 CkNPTkZJR19VTklYPXkKQ09ORklHX1VOSVhfRElBRz1tCkNPTkZJR19YRlJNPXkKQ09ORklHX1hG Uk1fQUxHTz15CkNPTkZJR19YRlJNX1VTRVI9eQpDT05GSUdfWEZSTV9TVUJfUE9MSUNZPXkKQ09O RklHX1hGUk1fTUlHUkFURT15CkNPTkZJR19YRlJNX1NUQVRJU1RJQ1M9eQpDT05GSUdfWEZSTV9J UENPTVA9bQpDT05GSUdfTkVUX0tFWT1tCkNPTkZJR19ORVRfS0VZX01JR1JBVEU9eQpDT05GSUdf SU5FVD15CkNPTkZJR19JUF9NVUxUSUNBU1Q9eQpDT05GSUdfSVBfQURWQU5DRURfUk9VVEVSPXkK Q09ORklHX0lQX0ZJQl9UUklFX1NUQVRTPXkKQ09ORklHX0lQX01VTFRJUExFX1RBQkxFUz15CkNP TkZJR19JUF9ST1VURV9NVUxUSVBBVEg9eQpDT05GSUdfSVBfUk9VVEVfVkVSQk9TRT15CkNPTkZJ R19JUF9ST1VURV9DTEFTU0lEPXkKIyBDT05GSUdfSVBfUE5QIGlzIG5vdCBzZXQKQ09ORklHX05F VF9JUElQPW0KQ09ORklHX05FVF9JUEdSRV9ERU1VWD1tCkNPTkZJR19ORVRfSVBHUkU9bQpDT05G SUdfTkVUX0lQR1JFX0JST0FEQ0FTVD15CkNPTkZJR19JUF9NUk9VVEU9eQpDT05GSUdfSVBfTVJP VVRFX01VTFRJUExFX1RBQkxFUz15CkNPTkZJR19JUF9QSU1TTV9WMT15CkNPTkZJR19JUF9QSU1T TV9WMj15CkNPTkZJR19BUlBEPXkKQ09ORklHX1NZTl9DT09LSUVTPXkKQ09ORklHX05FVF9JUFZU ST1tCkNPTkZJR19JTkVUX0FIPW0KQ09ORklHX0lORVRfRVNQPW0KQ09ORklHX0lORVRfSVBDT01Q PW0KQ09ORklHX0lORVRfWEZSTV9UVU5ORUw9bQpDT05GSUdfSU5FVF9UVU5ORUw9bQpDT05GSUdf SU5FVF9YRlJNX01PREVfVFJBTlNQT1JUPW0KQ09ORklHX0lORVRfWEZSTV9NT0RFX1RVTk5FTD1t CkNPTkZJR19JTkVUX1hGUk1fTU9ERV9CRUVUPW0KQ09ORklHX0lORVRfTFJPPXkKQ09ORklHX0lO RVRfRElBRz1tCkNPTkZJR19JTkVUX1RDUF9ESUFHPW0KQ09ORklHX0lORVRfVURQX0RJQUc9bQpD T05GSUdfVENQX0NPTkdfQURWQU5DRUQ9eQpDT05GSUdfVENQX0NPTkdfQklDPW0KQ09ORklHX1RD UF9DT05HX0NVQklDPXkKQ09ORklHX1RDUF9DT05HX1dFU1RXT09EPW0KQ09ORklHX1RDUF9DT05H X0hUQ1A9bQpDT05GSUdfVENQX0NPTkdfSFNUQ1A9bQpDT05GSUdfVENQX0NPTkdfSFlCTEE9bQpD T05GSUdfVENQX0NPTkdfVkVHQVM9bQpDT05GSUdfVENQX0NPTkdfU0NBTEFCTEU9bQpDT05GSUdf VENQX0NPTkdfTFA9bQpDT05GSUdfVENQX0NPTkdfVkVOTz1tCkNPTkZJR19UQ1BfQ09OR19ZRUFI PW0KQ09ORklHX1RDUF9DT05HX0lMTElOT0lTPW0KQ09ORklHX0RFRkFVTFRfQ1VCSUM9eQojIENP TkZJR19ERUZBVUxUX1JFTk8gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9UQ1BfQ09ORz0iY3Vi aWMiCkNPTkZJR19UQ1BfTUQ1U0lHPXkKQ09ORklHX0lQVjY9eQpDT05GSUdfSVBWNl9QUklWQUNZ PXkKQ09ORklHX0lQVjZfUk9VVEVSX1BSRUY9eQpDT05GSUdfSVBWNl9ST1VURV9JTkZPPXkKQ09O RklHX0lQVjZfT1BUSU1JU1RJQ19EQUQ9eQpDT05GSUdfSU5FVDZfQUg9bQpDT05GSUdfSU5FVDZf RVNQPW0KQ09ORklHX0lORVQ2X0lQQ09NUD1tCkNPTkZJR19JUFY2X01JUDY9eQpDT05GSUdfSU5F VDZfWEZSTV9UVU5ORUw9bQpDT05GSUdfSU5FVDZfVFVOTkVMPW0KQ09ORklHX0lORVQ2X1hGUk1f TU9ERV9UUkFOU1BPUlQ9bQpDT05GSUdfSU5FVDZfWEZSTV9NT0RFX1RVTk5FTD1tCkNPTkZJR19J TkVUNl9YRlJNX01PREVfQkVFVD1tCkNPTkZJR19JTkVUNl9YRlJNX01PREVfUk9VVEVPUFRJTUla QVRJT049bQpDT05GSUdfSVBWNl9TSVQ9bQpDT05GSUdfSVBWNl9TSVRfNlJEPXkKQ09ORklHX0lQ VjZfTkRJU0NfTk9ERVRZUEU9eQpDT05GSUdfSVBWNl9UVU5ORUw9bQpDT05GSUdfSVBWNl9NVUxU SVBMRV9UQUJMRVM9eQpDT05GSUdfSVBWNl9TVUJUUkVFUz15CkNPTkZJR19JUFY2X01ST1VURT15 CkNPTkZJR19JUFY2X01ST1VURV9NVUxUSVBMRV9UQUJMRVM9eQpDT05GSUdfSVBWNl9QSU1TTV9W Mj15CkNPTkZJR19ORVRMQUJFTD15CkNPTkZJR19ORVRXT1JLX1NFQ01BUks9eQpDT05GSUdfTkVU V09SS19QSFlfVElNRVNUQU1QSU5HPXkKQ09ORklHX05FVEZJTFRFUj15CiMgQ09ORklHX05FVEZJ TFRFUl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfQURWQU5DRUQ9eQpDT05GSUdf QlJJREdFX05FVEZJTFRFUj15CgojCiMgQ29yZSBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbgojCkNP TkZJR19ORVRGSUxURVJfTkVUTElOSz1tCkNPTkZJR19ORVRGSUxURVJfTkVUTElOS19BQ0NUPW0K Q09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFPW0KQ09ORklHX05FVEZJTFRFUl9ORVRMSU5L X0xPRz1tCkNPTkZJR19ORl9DT05OVFJBQ0s9bQpDT05GSUdfTkZfQ09OTlRSQUNLX01BUks9eQpD T05GSUdfTkZfQ09OTlRSQUNLX1NFQ01BUks9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1pPTkVTPXkK Q09ORklHX05GX0NPTk5UUkFDS19QUk9DRlM9eQpDT05GSUdfTkZfQ09OTlRSQUNLX0VWRU5UUz15 CiMgQ09ORklHX05GX0NPTk5UUkFDS19USU1FT1VUIGlzIG5vdCBzZXQKQ09ORklHX05GX0NPTk5U UkFDS19USU1FU1RBTVA9eQpDT05GSUdfTkZfQ1RfUFJPVE9fRENDUD1tCkNPTkZJR19ORl9DVF9Q Uk9UT19HUkU9bQpDT05GSUdfTkZfQ1RfUFJPVE9fU0NUUD1tCkNPTkZJR19ORl9DVF9QUk9UT19V RFBMSVRFPW0KQ09ORklHX05GX0NPTk5UUkFDS19BTUFOREE9bQpDT05GSUdfTkZfQ09OTlRSQUNL X0ZUUD1tCkNPTkZJR19ORl9DT05OVFJBQ0tfSDMyMz1tCkNPTkZJR19ORl9DT05OVFJBQ0tfSVJD PW0KQ09ORklHX05GX0NPTk5UUkFDS19CUk9BRENBU1Q9bQpDT05GSUdfTkZfQ09OTlRSQUNLX05F VEJJT1NfTlM9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1NOTVA9bQpDT05GSUdfTkZfQ09OTlRSQUNL X1BQVFA9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1NBTkU9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1NJ UD1tCkNPTkZJR19ORl9DT05OVFJBQ0tfVEZUUD1tCkNPTkZJR19ORl9DVF9ORVRMSU5LPW0KIyBD T05GSUdfTkZfQ1RfTkVUTElOS19USU1FT1VUIGlzIG5vdCBzZXQKQ09ORklHX05GX0NUX05FVExJ TktfSEVMUEVSPW0KQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFX0NUPXkKQ09ORklHX05F VEZJTFRFUl9UUFJPWFk9bQpDT05GSUdfTkVURklMVEVSX1hUQUJMRVM9eQoKIwojIFh0YWJsZXMg Y29tYmluZWQgbW9kdWxlcwojCkNPTkZJR19ORVRGSUxURVJfWFRfTUFSSz1tCkNPTkZJR19ORVRG SUxURVJfWFRfQ09OTk1BUks9bQpDT05GSUdfTkVURklMVEVSX1hUX1NFVD1tCgojCiMgWHRhYmxl cyB0YXJnZXRzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQVVESVQ9bQpDT05GSUdfTkVU RklMVEVSX1hUX1RBUkdFVF9DSEVDS1NVTT1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NM QVNTSUZZPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ09OTk1BUks9bQpDT05GSUdfTkVU RklMVEVSX1hUX1RBUkdFVF9DT05OU0VDTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU X0NUPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfRFNDUD1tCkNPTkZJR19ORVRGSUxURVJf WFRfVEFSR0VUX0hMPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSE1BUks9bQpDT05GSUdf TkVURklMVEVSX1hUX1RBUkdFVF9JRExFVElNRVI9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdF VF9MRUQ9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9MT0c9bQpDT05GSUdfTkVURklMVEVS X1hUX1RBUkdFVF9NQVJLPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTkZMT0c9bQpDT05G SUdfTkVURklMVEVSX1hUX1RBUkdFVF9ORlFVRVVFPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJH RVRfTk9UUkFDSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1JBVEVFU1Q9bQpDT05GSUdf TkVURklMVEVSX1hUX1RBUkdFVF9URUU9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUFJP WFk9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUkFDRT1tCkNPTkZJR19ORVRGSUxURVJf WFRfVEFSR0VUX1NFQ01BUks9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BNU1M9bQpD T05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BPUFRTVFJJUD1tCgojCiMgWHRhYmxlcyBtYXRj aGVzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9BRERSVFlQRT1tCkNPTkZJR19ORVRGSUxU RVJfWFRfTUFUQ0hfQ0xVU1RFUj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09NTUVOVD1t CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09OTkJZVEVTPW0KQ09ORklHX05FVEZJTFRFUl9Y VF9NQVRDSF9DT05OTElNSVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5NQVJLPW0K Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OVFJBQ0s9bQpDT05GSUdfTkVURklMVEVSX1hU X01BVENIX0NQVT1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRENDUD1tCkNPTkZJR19ORVRG SUxURVJfWFRfTUFUQ0hfREVWR1JPVVA9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0RTQ1A9 bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VDTj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFU Q0hfRVNQPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9IQVNITElNSVQ9bQpDT05GSUdfTkVU RklMVEVSX1hUX01BVENIX0hFTFBFUj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEw9bQpD T05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQUkFOR0U9bQpDT05GSUdfTkVURklMVEVSX1hUX01B VENIX0lQVlM9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xFTkdUSD1tCkNPTkZJR19ORVRG SUxURVJfWFRfTUFUQ0hfTElNSVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX01BQz1tCkNP TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hf TVVMVElQT1JUPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9ORkFDQ1Q9bQpDT05GSUdfTkVU RklMVEVSX1hUX01BVENIX09TRj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfT1dORVI9bQpD T05GSUdfTkVURklMVEVSX1hUX01BVENIX1BPTElDWT1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFU Q0hfUEhZU0RFVj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUEtUVFlQRT1tCkNPTkZJR19O RVRGSUxURVJfWFRfTUFUQ0hfUVVPVEE9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JBVEVF U1Q9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JFQUxNPW0KQ09ORklHX05FVEZJTFRFUl9Y VF9NQVRDSF9SRUNFTlQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NDVFA9bQpDT05GSUdf TkVURklMVEVSX1hUX01BVENIX1NPQ0tFVD1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfU1RB VEU9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NUQVRJU1RJQz1tCkNPTkZJR19ORVRGSUxU RVJfWFRfTUFUQ0hfU1RSSU5HPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9UQ1BNU1M9bQpD T05GSUdfTkVURklMVEVSX1hUX01BVENIX1RJTUU9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENI X1UzMj1tCkNPTkZJR19JUF9TRVQ9bQpDT05GSUdfSVBfU0VUX01BWD0yNTYKQ09ORklHX0lQX1NF VF9CSVRNQVBfSVA9bQpDT05GSUdfSVBfU0VUX0JJVE1BUF9JUE1BQz1tCkNPTkZJR19JUF9TRVRf QklUTUFQX1BPUlQ9bQpDT05GSUdfSVBfU0VUX0hBU0hfSVA9bQpDT05GSUdfSVBfU0VUX0hBU0hf SVBQT1JUPW0KQ09ORklHX0lQX1NFVF9IQVNIX0lQUE9SVElQPW0KQ09ORklHX0lQX1NFVF9IQVNI X0lQUE9SVE5FVD1tCkNPTkZJR19JUF9TRVRfSEFTSF9ORVQ9bQpDT05GSUdfSVBfU0VUX0hBU0hf TkVUUE9SVD1tCkNPTkZJR19JUF9TRVRfSEFTSF9ORVRJRkFDRT1tCkNPTkZJR19JUF9TRVRfTElT VF9TRVQ9bQpDT05GSUdfSVBfVlM9bQpDT05GSUdfSVBfVlNfSVBWNj15CiMgQ09ORklHX0lQX1ZT X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0lQX1ZTX1RBQl9CSVRTPTEyCgojCiMgSVBWUyB0cmFu c3BvcnQgcHJvdG9jb2wgbG9hZCBiYWxhbmNpbmcgc3VwcG9ydAojCkNPTkZJR19JUF9WU19QUk9U T19UQ1A9eQpDT05GSUdfSVBfVlNfUFJPVE9fVURQPXkKQ09ORklHX0lQX1ZTX1BST1RPX0FIX0VT UD15CkNPTkZJR19JUF9WU19QUk9UT19FU1A9eQpDT05GSUdfSVBfVlNfUFJPVE9fQUg9eQpDT05G SUdfSVBfVlNfUFJPVE9fU0NUUD15CgojCiMgSVBWUyBzY2hlZHVsZXIKIwpDT05GSUdfSVBfVlNf UlI9bQpDT05GSUdfSVBfVlNfV1JSPW0KQ09ORklHX0lQX1ZTX0xDPW0KQ09ORklHX0lQX1ZTX1dM Qz1tCkNPTkZJR19JUF9WU19MQkxDPW0KQ09ORklHX0lQX1ZTX0xCTENSPW0KQ09ORklHX0lQX1ZT X0RIPW0KQ09ORklHX0lQX1ZTX1NIPW0KQ09ORklHX0lQX1ZTX1NFRD1tCkNPTkZJR19JUF9WU19O UT1tCgojCiMgSVBWUyBTSCBzY2hlZHVsZXIKIwpDT05GSUdfSVBfVlNfU0hfVEFCX0JJVFM9OAoK IwojIElQVlMgYXBwbGljYXRpb24gaGVscGVyCiMKQ09ORklHX0lQX1ZTX0ZUUD1tCkNPTkZJR19J UF9WU19ORkNUPXkKQ09ORklHX0lQX1ZTX1BFX1NJUD1tCgojCiMgSVA6IE5ldGZpbHRlciBDb25m aWd1cmF0aW9uCiMKQ09ORklHX05GX0RFRlJBR19JUFY0PW0KQ09ORklHX05GX0NPTk5UUkFDS19J UFY0PW0KIyBDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NfQ09NUEFUIGlzIG5vdCBzZXQKQ09ORklH X0lQX05GX1FVRVVFPW0KQ09ORklHX0lQX05GX0lQVEFCTEVTPXkKQ09ORklHX0lQX05GX01BVENI X0FIPW0KQ09ORklHX0lQX05GX01BVENIX0VDTj1tCkNPTkZJR19JUF9ORl9NQVRDSF9SUEZJTFRF Uj1tCkNPTkZJR19JUF9ORl9NQVRDSF9UVEw9bQpDT05GSUdfSVBfTkZfRklMVEVSPXkKQ09ORklH X0lQX05GX1RBUkdFVF9SRUpFQ1Q9eQpDT05GSUdfSVBfTkZfVEFSR0VUX1VMT0c9bQpDT05GSUdf TkZfTkFUPW0KQ09ORklHX05GX05BVF9ORUVERUQ9eQpDT05GSUdfSVBfTkZfVEFSR0VUX01BU1FV RVJBREU9bQpDT05GSUdfSVBfTkZfVEFSR0VUX05FVE1BUD1tCkNPTkZJR19JUF9ORl9UQVJHRVRf UkVESVJFQ1Q9bQpDT05GSUdfTkZfTkFUX1NOTVBfQkFTSUM9bQpDT05GSUdfTkZfTkFUX1BST1RP X0RDQ1A9bQpDT05GSUdfTkZfTkFUX1BST1RPX0dSRT1tCkNPTkZJR19ORl9OQVRfUFJPVE9fVURQ TElURT1tCkNPTkZJR19ORl9OQVRfUFJPVE9fU0NUUD1tCkNPTkZJR19ORl9OQVRfRlRQPW0KQ09O RklHX05GX05BVF9JUkM9bQpDT05GSUdfTkZfTkFUX1RGVFA9bQpDT05GSUdfTkZfTkFUX0FNQU5E QT1tCkNPTkZJR19ORl9OQVRfUFBUUD1tCkNPTkZJR19ORl9OQVRfSDMyMz1tCkNPTkZJR19ORl9O QVRfU0lQPW0KQ09ORklHX0lQX05GX01BTkdMRT1tCkNPTkZJR19JUF9ORl9UQVJHRVRfQ0xVU1RF UklQPW0KQ09ORklHX0lQX05GX1RBUkdFVF9FQ049bQpDT05GSUdfSVBfTkZfVEFSR0VUX1RUTD1t CkNPTkZJR19JUF9ORl9SQVc9bQpDT05GSUdfSVBfTkZfU0VDVVJJVFk9bQpDT05GSUdfSVBfTkZf QVJQVEFCTEVTPW0KQ09ORklHX0lQX05GX0FSUEZJTFRFUj1tCkNPTkZJR19JUF9ORl9BUlBfTUFO R0xFPW0KCiMKIyBJUHY2OiBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbgojCkNPTkZJR19ORl9ERUZS QUdfSVBWNj1tCkNPTkZJR19ORl9DT05OVFJBQ0tfSVBWNj1tCkNPTkZJR19JUDZfTkZfSVBUQUJM RVM9bQpDT05GSUdfSVA2X05GX01BVENIX0FIPW0KQ09ORklHX0lQNl9ORl9NQVRDSF9FVUk2ND1t CkNPTkZJR19JUDZfTkZfTUFUQ0hfRlJBRz1tCkNPTkZJR19JUDZfTkZfTUFUQ0hfT1BUUz1tCkNP TkZJR19JUDZfTkZfTUFUQ0hfSEw9bQpDT05GSUdfSVA2X05GX01BVENIX0lQVjZIRUFERVI9bQpD T05GSUdfSVA2X05GX01BVENIX01IPW0KQ09ORklHX0lQNl9ORl9NQVRDSF9SUEZJTFRFUj1tCkNP TkZJR19JUDZfTkZfTUFUQ0hfUlQ9bQpDT05GSUdfSVA2X05GX1RBUkdFVF9ITD1tCkNPTkZJR19J UDZfTkZfRklMVEVSPW0KQ09ORklHX0lQNl9ORl9UQVJHRVRfUkVKRUNUPW0KQ09ORklHX0lQNl9O Rl9NQU5HTEU9bQpDT05GSUdfSVA2X05GX1JBVz1tCkNPTkZJR19JUDZfTkZfU0VDVVJJVFk9bQpD T05GSUdfQlJJREdFX05GX0VCVEFCTEVTPW0KQ09ORklHX0JSSURHRV9FQlRfQlJPVVRFPW0KQ09O RklHX0JSSURHRV9FQlRfVF9GSUxURVI9bQpDT05GSUdfQlJJREdFX0VCVF9UX05BVD1tCkNPTkZJ R19CUklER0VfRUJUXzgwMl8zPW0KQ09ORklHX0JSSURHRV9FQlRfQU1PTkc9bQpDT05GSUdfQlJJ REdFX0VCVF9BUlA9bQpDT05GSUdfQlJJREdFX0VCVF9JUD1tCkNPTkZJR19CUklER0VfRUJUX0lQ Nj1tCkNPTkZJR19CUklER0VfRUJUX0xJTUlUPW0KQ09ORklHX0JSSURHRV9FQlRfTUFSSz1tCkNP TkZJR19CUklER0VfRUJUX1BLVFRZUEU9bQpDT05GSUdfQlJJREdFX0VCVF9TVFA9bQpDT05GSUdf QlJJREdFX0VCVF9WTEFOPW0KQ09ORklHX0JSSURHRV9FQlRfQVJQUkVQTFk9bQpDT05GSUdfQlJJ REdFX0VCVF9ETkFUPW0KQ09ORklHX0JSSURHRV9FQlRfTUFSS19UPW0KQ09ORklHX0JSSURHRV9F QlRfUkVESVJFQ1Q9bQpDT05GSUdfQlJJREdFX0VCVF9TTkFUPW0KQ09ORklHX0JSSURHRV9FQlRf TE9HPW0KQ09ORklHX0JSSURHRV9FQlRfVUxPRz1tCkNPTkZJR19CUklER0VfRUJUX05GTE9HPW0K Q09ORklHX0lQX0RDQ1A9bQpDT05GSUdfSU5FVF9EQ0NQX0RJQUc9bQoKIwojIERDQ1AgQ0NJRHMg Q29uZmlndXJhdGlvbiAoRVhQRVJJTUVOVEFMKQojCiMgQ09ORklHX0lQX0RDQ1BfQ0NJRDJfREVC VUcgaXMgbm90IHNldApDT05GSUdfSVBfRENDUF9DQ0lEMz15CiMgQ09ORklHX0lQX0RDQ1BfQ0NJ RDNfREVCVUcgaXMgbm90IHNldApDT05GSUdfSVBfRENDUF9URlJDX0xJQj15CgojCiMgRENDUCBL ZXJuZWwgSGFja2luZwojCiMgQ09ORklHX0lQX0RDQ1BfREVCVUcgaXMgbm90IHNldAojIENPTkZJ R19ORVRfRENDUFBST0JFIGlzIG5vdCBzZXQKQ09ORklHX0lQX1NDVFA9bQpDT05GSUdfTkVUX1ND VFBQUk9CRT1tCiMgQ09ORklHX1NDVFBfREJHX01TRyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDVFBf REJHX09CSkNOVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDVFBfSE1BQ19OT05FIGlzIG5vdCBzZXQK Q09ORklHX1NDVFBfSE1BQ19TSEExPXkKIyBDT05GSUdfU0NUUF9ITUFDX01ENSBpcyBub3Qgc2V0 CkNPTkZJR19SRFM9bQpDT05GSUdfUkRTX1JETUE9bQpDT05GSUdfUkRTX1RDUD1tCiMgQ09ORklH X1JEU19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1RJUEMgaXMgbm90IHNldApDT05GSUdfQVRN PW0KQ09ORklHX0FUTV9DTElQPW0KIyBDT05GSUdfQVRNX0NMSVBfTk9fSUNNUCBpcyBub3Qgc2V0 CkNPTkZJR19BVE1fTEFORT1tCiMgQ09ORklHX0FUTV9NUE9BIGlzIG5vdCBzZXQKQ09ORklHX0FU TV9CUjI2ODQ9bQojIENPTkZJR19BVE1fQlIyNjg0X0lQRklMVEVSIGlzIG5vdCBzZXQKQ09ORklH X0wyVFA9bQpDT05GSUdfTDJUUF9ERUJVR0ZTPW0KQ09ORklHX0wyVFBfVjM9eQpDT05GSUdfTDJU UF9JUD1tCkNPTkZJR19MMlRQX0VUSD1tCkNPTkZJR19TVFA9bQpDT05GSUdfR0FSUD1tCkNPTkZJ R19CUklER0U9bQpDT05GSUdfQlJJREdFX0lHTVBfU05PT1BJTkc9eQpDT05GSUdfTkVUX0RTQT1t CkNPTkZJR19ORVRfRFNBX1RBR19EU0E9eQpDT05GSUdfTkVUX0RTQV9UQUdfRURTQT15CkNPTkZJ R19ORVRfRFNBX1RBR19UUkFJTEVSPXkKQ09ORklHX1ZMQU5fODAyMVE9bQpDT05GSUdfVkxBTl84 MDIxUV9HVlJQPXkKIyBDT05GSUdfREVDTkVUIGlzIG5vdCBzZXQKQ09ORklHX0xMQz1tCiMgQ09O RklHX0xMQzIgaXMgbm90IHNldApDT05GSUdfSVBYPW0KIyBDT05GSUdfSVBYX0lOVEVSTiBpcyBu b3Qgc2V0CkNPTkZJR19BVEFMSz1tCkNPTkZJR19ERVZfQVBQTEVUQUxLPW0KQ09ORklHX0lQRERQ PW0KQ09ORklHX0lQRERQX0VOQ0FQPXkKQ09ORklHX0lQRERQX0RFQ0FQPXkKIyBDT05GSUdfWDI1 IGlzIG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0CkNPTkZJR19XQU5fUk9VVEVSPW0K IyBDT05GSUdfUEhPTkVUIGlzIG5vdCBzZXQKQ09ORklHX0lFRUU4MDIxNTQ9bQpDT05GSUdfSUVF RTgwMjE1NF82TE9XUEFOPW0KQ09ORklHX01BQzgwMjE1ND1tCkNPTkZJR19ORVRfU0NIRUQ9eQoK IwojIFF1ZXVlaW5nL1NjaGVkdWxpbmcKIwpDT05GSUdfTkVUX1NDSF9DQlE9bQpDT05GSUdfTkVU X1NDSF9IVEI9bQpDT05GSUdfTkVUX1NDSF9IRlNDPW0KQ09ORklHX05FVF9TQ0hfQVRNPW0KQ09O RklHX05FVF9TQ0hfUFJJTz1tCkNPTkZJR19ORVRfU0NIX01VTFRJUT1tCkNPTkZJR19ORVRfU0NI X1JFRD1tCkNPTkZJR19ORVRfU0NIX1NGQj1tCkNPTkZJR19ORVRfU0NIX1NGUT1tCkNPTkZJR19O RVRfU0NIX1RFUUw9bQpDT05GSUdfTkVUX1NDSF9UQkY9bQpDT05GSUdfTkVUX1NDSF9HUkVEPW0K Q09ORklHX05FVF9TQ0hfRFNNQVJLPW0KQ09ORklHX05FVF9TQ0hfTkVURU09bQpDT05GSUdfTkVU X1NDSF9EUlI9bQpDT05GSUdfTkVUX1NDSF9NUVBSSU89bQpDT05GSUdfTkVUX1NDSF9DSE9LRT1t CkNPTkZJR19ORVRfU0NIX1FGUT1tCkNPTkZJR19ORVRfU0NIX0NPREVMPW0KQ09ORklHX05FVF9T Q0hfRlFfQ09ERUw9bQpDT05GSUdfTkVUX1NDSF9JTkdSRVNTPW0KQ09ORklHX05FVF9TQ0hfUExV Rz1tCgojCiMgQ2xhc3NpZmljYXRpb24KIwpDT05GSUdfTkVUX0NMUz15CkNPTkZJR19ORVRfQ0xT X0JBU0lDPW0KQ09ORklHX05FVF9DTFNfVENJTkRFWD1tCkNPTkZJR19ORVRfQ0xTX1JPVVRFND1t CkNPTkZJR19ORVRfQ0xTX0ZXPW0KQ09ORklHX05FVF9DTFNfVTMyPW0KQ09ORklHX0NMU19VMzJf UEVSRj15CkNPTkZJR19DTFNfVTMyX01BUks9eQpDT05GSUdfTkVUX0NMU19SU1ZQPW0KQ09ORklH X05FVF9DTFNfUlNWUDY9bQpDT05GSUdfTkVUX0NMU19GTE9XPW0KQ09ORklHX05FVF9DTFNfQ0dS T1VQPXkKQ09ORklHX05FVF9FTUFUQ0g9eQpDT05GSUdfTkVUX0VNQVRDSF9TVEFDSz0zMgpDT05G SUdfTkVUX0VNQVRDSF9DTVA9bQpDT05GSUdfTkVUX0VNQVRDSF9OQllURT1tCkNPTkZJR19ORVRf RU1BVENIX1UzMj1tCkNPTkZJR19ORVRfRU1BVENIX01FVEE9bQpDT05GSUdfTkVUX0VNQVRDSF9U RVhUPW0KQ09ORklHX05FVF9FTUFUQ0hfSVBTRVQ9bQpDT05GSUdfTkVUX0NMU19BQ1Q9eQpDT05G SUdfTkVUX0FDVF9QT0xJQ0U9bQpDT05GSUdfTkVUX0FDVF9HQUNUPW0KQ09ORklHX0dBQ1RfUFJP Qj15CkNPTkZJR19ORVRfQUNUX01JUlJFRD1tCkNPTkZJR19ORVRfQUNUX0lQVD1tCkNPTkZJR19O RVRfQUNUX05BVD1tCkNPTkZJR19ORVRfQUNUX1BFRElUPW0KQ09ORklHX05FVF9BQ1RfU0lNUD1t CkNPTkZJR19ORVRfQUNUX1NLQkVESVQ9bQpDT05GSUdfTkVUX0FDVF9DU1VNPW0KQ09ORklHX05F VF9DTFNfSU5EPXkKQ09ORklHX05FVF9TQ0hfRklGTz15CkNPTkZJR19EQ0I9eQpDT05GSUdfRE5T X1JFU09MVkVSPW0KQ09ORklHX0JBVE1BTl9BRFY9bQpDT05GSUdfQkFUTUFOX0FEVl9CTEE9eQoj IENPTkZJR19CQVRNQU5fQURWX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX09QRU5WU1dJVENIPW0K Q09ORklHX1JQUz15CkNPTkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKQ09ORklHX05FVFBS SU9fQ0dST1VQPW0KQ09ORklHX0JRTD15CkNPTkZJR19CUEZfSklUPXkKCiMKIyBOZXR3b3JrIHRl c3RpbmcKIwpDT05GSUdfTkVUX1BLVEdFTj1tCiMgQ09ORklHX05FVF9UQ1BQUk9CRSBpcyBub3Qg c2V0CkNPTkZJR19ORVRfRFJPUF9NT05JVE9SPXkKQ09ORklHX0hBTVJBRElPPXkKCiMKIyBQYWNr ZXQgUmFkaW8gcHJvdG9jb2xzCiMKQ09ORklHX0FYMjU9bQpDT05GSUdfQVgyNV9EQU1BX1NMQVZF PXkKQ09ORklHX05FVFJPTT1tCkNPTkZJR19ST1NFPW0KCiMKIyBBWC4yNSBuZXR3b3JrIGRldmlj ZSBkcml2ZXJzCiMKQ09ORklHX01LSVNTPW0KQ09ORklHXzZQQUNLPW0KQ09ORklHX0JQUUVUSEVS PW0KQ09ORklHX0JBWUNPTV9TRVJfRkRYPW0KQ09ORklHX0JBWUNPTV9TRVJfSERYPW0KQ09ORklH X0JBWUNPTV9QQVI9bQpDT05GSUdfWUFNPW0KIyBDT05GSUdfQ0FOIGlzIG5vdCBzZXQKQ09ORklH X0lSREE9bQoKIwojIElyREEgcHJvdG9jb2xzCiMKQ09ORklHX0lSTEFOPW0KQ09ORklHX0lSTkVU PW0KQ09ORklHX0lSQ09NTT1tCiMgQ09ORklHX0lSREFfVUxUUkEgaXMgbm90IHNldAoKIwojIEly REEgb3B0aW9ucwojCkNPTkZJR19JUkRBX0NBQ0hFX0xBU1RfTFNBUD15CkNPTkZJR19JUkRBX0ZB U1RfUlI9eQojIENPTkZJR19JUkRBX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBJbmZyYXJlZC1wb3J0 IGRldmljZSBkcml2ZXJzCiMKCiMKIyBTSVIgZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfSVJUVFlf U0lSPW0KCiMKIyBEb25nbGUgc3VwcG9ydAojCkNPTkZJR19ET05HTEU9eQpDT05GSUdfRVNJX0RP TkdMRT1tCkNPTkZJR19BQ1RJU1lTX0RPTkdMRT1tCkNPTkZJR19URUtSQU1fRE9OR0xFPW0KQ09O RklHX1RPSU0zMjMyX0RPTkdMRT1tCkNPTkZJR19MSVRFTElOS19ET05HTEU9bQpDT05GSUdfTUE2 MDBfRE9OR0xFPW0KQ09ORklHX0dJUkJJTF9ET05HTEU9bQpDT05GSUdfTUNQMjEyMF9ET05HTEU9 bQpDT05GSUdfT0xEX0JFTEtJTl9ET05HTEU9bQpDT05GSUdfQUNUMjAwTF9ET05HTEU9bQpDT05G SUdfS0lOR1NVTl9ET05HTEU9bQpDT05GSUdfS1NEQVpaTEVfRE9OR0xFPW0KQ09ORklHX0tTOTU5 X0RPTkdMRT1tCgojCiMgRklSIGRldmljZSBkcml2ZXJzCiMKQ09ORklHX1VTQl9JUkRBPW0KQ09O RklHX1NJR01BVEVMX0ZJUj1tCkNPTkZJR19OU0NfRklSPW0KQ09ORklHX1dJTkJPTkRfRklSPW0K Q09ORklHX1NNQ19JUkNDX0ZJUj1tCkNPTkZJR19BTElfRklSPW0KQ09ORklHX1ZMU0lfRklSPW0K Q09ORklHX1ZJQV9GSVI9bQpDT05GSUdfTUNTX0ZJUj1tCkNPTkZJR19CVD1tCkNPTkZJR19CVF9S RkNPTU09bQpDT05GSUdfQlRfUkZDT01NX1RUWT15CkNPTkZJR19CVF9CTkVQPW0KQ09ORklHX0JU X0JORVBfTUNfRklMVEVSPXkKQ09ORklHX0JUX0JORVBfUFJPVE9fRklMVEVSPXkKQ09ORklHX0JU X0NNVFA9bQpDT05GSUdfQlRfSElEUD1tCgojCiMgQmx1ZXRvb3RoIGRldmljZSBkcml2ZXJzCiMK Q09ORklHX0JUX0hDSUJUVVNCPW0KQ09ORklHX0JUX0hDSUJUU0RJTz1tCkNPTkZJR19CVF9IQ0lV QVJUPW0KQ09ORklHX0JUX0hDSVVBUlRfSDQ9eQpDT05GSUdfQlRfSENJVUFSVF9CQ1NQPXkKQ09O RklHX0JUX0hDSVVBUlRfQVRIM0s9eQpDT05GSUdfQlRfSENJVUFSVF9MTD15CkNPTkZJR19CVF9I Q0lVQVJUXzNXSVJFPXkKQ09ORklHX0JUX0hDSUJDTTIwM1g9bQpDT05GSUdfQlRfSENJQlBBMTBY PW0KQ09ORklHX0JUX0hDSUJGVVNCPW0KQ09ORklHX0JUX0hDSURUTDE9bQpDT05GSUdfQlRfSENJ QlQzQz1tCkNPTkZJR19CVF9IQ0lCTFVFQ0FSRD1tCkNPTkZJR19CVF9IQ0lCVFVBUlQ9bQpDT05G SUdfQlRfSENJVkhDST1tCkNPTkZJR19CVF9NUlZMPW0KQ09ORklHX0JUX01SVkxfU0RJTz1tCkNP TkZJR19CVF9BVEgzSz1tCiMgQ09ORklHX0FGX1JYUlBDIGlzIG5vdCBzZXQKQ09ORklHX0ZJQl9S VUxFUz15CkNPTkZJR19XSVJFTEVTUz15CkNPTkZJR19XSVJFTEVTU19FWFQ9eQpDT05GSUdfV0VY VF9DT1JFPXkKQ09ORklHX1dFWFRfUFJPQz15CkNPTkZJR19XRVhUX1NQWT15CkNPTkZJR19XRVhU X1BSSVY9eQpDT05GSUdfQ0ZHODAyMTE9bQojIENPTkZJR19OTDgwMjExX1RFU1RNT0RFIGlzIG5v dCBzZXQKIyBDT05GSUdfQ0ZHODAyMTFfREVWRUxPUEVSX1dBUk5JTkdTIGlzIG5vdCBzZXQKIyBD T05GSUdfQ0ZHODAyMTFfUkVHX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0NGRzgwMjExX0RFRkFV TFRfUFM9eQpDT05GSUdfQ0ZHODAyMTFfREVCVUdGUz15CiMgQ09ORklHX0NGRzgwMjExX0lOVEVS TkFMX1JFR0RCIGlzIG5vdCBzZXQKQ09ORklHX0NGRzgwMjExX1dFWFQ9eQpDT05GSUdfTElCODAy MTE9bQpDT05GSUdfTElCODAyMTFfQ1JZUFRfV0VQPW0KQ09ORklHX0xJQjgwMjExX0NSWVBUX0ND TVA9bQpDT05GSUdfTElCODAyMTFfQ1JZUFRfVEtJUD1tCiMgQ09ORklHX0xJQjgwMjExX0RFQlVH IGlzIG5vdCBzZXQKQ09ORklHX01BQzgwMjExPW0KQ09ORklHX01BQzgwMjExX0hBU19SQz15CkNP TkZJR19NQUM4MDIxMV9SQ19NSU5TVFJFTD15CkNPTkZJR19NQUM4MDIxMV9SQ19NSU5TVFJFTF9I VD15CkNPTkZJR19NQUM4MDIxMV9SQ19ERUZBVUxUX01JTlNUUkVMPXkKQ09ORklHX01BQzgwMjEx X1JDX0RFRkFVTFQ9Im1pbnN0cmVsX2h0IgpDT05GSUdfTUFDODAyMTFfTUVTSD15CkNPTkZJR19N QUM4MDIxMV9MRURTPXkKQ09ORklHX01BQzgwMjExX0RFQlVHRlM9eQojIENPTkZJR19NQUM4MDIx MV9NRVNTQUdFX1RSQUNJTkcgaXMgbm90IHNldAojIENPTkZJR19NQUM4MDIxMV9ERUJVR19NRU5V IGlzIG5vdCBzZXQKQ09ORklHX1dJTUFYPW0KQ09ORklHX1dJTUFYX0RFQlVHX0xFVkVMPTgKQ09O RklHX1JGS0lMTD1tCkNPTkZJR19SRktJTExfTEVEUz15CkNPTkZJR19SRktJTExfSU5QVVQ9eQpD T05GSUdfTkVUXzlQPW0KQ09ORklHX05FVF85UF9WSVJUSU89bQpDT05GSUdfTkVUXzlQX1JETUE9 bQojIENPTkZJR19ORVRfOVBfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19DQUlGIGlzIG5vdCBz ZXQKQ09ORklHX0NFUEhfTElCPW0KIyBDT05GSUdfQ0VQSF9MSUJfUFJFVFRZREVCVUcgaXMgbm90 IHNldAojIENPTkZJR19DRVBIX0xJQl9VU0VfRE5TX1JFU09MVkVSIGlzIG5vdCBzZXQKQ09ORklH X05GQz1tCkNPTkZJR19ORkNfTkNJPW0KQ09ORklHX05GQ19IQ0k9bQpDT05GSUdfTkZDX1NIRExD PXkKQ09ORklHX05GQ19MTENQPXkKCiMKIyBOZWFyIEZpZWxkIENvbW11bmljYXRpb24gKE5GQykg ZGV2aWNlcwojCkNPTkZJR19QTjU0NF9ORkM9bQpDT05GSUdfUE41NDRfSENJX05GQz1tCkNPTkZJ R19ORkNfUE41MzM9bQpDT05GSUdfSEFWRV9CUEZfSklUPXkKCiMKIyBEZXZpY2UgRHJpdmVycwoj CgojCiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucwojCkNPTkZJR19VRVZFTlRfSEVMUEVSX1BBVEg9 IiIKQ09ORklHX0RFVlRNUEZTPXkKQ09ORklHX0RFVlRNUEZTX01PVU5UPXkKQ09ORklHX1NUQU5E QUxPTkU9eQpDT05GSUdfUFJFVkVOVF9GSVJNV0FSRV9CVUlMRD15CkNPTkZJR19GV19MT0FERVI9 eQojIENPTkZJR19GSVJNV0FSRV9JTl9LRVJORUwgaXMgbm90IHNldApDT05GSUdfRVhUUkFfRklS TVdBUkU9IiIKIyBDT05GSUdfREVCVUdfRFJJVkVSIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX0RF VlJFUz15CkNPTkZJR19TWVNfSFlQRVJWSVNPUj15CiMgQ09ORklHX0dFTkVSSUNfQ1BVX0RFVklD RVMgaXMgbm90IHNldApDT05GSUdfUkVHTUFQPXkKQ09ORklHX1JFR01BUF9JMkM9bQpDT05GSUdf RE1BX1NIQVJFRF9CVUZGRVI9eQpDT05GSUdfQ09OTkVDVE9SPXkKQ09ORklHX1BST0NfRVZFTlRT PXkKQ09ORklHX01URD1tCiMgQ09ORklHX01URF9URVNUUyBpcyBub3Qgc2V0CiMgQ09ORklHX01U RF9SRURCT09UX1BBUlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX0FSN19QQVJUUyBpcyBub3Qg c2V0CgojCiMgVXNlciBNb2R1bGVzIEFuZCBUcmFuc2xhdGlvbiBMYXllcnMKIwojIENPTkZJR19N VERfQ0hBUiBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9CTEtERVZTIGlzIG5vdCBzZXQKIyBDT05G SUdfTVREX0JMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX0JMT0NLX1JPIGlzIG5vdCBzZXQK IyBDT05GSUdfRlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZUTCBpcyBub3Qgc2V0CiMgQ09ORklH X0lORlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfUkZEX0ZUTCBpcyBub3Qgc2V0CiMgQ09ORklHX1NT RkRDIGlzIG5vdCBzZXQKIyBDT05GSUdfU01fRlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX09P UFMgaXMgbm90IHNldAojIENPTkZJR19NVERfU1dBUCBpcyBub3Qgc2V0CgojCiMgUkFNL1JPTS9G bGFzaCBjaGlwIGRyaXZlcnMKIwojIENPTkZJR19NVERfQ0ZJIGlzIG5vdCBzZXQKIyBDT05GSUdf TVREX0pFREVDUFJPQkUgaXMgbm90IHNldApDT05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzE9eQpD T05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzI9eQpDT05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzQ9 eQojIENPTkZJR19NVERfTUFQX0JBTktfV0lEVEhfOCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9N QVBfQkFOS19XSURUSF8xNiBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9NQVBfQkFOS19XSURUSF8z MiBpcyBub3Qgc2V0CkNPTkZJR19NVERfQ0ZJX0kxPXkKQ09ORklHX01URF9DRklfSTI9eQojIENP TkZJR19NVERfQ0ZJX0k0IGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX0NGSV9JOCBpcyBub3Qgc2V0 CiMgQ09ORklHX01URF9SQU0gaXMgbm90IHNldAojIENPTkZJR19NVERfUk9NIGlzIG5vdCBzZXQK IyBDT05GSUdfTVREX0FCU0VOVCBpcyBub3Qgc2V0CgojCiMgTWFwcGluZyBkcml2ZXJzIGZvciBj aGlwIGFjY2VzcwojCiMgQ09ORklHX01URF9DT01QTEVYX01BUFBJTkdTIGlzIG5vdCBzZXQKIyBD T05GSUdfTVREX1RTNTUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9JTlRFTF9WUl9OT1IgaXMg bm90IHNldAojIENPTkZJR19NVERfUExBVFJBTSBpcyBub3Qgc2V0CgojCiMgU2VsZi1jb250YWlu ZWQgTVREIGRldmljZSBkcml2ZXJzCiMKIyBDT05GSUdfTVREX1BNQzU1MSBpcyBub3Qgc2V0CiMg Q09ORklHX01URF9TTFJBTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9QSFJBTSBpcyBub3Qgc2V0 CiMgQ09ORklHX01URF9NVERSQU0gaXMgbm90IHNldAojIENPTkZJR19NVERfQkxPQ0syTVREIGlz IG5vdCBzZXQKCiMKIyBEaXNrLU9uLUNoaXAgRGV2aWNlIERyaXZlcnMKIwojIENPTkZJR19NVERf RE9DRzMgaXMgbm90IHNldAojIENPTkZJR19NVERfTkFORCBpcyBub3Qgc2V0CiMgQ09ORklHX01U RF9PTkVOQU5EIGlzIG5vdCBzZXQKCiMKIyBMUEREUiBmbGFzaCBtZW1vcnkgZHJpdmVycwojCiMg Q09ORklHX01URF9MUEREUiBpcyBub3Qgc2V0CkNPTkZJR19NVERfVUJJPW0KQ09ORklHX01URF9V QklfV0xfVEhSRVNIT0xEPTQwOTYKQ09ORklHX01URF9VQklfQkVCX1JFU0VSVkU9MgojIENPTkZJ R19NVERfVUJJX0dMVUVCSSBpcyBub3Qgc2V0CkNPTkZJR19QQVJQT1JUPW0KQ09ORklHX1BBUlBP UlRfUEM9bQpDT05GSUdfUEFSUE9SVF9TRVJJQUw9bQojIENPTkZJR19QQVJQT1JUX1BDX0ZJRk8g aXMgbm90IHNldAojIENPTkZJR19QQVJQT1JUX1BDX1NVUEVSSU8gaXMgbm90IHNldApDT05GSUdf UEFSUE9SVF9QQ19QQ01DSUE9bQojIENPTkZJR19QQVJQT1JUX0dTQyBpcyBub3Qgc2V0CiMgQ09O RklHX1BBUlBPUlRfQVg4ODc5NiBpcyBub3Qgc2V0CkNPTkZJR19QQVJQT1JUXzEyODQ9eQpDT05G SUdfUEFSUE9SVF9OT1RfUEM9eQpDT05GSUdfUE5QPXkKIyBDT05GSUdfUE5QX0RFQlVHX01FU1NB R0VTIGlzIG5vdCBzZXQKCiMKIyBQcm90b2NvbHMKIwpDT05GSUdfUE5QQUNQST15CkNPTkZJR19C TEtfREVWPXkKQ09ORklHX0JMS19ERVZfRkQ9bQojIENPTkZJR19QQVJJREUgaXMgbm90IHNldApD T05GSUdfQkxLX0RFVl9QQ0lFU1NEX01USVAzMlhYPW0KQ09ORklHX0JMS19DUFFfREE9bQpDT05G SUdfQkxLX0NQUV9DSVNTX0RBPW0KQ09ORklHX0NJU1NfU0NTSV9UQVBFPXkKQ09ORklHX0JMS19E RVZfREFDOTYwPW0KQ09ORklHX0JMS19ERVZfVU1FTT1tCiMgQ09ORklHX0JMS19ERVZfQ09XX0NP TU1PTiBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0xPT1A9eQpDT05GSUdfQkxLX0RFVl9MT09Q X01JTl9DT1VOVD04CkNPTkZJR19CTEtfREVWX0NSWVBUT0xPT1A9bQpDT05GSUdfQkxLX0RFVl9E UkJEPW0KIyBDT05GSUdfRFJCRF9GQVVMVF9JTkpFQ1RJT04gaXMgbm90IHNldApDT05GSUdfQkxL X0RFVl9OQkQ9bQpDT05GSUdfQkxLX0RFVl9OVk1FPW0KQ09ORklHX0JMS19ERVZfT1NEPW0KQ09O RklHX0JMS19ERVZfU1g4PW0KIyBDT05GSUdfQkxLX0RFVl9VQiBpcyBub3Qgc2V0CkNPTkZJR19C TEtfREVWX1JBTT1tCkNPTkZJR19CTEtfREVWX1JBTV9DT1VOVD0xNgpDT05GSUdfQkxLX0RFVl9S QU1fU0laRT0xNjM4NAojIENPTkZJR19CTEtfREVWX1hJUCBpcyBub3Qgc2V0CkNPTkZJR19DRFJP TV9QS1RDRFZEPW0KQ09ORklHX0NEUk9NX1BLVENEVkRfQlVGRkVSUz04CiMgQ09ORklHX0NEUk9N X1BLVENEVkRfV0NBQ0hFIGlzIG5vdCBzZXQKQ09ORklHX0FUQV9PVkVSX0VUSD1tCkNPTkZJR19Y RU5fQkxLREVWX0ZST05URU5EPXkKQ09ORklHX1hFTl9CTEtERVZfQkFDS0VORD15CkNPTkZJR19W SVJUSU9fQkxLPW0KIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVW X1JCRD1tCgojCiMgTWlzYyBkZXZpY2VzCiMKQ09ORklHX1NFTlNPUlNfTElTM0xWMDJEPW0KIyBD T05GSUdfQUQ1MjVYX0RQT1QgaXMgbm90IHNldAojIENPTkZJR19JQk1fQVNNIGlzIG5vdCBzZXQK IyBDT05GSUdfUEhBTlRPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOVEVMX01JRF9QVEkgaXMgbm90 IHNldApDT05GSUdfU0dJX0lPQzQ9bQpDT05GSUdfVElGTV9DT1JFPW0KQ09ORklHX1RJRk1fN1hY MT1tCiMgQ09ORklHX0lDUzkzMlM0MDEgaXMgbm90IHNldApDT05GSUdfRU5DTE9TVVJFX1NFUlZJ Q0VTPW0KQ09ORklHX0hQX0lMTz1tCkNPTkZJR19BUERTOTgwMkFMUz1tCkNPTkZJR19JU0wyOTAw Mz1tCkNPTkZJR19JU0wyOTAyMD1tCkNPTkZJR19TRU5TT1JTX1RTTDI1NTA9bQojIENPTkZJR19T RU5TT1JTX0JIMTc4MCBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0JIMTc3MD1tCkNPTkZJR19T RU5TT1JTX0FQRFM5OTBYPW0KIyBDT05GSUdfSE1DNjM1MiBpcyBub3Qgc2V0CiMgQ09ORklHX0RT MTY4MiBpcyBub3Qgc2V0CkNPTkZJR19WTVdBUkVfQkFMTE9PTj1tCiMgQ09ORklHX0JNUDA4NV9J MkMgaXMgbm90IHNldApDT05GSUdfUENIX1BIVUI9bQojIENPTkZJR19VU0JfU1dJVENIX0ZTQTk0 ODAgaXMgbm90IHNldAojIENPTkZJR19DMlBPUlQgaXMgbm90IHNldAoKIwojIEVFUFJPTSBzdXBw b3J0CiMKQ09ORklHX0VFUFJPTV9BVDI0PW0KQ09ORklHX0VFUFJPTV9MRUdBQ1k9bQpDT05GSUdf RUVQUk9NX01BWDY4NzU9bQpDT05GSUdfRUVQUk9NXzkzQ1g2PW0KQ09ORklHX0NCNzEwX0NPUkU9 bQojIENPTkZJR19DQjcxMF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19DQjcxMF9ERUJVR19BU1NV TVBUSU9OUz15CgojCiMgVGV4YXMgSW5zdHJ1bWVudHMgc2hhcmVkIHRyYW5zcG9ydCBsaW5lIGRp c2NpcGxpbmUKIwpDT05GSUdfU0VOU09SU19MSVMzX0kyQz1tCgojCiMgQWx0ZXJhIEZQR0EgZmly bXdhcmUgZG93bmxvYWQgbW9kdWxlCiMKQ09ORklHX0FMVEVSQV9TVEFQTD1tCkNPTkZJR19JTlRF TF9NRUk9bQpDT05GSUdfSEFWRV9JREU9eQojIENPTkZJR19JREUgaXMgbm90IHNldAoKIwojIFND U0kgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfU0NTSV9NT0Q9eQpDT05GSUdfUkFJRF9BVFRSUz1t CkNPTkZJR19TQ1NJPXkKQ09ORklHX1NDU0lfRE1BPXkKQ09ORklHX1NDU0lfVEdUPW0KQ09ORklH X1NDU0lfTkVUTElOSz15CkNPTkZJR19TQ1NJX1BST0NfRlM9eQoKIwojIFNDU0kgc3VwcG9ydCB0 eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pCiMKQ09ORklHX0JMS19ERVZfU0Q9eQpDT05GSUdfQ0hS X0RFVl9TVD1tCkNPTkZJR19DSFJfREVWX09TU1Q9bQpDT05GSUdfQkxLX0RFVl9TUj15CkNPTkZJ R19CTEtfREVWX1NSX1ZFTkRPUj15CkNPTkZJR19DSFJfREVWX1NHPXkKQ09ORklHX0NIUl9ERVZf U0NIPW0KQ09ORklHX1NDU0lfRU5DTE9TVVJFPW0KQ09ORklHX1NDU0lfTVVMVElfTFVOPXkKQ09O RklHX1NDU0lfQ09OU1RBTlRTPXkKQ09ORklHX1NDU0lfTE9HR0lORz15CkNPTkZJR19TQ1NJX1ND QU5fQVNZTkM9eQoKIwojIFNDU0kgVHJhbnNwb3J0cwojCkNPTkZJR19TQ1NJX1NQSV9BVFRSUz1t CkNPTkZJR19TQ1NJX0ZDX0FUVFJTPW0KQ09ORklHX1NDU0lfRkNfVEdUX0FUVFJTPXkKQ09ORklH X1NDU0lfSVNDU0lfQVRUUlM9bQpDT05GSUdfU0NTSV9TQVNfQVRUUlM9bQpDT05GSUdfU0NTSV9T QVNfTElCU0FTPW0KQ09ORklHX1NDU0lfU0FTX0FUQT15CkNPTkZJR19TQ1NJX1NBU19IT1NUX1NN UD15CkNPTkZJR19TQ1NJX1NSUF9BVFRSUz1tCkNPTkZJR19TQ1NJX1NSUF9UR1RfQVRUUlM9eQpD T05GSUdfU0NTSV9MT1dMRVZFTD15CkNPTkZJR19JU0NTSV9UQ1A9bQpDT05GSUdfSVNDU0lfQk9P VF9TWVNGUz1tCkNPTkZJR19TQ1NJX0NYR0IzX0lTQ1NJPW0KQ09ORklHX1NDU0lfQ1hHQjRfSVND U0k9bQpDT05GSUdfU0NTSV9CTlgyX0lTQ1NJPW0KQ09ORklHX1NDU0lfQk5YMlhfRkNPRT1tCkNP TkZJR19CRTJJU0NTST1tCkNPTkZJR19CTEtfREVWXzNXX1hYWFhfUkFJRD1tCkNPTkZJR19TQ1NJ X0hQU0E9bQpDT05GSUdfU0NTSV8zV185WFhYPW0KQ09ORklHX1NDU0lfM1dfU0FTPW0KQ09ORklH X1NDU0lfQUNBUkQ9bQpDT05GSUdfU0NTSV9BQUNSQUlEPW0KQ09ORklHX1NDU0lfQUlDN1hYWD1t CkNPTkZJR19BSUM3WFhYX0NNRFNfUEVSX0RFVklDRT00CkNPTkZJR19BSUM3WFhYX1JFU0VUX0RF TEFZX01TPTE1MDAwCiMgQ09ORklHX0FJQzdYWFhfREVCVUdfRU5BQkxFIGlzIG5vdCBzZXQKQ09O RklHX0FJQzdYWFhfREVCVUdfTUFTSz0wCiMgQ09ORklHX0FJQzdYWFhfUkVHX1BSRVRUWV9QUklO VCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX0FJQzdYWFhfT0xEPW0KQ09ORklHX1NDU0lfQUlDNzlY WD1tCkNPTkZJR19BSUM3OVhYX0NNRFNfUEVSX0RFVklDRT00CkNPTkZJR19BSUM3OVhYX1JFU0VU X0RFTEFZX01TPTE1MDAwCiMgQ09ORklHX0FJQzc5WFhfREVCVUdfRU5BQkxFIGlzIG5vdCBzZXQK Q09ORklHX0FJQzc5WFhfREVCVUdfTUFTSz0wCiMgQ09ORklHX0FJQzc5WFhfUkVHX1BSRVRUWV9Q UklOVCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX0FJQzk0WFg9bQojIENPTkZJR19BSUM5NFhYX0RF QlVHIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfTVZTQVM9bQojIENPTkZJR19TQ1NJX01WU0FTX0RF QlVHIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfTVZTQVNfVEFTS0xFVD15CkNPTkZJR19TQ1NJX01W VU1JPW0KIyBDT05GSUdfU0NTSV9EUFRfSTJPIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfQURWQU5T WVM9bQpDT05GSUdfU0NTSV9BUkNNU1I9bQpDT05GSUdfTUVHQVJBSURfTkVXR0VOPXkKQ09ORklH X01FR0FSQUlEX01NPW0KQ09ORklHX01FR0FSQUlEX01BSUxCT1g9bQpDT05GSUdfTUVHQVJBSURf TEVHQUNZPW0KQ09ORklHX01FR0FSQUlEX1NBUz1tCkNPTkZJR19TQ1NJX01QVDJTQVM9bQpDT05G SUdfU0NTSV9NUFQyU0FTX01BWF9TR0U9MTI4CkNPTkZJR19TQ1NJX01QVDJTQVNfTE9HR0lORz15 CkNPTkZJR19TQ1NJX1VGU0hDRD1tCkNPTkZJR19TQ1NJX0hQVElPUD1tCkNPTkZJR19TQ1NJX0JV U0xPR0lDPW0KQ09ORklHX1ZNV0FSRV9QVlNDU0k9bQpDT05GSUdfSFlQRVJWX1NUT1JBR0U9bQpD T05GSUdfTElCRkM9bQpDT05GSUdfTElCRkNPRT1tCkNPTkZJR19GQ09FPW0KQ09ORklHX0ZDT0Vf Rk5JQz1tCiMgQ09ORklHX1NDU0lfRE1YMzE5MUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0VB VEEgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldApDT05G SUdfU0NTSV9HRFRIPW0KQ09ORklHX1NDU0lfSVNDST1tCkNPTkZJR19TQ1NJX0lQUz1tCkNPTkZJ R19TQ1NJX0lOSVRJTz1tCkNPTkZJR19TQ1NJX0lOSUExMDA9bQojIENPTkZJR19TQ1NJX1BQQSBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSU1NIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfU1RFWD1t CkNPTkZJR19TQ1NJX1NZTTUzQzhYWF8yPW0KQ09ORklHX1NDU0lfU1lNNTNDOFhYX0RNQV9BRERS RVNTSU5HX01PREU9MQpDT05GSUdfU0NTSV9TWU01M0M4WFhfREVGQVVMVF9UQUdTPTE2CkNPTkZJ R19TQ1NJX1NZTTUzQzhYWF9NQVhfVEFHUz02NApDT05GSUdfU0NTSV9TWU01M0M4WFhfTU1JTz15 CiMgQ09ORklHX1NDU0lfSVBSIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfUUxPR0lDXzEyODA9bQpD T05GSUdfU0NTSV9RTEFfRkM9bQpDT05GSUdfVENNX1FMQTJYWFg9bQpDT05GSUdfU0NTSV9RTEFf SVNDU0k9bQpDT05GSUdfU0NTSV9MUEZDPW0KIyBDT05GSUdfU0NTSV9MUEZDX0RFQlVHX0ZTIGlz IG5vdCBzZXQKQ09ORklHX1NDU0lfREMzOTV4PW0KQ09ORklHX1NDU0lfREMzOTBUPW0KQ09ORklH X1NDU0lfREVCVUc9bQpDT05GSUdfU0NTSV9QTUNSQUlEPW0KQ09ORklHX1NDU0lfUE04MDAxPW0K Q09ORklHX1NDU0lfU1JQPW0KQ09ORklHX1NDU0lfQkZBX0ZDPW0KQ09ORklHX1NDU0lfVklSVElP PW0KIyBDT05GSUdfU0NTSV9MT1dMRVZFTF9QQ01DSUEgaXMgbm90IHNldApDT05GSUdfU0NTSV9E SD15CkNPTkZJR19TQ1NJX0RIX1JEQUM9bQpDT05GSUdfU0NTSV9ESF9IUF9TVz1tCkNPTkZJR19T Q1NJX0RIX0VNQz1tCkNPTkZJR19TQ1NJX0RIX0FMVUE9bQpDT05GSUdfU0NTSV9PU0RfSU5JVElB VE9SPW0KQ09ORklHX1NDU0lfT1NEX1VMRD1tCkNPTkZJR19TQ1NJX09TRF9EUFJJTlRfU0VOU0U9 MQojIENPTkZJR19TQ1NJX09TRF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BVEE9eQojIENPTkZJ R19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZFUkJPU0VfRVJST1I9eQpD T05GSUdfQVRBX0FDUEk9eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRyb2xsZXJzIHdpdGgg bm9uLVNGRiBuYXRpdmUgaW50ZXJmYWNlCiMKQ09ORklHX1NBVEFfQUhDST15CkNPTkZJR19TQVRB X0FIQ0lfUExBVEZPUk09bQpDT05GSUdfU0FUQV9JTklDMTYyWD1tCkNPTkZJR19TQVRBX0FDQVJE X0FIQ0k9bQpDT05GSUdfU0FUQV9TSUwyND1tCkNPTkZJR19BVEFfU0ZGPXkKCiMKIyBTRkYgY29u dHJvbGxlcnMgd2l0aCBjdXN0b20gRE1BIGludGVyZmFjZQojCkNPTkZJR19QRENfQURNQT1tCkNP TkZJR19TQVRBX1FTVE9SPW0KQ09ORklHX1NBVEFfU1g0PW0KQ09ORklHX0FUQV9CTURNQT15Cgoj CiMgU0FUQSBTRkYgY29udHJvbGxlcnMgd2l0aCBCTURNQQojCkNPTkZJR19BVEFfUElJWD15CiMg Q09ORklHX1NBVEFfSElHSEJBTksgaXMgbm90IHNldApDT05GSUdfU0FUQV9NVj1tCkNPTkZJR19T QVRBX05WPW0KQ09ORklHX1NBVEFfUFJPTUlTRT1tCkNPTkZJR19TQVRBX1NJTD1tCkNPTkZJR19T QVRBX1NJUz1tCkNPTkZJR19TQVRBX1NWVz1tCkNPTkZJR19TQVRBX1VMST1tCkNPTkZJR19TQVRB X1ZJQT1tCkNPTkZJR19TQVRBX1ZJVEVTU0U9bQoKIwojIFBBVEEgU0ZGIGNvbnRyb2xsZXJzIHdp dGggQk1ETUEKIwpDT05GSUdfUEFUQV9BTEk9bQpDT05GSUdfUEFUQV9BTUQ9bQpDT05GSUdfUEFU QV9BUkFTQU5fQ0Y9bQpDT05GSUdfUEFUQV9BUlRPUD1tCkNPTkZJR19QQVRBX0FUSUlYUD1tCkNP TkZJR19QQVRBX0FUUDg2N1g9bQpDT05GSUdfUEFUQV9DTUQ2NFg9bQpDT05GSUdfUEFUQV9DUzU1 MjA9bQpDT05GSUdfUEFUQV9DUzU1MzA9bQpDT05GSUdfUEFUQV9DUzU1MzY9bQpDT05GSUdfUEFU QV9DWVBSRVNTPW0KQ09ORklHX1BBVEFfRUZBUj1tCkNPTkZJR19QQVRBX0hQVDM2Nj1tCkNPTkZJ R19QQVRBX0hQVDM3WD1tCkNPTkZJR19QQVRBX0hQVDNYMk49bQpDT05GSUdfUEFUQV9IUFQzWDM9 bQojIENPTkZJR19QQVRBX0hQVDNYM19ETUEgaXMgbm90IHNldApDT05GSUdfUEFUQV9JVDgyMTM9 bQpDT05GSUdfUEFUQV9JVDgyMVg9bQpDT05GSUdfUEFUQV9KTUlDUk9OPW0KQ09ORklHX1BBVEFf TUFSVkVMTD1tCkNPTkZJR19QQVRBX05FVENFTEw9bQpDT05GSUdfUEFUQV9OSU5KQTMyPW0KQ09O RklHX1BBVEFfTlM4NzQxNT1tCkNPTkZJR19QQVRBX09MRFBJSVg9bQpDT05GSUdfUEFUQV9PUFRJ RE1BPW0KQ09ORklHX1BBVEFfUERDMjAyN1g9bQpDT05GSUdfUEFUQV9QRENfT0xEPW0KIyBDT05G SUdfUEFUQV9SQURJU1lTIGlzIG5vdCBzZXQKQ09ORklHX1BBVEFfUkRDPW0KIyBDT05GSUdfUEFU QV9TQzEyMDAgaXMgbm90IHNldApDT05GSUdfUEFUQV9TQ0g9bQpDT05GSUdfUEFUQV9TRVJWRVJX T1JLUz1tCkNPTkZJR19QQVRBX1NJTDY4MD1tCkNPTkZJR19QQVRBX1NJUz1tCkNPTkZJR19QQVRB X1RPU0hJQkE9bQpDT05GSUdfUEFUQV9UUklGTEVYPW0KQ09ORklHX1BBVEFfVklBPW0KQ09ORklH X1BBVEFfV0lOQk9ORD1tCgojCiMgUElPLW9ubHkgU0ZGIGNvbnRyb2xsZXJzCiMKQ09ORklHX1BB VEFfQ01ENjQwX1BDST1tCkNPTkZJR19QQVRBX01QSUlYPW0KQ09ORklHX1BBVEFfTlM4NzQxMD1t CkNPTkZJR19QQVRBX09QVEk9bQpDT05GSUdfUEFUQV9QQ01DSUE9bQojIENPTkZJR19QQVRBX1Ja MTAwMCBpcyBub3Qgc2V0CgojCiMgR2VuZXJpYyBmYWxsYmFjayAvIGxlZ2FjeSBkcml2ZXJzCiMK Q09ORklHX1BBVEFfQUNQST1tCkNPTkZJR19BVEFfR0VORVJJQz1tCiMgQ09ORklHX1BBVEFfTEVH QUNZIGlzIG5vdCBzZXQKQ09ORklHX01EPXkKQ09ORklHX0JMS19ERVZfTUQ9eQpDT05GSUdfTURf QVVUT0RFVEVDVD15CkNPTkZJR19NRF9MSU5FQVI9bQpDT05GSUdfTURfUkFJRDA9bQpDT05GSUdf TURfUkFJRDE9bQpDT05GSUdfTURfUkFJRDEwPW0KQ09ORklHX01EX1JBSUQ0NTY9bQojIENPTkZJ R19NVUxUSUNPUkVfUkFJRDQ1NiBpcyBub3Qgc2V0CkNPTkZJR19NRF9NVUxUSVBBVEg9bQpDT05G SUdfTURfRkFVTFRZPW0KQ09ORklHX0JMS19ERVZfRE09eQpDT05GSUdfRE1fREVCVUc9eQpDT05G SUdfRE1fQlVGSU89bQpDT05GSUdfRE1fUEVSU0lTVEVOVF9EQVRBPW0KQ09ORklHX0RNX0NSWVBU PW0KQ09ORklHX0RNX1NOQVBTSE9UPXkKQ09ORklHX0RNX1RISU5fUFJPVklTSU9OSU5HPW0KIyBD T05GSUdfRE1fREVCVUdfQkxPQ0tfU1RBQ0tfVFJBQ0lORyBpcyBub3Qgc2V0CkNPTkZJR19ETV9N SVJST1I9eQpDT05GSUdfRE1fUkFJRD1tCkNPTkZJR19ETV9MT0dfVVNFUlNQQUNFPW0KQ09ORklH X0RNX1pFUk89eQpDT05GSUdfRE1fTVVMVElQQVRIPW0KQ09ORklHX0RNX01VTFRJUEFUSF9RTD1t CkNPTkZJR19ETV9NVUxUSVBBVEhfU1Q9bQojIENPTkZJR19ETV9ERUxBWSBpcyBub3Qgc2V0CkNP TkZJR19ETV9VRVZFTlQ9eQpDT05GSUdfRE1fRkxBS0VZPW0KQ09ORklHX0RNX1ZFUklUWT1tCkNP TkZJR19UQVJHRVRfQ09SRT1tCkNPTkZJR19UQ01fSUJMT0NLPW0KQ09ORklHX1RDTV9GSUxFSU89 bQpDT05GSUdfVENNX1BTQ1NJPW0KQ09ORklHX0xPT1BCQUNLX1RBUkdFVD1tCkNPTkZJR19UQ01f RkM9bQpDT05GSUdfSVNDU0lfVEFSR0VUPW0KQ09ORklHX1NCUF9UQVJHRVQ9bQpDT05GSUdfRlVT SU9OPXkKQ09ORklHX0ZVU0lPTl9TUEk9bQpDT05GSUdfRlVTSU9OX0ZDPW0KQ09ORklHX0ZVU0lP Tl9TQVM9bQpDT05GSUdfRlVTSU9OX01BWF9TR0U9NDAKQ09ORklHX0ZVU0lPTl9DVEw9bQpDT05G SUdfRlVTSU9OX0xBTj1tCkNPTkZJR19GVVNJT05fTE9HR0lORz15CgojCiMgSUVFRSAxMzk0IChG aXJlV2lyZSkgc3VwcG9ydAojCkNPTkZJR19GSVJFV0lSRT1tCkNPTkZJR19GSVJFV0lSRV9PSENJ PW0KQ09ORklHX0ZJUkVXSVJFX1NCUDI9bQpDT05GSUdfRklSRVdJUkVfTkVUPW0KQ09ORklHX0ZJ UkVXSVJFX05PU1k9bQojIENPTkZJR19JMk8gaXMgbm90IHNldApDT05GSUdfTUFDSU5UT1NIX0RS SVZFUlM9eQpDT05GSUdfTUFDX0VNVU1PVVNFQlROPXkKQ09ORklHX05FVERFVklDRVM9eQpDT05G SUdfTkVUX0NPUkU9eQpDT05GSUdfQk9ORElORz1tCkNPTkZJR19EVU1NWT1tCkNPTkZJR19FUVVB TElaRVI9bQpDT05GSUdfTkVUX0ZDPXkKQ09ORklHX01JST1tCkNPTkZJR19JRUVFODAyMTU0X0RS SVZFUlM9bQpDT05GSUdfSUVFRTgwMjE1NF9GQUtFSEFSRD1tCkNPTkZJR19JRUVFODAyMTU0X0ZB S0VMQj1tCkNPTkZJR19JRkI9bQpDT05GSUdfTkVUX1RFQU09bQpDT05GSUdfTkVUX1RFQU1fTU9E RV9CUk9BRENBU1Q9bQpDT05GSUdfTkVUX1RFQU1fTU9ERV9ST1VORFJPQklOPW0KQ09ORklHX05F VF9URUFNX01PREVfQUNUSVZFQkFDS1VQPW0KQ09ORklHX05FVF9URUFNX01PREVfTE9BREJBTEFO Q0U9bQpDT05GSUdfTUFDVkxBTj1tCkNPTkZJR19NQUNWVEFQPW0KQ09ORklHX05FVENPTlNPTEU9 bQpDT05GSUdfTkVUQ09OU09MRV9EWU5BTUlDPXkKQ09ORklHX05FVFBPTEw9eQpDT05GSUdfTkVU UE9MTF9UUkFQPXkKQ09ORklHX05FVF9QT0xMX0NPTlRST0xMRVI9eQpDT05GSUdfVFVOPW0KQ09O RklHX1ZFVEg9bQpDT05GSUdfVklSVElPX05FVD1tCkNPTkZJR19TVU5HRU1fUEhZPW0KIyBDT05G SUdfQVJDTkVUIGlzIG5vdCBzZXQKQ09ORklHX0FUTV9EUklWRVJTPXkKIyBDT05GSUdfQVRNX0RV TU1ZIGlzIG5vdCBzZXQKQ09ORklHX0FUTV9UQ1A9bQojIENPTkZJR19BVE1fTEFOQUkgaXMgbm90 IHNldApDT05GSUdfQVRNX0VOST1tCiMgQ09ORklHX0FUTV9FTklfREVCVUcgaXMgbm90IHNldAoj IENPTkZJR19BVE1fRU5JX1RVTkVfQlVSU1QgaXMgbm90IHNldApDT05GSUdfQVRNX0ZJUkVTVFJF QU09bQojIENPTkZJR19BVE1fWkFUTSBpcyBub3Qgc2V0CkNPTkZJR19BVE1fTklDU1RBUj1tCiMg Q09ORklHX0FUTV9OSUNTVEFSX1VTRV9TVU5JIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNX05JQ1NU QVJfVVNFX0lEVDc3MTA1IGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNX0lEVDc3MjUyIGlzIG5vdCBz ZXQKIyBDT05GSUdfQVRNX0FNQkFTU0FET1IgaXMgbm90IHNldAojIENPTkZJR19BVE1fSE9SSVpP TiBpcyBub3Qgc2V0CiMgQ09ORklHX0FUTV9JQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FUTV9GT1JF MjAwRSBpcyBub3Qgc2V0CkNPTkZJR19BVE1fSEU9bQojIENPTkZJR19BVE1fSEVfVVNFX1NVTkkg aXMgbm90IHNldApDT05GSUdfQVRNX1NPTE9TPW0KCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJz CiMKCiMKIyBEaXN0cmlidXRlZCBTd2l0Y2ggQXJjaGl0ZWN0dXJlIGRyaXZlcnMKIwpDT05GSUdf TkVUX0RTQV9NVjg4RTZYWFg9bQpDT05GSUdfTkVUX0RTQV9NVjg4RTYwNjA9bQpDT05GSUdfTkVU X0RTQV9NVjg4RTZYWFhfTkVFRF9QUFU9eQpDT05GSUdfTkVUX0RTQV9NVjg4RTYxMzE9bQpDT05G SUdfTkVUX0RTQV9NVjg4RTYxMjNfNjFfNjU9bQpDT05GSUdfRVRIRVJORVQ9eQpDT05GSUdfTURJ Tz1tCkNPTkZJR19ORVRfVkVORE9SXzNDT009eQpDT05GSUdfUENNQ0lBXzNDNTc0PW0KQ09ORklH X1BDTUNJQV8zQzU4OT1tCkNPTkZJR19WT1JURVg9bQpDT05GSUdfVFlQSE9PTj1tCkNPTkZJR19O RVRfVkVORE9SX0FEQVBURUM9eQpDT05GSUdfQURBUFRFQ19TVEFSRklSRT1tCkNPTkZJR19ORVRf VkVORE9SX0FMVEVPTj15CkNPTkZJR19BQ0VOSUM9bQojIENPTkZJR19BQ0VOSUNfT01JVF9USUdP Tl9JIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQU1EPXkKQ09ORklHX0FNRDgxMTFfRVRI PW0KQ09ORklHX1BDTkVUMzI9bQpDT05GSUdfUENNQ0lBX05NQ0xBTj1tCkNPTkZJR19ORVRfVkVO RE9SX0FUSEVST1M9eQpDT05GSUdfQVRMMj1tCkNPTkZJR19BVEwxPW0KQ09ORklHX0FUTDFFPW0K Q09ORklHX0FUTDFDPW0KQ09ORklHX05FVF9WRU5ET1JfQlJPQURDT009eQpDT05GSUdfQjQ0PW0K Q09ORklHX0I0NF9QQ0lfQVVUT1NFTEVDVD15CkNPTkZJR19CNDRfUENJQ09SRV9BVVRPU0VMRUNU PXkKQ09ORklHX0I0NF9QQ0k9eQpDT05GSUdfQk5YMj1tCkNPTkZJR19DTklDPW0KQ09ORklHX1RJ R09OMz1tCkNPTkZJR19CTlgyWD1tCkNPTkZJR19ORVRfVkVORE9SX0JST0NBREU9eQpDT05GSUdf Qk5BPW0KQ09ORklHX05FVF9DQUxYRURBX1hHTUFDPW0KQ09ORklHX05FVF9WRU5ET1JfQ0hFTFNJ Tz15CkNPTkZJR19DSEVMU0lPX1QxPW0KQ09ORklHX0NIRUxTSU9fVDFfMUc9eQpDT05GSUdfQ0hF TFNJT19UMz1tCkNPTkZJR19DSEVMU0lPX1Q0PW0KQ09ORklHX0NIRUxTSU9fVDRWRj1tCkNPTkZJ R19ORVRfVkVORE9SX0NJU0NPPXkKQ09ORklHX0VOSUM9bQpDT05GSUdfRE5FVD1tCkNPTkZJR19O RVRfVkVORE9SX0RFQz15CkNPTkZJR19ORVRfVFVMSVA9eQpDT05GSUdfREUyMTA0WD1tCkNPTkZJ R19ERTIxMDRYX0RTTD0wCkNPTkZJR19UVUxJUD1tCiMgQ09ORklHX1RVTElQX01XSSBpcyBub3Qg c2V0CkNPTkZJR19UVUxJUF9NTUlPPXkKIyBDT05GSUdfVFVMSVBfTkFQSSBpcyBub3Qgc2V0CkNP TkZJR19ERTRYNT1tCkNPTkZJR19XSU5CT05EXzg0MD1tCkNPTkZJR19ETTkxMDI9bQpDT05GSUdf VUxJNTI2WD1tCkNPTkZJR19QQ01DSUFfWElSQ09NPW0KQ09ORklHX05FVF9WRU5ET1JfRExJTks9 eQpDT05GSUdfREU2MDA9bQpDT05GSUdfREU2MjA9bQpDT05GSUdfREwySz1tCkNPTkZJR19TVU5E QU5DRT1tCiMgQ09ORklHX1NVTkRBTkNFX01NSU8gaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRP Ul9FTVVMRVg9eQpDT05GSUdfQkUyTkVUPW0KQ09ORklHX05FVF9WRU5ET1JfRVhBUj15CkNPTkZJ R19TMklPPW0KQ09ORklHX1ZYR0U9bQojIENPTkZJR19WWEdFX0RFQlVHX1RSQUNFX0FMTCBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfRlVKSVRTVSBpcyBub3Qgc2V0CiMgQ09ORklHX05F VF9WRU5ET1JfSFAgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9JTlRFTD15CkNPTkZJR19F MTAwPW0KQ09ORklHX0UxMDAwPW0KQ09ORklHX0UxMDAwRT1tCkNPTkZJR19JR0I9bQpDT05GSUdf SUdCX0RDQT15CkNPTkZJR19JR0JfUFRQPXkKQ09ORklHX0lHQlZGPW0KQ09ORklHX0lYR0I9bQpD T05GSUdfSVhHQkU9bQpDT05GSUdfSVhHQkVfSFdNT049eQpDT05GSUdfSVhHQkVfRENBPXkKQ09O RklHX0lYR0JFX0RDQj15CkNPTkZJR19JWEdCRV9QVFA9eQpDT05GSUdfSVhHQkVWRj1tCiMgQ09O RklHX05FVF9WRU5ET1JfSTgyNVhYIGlzIG5vdCBzZXQKQ09ORklHX0lQMTAwMD1tCkNPTkZJR19K TUU9bQpDT05GSUdfTkVUX1ZFTkRPUl9NQVJWRUxMPXkKQ09ORklHX1NLR0U9bQojIENPTkZJR19T S0dFX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1NLR0VfR0VORVNJUz15CkNPTkZJR19TS1kyPW0K IyBDT05GSUdfU0tZMl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX01FTExBTk9Y PXkKQ09ORklHX01MWDRfRU49bQpDT05GSUdfTUxYNF9FTl9EQ0I9eQpDT05GSUdfTUxYNF9DT1JF PW0KQ09ORklHX01MWDRfREVCVUc9eQpDT05GSUdfTkVUX1ZFTkRPUl9NSUNSRUw9eQojIENPTkZJ R19LUzg4NDIgaXMgbm90IHNldAojIENPTkZJR19LUzg4NTFfTUxMIGlzIG5vdCBzZXQKQ09ORklH X0tTWjg4NFhfUENJPW0KQ09ORklHX05FVF9WRU5ET1JfTVlSST15CkNPTkZJR19NWVJJMTBHRT1t CkNPTkZJR19NWVJJMTBHRV9EQ0E9eQpDT05GSUdfRkVBTE5YPW0KQ09ORklHX05FVF9WRU5ET1Jf TkFUU0VNST15CkNPTkZJR19OQVRTRU1JPW0KQ09ORklHX05TODM4MjA9bQpDT05GSUdfTkVUX1ZF TkRPUl84MzkwPXkKQ09ORklHX1BDTUNJQV9BWE5FVD1tCkNPTkZJR19ORTJLX1BDST1tCkNPTkZJ R19QQ01DSUFfUENORVQ9bQpDT05GSUdfTkVUX1ZFTkRPUl9OVklESUE9eQpDT05GSUdfRk9SQ0VE RVRIPW0KQ09ORklHX05FVF9WRU5ET1JfT0tJPXkKQ09ORklHX1BDSF9HQkU9bQojIENPTkZJR19Q Q0hfUFRQIGlzIG5vdCBzZXQKQ09ORklHX0VUSE9DPW0KQ09ORklHX05FVF9QQUNLRVRfRU5HSU5F PXkKQ09ORklHX0hBTUFDSEk9bQpDT05GSUdfWUVMTE9XRklOPW0KQ09ORklHX05FVF9WRU5ET1Jf UUxPR0lDPXkKQ09ORklHX1FMQTNYWFg9bQpDT05GSUdfUUxDTklDPW0KQ09ORklHX1FMR0U9bQpD T05GSUdfTkVUWEVOX05JQz15CkNPTkZJR19ORVRfVkVORE9SX1JFQUxURUs9eQpDT05GSUdfQVRQ PW0KQ09ORklHXzgxMzlDUD1tCkNPTkZJR184MTM5VE9PPW0KIyBDT05GSUdfODEzOVRPT19QSU8g aXMgbm90IHNldAojIENPTkZJR184MTM5VE9PX1RVTkVfVFdJU1RFUiBpcyBub3Qgc2V0CkNPTkZJ R184MTM5VE9PXzgxMjk9eQojIENPTkZJR184MTM5X09MRF9SWF9SRVNFVCBpcyBub3Qgc2V0CkNP TkZJR19SODE2OT1tCkNPTkZJR19ORVRfVkVORE9SX1JEQz15CkNPTkZJR19SNjA0MD1tCiMgQ09O RklHX05FVF9WRU5ET1JfU0VFUSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1NJTEFOPXkK Q09ORklHX1NDOTIwMzE9bQpDT05GSUdfTkVUX1ZFTkRPUl9TSVM9eQpDT05GSUdfU0lTOTAwPW0K Q09ORklHX1NJUzE5MD1tCkNPTkZJR19TRkM9bQojIENPTkZJR19TRkNfTVREIGlzIG5vdCBzZXQK Q09ORklHX1NGQ19NQ0RJX01PTj15CkNPTkZJR19TRkNfU1JJT1Y9eQpDT05GSUdfTkVUX1ZFTkRP Ul9TTVNDPXkKQ09ORklHX1BDTUNJQV9TTUM5MUM5Mj1tCkNPTkZJR19FUElDMTAwPW0KQ09ORklH X1NNU0M5NDIwPW0KQ09ORklHX05FVF9WRU5ET1JfU1RNSUNSTz15CkNPTkZJR19TVE1NQUNfRVRI PW0KIyBDT05GSUdfU1RNTUFDX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfU1RNTUFDX1BD SSBpcyBub3Qgc2V0CiMgQ09ORklHX1NUTU1BQ19ERUJVR19GUyBpcyBub3Qgc2V0CiMgQ09ORklH X1NUTU1BQ19EQSBpcyBub3Qgc2V0CkNPTkZJR19TVE1NQUNfUklORz15CiMgQ09ORklHX1NUTU1B Q19DSEFJTkVEIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfU1VOPXkKQ09ORklHX0hBUFBZ TUVBTD1tCkNPTkZJR19TVU5HRU09bQpDT05GSUdfQ0FTU0lOST1tCkNPTkZJR19OSVU9bQpDT05G SUdfTkVUX1ZFTkRPUl9URUhVVEk9eQpDT05GSUdfVEVIVVRJPW0KQ09ORklHX05FVF9WRU5ET1Jf VEk9eQpDT05GSUdfVExBTj1tCkNPTkZJR19ORVRfVkVORE9SX1ZJQT15CkNPTkZJR19WSUFfUkhJ TkU9bQpDT05GSUdfVklBX1JISU5FX01NSU89eQpDT05GSUdfVklBX1ZFTE9DSVRZPW0KQ09ORklH X05FVF9WRU5ET1JfV0laTkVUPXkKQ09ORklHX1dJWk5FVF9XNTEwMD1tCkNPTkZJR19XSVpORVRf VzUzMDA9bQojIENPTkZJR19XSVpORVRfQlVTX0RJUkVDVCBpcyBub3Qgc2V0CiMgQ09ORklHX1dJ Wk5FVF9CVVNfSU5ESVJFQ1QgaXMgbm90IHNldApDT05GSUdfV0laTkVUX0JVU19BTlk9eQpDT05G SUdfTkVUX1ZFTkRPUl9YSVJDT009eQpDT05GSUdfUENNQ0lBX1hJUkMyUFM9bQojIENPTkZJR19G RERJIGlzIG5vdCBzZXQKIyBDT05GSUdfSElQUEkgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0Ix MDAwIGlzIG5vdCBzZXQKQ09ORklHX1BIWUxJQj15CgojCiMgTUlJIFBIWSBkZXZpY2UgZHJpdmVy cwojCkNPTkZJR19BTURfUEhZPW0KQ09ORklHX01BUlZFTExfUEhZPW0KQ09ORklHX0RBVklDT01f UEhZPW0KQ09ORklHX1FTRU1JX1BIWT1tCkNPTkZJR19MWFRfUEhZPW0KQ09ORklHX0NJQ0FEQV9Q SFk9bQpDT05GSUdfVklURVNTRV9QSFk9bQpDT05GSUdfU01TQ19QSFk9bQpDT05GSUdfQlJPQURD T01fUEhZPW0KQ09ORklHX0JDTTg3WFhfUEhZPW0KQ09ORklHX0lDUExVU19QSFk9bQpDT05GSUdf UkVBTFRFS19QSFk9bQpDT05GSUdfTkFUSU9OQUxfUEhZPW0KQ09ORklHX1NURTEwWFA9bQpDT05G SUdfTFNJX0VUMTAxMUNfUEhZPW0KQ09ORklHX01JQ1JFTF9QSFk9bQpDT05GSUdfRklYRURfUEhZ PXkKQ09ORklHX01ESU9fQklUQkFORz1tCiMgQ09ORklHX1BMSVAgaXMgbm90IHNldApDT05GSUdf UFBQPW0KQ09ORklHX1BQUF9CU0RDT01QPW0KQ09ORklHX1BQUF9ERUZMQVRFPW0KQ09ORklHX1BQ UF9GSUxURVI9eQpDT05GSUdfUFBQX01QUEU9bQpDT05GSUdfUFBQX01VTFRJTElOSz15CkNPTkZJ R19QUFBPQVRNPW0KQ09ORklHX1BQUE9FPW0KQ09ORklHX1BQVFA9bQpDT05GSUdfUFBQT0wyVFA9 bQpDT05GSUdfUFBQX0FTWU5DPW0KQ09ORklHX1BQUF9TWU5DX1RUWT1tCkNPTkZJR19TTElQPW0K Q09ORklHX1NMSEM9bQpDT05GSUdfU0xJUF9DT01QUkVTU0VEPXkKQ09ORklHX1NMSVBfU01BUlQ9 eQojIENPTkZJR19TTElQX01PREVfU0xJUDYgaXMgbm90IHNldAoKIwojIFVTQiBOZXR3b3JrIEFk YXB0ZXJzCiMKQ09ORklHX1VTQl9DQVRDPW0KQ09ORklHX1VTQl9LQVdFVEg9bQpDT05GSUdfVVNC X1BFR0FTVVM9bQpDT05GSUdfVVNCX1JUTDgxNTA9bQpDT05GSUdfVVNCX1VTQk5FVD1tCkNPTkZJ R19VU0JfTkVUX0FYODgxN1g9bQpDT05GSUdfVVNCX05FVF9DRENFVEhFUj1tCkNPTkZJR19VU0Jf TkVUX0NEQ19FRU09bQpDT05GSUdfVVNCX05FVF9DRENfTkNNPW0KQ09ORklHX1VTQl9ORVRfRE05 NjAxPW0KQ09ORklHX1VTQl9ORVRfU01TQzc1WFg9bQpDT05GSUdfVVNCX05FVF9TTVNDOTVYWD1t CkNPTkZJR19VU0JfTkVUX0dMNjIwQT1tCkNPTkZJR19VU0JfTkVUX05FVDEwODA9bQpDT05GSUdf VVNCX05FVF9QTFVTQj1tCkNPTkZJR19VU0JfTkVUX01DUzc4MzA9bQpDT05GSUdfVVNCX05FVF9S TkRJU19IT1NUPW0KQ09ORklHX1VTQl9ORVRfQ0RDX1NVQlNFVD1tCkNPTkZJR19VU0JfQUxJX001 NjMyPXkKQ09ORklHX1VTQl9BTjI3MjA9eQpDT05GSUdfVVNCX0JFTEtJTj15CkNPTkZJR19VU0Jf QVJNTElOVVg9eQpDT05GSUdfVVNCX0VQU09OMjg4OD15CkNPTkZJR19VU0JfS0MyMTkwPXkKQ09O RklHX1VTQl9ORVRfWkFVUlVTPW0KQ09ORklHX1VTQl9ORVRfQ1g4MjMxMF9FVEg9bQpDT05GSUdf VVNCX05FVF9LQUxNSUE9bQpDT05GSUdfVVNCX05FVF9RTUlfV1dBTj1tCkNPTkZJR19VU0JfSFNP PW0KQ09ORklHX1VTQl9ORVRfSU5UNTFYMT1tCkNPTkZJR19VU0JfSVBIRVRIPW0KQ09ORklHX1VT Ql9TSUVSUkFfTkVUPW0KQ09ORklHX1VTQl9WTDYwMD1tCkNPTkZJR19XTEFOPXkKIyBDT05GSUdf UENNQ0lBX1JBWUNTIGlzIG5vdCBzZXQKIyBDT05GSUdfTElCRVJUQVNfVEhJTkZJUk0gaXMgbm90 IHNldAojIENPTkZJR19BSVJPIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNRUwgaXMgbm90IHNldApD T05GSUdfQVQ3NkM1MFhfVVNCPW0KIyBDT05GSUdfQUlST19DUyBpcyBub3Qgc2V0CiMgQ09ORklH X1BDTUNJQV9XTDM1MDEgaXMgbm90IHNldAojIENPTkZJR19QUklTTTU0IGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1pEMTIwMSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfTkVUX1JORElTX1dMQU49bQpD T05GSUdfUlRMODE4MD1tCkNPTkZJR19SVEw4MTg3PW0KQ09ORklHX1JUTDgxODdfTEVEUz15CiMg Q09ORklHX0FETTgyMTEgaXMgbm90IHNldApDT05GSUdfTUFDODAyMTFfSFdTSU09bQpDT05GSUdf TVdMOEs9bQpDT05GSUdfQVRIX0NPTU1PTj1tCiMgQ09ORklHX0FUSF9ERUJVRyBpcyBub3Qgc2V0 CkNPTkZJR19BVEg1Sz1tCkNPTkZJR19BVEg1S19ERUJVRz15CiMgQ09ORklHX0FUSDVLX1RSQUNF UiBpcyBub3Qgc2V0CkNPTkZJR19BVEg1S19QQ0k9eQpDT05GSUdfQVRIOUtfSFc9bQpDT05GSUdf QVRIOUtfQ09NTU9OPW0KQ09ORklHX0FUSDlLX0JUQ09FWF9TVVBQT1JUPXkKQ09ORklHX0FUSDlL PW0KQ09ORklHX0FUSDlLX1BDST15CkNPTkZJR19BVEg5S19BSEI9eQpDT05GSUdfQVRIOUtfREVC VUdGUz15CiMgQ09ORklHX0FUSDlLX01BQ19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BVEg5S19S QVRFX0NPTlRST0w9eQpDT05GSUdfQVRIOUtfSFRDPW0KIyBDT05GSUdfQVRIOUtfSFRDX0RFQlVH RlMgaXMgbm90IHNldApDT05GSUdfQ0FSTDkxNzA9bQpDT05GSUdfQ0FSTDkxNzBfTEVEUz15CiMg Q09ORklHX0NBUkw5MTcwX0RFQlVHRlMgaXMgbm90IHNldApDT05GSUdfQ0FSTDkxNzBfV1BDPXkK IyBDT05GSUdfQ0FSTDkxNzBfSFdSTkcgaXMgbm90IHNldApDT05GSUdfQVRINktMPW0KQ09ORklH X0FUSDZLTF9TRElPPW0KQ09ORklHX0FUSDZLTF9VU0I9bQpDT05GSUdfQVRINktMX0RFQlVHPXkK Q09ORklHX0I0Mz1tCkNPTkZJR19CNDNfQkNNQT15CiMgQ09ORklHX0I0M19CQ01BX0VYVFJBIGlz IG5vdCBzZXQKQ09ORklHX0I0M19TU0I9eQpDT05GSUdfQjQzX1BDSV9BVVRPU0VMRUNUPXkKQ09O RklHX0I0M19QQ0lDT1JFX0FVVE9TRUxFQ1Q9eQpDT05GSUdfQjQzX1BDTUNJQT15CkNPTkZJR19C NDNfU0RJTz15CkNPTkZJR19CNDNfQkNNQV9QSU89eQpDT05GSUdfQjQzX1BJTz15CkNPTkZJR19C NDNfUEhZX049eQpDT05GSUdfQjQzX1BIWV9MUD15CkNPTkZJR19CNDNfUEhZX0hUPXkKQ09ORklH X0I0M19MRURTPXkKQ09ORklHX0I0M19IV1JORz15CiMgQ09ORklHX0I0M19ERUJVRyBpcyBub3Qg c2V0CkNPTkZJR19CNDNMRUdBQ1k9bQpDT05GSUdfQjQzTEVHQUNZX1BDSV9BVVRPU0VMRUNUPXkK Q09ORklHX0I0M0xFR0FDWV9QQ0lDT1JFX0FVVE9TRUxFQ1Q9eQpDT05GSUdfQjQzTEVHQUNZX0xF RFM9eQpDT05GSUdfQjQzTEVHQUNZX0hXUk5HPXkKIyBDT05GSUdfQjQzTEVHQUNZX0RFQlVHIGlz IG5vdCBzZXQKQ09ORklHX0I0M0xFR0FDWV9ETUE9eQpDT05GSUdfQjQzTEVHQUNZX1BJTz15CkNP TkZJR19CNDNMRUdBQ1lfRE1BX0FORF9QSU9fTU9ERT15CiMgQ09ORklHX0I0M0xFR0FDWV9ETUFf TU9ERSBpcyBub3Qgc2V0CiMgQ09ORklHX0I0M0xFR0FDWV9QSU9fTU9ERSBpcyBub3Qgc2V0CkNP TkZJR19CUkNNVVRJTD1tCkNPTkZJR19CUkNNU01BQz1tCkNPTkZJR19CUkNNRk1BQz1tCkNPTkZJ R19CUkNNRk1BQ19TRElPPXkKQ09ORklHX0JSQ01GTUFDX1NESU9fT09CPXkKQ09ORklHX0JSQ01G TUFDX1VTQj15CiMgQ09ORklHX0JSQ01EQkcgaXMgbm90IHNldAojIENPTkZJR19IT1NUQVAgaXMg bm90IHNldApDT05GSUdfSVBXMjEwMD1tCkNPTkZJR19JUFcyMTAwX01PTklUT1I9eQojIENPTkZJ R19JUFcyMTAwX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0lQVzIyMDA9bQpDT05GSUdfSVBXMjIw MF9NT05JVE9SPXkKQ09ORklHX0lQVzIyMDBfUkFESU9UQVA9eQpDT05GSUdfSVBXMjIwMF9QUk9N SVNDVU9VUz15CkNPTkZJR19JUFcyMjAwX1FPUz15CiMgQ09ORklHX0lQVzIyMDBfREVCVUcgaXMg bm90IHNldApDT05GSUdfTElCSVBXPW0KIyBDT05GSUdfTElCSVBXX0RFQlVHIGlzIG5vdCBzZXQK Q09ORklHX0lXTFdJRkk9bQpDT05GSUdfSVdMRFZNPW0KCiMKIyBEZWJ1Z2dpbmcgT3B0aW9ucwoj CkNPTkZJR19JV0xXSUZJX0RFQlVHPXkKQ09ORklHX0lXTFdJRklfREVCVUdGUz15CiMgQ09ORklH X0lXTFdJRklfREVCVUdfRVhQRVJJTUVOVEFMX1VDT0RFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVdM V0lGSV9ERVZJQ0VfVFJBQ0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX0lXTFdJRklfUDJQIGlzIG5v dCBzZXQKIyBDT05GSUdfSVdMV0lGSV9FWFBFUklNRU5UQUxfTUZQIGlzIG5vdCBzZXQKQ09ORklH X0lXTEVHQUNZPW0KQ09ORklHX0lXTDQ5NjU9bQpDT05GSUdfSVdMMzk0NT1tCgojCiMgaXdsMzk0 NSAvIGl3bDQ5NjUgRGVidWdnaW5nIE9wdGlvbnMKIwpDT05GSUdfSVdMRUdBQ1lfREVCVUc9eQpD T05GSUdfSVdMRUdBQ1lfREVCVUdGUz15CkNPTkZJR19MSUJFUlRBUz1tCkNPTkZJR19MSUJFUlRB U19VU0I9bQpDT05GSUdfTElCRVJUQVNfQ1M9bQpDT05GSUdfTElCRVJUQVNfU0RJTz1tCiMgQ09O RklHX0xJQkVSVEFTX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0xJQkVSVEFTX01FU0g9eQpDT05G SUdfSEVSTUVTPW0KIyBDT05GSUdfSEVSTUVTX1BSSVNNIGlzIG5vdCBzZXQKQ09ORklHX0hFUk1F U19DQUNIRV9GV19PTl9JTklUPXkKQ09ORklHX1BMWF9IRVJNRVM9bQojIENPTkZJR19UTURfSEVS TUVTIGlzIG5vdCBzZXQKQ09ORklHX05PUlRFTF9IRVJNRVM9bQpDT05GSUdfUENNQ0lBX0hFUk1F Uz1tCiMgQ09ORklHX1BDTUNJQV9TUEVDVFJVTSBpcyBub3Qgc2V0CkNPTkZJR19PUklOT0NPX1VT Qj1tCkNPTkZJR19QNTRfQ09NTU9OPW0KQ09ORklHX1A1NF9VU0I9bQpDT05GSUdfUDU0X1BDST1t CkNPTkZJR19QNTRfTEVEUz15CkNPTkZJR19SVDJYMDA9bQpDT05GSUdfUlQyNDAwUENJPW0KQ09O RklHX1JUMjUwMFBDST1tCkNPTkZJR19SVDYxUENJPW0KQ09ORklHX1JUMjgwMFBDST1tCkNPTkZJ R19SVDI4MDBQQ0lfUlQzM1hYPXkKQ09ORklHX1JUMjgwMFBDSV9SVDM1WFg9eQpDT05GSUdfUlQy ODAwUENJX1JUNTNYWD15CkNPTkZJR19SVDI4MDBQQ0lfUlQzMjkwPXkKQ09ORklHX1JUMjUwMFVT Qj1tCkNPTkZJR19SVDczVVNCPW0KQ09ORklHX1JUMjgwMFVTQj1tCkNPTkZJR19SVDI4MDBVU0Jf UlQzM1hYPXkKQ09ORklHX1JUMjgwMFVTQl9SVDM1WFg9eQpDT05GSUdfUlQyODAwVVNCX1JUNTNY WD15CkNPTkZJR19SVDI4MDBVU0JfVU5LTk9XTj15CkNPTkZJR19SVDI4MDBfTElCPW0KQ09ORklH X1JUMlgwMF9MSUJfUENJPW0KQ09ORklHX1JUMlgwMF9MSUJfVVNCPW0KQ09ORklHX1JUMlgwMF9M SUI9bQpDT05GSUdfUlQyWDAwX0xJQl9GSVJNV0FSRT15CkNPTkZJR19SVDJYMDBfTElCX0NSWVBU Tz15CkNPTkZJR19SVDJYMDBfTElCX0xFRFM9eQpDT05GSUdfUlQyWDAwX0xJQl9ERUJVR0ZTPXkK IyBDT05GSUdfUlQyWDAwX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1JUTDgxOTJDRT1tCkNPTkZJ R19SVEw4MTkyU0U9bQpDT05GSUdfUlRMODE5MkRFPW0KQ09ORklHX1JUTDgxOTJDVT1tCkNPTkZJ R19SVExXSUZJPW0KIyBDT05GSUdfUlRMV0lGSV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19SVEw4 MTkyQ19DT01NT049bQojIENPTkZJR19XTF9USSBpcyBub3Qgc2V0CkNPTkZJR19aRDEyMTFSVz1t CiMgQ09ORklHX1pEMTIxMVJXX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX01XSUZJRVg9bQpDT05G SUdfTVdJRklFWF9TRElPPW0KQ09ORklHX01XSUZJRVhfUENJRT1tCkNPTkZJR19NV0lGSUVYX1VT Qj1tCgojCiMgV2lNQVggV2lyZWxlc3MgQnJvYWRiYW5kIGRldmljZXMKIwpDT05GSUdfV0lNQVhf STI0MDBNPW0KQ09ORklHX1dJTUFYX0kyNDAwTV9VU0I9bQpDT05GSUdfV0lNQVhfSTI0MDBNX0RF QlVHX0xFVkVMPTgKIyBDT05GSUdfV0FOIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9ORVRERVZfRlJP TlRFTkQ9eQpDT05GSUdfWEVOX05FVERFVl9CQUNLRU5EPXkKQ09ORklHX1ZNWE5FVDM9bQpDT05G SUdfSFlQRVJWX05FVD1tCkNPTkZJR19JU0ROPXkKQ09ORklHX0lTRE5fSTRMPW0KQ09ORklHX0lT RE5fUFBQPXkKQ09ORklHX0lTRE5fUFBQX1ZKPXkKQ09ORklHX0lTRE5fTVBQPXkKQ09ORklHX0lQ UFBfRklMVEVSPXkKIyBDT05GSUdfSVNETl9QUFBfQlNEQ09NUCBpcyBub3Qgc2V0CkNPTkZJR19J U0ROX0FVRElPPXkKQ09ORklHX0lTRE5fVFRZX0ZBWD15CgojCiMgSVNETiBmZWF0dXJlIHN1Ym1v ZHVsZXMKIwpDT05GSUdfSVNETl9ESVZFUlNJT049bQoKIwojIElTRE40TGludXggaGFyZHdhcmUg ZHJpdmVycwojCgojCiMgUGFzc2l2ZSBjYXJkcwojCkNPTkZJR19JU0ROX0RSVl9ISVNBWD1tCgoj CiMgRC1jaGFubmVsIHByb3RvY29sIGZlYXR1cmVzCiMKQ09ORklHX0hJU0FYX0VVUk89eQpDT05G SUdfREVfQU9DPXkKQ09ORklHX0hJU0FYX05PX1NFTkRDT01QTEVURT15CkNPTkZJR19ISVNBWF9O T19MTEM9eQpDT05GSUdfSElTQVhfTk9fS0VZUEFEPXkKQ09ORklHX0hJU0FYXzFUUjY9eQpDT05G SUdfSElTQVhfTkkxPXkKQ09ORklHX0hJU0FYX01BWF9DQVJEUz04CgojCiMgSGlTYXggc3VwcG9y dGVkIGNhcmRzCiMKQ09ORklHX0hJU0FYXzE2XzM9eQpDT05GSUdfSElTQVhfVEVMRVNQQ0k9eQpD T05GSUdfSElTQVhfUzBCT1g9eQpDT05GSUdfSElTQVhfRlJJVFpQQ0k9eQpDT05GSUdfSElTQVhf QVZNX0ExX1BDTUNJQT15CkNPTkZJR19ISVNBWF9FTFNBPXkKQ09ORklHX0hJU0FYX0RJRUhMRElW QT15CkNPTkZJR19ISVNBWF9TRURMQkFVRVI9eQpDT05GSUdfSElTQVhfTkVUSkVUPXkKQ09ORklH X0hJU0FYX05FVEpFVF9VPXkKQ09ORklHX0hJU0FYX05JQ0NZPXkKQ09ORklHX0hJU0FYX0JLTV9B NFQ9eQpDT05GSUdfSElTQVhfU0NUX1FVQURSTz15CkNPTkZJR19ISVNBWF9HQVpFTD15CkNPTkZJ R19ISVNBWF9IRkNfUENJPXkKQ09ORklHX0hJU0FYX1c2NjkyPXkKQ09ORklHX0hJU0FYX0hGQ19T WD15CkNPTkZJR19ISVNBWF9FTlRFUk5PV19QQ0k9eQojIENPTkZJR19ISVNBWF9ERUJVRyBpcyBu b3Qgc2V0CgojCiMgSGlTYXggUENNQ0lBIGNhcmQgc2VydmljZSBtb2R1bGVzCiMKQ09ORklHX0hJ U0FYX1NFRExCQVVFUl9DUz1tCkNPTkZJR19ISVNBWF9FTFNBX0NTPW0KQ09ORklHX0hJU0FYX0FW TV9BMV9DUz1tCkNPTkZJR19ISVNBWF9URUxFU19DUz1tCgojCiMgSGlTYXggc3ViIGRyaXZlciBt b2R1bGVzCiMKQ09ORklHX0hJU0FYX1NUNTQ4MT1tCiMgQ09ORklHX0hJU0FYX0hGQ1VTQiBpcyBu b3Qgc2V0CkNPTkZJR19ISVNBWF9IRkM0UzhTPW0KQ09ORklHX0hJU0FYX0ZSSVRaX1BDSVBOUD1t CgojCiMgQWN0aXZlIGNhcmRzCiMKQ09ORklHX0lTRE5fQ0FQST1tCkNPTkZJR19JU0ROX0RSVl9B Vk1CMV9WRVJCT1NFX1JFQVNPTj15CiMgQ09ORklHX0NBUElfVFJBQ0UgaXMgbm90IHNldApDT05G SUdfSVNETl9DQVBJX01JRERMRVdBUkU9eQpDT05GSUdfSVNETl9DQVBJX0NBUEkyMD1tCkNPTkZJ R19JU0ROX0NBUElfQ0FQSURSVj1tCgojCiMgQ0FQSSBoYXJkd2FyZSBkcml2ZXJzCiMKQ09ORklH X0NBUElfQVZNPXkKQ09ORklHX0lTRE5fRFJWX0FWTUIxX0IxUENJPW0KQ09ORklHX0lTRE5fRFJW X0FWTUIxX0IxUENJVjQ9eQpDT05GSUdfSVNETl9EUlZfQVZNQjFfQjFQQ01DSUE9bQpDT05GSUdf SVNETl9EUlZfQVZNQjFfQVZNX0NTPW0KQ09ORklHX0lTRE5fRFJWX0FWTUIxX1QxUENJPW0KQ09O RklHX0lTRE5fRFJWX0FWTUIxX0M0PW0KQ09ORklHX0NBUElfRUlDT049eQpDT05GSUdfSVNETl9E SVZBUz1tCkNPTkZJR19JU0ROX0RJVkFTX0JSSVBDST15CkNPTkZJR19JU0ROX0RJVkFTX1BSSVBD ST15CkNPTkZJR19JU0ROX0RJVkFTX0RJVkFDQVBJPW0KQ09ORklHX0lTRE5fRElWQVNfVVNFUklE ST1tCkNPTkZJR19JU0ROX0RJVkFTX01BSU5UPW0KQ09ORklHX0lTRE5fRFJWX0dJR0FTRVQ9bQpD T05GSUdfR0lHQVNFVF9DQVBJPXkKIyBDT05GSUdfR0lHQVNFVF9JNEwgaXMgbm90IHNldAojIENP TkZJR19HSUdBU0VUX0RVTU1ZTEwgaXMgbm90IHNldApDT05GSUdfR0lHQVNFVF9CQVNFPW0KQ09O RklHX0dJR0FTRVRfTTEwNT1tCkNPTkZJR19HSUdBU0VUX00xMDE9bQojIENPTkZJR19HSUdBU0VU X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0hZU0ROPW0KQ09ORklHX0hZU0ROX0NBUEk9eQpDT05G SUdfTUlTRE49bQpDT05GSUdfTUlTRE5fRFNQPW0KQ09ORklHX01JU0ROX0wxT0lQPW0KCiMKIyBt SVNETiBoYXJkd2FyZSBkcml2ZXJzCiMKQ09ORklHX01JU0ROX0hGQ1BDST1tCkNPTkZJR19NSVNE Tl9IRkNNVUxUST1tCkNPTkZJR19NSVNETl9IRkNVU0I9bQpDT05GSUdfTUlTRE5fQVZNRlJJVFo9 bQpDT05GSUdfTUlTRE5fU1BFRURGQVg9bQpDT05GSUdfTUlTRE5fSU5GSU5FT049bQpDT05GSUdf TUlTRE5fVzY2OTI9bQpDT05GSUdfTUlTRE5fTkVUSkVUPW0KQ09ORklHX01JU0ROX0lQQUM9bQpD T05GSUdfTUlTRE5fSVNBUj1tCkNPTkZJR19JU0ROX0hETEM9bQoKIwojIElucHV0IGRldmljZSBz dXBwb3J0CiMKQ09ORklHX0lOUFVUPXkKQ09ORklHX0lOUFVUX0ZGX01FTUxFU1M9eQpDT05GSUdf SU5QVVRfUE9MTERFVj1tCkNPTkZJR19JTlBVVF9TUEFSU0VLTUFQPW0KIyBDT05GSUdfSU5QVVRf TUFUUklYS01BUCBpcyBub3Qgc2V0CgojCiMgVXNlcmxhbmQgaW50ZXJmYWNlcwojCkNPTkZJR19J TlBVVF9NT1VTRURFVj15CiMgQ09ORklHX0lOUFVUX01PVVNFREVWX1BTQVVYIGlzIG5vdCBzZXQK Q09ORklHX0lOUFVUX01PVVNFREVWX1NDUkVFTl9YPTEwMjQKQ09ORklHX0lOUFVUX01PVVNFREVW X1NDUkVFTl9ZPTc2OApDT05GSUdfSU5QVVRfSk9ZREVWPW0KQ09ORklHX0lOUFVUX0VWREVWPXkK IyBDT05GSUdfSU5QVVRfRVZCVUcgaXMgbm90IHNldAoKIwojIElucHV0IERldmljZSBEcml2ZXJz CiMKQ09ORklHX0lOUFVUX0tFWUJPQVJEPXkKIyBDT05GSUdfS0VZQk9BUkRfQURQNTU4OCBpcyBu b3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1ODkgaXMgbm90IHNldApDT05GSUdfS0VZQk9B UkRfQVRLQkQ9eQojIENPTkZJR19LRVlCT0FSRF9RVDEwNzAgaXMgbm90IHNldAojIENPTkZJR19L RVlCT0FSRF9RVDIxNjAgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9MS0tCRCBpcyBub3Qg c2V0CiMgQ09ORklHX0tFWUJPQVJEX1RDQTY0MTYgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FS RF9UQ0E4NDE4IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTE04MzIzIGlzIG5vdCBzZXQK IyBDT05GSUdfS0VZQk9BUkRfTE04MzMzIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTUFY NzM1OSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX01DUyBpcyBub3Qgc2V0CiMgQ09ORklH X0tFWUJPQVJEX01QUjEyMSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX05FV1RPTiBpcyBu b3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX09QRU5DT1JFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0tF WUJPQVJEX1NUT1dBV0FZIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfU1VOS0JEIGlzIG5v dCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfT01BUDQgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FS RF9YVEtCRCBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9NT1VTRT15CkNPTkZJR19NT1VTRV9QUzI9 eQpDT05GSUdfTU9VU0VfUFMyX0FMUFM9eQpDT05GSUdfTU9VU0VfUFMyX0xPR0lQUzJQUD15CkNP TkZJR19NT1VTRV9QUzJfU1lOQVBUSUNTPXkKQ09ORklHX01PVVNFX1BTMl9MSUZFQk9PSz15CkNP TkZJR19NT1VTRV9QUzJfVFJBQ0tQT0lOVD15CkNPTkZJR19NT1VTRV9QUzJfRUxBTlRFQ0g9eQpD T05GSUdfTU9VU0VfUFMyX1NFTlRFTElDPXkKIyBDT05GSUdfTU9VU0VfUFMyX1RPVUNIS0lUIGlz IG5vdCBzZXQKQ09ORklHX01PVVNFX1NFUklBTD1tCkNPTkZJR19NT1VTRV9BUFBMRVRPVUNIPW0K Q09ORklHX01PVVNFX0JDTTU5NzQ9bQpDT05GSUdfTU9VU0VfVlNYWFhBQT1tCkNPTkZJR19NT1VT RV9TWU5BUFRJQ1NfSTJDPW0KQ09ORklHX01PVVNFX1NZTkFQVElDU19VU0I9bQpDT05GSUdfSU5Q VVRfSk9ZU1RJQ0s9eQpDT05GSUdfSk9ZU1RJQ0tfQU5BTE9HPW0KQ09ORklHX0pPWVNUSUNLX0Ez RD1tCkNPTkZJR19KT1lTVElDS19BREk9bQpDT05GSUdfSk9ZU1RJQ0tfQ09CUkE9bQpDT05GSUdf Sk9ZU1RJQ0tfR0YySz1tCkNPTkZJR19KT1lTVElDS19HUklQPW0KQ09ORklHX0pPWVNUSUNLX0dS SVBfTVA9bQpDT05GSUdfSk9ZU1RJQ0tfR1VJTExFTU9UPW0KQ09ORklHX0pPWVNUSUNLX0lOVEVS QUNUPW0KQ09ORklHX0pPWVNUSUNLX1NJREVXSU5ERVI9bQpDT05GSUdfSk9ZU1RJQ0tfVE1EQz1t CkNPTkZJR19KT1lTVElDS19JRk9SQ0U9bQpDT05GSUdfSk9ZU1RJQ0tfSUZPUkNFX1VTQj15CkNP TkZJR19KT1lTVElDS19JRk9SQ0VfMjMyPXkKQ09ORklHX0pPWVNUSUNLX1dBUlJJT1I9bQpDT05G SUdfSk9ZU1RJQ0tfTUFHRUxMQU49bQpDT05GSUdfSk9ZU1RJQ0tfU1BBQ0VPUkI9bQpDT05GSUdf Sk9ZU1RJQ0tfU1BBQ0VCQUxMPW0KQ09ORklHX0pPWVNUSUNLX1NUSU5HRVI9bQpDT05GSUdfSk9Z U1RJQ0tfVFdJREpPWT1tCkNPTkZJR19KT1lTVElDS19aSEVOSFVBPW0KQ09ORklHX0pPWVNUSUNL X0RCOT1tCkNPTkZJR19KT1lTVElDS19HQU1FQ09OPW0KQ09ORklHX0pPWVNUSUNLX1RVUkJPR1JB Rlg9bQojIENPTkZJR19KT1lTVElDS19BUzUwMTEgaXMgbm90IHNldApDT05GSUdfSk9ZU1RJQ0tf Sk9ZRFVNUD1tCkNPTkZJR19KT1lTVElDS19YUEFEPW0KQ09ORklHX0pPWVNUSUNLX1hQQURfRkY9 eQpDT05GSUdfSk9ZU1RJQ0tfWFBBRF9MRURTPXkKQ09ORklHX0pPWVNUSUNLX1dBTEtFUkEwNzAx PW0KQ09ORklHX0lOUFVUX1RBQkxFVD15CkNPTkZJR19UQUJMRVRfVVNCX0FDRUNBRD1tCkNPTkZJ R19UQUJMRVRfVVNCX0FJUFRFSz1tCkNPTkZJR19UQUJMRVRfVVNCX0dUQ089bQpDT05GSUdfVEFC TEVUX1VTQl9IQU5XQU5HPW0KQ09ORklHX1RBQkxFVF9VU0JfS0JUQUI9bQpDT05GSUdfVEFCTEVU X1VTQl9XQUNPTT1tCkNPTkZJR19JTlBVVF9UT1VDSFNDUkVFTj15CiMgQ09ORklHX1RPVUNIU0NS RUVOX0FENzg3OSBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9BVE1FTF9NWFQ9bQojIENP TkZJR19UT1VDSFNDUkVFTl9CVTIxMDEzIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5f Q1lUVFNQX0NPUkUgaXMgbm90IHNldApDT05GSUdfVE9VQ0hTQ1JFRU5fRFlOQVBSTz1tCiMgQ09O RklHX1RPVUNIU0NSRUVOX0hBTVBTSElSRSBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9F RVRJPW0KQ09ORklHX1RPVUNIU0NSRUVOX0VHQUxBWD1tCkNPTkZJR19UT1VDSFNDUkVFTl9GVUpJ VFNVPW0KQ09ORklHX1RPVUNIU0NSRUVOX0lMSTIxMFg9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fR1VO WkU9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fRUxPPW0KQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4 MDAxPW0KQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX0kyQz1tCiMgQ09ORklHX1RPVUNIU0NSRUVO X01BWDExODAxIGlzIG5vdCBzZXQKQ09ORklHX1RPVUNIU0NSRUVOX01DUzUwMDA9bQpDT05GSUdf VE9VQ0hTQ1JFRU5fTU1TMTE0PW0KQ09ORklHX1RPVUNIU0NSRUVOX01UT1VDSD1tCkNPTkZJR19U T1VDSFNDUkVFTl9JTkVYSU89bQpDT05GSUdfVE9VQ0hTQ1JFRU5fTUs3MTI9bQpDT05GSUdfVE9V Q0hTQ1JFRU5fUEVOTU9VTlQ9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fRURUX0ZUNVgwNj1tCkNPTkZJ R19UT1VDSFNDUkVFTl9UT1VDSFJJR0hUPW0KQ09ORklHX1RPVUNIU0NSRUVOX1RPVUNIV0lOPW0K Q09ORklHX1RPVUNIU0NSRUVOX1BJWENJUj1tCiMgQ09ORklHX1RPVUNIU0NSRUVOX1dNOTdYWCBp cyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfQ09NUE9TSVRFPW0KQ09ORklHX1RPVUNI U0NSRUVOX1VTQl9FR0FMQVg9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX1BBTkpJVD15CkNPTkZJ R19UT1VDSFNDUkVFTl9VU0JfM009eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0lUTT15CkNPTkZJ R19UT1VDSFNDUkVFTl9VU0JfRVRVUkJPPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9HVU5aRT15 CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfRE1DX1RTQzEwPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VT Ql9JUlRPVUNIPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9JREVBTFRFSz15CkNPTkZJR19UT1VD SFNDUkVFTl9VU0JfR0VORVJBTF9UT1VDSD15CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfR09UT1A9 eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0pBU1RFQz15CkNPTkZJR19UT1VDSFNDUkVFTl9VU0Jf RUxPPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9FMkk9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNC X1pZVFJPTklDPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9FVFRfVEM0NVVTQj15CkNPTkZJR19U T1VDSFNDUkVFTl9VU0JfTkVYSU89eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0VBU1lUT1VDSD15 CkNPTkZJR19UT1VDSFNDUkVFTl9UT1VDSElUMjEzPW0KQ09ORklHX1RPVUNIU0NSRUVOX1RTQ19T RVJJTz1tCkNPTkZJR19UT1VDSFNDUkVFTl9UU0MyMDA3PW0KQ09ORklHX1RPVUNIU0NSRUVOX1NU MTIzMj1tCiMgQ09ORklHX1RPVUNIU0NSRUVOX1RQUzY1MDdYIGlzIG5vdCBzZXQKQ09ORklHX0lO UFVUX01JU0M9eQojIENPTkZJR19JTlBVVF9BRDcxNFggaXMgbm90IHNldAojIENPTkZJR19JTlBV VF9CTUExNTAgaXMgbm90IHNldApDT05GSUdfSU5QVVRfUENTUEtSPW0KQ09ORklHX0lOUFVUX01N QTg0NTA9bQpDT05GSUdfSU5QVVRfTVBVMzA1MD1tCkNPTkZJR19JTlBVVF9BUEFORUw9bQpDT05G SUdfSU5QVVRfQVRMQVNfQlROUz1tCkNPTkZJR19JTlBVVF9BVElfUkVNT1RFMj1tCkNPTkZJR19J TlBVVF9LRVlTUEFOX1JFTU9URT1tCkNPTkZJR19JTlBVVF9LWFRKOT1tCiMgQ09ORklHX0lOUFVU X0tYVEo5X1BPTExFRF9NT0RFIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1BPV0VSTUFURT1tCkNP TkZJR19JTlBVVF9ZRUFMSU5LPW0KQ09ORklHX0lOUFVUX0NNMTA5PW0KQ09ORklHX0lOUFVUX1VJ TlBVVD1tCiMgQ09ORklHX0lOUFVUX1BDRjg1NzQgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9B RFhMMzRYIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX0NNQTMwMDA9bQpDT05GSUdfSU5QVVRfQ01B MzAwMF9JMkM9bQpDT05GSUdfSU5QVVRfWEVOX0tCRERFVl9GUk9OVEVORD15CgojCiMgSGFyZHdh cmUgSS9PIHBvcnRzCiMKQ09ORklHX1NFUklPPXkKQ09ORklHX1NFUklPX0k4MDQyPXkKQ09ORklH X1NFUklPX1NFUlBPUlQ9eQojIENPTkZJR19TRVJJT19DVDgyQzcxMCBpcyBub3Qgc2V0CiMgQ09O RklHX1NFUklPX1BBUktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BDSVBTMiBpcyBub3Qg c2V0CkNPTkZJR19TRVJJT19MSUJQUzI9eQpDT05GSUdfU0VSSU9fUkFXPW0KQ09ORklHX1NFUklP X0FMVEVSQV9QUzI9bQojIENPTkZJR19TRVJJT19QUzJNVUxUIGlzIG5vdCBzZXQKQ09ORklHX0dB TUVQT1JUPW0KQ09ORklHX0dBTUVQT1JUX05TNTU4PW0KQ09ORklHX0dBTUVQT1JUX0w0PW0KQ09O RklHX0dBTUVQT1JUX0VNVTEwSzE9bQpDT05GSUdfR0FNRVBPUlRfRk04MDE9bQoKIwojIENoYXJh Y3RlciBkZXZpY2VzCiMKQ09ORklHX0NSQVNIPW0KQ09ORklHX1ZUPXkKQ09ORklHX0NPTlNPTEVf VFJBTlNMQVRJT05TPXkKQ09ORklHX1ZUX0NPTlNPTEU9eQpDT05GSUdfVlRfQ09OU09MRV9TTEVF UD15CkNPTkZJR19IV19DT05TT0xFPXkKQ09ORklHX1ZUX0hXX0NPTlNPTEVfQklORElORz15CkNP TkZJR19VTklYOThfUFRZUz15CkNPTkZJR19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTPXkKIyBD T05GSUdfTEVHQUNZX1BUWVMgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEPXkK Q09ORklHX1JPQ0tFVFBPUlQ9bQpDT05GSUdfQ1lDTEFERVM9bQojIENPTkZJR19DWVpfSU5UUiBp cyBub3Qgc2V0CiMgQ09ORklHX01PWEFfSU5URUxMSU8gaXMgbm90IHNldAojIENPTkZJR19NT1hB X1NNQVJUSU8gaXMgbm90IHNldApDT05GSUdfU1lOQ0xJTks9bQpDT05GSUdfU1lOQ0xJTktNUD1t CkNPTkZJR19TWU5DTElOS19HVD1tCkNPTkZJR19OT1pPTUk9bQojIENPTkZJR19JU0kgaXMgbm90 IHNldApDT05GSUdfTl9IRExDPW0KQ09ORklHX05fR1NNPW0KIyBDT05GSUdfVFJBQ0VfU0lOSyBp cyBub3Qgc2V0CiMgQ09ORklHX0RFVktNRU0gaXMgbm90IHNldAojIENPTkZJR19TVEFMRFJWIGlz IG5vdCBzZXQKCiMKIyBTZXJpYWwgZHJpdmVycwojCkNPTkZJR19TRVJJQUxfODI1MD15CkNPTkZJ R19TRVJJQUxfODI1MF9DT05TT0xFPXkKQ09ORklHX0ZJWF9FQVJMWUNPTl9NRU09eQpDT05GSUdf U0VSSUFMXzgyNTBfUENJPXkKQ09ORklHX1NFUklBTF84MjUwX1BOUD15CkNPTkZJR19TRVJJQUxf ODI1MF9DUz1tCkNPTkZJR19TRVJJQUxfODI1MF9OUl9VQVJUUz0zMgpDT05GSUdfU0VSSUFMXzgy NTBfUlVOVElNRV9VQVJUUz00CkNPTkZJR19TRVJJQUxfODI1MF9FWFRFTkRFRD15CkNPTkZJR19T RVJJQUxfODI1MF9NQU5ZX1BPUlRTPXkKQ09ORklHX1NFUklBTF84MjUwX1NIQVJFX0lSUT15CiMg Q09ORklHX1NFUklBTF84MjUwX0RFVEVDVF9JUlEgaXMgbm90IHNldApDT05GSUdfU0VSSUFMXzgy NTBfUlNBPXkKCiMKIyBOb24tODI1MCBzZXJpYWwgcG9ydCBzdXBwb3J0CiMKIyBDT05GSUdfU0VS SUFMX01GRF9IU1UgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX0NPUkU9eQpDT05GSUdfU0VSSUFM X0NPUkVfQ09OU09MRT15CkNPTkZJR19DT05TT0xFX1BPTEw9eQpDT05GSUdfU0VSSUFMX0pTTT1t CiMgQ09ORklHX1NFUklBTF9USU1CRVJEQUxFIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0FM VEVSQV9KVEFHVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFfVUFSVCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NFUklBTF9QQ0hfVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklB TF9YSUxJTlhfUFNfVUFSVCBpcyBub3Qgc2V0CkNPTkZJR19QUklOVEVSPW0KQ09ORklHX0xQX0NP TlNPTEU9eQpDT05GSUdfUFBERVY9bQpDT05GSUdfSFZDX0RSSVZFUj15CkNPTkZJR19IVkNfSVJR PXkKQ09ORklHX0hWQ19YRU49eQpDT05GSUdfSFZDX1hFTl9GUk9OVEVORD15CkNPTkZJR19WSVJU SU9fQ09OU09MRT15CkNPTkZJR19JUE1JX0hBTkRMRVI9bQojIENPTkZJR19JUE1JX1BBTklDX0VW RU5UIGlzIG5vdCBzZXQKQ09ORklHX0lQTUlfREVWSUNFX0lOVEVSRkFDRT1tCkNPTkZJR19JUE1J X1NJPW0KQ09ORklHX0lQTUlfV0FUQ0hET0c9bQpDT05GSUdfSVBNSV9QT1dFUk9GRj1tCkNPTkZJ R19IV19SQU5ET009eQpDT05GSUdfSFdfUkFORE9NX1RJTUVSSU9NRU09bQpDT05GSUdfSFdfUkFO RE9NX0lOVEVMPW0KQ09ORklHX0hXX1JBTkRPTV9BTUQ9bQpDT05GSUdfSFdfUkFORE9NX1ZJQT1t CkNPTkZJR19IV19SQU5ET01fVklSVElPPW0KQ09ORklHX05WUkFNPXkKQ09ORklHX1IzOTY0PW0K IyBDT05GSUdfQVBQTElDT00gaXMgbm90IHNldAoKIwojIFBDTUNJQSBjaGFyYWN0ZXIgZGV2aWNl cwojCiMgQ09ORklHX1NZTkNMSU5LX0NTIGlzIG5vdCBzZXQKQ09ORklHX0NBUkRNQU5fNDAwMD1t CkNPTkZJR19DQVJETUFOXzQwNDA9bQpDT05GSUdfSVBXSVJFTEVTUz1tCkNPTkZJR19NV0FWRT1t CkNPTkZJR19SQVdfRFJJVkVSPXkKQ09ORklHX01BWF9SQVdfREVWUz04MTkyCkNPTkZJR19IUEVU PXkKIyBDT05GSUdfSFBFVF9NTUFQIGlzIG5vdCBzZXQKQ09ORklHX0hBTkdDSEVDS19USU1FUj1t CkNPTkZJR19UQ0dfVFBNPW0KQ09ORklHX1RDR19USVM9bQpDT05GSUdfVENHX05TQz1tCkNPTkZJ R19UQ0dfQVRNRUw9bQpDT05GSUdfVENHX0lORklORU9OPW0KQ09ORklHX1RFTENMT0NLPW0KQ09O RklHX0RFVlBPUlQ9eQpDT05GSUdfSTJDPW0KQ09ORklHX0kyQ19CT0FSRElORk89eQpDT05GSUdf STJDX0NPTVBBVD15CkNPTkZJR19JMkNfQ0hBUkRFVj1tCiMgQ09ORklHX0kyQ19NVVggaXMgbm90 IHNldApDT05GSUdfSTJDX0hFTFBFUl9BVVRPPXkKQ09ORklHX0kyQ19TTUJVUz1tCkNPTkZJR19J MkNfQUxHT0JJVD1tCkNPTkZJR19JMkNfQUxHT1BDQT1tCgojCiMgSTJDIEhhcmR3YXJlIEJ1cyBz dXBwb3J0CiMKCiMKIyBQQyBTTUJ1cyBob3N0IGNvbnRyb2xsZXIgZHJpdmVycwojCiMgQ09ORklH X0kyQ19BTEkxNTM1IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FMSTE1NjMgaXMgbm90IHNldAoj IENPTkZJR19JMkNfQUxJMTVYMyBpcyBub3Qgc2V0CkNPTkZJR19JMkNfQU1ENzU2PW0KQ09ORklH X0kyQ19BTUQ3NTZfUzQ4ODI9bQpDT05GSUdfSTJDX0FNRDgxMTE9bQpDT05GSUdfSTJDX0k4MDE9 bQpDT05GSUdfSTJDX0lTQ0g9bQpDT05GSUdfSTJDX1BJSVg0PW0KQ09ORklHX0kyQ19ORk9SQ0Uy PW0KQ09ORklHX0kyQ19ORk9SQ0UyX1M0OTg1PW0KIyBDT05GSUdfSTJDX1NJUzU1OTUgaXMgbm90 IHNldAojIENPTkZJR19JMkNfU0lTNjMwIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19TSVM5Nlg9bQpD T05GSUdfSTJDX1ZJQT1tCkNPTkZJR19JMkNfVklBUFJPPW0KCiMKIyBBQ1BJIGRyaXZlcnMKIwpD T05GSUdfSTJDX1NDTUk9bQoKIwojIEkyQyBzeXN0ZW0gYnVzIGRyaXZlcnMgKG1vc3RseSBlbWJl ZGRlZCAvIHN5c3RlbS1vbi1jaGlwKQojCiMgQ09ORklHX0kyQ19ERVNJR05XQVJFX1BDSSBpcyBu b3Qgc2V0CiMgQ09ORklHX0kyQ19FRzIwVCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19JTlRFTF9N SUQgaXMgbm90IHNldAojIENPTkZJR19JMkNfT0NPUkVTIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19Q Q0FfUExBVEZPUk09bQojIENPTkZJR19JMkNfUFhBX1BDSSBpcyBub3Qgc2V0CkNPTkZJR19JMkNf U0lNVEVDPW0KIyBDT05GSUdfSTJDX1hJTElOWCBpcyBub3Qgc2V0CgojCiMgRXh0ZXJuYWwgSTJD L1NNQnVzIGFkYXB0ZXIgZHJpdmVycwojCkNPTkZJR19JMkNfRElPTEFOX1UyQz1tCkNPTkZJR19J MkNfUEFSUE9SVD1tCkNPTkZJR19JMkNfUEFSUE9SVF9MSUdIVD1tCiMgQ09ORklHX0kyQ19UQU9T X0VWTSBpcyBub3Qgc2V0CkNPTkZJR19JMkNfVElOWV9VU0I9bQoKIwojIE90aGVyIEkyQy9TTUJ1 cyBidXMgZHJpdmVycwojCkNPTkZJR19JMkNfU1RVQj1tCiMgQ09ORklHX0kyQ19ERUJVR19DT1JF IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0RFQlVHX0FMR08gaXMgbm90IHNldAojIENPTkZJR19J MkNfREVCVUdfQlVTIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdf SFNJIGlzIG5vdCBzZXQKCiMKIyBQUFMgc3VwcG9ydAojCkNPTkZJR19QUFM9bQojIENPTkZJR19Q UFNfREVCVUcgaXMgbm90IHNldAoKIwojIFBQUyBjbGllbnRzIHN1cHBvcnQKIwojIENPTkZJR19Q UFNfQ0xJRU5UX0tUSU1FUiBpcyBub3Qgc2V0CkNPTkZJR19QUFNfQ0xJRU5UX0xESVNDPW0KQ09O RklHX1BQU19DTElFTlRfUEFSUE9SVD1tCkNPTkZJR19QUFNfQ0xJRU5UX0dQSU89bQoKIwojIFBQ UyBnZW5lcmF0b3JzIHN1cHBvcnQKIwoKIwojIFBUUCBjbG9jayBzdXBwb3J0CiMKQ09ORklHX1BU UF8xNTg4X0NMT0NLPW0KQ09ORklHX0RQODM2NDBfUEhZPW0KQ09ORklHX1BUUF8xNTg4X0NMT0NL X1BDSD1tCkNPTkZJR19BUkNIX1dBTlRfT1BUSU9OQUxfR1BJT0xJQj15CiMgQ09ORklHX0dQSU9M SUIgaXMgbm90IHNldApDT05GSUdfVzE9bQpDT05GSUdfVzFfQ09OPXkKCiMKIyAxLXdpcmUgQnVz IE1hc3RlcnMKIwojIENPTkZJR19XMV9NQVNURVJfTUFUUk9YIGlzIG5vdCBzZXQKQ09ORklHX1cx X01BU1RFUl9EUzI0OTA9bQpDT05GSUdfVzFfTUFTVEVSX0RTMjQ4Mj1tCkNPTkZJR19XMV9NQVNU RVJfRFMxV009bQoKIwojIDEtd2lyZSBTbGF2ZXMKIwpDT05GSUdfVzFfU0xBVkVfVEhFUk09bQpD T05GSUdfVzFfU0xBVkVfU01FTT1tCkNPTkZJR19XMV9TTEFWRV9EUzI0MDg9bQpDT05GSUdfVzFf U0xBVkVfRFMyNDIzPW0KQ09ORklHX1cxX1NMQVZFX0RTMjQzMT1tCkNPTkZJR19XMV9TTEFWRV9E UzI0MzM9bQpDT05GSUdfVzFfU0xBVkVfRFMyNDMzX0NSQz15CkNPTkZJR19XMV9TTEFWRV9EUzI3 NjA9bQpDT05GSUdfVzFfU0xBVkVfRFMyNzgwPW0KQ09ORklHX1cxX1NMQVZFX0RTMjc4MT1tCkNP TkZJR19XMV9TTEFWRV9EUzI4RTA0PW0KQ09ORklHX1cxX1NMQVZFX0JRMjcwMDA9bQpDT05GSUdf UE9XRVJfU1VQUExZPXkKIyBDT05GSUdfUE9XRVJfU1VQUExZX0RFQlVHIGlzIG5vdCBzZXQKIyBD T05GSUdfUERBX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9QT1dFUiBpcyBub3Qgc2V0 CiMgQ09ORklHX0JBVFRFUllfRFMyNzYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3 ODAgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0RTMjc4MSBpcyBub3Qgc2V0CiMgQ09ORklH X0JBVFRFUllfRFMyNzgyIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9TQlMgaXMgbm90IHNl dAojIENPTkZJR19CQVRURVJZX0JRMjd4MDAgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX01B WDE3MDQwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MiBpcyBub3Qgc2V0CiMg Q09ORklHX0NIQVJHRVJfSVNQMTcwNCBpcyBub3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTUFYODkw MyBpcyBub3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTFA4NzI3IGlzIG5vdCBzZXQKQ09ORklHX0NI QVJHRVJfU01CMzQ3PW0KIyBDT05GSUdfUE9XRVJfQVZTIGlzIG5vdCBzZXQKQ09ORklHX0hXTU9O PXkKQ09ORklHX0hXTU9OX1ZJRD1tCiMgQ09ORklHX0hXTU9OX0RFQlVHX0NISVAgaXMgbm90IHNl dAoKIwojIE5hdGl2ZSBkcml2ZXJzCiMKQ09ORklHX1NFTlNPUlNfQUJJVFVHVVJVPW0KQ09ORklH X1NFTlNPUlNfQUJJVFVHVVJVMz1tCkNPTkZJR19TRU5TT1JTX0FENzQxND1tCkNPTkZJR19TRU5T T1JTX0FENzQxOD1tCkNPTkZJR19TRU5TT1JTX0FETTEwMjE9bQpDT05GSUdfU0VOU09SU19BRE0x MDI1PW0KQ09ORklHX1NFTlNPUlNfQURNMTAyNj1tCkNPTkZJR19TRU5TT1JTX0FETTEwMjk9bQpD T05GSUdfU0VOU09SU19BRE0xMDMxPW0KQ09ORklHX1NFTlNPUlNfQURNOTI0MD1tCkNPTkZJR19T RU5TT1JTX0FEVDc0MTE9bQpDT05GSUdfU0VOU09SU19BRFQ3NDYyPW0KQ09ORklHX1NFTlNPUlNf QURUNzQ3MD1tCkNPTkZJR19TRU5TT1JTX0FEVDc0NzU9bQpDT05GSUdfU0VOU09SU19BU0M3NjIx PW0KQ09ORklHX1NFTlNPUlNfSzhURU1QPW0KQ09ORklHX1NFTlNPUlNfSzEwVEVNUD1tCkNPTkZJ R19TRU5TT1JTX0ZBTTE1SF9QT1dFUj1tCkNPTkZJR19TRU5TT1JTX0FTQjEwMD1tCkNPTkZJR19T RU5TT1JTX0FUWFAxPW0KQ09ORklHX1NFTlNPUlNfRFM2MjA9bQpDT05GSUdfU0VOU09SU19EUzE2 MjE9bQpDT05GSUdfU0VOU09SU19JNUtfQU1CPW0KQ09ORklHX1NFTlNPUlNfRjcxODA1Rj1tCkNP TkZJR19TRU5TT1JTX0Y3MTg4MkZHPW0KQ09ORklHX1NFTlNPUlNfRjc1Mzc1Uz1tCkNPTkZJR19T RU5TT1JTX0ZTQ0hNRD1tCkNPTkZJR19TRU5TT1JTX0c3NjBBPW0KQ09ORklHX1NFTlNPUlNfR0w1 MThTTT1tCkNPTkZJR19TRU5TT1JTX0dMNTIwU009bQojIENPTkZJR19TRU5TT1JTX0hJSDYxMzAg aXMgbm90IHNldApDT05GSUdfU0VOU09SU19DT1JFVEVNUD1tCkNPTkZJR19TRU5TT1JTX0lCTUFF TT1tCkNPTkZJR19TRU5TT1JTX0lCTVBFWD1tCkNPTkZJR19TRU5TT1JTX0lUODc9bQojIENPTkZJ R19TRU5TT1JTX0pDNDIgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19MSU5FQUdFPW0KQ09ORklH X1NFTlNPUlNfTE02Mz1tCkNPTkZJR19TRU5TT1JTX0xNNzM9bQpDT05GSUdfU0VOU09SU19MTTc1 PW0KQ09ORklHX1NFTlNPUlNfTE03Nz1tCkNPTkZJR19TRU5TT1JTX0xNNzg9bQpDT05GSUdfU0VO U09SU19MTTgwPW0KQ09ORklHX1NFTlNPUlNfTE04Mz1tCkNPTkZJR19TRU5TT1JTX0xNODU9bQpD T05GSUdfU0VOU09SU19MTTg3PW0KQ09ORklHX1NFTlNPUlNfTE05MD1tCkNPTkZJR19TRU5TT1JT X0xNOTI9bQpDT05GSUdfU0VOU09SU19MTTkzPW0KQ09ORklHX1NFTlNPUlNfTFRDNDE1MT1tCkNP TkZJR19TRU5TT1JTX0xUQzQyMTU9bQpDT05GSUdfU0VOU09SU19MVEM0MjQ1PW0KQ09ORklHX1NF TlNPUlNfTFRDNDI2MT1tCkNPTkZJR19TRU5TT1JTX0xNOTUyNDE9bQpDT05GSUdfU0VOU09SU19M TTk1MjQ1PW0KQ09ORklHX1NFTlNPUlNfTUFYMTYwNjU9bQpDT05GSUdfU0VOU09SU19NQVgxNjE5 PW0KQ09ORklHX1NFTlNPUlNfTUFYMTY2OD1tCkNPTkZJR19TRU5TT1JTX01BWDY2Mzk9bQpDT05G SUdfU0VOU09SU19NQVg2NjQyPW0KQ09ORklHX1NFTlNPUlNfTUFYNjY1MD1tCkNPTkZJR19TRU5T T1JTX01DUDMwMjE9bQpDT05GSUdfU0VOU09SU19OVENfVEhFUk1JU1RPUj1tCkNPTkZJR19TRU5T T1JTX1BDODczNjA9bQpDT05GSUdfU0VOU09SU19QQzg3NDI3PW0KQ09ORklHX1NFTlNPUlNfUENG ODU5MT1tCkNPTkZJR19QTUJVUz1tCkNPTkZJR19TRU5TT1JTX1BNQlVTPW0KQ09ORklHX1NFTlNP UlNfQURNMTI3NT1tCkNPTkZJR19TRU5TT1JTX0xNMjUwNjY9bQpDT05GSUdfU0VOU09SU19MVEMy OTc4PW0KQ09ORklHX1NFTlNPUlNfTUFYMTYwNjQ9bQpDT05GSUdfU0VOU09SU19NQVgzNDQ0MD1t CkNPTkZJR19TRU5TT1JTX01BWDg2ODg9bQpDT05GSUdfU0VOU09SU19VQ0Q5MDAwPW0KQ09ORklH X1NFTlNPUlNfVUNEOTIwMD1tCkNPTkZJR19TRU5TT1JTX1pMNjEwMD1tCkNPTkZJR19TRU5TT1JT X1NIVDIxPW0KQ09ORklHX1NFTlNPUlNfU0lTNTU5NT1tCiMgQ09ORklHX1NFTlNPUlNfU01NNjY1 IGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfRE1FMTczNz1tCkNPTkZJR19TRU5TT1JTX0VNQzE0 MDM9bQojIENPTkZJR19TRU5TT1JTX0VNQzIxMDMgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19F TUM2VzIwMT1tCkNPTkZJR19TRU5TT1JTX1NNU0M0N00xPW0KQ09ORklHX1NFTlNPUlNfU01TQzQ3 TTE5Mj1tCkNPTkZJR19TRU5TT1JTX1NNU0M0N0IzOTc9bQpDT05GSUdfU0VOU09SU19TQ0g1NlhY X0NPTU1PTj1tCkNPTkZJR19TRU5TT1JTX1NDSDU2Mjc9bQpDT05GSUdfU0VOU09SU19TQ0g1NjM2 PW0KQ09ORklHX1NFTlNPUlNfQURTMTAxNT1tCkNPTkZJR19TRU5TT1JTX0FEUzc4Mjg9bQpDT05G SUdfU0VOU09SU19BTUM2ODIxPW0KQ09ORklHX1NFTlNPUlNfSU5BMlhYPW0KQ09ORklHX1NFTlNP UlNfVEhNQzUwPW0KQ09ORklHX1NFTlNPUlNfVE1QMTAyPW0KQ09ORklHX1NFTlNPUlNfVE1QNDAx PW0KQ09ORklHX1NFTlNPUlNfVE1QNDIxPW0KQ09ORklHX1NFTlNPUlNfVklBX0NQVVRFTVA9bQpD T05GSUdfU0VOU09SU19WSUE2ODZBPW0KQ09ORklHX1NFTlNPUlNfVlQxMjExPW0KQ09ORklHX1NF TlNPUlNfVlQ4MjMxPW0KQ09ORklHX1NFTlNPUlNfVzgzNzgxRD1tCkNPTkZJR19TRU5TT1JTX1c4 Mzc5MUQ9bQpDT05GSUdfU0VOU09SU19XODM3OTJEPW0KQ09ORklHX1NFTlNPUlNfVzgzNzkzPW0K Q09ORklHX1NFTlNPUlNfVzgzNzk1PW0KIyBDT05GSUdfU0VOU09SU19XODM3OTVfRkFOQ1RSTCBp cyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX1c4M0w3ODVUUz1tCkNPTkZJR19TRU5TT1JTX1c4M0w3 ODZORz1tCkNPTkZJR19TRU5TT1JTX1c4MzYyN0hGPW0KQ09ORklHX1NFTlNPUlNfVzgzNjI3RUhG PW0KQ09ORklHX1NFTlNPUlNfQVBQTEVTTUM9bQoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJR19T RU5TT1JTX0FDUElfUE9XRVI9bQpDT05GSUdfU0VOU09SU19BVEswMTEwPW0KQ09ORklHX1RIRVJN QUw9eQpDT05GSUdfVEhFUk1BTF9IV01PTj15CkNPTkZJR19XQVRDSERPRz15CkNPTkZJR19XQVRD SERPR19DT1JFPXkKIyBDT05GSUdfV0FUQ0hET0dfTk9XQVlPVVQgaXMgbm90IHNldAoKIwojIFdh dGNoZG9nIERldmljZSBEcml2ZXJzCiMKQ09ORklHX1NPRlRfV0FUQ0hET0c9bQojIENPTkZJR19B Q1FVSVJFX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FEVkFOVEVDSF9XRFQgaXMgbm90IHNldApD T05GSUdfQUxJTTE1MzVfV0RUPW0KQ09ORklHX0FMSU03MTAxX1dEVD1tCkNPTkZJR19GNzE4MDhF X1dEVD1tCkNPTkZJR19TUDUxMDBfVENPPW0KIyBDT05GSUdfU0M1MjBfV0RUIGlzIG5vdCBzZXQK Q09ORklHX1NCQ19GSVRQQzJfV0FUQ0hET0c9bQojIENPTkZJR19FVVJPVEVDSF9XRFQgaXMgbm90 IHNldApDT05GSUdfSUI3MDBfV0RUPW0KQ09ORklHX0lCTUFTUj1tCiMgQ09ORklHX1dBRkVSX1dE VCBpcyBub3Qgc2V0CkNPTkZJR19JNjMwMEVTQl9XRFQ9bQpDT05GSUdfSUU2WFhfV0RUPW0KQ09O RklHX0lUQ09fV0RUPW0KQ09ORklHX0lUQ09fVkVORE9SX1NVUFBPUlQ9eQpDT05GSUdfSVQ4NzEy Rl9XRFQ9bQpDT05GSUdfSVQ4N19XRFQ9bQpDT05GSUdfSFBfV0FUQ0hET0c9bQpDT05GSUdfSFBX RFRfTk1JX0RFQ09ESU5HPXkKIyBDT05GSUdfU0MxMjAwX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklH X1BDODc0MTNfV0RUIGlzIG5vdCBzZXQKQ09ORklHX05WX1RDTz1tCiMgQ09ORklHXzYwWFhfV0RU IGlzIG5vdCBzZXQKIyBDT05GSUdfU0JDODM2MF9XRFQgaXMgbm90IHNldAojIENPTkZJR19DUFU1 X1dEVCBpcyBub3Qgc2V0CkNPTkZJR19TTVNDX1NDSDMxMVhfV0RUPW0KIyBDT05GSUdfU01TQzM3 Qjc4N19XRFQgaXMgbm90IHNldApDT05GSUdfVklBX1dEVD1tCkNPTkZJR19XODM2MjdIRl9XRFQ9 bQpDT05GSUdfVzgzNjk3SEZfV0RUPW0KQ09ORklHX1c4MzY5N1VHX1dEVD1tCkNPTkZJR19XODM4 NzdGX1dEVD1tCkNPTkZJR19XODM5NzdGX1dEVD1tCkNPTkZJR19NQUNIWl9XRFQ9bQojIENPTkZJ R19TQkNfRVBYX0MzX1dBVENIRE9HIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9XRFQ9eQoKIwojIFBD SS1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCkNPTkZJR19QQ0lQQ1dBVENIRE9HPW0KQ09ORklHX1dE VFBDST1tCgojCiMgVVNCLWJhc2VkIFdhdGNoZG9nIENhcmRzCiMKQ09ORklHX1VTQlBDV0FUQ0hE T0c9bQpDT05GSUdfU1NCX1BPU1NJQkxFPXkKCiMKIyBTb25pY3MgU2lsaWNvbiBCYWNrcGxhbmUK IwpDT05GSUdfU1NCPW0KQ09ORklHX1NTQl9TUFJPTT15CkNPTkZJR19TU0JfQkxPQ0tJTz15CkNP TkZJR19TU0JfUENJSE9TVF9QT1NTSUJMRT15CkNPTkZJR19TU0JfUENJSE9TVD15CkNPTkZJR19T U0JfQjQzX1BDSV9CUklER0U9eQpDT05GSUdfU1NCX1BDTUNJQUhPU1RfUE9TU0lCTEU9eQpDT05G SUdfU1NCX1BDTUNJQUhPU1Q9eQpDT05GSUdfU1NCX1NESU9IT1NUX1BPU1NJQkxFPXkKQ09ORklH X1NTQl9TRElPSE9TVD15CiMgQ09ORklHX1NTQl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TU0Jf RFJJVkVSX1BDSUNPUkVfUE9TU0lCTEU9eQpDT05GSUdfU1NCX0RSSVZFUl9QQ0lDT1JFPXkKQ09O RklHX0JDTUFfUE9TU0lCTEU9eQoKIwojIEJyb2FkY29tIHNwZWNpZmljIEFNQkEKIwpDT05GSUdf QkNNQT1tCkNPTkZJR19CQ01BX0JMT0NLSU89eQpDT05GSUdfQkNNQV9IT1NUX1BDSV9QT1NTSUJM RT15CkNPTkZJR19CQ01BX0hPU1RfUENJPXkKQ09ORklHX0JDTUFfRFJJVkVSX0dNQUNfQ01OPXkK IyBDT05GSUdfQkNNQV9ERUJVRyBpcyBub3Qgc2V0CgojCiMgTXVsdGlmdW5jdGlvbiBkZXZpY2Ug ZHJpdmVycwojCkNPTkZJR19NRkRfQ09SRT1tCkNPTkZJR19NRkRfU001MDE9bQojIENPTkZJR19I VENfUEFTSUMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0xNMzUzMyBpcyBub3Qgc2V0CiMgQ09O RklHX1RQUzYxMDVYIGlzIG5vdCBzZXQKIyBDT05GSUdfVFBTNjUwN1ggaXMgbm90IHNldAojIENP TkZJR19NRkRfVFBTNjUyMTcgaXMgbm90IHNldAojIENPTkZJR19NRkRfVE1JTyBpcyBub3Qgc2V0 CiMgQ09ORklHX01GRF9BUklaT05BX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9QQ0Y1MDYz MyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQzEzWFhYX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklH X0FCWDUwMF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0NTNTUzNSBpcyBub3Qgc2V0CkNP TkZJR19MUENfU0NIPW0KQ09ORklHX0xQQ19JQ0g9bQojIENPTkZJR19NRkRfUkRDMzIxWCBpcyBu b3Qgc2V0CiMgQ09ORklHX01GRF9KQU5aX0NNT0RJTyBpcyBub3Qgc2V0CkNPTkZJR19NRkRfVlg4 NTU9bQpDT05GSUdfTUZEX1dMMTI3M19DT1JFPW0KIyBDT05GSUdfUkVHVUxBVE9SIGlzIG5vdCBz ZXQKQ09ORklHX01FRElBX1NVUFBPUlQ9bQoKIwojIE11bHRpbWVkaWEgY29yZSBzdXBwb3J0CiMK Q09ORklHX01FRElBX0NBTUVSQV9TVVBQT1JUPXkKQ09ORklHX01FRElBX0FOQUxPR19UVl9TVVBQ T1JUPXkKQ09ORklHX01FRElBX0RJR0lUQUxfVFZfU1VQUE9SVD15CkNPTkZJR19NRURJQV9SQURJ T19TVVBQT1JUPXkKQ09ORklHX01FRElBX1JDX1NVUFBPUlQ9eQpDT05GSUdfTUVESUFfQ09OVFJP TExFUj15CkNPTkZJR19WSURFT19ERVY9bQpDT05GSUdfVklERU9fVjRMMl9DT01NT049bQpDT05G SUdfVklERU9fVjRMMl9TVUJERVZfQVBJPXkKQ09ORklHX0RWQl9DT1JFPW0KQ09ORklHX0RWQl9O RVQ9eQoKIwojIE1lZGlhIGRyaXZlcnMKIwpDT05GSUdfVklERU9fU0FBNzE0Nj1tCkNPTkZJR19W SURFT19TQUE3MTQ2X1ZWPW0KQ09ORklHX1JDX0NPUkU9bQpDT05GSUdfUkNfTUFQPW0KQ09ORklH X1JDX0RFQ09ERVJTPXkKQ09ORklHX0xJUkM9bQpDT05GSUdfSVJfTElSQ19DT0RFQz1tCkNPTkZJ R19JUl9ORUNfREVDT0RFUj1tCkNPTkZJR19JUl9SQzVfREVDT0RFUj1tCkNPTkZJR19JUl9SQzZf REVDT0RFUj1tCkNPTkZJR19JUl9KVkNfREVDT0RFUj1tCkNPTkZJR19JUl9TT05ZX0RFQ09ERVI9 bQpDT05GSUdfSVJfUkM1X1NaX0RFQ09ERVI9bQpDT05GSUdfSVJfU0FOWU9fREVDT0RFUj1tCkNP TkZJR19JUl9NQ0VfS0JEX0RFQ09ERVI9bQpDT05GSUdfUkNfREVWSUNFUz15CkNPTkZJR19SQ19B VElfUkVNT1RFPW0KQ09ORklHX0lSX0VORT1tCkNPTkZJR19JUl9JTU9OPW0KQ09ORklHX0lSX01D RVVTQj1tCkNPTkZJR19JUl9JVEVfQ0lSPW0KQ09ORklHX0lSX0ZJTlRFSz1tCkNPTkZJR19JUl9O VVZPVE9OPW0KQ09ORklHX0lSX1JFRFJBVDM9bQpDT05GSUdfSVJfU1RSRUFNWkFQPW0KQ09ORklH X0lSX1dJTkJPTkRfQ0lSPW0KQ09ORklHX0lSX0lHVUFOQT1tCkNPTkZJR19SQ19MT09QQkFDSz1t CkNPTkZJR19JUl9HUElPX0NJUj1tCkNPTkZJR19NRURJQV9BVFRBQ0g9eQpDT05GSUdfTUVESUFf VFVORVI9bQojIENPTkZJR19NRURJQV9UVU5FUl9DVVNUT01JU0UgaXMgbm90IHNldApDT05GSUdf TUVESUFfVFVORVJfU0lNUExFPW0KQ09ORklHX01FRElBX1RVTkVSX1REQTgyOTA9bQpDT05GSUdf TUVESUFfVFVORVJfVERBODI3WD1tCkNPTkZJR19NRURJQV9UVU5FUl9UREExODI3MT1tCkNPTkZJ R19NRURJQV9UVU5FUl9UREE5ODg3PW0KQ09ORklHX01FRElBX1RVTkVSX1RFQTU3NjE9bQpDT05G SUdfTUVESUFfVFVORVJfVEVBNTc2Nz1tCkNPTkZJR19NRURJQV9UVU5FUl9NVDIwWFg9bQpDT05G SUdfTUVESUFfVFVORVJfTVQyMDYwPW0KQ09ORklHX01FRElBX1RVTkVSX01UMjA2Mz1tCkNPTkZJ R19NRURJQV9UVU5FUl9NVDIyNjY9bQpDT05GSUdfTUVESUFfVFVORVJfTVQyMTMxPW0KQ09ORklH X01FRElBX1RVTkVSX1FUMTAxMD1tCkNPTkZJR19NRURJQV9UVU5FUl9YQzIwMjg9bQpDT05GSUdf TUVESUFfVFVORVJfWEM1MDAwPW0KQ09ORklHX01FRElBX1RVTkVSX1hDNDAwMD1tCkNPTkZJR19N RURJQV9UVU5FUl9NWEw1MDA1Uz1tCkNPTkZJR19NRURJQV9UVU5FUl9NWEw1MDA3VD1tCkNPTkZJ R19NRURJQV9UVU5FUl9NQzQ0UzgwMz1tCkNPTkZJR19NRURJQV9UVU5FUl9NQVgyMTY1PW0KQ09O RklHX01FRElBX1RVTkVSX1REQTE4MjE4PW0KQ09ORklHX01FRElBX1RVTkVSX0ZDMDAxMT1tCkNP TkZJR19NRURJQV9UVU5FUl9GQzAwMTI9bQpDT05GSUdfTUVESUFfVFVORVJfRkMwMDEzPW0KQ09O RklHX01FRElBX1RVTkVSX1REQTE4MjEyPW0KQ09ORklHX01FRElBX1RVTkVSX1RVQTkwMDE9bQpD T05GSUdfVklERU9fVjRMMj1tCkNPTkZJR19WSURFT0JVRl9HRU49bQpDT05GSUdfVklERU9CVUZf RE1BX1NHPW0KQ09ORklHX1ZJREVPQlVGX1ZNQUxMT0M9bQpDT05GSUdfVklERU9CVUZfRFZCPW0K Q09ORklHX1ZJREVPX0JUQ1g9bQpDT05GSUdfVklERU9fVFZFRVBST009bQpDT05GSUdfVklERU9f VFVORVI9bQpDT05GSUdfVklERU9CVUYyX0NPUkU9bQpDT05GSUdfVklERU9CVUYyX01FTU9QUz1t CkNPTkZJR19WSURFT0JVRjJfVk1BTExPQz1tCkNPTkZJR19WSURFT19DQVBUVVJFX0RSSVZFUlM9 eQojIENPTkZJR19WSURFT19BRFZfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19WSURFT19GSVhF RF9NSU5PUl9SQU5HRVMgaXMgbm90IHNldApDT05GSUdfVklERU9fSEVMUEVSX0NISVBTX0FVVE89 eQpDT05GSUdfVklERU9fSVJfSTJDPW0KCiMKIyBBdWRpbyBkZWNvZGVycywgcHJvY2Vzc29ycyBh bmQgbWl4ZXJzCiMKQ09ORklHX1ZJREVPX1RWQVVESU89bQpDT05GSUdfVklERU9fVERBNzQzMj1t CkNPTkZJR19WSURFT19UREE5ODQwPW0KQ09ORklHX1ZJREVPX1RFQTY0MTVDPW0KQ09ORklHX1ZJ REVPX1RFQTY0MjA9bQpDT05GSUdfVklERU9fTVNQMzQwMD1tCkNPTkZJR19WSURFT19DUzUzNDU9 bQpDT05GSUdfVklERU9fQ1M1M0wzMkE9bQpDT05GSUdfVklERU9fV004Nzc1PW0KQ09ORklHX1ZJ REVPX1dNODczOT1tCkNPTkZJR19WSURFT19WUDI3U01QWD1tCgojCiMgUkRTIGRlY29kZXJzCiMK Q09ORklHX1ZJREVPX1NBQTY1ODg9bQoKIwojIFZpZGVvIGRlY29kZXJzCiMKQ09ORklHX1ZJREVP X0JUODE5PW0KQ09ORklHX1ZJREVPX0JUODU2PW0KQ09ORklHX1ZJREVPX0JUODY2PW0KQ09ORklH X1ZJREVPX0tTMDEyNz1tCkNPTkZJR19WSURFT19TQUE3MTEwPW0KQ09ORklHX1ZJREVPX1NBQTcx MVg9bQpDT05GSUdfVklERU9fVFZQNTE1MD1tCkNPTkZJR19WSURFT19WUFgzMjIwPW0KCiMKIyBW aWRlbyBhbmQgYXVkaW8gZGVjb2RlcnMKIwpDT05GSUdfVklERU9fU0FBNzE3WD1tCkNPTkZJR19W SURFT19DWDI1ODQwPW0KCiMKIyBNUEVHIHZpZGVvIGVuY29kZXJzCiMKQ09ORklHX1ZJREVPX0NY MjM0MVg9bQoKIwojIFZpZGVvIGVuY29kZXJzCiMKQ09ORklHX1ZJREVPX1NBQTcxMjc9bQpDT05G SUdfVklERU9fU0FBNzE4NT1tCkNPTkZJR19WSURFT19BRFY3MTcwPW0KQ09ORklHX1ZJREVPX0FE VjcxNzU9bQoKIwojIENhbWVyYSBzZW5zb3IgZGV2aWNlcwojCkNPTkZJR19WSURFT19NVDlWMDEx PW0KCiMKIyBGbGFzaCBkZXZpY2VzCiMKCiMKIyBWaWRlbyBpbXByb3ZlbWVudCBjaGlwcwojCkNP TkZJR19WSURFT19VUEQ2NDAzMUE9bQpDT05GSUdfVklERU9fVVBENjQwODM9bQoKIwojIE1pc2Nl bGFuZW91cyBoZWxwZXIgY2hpcHMKIwpDT05GSUdfVklERU9fTTUyNzkwPW0KIyBDT05GSUdfVklE RU9fVklWSSBpcyBub3Qgc2V0CkNPTkZJR19WNExfVVNCX0RSSVZFUlM9eQoKIwojIFdlYmNhbSBk ZXZpY2VzCiMKQ09ORklHX1VTQl9WSURFT19DTEFTUz1tCkNPTkZJR19VU0JfVklERU9fQ0xBU1Nf SU5QVVRfRVZERVY9eQpDT05GSUdfVVNCX0dTUENBPW0KQ09ORklHX1VTQl9NNTYwMj1tCkNPTkZJ R19VU0JfU1RWMDZYWD1tCkNPTkZJR19VU0JfR0w4NjA9bQpDT05GSUdfVVNCX0dTUENBX0JFTlE9 bQpDT05GSUdfVVNCX0dTUENBX0NPTkVYPW0KQ09ORklHX1VTQl9HU1BDQV9DUElBMT1tCkNPTkZJ R19VU0JfR1NQQ0FfRVRPTVM9bQpDT05GSUdfVVNCX0dTUENBX0ZJTkVQSVg9bQpDT05GSUdfVVNC X0dTUENBX0pFSUxJTko9bQpDT05GSUdfVVNCX0dTUENBX0pMMjAwNUJDRD1tCkNPTkZJR19VU0Jf R1NQQ0FfS0lORUNUPW0KQ09ORklHX1VTQl9HU1BDQV9LT05JQ0E9bQpDT05GSUdfVVNCX0dTUENB X01BUlM9bQpDT05GSUdfVVNCX0dTUENBX01SOTczMTBBPW0KQ09ORklHX1VTQl9HU1BDQV9OVzgw WD1tCkNPTkZJR19VU0JfR1NQQ0FfT1Y1MTk9bQpDT05GSUdfVVNCX0dTUENBX09WNTM0PW0KQ09O RklHX1VTQl9HU1BDQV9PVjUzNF85PW0KQ09ORklHX1VTQl9HU1BDQV9QQUMyMDc9bQpDT05GSUdf VVNCX0dTUENBX1BBQzczMDI9bQpDT05GSUdfVVNCX0dTUENBX1BBQzczMTE9bQpDT05GSUdfVVNC X0dTUENBX1NFNDAxPW0KQ09ORklHX1VTQl9HU1BDQV9TTjlDMjAyOD1tCkNPTkZJR19VU0JfR1NQ Q0FfU045QzIwWD1tCkNPTkZJR19VU0JfR1NQQ0FfU09OSVhCPW0KQ09ORklHX1VTQl9HU1BDQV9T T05JWEo9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1MDA9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1 MDE9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1MDU9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1MDY9 bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1MDg9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1NjE9bQpD T05GSUdfVVNCX0dTUENBX1NQQ0ExNTI4PW0KQ09ORklHX1VTQl9HU1BDQV9TUTkwNT1tCkNPTkZJ R19VU0JfR1NQQ0FfU1E5MDVDPW0KQ09ORklHX1VTQl9HU1BDQV9TUTkzMFg9bQpDT05GSUdfVVNC X0dTUENBX1NUSzAxND1tCkNPTkZJR19VU0JfR1NQQ0FfU1RWMDY4MD1tCkNPTkZJR19VU0JfR1NQ Q0FfU1VOUExVUz1tCkNPTkZJR19VU0JfR1NQQ0FfVDYxMz1tCkNPTkZJR19VU0JfR1NQQ0FfVE9Q Uk89bQpDT05GSUdfVVNCX0dTUENBX1RWODUzMj1tCkNPTkZJR19VU0JfR1NQQ0FfVkMwMzJYPW0K Q09ORklHX1VTQl9HU1BDQV9WSUNBTT1tCkNPTkZJR19VU0JfR1NQQ0FfWElSTElOS19DSVQ9bQpD T05GSUdfVVNCX0dTUENBX1pDM1hYPW0KQ09ORklHX1VTQl9QV0M9bQojIENPTkZJR19VU0JfUFdD X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9QV0NfSU5QVVRfRVZERVY9eQpDT05GSUdfVklE RU9fQ1BJQTI9bQpDT05GSUdfVVNCX1pSMzY0WFg9bQpDT05GSUdfVVNCX1NUS1dFQkNBTT1tCkNP TkZJR19VU0JfUzIyNTU9bQojIENPTkZJR19VU0JfU045QzEwMiBpcyBub3Qgc2V0CgojCiMgV2Vi Y2FtIGFuZC9vciBUViBVU0IgZGV2aWNlcwojCkNPTkZJR19WSURFT19FTTI4WFg9bQpDT05GSUdf VklERU9fRU0yOFhYX0FMU0E9bQpDT05GSUdfVklERU9fRU0yOFhYX0RWQj1tCkNPTkZJR19WSURF T19FTTI4WFhfUkM9bQoKIwojIFRWIFVTQiBkZXZpY2VzCiMKQ09ORklHX1ZJREVPX0FVMDgyOD1t CkNPTkZJR19WSURFT19QVlJVU0IyPW0KQ09ORklHX1ZJREVPX1BWUlVTQjJfU1lTRlM9eQpDT05G SUdfVklERU9fUFZSVVNCMl9EVkI9eQojIENPTkZJR19WSURFT19QVlJVU0IyX0RFQlVHSUZDIGlz IG5vdCBzZXQKQ09ORklHX1ZJREVPX0hEUFZSPW0KQ09ORklHX1ZJREVPX1RMRzIzMDA9bQpDT05G SUdfVklERU9fQ1gyMzFYWD1tCkNPTkZJR19WSURFT19DWDIzMVhYX1JDPXkKQ09ORklHX1ZJREVP X0NYMjMxWFhfQUxTQT1tCkNPTkZJR19WSURFT19DWDIzMVhYX0RWQj1tCkNPTkZJR19WSURFT19U TTYwMDA9bQpDT05GSUdfVklERU9fVE02MDAwX0FMU0E9bQpDT05GSUdfVklERU9fVE02MDAwX0RW Qj1tCkNPTkZJR19WSURFT19VU0JWSVNJT049bQpDT05GSUdfVjRMX1BDSV9EUklWRVJTPXkKQ09O RklHX1ZJREVPX0JUODQ4PW0KQ09ORklHX1ZJREVPX0JUODQ4X0RWQj15CkNPTkZJR19WSURFT19D WDE4PW0KQ09ORklHX1ZJREVPX0NYMThfQUxTQT1tCkNPTkZJR19WSURFT19DWDIzODg1PW0KQ09O RklHX01FRElBX0FMVEVSQV9DST1tCiMgQ09ORklHX1ZJREVPX0NYMjU4MjEgaXMgbm90IHNldApD T05GSUdfVklERU9fQ1g4OD1tCkNPTkZJR19WSURFT19DWDg4X0FMU0E9bQpDT05GSUdfVklERU9f Q1g4OF9CTEFDS0JJUkQ9bQpDT05GSUdfVklERU9fQ1g4OF9EVkI9bQpDT05GSUdfVklERU9fQ1g4 OF9WUDMwNTQ9bQpDT05GSUdfVklERU9fQ1g4OF9NUEVHPW0KQ09ORklHX1ZJREVPX0hFWElVTV9H RU1JTkk9bQpDT05GSUdfVklERU9fSEVYSVVNX09SSU9OPW0KQ09ORklHX1ZJREVPX0lWVFY9bQpD T05GSUdfVklERU9fRkJfSVZUVj1tCkNPTkZJR19WSURFT19NRVlFPW0KQ09ORklHX1ZJREVPX01Y Qj1tCkNPTkZJR19WSURFT19TQUE3MTM0PW0KQ09ORklHX1ZJREVPX1NBQTcxMzRfQUxTQT1tCkNP TkZJR19WSURFT19TQUE3MTM0X1JDPXkKQ09ORklHX1ZJREVPX1NBQTcxMzRfRFZCPW0KQ09ORklH X1ZJREVPX1NBQTcxNjQ9bQpDT05GSUdfVklERU9fWk9SQU49bQpDT05GSUdfVklERU9fWk9SQU5f REMzMD1tCkNPTkZJR19WSURFT19aT1JBTl9aUjM2MDYwPW0KQ09ORklHX1ZJREVPX1pPUkFOX0JV Wj1tCkNPTkZJR19WSURFT19aT1JBTl9EQzEwPW0KQ09ORklHX1ZJREVPX1pPUkFOX0xNTDMzPW0K Q09ORklHX1ZJREVPX1pPUkFOX0xNTDMzUjEwPW0KQ09ORklHX1ZJREVPX1pPUkFOX0FWUzZFWUVT PW0KIyBDT05GSUdfVjRMX0lTQV9QQVJQT1JUX0RSSVZFUlMgaXMgbm90IHNldAojIENPTkZJR19W NExfUExBVEZPUk1fRFJJVkVSUyBpcyBub3Qgc2V0CkNPTkZJR19WNExfTUVNMk1FTV9EUklWRVJT PXkKIyBDT05GSUdfVklERU9fTUVNMk1FTV9URVNUREVWIGlzIG5vdCBzZXQKQ09ORklHX1JBRElP X0FEQVBURVJTPXkKQ09ORklHX1JBRElPX1NJNDcwWD15CkNPTkZJR19VU0JfU0k0NzBYPW0KQ09O RklHX0kyQ19TSTQ3MFg9bQpDT05GSUdfVVNCX01SODAwPW0KQ09ORklHX1VTQl9EU0JSPW0KQ09O RklHX1JBRElPX01BWElSQURJTz1tCkNPTkZJR19SQURJT19TSEFSSz1tCkNPTkZJR19SQURJT19T SEFSSzI9bQpDT05GSUdfSTJDX1NJNDcxMz1tCkNPTkZJR19SQURJT19TSTQ3MTM9bQpDT05GSUdf VVNCX0tFRU5FPW0KQ09ORklHX1JBRElPX1RFQTU3NjQ9bQpDT05GSUdfUkFESU9fU0FBNzcwNkg9 bQojIENPTkZJR19SQURJT19URUY2ODYyIGlzIG5vdCBzZXQKQ09ORklHX1JBRElPX1dMMTI3Mz1t CgojCiMgVGV4YXMgSW5zdHJ1bWVudHMgV0wxMjh4IEZNIGRyaXZlciAoU1QgYmFzZWQpCiMKQ09O RklHX0RWQl9NQVhfQURBUFRFUlM9OApDT05GSUdfRFZCX0RZTkFNSUNfTUlOT1JTPXkKQ09ORklH X0RWQl9DQVBUVVJFX0RSSVZFUlM9eQoKIwojIFN1cHBvcnRlZCBTQUE3MTQ2IGJhc2VkIFBDSSBB ZGFwdGVycwojCkNPTkZJR19UVFBDSV9FRVBST009bQpDT05GSUdfRFZCX0FWNzExMD1tCkNPTkZJ R19EVkJfQVY3MTEwX09TRD15CkNPTkZJR19EVkJfQlVER0VUX0NPUkU9bQpDT05GSUdfRFZCX0JV REdFVD1tCkNPTkZJR19EVkJfQlVER0VUX0NJPW0KQ09ORklHX0RWQl9CVURHRVRfQVY9bQpDT05G SUdfRFZCX0JVREdFVF9QQVRDSD1tCgojCiMgU3VwcG9ydGVkIFVTQiBBZGFwdGVycwojCkNPTkZJ R19EVkJfVVNCPW0KIyBDT05GSUdfRFZCX1VTQl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19EVkJf VVNCX0E4MDA9bQpDT05GSUdfRFZCX1VTQl9ESUJVU0JfTUI9bQojIENPTkZJR19EVkJfVVNCX0RJ QlVTQl9NQl9GQVVMVFkgaXMgbm90IHNldApDT05GSUdfRFZCX1VTQl9ESUJVU0JfTUM9bQpDT05G SUdfRFZCX1VTQl9ESUIwNzAwPW0KQ09ORklHX0RWQl9VU0JfVU1UXzAxMD1tCkNPTkZJR19EVkJf VVNCX0NYVVNCPW0KQ09ORklHX0RWQl9VU0JfTTkyMFg9bQpDT05GSUdfRFZCX1VTQl9HTDg2MT1t CkNPTkZJR19EVkJfVVNCX0FVNjYxMD1tCkNPTkZJR19EVkJfVVNCX0RJR0lUVj1tCkNPTkZJR19E VkJfVVNCX1ZQNzA0NT1tCkNPTkZJR19EVkJfVVNCX1ZQNzAyWD1tCkNPTkZJR19EVkJfVVNCX0dQ OFBTSz1tCkNPTkZJR19EVkJfVVNCX05PVkFfVF9VU0IyPW0KQ09ORklHX0RWQl9VU0JfVFRVU0Iy PW0KQ09ORklHX0RWQl9VU0JfRFRUMjAwVT1tCkNPTkZJR19EVkJfVVNCX09QRVJBMT1tCkNPTkZJ R19EVkJfVVNCX0FGOTAwNT1tCkNPTkZJR19EVkJfVVNCX0FGOTAwNV9SRU1PVEU9bQpDT05GSUdf RFZCX1VTQl9QQ1RWNDUyRT1tCkNPTkZJR19EVkJfVVNCX0RXMjEwMj1tCkNPTkZJR19EVkJfVVNC X0NJTkVSR1lfVDI9bQpDT05GSUdfRFZCX1VTQl9BTllTRUU9bQpDT05GSUdfRFZCX1VTQl9EVFY1 MTAwPW0KQ09ORklHX0RWQl9VU0JfQUY5MDE1PW0KQ09ORklHX0RWQl9VU0JfQ0U2MjMwPW0KQ09O RklHX0RWQl9VU0JfRlJJSU89bQpDT05GSUdfRFZCX1VTQl9FQzE2OD1tCkNPTkZJR19EVkJfVVNC X0FaNjAwNz1tCkNPTkZJR19EVkJfVVNCX0FaNjAyNz1tCkNPTkZJR19EVkJfVVNCX0xNRTI1MTA9 bQpDT05GSUdfRFZCX1VTQl9URUNITklTQVRfVVNCMj1tCkNPTkZJR19EVkJfVVNCX0lUOTEzWD1t CkNPTkZJR19EVkJfVVNCX01YTDExMVNGPW0KQ09ORklHX0RWQl9VU0JfUlRMMjhYWFU9bQpDT05G SUdfRFZCX1VTQl9BRjkwMzU9bQpDT05GSUdfRFZCX1RUVVNCX0JVREdFVD1tCkNPTkZJR19EVkJf VFRVU0JfREVDPW0KQ09ORklHX1NNU19TSUFOT19NRFRWPW0KCiMKIyBTaWFubyBtb2R1bGUgY29t cG9uZW50cwojCkNPTkZJR19TTVNfVVNCX0RSVj1tCkNPTkZJR19TTVNfU0RJT19EUlY9bQoKIwoj IFN1cHBvcnRlZCBGbGV4Q29wSUkgKEIyQzIpIEFkYXB0ZXJzCiMKQ09ORklHX0RWQl9CMkMyX0ZM RVhDT1A9bQpDT05GSUdfRFZCX0IyQzJfRkxFWENPUF9QQ0k9bQpDT05GSUdfRFZCX0IyQzJfRkxF WENPUF9VU0I9bQojIENPTkZJR19EVkJfQjJDMl9GTEVYQ09QX0RFQlVHIGlzIG5vdCBzZXQKCiMK IyBTdXBwb3J0ZWQgQlQ4NzggQWRhcHRlcnMKIwpDT05GSUdfRFZCX0JUOFhYPW0KCiMKIyBTdXBw b3J0ZWQgUGx1dG8yIEFkYXB0ZXJzCiMKQ09ORklHX0RWQl9QTFVUTzI9bQoKIwojIFN1cHBvcnRl ZCBTRE1DIERNMTEwNSBBZGFwdGVycwojCkNPTkZJR19EVkJfRE0xMTA1PW0KCiMKIyBTdXBwb3J0 ZWQgRmlyZVdpcmUgKElFRUUgMTM5NCkgQWRhcHRlcnMKIwpDT05GSUdfRFZCX0ZJUkVEVFY9bQpD T05GSUdfRFZCX0ZJUkVEVFZfSU5QVVQ9eQoKIwojIFN1cHBvcnRlZCBFYXJ0aHNvZnQgUFQxIEFk YXB0ZXJzCiMKQ09ORklHX0RWQl9QVDE9bQoKIwojIFN1cHBvcnRlZCBNYW50aXMgQWRhcHRlcnMK IwpDT05GSUdfTUFOVElTX0NPUkU9bQpDT05GSUdfRFZCX01BTlRJUz1tCkNPTkZJR19EVkJfSE9Q UEVSPW0KCiMKIyBTdXBwb3J0ZWQgbkdlbmUgQWRhcHRlcnMKIwpDT05GSUdfRFZCX05HRU5FPW0K CiMKIyBTdXBwb3J0ZWQgZGRicmlkZ2UgKCdPY3RvcHVzJykgQWRhcHRlcnMKIwpDT05GSUdfRFZC X0REQlJJREdFPW0KCiMKIyBTdXBwb3J0ZWQgRFZCIEZyb250ZW5kcwojCgojCiMgTXVsdGlzdGFu ZGFyZCAoc2F0ZWxsaXRlKSBmcm9udGVuZHMKIwpDT05GSUdfRFZCX1NUQjA4OTk9bQpDT05GSUdf RFZCX1NUQjYxMDA9bQpDT05GSUdfRFZCX1NUVjA5MHg9bQpDT05GSUdfRFZCX1NUVjYxMTB4PW0K CiMKIyBNdWx0aXN0YW5kYXJkIChjYWJsZSArIHRlcnJlc3RyaWFsKSBmcm9udGVuZHMKIwpDT05G SUdfRFZCX0RSWEs9bQpDT05GSUdfRFZCX1REQTE4MjcxQzJERD1tCgojCiMgRFZCLVMgKHNhdGVs bGl0ZSkgZnJvbnRlbmRzCiMKQ09ORklHX0RWQl9DWDI0MTEwPW0KQ09ORklHX0RWQl9DWDI0MTIz PW0KQ09ORklHX0RWQl9NVDMxMj1tCkNPTkZJR19EVkJfWkwxMDAzNj1tCkNPTkZJR19EVkJfWkwx MDAzOT1tCkNPTkZJR19EVkJfUzVIMTQyMD1tCkNPTkZJR19EVkJfU1RWMDI4OD1tCkNPTkZJR19E VkJfU1RCNjAwMD1tCkNPTkZJR19EVkJfU1RWMDI5OT1tCkNPTkZJR19EVkJfU1RWNjExMD1tCkNP TkZJR19EVkJfU1RWMDkwMD1tCkNPTkZJR19EVkJfVERBODA4Mz1tCkNPTkZJR19EVkJfVERBMTAw ODY9bQpDT05GSUdfRFZCX1REQTgyNjE9bQpDT05GSUdfRFZCX1ZFUzFYOTM9bQpDT05GSUdfRFZC X1RVTkVSX0lURDEwMDA9bQpDT05GSUdfRFZCX1RVTkVSX0NYMjQxMTM9bQpDT05GSUdfRFZCX1RE QTgyNlg9bQpDT05GSUdfRFZCX1RVQTYxMDA9bQpDT05GSUdfRFZCX0NYMjQxMTY9bQpDT05GSUdf RFZCX1NJMjFYWD1tCkNPTkZJR19EVkJfRFMzMDAwPW0KQ09ORklHX0RWQl9NQjg2QTE2PW0KQ09O RklHX0RWQl9UREExMDA3MT1tCgojCiMgRFZCLVQgKHRlcnJlc3RyaWFsKSBmcm9udGVuZHMKIwpD T05GSUdfRFZCX1NQODg3MD1tCkNPTkZJR19EVkJfU1A4ODdYPW0KQ09ORklHX0RWQl9DWDIyNzAw PW0KQ09ORklHX0RWQl9DWDIyNzAyPW0KQ09ORklHX0RWQl9EUlhEPW0KQ09ORklHX0RWQl9MNjQ3 ODE9bQpDT05GSUdfRFZCX1REQTEwMDRYPW0KQ09ORklHX0RWQl9OWFQ2MDAwPW0KQ09ORklHX0RW Ql9NVDM1Mj1tCkNPTkZJR19EVkJfWkwxMDM1Mz1tCkNPTkZJR19EVkJfRElCMzAwME1CPW0KQ09O RklHX0RWQl9ESUIzMDAwTUM9bQpDT05GSUdfRFZCX0RJQjcwMDBNPW0KQ09ORklHX0RWQl9ESUI3 MDAwUD1tCkNPTkZJR19EVkJfVERBMTAwNDg9bQpDT05GSUdfRFZCX0FGOTAxMz1tCkNPTkZJR19E VkJfRUMxMDA9bQpDT05GSUdfRFZCX1NUVjAzNjc9bQpDT05GSUdfRFZCX0NYRDI4MjBSPW0KQ09O RklHX0RWQl9SVEwyODMwPW0KQ09ORklHX0RWQl9SVEwyODMyPW0KCiMKIyBEVkItQyAoY2FibGUp IGZyb250ZW5kcwojCkNPTkZJR19EVkJfVkVTMTgyMD1tCkNPTkZJR19EVkJfVERBMTAwMjE9bQpD T05GSUdfRFZCX1REQTEwMDIzPW0KQ09ORklHX0RWQl9TVFYwMjk3PW0KCiMKIyBBVFNDIChOb3J0 aCBBbWVyaWNhbi9Lb3JlYW4gVGVycmVzdHJpYWwvQ2FibGUgRFRWKSBmcm9udGVuZHMKIwpDT05G SUdfRFZCX05YVDIwMFg9bQpDT05GSUdfRFZCX09SNTEyMTE9bQpDT05GSUdfRFZCX09SNTExMzI9 bQpDT05GSUdfRFZCX0JDTTM1MTA9bQpDT05GSUdfRFZCX0xHRFQzMzBYPW0KQ09ORklHX0RWQl9M R0RUMzMwNT1tCkNPTkZJR19EVkJfTEcyMTYwPW0KQ09ORklHX0RWQl9TNUgxNDA5PW0KQ09ORklH X0RWQl9BVTg1MjI9bQpDT05GSUdfRFZCX0FVODUyMl9EVFY9bQpDT05GSUdfRFZCX0FVODUyMl9W NEw9bQpDT05GSUdfRFZCX1M1SDE0MTE9bQoKIwojIElTREItVCAodGVycmVzdHJpYWwpIGZyb250 ZW5kcwojCkNPTkZJR19EVkJfUzkyMT1tCkNPTkZJR19EVkJfRElCODAwMD1tCkNPTkZJR19EVkJf TUI4NkEyMFM9bQoKIwojIERpZ2l0YWwgdGVycmVzdHJpYWwgb25seSB0dW5lcnMvUExMCiMKQ09O RklHX0RWQl9QTEw9bQpDT05GSUdfRFZCX1RVTkVSX0RJQjAwNzA9bQpDT05GSUdfRFZCX1RVTkVS X0RJQjAwOTA9bQoKIwojIFNFQyBjb250cm9sIGRldmljZXMgZm9yIERWQi1TCiMKQ09ORklHX0RW Ql9MTkJQMjE9bQpDT05GSUdfRFZCX0xOQlAyMj1tCkNPTkZJR19EVkJfSVNMNjQwNT1tCkNPTkZJ R19EVkJfSVNMNjQyMT1tCkNPTkZJR19EVkJfSVNMNjQyMz1tCkNPTkZJR19EVkJfQTgyOTM9bQpD T05GSUdfRFZCX0xHUzhHWFg9bQpDT05GSUdfRFZCX0FUQk04ODMwPW0KQ09ORklHX0RWQl9UREE2 NjV4PW0KQ09ORklHX0RWQl9JWDI1MDVWPW0KQ09ORklHX0RWQl9JVDkxM1hfRkU9bQpDT05GSUdf RFZCX004OFJTMjAwMD1tCkNPTkZJR19EVkJfQUY5MDMzPW0KCiMKIyBUb29scyB0byBkZXZlbG9w IG5ldyBmcm9udGVuZHMKIwojIENPTkZJR19EVkJfRFVNTVlfRkUgaXMgbm90IHNldAoKIwojIEdy YXBoaWNzIHN1cHBvcnQKIwpDT05GSUdfQUdQPXkKQ09ORklHX0FHUF9BTUQ2ND15CkNPTkZJR19B R1BfSU5URUw9eQpDT05GSUdfQUdQX1NJUz15CkNPTkZJR19BR1BfVklBPXkKQ09ORklHX1ZHQV9B UkI9eQpDT05GSUdfVkdBX0FSQl9NQVhfR1BVUz0xNgpDT05GSUdfVkdBX1NXSVRDSEVST089eQpD T05GSUdfRFJNPW0KQ09ORklHX0RSTV9VU0I9bQpDT05GSUdfRFJNX0tNU19IRUxQRVI9bQpDT05G SUdfRFJNX0xPQURfRURJRF9GSVJNV0FSRT15CkNPTkZJR19EUk1fVFRNPW0KIyBDT05GSUdfRFJN X1RERlggaXMgbm90IHNldAojIENPTkZJR19EUk1fUjEyOCBpcyBub3Qgc2V0CkNPTkZJR19EUk1f UkFERU9OPW0KQ09ORklHX0RSTV9SQURFT05fS01TPXkKQ09ORklHX0RSTV9OT1VWRUFVPW0KQ09O RklHX0RSTV9OT1VWRUFVX0JBQ0tMSUdIVD15CkNPTkZJR19EUk1fTk9VVkVBVV9ERUJVRz15Cgoj CiMgSTJDIGVuY29kZXIgb3IgaGVscGVyIGNoaXBzCiMKQ09ORklHX0RSTV9JMkNfQ0g3MDA2PW0K Q09ORklHX0RSTV9JMkNfU0lMMTY0PW0KIyBDT05GSUdfRFJNX0k4MTAgaXMgbm90IHNldApDT05G SUdfRFJNX0k5MTU9bQpDT05GSUdfRFJNX0k5MTVfS01TPXkKIyBDT05GSUdfRFJNX01HQSBpcyBu b3Qgc2V0CiMgQ09ORklHX0RSTV9TSVMgaXMgbm90IHNldApDT05GSUdfRFJNX1ZJQT1tCiMgQ09O RklHX0RSTV9TQVZBR0UgaXMgbm90IHNldApDT05GSUdfRFJNX1ZNV0dGWD1tCiMgQ09ORklHX0RS TV9WTVdHRlhfRkJDT04gaXMgbm90IHNldApDT05GSUdfRFJNX0dNQTUwMD1tCiMgQ09ORklHX0RS TV9HTUE2MDAgaXMgbm90IHNldApDT05GSUdfRFJNX0dNQTM2MDA9eQpDT05GSUdfRFJNX1VETD1t CkNPTkZJR19EUk1fQVNUPW0KQ09ORklHX0RSTV9NR0FHMjAwPW0KQ09ORklHX0RSTV9DSVJSVVNf UUVNVT1tCiMgQ09ORklHX1NUVUJfUE9VTFNCTyBpcyBub3Qgc2V0CkNPTkZJR19WR0FTVEFURT1t CkNPTkZJR19WSURFT19PVVRQVVRfQ09OVFJPTD1tCkNPTkZJR19GQj15CiMgQ09ORklHX0ZJUk1X QVJFX0VESUQgaXMgbm90IHNldAojIENPTkZJR19GQl9EREMgaXMgbm90IHNldApDT05GSUdfRkJf Qk9PVF9WRVNBX1NVUFBPUlQ9eQpDT05GSUdfRkJfQ0ZCX0ZJTExSRUNUPXkKQ09ORklHX0ZCX0NG Ql9DT1BZQVJFQT15CkNPTkZJR19GQl9DRkJfSU1BR0VCTElUPXkKIyBDT05GSUdfRkJfQ0ZCX1JF Vl9QSVhFTFNfSU5fQllURSBpcyBub3Qgc2V0CkNPTkZJR19GQl9TWVNfRklMTFJFQ1Q9eQpDT05G SUdfRkJfU1lTX0NPUFlBUkVBPXkKQ09ORklHX0ZCX1NZU19JTUFHRUJMSVQ9eQojIENPTkZJR19G Ql9GT1JFSUdOX0VORElBTiBpcyBub3Qgc2V0CkNPTkZJR19GQl9TWVNfRk9QUz15CiMgQ09ORklH X0ZCX1dNVF9HRV9ST1BTIGlzIG5vdCBzZXQKQ09ORklHX0ZCX0RFRkVSUkVEX0lPPXkKIyBDT05G SUdfRkJfU1ZHQUxJQiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01BQ01PREVTIGlzIG5vdCBzZXQK Q09ORklHX0ZCX0JBQ0tMSUdIVD15CiMgQ09ORklHX0ZCX01PREVfSEVMUEVSUyBpcyBub3Qgc2V0 CkNPTkZJR19GQl9USUxFQkxJVFRJTkc9eQoKIwojIEZyYW1lIGJ1ZmZlciBoYXJkd2FyZSBkcml2 ZXJzCiMKIyBDT05GSUdfRkJfQ0lSUlVTIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUE0yIGlzIG5v dCBzZXQKIyBDT05GSUdfRkJfQ1lCRVIyMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVJDIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfQVNJTElBTlQgaXMgbm90IHNldAojIENPTkZJR19GQl9JTVNU VCBpcyBub3Qgc2V0CkNPTkZJR19GQl9WR0ExNj1tCiMgQ09ORklHX0ZCX1VWRVNBIGlzIG5vdCBz ZXQKQ09ORklHX0ZCX1ZFU0E9eQpDT05GSUdfRkJfRUZJPXkKIyBDT05GSUdfRkJfTjQxMSBpcyBu b3Qgc2V0CiMgQ09ORklHX0ZCX0hHQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1MxRDEzWFhYIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfTlZJRElBIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUklWQSBp cyBub3Qgc2V0CiMgQ09ORklHX0ZCX0k3NDAgaXMgbm90IHNldAojIENPTkZJR19GQl9MRTgwNTc4 IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTUFUUk9YIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUkFE RU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVRZMTI4IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf QVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUzMgaXMgbm90IHNldAojIENPTkZJR19GQl9TQVZB R0UgaXMgbm90IHNldAojIENPTkZJR19GQl9TSVMgaXMgbm90IHNldAojIENPTkZJR19GQl9WSUEg aXMgbm90IHNldAojIENPTkZJR19GQl9ORU9NQUdJQyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0tZ Uk8gaXMgbm90IHNldAojIENPTkZJR19GQl8zREZYIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1ZPT0RP TzE9bQojIENPTkZJR19GQl9WVDg2MjMgaXMgbm90IHNldAojIENPTkZJR19GQl9UUklERU5UIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUE0zIGlzIG5v dCBzZXQKIyBDT05GSUdfRkJfQ0FSTUlORSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0dFT0RFIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfVE1JTyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1NNNTAxIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfU01TQ1VGWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1VETCBp cyBub3Qgc2V0CkNPTkZJR19GQl9WSVJUVUFMPW0KQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD15 CiMgQ09ORklHX0ZCX01FVFJPTk9NRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01CODYyWFggaXMg bm90IHNldAojIENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVVP X0sxOTBYIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhZTk9TX1ZJREVPIGlzIG5vdCBzZXQKQ09ORklH X0JBQ0tMSUdIVF9MQ0RfU1VQUE9SVD15CkNPTkZJR19MQ0RfQ0xBU1NfREVWSUNFPW0KQ09ORklH X0xDRF9QTEFURk9STT1tCkNPTkZJR19CQUNLTElHSFRfQ0xBU1NfREVWSUNFPXkKIyBDT05GSUdf QkFDS0xJR0hUX0dFTkVSSUMgaXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX1BST0dFQVI9bQpD T05GSUdfQkFDS0xJR0hUX0FQUExFPW0KIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFSQSBpcyBub3Qg c2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJ R0hUX0FEUDg4NzAgaXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX0xQODU1WD1tCgojCiMgQ29u c29sZSBkaXNwbGF5IGRyaXZlciBzdXBwb3J0CiMKQ09ORklHX1ZHQV9DT05TT0xFPXkKQ09ORklH X1ZHQUNPTl9TT0ZUX1NDUk9MTEJBQ0s9eQpDT05GSUdfVkdBQ09OX1NPRlRfU0NST0xMQkFDS19T SVpFPTY0CkNPTkZJR19EVU1NWV9DT05TT0xFPXkKQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNPTEU9 eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRV9ERVRFQ1RfUFJJTUFSWT15CkNPTkZJR19GUkFN RUJVRkZFUl9DT05TT0xFX1JPVEFUSU9OPXkKIyBDT05GSUdfRk9OVFMgaXMgbm90IHNldApDT05G SUdfRk9OVF84eDg9eQpDT05GSUdfRk9OVF84eDE2PXkKQ09ORklHX0xPR089eQojIENPTkZJR19M T0dPX0xJTlVYX01PTk8gaXMgbm90IHNldAojIENPTkZJR19MT0dPX0xJTlVYX1ZHQTE2IGlzIG5v dCBzZXQKQ09ORklHX0xPR09fTElOVVhfQ0xVVDIyND15CkNPTkZJR19TT1VORD1tCkNPTkZJR19T T1VORF9PU1NfQ09SRT15CkNPTkZJR19TT1VORF9PU1NfQ09SRV9QUkVDTEFJTT15CkNPTkZJR19T TkQ9bQpDT05GSUdfU05EX1RJTUVSPW0KQ09ORklHX1NORF9QQ009bQpDT05GSUdfU05EX0hXREVQ PW0KQ09ORklHX1NORF9SQVdNSURJPW0KQ09ORklHX1NORF9KQUNLPXkKQ09ORklHX1NORF9TRVFV RU5DRVI9bQpDT05GSUdfU05EX1NFUV9EVU1NWT1tCkNPTkZJR19TTkRfT1NTRU1VTD15CkNPTkZJ R19TTkRfTUlYRVJfT1NTPW0KQ09ORklHX1NORF9QQ01fT1NTPW0KQ09ORklHX1NORF9QQ01fT1NT X1BMVUdJTlM9eQpDT05GSUdfU05EX1NFUVVFTkNFUl9PU1M9eQpDT05GSUdfU05EX0hSVElNRVI9 bQpDT05GSUdfU05EX1NFUV9IUlRJTUVSX0RFRkFVTFQ9eQpDT05GSUdfU05EX0RZTkFNSUNfTUlO T1JTPXkKIyBDT05GSUdfU05EX1NVUFBPUlRfT0xEX0FQSSBpcyBub3Qgc2V0CkNPTkZJR19TTkRf VkVSQk9TRV9QUk9DRlM9eQpDT05GSUdfU05EX1ZFUkJPU0VfUFJJTlRLPXkKQ09ORklHX1NORF9E RUJVRz15CiMgQ09ORklHX1NORF9ERUJVR19WRVJCT1NFIGlzIG5vdCBzZXQKQ09ORklHX1NORF9Q Q01fWFJVTl9ERUJVRz15CkNPTkZJR19TTkRfVk1BU1RFUj15CkNPTkZJR19TTkRfS0NUTF9KQUNL PXkKQ09ORklHX1NORF9ETUFfU0dCVUY9eQpDT05GSUdfU05EX1JBV01JRElfU0VRPW0KQ09ORklH X1NORF9PUEwzX0xJQl9TRVE9bQojIENPTkZJR19TTkRfT1BMNF9MSUJfU0VRIGlzIG5vdCBzZXQK IyBDT05GSUdfU05EX1NCQVdFX1NFUSBpcyBub3Qgc2V0CkNPTkZJR19TTkRfRU1VMTBLMV9TRVE9 bQpDT05GSUdfU05EX01QVTQwMV9VQVJUPW0KQ09ORklHX1NORF9PUEwzX0xJQj1tCkNPTkZJR19T TkRfVlhfTElCPW0KQ09ORklHX1NORF9BQzk3X0NPREVDPW0KQ09ORklHX1NORF9EUklWRVJTPXkK Q09ORklHX1NORF9QQ1NQPW0KQ09ORklHX1NORF9EVU1NWT1tCkNPTkZJR19TTkRfQUxPT1A9bQpD T05GSUdfU05EX1ZJUk1JREk9bQpDT05GSUdfU05EX01UUEFWPW0KQ09ORklHX1NORF9NVFM2ND1t CkNPTkZJR19TTkRfU0VSSUFMX1UxNjU1MD1tCkNPTkZJR19TTkRfTVBVNDAxPW0KQ09ORklHX1NO RF9QT1JUTUFOMlg0PW0KQ09ORklHX1NORF9BQzk3X1BPV0VSX1NBVkU9eQpDT05GSUdfU05EX0FD OTdfUE9XRVJfU0FWRV9ERUZBVUxUPTAKQ09ORklHX1NORF9TQl9DT01NT049bQpDT05GSUdfU05E X1NCMTZfRFNQPW0KQ09ORklHX1NORF9URUE1NzVYPW0KQ09ORklHX1NORF9QQ0k9eQpDT05GSUdf U05EX0FEMTg4OT1tCkNPTkZJR19TTkRfQUxTMzAwPW0KQ09ORklHX1NORF9BTFM0MDAwPW0KQ09O RklHX1NORF9BTEk1NDUxPW0KQ09ORklHX1NORF9BU0lIUEk9bQpDT05GSUdfU05EX0FUSUlYUD1t CkNPTkZJR19TTkRfQVRJSVhQX01PREVNPW0KQ09ORklHX1NORF9BVTg4MTA9bQpDT05GSUdfU05E X0FVODgyMD1tCkNPTkZJR19TTkRfQVU4ODMwPW0KIyBDT05GSUdfU05EX0FXMiBpcyBub3Qgc2V0 CkNPTkZJR19TTkRfQVpUMzMyOD1tCkNPTkZJR19TTkRfQlQ4N1g9bQojIENPTkZJR19TTkRfQlQ4 N1hfT1ZFUkNMT0NLIGlzIG5vdCBzZXQKQ09ORklHX1NORF9DQTAxMDY9bQpDT05GSUdfU05EX0NN SVBDST1tCkNPTkZJR19TTkRfT1hZR0VOX0xJQj1tCkNPTkZJR19TTkRfT1hZR0VOPW0KQ09ORklH X1NORF9DUzQyODE9bQpDT05GSUdfU05EX0NTNDZYWD1tCkNPTkZJR19TTkRfQ1M0NlhYX05FV19E U1A9eQpDT05GSUdfU05EX0NTNTUzMD1tCkNPTkZJR19TTkRfQ1M1NTM1QVVESU89bQpDT05GSUdf U05EX0NUWEZJPW0KQ09ORklHX1NORF9EQVJMQTIwPW0KQ09ORklHX1NORF9HSU5BMjA9bQpDT05G SUdfU05EX0xBWUxBMjA9bQpDT05GSUdfU05EX0RBUkxBMjQ9bQpDT05GSUdfU05EX0dJTkEyND1t CkNPTkZJR19TTkRfTEFZTEEyND1tCkNPTkZJR19TTkRfTU9OQT1tCkNPTkZJR19TTkRfTUlBPW0K Q09ORklHX1NORF9FQ0hPM0c9bQpDT05GSUdfU05EX0lORElHTz1tCkNPTkZJR19TTkRfSU5ESUdP SU89bQpDT05GSUdfU05EX0lORElHT0RKPW0KQ09ORklHX1NORF9JTkRJR09JT1g9bQpDT05GSUdf U05EX0lORElHT0RKWD1tCkNPTkZJR19TTkRfRU1VMTBLMT1tCkNPTkZJR19TTkRfRU1VMTBLMVg9 bQpDT05GSUdfU05EX0VOUzEzNzA9bQpDT05GSUdfU05EX0VOUzEzNzE9bQpDT05GSUdfU05EX0VT MTkzOD1tCkNPTkZJR19TTkRfRVMxOTY4PW0KQ09ORklHX1NORF9FUzE5NjhfSU5QVVQ9eQpDT05G SUdfU05EX0VTMTk2OF9SQURJTz15CkNPTkZJR19TTkRfRk04MDE9bQpDT05GSUdfU05EX0ZNODAx X1RFQTU3NVhfQk9PTD15CkNPTkZJR19TTkRfSERBX0lOVEVMPW0KQ09ORklHX1NORF9IREFfUFJF QUxMT0NfU0laRT00MDk2CkNPTkZJR19TTkRfSERBX0hXREVQPXkKQ09ORklHX1NORF9IREFfUkVD T05GSUc9eQpDT05GSUdfU05EX0hEQV9JTlBVVF9CRUVQPXkKQ09ORklHX1NORF9IREFfSU5QVVRf QkVFUF9NT0RFPTAKQ09ORklHX1NORF9IREFfSU5QVVRfSkFDSz15CkNPTkZJR19TTkRfSERBX1BB VENIX0xPQURFUj15CkNPTkZJR19TTkRfSERBX0NPREVDX1JFQUxURUs9eQpDT05GSUdfU05EX0hE QV9DT0RFQ19BTkFMT0c9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19TSUdNQVRFTD15CkNPTkZJR19T TkRfSERBX0NPREVDX1ZJQT15CkNPTkZJR19TTkRfSERBX0NPREVDX0hETUk9eQpDT05GSUdfU05E X0hEQV9DT0RFQ19DSVJSVVM9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19DT05FWEFOVD15CkNPTkZJ R19TTkRfSERBX0NPREVDX0NBMDExMD15CkNPTkZJR19TTkRfSERBX0NPREVDX0NBMDEzMj15CkNP TkZJR19TTkRfSERBX0NPREVDX0NNRURJQT15CkNPTkZJR19TTkRfSERBX0NPREVDX1NJMzA1ND15 CkNPTkZJR19TTkRfSERBX0dFTkVSSUM9eQpDT05GSUdfU05EX0hEQV9QT1dFUl9TQVZFPXkKQ09O RklHX1NORF9IREFfUE9XRVJfU0FWRV9ERUZBVUxUPTAKQ09ORklHX1NORF9IRFNQPW0KQ09ORklH X1NORF9IRFNQTT1tCkNPTkZJR19TTkRfSUNFMTcxMj1tCkNPTkZJR19TTkRfSUNFMTcyND1tCkNP TkZJR19TTkRfSU5URUw4WDA9bQpDT05GSUdfU05EX0lOVEVMOFgwTT1tCkNPTkZJR19TTkRfS09S RzEyMTI9bQpDT05GSUdfU05EX0xPTEE9bQpDT05GSUdfU05EX0xYNjQ2NEVTPW0KQ09ORklHX1NO RF9NQUVTVFJPMz1tCkNPTkZJR19TTkRfTUFFU1RSTzNfSU5QVVQ9eQpDT05GSUdfU05EX01JWEFS VD1tCkNPTkZJR19TTkRfTk0yNTY9bQpDT05GSUdfU05EX1BDWEhSPW0KQ09ORklHX1NORF9SSVBU SURFPW0KQ09ORklHX1NORF9STUUzMj1tCkNPTkZJR19TTkRfUk1FOTY9bQpDT05GSUdfU05EX1JN RTk2NTI9bQpDT05GSUdfU05EX1NPTklDVklCRVM9bQpDT05GSUdfU05EX1RSSURFTlQ9bQpDT05G SUdfU05EX1ZJQTgyWFg9bQpDT05GSUdfU05EX1ZJQTgyWFhfTU9ERU09bQpDT05GSUdfU05EX1ZJ UlRVT1NPPW0KQ09ORklHX1NORF9WWDIyMj1tCkNPTkZJR19TTkRfWU1GUENJPW0KQ09ORklHX1NO RF9VU0I9eQpDT05GSUdfU05EX1VTQl9BVURJTz1tCkNPTkZJR19TTkRfVVNCX1VBMTAxPW0KQ09O RklHX1NORF9VU0JfVVNYMlk9bQpDT05GSUdfU05EX1VTQl9DQUlBUT1tCkNPTkZJR19TTkRfVVNC X0NBSUFRX0lOUFVUPXkKQ09ORklHX1NORF9VU0JfVVMxMjJMPW0KQ09ORklHX1NORF9VU0JfNkZJ UkU9bQpDT05GSUdfU05EX0ZJUkVXSVJFPXkKQ09ORklHX1NORF9GSVJFV0lSRV9MSUI9bQpDT05G SUdfU05EX0ZJUkVXSVJFX1NQRUFLRVJTPW0KQ09ORklHX1NORF9JU0lHSFQ9bQojIENPTkZJR19T TkRfUENNQ0lBIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQyBpcyBub3Qgc2V0CiMgQ09ORklH X1NPVU5EX1BSSU1FIGlzIG5vdCBzZXQKQ09ORklHX0FDOTdfQlVTPW0KCiMKIyBISUQgc3VwcG9y dAojCkNPTkZJR19ISUQ9eQpDT05GSUdfSElEX0JBVFRFUllfU1RSRU5HVEg9eQpDT05GSUdfSElE UkFXPXkKQ09ORklHX1VISUQ9bQpDT05GSUdfSElEX0dFTkVSSUM9eQoKIwojIFNwZWNpYWwgSElE IGRyaXZlcnMKIwpDT05GSUdfSElEX0E0VEVDSD15CkNPTkZJR19ISURfQUNSVVg9bQpDT05GSUdf SElEX0FDUlVYX0ZGPXkKQ09ORklHX0hJRF9BUFBMRT15CkNPTkZJR19ISURfQVVSRUFMPW0KQ09O RklHX0hJRF9CRUxLSU49eQpDT05GSUdfSElEX0NIRVJSWT15CkNPTkZJR19ISURfQ0hJQ09OWT15 CkNPTkZJR19ISURfUFJPRElLRVlTPW0KQ09ORklHX0hJRF9DWVBSRVNTPXkKQ09ORklHX0hJRF9E UkFHT05SSVNFPW0KQ09ORklHX0RSQUdPTlJJU0VfRkY9eQpDT05GSUdfSElEX0VNU19GRj1tCkNP TkZJR19ISURfRUxFQ09NPW0KQ09ORklHX0hJRF9FWktFWT15CkNPTkZJR19ISURfSE9MVEVLPW0K Q09ORklHX0hPTFRFS19GRj15CkNPTkZJR19ISURfS0VZVE9VQ0g9bQpDT05GSUdfSElEX0tZRT1t CkNPTkZJR19ISURfVUNMT0dJQz1tCkNPTkZJR19ISURfV0FMVE9QPW0KQ09ORklHX0hJRF9HWVJB VElPTj1tCkNPTkZJR19ISURfVFdJTkhBTj1tCkNPTkZJR19ISURfS0VOU0lOR1RPTj15CkNPTkZJ R19ISURfTENQT1dFUj1tCkNPTkZJR19ISURfTEVOT1ZPX1RQS0JEPW0KQ09ORklHX0hJRF9MT0dJ VEVDSD15CkNPTkZJR19ISURfTE9HSVRFQ0hfREo9bQpDT05GSUdfTE9HSVRFQ0hfRkY9eQpDT05G SUdfTE9HSVJVTUJMRVBBRDJfRkY9eQpDT05GSUdfTE9HSUc5NDBfRkY9eQpDT05GSUdfTE9HSVdI RUVMU19GRj15CkNPTkZJR19ISURfTUFHSUNNT1VTRT1tCkNPTkZJR19ISURfTUlDUk9TT0ZUPXkK Q09ORklHX0hJRF9NT05URVJFWT15CkNPTkZJR19ISURfTVVMVElUT1VDSD1tCkNPTkZJR19ISURf TlRSSUc9eQpDT05GSUdfSElEX09SVEVLPW0KQ09ORklHX0hJRF9QQU5USEVSTE9SRD1tCkNPTkZJ R19QQU5USEVSTE9SRF9GRj15CkNPTkZJR19ISURfUEVUQUxZTlg9bQpDT05GSUdfSElEX1BJQ09M Q0Q9bQpDT05GSUdfSElEX1BJQ09MQ0RfRkI9eQpDT05GSUdfSElEX1BJQ09MQ0RfQkFDS0xJR0hU PXkKQ09ORklHX0hJRF9QSUNPTENEX0xDRD15CkNPTkZJR19ISURfUElDT0xDRF9MRURTPXkKQ09O RklHX0hJRF9QUklNQVg9bQpDT05GSUdfSElEX1JPQ0NBVD1tCkNPTkZJR19ISURfU0FJVEVLPW0K Q09ORklHX0hJRF9TQU1TVU5HPW0KQ09ORklHX0hJRF9TT05ZPW0KQ09ORklHX0hJRF9TUEVFRExJ Tks9bQpDT05GSUdfSElEX1NVTlBMVVM9bQpDT05GSUdfSElEX0dSRUVOQVNJQT1tCkNPTkZJR19H UkVFTkFTSUFfRkY9eQpDT05GSUdfSElEX0hZUEVSVl9NT1VTRT1tCkNPTkZJR19ISURfU01BUlRK T1lQTFVTPW0KQ09ORklHX1NNQVJUSk9ZUExVU19GRj15CkNPTkZJR19ISURfVElWTz1tCkNPTkZJ R19ISURfVE9QU0VFRD1tCkNPTkZJR19ISURfVEhSVVNUTUFTVEVSPW0KQ09ORklHX1RIUlVTVE1B U1RFUl9GRj15CkNPTkZJR19ISURfV0FDT009bQpDT05GSUdfSElEX1dJSU1PVEU9bQpDT05GSUdf SElEX1dJSU1PVEVfRVhUPXkKQ09ORklHX0hJRF9aRVJPUExVUz1tCkNPTkZJR19aRVJPUExVU19G Rj15CkNPTkZJR19ISURfWllEQUNST049bQoKIwojIFVTQiBISUQgc3VwcG9ydAojCkNPTkZJR19V U0JfSElEPXkKQ09ORklHX0hJRF9QSUQ9eQpDT05GSUdfVVNCX0hJRERFVj15CkNPTkZJR19VU0Jf QVJDSF9IQVNfT0hDST15CkNPTkZJR19VU0JfQVJDSF9IQVNfRUhDST15CkNPTkZJR19VU0JfQVJD SF9IQVNfWEhDST15CkNPTkZJR19VU0JfU1VQUE9SVD15CkNPTkZJR19VU0JfQ09NTU9OPXkKQ09O RklHX1VTQl9BUkNIX0hBU19IQ0Q9eQpDT05GSUdfVVNCPXkKIyBDT05GSUdfVVNCX0RFQlVHIGlz IG5vdCBzZXQKQ09ORklHX1VTQl9BTk5PVU5DRV9ORVdfREVWSUNFUz15CgojCiMgTWlzY2VsbGFu ZW91cyBVU0Igb3B0aW9ucwojCiMgQ09ORklHX1VTQl9EWU5BTUlDX01JTk9SUyBpcyBub3Qgc2V0 CkNPTkZJR19VU0JfU1VTUEVORD15CiMgQ09ORklHX1VTQl9PVEcgaXMgbm90IHNldApDT05GSUdf VVNCX01PTj15CkNPTkZJR19VU0JfV1VTQj1tCkNPTkZJR19VU0JfV1VTQl9DQkFGPW0KIyBDT05G SUdfVVNCX1dVU0JfQ0JBRl9ERUJVRyBpcyBub3Qgc2V0CgojCiMgVVNCIEhvc3QgQ29udHJvbGxl ciBEcml2ZXJzCiMKIyBDT05GSUdfVVNCX0M2N1gwMF9IQ0QgaXMgbm90IHNldApDT05GSUdfVVNC X1hIQ0lfSENEPXkKIyBDT05GSUdfVVNCX1hIQ0lfSENEX0RFQlVHR0lORyBpcyBub3Qgc2V0CkNP TkZJR19VU0JfRUhDSV9IQ0Q9eQpDT05GSUdfVVNCX0VIQ0lfUk9PVF9IVUJfVFQ9eQpDT05GSUdf VVNCX0VIQ0lfVFRfTkVXU0NIRUQ9eQojIENPTkZJR19VU0JfT1hVMjEwSFBfSENEIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0lTUDExNlhfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0lTUDE3 NjBfSENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9JU1AxMzYyX0hDRD1tCkNPTkZJR19VU0JfT0hD SV9IQ0Q9eQojIENPTkZJR19VU0JfT0hDSV9IQ0RfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJ R19VU0JfRUhDSV9IQ0RfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJR19VU0JfT0hDSV9CSUdf RU5ESUFOX0RFU0MgaXMgbm90IHNldAojIENPTkZJR19VU0JfT0hDSV9CSUdfRU5ESUFOX01NSU8g aXMgbm90IHNldApDT05GSUdfVVNCX09IQ0lfTElUVExFX0VORElBTj15CkNPTkZJR19VU0JfVUhD SV9IQ0Q9eQpDT05GSUdfVVNCX1UxMzJfSENEPW0KQ09ORklHX1VTQl9TTDgxMV9IQ0Q9bQpDT05G SUdfVVNCX1NMODExX0hDRF9JU089eQojIENPTkZJR19VU0JfU0w4MTFfQ1MgaXMgbm90IHNldAoj IENPTkZJR19VU0JfUjhBNjY1OTdfSENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9XSENJX0hDRD1t CkNPTkZJR19VU0JfSFdBX0hDRD1tCiMgQ09ORklHX1VTQl9IQ0RfQkNNQSBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9IQ0RfU1NCIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0NISVBJREVBIGlzIG5v dCBzZXQKCiMKIyBVU0IgRGV2aWNlIENsYXNzIGRyaXZlcnMKIwpDT05GSUdfVVNCX0FDTT1tCkNP TkZJR19VU0JfUFJJTlRFUj1tCkNPTkZJR19VU0JfV0RNPW0KQ09ORklHX1VTQl9UTUM9bQoKIwoj IE5PVEU6IFVTQl9TVE9SQUdFIGRlcGVuZHMgb24gU0NTSSBidXQgQkxLX0RFVl9TRCBtYXkKIwoK IwojIGFsc28gYmUgbmVlZGVkOyBzZWUgVVNCX1NUT1JBR0UgSGVscCBmb3IgbW9yZSBpbmZvCiMK Q09ORklHX1VTQl9TVE9SQUdFPW0KIyBDT05GSUdfVVNCX1NUT1JBR0VfREVCVUcgaXMgbm90IHNl dApDT05GSUdfVVNCX1NUT1JBR0VfUkVBTFRFSz1tCkNPTkZJR19SRUFMVEVLX0FVVE9QTT15CkNP TkZJR19VU0JfU1RPUkFHRV9EQVRBRkFCPW0KQ09ORklHX1VTQl9TVE9SQUdFX0ZSRUVDT009bQpD T05GSUdfVVNCX1NUT1JBR0VfSVNEMjAwPW0KQ09ORklHX1VTQl9TVE9SQUdFX1VTQkFUPW0KQ09O RklHX1VTQl9TVE9SQUdFX1NERFIwOT1tCkNPTkZJR19VU0JfU1RPUkFHRV9TRERSNTU9bQpDT05G SUdfVVNCX1NUT1JBR0VfSlVNUFNIT1Q9bQpDT05GSUdfVVNCX1NUT1JBR0VfQUxBVURBPW0KQ09O RklHX1VTQl9TVE9SQUdFX09ORVRPVUNIPW0KQ09ORklHX1VTQl9TVE9SQUdFX0tBUk1BPW0KQ09O RklHX1VTQl9TVE9SQUdFX0NZUFJFU1NfQVRBQ0I9bQpDT05GSUdfVVNCX1NUT1JBR0VfRU5FX1VC NjI1MD1tCiMgQ09ORklHX1VTQl9VQVMgaXMgbm90IHNldAojIENPTkZJR19VU0JfTElCVVNVQUwg aXMgbm90IHNldAoKIwojIFVTQiBJbWFnaW5nIGRldmljZXMKIwpDT05GSUdfVVNCX01EQzgwMD1t CkNPTkZJR19VU0JfTUlDUk9URUs9bQoKIwojIFVTQiBwb3J0IGRyaXZlcnMKIwpDT05GSUdfVVNC X1VTUzcyMD1tCkNPTkZJR19VU0JfU0VSSUFMPXkKQ09ORklHX1VTQl9TRVJJQUxfQ09OU09MRT15 CkNPTkZJR19VU0JfRVpVU0I9eQpDT05GSUdfVVNCX1NFUklBTF9HRU5FUklDPXkKQ09ORklHX1VT Ql9TRVJJQUxfQUlSQ0FCTEU9bQpDT05GSUdfVVNCX1NFUklBTF9BUkszMTE2PW0KQ09ORklHX1VT Ql9TRVJJQUxfQkVMS0lOPW0KQ09ORklHX1VTQl9TRVJJQUxfQ0gzNDE9bQpDT05GSUdfVVNCX1NF UklBTF9XSElURUhFQVQ9bQpDT05GSUdfVVNCX1NFUklBTF9ESUdJX0FDQ0VMRVBPUlQ9bQpDT05G SUdfVVNCX1NFUklBTF9DUDIxMFg9bQpDT05GSUdfVVNCX1NFUklBTF9DWVBSRVNTX004PW0KQ09O RklHX1VTQl9TRVJJQUxfRU1QRUc9bQpDT05GSUdfVVNCX1NFUklBTF9GVERJX1NJTz1tCkNPTkZJ R19VU0JfU0VSSUFMX0ZVTlNPRlQ9bQpDT05GSUdfVVNCX1NFUklBTF9WSVNPUj1tCkNPTkZJR19V U0JfU0VSSUFMX0lQQVE9bQpDT05GSUdfVVNCX1NFUklBTF9JUj1tCkNPTkZJR19VU0JfU0VSSUFM X0VER0VQT1JUPW0KQ09ORklHX1VTQl9TRVJJQUxfRURHRVBPUlRfVEk9bQojIENPTkZJR19VU0Jf U0VSSUFMX0Y4MTIzMiBpcyBub3Qgc2V0CkNPTkZJR19VU0JfU0VSSUFMX0dBUk1JTj1tCkNPTkZJ R19VU0JfU0VSSUFMX0lQVz1tCkNPTkZJR19VU0JfU0VSSUFMX0lVVT1tCkNPTkZJR19VU0JfU0VS SUFMX0tFWVNQQU5fUERBPW0KQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTj1tCkNPTkZJR19VU0Jf U0VSSUFMX0tMU0k9bQpDT05GSUdfVVNCX1NFUklBTF9LT0JJTF9TQ1Q9bQpDT05GSUdfVVNCX1NF UklBTF9NQ1RfVTIzMj1tCiMgQ09ORklHX1VTQl9TRVJJQUxfTUVUUk8gaXMgbm90IHNldApDT05G SUdfVVNCX1NFUklBTF9NT1M3NzIwPW0KQ09ORklHX1VTQl9TRVJJQUxfTU9TNzcxNV9QQVJQT1JU PXkKQ09ORklHX1VTQl9TRVJJQUxfTU9TNzg0MD1tCkNPTkZJR19VU0JfU0VSSUFMX01PVE9ST0xB PW0KQ09ORklHX1VTQl9TRVJJQUxfTkFWTUFOPW0KQ09ORklHX1VTQl9TRVJJQUxfUEwyMzAzPW0K Q09ORklHX1VTQl9TRVJJQUxfT1RJNjg1OD1tCkNPTkZJR19VU0JfU0VSSUFMX1FDQVVYPW0KQ09O RklHX1VTQl9TRVJJQUxfUVVBTENPTU09bQpDT05GSUdfVVNCX1NFUklBTF9TUENQOFg1PW0KQ09O RklHX1VTQl9TRVJJQUxfSFA0WD1tCkNPTkZJR19VU0JfU0VSSUFMX1NBRkU9bQpDT05GSUdfVVNC X1NFUklBTF9TQUZFX1BBRERFRD15CkNPTkZJR19VU0JfU0VSSUFMX1NJRU1FTlNfTVBJPW0KQ09O RklHX1VTQl9TRVJJQUxfU0lFUlJBV0lSRUxFU1M9bQpDT05GSUdfVVNCX1NFUklBTF9TWU1CT0w9 bQpDT05GSUdfVVNCX1NFUklBTF9UST1tCkNPTkZJR19VU0JfU0VSSUFMX0NZQkVSSkFDSz1tCkNP TkZJR19VU0JfU0VSSUFMX1hJUkNPTT1tCkNPTkZJR19VU0JfU0VSSUFMX1dXQU49bQpDT05GSUdf VVNCX1NFUklBTF9PUFRJT049bQpDT05GSUdfVVNCX1NFUklBTF9PTU5JTkVUPW0KQ09ORklHX1VT Ql9TRVJJQUxfT1BUSUNPTj1tCkNPTkZJR19VU0JfU0VSSUFMX1ZJVk9QQVlfU0VSSUFMPW0KIyBD T05GSUdfVVNCX1NFUklBTF9aSU8gaXMgbm90IHNldApDT05GSUdfVVNCX1NFUklBTF9TU1UxMDA9 bQpDT05GSUdfVVNCX1NFUklBTF9RVDI9bQpDT05GSUdfVVNCX1NFUklBTF9ERUJVRz1tCgojCiMg VVNCIE1pc2NlbGxhbmVvdXMgZHJpdmVycwojCkNPTkZJR19VU0JfRU1JNjI9bQpDT05GSUdfVVNC X0VNSTI2PW0KQ09ORklHX1VTQl9BRFVUVVg9bQpDT05GSUdfVVNCX1NFVlNFRz1tCiMgQ09ORklH X1VTQl9SSU81MDAgaXMgbm90IHNldApDT05GSUdfVVNCX0xFR09UT1dFUj1tCkNPTkZJR19VU0Jf TENEPW0KQ09ORklHX1VTQl9MRUQ9bQojIENPTkZJR19VU0JfQ1lQUkVTU19DWTdDNjMgaXMgbm90 IHNldAojIENPTkZJR19VU0JfQ1lUSEVSTSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfSURNT1VTRT1t CkNPTkZJR19VU0JfRlRESV9FTEFOPW0KQ09ORklHX1VTQl9BUFBMRURJU1BMQVk9bQpDT05GSUdf VVNCX1NJU1VTQlZHQT1tCkNPTkZJR19VU0JfU0lTVVNCVkdBX0NPTj15CkNPTkZJR19VU0JfTEQ9 bQpDT05GSUdfVVNCX1RSQU5DRVZJQlJBVE9SPW0KQ09ORklHX1VTQl9JT1dBUlJJT1I9bQojIENP TkZJR19VU0JfVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfSVNJR0hURlc9bQpDT05GSUdfVVNC X1lVUkVYPW0KCiMKIyBVU0IgUGh5c2ljYWwgTGF5ZXIgZHJpdmVycwojCiMgQ09ORklHX1VTQl9J U1AxMzAxIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9BVE09bQpDT05GSUdfVVNCX1NQRUVEVE9VQ0g9 bQpDT05GSUdfVVNCX0NYQUNSVT1tCkNPTkZJR19VU0JfVUVBR0xFQVRNPW0KQ09ORklHX1VTQl9Y VVNCQVRNPW0KIyBDT05GSUdfVVNCX0dBREdFVCBpcyBub3Qgc2V0CgojCiMgT1RHIGFuZCByZWxh dGVkIGluZnJhc3RydWN0dXJlCiMKQ09ORklHX1VTQl9PVEdfVVRJTFM9eQpDT05GSUdfTk9QX1VT Ql9YQ0VJVj1tCkNPTkZJR19VV0I9bQpDT05GSUdfVVdCX0hXQT1tCkNPTkZJR19VV0JfV0hDST1t CkNPTkZJR19VV0JfSTE0ODBVPW0KQ09ORklHX01NQz1tCiMgQ09ORklHX01NQ19ERUJVRyBpcyBu b3Qgc2V0CiMgQ09ORklHX01NQ19VTlNBRkVfUkVTVU1FIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1D X0NMS0dBVEUgaXMgbm90IHNldAoKIwojIE1NQy9TRC9TRElPIENhcmQgRHJpdmVycwojCkNPTkZJ R19NTUNfQkxPQ0s9bQpDT05GSUdfTU1DX0JMT0NLX01JTk9SUz04CkNPTkZJR19NTUNfQkxPQ0tf Qk9VTkNFPXkKQ09ORklHX1NESU9fVUFSVD1tCiMgQ09ORklHX01NQ19URVNUIGlzIG5vdCBzZXQK CiMKIyBNTUMvU0QvU0RJTyBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCkNPTkZJR19NTUNfU0RI Q0k9bQpDT05GSUdfTU1DX1NESENJX1BDST1tCkNPTkZJR19NTUNfUklDT0hfTU1DPXkKQ09ORklH X01NQ19TREhDSV9QTFRGTT1tCkNPTkZJR19NTUNfV0JTRD1tCkNPTkZJR19NTUNfVElGTV9TRD1t CkNPTkZJR19NTUNfU0RSSUNPSF9DUz1tCkNPTkZJR19NTUNfQ0I3MTA9bQpDT05GSUdfTU1DX1ZJ QV9TRE1NQz1tCkNPTkZJR19NTUNfVlVCMzAwPW0KQ09ORklHX01NQ19VU0hDPW0KQ09ORklHX01F TVNUSUNLPW0KIyBDT05GSUdfTUVNU1RJQ0tfREVCVUcgaXMgbm90IHNldAoKIwojIE1lbW9yeVN0 aWNrIGRyaXZlcnMKIwojIENPTkZJR19NRU1TVElDS19VTlNBRkVfUkVTVU1FIGlzIG5vdCBzZXQK Q09ORklHX01TUFJPX0JMT0NLPW0KCiMKIyBNZW1vcnlTdGljayBIb3N0IENvbnRyb2xsZXIgRHJp dmVycwojCkNPTkZJR19NRU1TVElDS19USUZNX01TPW0KQ09ORklHX01FTVNUSUNLX0pNSUNST05f MzhYPW0KQ09ORklHX01FTVNUSUNLX1I1OTI9bQpDT05GSUdfTkVXX0xFRFM9eQpDT05GSUdfTEVE U19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwpDT05GSUdfTEVEU19MTTM1MzA9bQojIENPTkZJ R19MRURTX1BDQTk1MzIgaXMgbm90IHNldApDT05GSUdfTEVEU19MUDM5NDQ9bQpDT05GSUdfTEVE U19MUDU1MjE9bQpDT05GSUdfTEVEU19MUDU1MjM9bQpDT05GSUdfTEVEU19DTEVWT19NQUlMPW0K IyBDT05GSUdfTEVEU19QQ0E5NTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19QQ0E5NjMzIGlz IG5vdCBzZXQKIyBDT05GSUdfTEVEU19CRDI4MDIgaXMgbm90IHNldApDT05GSUdfTEVEU19JTlRF TF9TUzQyMDA9bQpDT05GSUdfTEVEU19ERUxMX05FVEJPT0tTPW0KIyBDT05GSUdfTEVEU19UQ0E2 NTA3IGlzIG5vdCBzZXQKQ09ORklHX0xFRFNfTE0zNTU2PW0KIyBDT05GSUdfTEVEU19PVDIwMCBp cyBub3Qgc2V0CkNPTkZJR19MRURTX0JMSU5LTT1tCkNPTkZJR19MRURTX1RSSUdHRVJTPXkKCiMK IyBMRUQgVHJpZ2dlcnMKIwpDT05GSUdfTEVEU19UUklHR0VSX1RJTUVSPW0KQ09ORklHX0xFRFNf VFJJR0dFUl9PTkVTSE9UPW0KQ09ORklHX0xFRFNfVFJJR0dFUl9IRUFSVEJFQVQ9bQpDT05GSUdf TEVEU19UUklHR0VSX0JBQ0tMSUdIVD1tCkNPTkZJR19MRURTX1RSSUdHRVJfREVGQVVMVF9PTj1t CgojCiMgaXB0YWJsZXMgdHJpZ2dlciBpcyB1bmRlciBOZXRmaWx0ZXIgY29uZmlnIChMRUQgdGFy Z2V0KQojCkNPTkZJR19MRURTX1RSSUdHRVJfVFJBTlNJRU5UPW0KQ09ORklHX0FDQ0VTU0lCSUxJ VFk9eQpDT05GSUdfQTExWV9CUkFJTExFX0NPTlNPTEU9eQpDT05GSUdfSU5GSU5JQkFORD1tCkNP TkZJR19JTkZJTklCQU5EX1VTRVJfTUFEPW0KQ09ORklHX0lORklOSUJBTkRfVVNFUl9BQ0NFU1M9 bQpDT05GSUdfSU5GSU5JQkFORF9VU0VSX01FTT15CkNPTkZJR19JTkZJTklCQU5EX0FERFJfVFJB TlM9eQpDT05GSUdfSU5GSU5JQkFORF9NVEhDQT1tCkNPTkZJR19JTkZJTklCQU5EX01USENBX0RF QlVHPXkKQ09ORklHX0lORklOSUJBTkRfSVBBVEg9bQpDT05GSUdfSU5GSU5JQkFORF9RSUI9bQpD T05GSUdfSU5GSU5JQkFORF9BTVNPMTEwMD1tCiMgQ09ORklHX0lORklOSUJBTkRfQU1TTzExMDBf REVCVUcgaXMgbm90IHNldApDT05GSUdfSU5GSU5JQkFORF9DWEdCMz1tCiMgQ09ORklHX0lORklO SUJBTkRfQ1hHQjNfREVCVUcgaXMgbm90IHNldApDT05GSUdfSU5GSU5JQkFORF9DWEdCND1tCkNP TkZJR19NTFg0X0lORklOSUJBTkQ9bQpDT05GSUdfSU5GSU5JQkFORF9ORVM9bQojIENPTkZJR19J TkZJTklCQU5EX05FU19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0lORklOSUJBTkRfT0NSRE1B IGlzIG5vdCBzZXQKQ09ORklHX0lORklOSUJBTkRfSVBPSUI9bQpDT05GSUdfSU5GSU5JQkFORF9J UE9JQl9DTT15CkNPTkZJR19JTkZJTklCQU5EX0lQT0lCX0RFQlVHPXkKQ09ORklHX0lORklOSUJB TkRfSVBPSUJfREVCVUdfREFUQT15CkNPTkZJR19JTkZJTklCQU5EX1NSUD1tCkNPTkZJR19JTkZJ TklCQU5EX1NSUFQ9bQpDT05GSUdfSU5GSU5JQkFORF9JU0VSPW0KQ09ORklHX0VEQUM9eQoKIwoj IFJlcG9ydGluZyBzdWJzeXN0ZW1zCiMKQ09ORklHX0VEQUNfTEVHQUNZX1NZU0ZTPXkKIyBDT05G SUdfRURBQ19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19FREFDX0RFQ09ERV9NQ0U9bQpDT05GSUdf RURBQ19NQ0VfSU5KPW0KQ09ORklHX0VEQUNfTU1fRURBQz1tCkNPTkZJR19FREFDX0FNRDY0PW0K IyBDT05GSUdfRURBQ19BTUQ2NF9FUlJPUl9JTkpFQ1RJT04gaXMgbm90IHNldApDT05GSUdfRURB Q19FNzUyWD1tCkNPTkZJR19FREFDX0k4Mjk3NVg9bQpDT05GSUdfRURBQ19JMzAwMD1tCkNPTkZJ R19FREFDX0kzMjAwPW0KQ09ORklHX0VEQUNfWDM4PW0KQ09ORklHX0VEQUNfSTU0MDA9bQpDT05G SUdfRURBQ19JN0NPUkU9bQpDT05GSUdfRURBQ19JNTAwMD1tCkNPTkZJR19FREFDX0k1MTAwPW0K Q09ORklHX0VEQUNfSTczMDA9bQpDT05GSUdfRURBQ19TQlJJREdFPW0KQ09ORklHX1JUQ19MSUI9 eQpDT05GSUdfUlRDX0NMQVNTPXkKQ09ORklHX1JUQ19IQ1RPU1lTPXkKQ09ORklHX1JUQ19IQ1RP U1lTX0RFVklDRT0icnRjMCIKIyBDT05GSUdfUlRDX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBSVEMg aW50ZXJmYWNlcwojCkNPTkZJR19SVENfSU5URl9TWVNGUz15CkNPTkZJR19SVENfSU5URl9QUk9D PXkKQ09ORklHX1JUQ19JTlRGX0RFVj15CiMgQ09ORklHX1JUQ19JTlRGX0RFVl9VSUVfRU1VTCBp cyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfVEVTVCBpcyBub3Qgc2V0CgojCiMgSTJDIFJUQyBk cml2ZXJzCiMKQ09ORklHX1JUQ19EUlZfRFMxMzA3PW0KQ09ORklHX1JUQ19EUlZfRFMxMzc0PW0K Q09ORklHX1JUQ19EUlZfRFMxNjcyPW0KQ09ORklHX1JUQ19EUlZfRFMzMjMyPW0KQ09ORklHX1JU Q19EUlZfTUFYNjkwMD1tCkNPTkZJR19SVENfRFJWX1JTNUMzNzI9bQpDT05GSUdfUlRDX0RSVl9J U0wxMjA4PW0KQ09ORklHX1JUQ19EUlZfSVNMMTIwMjI9bQpDT05GSUdfUlRDX0RSVl9YMTIwNT1t CkNPTkZJR19SVENfRFJWX1BDRjg1NjM9bQpDT05GSUdfUlRDX0RSVl9QQ0Y4NTgzPW0KQ09ORklH X1JUQ19EUlZfTTQxVDgwPW0KQ09ORklHX1JUQ19EUlZfTTQxVDgwX1dEVD15CkNPTkZJR19SVENf RFJWX0JRMzJLPW0KIyBDT05GSUdfUlRDX0RSVl9TMzUzOTBBIGlzIG5vdCBzZXQKQ09ORklHX1JU Q19EUlZfRk0zMTMwPW0KQ09ORklHX1JUQ19EUlZfUlg4NTgxPW0KQ09ORklHX1JUQ19EUlZfUlg4 MDI1PW0KQ09ORklHX1JUQ19EUlZfRU0zMDI3PW0KQ09ORklHX1JUQ19EUlZfUlYzMDI5QzI9bQoK IwojIFNQSSBSVEMgZHJpdmVycwojCgojCiMgUGxhdGZvcm0gUlRDIGRyaXZlcnMKIwpDT05GSUdf UlRDX0RSVl9DTU9TPXkKQ09ORklHX1JUQ19EUlZfRFMxMjg2PW0KQ09ORklHX1JUQ19EUlZfRFMx NTExPW0KQ09ORklHX1JUQ19EUlZfRFMxNTUzPW0KQ09ORklHX1JUQ19EUlZfRFMxNzQyPW0KQ09O RklHX1JUQ19EUlZfU1RLMTdUQTg9bQojIENPTkZJR19SVENfRFJWX000OFQ4NiBpcyBub3Qgc2V0 CkNPTkZJR19SVENfRFJWX000OFQzNT1tCkNPTkZJR19SVENfRFJWX000OFQ1OT1tCkNPTkZJR19S VENfRFJWX01TTTYyNDI9bQpDT05GSUdfUlRDX0RSVl9CUTQ4MDI9bQpDT05GSUdfUlRDX0RSVl9S UDVDMDE9bQpDT05GSUdfUlRDX0RSVl9WMzAyMD1tCgojCiMgb24tQ1BVIFJUQyBkcml2ZXJzCiMK Q09ORklHX0RNQURFVklDRVM9eQojIENPTkZJR19ETUFERVZJQ0VTX0RFQlVHIGlzIG5vdCBzZXQK CiMKIyBETUEgRGV2aWNlcwojCiMgQ09ORklHX0lOVEVMX01JRF9ETUFDIGlzIG5vdCBzZXQKQ09O RklHX0lOVEVMX0lPQVRETUE9bQojIENPTkZJR19USU1CX0RNQSBpcyBub3Qgc2V0CkNPTkZJR19Q Q0hfRE1BPW0KQ09ORklHX0RNQV9FTkdJTkU9eQoKIwojIERNQSBDbGllbnRzCiMKQ09ORklHX05F VF9ETUE9eQpDT05GSUdfQVNZTkNfVFhfRE1BPXkKIyBDT05GSUdfRE1BVEVTVCBpcyBub3Qgc2V0 CkNPTkZJR19EQ0E9bQpDT05GSUdfQVVYRElTUExBWT15CkNPTkZJR19LUzAxMDg9bQpDT05GSUdf S1MwMTA4X1BPUlQ9MHgzNzgKQ09ORklHX0tTMDEwOF9ERUxBWT0yCkNPTkZJR19DRkFHMTI4NjRC PW0KQ09ORklHX0NGQUcxMjg2NEJfUkFURT0yMApDT05GSUdfVUlPPW0KQ09ORklHX1VJT19DSUY9 bQojIENPTkZJR19VSU9fUERSViBpcyBub3Qgc2V0CiMgQ09ORklHX1VJT19QRFJWX0dFTklSUSBp cyBub3Qgc2V0CkNPTkZJR19VSU9fQUVDPW0KQ09ORklHX1VJT19TRVJDT1MzPW0KQ09ORklHX1VJ T19QQ0lfR0VORVJJQz1tCiMgQ09ORklHX1VJT19ORVRYIGlzIG5vdCBzZXQKQ09ORklHX1ZGSU9f SU9NTVVfVFlQRTE9bQpDT05GSUdfVkZJTz1tCkNPTkZJR19WRklPX1BDST1tCkNPTkZJR19WSVJU SU89eQpDT05GSUdfVklSVElPX1JJTkc9eQoKIwojIFZpcnRpbyBkcml2ZXJzCiMKQ09ORklHX1ZJ UlRJT19QQ0k9eQpDT05GSUdfVklSVElPX0JBTExPT049bQpDT05GSUdfVklSVElPX01NSU89bQoj IENPTkZJR19WSVJUSU9fTU1JT19DTURMSU5FX0RFVklDRVMgaXMgbm90IHNldAoKIwojIE1pY3Jv c29mdCBIeXBlci1WIGd1ZXN0IHN1cHBvcnQKIwpDT05GSUdfSFlQRVJWPW0KQ09ORklHX0hZUEVS Vl9VVElMUz1tCgojCiMgWGVuIGRyaXZlciBzdXBwb3J0CiMKQ09ORklHX1hFTl9CQUxMT09OPXkK Q09ORklHX1hFTl9TRUxGQkFMTE9PTklORz15CkNPTkZJR19YRU5fU0NSVUJfUEFHRVM9eQpDT05G SUdfWEVOX0RFVl9FVlRDSE49eQpDT05GSUdfWEVOX0JBQ0tFTkQ9eQpDT05GSUdfWEVORlM9eQpD T05GSUdfWEVOX0NPTVBBVF9YRU5GUz15CkNPTkZJR19YRU5fU1lTX0hZUEVSVklTT1I9eQpDT05G SUdfWEVOX1hFTkJVU19GUk9OVEVORD15CkNPTkZJR19YRU5fR05UREVWPXkKQ09ORklHX1hFTl9H UkFOVF9ERVZfQUxMT0M9eQpDT05GSUdfU1dJT1RMQl9YRU49eQpDT05GSUdfWEVOX1RNRU09eQpD T05GSUdfWEVOX1BDSURFVl9CQUNLRU5EPXkKQ09ORklHX1hFTl9QUklWQ01EPXkKQ09ORklHX1hF Tl9BQ1BJX1BST0NFU1NPUj15CiMgQ09ORklHX1hFTl9NQ0VfTE9HIGlzIG5vdCBzZXQKQ09ORklH X1NUQUdJTkc9eQojIENPTkZJR19FVDEzMVggaXMgbm90IHNldAojIENPTkZJR19TTElDT1NTIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCSVBfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1czNVVORCBp cyBub3Qgc2V0CiMgQ09ORklHX1BSSVNNMl9VU0IgaXMgbm90IHNldAojIENPTkZJR19FQ0hPIGlz IG5vdCBzZXQKIyBDT05GSUdfQ09NRURJIGlzIG5vdCBzZXQKIyBDT05GSUdfQVNVU19PTEVEIGlz IG5vdCBzZXQKIyBDT05GSUdfUEFORUwgaXMgbm90IHNldAojIENPTkZJR19SODE4N1NFIGlzIG5v dCBzZXQKIyBDT05GSUdfUlRMODE5MlUgaXMgbm90IHNldAojIENPTkZJR19SVExMSUIgaXMgbm90 IHNldApDT05GSUdfUjg3MTJVPW0KIyBDT05GSUdfUlRTX1BTVE9SIGlzIG5vdCBzZXQKIyBDT05G SUdfUlRTNTEzOSBpcyBub3Qgc2V0CiMgQ09ORklHX1RSQU5aUE9SVCBpcyBub3Qgc2V0CiMgQ09O RklHX0lERV9QSElTT04gaXMgbm90IHNldAojIENPTkZJR19MSU5FNl9VU0IgaXMgbm90IHNldAoj IENPTkZJR19VU0JfU0VSSUFMX1FVQVRFQ0gyIGlzIG5vdCBzZXQKIyBDT05GSUdfVlQ2NjU1IGlz IG5vdCBzZXQKIyBDT05GSUdfVlQ2NjU2IGlzIG5vdCBzZXQKIyBDT05GSUdfRFhfU0VQIGlzIG5v dCBzZXQKIyBDT05GSUdfWlNNQUxMT0MgaXMgbm90IHNldAojIENPTkZJR19XTEFHUzQ5X0gyIGlz IG5vdCBzZXQKIyBDT05GSUdfV0xBR1M0OV9IMjUgaXMgbm90IHNldAojIENPTkZJR19GQl9TTTdY WCBpcyBub3Qgc2V0CkNPTkZJR19DUllTVEFMSEQ9bQojIENPTkZJR19GQl9YR0kgaXMgbm90IHNl dAojIENPTkZJR19BQ1BJX1FVSUNLU1RBUlQgaXMgbm90IHNldAojIENPTkZJR19VU0JfRU5FU1RP UkFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0JDTV9XSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZU MTAwMCBpcyBub3Qgc2V0CgojCiMgU3BlYWt1cCBjb25zb2xlIHNwZWVjaAojCiMgQ09ORklHX1NQ RUFLVVAgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9TWU5BUFRJQ1NfSTJDX1JNSTQg aXMgbm90IHNldApDT05GSUdfU1RBR0lOR19NRURJQT15CiMgQ09ORklHX0RWQl9BUzEwMiBpcyBu b3Qgc2V0CiMgQ09ORklHX0RWQl9DWEQyMDk5IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fRFQz MTU1IGlzIG5vdCBzZXQKIyBDT05GSUdfRUFTWUNBUCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVP X0dPNzAwNyBpcyBub3Qgc2V0CiMgQ09ORklHX1NPTE82WDEwIGlzIG5vdCBzZXQKQ09ORklHX0xJ UkNfU1RBR0lORz15CkNPTkZJR19MSVJDX0JUODI5PW0KQ09ORklHX0xJUkNfSUdPUlBMVUdVU0I9 bQpDT05GSUdfTElSQ19JTU9OPW0KQ09ORklHX0xJUkNfUEFSQUxMRUw9bQpDT05GSUdfTElSQ19T QVNFTT1tCkNPTkZJR19MSVJDX1NFUklBTD1tCkNPTkZJR19MSVJDX1NFUklBTF9UUkFOU01JVFRF Uj15CkNPTkZJR19MSVJDX1NJUj1tCkNPTkZJR19MSVJDX1RUVVNCSVI9bQpDT05GSUdfTElSQ19a SUxPRz1tCgojCiMgQW5kcm9pZAojCiMgQ09ORklHX0FORFJPSUQgaXMgbm90IHNldAojIENPTkZJ R19QSE9ORSBpcyBub3Qgc2V0CiMgQ09ORklHX1JBTVNURVIgaXMgbm90IHNldAojIENPTkZJR19V U0JfV1BBTl9IQ0QgaXMgbm90IHNldAojIENPTkZJR19JUEFDS19CVVMgaXMgbm90IHNldAojIENP TkZJR19XSU1BWF9HRE03MlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1NSX1dJRkkgaXMgbm90IHNl dApDT05GSUdfWDg2X1BMQVRGT1JNX0RFVklDRVM9eQpDT05GSUdfQUNFUl9XTUk9bQpDT05GSUdf QUNFUkhERj1tCkNPTkZJR19BU1VTX0xBUFRPUD1tCkNPTkZJR19ERUxMX0xBUFRPUD1tCkNPTkZJ R19ERUxMX1dNST1tCkNPTkZJR19ERUxMX1dNSV9BSU89bQpDT05GSUdfRlVKSVRTVV9MQVBUT1A9 bQojIENPTkZJR19GVUpJVFNVX0xBUFRPUF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GVUpJVFNV X1RBQkxFVD1tCkNPTkZJR19BTUlMT19SRktJTEw9bQpDT05GSUdfSFBfQUNDRUw9bQpDT05GSUdf SFBfV01JPW0KQ09ORklHX01TSV9MQVBUT1A9bQpDT05GSUdfUEFOQVNPTklDX0xBUFRPUD1tCkNP TkZJR19DT01QQUxfTEFQVE9QPW0KQ09ORklHX1NPTllfTEFQVE9QPW0KQ09ORklHX1NPTllQSV9D T01QQVQ9eQpDT05GSUdfSURFQVBBRF9MQVBUT1A9bQpDT05GSUdfVEhJTktQQURfQUNQST1tCkNP TkZJR19USElOS1BBRF9BQ1BJX0FMU0FfU1VQUE9SVD15CiMgQ09ORklHX1RISU5LUEFEX0FDUElf REVCVUdGQUNJTElUSUVTIGlzIG5vdCBzZXQKIyBDT05GSUdfVEhJTktQQURfQUNQSV9ERUJVRyBp cyBub3Qgc2V0CiMgQ09ORklHX1RISU5LUEFEX0FDUElfVU5TQUZFX0xFRFMgaXMgbm90IHNldApD T05GSUdfVEhJTktQQURfQUNQSV9WSURFTz15CkNPTkZJR19USElOS1BBRF9BQ1BJX0hPVEtFWV9Q T0xMPXkKQ09ORklHX1NFTlNPUlNfSERBUFM9bQojIENPTkZJR19JTlRFTF9NRU5MT1cgaXMgbm90 IHNldApDT05GSUdfRUVFUENfTEFQVE9QPW0KQ09ORklHX0FTVVNfV01JPW0KQ09ORklHX0FTVVNf TkJfV01JPW0KQ09ORklHX0VFRVBDX1dNST1tCkNPTkZJR19BQ1BJX1dNST1tCkNPTkZJR19NU0lf V01JPW0KQ09ORklHX1RPUFNUQVJfTEFQVE9QPW0KQ09ORklHX0FDUElfVE9TSElCQT1tCkNPTkZJ R19UT1NISUJBX0JUX1JGS0lMTD1tCkNPTkZJR19BQ1BJX0NNUEM9bQpDT05GSUdfSU5URUxfSVBT PW0KIyBDT05GSUdfSUJNX1JUTCBpcyBub3Qgc2V0CiMgQ09ORklHX1hPMTVfRUJPT0sgaXMgbm90 IHNldApDT05GSUdfU0FNU1VOR19MQVBUT1A9bQpDT05GSUdfTVhNX1dNST1tCkNPTkZJR19JTlRF TF9PQUtUUkFJTD1tCkNPTkZJR19TQU1TVU5HX1ExMD1tCkNPTkZJR19BUFBMRV9HTVVYPW0KCiMK IyBIYXJkd2FyZSBTcGlubG9jayBkcml2ZXJzCiMKQ09ORklHX0NMS0VWVF9JODI1Mz15CkNPTkZJ R19JODI1M19MT0NLPXkKQ09ORklHX0NMS0JMRF9JODI1Mz15CkNPTkZJR19JT01NVV9BUEk9eQpD T05GSUdfSU9NTVVfU1VQUE9SVD15CkNPTkZJR19BTURfSU9NTVU9eQpDT05GSUdfQU1EX0lPTU1V X1NUQVRTPXkKQ09ORklHX0FNRF9JT01NVV9WMj1tCkNPTkZJR19ETUFSX1RBQkxFPXkKQ09ORklH X0lOVEVMX0lPTU1VPXkKIyBDT05GSUdfSU5URUxfSU9NTVVfREVGQVVMVF9PTiBpcyBub3Qgc2V0 CkNPTkZJR19JTlRFTF9JT01NVV9GTE9QUFlfV0E9eQpDT05GSUdfSVJRX1JFTUFQPXkKCiMKIyBS ZW1vdGVwcm9jIGRyaXZlcnMgKEVYUEVSSU1FTlRBTCkKIwoKIwojIFJwbXNnIGRyaXZlcnMgKEVY UEVSSU1FTlRBTCkKIwojIENPTkZJR19WSVJUX0RSSVZFUlMgaXMgbm90IHNldAojIENPTkZJR19Q TV9ERVZGUkVRIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUQ09OIGlzIG5vdCBzZXQKIyBDT05GSUdf TUVNT1JZIGlzIG5vdCBzZXQKIyBDT05GSUdfSUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfVk1FX0JV UyBpcyBub3Qgc2V0CiMgQ09ORklHX1BXTSBpcyBub3Qgc2V0CgojCiMgRmlybXdhcmUgRHJpdmVy cwojCkNPTkZJR19FREQ9bQojIENPTkZJR19FRERfT0ZGIGlzIG5vdCBzZXQKQ09ORklHX0ZJUk1X QVJFX01FTU1BUD15CkNPTkZJR19FRklfVkFSUz15CkNPTkZJR19ERUxMX1JCVT1tCkNPTkZJR19E Q0RCQVM9bQpDT05GSUdfRE1JSUQ9eQpDT05GSUdfRE1JX1NZU0ZTPXkKQ09ORklHX0lTQ1NJX0lC RlRfRklORD15CkNPTkZJR19JU0NTSV9JQkZUPW0KIyBDT05GSUdfR09PR0xFX0ZJUk1XQVJFIGlz IG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMKIwpDT05GSUdfRENBQ0hFX1dPUkRfQUNDRVNTPXkK IyBDT05GSUdfRVhUMl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDNfRlMgaXMgbm90IHNldApD T05GSUdfRVhUNF9GUz15CkNPTkZJR19FWFQ0X1VTRV9GT1JfRVhUMjM9eQpDT05GSUdfRVhUNF9G U19YQVRUUj15CkNPTkZJR19FWFQ0X0ZTX1BPU0lYX0FDTD15CkNPTkZJR19FWFQ0X0ZTX1NFQ1VS SVRZPXkKIyBDT05GSUdfRVhUNF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19KQkQyPXkKIyBDT05G SUdfSkJEMl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GU19NQkNBQ0hFPXkKQ09ORklHX1JFSVNF UkZTX0ZTPW0KIyBDT05GSUdfUkVJU0VSRlNfQ0hFQ0sgaXMgbm90IHNldApDT05GSUdfUkVJU0VS RlNfUFJPQ19JTkZPPXkKQ09ORklHX1JFSVNFUkZTX0ZTX1hBVFRSPXkKQ09ORklHX1JFSVNFUkZT X0ZTX1BPU0lYX0FDTD15CkNPTkZJR19SRUlTRVJGU19GU19TRUNVUklUWT15CkNPTkZJR19KRlNf RlM9bQpDT05GSUdfSkZTX1BPU0lYX0FDTD15CkNPTkZJR19KRlNfU0VDVVJJVFk9eQojIENPTkZJ R19KRlNfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19KRlNfU1RBVElTVElDUyBpcyBub3Qgc2V0 CkNPTkZJR19YRlNfRlM9bQpDT05GSUdfWEZTX1FVT1RBPXkKQ09ORklHX1hGU19QT1NJWF9BQ0w9 eQojIENPTkZJR19YRlNfUlQgaXMgbm90IHNldAojIENPTkZJR19YRlNfREVCVUcgaXMgbm90IHNl dApDT05GSUdfR0ZTMl9GUz1tCkNPTkZJR19HRlMyX0ZTX0xPQ0tJTkdfRExNPXkKQ09ORklHX09D RlMyX0ZTPW0KQ09ORklHX09DRlMyX0ZTX08yQ0I9bQpDT05GSUdfT0NGUzJfRlNfVVNFUlNQQUNF X0NMVVNURVI9bQojIENPTkZJR19PQ0ZTMl9GU19TVEFUUyBpcyBub3Qgc2V0CiMgQ09ORklHX09D RlMyX0RFQlVHX01BU0tMT0cgaXMgbm90IHNldAojIENPTkZJR19PQ0ZTMl9ERUJVR19GUyBpcyBu b3Qgc2V0CkNPTkZJR19CVFJGU19GUz1tCkNPTkZJR19CVFJGU19GU19QT1NJWF9BQ0w9eQojIENP TkZJR19CVFJGU19GU19DSEVDS19JTlRFR1JJVFkgaXMgbm90IHNldApDT05GSUdfTklMRlMyX0ZT PW0KQ09ORklHX0ZTX1BPU0lYX0FDTD15CkNPTkZJR19FWFBPUlRGUz15CkNPTkZJR19GSUxFX0xP Q0tJTkc9eQpDT05GSUdfRlNOT1RJRlk9eQpDT05GSUdfRE5PVElGWT15CkNPTkZJR19JTk9USUZZ X1VTRVI9eQpDT05GSUdfRkFOT1RJRlk9eQpDT05GSUdfRkFOT1RJRllfQUNDRVNTX1BFUk1JU1NJ T05TPXkKQ09ORklHX1FVT1RBPXkKQ09ORklHX1FVT1RBX05FVExJTktfSU5URVJGQUNFPXkKIyBD T05GSUdfUFJJTlRfUVVPVEFfV0FSTklORyBpcyBub3Qgc2V0CiMgQ09ORklHX1FVT1RBX0RFQlVH IGlzIG5vdCBzZXQKQ09ORklHX1FVT1RBX1RSRUU9eQojIENPTkZJR19RRk1UX1YxIGlzIG5vdCBz ZXQKQ09ORklHX1FGTVRfVjI9eQpDT05GSUdfUVVPVEFDVEw9eQpDT05GSUdfUVVPVEFDVExfQ09N UEFUPXkKQ09ORklHX0FVVE9GUzRfRlM9eQpDT05GSUdfRlVTRV9GUz1tCkNPTkZJR19DVVNFPW0K Q09ORklHX0dFTkVSSUNfQUNMPXkKCiMKIyBDYWNoZXMKIwpDT05GSUdfRlNDQUNIRT1tCkNPTkZJ R19GU0NBQ0hFX1NUQVRTPXkKIyBDT05GSUdfRlNDQUNIRV9ISVNUT0dSQU0gaXMgbm90IHNldAoj IENPTkZJR19GU0NBQ0hFX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0ZTQ0FDSEVfT0JKRUNUX0xJ U1Q9eQpDT05GSUdfQ0FDSEVGSUxFUz1tCiMgQ09ORklHX0NBQ0hFRklMRVNfREVCVUcgaXMgbm90 IHNldAojIENPTkZJR19DQUNIRUZJTEVTX0hJU1RPR1JBTSBpcyBub3Qgc2V0CgojCiMgQ0QtUk9N L0RWRCBGaWxlc3lzdGVtcwojCkNPTkZJR19JU085NjYwX0ZTPXkKQ09ORklHX0pPTElFVD15CkNP TkZJR19aSVNPRlM9eQpDT05GSUdfVURGX0ZTPW0KQ09ORklHX1VERl9OTFM9eQoKIwojIERPUy9G QVQvTlQgRmlsZXN5c3RlbXMKIwpDT05GSUdfRkFUX0ZTPW0KQ09ORklHX01TRE9TX0ZTPW0KQ09O RklHX1ZGQVRfRlM9bQpDT05GSUdfRkFUX0RFRkFVTFRfQ09ERVBBR0U9NDM3CkNPTkZJR19GQVRf REVGQVVMVF9JT0NIQVJTRVQ9ImFzY2lpIgojIENPTkZJR19OVEZTX0ZTIGlzIG5vdCBzZXQKCiMK IyBQc2V1ZG8gZmlsZXN5c3RlbXMKIwpDT05GSUdfUFJPQ19GUz15CkNPTkZJR19QUk9DX0tDT1JF PXkKQ09ORklHX1BST0NfVk1DT1JFPXkKQ09ORklHX1BST0NfU1lTQ1RMPXkKQ09ORklHX1BST0Nf UEFHRV9NT05JVE9SPXkKQ09ORklHX1NZU0ZTPXkKQ09ORklHX1RNUEZTPXkKQ09ORklHX1RNUEZT X1BPU0lYX0FDTD15CkNPTkZJR19UTVBGU19YQVRUUj15CkNPTkZJR19IVUdFVExCRlM9eQpDT05G SUdfSFVHRVRMQl9QQUdFPXkKQ09ORklHX0NPTkZJR0ZTX0ZTPXkKQ09ORklHX01JU0NfRklMRVNZ U1RFTVM9eQojIENPTkZJR19BREZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0FGRlNfRlM9bQpDT05G SUdfRUNSWVBUX0ZTPW0KQ09ORklHX0hGU19GUz1tCkNPTkZJR19IRlNQTFVTX0ZTPW0KQ09ORklH X0JFRlNfRlM9bQojIENPTkZJR19CRUZTX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQkZTX0ZT IGlzIG5vdCBzZXQKIyBDT05GSUdfRUZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSkZGUzJfRlMg aXMgbm90IHNldApDT05GSUdfVUJJRlNfRlM9bQojIENPTkZJR19VQklGU19GU19BRFZBTkNFRF9D T01QUiBpcyBub3Qgc2V0CkNPTkZJR19VQklGU19GU19MWk89eQpDT05GSUdfVUJJRlNfRlNfWkxJ Qj15CiMgQ09ORklHX0xPR0ZTIGlzIG5vdCBzZXQKQ09ORklHX0NSQU1GUz1tCkNPTkZJR19TUVVB U0hGUz1tCkNPTkZJR19TUVVBU0hGU19YQVRUUj15CkNPTkZJR19TUVVBU0hGU19aTElCPXkKQ09O RklHX1NRVUFTSEZTX0xaTz15CkNPTkZJR19TUVVBU0hGU19YWj15CiMgQ09ORklHX1NRVUFTSEZT XzRLX0RFVkJMS19TSVpFIGlzIG5vdCBzZXQKIyBDT05GSUdfU1FVQVNIRlNfRU1CRURERUQgaXMg bm90IHNldApDT05GSUdfU1FVQVNIRlNfRlJBR01FTlRfQ0FDSEVfU0laRT0zCiMgQ09ORklHX1ZY RlNfRlMgaXMgbm90IHNldApDT05GSUdfTUlOSVhfRlM9bQojIENPTkZJR19PTUZTX0ZTIGlzIG5v dCBzZXQKIyBDT05GSUdfSFBGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1FOWDRGU19GUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1FOWDZGU19GUyBpcyBub3Qgc2V0CkNPTkZJR19ST01GU19GUz1tCkNP TkZJR19ST01GU19CQUNLRURfQllfQkxPQ0s9eQojIENPTkZJR19ST01GU19CQUNLRURfQllfTVRE IGlzIG5vdCBzZXQKIyBDT05GSUdfUk9NRlNfQkFDS0VEX0JZX0JPVEggaXMgbm90IHNldApDT05G SUdfUk9NRlNfT05fQkxPQ0s9eQpDT05GSUdfUFNUT1JFPXkKIyBDT05GSUdfUFNUT1JFX0NPTlNP TEUgaXMgbm90IHNldAojIENPTkZJR19QU1RPUkVfRlRSQUNFIGlzIG5vdCBzZXQKQ09ORklHX1BT VE9SRV9SQU09bQpDT05GSUdfU1lTVl9GUz1tCkNPTkZJR19VRlNfRlM9bQojIENPTkZJR19VRlNf RlNfV1JJVEUgaXMgbm90IHNldAojIENPTkZJR19VRlNfREVCVUcgaXMgbm90IHNldAojIENPTkZJ R19FWE9GU19GUyBpcyBub3Qgc2V0CkNPTkZJR19PUkU9bQpDT05GSUdfTkVUV09SS19GSUxFU1lT VEVNUz15CkNPTkZJR19ORlNfRlM9bQpDT05GSUdfTkZTX1YyPW0KQ09ORklHX05GU19WMz1tCkNP TkZJR19ORlNfVjNfQUNMPXkKQ09ORklHX05GU19WND1tCiMgQ09ORklHX05GU19TV0FQIGlzIG5v dCBzZXQKQ09ORklHX05GU19WNF8xPXkKQ09ORklHX1BORlNfRklMRV9MQVlPVVQ9bQpDT05GSUdf UE5GU19CTE9DSz1tCkNPTkZJR19QTkZTX09CSkxBWU9VVD1tCkNPTkZJR19ORlNfVjRfMV9JTVBM RU1FTlRBVElPTl9JRF9ET01BSU49Imtlcm5lbC5vcmciCkNPTkZJR19ORlNfRlNDQUNIRT15CiMg Q09ORklHX05GU19VU0VfTEVHQUNZX0ROUyBpcyBub3Qgc2V0CkNPTkZJR19ORlNfVVNFX0tFUk5F TF9ETlM9eQpDT05GSUdfTkZTX0RFQlVHPXkKQ09ORklHX05GU0Q9bQpDT05GSUdfTkZTRF9WMl9B Q0w9eQpDT05GSUdfTkZTRF9WMz15CkNPTkZJR19ORlNEX1YzX0FDTD15CkNPTkZJR19ORlNEX1Y0 PXkKIyBDT05GSUdfTkZTRF9GQVVMVF9JTkpFQ1RJT04gaXMgbm90IHNldApDT05GSUdfTE9DS0Q9 bQpDT05GSUdfTE9DS0RfVjQ9eQpDT05GSUdfTkZTX0FDTF9TVVBQT1JUPW0KQ09ORklHX05GU19D T01NT049eQpDT05GSUdfU1VOUlBDPW0KQ09ORklHX1NVTlJQQ19HU1M9bQpDT05GSUdfU1VOUlBD X0JBQ0tDSEFOTkVMPXkKQ09ORklHX1NVTlJQQ19YUFJUX1JETUE9bQpDT05GSUdfUlBDU0VDX0dT U19LUkI1PW0KQ09ORklHX1NVTlJQQ19ERUJVRz15CkNPTkZJR19DRVBIX0ZTPW0KQ09ORklHX0NJ RlM9bQpDT05GSUdfQ0lGU19TVEFUUz15CiMgQ09ORklHX0NJRlNfU1RBVFMyIGlzIG5vdCBzZXQK Q09ORklHX0NJRlNfV0VBS19QV19IQVNIPXkKQ09ORklHX0NJRlNfVVBDQUxMPXkKQ09ORklHX0NJ RlNfWEFUVFI9eQpDT05GSUdfQ0lGU19QT1NJWD15CiMgQ09ORklHX0NJRlNfREVCVUcyIGlzIG5v dCBzZXQKQ09ORklHX0NJRlNfREZTX1VQQ0FMTD15CkNPTkZJR19DSUZTX0ZTQ0FDSEU9eQpDT05G SUdfQ0lGU19BQ0w9eQpDT05GSUdfTkNQX0ZTPW0KQ09ORklHX05DUEZTX1BBQ0tFVF9TSUdOSU5H PXkKQ09ORklHX05DUEZTX0lPQ1RMX0xPQ0tJTkc9eQpDT05GSUdfTkNQRlNfU1RST05HPXkKQ09O RklHX05DUEZTX05GU19OUz15CkNPTkZJR19OQ1BGU19PUzJfTlM9eQpDT05GSUdfTkNQRlNfU01B TExET1M9eQpDT05GSUdfTkNQRlNfTkxTPXkKQ09ORklHX05DUEZTX0VYVFJBUz15CkNPTkZJR19D T0RBX0ZTPW0KIyBDT05GSUdfQUZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHXzlQX0ZTPW0KQ09ORklH XzlQX0ZTQ0FDSEU9eQpDT05GSUdfOVBfRlNfUE9TSVhfQUNMPXkKQ09ORklHX05MUz15CkNPTkZJ R19OTFNfREVGQVVMVD0idXRmOCIKQ09ORklHX05MU19DT0RFUEFHRV80Mzc9eQpDT05GSUdfTkxT X0NPREVQQUdFXzczNz1tCkNPTkZJR19OTFNfQ09ERVBBR0VfNzc1PW0KQ09ORklHX05MU19DT0RF UEFHRV84NTA9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg1Mj1tCkNPTkZJR19OTFNfQ09ERVBBR0Vf ODU1PW0KQ09ORklHX05MU19DT0RFUEFHRV84NTc9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg2MD1t CkNPTkZJR19OTFNfQ09ERVBBR0VfODYxPW0KQ09ORklHX05MU19DT0RFUEFHRV84NjI9bQpDT05G SUdfTkxTX0NPREVQQUdFXzg2Mz1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODY0PW0KQ09ORklHX05M U19DT0RFUEFHRV84NjU9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg2Nj1tCkNPTkZJR19OTFNfQ09E RVBBR0VfODY5PW0KQ09ORklHX05MU19DT0RFUEFHRV85MzY9bQpDT05GSUdfTkxTX0NPREVQQUdF Xzk1MD1tCkNPTkZJR19OTFNfQ09ERVBBR0VfOTMyPW0KQ09ORklHX05MU19DT0RFUEFHRV85NDk9 bQpDT05GSUdfTkxTX0NPREVQQUdFXzg3ND1tCkNPTkZJR19OTFNfSVNPODg1OV84PW0KQ09ORklH X05MU19DT0RFUEFHRV8xMjUwPW0KQ09ORklHX05MU19DT0RFUEFHRV8xMjUxPW0KQ09ORklHX05M U19BU0NJST15CkNPTkZJR19OTFNfSVNPODg1OV8xPW0KQ09ORklHX05MU19JU084ODU5XzI9bQpD T05GSUdfTkxTX0lTTzg4NTlfMz1tCkNPTkZJR19OTFNfSVNPODg1OV80PW0KQ09ORklHX05MU19J U084ODU5XzU9bQpDT05GSUdfTkxTX0lTTzg4NTlfNj1tCkNPTkZJR19OTFNfSVNPODg1OV83PW0K Q09ORklHX05MU19JU084ODU5Xzk9bQpDT05GSUdfTkxTX0lTTzg4NTlfMTM9bQpDT05GSUdfTkxT X0lTTzg4NTlfMTQ9bQpDT05GSUdfTkxTX0lTTzg4NTlfMTU9bQpDT05GSUdfTkxTX0tPSThfUj1t CkNPTkZJR19OTFNfS09JOF9VPW0KQ09ORklHX05MU19NQUNfUk9NQU49bQpDT05GSUdfTkxTX01B Q19DRUxUSUM9bQpDT05GSUdfTkxTX01BQ19DRU5URVVSTz1tCkNPTkZJR19OTFNfTUFDX0NST0FU SUFOPW0KQ09ORklHX05MU19NQUNfQ1lSSUxMSUM9bQpDT05GSUdfTkxTX01BQ19HQUVMSUM9bQpD T05GSUdfTkxTX01BQ19HUkVFSz1tCkNPTkZJR19OTFNfTUFDX0lDRUxBTkQ9bQpDT05GSUdfTkxT X01BQ19JTlVJVD1tCkNPTkZJR19OTFNfTUFDX1JPTUFOSUFOPW0KQ09ORklHX05MU19NQUNfVFVS S0lTSD1tCkNPTkZJR19OTFNfVVRGOD1tCkNPTkZJR19ETE09bQpDT05GSUdfRExNX0RFQlVHPXkK CiMKIyBLZXJuZWwgaGFja2luZwojCkNPTkZJR19UUkFDRV9JUlFGTEFHU19TVVBQT1JUPXkKQ09O RklHX1BSSU5US19USU1FPXkKQ09ORklHX0RFRkFVTFRfTUVTU0FHRV9MT0dMRVZFTD00CiMgQ09O RklHX0VOQUJMRV9XQVJOX0RFUFJFQ0FURUQgaXMgbm90IHNldApDT05GSUdfRU5BQkxFX01VU1Rf Q0hFQ0s9eQpDT05GSUdfRlJBTUVfV0FSTj0yMDQ4CkNPTkZJR19NQUdJQ19TWVNSUT15CkNPTkZJ R19TVFJJUF9BU01fU1lNUz15CiMgQ09ORklHX1JFQURBQkxFX0FTTSBpcyBub3Qgc2V0CkNPTkZJ R19VTlVTRURfU1lNQk9MUz15CkNPTkZJR19ERUJVR19GUz15CkNPTkZJR19IRUFERVJTX0NIRUNL PXkKIyBDT05GSUdfREVCVUdfU0VDVElPTl9NSVNNQVRDSCBpcyBub3Qgc2V0CkNPTkZJR19ERUJV R19LRVJORUw9eQpDT05GSUdfREVCVUdfU0hJUlE9eQpDT05GSUdfTE9DS1VQX0RFVEVDVE9SPXkK Q09ORklHX0hBUkRMT0NLVVBfREVURUNUT1I9eQojIENPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tV UF9QQU5JQyBpcyBub3Qgc2V0CkNPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQ19WQUxV RT0wCiMgQ09ORklHX0JPT1RQQVJBTV9TT0ZUTE9DS1VQX1BBTklDIGlzIG5vdCBzZXQKQ09ORklH X0JPT1RQQVJBTV9TT0ZUTE9DS1VQX1BBTklDX1ZBTFVFPTAKIyBDT05GSUdfUEFOSUNfT05fT09Q UyBpcyBub3Qgc2V0CkNPTkZJR19QQU5JQ19PTl9PT1BTX1ZBTFVFPTAKIyBDT05GSUdfREVURUNU X0hVTkdfVEFTSyBpcyBub3Qgc2V0CkNPTkZJR19TQ0hFRF9ERUJVRz15CkNPTkZJR19TQ0hFRFNU QVRTPXkKQ09ORklHX1RJTUVSX1NUQVRTPXkKIyBDT05GSUdfREVCVUdfT0JKRUNUUyBpcyBub3Qg c2V0CiMgQ09ORklHX1NMVUJfREVCVUdfT04gaXMgbm90IHNldAojIENPTkZJR19TTFVCX1NUQVRT IGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfS01FTUxFQUsgaXMgbm90IHNldAojIENPTkZJR19E RUJVR19SVF9NVVRFWEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRfTVVURVhfVEVTVEVSIGlzIG5v dCBzZXQKIyBDT05GSUdfREVCVUdfU1BJTkxPQ0sgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19N VVRFWEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTE9DS19BTExPQyBpcyBub3Qgc2V0CiMg Q09ORklHX1BST1ZFX0xPQ0tJTkcgaXMgbm90IHNldApDT05GSUdfU1BBUlNFX1JDVV9QT0lOVEVS PXkKIyBDT05GSUdfTE9DS19TVEFUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfQVRPTUlDX1NM RUVQIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTE9DS0lOR19BUElfU0VMRlRFU1RTIGlzIG5v dCBzZXQKQ09ORklHX1NUQUNLVFJBQ0U9eQojIENPTkZJR19ERUJVR19TVEFDS19VU0FHRSBpcyBu b3Qgc2V0CiMgQ09ORklHX0RFQlVHX0tPQkpFQ1QgaXMgbm90IHNldApDT05GSUdfREVCVUdfQlVH VkVSQk9TRT15CkNPTkZJR19ERUJVR19JTkZPPXkKIyBDT05GSUdfREVCVUdfSU5GT19SRURVQ0VE IGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX1ZNPXkKIyBDT05GSUdfREVCVUdfVklSVFVBTCBpcyBu b3Qgc2V0CiMgQ09ORklHX0RFQlVHX1dSSVRFQ09VTlQgaXMgbm90IHNldApDT05GSUdfREVCVUdf TUVNT1JZX0lOSVQ9eQpDT05GSUdfREVCVUdfTElTVD15CiMgQ09ORklHX1RFU1RfTElTVF9TT1JU IGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0cgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19O T1RJRklFUlMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19DUkVERU5USUFMUyBpcyBub3Qgc2V0 CkNPTkZJR19BUkNIX1dBTlRfRlJBTUVfUE9JTlRFUlM9eQpDT05GSUdfRlJBTUVfUE9JTlRFUj15 CkNPTkZJR19CT09UX1BSSU5US19ERUxBWT15CiMgQ09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMg bm90IHNldApDT05GSUdfUkNVX0NQVV9TVEFMTF9USU1FT1VUPTYwCiMgQ09ORklHX1JDVV9DUFVf U1RBTExfSU5GTyBpcyBub3Qgc2V0CiMgQ09ORklHX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09O RklHX0tQUk9CRVNfU0FOSVRZX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19CQUNLVFJBQ0VfU0VM Rl9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfQkxPQ0tfRVhUX0RFVlQgaXMgbm90IHNl dAojIENPTkZJR19ERUJVR19GT1JDRV9XRUFLX1BFUl9DUFUgaXMgbm90IHNldAojIENPTkZJR19E RUJVR19QRVJfQ1BVX01BUFMgaXMgbm90IHNldAojIENPTkZJR19MS0RUTSBpcyBub3Qgc2V0CiMg Q09ORklHX05PVElGSUVSX0VSUk9SX0lOSkVDVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZBVUxU X0lOSkVDVElPTiBpcyBub3Qgc2V0CkNPTkZJR19MQVRFTkNZVE9QPXkKIyBDT05GSUdfREVCVUdf UEFHRUFMTE9DIGlzIG5vdCBzZXQKQ09ORklHX1VTRVJfU1RBQ0tUUkFDRV9TVVBQT1JUPXkKQ09O RklHX05PUF9UUkFDRVI9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9UUkFDRVI9eQpDT05GSUdfSEFW RV9GVU5DVElPTl9HUkFQSF9UUkFDRVI9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9HUkFQSF9GUF9U RVNUPXkKQ09ORklHX0hBVkVfRlVOQ1RJT05fVFJBQ0VfTUNPVU5UX1RFU1Q9eQpDT05GSUdfSEFW RV9EWU5BTUlDX0ZUUkFDRT15CkNPTkZJR19IQVZFX0ZUUkFDRV9NQ09VTlRfUkVDT1JEPXkKQ09O RklHX0hBVkVfU1lTQ0FMTF9UUkFDRVBPSU5UUz15CkNPTkZJR19IQVZFX0NfUkVDT1JETUNPVU5U PXkKQ09ORklHX1RSQUNFUl9NQVhfVFJBQ0U9eQpDT05GSUdfUklOR19CVUZGRVI9eQpDT05GSUdf RVZFTlRfVFJBQ0lORz15CkNPTkZJR19FVkVOVF9QT1dFUl9UUkFDSU5HX0RFUFJFQ0FURUQ9eQpD T05GSUdfQ09OVEVYVF9TV0lUQ0hfVFJBQ0VSPXkKQ09ORklHX1JJTkdfQlVGRkVSX0FMTE9XX1NX QVA9eQpDT05GSUdfVFJBQ0lORz15CkNPTkZJR19HRU5FUklDX1RSQUNFUj15CkNPTkZJR19UUkFD SU5HX1NVUFBPUlQ9eQpDT05GSUdfRlRSQUNFPXkKQ09ORklHX0ZVTkNUSU9OX1RSQUNFUj15CkNP TkZJR19GVU5DVElPTl9HUkFQSF9UUkFDRVI9eQojIENPTkZJR19JUlFTT0ZGX1RSQUNFUiBpcyBu b3Qgc2V0CkNPTkZJR19TQ0hFRF9UUkFDRVI9eQpDT05GSUdfRlRSQUNFX1NZU0NBTExTPXkKQ09O RklHX0JSQU5DSF9QUk9GSUxFX05PTkU9eQojIENPTkZJR19QUk9GSUxFX0FOTk9UQVRFRF9CUkFO Q0hFUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BST0ZJTEVfQUxMX0JSQU5DSEVTIGlzIG5vdCBzZXQK Q09ORklHX1NUQUNLX1RSQUNFUj15CkNPTkZJR19CTEtfREVWX0lPX1RSQUNFPXkKQ09ORklHX0tQ Uk9CRV9FVkVOVD15CkNPTkZJR19VUFJPQkVfRVZFTlQ9eQpDT05GSUdfUFJPQkVfRVZFTlRTPXkK Q09ORklHX0RZTkFNSUNfRlRSQUNFPXkKQ09ORklHX0ZVTkNUSU9OX1BST0ZJTEVSPXkKQ09ORklH X0ZUUkFDRV9NQ09VTlRfUkVDT1JEPXkKIyBDT05GSUdfRlRSQUNFX1NUQVJUVVBfVEVTVCBpcyBu b3Qgc2V0CiMgQ09ORklHX01NSU9UUkFDRSBpcyBub3Qgc2V0CkNPTkZJR19SSU5HX0JVRkZFUl9C RU5DSE1BUks9bQpDT05GSUdfUFJPVklERV9PSENJMTM5NF9ETUFfSU5JVD15CiMgQ09ORklHX0ZJ UkVXSVJFX09IQ0lfUkVNT1RFX0RNQSBpcyBub3Qgc2V0CkNPTkZJR19CVUlMRF9ET0NTUkM9eQpD T05GSUdfRFlOQU1JQ19ERUJVRz15CiMgQ09ORklHX0RNQV9BUElfREVCVUcgaXMgbm90IHNldApD T05GSUdfQVRPTUlDNjRfU0VMRlRFU1Q9eQpDT05GSUdfQVNZTkNfUkFJRDZfVEVTVD1tCiMgQ09O RklHX1NBTVBMRVMgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNIX0tHREI9eQpDT05GSUdfS0dE Qj15CkNPTkZJR19LR0RCX1NFUklBTF9DT05TT0xFPXkKQ09ORklHX0tHREJfVEVTVFM9eQojIENP TkZJR19LR0RCX1RFU1RTX09OX0JPT1QgaXMgbm90IHNldApDT05GSUdfS0dEQl9MT1dfTEVWRUxf VFJBUD15CkNPTkZJR19LR0RCX0tEQj15CkNPTkZJR19LREJfS0VZQk9BUkQ9eQpDT05GSUdfSEFW RV9BUkNIX0tNRU1DSEVDSz15CkNPTkZJR19URVNUX0tTVFJUT1g9eQpDT05GSUdfU1RSSUNUX0RF Vk1FTT15CiMgQ09ORklHX1g4Nl9WRVJCT1NFX0JPT1RVUCBpcyBub3Qgc2V0CkNPTkZJR19FQVJM WV9QUklOVEs9eQpDT05GSUdfRUFSTFlfUFJJTlRLX0RCR1A9eQpDT05GSUdfREVCVUdfU1RBQ0tP VkVSRkxPVz15CiMgQ09ORklHX1g4Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9E QVRBPXkKQ09ORklHX0RFQlVHX1JPREFUQV9URVNUPXkKQ09ORklHX0RFQlVHX1NFVF9NT0RVTEVf Uk9OWD15CkNPTkZJR19ERUJVR19OWF9URVNUPW0KIyBDT05GSUdfREVCVUdfVExCRkxVU0ggaXMg bm90IHNldAojIENPTkZJR19JT01NVV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0lPTU1VX1NU UkVTUyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX01NSU9UUkFDRV9TVVBQT1JUPXkKQ09ORklHX1g4 Nl9ERUNPREVSX1NFTEZURVNUPXkKQ09ORklHX0lPX0RFTEFZX1RZUEVfMFg4MD0wCkNPTkZJR19J T19ERUxBWV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9VREVMQVk9MgpDT05GSUdf SU9fREVMQVlfVFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9eQojIENPTkZJR19JT19E RUxBWV8wWEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURFTEFZIGlzIG5vdCBzZXQK IyBDT05GSUdfSU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPX0RFTEFZ X1RZUEU9MApDT05GSUdfREVCVUdfQk9PVF9QQVJBTVM9eQojIENPTkZJR19DUEFfREVCVUcgaXMg bm90IHNldApDT05GSUdfT1BUSU1JWkVfSU5MSU5JTkc9eQojIENPTkZJR19ERUJVR19TVFJJQ1Rf VVNFUl9DT1BZX0NIRUNLUyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX05NSV9TRUxGVEVTVCBp cyBub3Qgc2V0CgojCiMgU2VjdXJpdHkgb3B0aW9ucwojCkNPTkZJR19LRVlTPXkKQ09ORklHX1RS VVNURURfS0VZUz1tCkNPTkZJR19FTkNSWVBURURfS0VZUz1tCkNPTkZJR19LRVlTX0RFQlVHX1BS T0NfS0VZUz15CiMgQ09ORklHX1NFQ1VSSVRZX0RNRVNHX1JFU1RSSUNUIGlzIG5vdCBzZXQKQ09O RklHX1NFQ1VSSVRZPXkKQ09ORklHX1NFQ1VSSVRZRlM9eQpDT05GSUdfU0VDVVJJVFlfTkVUV09S Sz15CkNPTkZJR19TRUNVUklUWV9ORVRXT1JLX1hGUk09eQojIENPTkZJR19TRUNVUklUWV9QQVRI IGlzIG5vdCBzZXQKQ09ORklHX0lOVEVMX1RYVD15CkNPTkZJR19MU01fTU1BUF9NSU5fQUREUj02 NTUzNgpDT05GSUdfU0VDVVJJVFlfU0VMSU5VWD15CkNPTkZJR19TRUNVUklUWV9TRUxJTlVYX0JP T1RQQVJBTT15CkNPTkZJR19TRUNVUklUWV9TRUxJTlVYX0JPT1RQQVJBTV9WQUxVRT0xCkNPTkZJ R19TRUNVUklUWV9TRUxJTlVYX0RJU0FCTEU9eQpDT05GSUdfU0VDVVJJVFlfU0VMSU5VWF9ERVZF TE9QPXkKQ09ORklHX1NFQ1VSSVRZX1NFTElOVVhfQVZDX1NUQVRTPXkKQ09ORklHX1NFQ1VSSVRZ X1NFTElOVVhfQ0hFQ0tSRVFQUk9UX1ZBTFVFPTEKIyBDT05GSUdfU0VDVVJJVFlfU0VMSU5VWF9Q T0xJQ1lEQl9WRVJTSU9OX01BWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZX1NNQUNLIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlfVE9NT1lPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VD VVJJVFlfQVBQQVJNT1IgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWV9ZQU1BIGlzIG5vdCBz ZXQKIyBDT05GSUdfSU1BIGlzIG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfU0VDVVJJVFlfU0VMSU5V WD15CiMgQ09ORklHX0RFRkFVTFRfU0VDVVJJVFlfREFDIGlzIG5vdCBzZXQKQ09ORklHX0RFRkFV TFRfU0VDVVJJVFk9InNlbGludXgiCkNPTkZJR19YT1JfQkxPQ0tTPW0KQ09ORklHX0FTWU5DX0NP UkU9bQpDT05GSUdfQVNZTkNfTUVNQ1BZPW0KQ09ORklHX0FTWU5DX1hPUj1tCkNPTkZJR19BU1lO Q19QUT1tCkNPTkZJR19BU1lOQ19SQUlENl9SRUNPVj1tCkNPTkZJR19BU1lOQ19UWF9ESVNBQkxF X1BRX1ZBTF9ETUE9eQpDT05GSUdfQVNZTkNfVFhfRElTQUJMRV9YT1JfVkFMX0RNQT15CkNPTkZJ R19DUllQVE89eQoKIwojIENyeXB0byBjb3JlIG9yIGhlbHBlcgojCkNPTkZJR19DUllQVE9fRklQ Uz15CkNPTkZJR19DUllQVE9fQUxHQVBJPXkKQ09ORklHX0NSWVBUT19BTEdBUEkyPXkKQ09ORklH X0NSWVBUT19BRUFEPXkKQ09ORklHX0NSWVBUT19BRUFEMj15CkNPTkZJR19DUllQVE9fQkxLQ0lQ SEVSPXkKQ09ORklHX0NSWVBUT19CTEtDSVBIRVIyPXkKQ09ORklHX0NSWVBUT19IQVNIPXkKQ09O RklHX0NSWVBUT19IQVNIMj15CkNPTkZJR19DUllQVE9fUk5HPXkKQ09ORklHX0NSWVBUT19STkcy PXkKQ09ORklHX0NSWVBUT19QQ09NUD1tCkNPTkZJR19DUllQVE9fUENPTVAyPXkKQ09ORklHX0NS WVBUT19NQU5BR0VSPXkKQ09ORklHX0NSWVBUT19NQU5BR0VSMj15CkNPTkZJR19DUllQVE9fVVNF Uj1tCiMgQ09ORklHX0NSWVBUT19NQU5BR0VSX0RJU0FCTEVfVEVTVFMgaXMgbm90IHNldApDT05G SUdfQ1JZUFRPX0dGMTI4TVVMPXkKQ09ORklHX0NSWVBUT19OVUxMPW0KQ09ORklHX0NSWVBUT19Q Q1JZUFQ9bQpDT05GSUdfQ1JZUFRPX1dPUktRVUVVRT15CkNPTkZJR19DUllQVE9fQ1JZUFREPXkK Q09ORklHX0NSWVBUT19BVVRIRU5DPW0KQ09ORklHX0NSWVBUT19URVNUPW0KQ09ORklHX0NSWVBU T19BQkxLX0hFTFBFUl9YODY9eQpDT05GSUdfQ1JZUFRPX0dMVUVfSEVMUEVSX1g4Nj1tCgojCiMg QXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhCiMKQ09ORklHX0NS WVBUT19DQ009bQpDT05GSUdfQ1JZUFRPX0dDTT1tCkNPTkZJR19DUllQVE9fU0VRSVY9eQoKIwoj IEJsb2NrIG1vZGVzCiMKQ09ORklHX0NSWVBUT19DQkM9eQpDT05GSUdfQ1JZUFRPX0NUUj15CkNP TkZJR19DUllQVE9fQ1RTPW0KQ09ORklHX0NSWVBUT19FQ0I9eQpDT05GSUdfQ1JZUFRPX0xSVz15 CkNPTkZJR19DUllQVE9fUENCQz1tCkNPTkZJR19DUllQVE9fWFRTPXkKCiMKIyBIYXNoIG1vZGVz CiMKQ09ORklHX0NSWVBUT19ITUFDPXkKQ09ORklHX0NSWVBUT19YQ0JDPW0KQ09ORklHX0NSWVBU T19WTUFDPW0KCiMKIyBEaWdlc3QKIwpDT05GSUdfQ1JZUFRPX0NSQzMyQz15CkNPTkZJR19DUllQ VE9fQ1JDMzJDX0lOVEVMPW0KQ09ORklHX0NSWVBUT19HSEFTSD1tCkNPTkZJR19DUllQVE9fTUQ0 PW0KQ09ORklHX0NSWVBUT19NRDU9eQpDT05GSUdfQ1JZUFRPX01JQ0hBRUxfTUlDPW0KQ09ORklH X0NSWVBUT19STUQxMjg9bQpDT05GSUdfQ1JZUFRPX1JNRDE2MD1tCkNPTkZJR19DUllQVE9fUk1E MjU2PW0KQ09ORklHX0NSWVBUT19STUQzMjA9bQpDT05GSUdfQ1JZUFRPX1NIQTE9eQpDT05GSUdf Q1JZUFRPX1NIQTFfU1NTRTM9bQpDT05GSUdfQ1JZUFRPX1NIQTI1Nj15CkNPTkZJR19DUllQVE9f U0hBNTEyPW0KQ09ORklHX0NSWVBUT19UR1IxOTI9bQpDT05GSUdfQ1JZUFRPX1dQNTEyPW0KQ09O RklHX0NSWVBUT19HSEFTSF9DTE1VTF9OSV9JTlRFTD1tCgojCiMgQ2lwaGVycwojCkNPTkZJR19D UllQVE9fQUVTPXkKQ09ORklHX0NSWVBUT19BRVNfWDg2XzY0PXkKQ09ORklHX0NSWVBUT19BRVNf TklfSU5URUw9eQpDT05GSUdfQ1JZUFRPX0FOVUJJUz1tCkNPTkZJR19DUllQVE9fQVJDND1tCkNP TkZJR19DUllQVE9fQkxPV0ZJU0g9bQpDT05GSUdfQ1JZUFRPX0JMT1dGSVNIX0NPTU1PTj1tCkNP TkZJR19DUllQVE9fQkxPV0ZJU0hfWDg2XzY0PW0KQ09ORklHX0NSWVBUT19DQU1FTExJQT1tCkNP TkZJR19DUllQVE9fQ0FNRUxMSUFfWDg2XzY0PW0KQ09ORklHX0NSWVBUT19DQVNUNT1tCkNPTkZJ R19DUllQVE9fQ0FTVDY9bQpDT05GSUdfQ1JZUFRPX0RFUz1tCkNPTkZJR19DUllQVE9fRkNSWVBU PW0KQ09ORklHX0NSWVBUT19LSEFaQUQ9bQpDT05GSUdfQ1JZUFRPX1NBTFNBMjA9bQpDT05GSUdf Q1JZUFRPX1NBTFNBMjBfWDg2XzY0PW0KQ09ORklHX0NSWVBUT19TRUVEPW0KQ09ORklHX0NSWVBU T19TRVJQRU5UPW0KQ09ORklHX0NSWVBUT19TRVJQRU5UX1NTRTJfWDg2XzY0PW0KQ09ORklHX0NS WVBUT19TRVJQRU5UX0FWWF9YODZfNjQ9bQpDT05GSUdfQ1JZUFRPX1RFQT1tCkNPTkZJR19DUllQ VE9fVFdPRklTSD1tCkNPTkZJR19DUllQVE9fVFdPRklTSF9DT01NT049bQpDT05GSUdfQ1JZUFRP X1RXT0ZJU0hfWDg2XzY0PW0KQ09ORklHX0NSWVBUT19UV09GSVNIX1g4Nl82NF8zV0FZPW0KQ09O RklHX0NSWVBUT19UV09GSVNIX0FWWF9YODZfNjQ9bQoKIwojIENvbXByZXNzaW9uCiMKQ09ORklH X0NSWVBUT19ERUZMQVRFPW0KQ09ORklHX0NSWVBUT19aTElCPW0KQ09ORklHX0NSWVBUT19MWk89 bQoKIwojIFJhbmRvbSBOdW1iZXIgR2VuZXJhdGlvbgojCkNPTkZJR19DUllQVE9fQU5TSV9DUFJO Rz1tCkNPTkZJR19DUllQVE9fVVNFUl9BUEk9eQpDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX0hBU0g9 eQpDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX1NLQ0lQSEVSPXkKQ09ORklHX0NSWVBUT19IVz15CkNP TkZJR19DUllQVE9fREVWX1BBRExPQ0s9bQpDT05GSUdfQ1JZUFRPX0RFVl9QQURMT0NLX0FFUz1t CkNPTkZJR19DUllQVE9fREVWX1BBRExPQ0tfU0hBPW0KQ09ORklHX0FTWU1NRVRSSUNfS0VZX1RZ UEU9eQpDT05GSUdfQVNZTU1FVFJJQ19QVUJMSUNfS0VZX1NVQlRZUEU9eQpDT05GSUdfUFVCTElD X0tFWV9BTEdPX1JTQT15CkNPTkZJR19YNTA5X0NFUlRJRklDQVRFX1BBUlNFUj15CkNPTkZJR19F RklfU0lHTkFUVVJFX0xJU1RfUEFSU0VSPXkKQ09ORklHX0hBVkVfS1ZNPXkKQ09ORklHX0hBVkVf S1ZNX0lSUUNISVA9eQpDT05GSUdfSEFWRV9LVk1fRVZFTlRGRD15CkNPTkZJR19LVk1fQVBJQ19B UkNISVRFQ1RVUkU9eQpDT05GSUdfS1ZNX01NSU89eQpDT05GSUdfS1ZNX0FTWU5DX1BGPXkKQ09O RklHX0hBVkVfS1ZNX01TST15CkNPTkZJR19WSVJUVUFMSVpBVElPTj15CkNPTkZJR19LVk09bQpD T05GSUdfS1ZNX0lOVEVMPW0KQ09ORklHX0tWTV9BTUQ9bQpDT05GSUdfS1ZNX01NVV9BVURJVD15 CkNPTkZJR19WSE9TVF9ORVQ9bQpDT05GSUdfVENNX1ZIT1NUPW0KQ09ORklHX0JJTkFSWV9QUklO VEY9eQoKIwojIExpYnJhcnkgcm91dGluZXMKIwpDT05GSUdfUkFJRDZfUFE9bQpDT05GSUdfQklU UkVWRVJTRT15CkNPTkZJR19HRU5FUklDX1NUUk5DUFlfRlJPTV9VU0VSPXkKQ09ORklHX0dFTkVS SUNfU1RSTkxFTl9VU0VSPXkKQ09ORklHX0dFTkVSSUNfRklORF9GSVJTVF9CSVQ9eQpDT05GSUdf R0VORVJJQ19QQ0lfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19JT01BUD15CkNPTkZJR19HRU5FUklD X0lPPXkKQ09ORklHX0NSQ19DQ0lUVD1tCkNPTkZJR19DUkMxNj15CkNPTkZJR19DUkNfVDEwRElG PXkKQ09ORklHX0NSQ19JVFVfVD1tCkNPTkZJR19DUkMzMj15CiMgQ09ORklHX0NSQzMyX1NFTEZU RVNUIGlzIG5vdCBzZXQKQ09ORklHX0NSQzMyX1NMSUNFQlk4PXkKIyBDT05GSUdfQ1JDMzJfU0xJ Q0VCWTQgaXMgbm90IHNldAojIENPTkZJR19DUkMzMl9TQVJXQVRFIGlzIG5vdCBzZXQKIyBDT05G SUdfQ1JDMzJfQklUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDNyBpcyBub3Qgc2V0CkNPTkZJR19M SUJDUkMzMkM9bQpDT05GSUdfQ1JDOD1tCkNPTkZJR19aTElCX0lORkxBVEU9eQpDT05GSUdfWkxJ Ql9ERUZMQVRFPW0KQ09ORklHX0xaT19DT01QUkVTUz15CkNPTkZJR19MWk9fREVDT01QUkVTUz15 CkNPTkZJR19YWl9ERUM9eQpDT05GSUdfWFpfREVDX1g4Nj15CkNPTkZJR19YWl9ERUNfUE9XRVJQ Qz15CkNPTkZJR19YWl9ERUNfSUE2ND15CkNPTkZJR19YWl9ERUNfQVJNPXkKQ09ORklHX1haX0RF Q19BUk1USFVNQj15CkNPTkZJR19YWl9ERUNfU1BBUkM9eQpDT05GSUdfWFpfREVDX0JDSj15CiMg Q09ORklHX1haX0RFQ19URVNUIGlzIG5vdCBzZXQKQ09ORklHX0RFQ09NUFJFU1NfR1pJUD15CkNP TkZJR19ERUNPTVBSRVNTX0JaSVAyPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpNQT15CkNPTkZJR19E RUNPTVBSRVNTX1haPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpPPXkKQ09ORklHX0dFTkVSSUNfQUxM T0NBVE9SPXkKQ09ORklHX1JFRURfU09MT01PTj1tCkNPTkZJR19SRUVEX1NPTE9NT05fRU5DOD15 CkNPTkZJR19SRUVEX1NPTE9NT05fREVDOD15CkNPTkZJR19URVhUU0VBUkNIPXkKQ09ORklHX1RF WFRTRUFSQ0hfS01QPW0KQ09ORklHX1RFWFRTRUFSQ0hfQk09bQpDT05GSUdfVEVYVFNFQVJDSF9G U009bQpDT05GSUdfQlRSRUU9eQpDT05GSUdfSEFTX0lPTUVNPXkKQ09ORklHX0hBU19JT1BPUlQ9 eQpDT05GSUdfSEFTX0RNQT15CkNPTkZJR19DSEVDS19TSUdOQVRVUkU9eQpDT05GSUdfQ1BVX1JN QVA9eQpDT05GSUdfRFFMPXkKQ09ORklHX05MQVRUUj15CkNPTkZJR19BUkNIX0hBU19BVE9NSUM2 NF9ERUNfSUZfUE9TSVRJVkU9eQpDT05GSUdfTFJVX0NBQ0hFPW0KQ09ORklHX0FWRVJBR0U9eQpD T05GSUdfQ0xaX1RBQj15CkNPTkZJR19DT1JESUM9bQojIENPTkZJR19ERFIgaXMgbm90IHNldApD T05GSUdfTVBJTElCPXkKQ09ORklHX09JRF9SRUdJU1RSWT15Cg== --14dae9340959d5aa6f04d7246e42 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 --14dae9340959d5aa6f04d7246e42-- From xen-users-bounces@lists.xen.org Tue Mar 05 02:44:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 02:44: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 1UChqS-0000ru-RA; Tue, 05 Mar 2013 02:43:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UChqQ-0000rp-OK for xen-users@lists.xen.org; Tue, 05 Mar 2013 02:43:11 +0000 Received: from [85.158.138.51:44671] by server-6.bemta-3.messagelabs.com id E8/F0-11048-DBB55315; Tue, 05 Mar 2013 02:43:09 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1362451385!30234345!1 X-Originating-IP: [209.85.210.178] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11354 invoked from network); 5 Mar 2013 02:43:07 -0000 Received: from mail-ia0-f178.google.com (HELO mail-ia0-f178.google.com) (209.85.210.178) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 02:43:07 -0000 Received: by mail-ia0-f178.google.com with SMTP id y26so5500864iab.37 for ; Mon, 04 Mar 2013 18:43:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZMKD73s4Y6TuPbKUF2z82R5kSohcg1ldji7HOh/Hpwo=; b=F9QZ7+G/gTEPedjOjAaCGzXcUWSQQsxMTGvQdsKv+Ncpx9wOQrZ726zrUJ0pGfed0n j2EMPzqQFvWDdHVUfddmFaNifDZFaNnf+KBhw5bUf+X9uejIS0mHLigWOPXSTlVpIzvp 6uUfhGp2KHRV3HRiHp7jX2Pa530c8uwGjKNSP7eXshTd/oLiXyqFyik5flggs0UhYVl7 cWqdidKlTGQTs76L17S/GLpqYxbBUVo3MtVTVmtz5ge/3/TTmwPiOPh//4k/9nJS7uJ5 rwIs/c1OHJJstImzft1V9COn6kUNe+DIXS2kn1tA7S1zcb5zNGgz6oz85eZE4FFASKeV dcqg== MIME-Version: 1.0 X-Received: by 10.50.183.233 with SMTP id ep9mr4726819igc.87.1362451385131; Mon, 04 Mar 2013 18:43:05 -0800 (PST) Received: by 10.64.92.198 with HTTP; Mon, 4 Mar 2013 18:43:04 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 23:43:04 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Content-Type: multipart/mixed; boundary=14dae9340959d5aa6f04d7246e42 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@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 --14dae9340959d5aa6f04d7246e42 Content-Type: multipart/alternative; boundary=14dae9340959d5aa6a04d7246e40 --14dae9340959d5aa6a04d7246e40 Content-Type: text/plain; charset=ISO-8859-1 Matthias, hi! I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the same on and on (*VGA passthru worked only as secondary device and dom0 freshly rebooted*). As requested, I'm sending you the hvm configuration files from windows-xp and windows-7, my lspci -vv, uname and the kernel configuration file. Do you have any idea how I can make this work? 2013/3/4 Guilherme Suzuki > Alright! > > I'm gonna try catalyst 12-10 (after deinstalling and checking if the > passthru works rebooting and so on). > > I'll send my domU config as soon as I get home. > > One more question: does it matter if I use intel onboard graphics with the > dom0 and xen-pciback(radeon device pci)? Cause that would be the reason > primary VGA passthru did not work... > > Thx, xen guys are awesome! =D > > On Mar 4, 2013 2:07 PM, "Matthias" > wrote: > > Hi, > > good news, since you said your winxp was able to boot with vga > passthrough just fine, your FLR seems to work fine and this might > 'only' be a driver-related problem. > > What you can do is deinstall your catalyst drivers. After rebooting, > Win7 will fallback on a windows-standard driver for the vga but when > it correctly says the vga name (like ATI Radeion HD whatever Series), > it actually is falling back to an older catalyst version which is > shipped per default with windows. I have found this much more stable > on reboots then the newest driver. Also, deinstall Catalyst / Vision > control center and at best everything the catalyst installer lets you > deinstall. > > If vga passthrough works without all the drivers and you really want > the latest and greatest catalyst, i recommend not using the latest > 13-1 because it creates a similar behavior you mentioned on my > machine. But catalyst 12-10 seems to work fine, so i would advice you > trying that one. > > > If it still doesn't work with deinstalled drivers, we can try a patch > i'm currently testing.. But this the patch is somewhat complicated to > install, let's stick with the simple things for the moment. > > Also, your domU config still would be of help ruling out some > misconfiguration there.. > > > > 2013/3/4 Guilherme Suzuki : > > > Sorry (hit send). > > > > So, the radeon device tells it couldnt start itself (code 10) and cirrus > > d... > > -- Grato, ** *Guilherme Suzuki* Consultor em TI para projetos Microsoft *http://www.guilhermesuzuki.com* 11 - 992360535 11 - 20990757 --14dae9340959d5aa6a04d7246e40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Matthias, hi!

I've tried Cataly= st 12.10 and even 12.1, but xen behavior kept the same on and on (VGA pa= ssthru worked only as secondary device and dom0 freshly rebooted). As r= equested, I'm sending you the hvm configuration files from windows-xp a= nd windows-7, my lspci -vv, uname and the kernel configuration file.

Do you have any idea how I can make this work?

=


2013/3/= 4 Guilherme Suzuki <suzuki.gui@gmail.com>

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the= passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with t= he dom0 and xen-pciback(radeon device pci)? Cause that would be the reason = primary VGA passthru did not work...

Thx, xen guys are awesome! =3DD

On Mar 4, 2013 2:07= PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote= :

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch i'm currently testing.. But this the patch is somewhat complicated to install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Sorry (hit send).
>
> So, the radeon= device tells it couldnt start itself (code 10) and cirrus
=
> d...




--
Grato,
Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=A0
--14dae9340959d5aa6a04d7246e40-- --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name="windows-xp.hvm" Content-Disposition: attachment; filename="windows-xp.hvm" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1uw0 ICAgI2tlcm5lbCA9ICJodm1sb2FkZXIiCiAgIGJ1aWxkZXI9J2h2bScKICAgbWVtb3J5ID00MDk2 IAogICB2Y3B1cz0yCiAgIG5hbWUgPSAid2luZG93cy14cCIKICAgI3ZpZiA9IFsnYnJpZGdlPXhl bmJyMCddCiAgIGRpc2sgPSBbCgkjIyBwZW4tZHJpdmUKCSMncGh5Oi9kZXYvc2RnLGhkYix3JywK CSdwaHk6L2Rldi92ZzEveHAsaGRhLHcnLAoJJ2ZpbGU6L2hvbWUvc3V6dWtpLmd1aWxoZXJtZS9W TXMvTWljcm9zb2Z0LldpbmRvd3MuWFAuUHJvZmVzc2lvbmFsLlNQMy5JbnRlZ3JhdGVkLkp1bHku MjAxMS5TQVRBLmlzbyxoZGM6Y2Ryb20sciddCiAgIGFjcGkgPSAxCiAgICNkZXZpY2VfbW9kZWwg PSAncWVtdS1kbScKICAgYm9vdD0iZGMiCiAgIHNkbD0wCiAgIHNlcmlhbD0ncHR5JwogICB2bmM9 MQogICB2bmNsaXN0ZW49IiIKICAgdm5jZGlzcGxheT0wCiAgIHZuY3VudXNlZD0xCiAgIHZuY3Bh c3N3ZD0iIgogICBnZnhfcGFzc3RocnU9MAogICBwY2k9WycwMTowMC4wJywnMDE6MDAuMScsJzAw OjFkLjAnXQogICAjdXNiPTEKICAgI3VzYmRldmljZT0iaG9zdDowM2YwOjAwMjQiCiAgICN1c2Jk ZXZpY2U9Imhvc3Q6MDQ2MTo0ZDIwIgo= --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name="windows.hvm" Content-Disposition: attachment; filename="windows.hvm" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1v81 ICAgI2tlcm5lbCA9ICJodm1sb2FkZXIiCiAgIGJ1aWxkZXI9J2h2bScKICAgbWVtb3J5PTgxOTIg CiAgIHZjcHVzPTQKICAgbmFtZSA9ICJ3aW5kb3dzLTciCiAgICN2aWYgPSBbJ2JyaWRnZT14ZW5i cjAnXQogICBkaXNrID0gWwoJJ3BoeTovZGV2L3ZnMS93aW5kb3dzLGhkYSx3JywKCSMncGh5Oi9k ZXYvc2RoLGhkYix3JywKCSdmaWxlOi9ob21lL3N1enVraS5ndWlsaGVybWUvVk1zL2VuX3dpbmRv d3NfN191bHRpbWF0ZV9uX3dpdGhfc3AxX3g2NF9kdmRfdV82Nzc1NDMuaXNvLGhkYzpjZHJvbSxy J10KICAgYWNwaT0xCiAgIGFwaWM9MQogICB4ZW5fZXh0ZW5kZWRfcG93ZXJfbWdtdD0xCiAgICNk ZXZpY2VfbW9kZWwgPSAncWVtdS1kbScKICAgYXJjaD0neDg2XzY0JwogICBocGV0ID0gMQogICBo YXAgPSAxCiAgIHZpcmlkaWFuID0gMQogICBtb25pdG9yPTEKICAgYXVkaW89Im9uIgogICBib290 PSJkYyIKICAgc2RsPTAKICAgc2VyaWFsPSdwdHknCiAgIHZuYz0xCiAgIHZuY2xpc3Rlbj0iIgog ICB2bmNkaXNwbGF5PTAKICAgdm5jdW51c2VkPTEKICAgdm5jcGFzc3dkPSIiCiAgICN4ZW5fcGxh dGZvcm1fcGNpPTEKICAgZ2Z4X3Bhc3N0aHJ1PTAKICAgcGNpPVsnMDE6MDAuMCcsJzAxOjAwLjEn LCcwMDoxZC4wJ10KICAgcGNpX21zaXRyYW5zbGF0ZSA9IDEKICAgcGNpX3Bvd2VyX21nbXQgPSAx CiAgIGFjcGlfczMgPSAxCiAgIGFjcGlfczQgPSAxCiAgICN1c2I9MQogICAjdXNiZGV2aWNlPSJ0 YWJsZXQiCiAgICN1c2JkZXZpY2U9Imhvc3Q6MDNmMDowMDI0IgogICAjdXNiZGV2aWNlPSJob3N0 OjA0NjE6NGQyMCIK --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name=lspci-txt Content-Disposition: attachment; filename=lspci-txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1vi2 MDA6MDAuMCBIb3N0IGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24gMm5kIEdlbmVyYXRpb24gQ29y ZSBQcm9jZXNzb3IgRmFtaWx5IERSQU0gQ29udHJvbGxlciAocmV2IDA5KQoJU3Vic3lzdGVtOiBH aWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgNTAwMAoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01h c3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VS Ui0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCKyBQ YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVS Ui0gSU5UeC0KCUxhdGVuY3k6IDAKCUNhcGFiaWxpdGllczogW2UwXSBWZW5kb3IgU3BlY2lmaWMg SW5mb3JtYXRpb246IExlbj0wYyA8Pz4KCjAwOjAxLjAgUENJIGJyaWRnZTogSW50ZWwgQ29ycG9y YXRpb24gWGVvbiBFMy0xMjAwLzJuZCBHZW5lcmF0aW9uIENvcmUgUHJvY2Vzc29yIEZhbWlseSBQ Q0kgRXhwcmVzcyBSb290IFBvcnQgKHJldiAwOSkgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVd KQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czog Q2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENhY2hlIExp bmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTAxLCBzdWJvcmRp bmF0ZT0wMSwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlkZ2U6IDAwMDBlMDAwLTAwMDBl ZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjdiMDAwMDAtZjdiZmZmZmYKCVByZWZldGNoYWJs ZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBlMDAwMDAwMC0wMDAwMDAwMGVmZmZmZmZm CglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+ VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0 eS0gU0VSUi0gTm9JU0EtIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rt ci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6 IFs4OF0gU3Vic3lzdGVtOiBHaWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgNTAwMAoJQ2FwYWJp bGl0aWVzOiBbODBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0g RFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xk KykKCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBN RS0KCUNhcGFiaWxpdGllczogWzkwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2 NGJpdC0KCQlBZGRyZXNzOiBmZWUwMDI5OCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0aWVzOiBbYTBd IEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3QrKSwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXls b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzCgkJ CUV4dFRhZy0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFi bGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkLSBFeHRUYWctIFBo YW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVh ZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVu c3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICMyLCBTcGVlZCA1R1Qv cywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MjU2bnMsIEwxIDw0dXMKCQkJ Q2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdCsKCQlMbmtDdGw6CUFTUE0gRGlzYWJs ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gt IENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41 R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQr IEFCV01nbXQrCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3cklu ZC0gSG90UGx1Zy0gU3VycHJpc2UtCgkJCVNsb3QgIzEsIFBvd2VyTGltaXQgNzUuMDAwVzsgSW50 ZXJsb2NrLSBOb0NvbXBsKwoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0g UHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5r bm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stCgkJU2x0U3RhOglTdGF0dXM6 IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0KCQkJ Q2hhbmdlZDogTVJMLSBQcmVzRGV0LSBMaW5rU3RhdGUtCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFi bGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290 Q2FwOiBDUlNWaXNpYmxlLQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBN RVBlbmRpbmctCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBU aW1lb3V0RGlzLSwgTFRSKywgT0JGRiBOb3QgU3VwcG9ydGVkIEFSSUZ3ZC0KCQlEZXZDdGwyOiBD b21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0sIExUUi0sIE9CRkYg RGlzYWJsZWQgQVJJRndkLQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50 ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJh dGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBD b21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNp cyBMZXZlbDogLTZkQiwgRXF1YWxpemF0aW9uQ29tcGxldGUtLCBFcXVhbGl6YXRpb25QaGFzZTEt CgkJCSBFcXVhbGl6YXRpb25QaGFzZTItLCBFcXVhbGl6YXRpb25QaGFzZTMtLCBMaW5rRXF1YWxp emF0aW9uUmVxdWVzdC0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmlydHVhbCBDaGFubmVsCgkJ Q2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTEKCQlBcmI6CUZpeGVkLSBX UlIzMi0gV1JSNjQtIFdSUjEyOC0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQKCQlTdGF0dXM6CUlu UHJvZ3Jlc3MtCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25v b3BUcmFucy0KCQkJQXJiOglGaXhlZCsgV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdS UjI1Ni0KCQkJQ3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZgoJCQlT dGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQoJQ2FwYWJpbGl0aWVzOiBbMTQwIHYxXSBS b290IENvbXBsZXggTGluawoJCURlc2M6CVBvcnROdW1iZXI9MDIgQ29tcG9uZW50SUQ9MDEgRWx0 VHlwZT1Db25maWcKCQlMaW5rMDoJRGVzYzoJVGFyZ2V0UG9ydD0wMCBUYXJnZXRDb21wb25lbnQ9 MDEgQXNzb2NSQ1JCLSBMaW5rVHlwZT1NZW1NYXBwZWQgTGlua1ZhbGlkKwoJCQlBZGRyOgkwMDAw MDAwMGZlZDE5MDAwCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCjAwOjAyLjAgVkdB IGNvbXBhdGlibGUgY29udHJvbGxlcjogSW50ZWwgQ29ycG9yYXRpb24gMm5kIEdlbmVyYXRpb24g Q29yZSBQcm9jZXNzb3IgRmFtaWx5IEludGVncmF0ZWQgR3JhcGhpY3MgQ29udHJvbGxlciAocmV2 IDA5KSAocHJvZy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQoJU3Vic3lzdGVtOiBHaWdhLWJ5dGUg VGVjaG5vbG9neSBEZXZpY2UgZDAwMAoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlci0gU3Bl Y0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy Qi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCKyBQYXJFcnItIERF VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0K CUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxNgoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm NzQwMDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00TV0KCVJlZ2lvbiAyOiBN ZW1vcnkgYXQgZDAwMDAwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZNXQoJUmVn aW9uIDQ6IEkvTyBwb3J0cyBhdCBmMDAwIFtzaXplPTY0XQoJRXhwYW5zaW9uIFJPTSBhdCA8dW5h c3NpZ25lZD4gW2Rpc2FibGVkXQoJQ2FwYWJpbGl0aWVzOiBbOTBdIE1TSTogRW5hYmxlLSBDb3Vu dD0xLzEgTWFza2FibGUtIDY0Yml0LQoJCUFkZHJlc3M6IDAwMDAwMDAwICBEYXRhOiAwMDAwCglD YXBhYmlsaXRpZXM6IFtkMF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFnczogUE1F Q2xrLSBEU0krIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxE M2NvbGQtKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxl PTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbYTRdIFBDSSBBZHZhbmNlZCBGZWF0dXJlcwoJCUFGQ2Fw OiBUUCsgRkxSKwoJCUFGQ3RybDogRkxSLQoJCUFGU3RhdHVzOiBUUC0KCjAwOjE0LjAgVVNCIGNv bnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIDcgU2VyaWVzL0MyMTAgU2VyaWVzIENoaXBzZXQg RmFtaWx5IFVTQiB4SENJIEhvc3QgQ29udHJvbGxlciAocmV2IDA0KSAocHJvZy1pZiAzMCBbWEhD SV0pCglTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSA1MDA3CglDb250cm9s OiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6 LSBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8 TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwCglJbnRlcnJ1cHQ6IHBpbiBB IHJvdXRlZCB0byBJUlEgOTQKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjdjMDAwMDAgKDY0LWJpdCwg bm9uLXByZWZldGNoYWJsZSkgW3NpemU9NjRLXQoJQ2FwYWJpbGl0aWVzOiBbNzBdIFBvd2VyIE1h bmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJl bnQ9Mzc1bUEgUE1FKEQwLSxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9T b2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBb ODBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzggTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAw MDAwMDAwZmVlMDAyZjggIERhdGE6IDAwMDAKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiB4aGNpX2hj ZAoKMDA6MTYuMCBDb21tdW5pY2F0aW9uIGNvbnRyb2xsZXI6IEludGVsIENvcnBvcmF0aW9uIDcg U2VyaWVzL0MyMTAgU2VyaWVzIENoaXBzZXQgRmFtaWx5IE1FSSBDb250cm9sbGVyICMxIChyZXYg MDQpCglTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSAxYzNhCglDb250cm9s OiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6 LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1B Ym9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJSW50ZXJydXB0OiBwaW4gQSBy b3V0ZWQgdG8gSVJRIDk2CglSZWdpb24gMDogTWVtb3J5IGF0IGY3YzFhMDAwICg2NC1iaXQsIG5v bi1wcmVmZXRjaGFibGUpIFtzaXplPTE2XQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFn ZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9 MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIE5vU29mdFJz dCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzhjXSBN U0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsKCQlBZGRyZXNzOiAwMDAwMDAw MGZlZTAwMzM4ICBEYXRhOiAwMDAwCglLZXJuZWwgZHJpdmVyIGluIHVzZTogbWVpCgowMDoxYS4w IFVTQiBjb250cm9sbGVyOiBJbnRlbCBDb3Jwb3JhdGlvbiA3IFNlcmllcy9DMjEwIFNlcmllcyBD aGlwc2V0IEZhbWlseSBVU0IgRW5oYW5jZWQgSG9zdCBDb250cm9sbGVyICMyIChyZXYgMDQpIChw cm9nLWlmIDIwIFtFSENJXSkKCVN1YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xvZ3kgRGV2aWNl IDUwMDYKCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0g VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0 dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJv cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCUlu dGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxNgoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmN2Mx ODAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xS10KCUNhcGFiaWxpdGllczog WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt IEQyLSBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlT dGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNh cGFiaWxpdGllczogWzU4XSBEZWJ1ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBhMAoJQ2FwYWJpbGl0 aWVzOiBbOThdIFBDSSBBZHZhbmNlZCBGZWF0dXJlcwoJCUFGQ2FwOiBUUCsgRkxSKwoJCUFGQ3Ry bDogRkxSLQoJCUFGU3RhdHVzOiBUUCsKCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZAoK MDA6MWIuMCBBdWRpbyBkZXZpY2U6IEludGVsIENvcnBvcmF0aW9uIDcgU2VyaWVzL0MyMTAgU2Vy aWVzIENoaXBzZXQgRmFtaWx5IEhpZ2ggRGVmaW5pdGlvbiBBdWRpbyBDb250cm9sbGVyIChyZXYg MDQpCglTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSBhMDE0CglDb250cm9s OiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6 LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1B Ym9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2 NCBieXRlcwoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDMKCVJlZ2lvbiAwOiBNZW1v cnkgYXQgZjdjMTAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MTZLXQoJQ2Fw YWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNs ay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9NTVtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQz Y29sZCspCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9 MCBQTUUtCglDYXBhYmlsaXRpZXM6IFs2MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJs ZS0gNjRiaXQrCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMAoJQ2FwYWJp bGl0aWVzOiBbNzBdIEV4cHJlc3MgKHYxKSBSb290IENvbXBsZXggSW50ZWdyYXRlZCBFbmRwb2lu dCwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExh dGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzCgkJCUV4dFRhZy0gUkJFLSBGTFJlc2V0KwoJCURldkN0 bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y dGVkLQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlN YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMKCQlEZXZTdGE6CUNvcnJF cnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyKyBUcmFuc1BlbmQtCgkJ TG5rQ2FwOglQb3J0ICMwLCBTcGVlZCB1bmtub3duLCBXaWR0aCB4MCwgQVNQTSB1bmtub3duLCBM YXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0g QndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs ay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxu a1N0YToJU3BlZWQgdW5rbm93biwgV2lkdGggeDAsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExB Y3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmlydHVhbCBD aGFubmVsCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTEKCQlBcmI6 CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQKCQlT dGF0dXM6CUluUHJvZ3Jlc3MtCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3Rz PTEgUmVqU25vb3BUcmFucy0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRX UlIxMjgtIFdSUjI1Ni0KCQkJQ3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9W Qz0wMQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQoJCVZDMToJQ2FwczoJUEFU T2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtCgkJCUFyYjoJRml4ZWQtIFdS UjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtCgkJCUN0cmw6CUVuYWJsZSsgSUQ9 MSBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9MjIKCQkJU3RhdHVzOglOZWdvUGVuZGluZy0gSW5Qcm9n cmVzcy0KCUNhcGFiaWxpdGllczogWzEzMCB2MV0gUm9vdCBDb21wbGV4IExpbmsKCQlEZXNjOglQ b3J0TnVtYmVyPTBmIENvbXBvbmVudElEPTAwIEVsdFR5cGU9Q29uZmlnCgkJTGluazA6CURlc2M6 CVRhcmdldFBvcnQ9MDAgVGFyZ2V0Q29tcG9uZW50PTAwIEFzc29jUkNSQi0gTGlua1R5cGU9TWVt TWFwcGVkIExpbmtWYWxpZCsKCQkJQWRkcjoJMDAwMDAwMDBmZWQxYzAwMAoKMDA6MWMuMCBQQ0kg YnJpZGdlOiBJbnRlbCBDb3Jwb3JhdGlvbiA3IFNlcmllcy9DMjEwIFNlcmllcyBDaGlwc2V0IEZh bWlseSBQQ0kgRXhwcmVzcyBSb290IFBvcnQgMSAocmV2IGM0KSAocHJvZy1pZiAwMCBbTm9ybWFs IGRlY29kZV0pCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJ U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwg Q2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDIs IHN1Ym9yZGluYXRlPTAyLCBzZWMtbGF0ZW5jeT0wCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0g RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0KyA8 U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eS0gU0VSUi0gTm9JU0EtIFZHQS0gTUFib3J0 LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQt IERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjIpIFJvb3QgUG9y dCAoU2xvdCspLCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1 bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFnLSBSQkUrIEZMUmVzZXQt CgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0g VW5zdXBwb3J0ZWQtCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25v b3AtCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcwoJCURldlN0 YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3IrIFRyYW5z UGVuZC0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtu b3duLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDwxNnVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFj dFJlcCsgQndOb3QtCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs ZWQtIFJldHJhaW4tIENvbW1DbGstCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJX SW50LSBBdXRCV0ludC0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgwLCBUckVyci0g VHJhaW4rIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtCgkJU2x0Q2FwOglBdHRu QnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtCgkJ CVNsb3QgIzAsIFBvd2VyTGltaXQgMTAuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKwoJCVNsdEN0 bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEt IExpbmtDaGctCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBv d2VyLSBJbnRlcmxvY2stCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwt IENtZENwbHQtIFByZXNEZXQtIEludGVybG9jay0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0LSBM aW5rU3RhdGUtCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0 YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQoJCVJvb3RT dGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctCgkJRGV2Q2FwMjogQ29t cGxldGlvbiBUaW1lb3V0OiBSYW5nZSBCQywgVGltZW91dERpcyssIExUUi0sIE9CRkYgTm90IFN1 cHBvcnRlZCBBUklGd2QtCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVzIHRvIDUw bXMsIFRpbWVvdXREaXMtLCBMVFItLCBPQkZGIERpc2FibGVkIEFSSUZ3ZC0KCQlMbmtDdGwyOiBU YXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0KCQkJ IFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENv bXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC CgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCLCBFcXVhbGl6YXRp b25Db21wbGV0ZS0sIEVxdWFsaXphdGlvblBoYXNlMS0KCQkJIEVxdWFsaXphdGlvblBoYXNlMi0s IEVxdWFsaXphdGlvblBoYXNlMy0sIExpbmtFcXVhbGl6YXRpb25SZXF1ZXN0LQoJQ2FwYWJpbGl0 aWVzOiBbODBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQoJCUFkZHJl c3M6IDAwMDAwMDAwICBEYXRhOiAwMDAwCglDYXBhYmlsaXRpZXM6IFs5MF0gU3Vic3lzdGVtOiBH aWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgNTAwMQoJQ2FwYWJpbGl0aWVzOiBbYTBdIFBvd2Vy IE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1 cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIE5v U29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUtlcm5lbCBkcml2ZXIg aW4gdXNlOiBwY2llcG9ydAoKMDA6MWMuNCBQQ0kgYnJpZGdlOiBJbnRlbCBDb3Jwb3JhdGlvbiA3 IFNlcmllcy9DMjEwIFNlcmllcyBDaGlwc2V0IEZhbWlseSBQQ0kgRXhwcmVzcyBSb290IFBvcnQg NSAocmV2IGM0KSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pCglDb250cm9sOiBJL08rIE1l bSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBw aW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZh c3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF UlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJ QnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDMsIHN1Ym9yZGluYXRlPTAzLCBzZWMtbGF0ZW5j eT0wCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjdhMDAwMDAtZjdhZmZmZmYKCVNlY29uZGFyeSBz dGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv cnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5LSBTRVJSLSBOb0lT QS0gVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1y LSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNz ICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjgg Ynl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlFeHRUYWct IFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24t RmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMt IEF1eFB3ci0gTm9Tbm9vcC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4 IGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt IEF1eFB3cisgVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgNUdUL3MsIFdpZHRo IHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDUxMm5zLCBMMSA8MTZ1cwoJCQlDbG9ja1BN LSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0gQ2xvY2tQ TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCA1R1QvcywgV2lk dGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdCsK CQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVn LSBTdXJwcmlzZS0KCQkJU2xvdCAjNCwgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2stIE5v Q29tcGwrCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBD bWRDcGx0LSBIUElycS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJ bmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0g UG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJCQlDaGFuZ2VkOiBN UkwtIFByZXNEZXQtIExpbmtTdGF0ZS0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9u LUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQoJCVJvb3RDYXA6IENSU1Zp c2libGUtCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0K CQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEJDLCBUaW1lb3V0RGlzKywgTFRS LSwgT0JGRiBOb3QgU3VwcG9ydGVkIEFSSUZ3ZC0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVv dXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0sIExUUi0sIE9CRkYgRGlzYWJsZWQgQVJJRndk LQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBT cGVlZERpcy0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50 ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVt cGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQiwg RXF1YWxpemF0aW9uQ29tcGxldGUtLCBFcXVhbGl6YXRpb25QaGFzZTEtCgkJCSBFcXVhbGl6YXRp b25QaGFzZTItLCBFcXVhbGl6YXRpb25QaGFzZTMtLCBMaW5rRXF1YWxpemF0aW9uUmVxdWVzdC0K CUNhcGFiaWxpdGllczogWzgwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJp dC0KCQlBZGRyZXNzOiAwMDAwMDAwMCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0aWVzOiBbOTBdIFN1 YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xvZ3kgRGV2aWNlIDUwMDEKCUNhcGFiaWxpdGllczog W2EwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspCgkJU3Rh dHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglLZXJu ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQKCjAwOjFjLjUgUENJIGJyaWRnZTogSW50ZWwgQ29y cG9yYXRpb24gODI4MDEgUENJIEJyaWRnZSAocmV2IGM0KSAocHJvZy1pZiAwMSBbU3VidHJhY3Rp dmUgZGVjb2RlXSkKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+ VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAw LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0w NCwgc3Vib3JkaW5hdGU9MDUsIHNlYy1sYXRlbmN5PTAKCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6 LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQr IDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5LSBTRVJSLSBOb0lTQS0gVkdBLSBNQWJv cnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNjVG1yU3Rh dC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNzICh2MikgUm9vdCBQ b3J0IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50 RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlFeHRUYWctIFJCRSsgRkxSZXNl dC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs LSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T bm9vcC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzCgkJRGV2 U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3cisgVHJh bnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjNiwgU3BlZWQgNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVu a25vd24sIExhdGVuY3kgTDAgPDF1cywgTDEgPDE2dXMKCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExM QWN0UmVwKyBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNh YmxlZC0gUmV0cmFpbi0gQ29tbUNsay0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g QldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy LSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0KCQlTbHRDYXA6CUF0 dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0K CQkJU2xvdCAjNSwgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrCgkJU2x0 Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUEly cS0gTGlua0NoZy0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwg UG93ZXItIEludGVybG9jay0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1S TC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQt IExpbmtTdGF0ZS0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJG YXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQoJCVJvb3RDYXA6IENSU1Zpc2libGUtCgkJUm9v dFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0KCQlEZXZDYXAyOiBD b21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEJDLCBUaW1lb3V0RGlzKywgTFRSLSwgT0JGRiBOb3Qg U3VwcG9ydGVkIEFSSUZ3ZC0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8g NTBtcywgVGltZW91dERpcy0sIExUUi0sIE9CRkYgRGlzYWJsZWQgQVJJRndkLQoJCUxua0N0bDI6 IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0KCQkJ IFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENv bXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC CgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCLCBFcXVhbGl6YXRp b25Db21wbGV0ZS0sIEVxdWFsaXphdGlvblBoYXNlMS0KCQkJIEVxdWFsaXphdGlvblBoYXNlMi0s IEVxdWFsaXphdGlvblBoYXNlMy0sIExpbmtFcXVhbGl6YXRpb25SZXF1ZXN0LQoJQ2FwYWJpbGl0 aWVzOiBbODBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQoJCUFkZHJl c3M6IDAwMDAwMDAwICBEYXRhOiAwMDAwCglDYXBhYmlsaXRpZXM6IFs5MF0gU3Vic3lzdGVtOiBH aWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgNTAwMQoJQ2FwYWJpbGl0aWVzOiBbYTBdIFBvd2Vy IE1hbmFnZW1lbnQgdmVyc2lvbiAyCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1 cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIE5v U29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCjAwOjFjLjYgUENJIGJy aWRnZTogSW50ZWwgQ29ycG9yYXRpb24gNyBTZXJpZXMvQzIxMCBTZXJpZXMgQ2hpcHNldCBGYW1p bHkgUENJIEV4cHJlc3MgUm9vdCBQb3J0IDcgKHJldiBjNCkgKHByb2ctaWYgMDAgW05vcm1hbCBk ZWNvZGVdKQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0 YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENh Y2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA2LCBz dWJvcmRpbmF0ZT0wNiwgc2VjLWxhdGVuY3k9MAoJSS9PIGJlaGluZCBicmlkZ2U6IDAwMDBkMDAw LTAwMDBkZmZmCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjc5MDAwMDAtZjc5ZmZmZmYKCVNlY29u ZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQt IDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0KCUJyaWRnZUN0bDogUGFyaXR5LSBTRVJS LSBOb0lTQS0gVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0KCQlQcmlEaXNjVG1yLSBTZWNE aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNhcGFiaWxpdGllczogWzQwXSBF eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9h ZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cwoJCQlF eHRUYWctIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFu dEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcC0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRS ZXEgMTI4IGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1 cHBSZXEtIEF1eFB3cisgVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjNywgU3BlZWQgNUdUL3Ms IFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDUxMm5zLCBMMSA8MTZ1cwoJCQlD bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBEaXNhYmxl ZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKwoJCQlFeHRTeW5jaC0g Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVlZCAyLjVH VC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210KyBB QldNZ210LQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQt IEhvdFBsdWctIFN1cnByaXNlLQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDEwLjAwMFc7IEludGVy bG9jay0gTm9Db21wbCsKCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFBy ZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25v d24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQoJCVNsdFN0YToJU3RhdHVzOiBB dHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stCgkJCUNo YW5nZWQ6IE1STC0gUHJlc0RldC0gTGlua1N0YXRlLQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxl LSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtCgkJUm9vdENh cDogQ1JTVmlzaWJsZS0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQ ZW5kaW5nLQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQkMsIFRpbWVvdXRE aXMrLCBMVFItLCBPQkZGIE5vdCBTdXBwb3J0ZWQgQVJJRndkLQoJCURldkN0bDI6IENvbXBsZXRp b24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLSwgTFRSLSwgT0JGRiBEaXNhYmxl ZCBBUklGd2QtCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBs aWFuY2UtIFNwZWVkRGlzLQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJh bmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFu Y2UgRGUtZW1waGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVs OiAtMy41ZEIsIEVxdWFsaXphdGlvbkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkg RXF1YWxpemF0aW9uUGhhc2UyLSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlv blJlcXVlc3QtCglDYXBhYmlsaXRpZXM6IFs4MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNr YWJsZS0gNjRiaXQtCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGll czogWzkwXSBTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSA1MDAxCglDYXBh YmlsaXRpZXM6IFthMF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFnczogUE1FQ2xr LSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2Nv bGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg UE1FLQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0CgowMDoxYy43IFBDSSBicmlkZ2U6 IEludGVsIENvcnBvcmF0aW9uIDcgU2VyaWVzL0MyMTAgU2VyaWVzIENoaXBzZXQgRmFtaWx5IFBD SSBFeHByZXNzIFJvb3QgUG9ydCA4IChyZXYgYzQpIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVjb2Rl XSkKCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6 IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8 VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBM aW5lIFNpemU6IDY0IGJ5dGVzCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wNywgc3Vib3Jk aW5hdGU9MDcsIHNlYy1sYXRlbmN5PTAKCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw Y2ZmZgoJTWVtb3J5IGJlaGluZCBicmlkZ2U6IGY3ODAwMDAwLWY3OGZmZmZmCglTZWNvbmRhcnkg c3RhdHVzOiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFi b3J0LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItCglCcmlkZ2VDdGw6IFBhcml0eS0gU0VSUi0gTm9J U0EtIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rt ci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVz cyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAKCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4 IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMKCQkJRXh0VGFn LSBSQkUrIEZMUmVzZXQtCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9u LUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5j LSBBdXhQd3ItIE5vU25vb3AtCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEy OCBieXRlcwoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVx LSBBdXhQd3IrIFRyYW5zUGVuZC0KCQlMbmtDYXA6CVBvcnQgIzgsIFNwZWVkIDVHVC9zLCBXaWR0 aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw1MTJucywgTDEgPDE2dXMKCQkJQ2xvY2tQ TS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJD QiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gtIENsb2Nr UE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgNUdUL3MsIFdp ZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQt CgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1 Zy0gU3VycHJpc2UtCgkJCVNsb3QgIzcsIFBvd2VyTGltaXQgMTAuMDAwVzsgSW50ZXJsb2NrLSBO b0NvbXBsKwoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0g Q21kQ3BsdC0gSFBJcnEtIExpbmtDaGctCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdy SW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4t IFBvd2VyRmx0LSBNUkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0KCQkJQ2hhbmdlZDog TVJMLSBQcmVzRGV0LSBMaW5rU3RhdGUtCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5v bi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0KCQlSb290Q2FwOiBDUlNW aXNpYmxlLQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmct CgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBCQywgVGltZW91dERpcyssIExU Ui0sIE9CRkYgTm90IFN1cHBvcnRlZCBBUklGd2QtCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1l b3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtLCBMVFItLCBPQkZGIERpc2FibGVkIEFSSUZ3 ZC0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0g U3BlZWREaXMtCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVu dGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBEZS1l bXBoYXNpczogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEIs IEVxdWFsaXphdGlvbkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkgRXF1YWxpemF0 aW9uUGhhc2UyLSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlvblJlcXVlc3Qt CglDYXBhYmlsaXRpZXM6IFs4MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi aXQtCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzkwXSBT dWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSA1MDAxCglDYXBhYmlsaXRpZXM6 IFthMF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDIKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx LSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQoJCVN0 YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJS2Vy bmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0CgowMDoxZC4wIFVTQiBjb250cm9sbGVyOiBJbnRl bCBDb3Jwb3JhdGlvbiA3IFNlcmllcy9DMjEwIFNlcmllcyBDaGlwc2V0IEZhbWlseSBVU0IgRW5o YW5jZWQgSG9zdCBDb250cm9sbGVyICMxIChyZXYgMDQpIChwcm9nLWlmIDIwIFtFSENJXSkKCVN1 YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xvZ3kgRGV2aWNlIDUwMDYKCUNvbnRyb2w6IEkvTy0g TWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3Rl cHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g RmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt ID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCUludGVycnVwdDogcGluIEEgcm91dGVk IHRvIElSUSAyMwoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmN2MxNzAwMCAoMzItYml0LCBub24tcHJl ZmV0Y2hhYmxlKSBbc2l6ZT0xS10KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50 IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTM3NW1B IFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykKCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0g UE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KCUNhcGFiaWxpdGllczogWzU4XSBEZWJ1 ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBhMAoJQ2FwYWJpbGl0aWVzOiBbOThdIFBDSSBBZHZhbmNl ZCBGZWF0dXJlcwoJCUFGQ2FwOiBUUCsgRkxSKwoJCUFGQ3RybDogRkxSLQoJCUFGU3RhdHVzOiBU UC0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrCgowMDoxZi4wIElTQSBicmlkZ2U6IElu dGVsIENvcnBvcmF0aW9uIFo3NyBFeHByZXNzIENoaXBzZXQgTFBDIENvbnRyb2xsZXIgKHJldiAw NCkKCVN1YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xvZ3kgRGV2aWNlIDUwMDEKCUNvbnRyb2w6 IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVy ci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHot IFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxN QWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAKCUNhcGFiaWxpdGllczogW2Uw XSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IExlbj0wYyA8Pz4KCUtlcm5lbCBkcml2ZXIg aW4gdXNlOiBscGNfaWNoCgowMDoxZi4yIFJBSUQgYnVzIGNvbnRyb2xsZXI6IEludGVsIENvcnBv cmF0aW9uIDgyODAxIFNBVEEgQ29udHJvbGxlciBbUkFJRCBtb2RlXSAocmV2IDA0KQoJU3Vic3lz dGVtOiBHaWdhLWJ5dGUgVGVjaG5vbG9neSBEZXZpY2UgYjAwNQoJQ29udHJvbDogSS9PKyBNZW0r IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGlu Zy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0 QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF UlItIDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMAoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8g SVJRIDkyCglSZWdpb24gMDogSS9PIHBvcnRzIGF0IGYwYjAgW3NpemU9OF0KCVJlZ2lvbiAxOiBJ L08gcG9ydHMgYXQgZjBhMCBbc2l6ZT00XQoJUmVnaW9uIDI6IEkvTyBwb3J0cyBhdCBmMDkwIFtz aXplPThdCglSZWdpb24gMzogSS9PIHBvcnRzIGF0IGYwODAgW3NpemU9NF0KCVJlZ2lvbiA0OiBJ L08gcG9ydHMgYXQgZjA2MCBbc2l6ZT0zMl0KCVJlZ2lvbiA1OiBNZW1vcnkgYXQgZjdjMTYwMDAg KDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MktdCglDYXBhYmlsaXRpZXM6IFs4MF0g TVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtCgkJQWRkcmVzczogZmVlMDAy YjggIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzcwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNp b24gMwoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDAt LEQxLSxEMi0sRDNob3QrLEQzY29sZC0pCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFi bGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtCglDYXBhYmlsaXRpZXM6IFthOF0gU0FUQSBIQkEgdjEu MCBCQVI0IE9mZnNldD0wMDAwMDAwNAoJQ2FwYWJpbGl0aWVzOiBbYjBdIFBDSSBBZHZhbmNlZCBG ZWF0dXJlcwoJCUFGQ2FwOiBUUCsgRkxSKwoJCUFGQ3RybDogRkxSLQoJCUFGU3RhdHVzOiBUUC0K CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNpCgowMDoxZi4zIFNNQnVzOiBJbnRlbCBDb3Jwb3Jh dGlvbiA3IFNlcmllcy9DMjEwIFNlcmllcyBDaGlwc2V0IEZhbWlseSBTTUJ1cyBDb250cm9sbGVy IChyZXYgMDQpCglTdWJzeXN0ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSA1MDAxCglD b250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29w LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXAt IDY2TUh6LSBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFi b3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRl ZCB0byBJUlEgMTgKCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjdjMTUwMDAgKDY0LWJpdCwgbm9uLXBy ZWZldGNoYWJsZSkgW3NpemU9MjU2XQoJUmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBmMDQwIFtzaXpl PTMyXQoKMDE6MDAuMCBWR0EgY29tcGF0aWJsZSBjb250cm9sbGVyOiBBZHZhbmNlZCBNaWNybyBE ZXZpY2VzIFtBTURdIG5lZSBBVEkgVGFoaXRpIFBSTyBbUmFkZW9uIEhEIDc5NTBdIChwcm9nLWlm IDAwIFtWR0EgY29udHJvbGxlcl0pCglTdWJzeXN0ZW06IFBDIFBhcnRuZXIgTGltaXRlZCBEZXZp Y2UgMzAwMAoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0 YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENh Y2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAx NgoJUmVnaW9uIDA6IE1lbW9yeSBhdCBlMDAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtz aXplPTI1Nk1dCglSZWdpb24gMjogTWVtb3J5IGF0IGY3YjAwMDAwICg2NC1iaXQsIG5vbi1wcmVm ZXRjaGFibGUpIFtzaXplPTI1NktdCglSZWdpb24gNDogSS9PIHBvcnRzIGF0IGUwMDAgW3NpemU9 MjU2XQoJRXhwYW5zaW9uIFJPTSBhdCBmN2I0MDAwMCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdCglD YXBhYmlsaXRpZXM6IFs0OF0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBMZW49MDggPD8+ CglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczog UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMSssRDIrLEQzaG90 KyxEM2NvbGQtKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj YWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdhY3kgRW5kcG9p bnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBM YXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0ZWQKCQkJRXh0VGFnKyBBdHRuQnRuLSBBdHRuSW5k LSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3Rh YmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnKyBQ aGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJl YWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBV bnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgOEdU L3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMKCQkJ Q2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gt IENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41 R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQt IEFCV01nbXQtCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBU aW1lb3V0RGlzLSwgTFRSLSwgT0JGRiBOb3QgU3VwcG9ydGVkCgkJRGV2Q3RsMjogQ29tcGxldGlv biBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtLCBMVFItLCBPQkZGIERpc2FibGVk CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDhHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNw ZWVkRGlzLQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRl ck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0KCQkJIENvbXBsaWFuY2UgRGUtZW1w aGFzaXM6IC02ZEIKCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEIs IEVxdWFsaXphdGlvbkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkgRXF1YWxpemF0 aW9uUGhhc2UyLSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlvblJlcXVlc3Qt CglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi aXQrCgkJQWRkcmVzczogMDAwMDAwMDBmZWUwMDM1OCAgRGF0YTogMDAwMAoJQ2FwYWJpbGl0aWVz OiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVu PTAxMCA8Pz4KCUNhcGFiaWxpdGllczogWzE1MCB2Ml0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5n CgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21w bHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCVVFTXNrOglETFAt IFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxm VExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRVN2cnQ6CURMUCsgU0RFUysgVExQLSBG Q1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVu c3VwUmVxLSBBQ1NWaW9sLQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zl ci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAt IFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisKCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBv aW50ZXI6IDAwLCBHZW5DYXArIENHZW5Fbi0gQ2hrQ2FwKyBDaGtFbi0KCUNhcGFiaWxpdGllczog WzI3MCB2MV0gIzE5CglDYXBhYmlsaXRpZXM6IFsyYjAgdjFdIEFkZHJlc3MgVHJhbnNsYXRpb24g U2VydmljZSAoQVRTKQoJCUFUU0NhcDoJSW52YWxpZGF0ZSBRdWV1ZSBEZXB0aDogMDAKCQlBVFND dGw6CUVuYWJsZS0sIFNtYWxsZXN0IFRyYW5zbGF0aW9uIFVuaXQ6IDAwCglDYXBhYmlsaXRpZXM6 IFsyYzAgdjFdICMxMwoJQ2FwYWJpbGl0aWVzOiBbMmQwIHYxXSAjMWIKCUtlcm5lbCBkcml2ZXIg aW4gdXNlOiBwY2liYWNrCgowMTowMC4xIEF1ZGlvIGRldmljZTogQWR2YW5jZWQgTWljcm8gRGV2 aWNlcyBbQU1EXSBuZWUgQVRJIFRhaGl0aSBYVCBIRE1JIEF1ZGlvIFtSYWRlb24gSEQgNzk3MCBT ZXJpZXNdCglTdWJzeXN0ZW06IFBDIFBhcnRuZXIgTGltaXRlZCBEZXZpY2UgYWFhMAoJQ29udHJv bDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFy RXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0KCVN0YXR1czogQ2FwKyA2Nk1I ei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxN QWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog NjQgYnl0ZXMKCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAxNwoJUmVnaW9uIDA6IE1l bW9yeSBhdCBmN2I2MDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNktdCglD YXBhYmlsaXRpZXM6IFs0OF0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBMZW49MDggPD8+ CglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczog UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90 LSxEM2NvbGQtKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj YWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdhY3kgRW5kcG9p bnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBM YXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0ZWQKCQkJRXh0VGFnKyBBdHRuQnRuLSBBdHRuSW5k LSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3Rh YmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQ aGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsKCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJl YWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJyLSBV bnN1cHBSZXErIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgOEdU L3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMKCQkJ Q2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gt IENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41 R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQt IEFCV01nbXQtCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBU aW1lb3V0RGlzLSwgTFRSLSwgT0JGRiBOb3QgU3VwcG9ydGVkCgkJRGV2Q3RsMjogQ29tcGxldGlv biBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtLCBMVFItLCBPQkZGIERpc2FibGVk CgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCLCBFcXVhbGl6YXRp b25Db21wbGV0ZS0sIEVxdWFsaXphdGlvblBoYXNlMS0KCQkJIEVxdWFsaXphdGlvblBoYXNlMi0s IEVxdWFsaXphdGlvblBoYXNlMy0sIExpbmtFcXVhbGl6YXRpb25SZXF1ZXN0LQoJQ2FwYWJpbGl0 aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJl c3M6IDAwMDAwMDAwZmVlMDAzNzggIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogWzEwMCB2MV0g VmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+CglD YXBhYmlsaXRpZXM6IFsxNTAgdjJdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3RhOglE TFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBN YWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAt IEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0g VW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0gRkNQKyBDbXBsdFRP LSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBVbnN1cFJlcS0gQUNT VmlvbC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQt IE5vbkZhdGFsRXJyKwoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0g VGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwg R2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4tCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp YmFjawoKMDM6MDAuMCBVU0IgY29udHJvbGxlcjogVklBIFRlY2hub2xvZ2llcywgSW5jLiBEZXZp Y2UgMzQzMiAocmV2IDAzKSAocHJvZy1pZiAzMCBbWEhDSV0pCglTdWJzeXN0ZW06IEdpZ2EtYnl0 ZSBUZWNobm9sb2d5IERldmljZSA1MDA3CglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBT cGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0 QjJCLSBEaXNJTlR4KwoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0g REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4 LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50ZXJydXB0OiBwaW4g QSByb3V0ZWQgdG8gSVJRIDk1CglSZWdpb24gMDogTWVtb3J5IGF0IGY3YTAwMDAwICgzMi1iaXQs IG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQoJQ2FwYWJpbGl0aWVzOiBbODBdIFBvd2VyIE1h bmFnZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJl bnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9T b2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBb OTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0KwoJCUFkZHJlc3M6IDAw MDAwMDAwZmVlMDAzMTggIERhdGE6IDAwMDAKCUNhcGFiaWxpdGllczogW2M0XSBFeHByZXNzICh2 MikgRW5kcG9pbnQsIE1TSSAwMAoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50 RnVuYyAwLCBMYXRlbmN5IEwwcyA8MXVzLCBMMSA8MTZ1cwoJCQlFeHRUYWctIEF0dG5CdG4tIEF0 dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29y cmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQoJCQlSbHhkT3JkLSBFeHRU YWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKwoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg TWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxF cnItIFVuc3VwcFJlcS0gQXV4UHdyKyBUcmFuc1BlbmQtCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVl ZCA1R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8MnVzLCBMMSA8MTZ1 cwoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQoJCUxua0N0bDoJQVNQTSBE aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQoJCQlFeHRT eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCgkJTG5rU3RhOglTcGVl ZCA1R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdt dC0gQUJXTWdtdC0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEIsIFRpbWVv dXREaXMrLCBMVFItLCBPQkZGIE5vdCBTdXBwb3J0ZWQKCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRp bWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0sIExUUi0sIE9CRkYgRGlzYWJsZWQKCQlM bmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWRE aXMtCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9k aWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNp czogLTZkQgoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEIsIEVxdWFs aXphdGlvbkNvbXBsZXRlLSwgRXF1YWxpemF0aW9uUGhhc2UxLQoJCQkgRXF1YWxpemF0aW9uUGhh c2UyLSwgRXF1YWxpemF0aW9uUGhhc2UzLSwgTGlua0VxdWFsaXphdGlvblJlcXVlc3QtCglDYXBh YmlsaXRpZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZwoJCVVFU3RhOglETFAt IFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxm VExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAtIEZD UC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5z dXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0gRkNQKyBDbXBsdFRPLSBD bXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlv bC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5v bkZhdGFsRXJyLQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGlt ZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2Vu Q2FwLSBDR2VuRW4tIENoa0NhcC0gQ2hrRW4tCglLZXJuZWwgZHJpdmVyIGluIHVzZTogeGhjaV9o Y2QKCjA0OjAwLjAgUENJIGJyaWRnZTogSW50ZWwgQ29ycG9yYXRpb24gODI4MDEgUENJIEJyaWRn ZSAocmV2IDQxKSAocHJvZy1pZiAwMSBbU3VidHJhY3RpdmUgZGVjb2RlXSkKCUNvbnRyb2w6IEkv TysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0g U3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtCglTdGF0dXM6IENhcCsgNjZNSHotIFVE Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0 LSA+U0VSUi0gPFBFUlItIElOVHgtCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5 dGVzCglCdXM6IHByaW1hcnk9MDQsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1s YXRlbmN5PTMyCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1IeisgRmFzdEIyQi0gUGFyRXJyLSBERVZT RUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrIDxTRVJSLSA8UEVSUi0KCUJyaWRn ZUN0bDogUGFyaXR5LSBTRVJSLSBOb0lTQS0gVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0K CQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yKyBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0KCUNh cGFiaWxpdGllczogWzkwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMgoJCUZsYWdzOiBQTUVD bGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTU1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxE M2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxl PTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbYTBdIFN1YnN5c3RlbTogR2lnYS1ieXRlIFRlY2hub2xv Z3kgRGV2aWNlIDg4OTIKCjA2OjAwLjAgRXRoZXJuZXQgY29udHJvbGxlcjogQXRoZXJvcyBDb21t dW5pY2F0aW9ucyBJbmMuIEFSODE2MSBHaWdhYml0IEV0aGVybmV0IChyZXYgMTApCglTdWJzeXN0 ZW06IEdpZ2EtYnl0ZSBUZWNobm9sb2d5IERldmljZSBlMDAwCglDb250cm9sOiBJL08rIE1lbSsg QnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5n LSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RC MkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt IDxQRVJSLSBJTlR4LQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwoJSW50 ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDExCglSZWdpb24gMDogTWVtb3J5IGF0IGY3OTAw MDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1NktdCglSZWdpb24gMjogSS9P IHBvcnRzIGF0IGQwMDAgW3NpemU9MTI4XQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFn ZW1lbnQgdmVyc2lvbiAzCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9 Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQoJCVN0YXR1czogRDAgTm9Tb2Z0 UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2FwYWJpbGl0aWVzOiBbNThd IEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDQwOTYg Ynl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZAoJ CQlFeHRUYWctIEF0dG5CdG4rIEF0dG5JbmQrIFB3ckluZCsgUkJFKyBGTFJlc2V0LQoJCURldkN0 bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y dGVkLQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQoJCQlN YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMKCQlEZXZTdGE6CUNvcnJF cnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyKyBUcmFuc1BlbmQtCgkJ TG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh dGVuY3kgTDAgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQKCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExM QWN0UmVwLSBCd05vdC0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNh YmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g QldJbnQtIEF1dEJXSW50LQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy LSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0KCUNhcGFiaWxpdGll czogW2MwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xNiBNYXNrYWJsZSsgNjRiaXQrCgkJQWRkcmVz czogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMAoJCU1hc2tpbmc6IDAwMDAwMDAwICBQZW5k aW5nOiAwMDAwMDAwMAoJQ2FwYWJpbGl0aWVzOiBbZDhdIE1TSS1YOiBFbmFibGUtIENvdW50PTE2 IE1hc2tlZC0KCQlWZWN0b3IgdGFibGU6IEJBUj0wIG9mZnNldD0wMDAwMjAwMAoJCVBCQTogQkFS PTAgb2Zmc2V0PTAwMDAzMDAwCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9y IFJlcG9ydGluZwoJCVVFU3RhOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFi cnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlV RU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0g UnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtCgkJVUVTdnJ0OglETFArIFNE RVMrIFRMUC0gRkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQ KyBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExM UC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyLQoJCUNFTXNrOglSeEVyci0gQmFkVExQ LSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrCgkJQUVSQ2FwOglGaXJz dCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4tCglDYXBh YmlsaXRpZXM6IFsxODAgdjFdIERldmljZSBTZXJpYWwgTnVtYmVyIGZmLTVjLTg1LWQxLTkwLTJi LTM0LWZmCgowNzowMC4wIElERSBpbnRlcmZhY2U6IE1hcnZlbGwgVGVjaG5vbG9neSBHcm91cCBM dGQuIDg4U0U5MTcyIFNBVEEgSUlJIDZHYi9zIFJBSUQgQ29udHJvbGxlciAocmV2IDExKSAocHJv Zy1pZiA4ZiBbTWFzdGVyIFNlY1AgU2VjTyBQcmlQIFByaU9dKQoJU3Vic3lzdGVtOiBHaWdhLWJ5 dGUgVGVjaG5vbG9neSBEZXZpY2UgYjAwMAoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFz dEIyQi0gRGlzSU5UeCsKCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U eC0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMKCUludGVycnVwdDogcGlu IEEgcm91dGVkIHRvIElSUSA5MwoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBjMDQwIFtzaXplPThd CglSZWdpb24gMTogSS9PIHBvcnRzIGF0IGMwMzAgW3NpemU9NF0KCVJlZ2lvbiAyOiBJL08gcG9y dHMgYXQgYzAyMCBbc2l6ZT04XQoJUmVnaW9uIDM6IEkvTyBwb3J0cyBhdCBjMDEwIFtzaXplPTRd CglSZWdpb24gNDogSS9PIHBvcnRzIGF0IGMwMDAgW3NpemU9MTZdCglSZWdpb24gNTogTWVtb3J5 IGF0IGY3ODEwMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTUxMl0KCUV4cGFu c2lvbiBST00gYXQgZjc4MDAwMDAgW2Rpc2FibGVkXSBbc2l6ZT02NEtdCglDYXBhYmlsaXRpZXM6 IFs0MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMKCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx LSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90KyxEM2NvbGQtKQoJCVN0 YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQoJQ2Fw YWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQoJ CUFkZHJlc3M6IGZlZTAwMmQ4ICBEYXRhOiAwMDAwCglDYXBhYmlsaXRpZXM6IFs3MF0gRXhwcmVz cyAodjIpIExlZ2FjeSBFbmRwb2ludCwgTVNJIDAwCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDUxMiBi eXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDwxdXMsIEwxIDw4dXMKCQkJRXh0VGFnLSBB dHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0KCQlEZXZDdGw6CVJlcG9ydCBl cnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0KCQkJUmx4 ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcC0KCQkJTWF4UGF5bG9hZCAx MjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJF cnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQoJCUxua0NhcDoJUG9y dCAjMCwgU3BlZWQgNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEy bnMsIEwxIDw2NHVzCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtCgkJTG5r Q3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1D bGsrCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0KCQlM bmtTdGE6CVNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj dGl2ZS0gQldNZ210LSBBQldNZ210LQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90 IFN1cHBvcnRlZCwgVGltZW91dERpcyssIExUUi0sIE9CRkYgTm90IFN1cHBvcnRlZAoJCURldkN0 bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLSwgTFRSLSwg T0JGRiBEaXNhYmxlZAoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJD b21wbGlhbmNlLSBTcGVlZERpcy0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtCgkJCSBDb21w bGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBM ZXZlbDogLTZkQiwgRXF1YWxpemF0aW9uQ29tcGxldGUtLCBFcXVhbGl6YXRpb25QaGFzZTEtCgkJ CSBFcXVhbGl6YXRpb25QaGFzZTItLCBFcXVhbGl6YXRpb25QaGFzZTMtLCBMaW5rRXF1YWxpemF0 aW9uUmVxdWVzdC0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0 aW5nCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54 Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQoJCVVFTXNrOglE TFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBN YWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0KCQlVRVN2cnQ6CURMUCsgU0RFUysgVExQ LSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMt IFVuc3VwUmVxLSBBQ1NWaW9sLQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xs b3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnItCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERM TFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisKCQlBRVJDYXA6CUZpcnN0IEVycm9y IFBvaW50ZXI6IDAwLCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2FwLSBDaGtFbi0KCUtlcm5lbCBkcml2 ZXIgaW4gdXNlOiBhaGNpCgo= --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name=uname-txt Content-Disposition: attachment; filename=uname-txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1vq3 TGludXggbG9jYWxob3N0LmxvY2FsZG9tYWluIDMuNi4xMC00LmZjMTgueDg2XzY0ICMxIFNNUCBU dWUgRmViIDE5IDIxOjEyOjE0IEJSVCAyMDEzIHg4Nl82NCB4ODZfNjQgeDg2XzY0IEdOVS9MaW51 eAo= --14dae9340959d5aa6f04d7246e42 Content-Type: application/octet-stream; name="config-3.6.10-4.fc18.x86_64" Content-Disposition: attachment; filename="config-3.6.10-4.fc18.x86_64" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdwga1vz4 IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4L3g4 Nl82NCAzLjYuMTAtNC5mYzE4Lng4Nl82NCBLZXJuZWwgQ29uZmlndXJhdGlvbgojCkNPTkZJR182 NEJJVD15CiMgQ09ORklHX1g4Nl8zMiBpcyBub3Qgc2V0CkNPTkZJR19YODZfNjQ9eQpDT05GSUdf WDg2PXkKQ09ORklHX0lOU1RSVUNUSU9OX0RFQ09ERVI9eQpDT05GSUdfT1VUUFVUX0ZPUk1BVD0i ZWxmNjQteDg2LTY0IgpDT05GSUdfQVJDSF9ERUZDT05GSUc9ImFyY2gveDg2L2NvbmZpZ3MveDg2 XzY0X2RlZmNvbmZpZyIKQ09ORklHX0xPQ0tERVBfU1VQUE9SVD15CkNPTkZJR19TVEFDS1RSQUNF X1NVUFBPUlQ9eQpDT05GSUdfSEFWRV9MQVRFTkNZVE9QX1NVUFBPUlQ9eQpDT05GSUdfTU1VPXkK Q09ORklHX05FRURfRE1BX01BUF9TVEFURT15CkNPTkZJR19ORUVEX1NHX0RNQV9MRU5HVEg9eQpD T05GSUdfR0VORVJJQ19JU0FfRE1BPXkKQ09ORklHX0dFTkVSSUNfQlVHPXkKQ09ORklHX0dFTkVS SUNfQlVHX1JFTEFUSVZFX1BPSU5URVJTPXkKQ09ORklHX0dFTkVSSUNfSFdFSUdIVD15CkNPTkZJ R19BUkNIX01BWV9IQVZFX1BDX0ZEQz15CiMgQ09ORklHX1JXU0VNX0dFTkVSSUNfU1BJTkxPQ0sg aXMgbm90IHNldApDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklUSE09eQpDT05GSUdfR0VORVJJ Q19DQUxJQlJBVEVfREVMQVk9eQpDT05GSUdfQVJDSF9IQVNfQ1BVX1JFTEFYPXkKQ09ORklHX0FS Q0hfSEFTX0RFRkFVTFRfSURMRT15CkNPTkZJR19BUkNIX0hBU19DQUNIRV9MSU5FX1NJWkU9eQpD T05GSUdfQVJDSF9IQVNfQ1BVX0FVVE9QUk9CRT15CkNPTkZJR19IQVZFX1NFVFVQX1BFUl9DUFVf QVJFQT15CkNPTkZJR19ORUVEX1BFUl9DUFVfRU1CRURfRklSU1RfQ0hVTks9eQpDT05GSUdfTkVF RF9QRVJfQ1BVX1BBR0VfRklSU1RfQ0hVTks9eQpDT05GSUdfQVJDSF9ISUJFUk5BVElPTl9QT1NT SUJMRT15CkNPTkZJR19BUkNIX1NVU1BFTkRfUE9TU0lCTEU9eQpDT05GSUdfWk9ORV9ETUEzMj15 CkNPTkZJR19BVURJVF9BUkNIPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfT1BUSU1JWkVEX0lOTElO SU5HPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfREVCVUdfUEFHRUFMTE9DPXkKQ09ORklHX0hBVkVf SU5URUxfVFhUPXkKQ09ORklHX1g4Nl82NF9TTVA9eQpDT05GSUdfWDg2X0hUPXkKQ09ORklHX0FS Q0hfSFdFSUdIVF9DRkxBR1M9Ii1mY2FsbC1zYXZlZC1yZGkgLWZjYWxsLXNhdmVkLXJzaSAtZmNh bGwtc2F2ZWQtcmR4IC1mY2FsbC1zYXZlZC1yY3ggLWZjYWxsLXNhdmVkLXI4IC1mY2FsbC1zYXZl ZC1yOSAtZmNhbGwtc2F2ZWQtcjEwIC1mY2FsbC1zYXZlZC1yMTEiCkNPTkZJR19BUkNIX0NQVV9Q Uk9CRV9SRUxFQVNFPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNfVVBST0JFUz15CkNPTkZJR19ERUZD T05GSUdfTElTVD0iL2xpYi9tb2R1bGVzLyRVTkFNRV9SRUxFQVNFLy5jb25maWciCkNPTkZJR19I QVZFX0lSUV9XT1JLPXkKQ09ORklHX0lSUV9XT1JLPXkKQ09ORklHX0JVSUxEVElNRV9FWFRBQkxF X1NPUlQ9eQoKIwojIEdlbmVyYWwgc2V0dXAKIwpDT05GSUdfRVhQRVJJTUVOVEFMPXkKQ09ORklH X0lOSVRfRU5WX0FSR19MSU1JVD0zMgpDT05GSUdfQ1JPU1NfQ09NUElMRT0iIgpDT05GSUdfTE9D QUxWRVJTSU9OPSIiCiMgQ09ORklHX0xPQ0FMVkVSU0lPTl9BVVRPIGlzIG5vdCBzZXQKQ09ORklH X0hBVkVfS0VSTkVMX0daSVA9eQpDT05GSUdfSEFWRV9LRVJORUxfQlpJUDI9eQpDT05GSUdfSEFW RV9LRVJORUxfTFpNQT15CkNPTkZJR19IQVZFX0tFUk5FTF9YWj15CkNPTkZJR19IQVZFX0tFUk5F TF9MWk89eQpDT05GSUdfS0VSTkVMX0daSVA9eQojIENPTkZJR19LRVJORUxfQlpJUDIgaXMgbm90 IHNldAojIENPTkZJR19LRVJORUxfTFpNQSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9YWiBp cyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9MWk8gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9I T1NUTkFNRT0iKG5vbmUpIgpDT05GSUdfU1dBUD15CkNPTkZJR19TWVNWSVBDPXkKQ09ORklHX1NZ U1ZJUENfU1lTQ1RMPXkKQ09ORklHX1BPU0lYX01RVUVVRT15CkNPTkZJR19QT1NJWF9NUVVFVUVf U1lTQ1RMPXkKQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1Q9eQpDT05GSUdfQlNEX1BST0NFU1NfQUND VF9WMz15CkNPTkZJR19GSEFORExFPXkKQ09ORklHX1RBU0tTVEFUUz15CkNPTkZJR19UQVNLX0RF TEFZX0FDQ1Q9eQpDT05GSUdfVEFTS19YQUNDVD15CkNPTkZJR19UQVNLX0lPX0FDQ09VTlRJTkc9 eQpDT05GSUdfQVVESVQ9eQpDT05GSUdfQVVESVRTWVNDQUxMPXkKQ09ORklHX0FVRElUX1dBVENI PXkKQ09ORklHX0FVRElUX1RSRUU9eQojIENPTkZJR19BVURJVF9MT0dJTlVJRF9JTU1VVEFCTEUg aXMgbm90IHNldApDT05GSUdfSEFWRV9HRU5FUklDX0hBUkRJUlFTPXkKCiMKIyBJUlEgc3Vic3lz dGVtCiMKQ09ORklHX0dFTkVSSUNfSEFSRElSUVM9eQpDT05GSUdfR0VORVJJQ19JUlFfUFJPQkU9 eQpDT05GSUdfR0VORVJJQ19JUlFfU0hPVz15CkNPTkZJR19HRU5FUklDX1BFTkRJTkdfSVJRPXkK Q09ORklHX0lSUV9ET01BSU49eQojIENPTkZJR19JUlFfRE9NQUlOX0RFQlVHIGlzIG5vdCBzZXQK Q09ORklHX0lSUV9GT1JDRURfVEhSRUFESU5HPXkKQ09ORklHX1NQQVJTRV9JUlE9eQpDT05GSUdf Q0xPQ0tTT1VSQ0VfV0FUQ0hET0c9eQpDT05GSUdfQVJDSF9DTE9DS1NPVVJDRV9EQVRBPXkKQ09O RklHX0dFTkVSSUNfVElNRV9WU1lTQ0FMTD15CkNPTkZJR19HRU5FUklDX0NMT0NLRVZFTlRTPXkK Q09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNfQlVJTEQ9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VW RU5UU19CUk9BRENBU1Q9eQpDT05GSUdfR0VORVJJQ19DTE9DS0VWRU5UU19NSU5fQURKVVNUPXkK Q09ORklHX0dFTkVSSUNfQ01PU19VUERBVEU9eQoKIwojIFRpbWVycyBzdWJzeXN0ZW0KIwpDT05G SUdfVElDS19PTkVTSE9UPXkKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVSUz15 CgojCiMgUkNVIFN1YnN5c3RlbQojCkNPTkZJR19UUkVFX1JDVT15CiMgQ09ORklHX1BSRUVNUFRf UkNVIGlzIG5vdCBzZXQKQ09ORklHX1JDVV9GQU5PVVQ9NjQKQ09ORklHX1JDVV9GQU5PVVRfTEVB Rj0xNgojIENPTkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUkNVX0ZB U1RfTk9fSFogaXMgbm90IHNldAojIENPTkZJR19UUkVFX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMg Q09ORklHX0lLQ09ORklHIGlzIG5vdCBzZXQKQ09ORklHX0xPR19CVUZfU0hJRlQ9MTgKQ09ORklH X0hBVkVfVU5TVEFCTEVfU0NIRURfQ0xPQ0s9eQpDT05GSUdfQ0dST1VQUz15CiMgQ09ORklHX0NH Uk9VUF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19DR1JPVVBfRlJFRVpFUj15CkNPTkZJR19DR1JP VVBfREVWSUNFPXkKQ09ORklHX0NQVVNFVFM9eQpDT05GSUdfUFJPQ19QSURfQ1BVU0VUPXkKQ09O RklHX0NHUk9VUF9DUFVBQ0NUPXkKQ09ORklHX1JFU09VUkNFX0NPVU5URVJTPXkKQ09ORklHX01F TUNHPXkKQ09ORklHX01FTUNHX1NXQVA9eQojIENPTkZJR19NRU1DR19TV0FQX0VOQUJMRUQgaXMg bm90IHNldApDT05GSUdfTUVNQ0dfS01FTT15CiMgQ09ORklHX0NHUk9VUF9IVUdFVExCIGlzIG5v dCBzZXQKQ09ORklHX0NHUk9VUF9QRVJGPXkKQ09ORklHX0NHUk9VUF9TQ0hFRD15CkNPTkZJR19G QUlSX0dST1VQX1NDSEVEPXkKQ09ORklHX0NGU19CQU5EV0lEVEg9eQpDT05GSUdfUlRfR1JPVVBf U0NIRUQ9eQpDT05GSUdfQkxLX0NHUk9VUD15CiMgQ09ORklHX0RFQlVHX0JMS19DR1JPVVAgaXMg bm90IHNldAojIENPTkZJR19DSEVDS1BPSU5UX1JFU1RPUkUgaXMgbm90IHNldApDT05GSUdfTkFN RVNQQUNFUz15CkNPTkZJR19VVFNfTlM9eQpDT05GSUdfSVBDX05TPXkKQ09ORklHX1BJRF9OUz15 CkNPTkZJR19ORVRfTlM9eQpDT05GSUdfU0NIRURfQVVUT0dST1VQPXkKQ09ORklHX01NX09XTkVS PXkKIyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0CkNPTkZJR19SRUxBWT15CkNP TkZJR19CTEtfREVWX0lOSVRSRD15CkNPTkZJR19JTklUUkFNRlNfU09VUkNFPSIiCkNPTkZJR19S RF9HWklQPXkKQ09ORklHX1JEX0JaSVAyPXkKQ09ORklHX1JEX0xaTUE9eQpDT05GSUdfUkRfWFo9 eQpDT05GSUdfUkRfTFpPPXkKIyBDT05GSUdfQ0NfT1BUSU1JWkVfRk9SX1NJWkUgaXMgbm90IHNl dApDT05GSUdfU1lTQ1RMPXkKQ09ORklHX0FOT05fSU5PREVTPXkKIyBDT05GSUdfRVhQRVJUIGlz IG5vdCBzZXQKQ09ORklHX1VJRDE2PXkKIyBDT05GSUdfU1lTQ1RMX1NZU0NBTEwgaXMgbm90IHNl dApDT05GSUdfS0FMTFNZTVM9eQpDT05GSUdfS0FMTFNZTVNfQUxMPXkKQ09ORklHX0hPVFBMVUc9 eQpDT05GSUdfUFJJTlRLPXkKQ09ORklHX0JVRz15CkNPTkZJR19FTEZfQ09SRT15CkNPTkZJR19Q Q1NQS1JfUExBVEZPUk09eQpDT05GSUdfSEFWRV9QQ1NQS1JfUExBVEZPUk09eQpDT05GSUdfQkFT RV9GVUxMPXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0VQT0xMPXkKQ09ORklHX1NJR05BTEZEPXkK Q09ORklHX1RJTUVSRkQ9eQpDT05GSUdfRVZFTlRGRD15CkNPTkZJR19TSE1FTT15CkNPTkZJR19B SU89eQojIENPTkZJR19FTUJFRERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZfRVZFTlRT PXkKCiMKIyBLZXJuZWwgUGVyZm9ybWFuY2UgRXZlbnRzIEFuZCBDb3VudGVycwojCkNPTkZJR19Q RVJGX0VWRU5UUz15CiMgQ09ORklHX0RFQlVHX1BFUkZfVVNFX1ZNQUxMT0MgaXMgbm90IHNldApD T05GSUdfVk1fRVZFTlRfQ09VTlRFUlM9eQpDT05GSUdfUENJX1FVSVJLUz15CkNPTkZJR19TTFVC X0RFQlVHPXkKIyBDT05GSUdfQ09NUEFUX0JSSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NMQUIgaXMg bm90IHNldApDT05GSUdfU0xVQj15CkNPTkZJR19QUk9GSUxJTkc9eQpDT05GSUdfVFJBQ0VQT0lO VFM9eQpDT05GSUdfT1BST0ZJTEU9bQpDT05GSUdfT1BST0ZJTEVfRVZFTlRfTVVMVElQTEVYPXkK Q09ORklHX0hBVkVfT1BST0ZJTEU9eQpDT05GSUdfT1BST0ZJTEVfTk1JX1RJTUVSPXkKQ09ORklH X0tQUk9CRVM9eQpDT05GSUdfSlVNUF9MQUJFTD15CkNPTkZJR19PUFRQUk9CRVM9eQpDT05GSUdf VVBST0JFUz15CkNPTkZJR19IQVZFX0VGRklDSUVOVF9VTkFMSUdORURfQUNDRVNTPXkKQ09ORklH X0tSRVRQUk9CRVM9eQpDT05GSUdfVVNFUl9SRVRVUk5fTk9USUZJRVI9eQpDT05GSUdfSEFWRV9J T1JFTUFQX1BST1Q9eQpDT05GSUdfSEFWRV9LUFJPQkVTPXkKQ09ORklHX0hBVkVfS1JFVFBST0JF Uz15CkNPTkZJR19IQVZFX09QVFBST0JFUz15CkNPTkZJR19IQVZFX0FSQ0hfVFJBQ0VIT09LPXkK Q09ORklHX0hBVkVfRE1BX0FUVFJTPXkKQ09ORklHX1VTRV9HRU5FUklDX1NNUF9IRUxQRVJTPXkK Q09ORklHX0dFTkVSSUNfU01QX0lETEVfVEhSRUFEPXkKQ09ORklHX0hBVkVfUkVHU19BTkRfU1RB Q0tfQUNDRVNTX0FQST15CkNPTkZJR19IQVZFX0RNQV9BUElfREVCVUc9eQpDT05GSUdfSEFWRV9I V19CUkVBS1BPSU5UPXkKQ09ORklHX0hBVkVfTUlYRURfQlJFQUtQT0lOVFNfUkVHUz15CkNPTkZJ R19IQVZFX1VTRVJfUkVUVVJOX05PVElGSUVSPXkKQ09ORklHX0hBVkVfUEVSRl9FVkVOVFNfTk1J PXkKQ09ORklHX0hBVkVfQVJDSF9KVU1QX0xBQkVMPXkKQ09ORklHX0FSQ0hfSEFWRV9OTUlfU0FG RV9DTVBYQ0hHPXkKQ09ORklHX0hBVkVfQUxJR05FRF9TVFJVQ1RfUEFHRT15CkNPTkZJR19IQVZF X0NNUFhDSEdfTE9DQUw9eQpDT05GSUdfSEFWRV9DTVBYQ0hHX0RPVUJMRT15CkNPTkZJR19BUkNI X1dBTlRfQ09NUEFUX0lQQ19QQVJTRV9WRVJTSU9OPXkKQ09ORklHX0FSQ0hfV0FOVF9PTERfQ09N UEFUX0lQQz15CkNPTkZJR19IQVZFX0FSQ0hfU0VDQ09NUF9GSUxURVI9eQpDT05GSUdfU0VDQ09N UF9GSUxURVI9eQoKIwojIEdDT1YtYmFzZWQga2VybmVsIHByb2ZpbGluZwojCiMgQ09ORklHX0dD T1ZfS0VSTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfSEFWRV9HRU5FUklDX0RNQV9DT0hFUkVOVCBp cyBub3Qgc2V0CkNPTkZJR19TTEFCSU5GTz15CkNPTkZJR19SVF9NVVRFWEVTPXkKQ09ORklHX0JB U0VfU01BTEw9MApDT05GSUdfTU9EVUxFUz15CiMgQ09ORklHX01PRFVMRV9GT1JDRV9MT0FEIGlz IG5vdCBzZXQKQ09ORklHX01PRFVMRV9VTkxPQUQ9eQojIENPTkZJR19NT0RVTEVfRk9SQ0VfVU5M T0FEIGlzIG5vdCBzZXQKIyBDT05GSUdfTU9EVkVSU0lPTlMgaXMgbm90IHNldAojIENPTkZJR19N T0RVTEVfU1JDVkVSU0lPTl9BTEwgaXMgbm90IHNldApDT05GSUdfTU9EVUxFX1NJRz15CiMgQ09O RklHX01PRFVMRV9TSUdfRk9SQ0UgaXMgbm90IHNldApDT05GSUdfTU9EVUxFX1NJR19CTEFDS0xJ U1Q9eQpDT05GSUdfTU9EVUxFX1NJR19VRUZJPXkKIyBDT05GSUdfTU9EVUxFX1NJR19TSEExIGlz IG5vdCBzZXQKIyBDT05GSUdfTU9EVUxFX1NJR19TSEEyMjQgaXMgbm90IHNldApDT05GSUdfTU9E VUxFX1NJR19TSEEyNTY9eQojIENPTkZJR19NT0RVTEVfU0lHX1NIQTM4NCBpcyBub3Qgc2V0CiMg Q09ORklHX01PRFVMRV9TSUdfU0hBNTEyIGlzIG5vdCBzZXQKQ09ORklHX1NUT1BfTUFDSElORT15 CkNPTkZJR19CTE9DSz15CkNPTkZJR19CTEtfREVWX0JTRz15CkNPTkZJR19CTEtfREVWX0JTR0xJ Qj15CkNPTkZJR19CTEtfREVWX0lOVEVHUklUWT15CkNPTkZJR19CTEtfREVWX1RIUk9UVExJTkc9 eQoKIwojIFBhcnRpdGlvbiBUeXBlcwojCkNPTkZJR19QQVJUSVRJT05fQURWQU5DRUQ9eQojIENP TkZJR19BQ09STl9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfT1NGX1BBUlRJVElPTj15CkNP TkZJR19BTUlHQV9QQVJUSVRJT049eQojIENPTkZJR19BVEFSSV9QQVJUSVRJT04gaXMgbm90IHNl dApDT05GSUdfTUFDX1BBUlRJVElPTj15CkNPTkZJR19NU0RPU19QQVJUSVRJT049eQpDT05GSUdf QlNEX0RJU0tMQUJFTD15CkNPTkZJR19NSU5JWF9TVUJQQVJUSVRJT049eQpDT05GSUdfU09MQVJJ U19YODZfUEFSVElUSU9OPXkKQ09ORklHX1VOSVhXQVJFX0RJU0tMQUJFTD15CiMgQ09ORklHX0xE TV9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfU0dJX1BBUlRJVElPTj15CiMgQ09ORklHX1VM VFJJWF9QQVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfU1VOX1BBUlRJVElPTj15CkNPTkZJR19L QVJNQV9QQVJUSVRJT049eQpDT05GSUdfRUZJX1BBUlRJVElPTj15CiMgQ09ORklHX1NZU1Y2OF9Q QVJUSVRJT04gaXMgbm90IHNldApDT05GSUdfQkxPQ0tfQ09NUEFUPXkKCiMKIyBJTyBTY2hlZHVs ZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15CkNPTkZJR19JT1NDSEVEX0RFQURMSU5FPXkKQ09O RklHX0lPU0NIRURfQ0ZRPXkKQ09ORklHX0NGUV9HUk9VUF9JT1NDSEVEPXkKIyBDT05GSUdfREVG QVVMVF9ERUFETElORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0NGUT15CiMgQ09ORklHX0RF RkFVTFRfTk9PUCBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPU0NIRUQ9ImNmcSIKQ09ORklH X1BSRUVNUFRfTk9USUZJRVJTPXkKQ09ORklHX1BBREFUQT15CkNPTkZJR19BU04xPXkKIyBDT05G SUdfSU5MSU5FX1NQSU5fVFJZTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX1RS WUxPQ0tfQkggaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfU1BJTl9MT0NLIGlzIG5vdCBzZXQK IyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9T UElOX0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19JUlFTQVZF IGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQSU5fVU5MT0NLX0JIIGlzIG5vdCBzZXQKQ09O RklHX0lOTElORV9TUElOX1VOTE9DS19JUlE9eQojIENPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tf SVJRUkVTVE9SRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX1RSWUxPQ0sgaXMgbm90 IHNldAojIENPTkZJR19JTkxJTkVfUkVBRF9MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5F X1JFQURfTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xPQ0tfSVJRIGlz IG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfTE9DS19JUlFTQVZFIGlzIG5vdCBzZXQKQ09O RklHX0lOTElORV9SRUFEX1VOTE9DSz15CiMgQ09ORklHX0lOTElORV9SRUFEX1VOTE9DS19CSCBp cyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfUkVBRF9VTkxPQ0tfSVJRPXkKIyBDT05GSUdfSU5MSU5F X1JFQURfVU5MT0NLX0lSUVJFU1RPUkUgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVf VFJZTE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9MT0NLIGlzIG5vdCBzZXQK IyBDT05GSUdfSU5MSU5FX1dSSVRFX0xPQ0tfQkggaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVf V1JJVEVfTE9DS19JUlEgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVfTE9DS19JUlFT QVZFIGlzIG5vdCBzZXQKQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0s9eQojIENPTkZJR19JTkxJ TkVfV1JJVEVfVU5MT0NLX0JIIGlzIG5vdCBzZXQKQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0tf SVJRPXkKIyBDT05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19JUlFSRVNUT1JFIGlzIG5vdCBzZXQK Q09ORklHX01VVEVYX1NQSU5fT05fT1dORVI9eQpDT05GSUdfRlJFRVpFUj15CgojCiMgUHJvY2Vz c29yIHR5cGUgYW5kIGZlYXR1cmVzCiMKQ09ORklHX1pPTkVfRE1BPXkKQ09ORklHX1NNUD15CkNP TkZJR19YODZfWDJBUElDPXkKQ09ORklHX1g4Nl9NUFBBUlNFPXkKQ09ORklHX1g4Nl9FWFRFTkRF RF9QTEFURk9STT15CiMgQ09ORklHX1g4Nl9OVU1BQ0hJUCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4 Nl9WU01QIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X1VWIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9T VVBQT1JUU19NRU1PUllfRkFJTFVSRT15CkNPTkZJR19TQ0hFRF9PTUlUX0ZSQU1FX1BPSU5URVI9 eQpDT05GSUdfUEFSQVZJUlRfR1VFU1Q9eQpDT05GSUdfUEFSQVZJUlRfVElNRV9BQ0NPVU5USU5H PXkKQ09ORklHX1hFTj15CkNPTkZJR19YRU5fRE9NMD15CkNPTkZJR19YRU5fUFJJVklMRUdFRF9H VUVTVD15CkNPTkZJR19YRU5fUFZIVk09eQpDT05GSUdfWEVOX01BWF9ET01BSU5fTUVNT1JZPTUw MApDT05GSUdfWEVOX1NBVkVfUkVTVE9SRT15CiMgQ09ORklHX1hFTl9ERUJVR19GUyBpcyBub3Qg c2V0CkNPTkZJR19LVk1fQ0xPQ0s9eQpDT05GSUdfS1ZNX0dVRVNUPXkKQ09ORklHX1BBUkFWSVJU PXkKIyBDT05GSUdfUEFSQVZJUlRfU1BJTkxPQ0tTIGlzIG5vdCBzZXQKQ09ORklHX1BBUkFWSVJU X0NMT0NLPXkKIyBDT05GSUdfUEFSQVZJUlRfREVCVUcgaXMgbm90IHNldApDT05GSUdfTk9fQk9P VE1FTT15CiMgQ09ORklHX01FTVRFU1QgaXMgbm90IHNldAojIENPTkZJR19NSzggaXMgbm90IHNl dAojIENPTkZJR19NUFNDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUNPUkUyIGlzIG5vdCBzZXQKIyBD T05GSUdfTUFUT00gaXMgbm90IHNldApDT05GSUdfR0VORVJJQ19DUFU9eQpDT05GSUdfWDg2X0lO VEVSTk9ERV9DQUNIRV9TSElGVD02CkNPTkZJR19YODZfQ01QWENIRz15CkNPTkZJR19YODZfTDFf Q0FDSEVfU0hJRlQ9NgpDT05GSUdfWDg2X1hBREQ9eQpDT05GSUdfWDg2X1dQX1dPUktTX09LPXkK Q09ORklHX1g4Nl9UU0M9eQpDT05GSUdfWDg2X0NNUFhDSEc2ND15CkNPTkZJR19YODZfQ01PVj15 CkNPTkZJR19YODZfTUlOSU1VTV9DUFVfRkFNSUxZPTY0CkNPTkZJR19YODZfREVCVUdDVExNU1I9 eQpDT05GSUdfQ1BVX1NVUF9JTlRFTD15CkNPTkZJR19DUFVfU1VQX0FNRD15CkNPTkZJR19DUFVf U1VQX0NFTlRBVVI9eQpDT05GSUdfSFBFVF9USU1FUj15CkNPTkZJR19IUEVUX0VNVUxBVEVfUlRD PXkKQ09ORklHX0RNST15CkNPTkZJR19HQVJUX0lPTU1VPXkKIyBDT05GSUdfQ0FMR0FSWV9JT01N VSBpcyBub3Qgc2V0CkNPTkZJR19TV0lPVExCPXkKQ09ORklHX0lPTU1VX0hFTFBFUj15CiMgQ09O RklHX01BWFNNUCBpcyBub3Qgc2V0CkNPTkZJR19OUl9DUFVTPTEyOApDT05GSUdfU0NIRURfU01U PXkKQ09ORklHX1NDSEVEX01DPXkKQ09ORklHX0lSUV9USU1FX0FDQ09VTlRJTkc9eQojIENPTkZJ R19QUkVFTVBUX05PTkUgaXMgbm90IHNldApDT05GSUdfUFJFRU1QVF9WT0xVTlRBUlk9eQojIENP TkZJR19QUkVFTVBUIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9MT0NBTF9BUElDPXkKQ09ORklHX1g4 Nl9JT19BUElDPXkKQ09ORklHX1g4Nl9SRVJPVVRFX0ZPUl9CUk9LRU5fQk9PVF9JUlFTPXkKQ09O RklHX1g4Nl9NQ0U9eQpDT05GSUdfWDg2X01DRV9JTlRFTD15CkNPTkZJR19YODZfTUNFX0FNRD15 CkNPTkZJR19YODZfTUNFX1RIUkVTSE9MRD15CiMgQ09ORklHX1g4Nl9NQ0VfSU5KRUNUIGlzIG5v dCBzZXQKQ09ORklHX1g4Nl9USEVSTUFMX1ZFQ1RPUj15CkNPTkZJR19JOEs9bQpDT05GSUdfTUlD Uk9DT0RFPW0KQ09ORklHX01JQ1JPQ09ERV9JTlRFTD15CkNPTkZJR19NSUNST0NPREVfQU1EPXkK Q09ORklHX01JQ1JPQ09ERV9PTERfSU5URVJGQUNFPXkKQ09ORklHX1g4Nl9NU1I9eQpDT05GSUdf WDg2X0NQVUlEPXkKQ09ORklHX0FSQ0hfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9E TUFfQUREUl9UXzY0QklUPXkKQ09ORklHX0RJUkVDVF9HQlBBR0VTPXkKQ09ORklHX05VTUE9eQpD T05GSUdfQU1EX05VTUE9eQpDT05GSUdfWDg2XzY0X0FDUElfTlVNQT15CkNPTkZJR19OT0RFU19T UEFOX09USEVSX05PREVTPXkKIyBDT05GSUdfTlVNQV9FTVUgaXMgbm90IHNldApDT05GSUdfTk9E RVNfU0hJRlQ9OQpDT05GSUdfQVJDSF9TUEFSU0VNRU1fRU5BQkxFPXkKQ09ORklHX0FSQ0hfU1BB UlNFTUVNX0RFRkFVTFQ9eQpDT05GSUdfQVJDSF9TRUxFQ1RfTUVNT1JZX01PREVMPXkKQ09ORklH X0FSQ0hfUFJPQ19LQ09SRV9URVhUPXkKQ09ORklHX0lMTEVHQUxfUE9JTlRFUl9WQUxVRT0weGRl YWQwMDAwMDAwMDAwMDAKQ09ORklHX1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdfU1BBUlNF TUVNX01BTlVBTD15CkNPTkZJR19TUEFSU0VNRU09eQpDT05GSUdfTkVFRF9NVUxUSVBMRV9OT0RF Uz15CkNPTkZJR19IQVZFX01FTU9SWV9QUkVTRU5UPXkKQ09ORklHX1NQQVJTRU1FTV9FWFRSRU1F PXkKQ09ORklHX1NQQVJTRU1FTV9WTUVNTUFQX0VOQUJMRT15CkNPTkZJR19TUEFSU0VNRU1fQUxM T0NfTUVNX01BUF9UT0dFVEhFUj15CkNPTkZJR19TUEFSU0VNRU1fVk1FTU1BUD15CkNPTkZJR19I QVZFX01FTUJMT0NLPXkKQ09ORklHX0hBVkVfTUVNQkxPQ0tfTk9ERV9NQVA9eQpDT05GSUdfQVJD SF9ESVNDQVJEX01FTUJMT0NLPXkKQ09ORklHX01FTU9SWV9JU09MQVRJT049eQojIENPTkZJR19N RU1PUllfSE9UUExVRyBpcyBub3Qgc2V0CkNPTkZJR19QQUdFRkxBR1NfRVhURU5ERUQ9eQpDT05G SUdfU1BMSVRfUFRMT0NLX0NQVVM9NApDT05GSUdfQ09NUEFDVElPTj15CkNPTkZJR19NSUdSQVRJ T049eQpDT05GSUdfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfWk9ORV9ETUFfRkxBRz0xCkNP TkZJR19CT1VOQ0U9eQpDT05GSUdfVklSVF9UT19CVVM9eQpDT05GSUdfTU1VX05PVElGSUVSPXkK Q09ORklHX0tTTT15CkNPTkZJR19ERUZBVUxUX01NQVBfTUlOX0FERFI9NDA5NgpDT05GSUdfQVJD SF9TVVBQT1JUU19NRU1PUllfRkFJTFVSRT15CkNPTkZJR19NRU1PUllfRkFJTFVSRT15CkNPTkZJ R19IV1BPSVNPTl9JTkpFQ1Q9bQpDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBBR0U9eQpDT05GSUdf VFJBTlNQQVJFTlRfSFVHRVBBR0VfQUxXQVlTPXkKIyBDT05GSUdfVFJBTlNQQVJFTlRfSFVHRVBB R0VfTUFEVklTRSBpcyBub3Qgc2V0CkNPTkZJR19DUk9TU19NRU1PUllfQVRUQUNIPXkKQ09ORklH X0NMRUFOQ0FDSEU9eQpDT05GSUdfRlJPTlRTV0FQPXkKQ09ORklHX1g4Nl9DSEVDS19CSU9TX0NP UlJVUFRJT049eQojIENPTkZJR19YODZfQk9PVFBBUkFNX01FTU9SWV9DT1JSVVBUSU9OX0NIRUNL IGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9SRVNFUlZFX0xPVz02NApDT05GSUdfTVRSUj15CkNPTkZJ R19NVFJSX1NBTklUSVpFUj15CkNPTkZJR19NVFJSX1NBTklUSVpFUl9FTkFCTEVfREVGQVVMVD0x CkNPTkZJR19NVFJSX1NBTklUSVpFUl9TUEFSRV9SRUdfTlJfREVGQVVMVD0xCkNPTkZJR19YODZf UEFUPXkKQ09ORklHX0FSQ0hfVVNFU19QR19VTkNBQ0hFRD15CkNPTkZJR19BUkNIX1JBTkRPTT15 CkNPTkZJR19FRkk9eQpDT05GSUdfRUZJX1NUVUI9eQpDT05GSUdfU0VDQ09NUD15CkNPTkZJR19D Q19TVEFDS1BST1RFQ1RPUj15CiMgQ09ORklHX0haXzEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ha XzI1MCBpcyBub3Qgc2V0CiMgQ09ORklHX0haXzMwMCBpcyBub3Qgc2V0CkNPTkZJR19IWl8xMDAw PXkKQ09ORklHX0haPTEwMDAKQ09ORklHX1NDSEVEX0hSVElDSz15CkNPTkZJR19LRVhFQz15CkNP TkZJR19DUkFTSF9EVU1QPXkKQ09ORklHX0tFWEVDX0pVTVA9eQpDT05GSUdfUEhZU0lDQUxfU1RB UlQ9MHgxMDAwMDAwCkNPTkZJR19SRUxPQ0FUQUJMRT15CkNPTkZJR19QSFlTSUNBTF9BTElHTj0w eDEwMDAwMDAKQ09ORklHX0hPVFBMVUdfQ1BVPXkKIyBDT05GSUdfQ09NUEFUX1ZEU08gaXMgbm90 IHNldAojIENPTkZJR19DTURMSU5FX0JPT0wgaXMgbm90IHNldApDT05GSUdfQVJDSF9FTkFCTEVf TUVNT1JZX0hPVFBMVUc9eQpDT05GSUdfVVNFX1BFUkNQVV9OVU1BX05PREVfSUQ9eQoKIwojIFBv d2VyIG1hbmFnZW1lbnQgYW5kIEFDUEkgb3B0aW9ucwojCkNPTkZJR19BUkNIX0hJQkVSTkFUSU9O X0hFQURFUj15CkNPTkZJR19TVVNQRU5EPXkKQ09ORklHX1NVU1BFTkRfRlJFRVpFUj15CkNPTkZJ R19ISUJFUk5BVEVfQ0FMTEJBQ0tTPXkKQ09ORklHX0hJQkVSTkFUSU9OPXkKQ09ORklHX1BNX1NU RF9QQVJUSVRJT049IiIKQ09ORklHX1BNX1NMRUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CiMg Q09ORklHX1BNX0FVVE9TTEVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BNX1dBS0VMT0NLUyBpcyBu b3Qgc2V0CkNPTkZJR19QTV9SVU5USU1FPXkKQ09ORklHX1BNPXkKQ09ORklHX1BNX0RFQlVHPXkK Q09ORklHX1BNX0FEVkFOQ0VEX0RFQlVHPXkKIyBDT05GSUdfUE1fVEVTVF9TVVNQRU5EIGlzIG5v dCBzZXQKQ09ORklHX1BNX1NMRUVQX0RFQlVHPXkKQ09ORklHX1BNX1RSQUNFPXkKQ09ORklHX1BN X1RSQUNFX1JUQz15CkNPTkZJR19BQ1BJPXkKQ09ORklHX0FDUElfU0xFRVA9eQpDT05GSUdfQUNQ SV9QUk9DRlM9eQojIENPTkZJR19BQ1BJX1BST0NGU19QT1dFUiBpcyBub3Qgc2V0CkNPTkZJR19B Q1BJX0VDX0RFQlVHRlM9bQojIENPTkZJR19BQ1BJX1BST0NfRVZFTlQgaXMgbm90IHNldApDT05G SUdfQUNQSV9BQz15CkNPTkZJR19BQ1BJX0JBVFRFUlk9eQpDT05GSUdfQUNQSV9CVVRUT049eQpD T05GSUdfQUNQSV9WSURFTz1tCkNPTkZJR19BQ1BJX0ZBTj15CkNPTkZJR19BQ1BJX0RPQ0s9eQpD T05GSUdfQUNQSV9QUk9DRVNTT1I9eQpDT05GSUdfQUNQSV9JUE1JPW0KQ09ORklHX0FDUElfSE9U UExVR19DUFU9eQpDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRPUj1tCkNPTkZJR19BQ1BJ X1RIRVJNQUw9eQpDT05GSUdfQUNQSV9OVU1BPXkKIyBDT05GSUdfQUNQSV9DVVNUT01fRFNEVCBp cyBub3Qgc2V0CkNPTkZJR19BQ1BJX0JMQUNLTElTVF9ZRUFSPTAKIyBDT05GSUdfQUNQSV9ERUJV RyBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX1BDSV9TTE9UPXkKQ09ORklHX1g4Nl9QTV9USU1FUj15 CkNPTkZJR19BQ1BJX0NPTlRBSU5FUj15CkNPTkZJR19BQ1BJX1NCUz1tCkNPTkZJR19BQ1BJX0hF RD15CkNPTkZJR19BQ1BJX0NVU1RPTV9NRVRIT0Q9bQpDT05GSUdfQUNQSV9CR1JUPXkKQ09ORklH X0FDUElfQVBFST15CkNPTkZJR19BQ1BJX0FQRUlfR0hFUz15CkNPTkZJR19BQ1BJX0FQRUlfUENJ RUFFUj15CkNPTkZJR19BQ1BJX0FQRUlfTUVNT1JZX0ZBSUxVUkU9eQojIENPTkZJR19BQ1BJX0FQ RUlfRUlOSiBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfQVBFSV9FUlNUX0RFQlVHIGlzIG5vdCBz ZXQKQ09ORklHX1NGST15CgojCiMgQ1BVIEZyZXF1ZW5jeSBzY2FsaW5nCiMKQ09ORklHX0NQVV9G UkVRPXkKQ09ORklHX0NQVV9GUkVRX1RBQkxFPXkKQ09ORklHX0NQVV9GUkVRX1NUQVQ9bQpDT05G SUdfQ1BVX0ZSRVFfU1RBVF9ERVRBSUxTPXkKIyBDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1Zf UEVSRk9STUFOQ0UgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9VU0VS U1BBQ0UgaXMgbm90IHNldApDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfT05ERU1BTkQ9eQoj IENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9DT05TRVJWQVRJVkUgaXMgbm90IHNldApDT05G SUdfQ1BVX0ZSRVFfR09WX1BFUkZPUk1BTkNFPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9QT1dFUlNB VkU9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX1VTRVJTUEFDRT15CkNPTkZJR19DUFVfRlJFUV9HT1Zf T05ERU1BTkQ9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTlNFUlZBVElWRT15CgojCiMgeDg2IENQ VSBmcmVxdWVuY3kgc2NhbGluZyBkcml2ZXJzCiMKQ09ORklHX1g4Nl9QQ0NfQ1BVRlJFUT15CkNP TkZJR19YODZfQUNQSV9DUFVGUkVRPXkKQ09ORklHX1g4Nl9QT1dFUk5PV19LOD15CiMgQ09ORklH X1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk8gaXMgbm90IHNldApDT05GSUdfWDg2X1A0X0NMT0NLTU9E PXkKCiMKIyBzaGFyZWQgb3B0aW9ucwojCkNPTkZJR19YODZfU1BFRURTVEVQX0xJQj15CkNPTkZJ R19DUFVfSURMRT15CkNPTkZJR19DUFVfSURMRV9HT1ZfTEFEREVSPXkKQ09ORklHX0NQVV9JRExF X0dPVl9NRU5VPXkKIyBDT05GSUdfQVJDSF9ORUVEU19DUFVfSURMRV9DT1VQTEVEIGlzIG5vdCBz ZXQKQ09ORklHX0lOVEVMX0lETEU9eQoKIwojIE1lbW9yeSBwb3dlciBzYXZpbmdzCiMKQ09ORklH X0k3MzAwX0lETEVfSU9BVF9DSEFOTkVMPXkKQ09ORklHX0k3MzAwX0lETEU9bQoKIwojIEJ1cyBv cHRpb25zIChQQ0kgZXRjLikKIwpDT05GSUdfUENJPXkKQ09ORklHX1BDSV9ESVJFQ1Q9eQpDT05G SUdfUENJX01NQ09ORklHPXkKQ09ORklHX1BDSV9YRU49eQpDT05GSUdfUENJX0RPTUFJTlM9eQoj IENPTkZJR19QQ0lfQ05CMjBMRV9RVUlSSyBpcyBub3Qgc2V0CkNPTkZJR19QQ0lFUE9SVEJVUz15 CkNPTkZJR19IT1RQTFVHX1BDSV9QQ0lFPXkKQ09ORklHX1BDSUVBRVI9eQpDT05GSUdfUENJRV9F Q1JDPXkKQ09ORklHX1BDSUVBRVJfSU5KRUNUPW0KQ09ORklHX1BDSUVBU1BNPXkKIyBDT05GSUdf UENJRUFTUE1fREVCVUcgaXMgbm90IHNldApDT05GSUdfUENJRUFTUE1fREVGQVVMVD15CiMgQ09O RklHX1BDSUVBU1BNX1BPV0VSU0FWRSBpcyBub3Qgc2V0CiMgQ09ORklHX1BDSUVBU1BNX1BFUkZP Uk1BTkNFIGlzIG5vdCBzZXQKQ09ORklHX1BDSUVfUE1FPXkKQ09ORklHX0FSQ0hfU1VQUE9SVFNf TVNJPXkKQ09ORklHX1BDSV9NU0k9eQojIENPTkZJR19QQ0lfREVCVUcgaXMgbm90IHNldAojIENP TkZJR19QQ0lfUkVBTExPQ19FTkFCTEVfQVVUTyBpcyBub3Qgc2V0CkNPTkZJR19QQ0lfU1RVQj15 CkNPTkZJR19YRU5fUENJREVWX0ZST05URU5EPXkKQ09ORklHX0hUX0lSUT15CkNPTkZJR19QQ0lf QVRTPXkKQ09ORklHX1BDSV9JT1Y9eQpDT05GSUdfUENJX1BSST15CkNPTkZJR19QQ0lfUEFTSUQ9 eQpDT05GSUdfUENJX0lPQVBJQz15CkNPTkZJR19QQ0lfTEFCRUw9eQpDT05GSUdfSVNBX0RNQV9B UEk9eQpDT05GSUdfQU1EX05CPXkKQ09ORklHX1BDQ0FSRD15CkNPTkZJR19QQ01DSUE9eQpDT05G SUdfUENNQ0lBX0xPQURfQ0lTPXkKQ09ORklHX0NBUkRCVVM9eQoKIwojIFBDLWNhcmQgYnJpZGdl cwojCkNPTkZJR19ZRU5UQT1tCkNPTkZJR19ZRU5UQV9PMj15CkNPTkZJR19ZRU5UQV9SSUNPSD15 CkNPTkZJR19ZRU5UQV9UST15CkNPTkZJR19ZRU5UQV9FTkVfVFVORT15CkNPTkZJR19ZRU5UQV9U T1NISUJBPXkKQ09ORklHX1BENjcyOT1tCkNPTkZJR19JODIwOTI9bQpDT05GSUdfUENDQVJEX05P TlNUQVRJQz15CkNPTkZJR19IT1RQTFVHX1BDST15CkNPTkZJR19IT1RQTFVHX1BDSV9GQUtFPW0K Q09ORklHX0hPVFBMVUdfUENJX0FDUEk9eQpDT05GSUdfSE9UUExVR19QQ0lfQUNQSV9JQk09bQoj IENPTkZJR19IT1RQTFVHX1BDSV9DUENJIGlzIG5vdCBzZXQKQ09ORklHX0hPVFBMVUdfUENJX1NI UEM9bQojIENPTkZJR19SQVBJRElPIGlzIG5vdCBzZXQKCiMKIyBFeGVjdXRhYmxlIGZpbGUgZm9y bWF0cyAvIEVtdWxhdGlvbnMKIwpDT05GSUdfQklORk1UX0VMRj15CkNPTkZJR19DT01QQVRfQklO Rk1UX0VMRj15CkNPTkZJR19BUkNIX0JJTkZNVF9FTEZfUkFORE9NSVpFX1BJRT15CkNPTkZJR19D T1JFX0RVTVBfREVGQVVMVF9FTEZfSEVBREVSUz15CiMgQ09ORklHX0hBVkVfQU9VVCBpcyBub3Qg c2V0CkNPTkZJR19CSU5GTVRfTUlTQz1tCkNPTkZJR19JQTMyX0VNVUxBVElPTj15CiMgQ09ORklH X0lBMzJfQU9VVCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9YMzIgaXMgbm90IHNldApDT05GSUdf Q09NUEFUPXkKQ09ORklHX0NPTVBBVF9GT1JfVTY0X0FMSUdOTUVOVD15CkNPTkZJR19TWVNWSVBD X0NPTVBBVD15CkNPTkZJR19LRVlTX0NPTVBBVD15CkNPTkZJR19IQVZFX1RFWFRfUE9LRV9TTVA9 eQpDT05GSUdfWDg2X0RFVl9ETUFfT1BTPXkKQ09ORklHX05FVD15CkNPTkZJR19DT01QQVRfTkVU TElOS19NRVNTQUdFUz15CgojCiMgTmV0d29ya2luZyBvcHRpb25zCiMKQ09ORklHX1BBQ0tFVD15 CkNPTkZJR19VTklYPXkKQ09ORklHX1VOSVhfRElBRz1tCkNPTkZJR19YRlJNPXkKQ09ORklHX1hG Uk1fQUxHTz15CkNPTkZJR19YRlJNX1VTRVI9eQpDT05GSUdfWEZSTV9TVUJfUE9MSUNZPXkKQ09O RklHX1hGUk1fTUlHUkFURT15CkNPTkZJR19YRlJNX1NUQVRJU1RJQ1M9eQpDT05GSUdfWEZSTV9J UENPTVA9bQpDT05GSUdfTkVUX0tFWT1tCkNPTkZJR19ORVRfS0VZX01JR1JBVEU9eQpDT05GSUdf SU5FVD15CkNPTkZJR19JUF9NVUxUSUNBU1Q9eQpDT05GSUdfSVBfQURWQU5DRURfUk9VVEVSPXkK Q09ORklHX0lQX0ZJQl9UUklFX1NUQVRTPXkKQ09ORklHX0lQX01VTFRJUExFX1RBQkxFUz15CkNP TkZJR19JUF9ST1VURV9NVUxUSVBBVEg9eQpDT05GSUdfSVBfUk9VVEVfVkVSQk9TRT15CkNPTkZJ R19JUF9ST1VURV9DTEFTU0lEPXkKIyBDT05GSUdfSVBfUE5QIGlzIG5vdCBzZXQKQ09ORklHX05F VF9JUElQPW0KQ09ORklHX05FVF9JUEdSRV9ERU1VWD1tCkNPTkZJR19ORVRfSVBHUkU9bQpDT05G SUdfTkVUX0lQR1JFX0JST0FEQ0FTVD15CkNPTkZJR19JUF9NUk9VVEU9eQpDT05GSUdfSVBfTVJP VVRFX01VTFRJUExFX1RBQkxFUz15CkNPTkZJR19JUF9QSU1TTV9WMT15CkNPTkZJR19JUF9QSU1T TV9WMj15CkNPTkZJR19BUlBEPXkKQ09ORklHX1NZTl9DT09LSUVTPXkKQ09ORklHX05FVF9JUFZU ST1tCkNPTkZJR19JTkVUX0FIPW0KQ09ORklHX0lORVRfRVNQPW0KQ09ORklHX0lORVRfSVBDT01Q PW0KQ09ORklHX0lORVRfWEZSTV9UVU5ORUw9bQpDT05GSUdfSU5FVF9UVU5ORUw9bQpDT05GSUdf SU5FVF9YRlJNX01PREVfVFJBTlNQT1JUPW0KQ09ORklHX0lORVRfWEZSTV9NT0RFX1RVTk5FTD1t CkNPTkZJR19JTkVUX1hGUk1fTU9ERV9CRUVUPW0KQ09ORklHX0lORVRfTFJPPXkKQ09ORklHX0lO RVRfRElBRz1tCkNPTkZJR19JTkVUX1RDUF9ESUFHPW0KQ09ORklHX0lORVRfVURQX0RJQUc9bQpD T05GSUdfVENQX0NPTkdfQURWQU5DRUQ9eQpDT05GSUdfVENQX0NPTkdfQklDPW0KQ09ORklHX1RD UF9DT05HX0NVQklDPXkKQ09ORklHX1RDUF9DT05HX1dFU1RXT09EPW0KQ09ORklHX1RDUF9DT05H X0hUQ1A9bQpDT05GSUdfVENQX0NPTkdfSFNUQ1A9bQpDT05GSUdfVENQX0NPTkdfSFlCTEE9bQpD T05GSUdfVENQX0NPTkdfVkVHQVM9bQpDT05GSUdfVENQX0NPTkdfU0NBTEFCTEU9bQpDT05GSUdf VENQX0NPTkdfTFA9bQpDT05GSUdfVENQX0NPTkdfVkVOTz1tCkNPTkZJR19UQ1BfQ09OR19ZRUFI PW0KQ09ORklHX1RDUF9DT05HX0lMTElOT0lTPW0KQ09ORklHX0RFRkFVTFRfQ1VCSUM9eQojIENP TkZJR19ERUZBVUxUX1JFTk8gaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9UQ1BfQ09ORz0iY3Vi aWMiCkNPTkZJR19UQ1BfTUQ1U0lHPXkKQ09ORklHX0lQVjY9eQpDT05GSUdfSVBWNl9QUklWQUNZ PXkKQ09ORklHX0lQVjZfUk9VVEVSX1BSRUY9eQpDT05GSUdfSVBWNl9ST1VURV9JTkZPPXkKQ09O RklHX0lQVjZfT1BUSU1JU1RJQ19EQUQ9eQpDT05GSUdfSU5FVDZfQUg9bQpDT05GSUdfSU5FVDZf RVNQPW0KQ09ORklHX0lORVQ2X0lQQ09NUD1tCkNPTkZJR19JUFY2X01JUDY9eQpDT05GSUdfSU5F VDZfWEZSTV9UVU5ORUw9bQpDT05GSUdfSU5FVDZfVFVOTkVMPW0KQ09ORklHX0lORVQ2X1hGUk1f TU9ERV9UUkFOU1BPUlQ9bQpDT05GSUdfSU5FVDZfWEZSTV9NT0RFX1RVTk5FTD1tCkNPTkZJR19J TkVUNl9YRlJNX01PREVfQkVFVD1tCkNPTkZJR19JTkVUNl9YRlJNX01PREVfUk9VVEVPUFRJTUla QVRJT049bQpDT05GSUdfSVBWNl9TSVQ9bQpDT05GSUdfSVBWNl9TSVRfNlJEPXkKQ09ORklHX0lQ VjZfTkRJU0NfTk9ERVRZUEU9eQpDT05GSUdfSVBWNl9UVU5ORUw9bQpDT05GSUdfSVBWNl9NVUxU SVBMRV9UQUJMRVM9eQpDT05GSUdfSVBWNl9TVUJUUkVFUz15CkNPTkZJR19JUFY2X01ST1VURT15 CkNPTkZJR19JUFY2X01ST1VURV9NVUxUSVBMRV9UQUJMRVM9eQpDT05GSUdfSVBWNl9QSU1TTV9W Mj15CkNPTkZJR19ORVRMQUJFTD15CkNPTkZJR19ORVRXT1JLX1NFQ01BUks9eQpDT05GSUdfTkVU V09SS19QSFlfVElNRVNUQU1QSU5HPXkKQ09ORklHX05FVEZJTFRFUj15CiMgQ09ORklHX05FVEZJ TFRFUl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJfQURWQU5DRUQ9eQpDT05GSUdf QlJJREdFX05FVEZJTFRFUj15CgojCiMgQ29yZSBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbgojCkNP TkZJR19ORVRGSUxURVJfTkVUTElOSz1tCkNPTkZJR19ORVRGSUxURVJfTkVUTElOS19BQ0NUPW0K Q09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFPW0KQ09ORklHX05FVEZJTFRFUl9ORVRMSU5L X0xPRz1tCkNPTkZJR19ORl9DT05OVFJBQ0s9bQpDT05GSUdfTkZfQ09OTlRSQUNLX01BUks9eQpD T05GSUdfTkZfQ09OTlRSQUNLX1NFQ01BUks9eQpDT05GSUdfTkZfQ09OTlRSQUNLX1pPTkVTPXkK Q09ORklHX05GX0NPTk5UUkFDS19QUk9DRlM9eQpDT05GSUdfTkZfQ09OTlRSQUNLX0VWRU5UUz15 CiMgQ09ORklHX05GX0NPTk5UUkFDS19USU1FT1VUIGlzIG5vdCBzZXQKQ09ORklHX05GX0NPTk5U UkFDS19USU1FU1RBTVA9eQpDT05GSUdfTkZfQ1RfUFJPVE9fRENDUD1tCkNPTkZJR19ORl9DVF9Q Uk9UT19HUkU9bQpDT05GSUdfTkZfQ1RfUFJPVE9fU0NUUD1tCkNPTkZJR19ORl9DVF9QUk9UT19V RFBMSVRFPW0KQ09ORklHX05GX0NPTk5UUkFDS19BTUFOREE9bQpDT05GSUdfTkZfQ09OTlRSQUNL X0ZUUD1tCkNPTkZJR19ORl9DT05OVFJBQ0tfSDMyMz1tCkNPTkZJR19ORl9DT05OVFJBQ0tfSVJD PW0KQ09ORklHX05GX0NPTk5UUkFDS19CUk9BRENBU1Q9bQpDT05GSUdfTkZfQ09OTlRSQUNLX05F VEJJT1NfTlM9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1NOTVA9bQpDT05GSUdfTkZfQ09OTlRSQUNL X1BQVFA9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1NBTkU9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1NJ UD1tCkNPTkZJR19ORl9DT05OVFJBQ0tfVEZUUD1tCkNPTkZJR19ORl9DVF9ORVRMSU5LPW0KIyBD T05GSUdfTkZfQ1RfTkVUTElOS19USU1FT1VUIGlzIG5vdCBzZXQKQ09ORklHX05GX0NUX05FVExJ TktfSEVMUEVSPW0KQ09ORklHX05FVEZJTFRFUl9ORVRMSU5LX1FVRVVFX0NUPXkKQ09ORklHX05F VEZJTFRFUl9UUFJPWFk9bQpDT05GSUdfTkVURklMVEVSX1hUQUJMRVM9eQoKIwojIFh0YWJsZXMg Y29tYmluZWQgbW9kdWxlcwojCkNPTkZJR19ORVRGSUxURVJfWFRfTUFSSz1tCkNPTkZJR19ORVRG SUxURVJfWFRfQ09OTk1BUks9bQpDT05GSUdfTkVURklMVEVSX1hUX1NFVD1tCgojCiMgWHRhYmxl cyB0YXJnZXRzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQVVESVQ9bQpDT05GSUdfTkVU RklMVEVSX1hUX1RBUkdFVF9DSEVDS1NVTT1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NM QVNTSUZZPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQ09OTk1BUks9bQpDT05GSUdfTkVU RklMVEVSX1hUX1RBUkdFVF9DT05OU0VDTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU X0NUPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfRFNDUD1tCkNPTkZJR19ORVRGSUxURVJf WFRfVEFSR0VUX0hMPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfSE1BUks9bQpDT05GSUdf TkVURklMVEVSX1hUX1RBUkdFVF9JRExFVElNRVI9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdF VF9MRUQ9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9MT0c9bQpDT05GSUdfTkVURklMVEVS X1hUX1RBUkdFVF9NQVJLPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTkZMT0c9bQpDT05G SUdfTkVURklMVEVSX1hUX1RBUkdFVF9ORlFVRVVFPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJH RVRfTk9UUkFDSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1JBVEVFU1Q9bQpDT05GSUdf TkVURklMVEVSX1hUX1RBUkdFVF9URUU9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUFJP WFk9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUkFDRT1tCkNPTkZJR19ORVRGSUxURVJf WFRfVEFSR0VUX1NFQ01BUks9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BNU1M9bQpD T05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BPUFRTVFJJUD1tCgojCiMgWHRhYmxlcyBtYXRj aGVzCiMKQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9BRERSVFlQRT1tCkNPTkZJR19ORVRGSUxU RVJfWFRfTUFUQ0hfQ0xVU1RFUj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09NTUVOVD1t CkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09OTkJZVEVTPW0KQ09ORklHX05FVEZJTFRFUl9Y VF9NQVRDSF9DT05OTElNSVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5NQVJLPW0K Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OVFJBQ0s9bQpDT05GSUdfTkVURklMVEVSX1hU X01BVENIX0NQVT1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRENDUD1tCkNPTkZJR19ORVRG SUxURVJfWFRfTUFUQ0hfREVWR1JPVVA9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0RTQ1A9 bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VDTj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFU Q0hfRVNQPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9IQVNITElNSVQ9bQpDT05GSUdfTkVU RklMVEVSX1hUX01BVENIX0hFTFBFUj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEw9bQpD T05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQUkFOR0U9bQpDT05GSUdfTkVURklMVEVSX1hUX01B VENIX0lQVlM9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xFTkdUSD1tCkNPTkZJR19ORVRG SUxURVJfWFRfTUFUQ0hfTElNSVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX01BQz1tCkNP TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hf TVVMVElQT1JUPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9ORkFDQ1Q9bQpDT05GSUdfTkVU RklMVEVSX1hUX01BVENIX09TRj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfT1dORVI9bQpD T05GSUdfTkVURklMVEVSX1hUX01BVENIX1BPTElDWT1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFU Q0hfUEhZU0RFVj1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUEtUVFlQRT1tCkNPTkZJR19O RVRGSUxURVJfWFRfTUFUQ0hfUVVPVEE9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JBVEVF U1Q9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JFQUxNPW0KQ09ORklHX05FVEZJTFRFUl9Y VF9NQVRDSF9SRUNFTlQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NDVFA9bQpDT05GSUdf TkVURklMVEVSX1hUX01BVENIX1NPQ0tFVD1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfU1RB VEU9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NUQVRJU1RJQz1tCkNPTkZJR19ORVRGSUxU RVJfWFRfTUFUQ0hfU1RSSU5HPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9UQ1BNU1M9bQpD T05GSUdfTkVURklMVEVSX1hUX01BVENIX1RJTUU9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENI X1UzMj1tCkNPTkZJR19JUF9TRVQ9bQpDT05GSUdfSVBfU0VUX01BWD0yNTYKQ09ORklHX0lQX1NF VF9CSVRNQVBfSVA9bQpDT05GSUdfSVBfU0VUX0JJVE1BUF9JUE1BQz1tCkNPTkZJR19JUF9TRVRf QklUTUFQX1BPUlQ9bQpDT05GSUdfSVBfU0VUX0hBU0hfSVA9bQpDT05GSUdfSVBfU0VUX0hBU0hf SVBQT1JUPW0KQ09ORklHX0lQX1NFVF9IQVNIX0lQUE9SVElQPW0KQ09ORklHX0lQX1NFVF9IQVNI X0lQUE9SVE5FVD1tCkNPTkZJR19JUF9TRVRfSEFTSF9ORVQ9bQpDT05GSUdfSVBfU0VUX0hBU0hf TkVUUE9SVD1tCkNPTkZJR19JUF9TRVRfSEFTSF9ORVRJRkFDRT1tCkNPTkZJR19JUF9TRVRfTElT VF9TRVQ9bQpDT05GSUdfSVBfVlM9bQpDT05GSUdfSVBfVlNfSVBWNj15CiMgQ09ORklHX0lQX1ZT X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0lQX1ZTX1RBQl9CSVRTPTEyCgojCiMgSVBWUyB0cmFu c3BvcnQgcHJvdG9jb2wgbG9hZCBiYWxhbmNpbmcgc3VwcG9ydAojCkNPTkZJR19JUF9WU19QUk9U T19UQ1A9eQpDT05GSUdfSVBfVlNfUFJPVE9fVURQPXkKQ09ORklHX0lQX1ZTX1BST1RPX0FIX0VT UD15CkNPTkZJR19JUF9WU19QUk9UT19FU1A9eQpDT05GSUdfSVBfVlNfUFJPVE9fQUg9eQpDT05G SUdfSVBfVlNfUFJPVE9fU0NUUD15CgojCiMgSVBWUyBzY2hlZHVsZXIKIwpDT05GSUdfSVBfVlNf UlI9bQpDT05GSUdfSVBfVlNfV1JSPW0KQ09ORklHX0lQX1ZTX0xDPW0KQ09ORklHX0lQX1ZTX1dM Qz1tCkNPTkZJR19JUF9WU19MQkxDPW0KQ09ORklHX0lQX1ZTX0xCTENSPW0KQ09ORklHX0lQX1ZT X0RIPW0KQ09ORklHX0lQX1ZTX1NIPW0KQ09ORklHX0lQX1ZTX1NFRD1tCkNPTkZJR19JUF9WU19O UT1tCgojCiMgSVBWUyBTSCBzY2hlZHVsZXIKIwpDT05GSUdfSVBfVlNfU0hfVEFCX0JJVFM9OAoK IwojIElQVlMgYXBwbGljYXRpb24gaGVscGVyCiMKQ09ORklHX0lQX1ZTX0ZUUD1tCkNPTkZJR19J UF9WU19ORkNUPXkKQ09ORklHX0lQX1ZTX1BFX1NJUD1tCgojCiMgSVA6IE5ldGZpbHRlciBDb25m aWd1cmF0aW9uCiMKQ09ORklHX05GX0RFRlJBR19JUFY0PW0KQ09ORklHX05GX0NPTk5UUkFDS19J UFY0PW0KIyBDT05GSUdfTkZfQ09OTlRSQUNLX1BST0NfQ09NUEFUIGlzIG5vdCBzZXQKQ09ORklH X0lQX05GX1FVRVVFPW0KQ09ORklHX0lQX05GX0lQVEFCTEVTPXkKQ09ORklHX0lQX05GX01BVENI X0FIPW0KQ09ORklHX0lQX05GX01BVENIX0VDTj1tCkNPTkZJR19JUF9ORl9NQVRDSF9SUEZJTFRF Uj1tCkNPTkZJR19JUF9ORl9NQVRDSF9UVEw9bQpDT05GSUdfSVBfTkZfRklMVEVSPXkKQ09ORklH X0lQX05GX1RBUkdFVF9SRUpFQ1Q9eQpDT05GSUdfSVBfTkZfVEFSR0VUX1VMT0c9bQpDT05GSUdf TkZfTkFUPW0KQ09ORklHX05GX05BVF9ORUVERUQ9eQpDT05GSUdfSVBfTkZfVEFSR0VUX01BU1FV RVJBREU9bQpDT05GSUdfSVBfTkZfVEFSR0VUX05FVE1BUD1tCkNPTkZJR19JUF9ORl9UQVJHRVRf UkVESVJFQ1Q9bQpDT05GSUdfTkZfTkFUX1NOTVBfQkFTSUM9bQpDT05GSUdfTkZfTkFUX1BST1RP X0RDQ1A9bQpDT05GSUdfTkZfTkFUX1BST1RPX0dSRT1tCkNPTkZJR19ORl9OQVRfUFJPVE9fVURQ TElURT1tCkNPTkZJR19ORl9OQVRfUFJPVE9fU0NUUD1tCkNPTkZJR19ORl9OQVRfRlRQPW0KQ09O RklHX05GX05BVF9JUkM9bQpDT05GSUdfTkZfTkFUX1RGVFA9bQpDT05GSUdfTkZfTkFUX0FNQU5E QT1tCkNPTkZJR19ORl9OQVRfUFBUUD1tCkNPTkZJR19ORl9OQVRfSDMyMz1tCkNPTkZJR19ORl9O QVRfU0lQPW0KQ09ORklHX0lQX05GX01BTkdMRT1tCkNPTkZJR19JUF9ORl9UQVJHRVRfQ0xVU1RF UklQPW0KQ09ORklHX0lQX05GX1RBUkdFVF9FQ049bQpDT05GSUdfSVBfTkZfVEFSR0VUX1RUTD1t CkNPTkZJR19JUF9ORl9SQVc9bQpDT05GSUdfSVBfTkZfU0VDVVJJVFk9bQpDT05GSUdfSVBfTkZf QVJQVEFCTEVTPW0KQ09ORklHX0lQX05GX0FSUEZJTFRFUj1tCkNPTkZJR19JUF9ORl9BUlBfTUFO R0xFPW0KCiMKIyBJUHY2OiBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbgojCkNPTkZJR19ORl9ERUZS QUdfSVBWNj1tCkNPTkZJR19ORl9DT05OVFJBQ0tfSVBWNj1tCkNPTkZJR19JUDZfTkZfSVBUQUJM RVM9bQpDT05GSUdfSVA2X05GX01BVENIX0FIPW0KQ09ORklHX0lQNl9ORl9NQVRDSF9FVUk2ND1t CkNPTkZJR19JUDZfTkZfTUFUQ0hfRlJBRz1tCkNPTkZJR19JUDZfTkZfTUFUQ0hfT1BUUz1tCkNP TkZJR19JUDZfTkZfTUFUQ0hfSEw9bQpDT05GSUdfSVA2X05GX01BVENIX0lQVjZIRUFERVI9bQpD T05GSUdfSVA2X05GX01BVENIX01IPW0KQ09ORklHX0lQNl9ORl9NQVRDSF9SUEZJTFRFUj1tCkNP TkZJR19JUDZfTkZfTUFUQ0hfUlQ9bQpDT05GSUdfSVA2X05GX1RBUkdFVF9ITD1tCkNPTkZJR19J UDZfTkZfRklMVEVSPW0KQ09ORklHX0lQNl9ORl9UQVJHRVRfUkVKRUNUPW0KQ09ORklHX0lQNl9O Rl9NQU5HTEU9bQpDT05GSUdfSVA2X05GX1JBVz1tCkNPTkZJR19JUDZfTkZfU0VDVVJJVFk9bQpD T05GSUdfQlJJREdFX05GX0VCVEFCTEVTPW0KQ09ORklHX0JSSURHRV9FQlRfQlJPVVRFPW0KQ09O RklHX0JSSURHRV9FQlRfVF9GSUxURVI9bQpDT05GSUdfQlJJREdFX0VCVF9UX05BVD1tCkNPTkZJ R19CUklER0VfRUJUXzgwMl8zPW0KQ09ORklHX0JSSURHRV9FQlRfQU1PTkc9bQpDT05GSUdfQlJJ REdFX0VCVF9BUlA9bQpDT05GSUdfQlJJREdFX0VCVF9JUD1tCkNPTkZJR19CUklER0VfRUJUX0lQ Nj1tCkNPTkZJR19CUklER0VfRUJUX0xJTUlUPW0KQ09ORklHX0JSSURHRV9FQlRfTUFSSz1tCkNP TkZJR19CUklER0VfRUJUX1BLVFRZUEU9bQpDT05GSUdfQlJJREdFX0VCVF9TVFA9bQpDT05GSUdf QlJJREdFX0VCVF9WTEFOPW0KQ09ORklHX0JSSURHRV9FQlRfQVJQUkVQTFk9bQpDT05GSUdfQlJJ REdFX0VCVF9ETkFUPW0KQ09ORklHX0JSSURHRV9FQlRfTUFSS19UPW0KQ09ORklHX0JSSURHRV9F QlRfUkVESVJFQ1Q9bQpDT05GSUdfQlJJREdFX0VCVF9TTkFUPW0KQ09ORklHX0JSSURHRV9FQlRf TE9HPW0KQ09ORklHX0JSSURHRV9FQlRfVUxPRz1tCkNPTkZJR19CUklER0VfRUJUX05GTE9HPW0K Q09ORklHX0lQX0RDQ1A9bQpDT05GSUdfSU5FVF9EQ0NQX0RJQUc9bQoKIwojIERDQ1AgQ0NJRHMg Q29uZmlndXJhdGlvbiAoRVhQRVJJTUVOVEFMKQojCiMgQ09ORklHX0lQX0RDQ1BfQ0NJRDJfREVC VUcgaXMgbm90IHNldApDT05GSUdfSVBfRENDUF9DQ0lEMz15CiMgQ09ORklHX0lQX0RDQ1BfQ0NJ RDNfREVCVUcgaXMgbm90IHNldApDT05GSUdfSVBfRENDUF9URlJDX0xJQj15CgojCiMgRENDUCBL ZXJuZWwgSGFja2luZwojCiMgQ09ORklHX0lQX0RDQ1BfREVCVUcgaXMgbm90IHNldAojIENPTkZJ R19ORVRfRENDUFBST0JFIGlzIG5vdCBzZXQKQ09ORklHX0lQX1NDVFA9bQpDT05GSUdfTkVUX1ND VFBQUk9CRT1tCiMgQ09ORklHX1NDVFBfREJHX01TRyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDVFBf REJHX09CSkNOVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDVFBfSE1BQ19OT05FIGlzIG5vdCBzZXQK Q09ORklHX1NDVFBfSE1BQ19TSEExPXkKIyBDT05GSUdfU0NUUF9ITUFDX01ENSBpcyBub3Qgc2V0 CkNPTkZJR19SRFM9bQpDT05GSUdfUkRTX1JETUE9bQpDT05GSUdfUkRTX1RDUD1tCiMgQ09ORklH X1JEU19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1RJUEMgaXMgbm90IHNldApDT05GSUdfQVRN PW0KQ09ORklHX0FUTV9DTElQPW0KIyBDT05GSUdfQVRNX0NMSVBfTk9fSUNNUCBpcyBub3Qgc2V0 CkNPTkZJR19BVE1fTEFORT1tCiMgQ09ORklHX0FUTV9NUE9BIGlzIG5vdCBzZXQKQ09ORklHX0FU TV9CUjI2ODQ9bQojIENPTkZJR19BVE1fQlIyNjg0X0lQRklMVEVSIGlzIG5vdCBzZXQKQ09ORklH X0wyVFA9bQpDT05GSUdfTDJUUF9ERUJVR0ZTPW0KQ09ORklHX0wyVFBfVjM9eQpDT05GSUdfTDJU UF9JUD1tCkNPTkZJR19MMlRQX0VUSD1tCkNPTkZJR19TVFA9bQpDT05GSUdfR0FSUD1tCkNPTkZJ R19CUklER0U9bQpDT05GSUdfQlJJREdFX0lHTVBfU05PT1BJTkc9eQpDT05GSUdfTkVUX0RTQT1t CkNPTkZJR19ORVRfRFNBX1RBR19EU0E9eQpDT05GSUdfTkVUX0RTQV9UQUdfRURTQT15CkNPTkZJ R19ORVRfRFNBX1RBR19UUkFJTEVSPXkKQ09ORklHX1ZMQU5fODAyMVE9bQpDT05GSUdfVkxBTl84 MDIxUV9HVlJQPXkKIyBDT05GSUdfREVDTkVUIGlzIG5vdCBzZXQKQ09ORklHX0xMQz1tCiMgQ09O RklHX0xMQzIgaXMgbm90IHNldApDT05GSUdfSVBYPW0KIyBDT05GSUdfSVBYX0lOVEVSTiBpcyBu b3Qgc2V0CkNPTkZJR19BVEFMSz1tCkNPTkZJR19ERVZfQVBQTEVUQUxLPW0KQ09ORklHX0lQRERQ PW0KQ09ORklHX0lQRERQX0VOQ0FQPXkKQ09ORklHX0lQRERQX0RFQ0FQPXkKIyBDT05GSUdfWDI1 IGlzIG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0CkNPTkZJR19XQU5fUk9VVEVSPW0K IyBDT05GSUdfUEhPTkVUIGlzIG5vdCBzZXQKQ09ORklHX0lFRUU4MDIxNTQ9bQpDT05GSUdfSUVF RTgwMjE1NF82TE9XUEFOPW0KQ09ORklHX01BQzgwMjE1ND1tCkNPTkZJR19ORVRfU0NIRUQ9eQoK IwojIFF1ZXVlaW5nL1NjaGVkdWxpbmcKIwpDT05GSUdfTkVUX1NDSF9DQlE9bQpDT05GSUdfTkVU X1NDSF9IVEI9bQpDT05GSUdfTkVUX1NDSF9IRlNDPW0KQ09ORklHX05FVF9TQ0hfQVRNPW0KQ09O RklHX05FVF9TQ0hfUFJJTz1tCkNPTkZJR19ORVRfU0NIX01VTFRJUT1tCkNPTkZJR19ORVRfU0NI X1JFRD1tCkNPTkZJR19ORVRfU0NIX1NGQj1tCkNPTkZJR19ORVRfU0NIX1NGUT1tCkNPTkZJR19O RVRfU0NIX1RFUUw9bQpDT05GSUdfTkVUX1NDSF9UQkY9bQpDT05GSUdfTkVUX1NDSF9HUkVEPW0K Q09ORklHX05FVF9TQ0hfRFNNQVJLPW0KQ09ORklHX05FVF9TQ0hfTkVURU09bQpDT05GSUdfTkVU X1NDSF9EUlI9bQpDT05GSUdfTkVUX1NDSF9NUVBSSU89bQpDT05GSUdfTkVUX1NDSF9DSE9LRT1t CkNPTkZJR19ORVRfU0NIX1FGUT1tCkNPTkZJR19ORVRfU0NIX0NPREVMPW0KQ09ORklHX05FVF9T Q0hfRlFfQ09ERUw9bQpDT05GSUdfTkVUX1NDSF9JTkdSRVNTPW0KQ09ORklHX05FVF9TQ0hfUExV Rz1tCgojCiMgQ2xhc3NpZmljYXRpb24KIwpDT05GSUdfTkVUX0NMUz15CkNPTkZJR19ORVRfQ0xT X0JBU0lDPW0KQ09ORklHX05FVF9DTFNfVENJTkRFWD1tCkNPTkZJR19ORVRfQ0xTX1JPVVRFND1t CkNPTkZJR19ORVRfQ0xTX0ZXPW0KQ09ORklHX05FVF9DTFNfVTMyPW0KQ09ORklHX0NMU19VMzJf UEVSRj15CkNPTkZJR19DTFNfVTMyX01BUks9eQpDT05GSUdfTkVUX0NMU19SU1ZQPW0KQ09ORklH X05FVF9DTFNfUlNWUDY9bQpDT05GSUdfTkVUX0NMU19GTE9XPW0KQ09ORklHX05FVF9DTFNfQ0dS T1VQPXkKQ09ORklHX05FVF9FTUFUQ0g9eQpDT05GSUdfTkVUX0VNQVRDSF9TVEFDSz0zMgpDT05G SUdfTkVUX0VNQVRDSF9DTVA9bQpDT05GSUdfTkVUX0VNQVRDSF9OQllURT1tCkNPTkZJR19ORVRf RU1BVENIX1UzMj1tCkNPTkZJR19ORVRfRU1BVENIX01FVEE9bQpDT05GSUdfTkVUX0VNQVRDSF9U RVhUPW0KQ09ORklHX05FVF9FTUFUQ0hfSVBTRVQ9bQpDT05GSUdfTkVUX0NMU19BQ1Q9eQpDT05G SUdfTkVUX0FDVF9QT0xJQ0U9bQpDT05GSUdfTkVUX0FDVF9HQUNUPW0KQ09ORklHX0dBQ1RfUFJP Qj15CkNPTkZJR19ORVRfQUNUX01JUlJFRD1tCkNPTkZJR19ORVRfQUNUX0lQVD1tCkNPTkZJR19O RVRfQUNUX05BVD1tCkNPTkZJR19ORVRfQUNUX1BFRElUPW0KQ09ORklHX05FVF9BQ1RfU0lNUD1t CkNPTkZJR19ORVRfQUNUX1NLQkVESVQ9bQpDT05GSUdfTkVUX0FDVF9DU1VNPW0KQ09ORklHX05F VF9DTFNfSU5EPXkKQ09ORklHX05FVF9TQ0hfRklGTz15CkNPTkZJR19EQ0I9eQpDT05GSUdfRE5T X1JFU09MVkVSPW0KQ09ORklHX0JBVE1BTl9BRFY9bQpDT05GSUdfQkFUTUFOX0FEVl9CTEE9eQoj IENPTkZJR19CQVRNQU5fQURWX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX09QRU5WU1dJVENIPW0K Q09ORklHX1JQUz15CkNPTkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKQ09ORklHX05FVFBS SU9fQ0dST1VQPW0KQ09ORklHX0JRTD15CkNPTkZJR19CUEZfSklUPXkKCiMKIyBOZXR3b3JrIHRl c3RpbmcKIwpDT05GSUdfTkVUX1BLVEdFTj1tCiMgQ09ORklHX05FVF9UQ1BQUk9CRSBpcyBub3Qg c2V0CkNPTkZJR19ORVRfRFJPUF9NT05JVE9SPXkKQ09ORklHX0hBTVJBRElPPXkKCiMKIyBQYWNr ZXQgUmFkaW8gcHJvdG9jb2xzCiMKQ09ORklHX0FYMjU9bQpDT05GSUdfQVgyNV9EQU1BX1NMQVZF PXkKQ09ORklHX05FVFJPTT1tCkNPTkZJR19ST1NFPW0KCiMKIyBBWC4yNSBuZXR3b3JrIGRldmlj ZSBkcml2ZXJzCiMKQ09ORklHX01LSVNTPW0KQ09ORklHXzZQQUNLPW0KQ09ORklHX0JQUUVUSEVS PW0KQ09ORklHX0JBWUNPTV9TRVJfRkRYPW0KQ09ORklHX0JBWUNPTV9TRVJfSERYPW0KQ09ORklH X0JBWUNPTV9QQVI9bQpDT05GSUdfWUFNPW0KIyBDT05GSUdfQ0FOIGlzIG5vdCBzZXQKQ09ORklH X0lSREE9bQoKIwojIElyREEgcHJvdG9jb2xzCiMKQ09ORklHX0lSTEFOPW0KQ09ORklHX0lSTkVU PW0KQ09ORklHX0lSQ09NTT1tCiMgQ09ORklHX0lSREFfVUxUUkEgaXMgbm90IHNldAoKIwojIEly REEgb3B0aW9ucwojCkNPTkZJR19JUkRBX0NBQ0hFX0xBU1RfTFNBUD15CkNPTkZJR19JUkRBX0ZB U1RfUlI9eQojIENPTkZJR19JUkRBX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBJbmZyYXJlZC1wb3J0 IGRldmljZSBkcml2ZXJzCiMKCiMKIyBTSVIgZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfSVJUVFlf U0lSPW0KCiMKIyBEb25nbGUgc3VwcG9ydAojCkNPTkZJR19ET05HTEU9eQpDT05GSUdfRVNJX0RP TkdMRT1tCkNPTkZJR19BQ1RJU1lTX0RPTkdMRT1tCkNPTkZJR19URUtSQU1fRE9OR0xFPW0KQ09O RklHX1RPSU0zMjMyX0RPTkdMRT1tCkNPTkZJR19MSVRFTElOS19ET05HTEU9bQpDT05GSUdfTUE2 MDBfRE9OR0xFPW0KQ09ORklHX0dJUkJJTF9ET05HTEU9bQpDT05GSUdfTUNQMjEyMF9ET05HTEU9 bQpDT05GSUdfT0xEX0JFTEtJTl9ET05HTEU9bQpDT05GSUdfQUNUMjAwTF9ET05HTEU9bQpDT05G SUdfS0lOR1NVTl9ET05HTEU9bQpDT05GSUdfS1NEQVpaTEVfRE9OR0xFPW0KQ09ORklHX0tTOTU5 X0RPTkdMRT1tCgojCiMgRklSIGRldmljZSBkcml2ZXJzCiMKQ09ORklHX1VTQl9JUkRBPW0KQ09O RklHX1NJR01BVEVMX0ZJUj1tCkNPTkZJR19OU0NfRklSPW0KQ09ORklHX1dJTkJPTkRfRklSPW0K Q09ORklHX1NNQ19JUkNDX0ZJUj1tCkNPTkZJR19BTElfRklSPW0KQ09ORklHX1ZMU0lfRklSPW0K Q09ORklHX1ZJQV9GSVI9bQpDT05GSUdfTUNTX0ZJUj1tCkNPTkZJR19CVD1tCkNPTkZJR19CVF9S RkNPTU09bQpDT05GSUdfQlRfUkZDT01NX1RUWT15CkNPTkZJR19CVF9CTkVQPW0KQ09ORklHX0JU X0JORVBfTUNfRklMVEVSPXkKQ09ORklHX0JUX0JORVBfUFJPVE9fRklMVEVSPXkKQ09ORklHX0JU X0NNVFA9bQpDT05GSUdfQlRfSElEUD1tCgojCiMgQmx1ZXRvb3RoIGRldmljZSBkcml2ZXJzCiMK Q09ORklHX0JUX0hDSUJUVVNCPW0KQ09ORklHX0JUX0hDSUJUU0RJTz1tCkNPTkZJR19CVF9IQ0lV QVJUPW0KQ09ORklHX0JUX0hDSVVBUlRfSDQ9eQpDT05GSUdfQlRfSENJVUFSVF9CQ1NQPXkKQ09O RklHX0JUX0hDSVVBUlRfQVRIM0s9eQpDT05GSUdfQlRfSENJVUFSVF9MTD15CkNPTkZJR19CVF9I Q0lVQVJUXzNXSVJFPXkKQ09ORklHX0JUX0hDSUJDTTIwM1g9bQpDT05GSUdfQlRfSENJQlBBMTBY PW0KQ09ORklHX0JUX0hDSUJGVVNCPW0KQ09ORklHX0JUX0hDSURUTDE9bQpDT05GSUdfQlRfSENJ QlQzQz1tCkNPTkZJR19CVF9IQ0lCTFVFQ0FSRD1tCkNPTkZJR19CVF9IQ0lCVFVBUlQ9bQpDT05G SUdfQlRfSENJVkhDST1tCkNPTkZJR19CVF9NUlZMPW0KQ09ORklHX0JUX01SVkxfU0RJTz1tCkNP TkZJR19CVF9BVEgzSz1tCiMgQ09ORklHX0FGX1JYUlBDIGlzIG5vdCBzZXQKQ09ORklHX0ZJQl9S VUxFUz15CkNPTkZJR19XSVJFTEVTUz15CkNPTkZJR19XSVJFTEVTU19FWFQ9eQpDT05GSUdfV0VY VF9DT1JFPXkKQ09ORklHX1dFWFRfUFJPQz15CkNPTkZJR19XRVhUX1NQWT15CkNPTkZJR19XRVhU X1BSSVY9eQpDT05GSUdfQ0ZHODAyMTE9bQojIENPTkZJR19OTDgwMjExX1RFU1RNT0RFIGlzIG5v dCBzZXQKIyBDT05GSUdfQ0ZHODAyMTFfREVWRUxPUEVSX1dBUk5JTkdTIGlzIG5vdCBzZXQKIyBD T05GSUdfQ0ZHODAyMTFfUkVHX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0NGRzgwMjExX0RFRkFV TFRfUFM9eQpDT05GSUdfQ0ZHODAyMTFfREVCVUdGUz15CiMgQ09ORklHX0NGRzgwMjExX0lOVEVS TkFMX1JFR0RCIGlzIG5vdCBzZXQKQ09ORklHX0NGRzgwMjExX1dFWFQ9eQpDT05GSUdfTElCODAy MTE9bQpDT05GSUdfTElCODAyMTFfQ1JZUFRfV0VQPW0KQ09ORklHX0xJQjgwMjExX0NSWVBUX0ND TVA9bQpDT05GSUdfTElCODAyMTFfQ1JZUFRfVEtJUD1tCiMgQ09ORklHX0xJQjgwMjExX0RFQlVH IGlzIG5vdCBzZXQKQ09ORklHX01BQzgwMjExPW0KQ09ORklHX01BQzgwMjExX0hBU19SQz15CkNP TkZJR19NQUM4MDIxMV9SQ19NSU5TVFJFTD15CkNPTkZJR19NQUM4MDIxMV9SQ19NSU5TVFJFTF9I VD15CkNPTkZJR19NQUM4MDIxMV9SQ19ERUZBVUxUX01JTlNUUkVMPXkKQ09ORklHX01BQzgwMjEx X1JDX0RFRkFVTFQ9Im1pbnN0cmVsX2h0IgpDT05GSUdfTUFDODAyMTFfTUVTSD15CkNPTkZJR19N QUM4MDIxMV9MRURTPXkKQ09ORklHX01BQzgwMjExX0RFQlVHRlM9eQojIENPTkZJR19NQUM4MDIx MV9NRVNTQUdFX1RSQUNJTkcgaXMgbm90IHNldAojIENPTkZJR19NQUM4MDIxMV9ERUJVR19NRU5V IGlzIG5vdCBzZXQKQ09ORklHX1dJTUFYPW0KQ09ORklHX1dJTUFYX0RFQlVHX0xFVkVMPTgKQ09O RklHX1JGS0lMTD1tCkNPTkZJR19SRktJTExfTEVEUz15CkNPTkZJR19SRktJTExfSU5QVVQ9eQpD T05GSUdfTkVUXzlQPW0KQ09ORklHX05FVF85UF9WSVJUSU89bQpDT05GSUdfTkVUXzlQX1JETUE9 bQojIENPTkZJR19ORVRfOVBfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19DQUlGIGlzIG5vdCBz ZXQKQ09ORklHX0NFUEhfTElCPW0KIyBDT05GSUdfQ0VQSF9MSUJfUFJFVFRZREVCVUcgaXMgbm90 IHNldAojIENPTkZJR19DRVBIX0xJQl9VU0VfRE5TX1JFU09MVkVSIGlzIG5vdCBzZXQKQ09ORklH X05GQz1tCkNPTkZJR19ORkNfTkNJPW0KQ09ORklHX05GQ19IQ0k9bQpDT05GSUdfTkZDX1NIRExD PXkKQ09ORklHX05GQ19MTENQPXkKCiMKIyBOZWFyIEZpZWxkIENvbW11bmljYXRpb24gKE5GQykg ZGV2aWNlcwojCkNPTkZJR19QTjU0NF9ORkM9bQpDT05GSUdfUE41NDRfSENJX05GQz1tCkNPTkZJ R19ORkNfUE41MzM9bQpDT05GSUdfSEFWRV9CUEZfSklUPXkKCiMKIyBEZXZpY2UgRHJpdmVycwoj CgojCiMgR2VuZXJpYyBEcml2ZXIgT3B0aW9ucwojCkNPTkZJR19VRVZFTlRfSEVMUEVSX1BBVEg9 IiIKQ09ORklHX0RFVlRNUEZTPXkKQ09ORklHX0RFVlRNUEZTX01PVU5UPXkKQ09ORklHX1NUQU5E QUxPTkU9eQpDT05GSUdfUFJFVkVOVF9GSVJNV0FSRV9CVUlMRD15CkNPTkZJR19GV19MT0FERVI9 eQojIENPTkZJR19GSVJNV0FSRV9JTl9LRVJORUwgaXMgbm90IHNldApDT05GSUdfRVhUUkFfRklS TVdBUkU9IiIKIyBDT05GSUdfREVCVUdfRFJJVkVSIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX0RF VlJFUz15CkNPTkZJR19TWVNfSFlQRVJWSVNPUj15CiMgQ09ORklHX0dFTkVSSUNfQ1BVX0RFVklD RVMgaXMgbm90IHNldApDT05GSUdfUkVHTUFQPXkKQ09ORklHX1JFR01BUF9JMkM9bQpDT05GSUdf RE1BX1NIQVJFRF9CVUZGRVI9eQpDT05GSUdfQ09OTkVDVE9SPXkKQ09ORklHX1BST0NfRVZFTlRT PXkKQ09ORklHX01URD1tCiMgQ09ORklHX01URF9URVNUUyBpcyBub3Qgc2V0CiMgQ09ORklHX01U RF9SRURCT09UX1BBUlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX0FSN19QQVJUUyBpcyBub3Qg c2V0CgojCiMgVXNlciBNb2R1bGVzIEFuZCBUcmFuc2xhdGlvbiBMYXllcnMKIwojIENPTkZJR19N VERfQ0hBUiBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9CTEtERVZTIGlzIG5vdCBzZXQKIyBDT05G SUdfTVREX0JMT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX0JMT0NLX1JPIGlzIG5vdCBzZXQK IyBDT05GSUdfRlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZUTCBpcyBub3Qgc2V0CiMgQ09ORklH X0lORlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfUkZEX0ZUTCBpcyBub3Qgc2V0CiMgQ09ORklHX1NT RkRDIGlzIG5vdCBzZXQKIyBDT05GSUdfU01fRlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX09P UFMgaXMgbm90IHNldAojIENPTkZJR19NVERfU1dBUCBpcyBub3Qgc2V0CgojCiMgUkFNL1JPTS9G bGFzaCBjaGlwIGRyaXZlcnMKIwojIENPTkZJR19NVERfQ0ZJIGlzIG5vdCBzZXQKIyBDT05GSUdf TVREX0pFREVDUFJPQkUgaXMgbm90IHNldApDT05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzE9eQpD T05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzI9eQpDT05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzQ9 eQojIENPTkZJR19NVERfTUFQX0JBTktfV0lEVEhfOCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9N QVBfQkFOS19XSURUSF8xNiBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9NQVBfQkFOS19XSURUSF8z MiBpcyBub3Qgc2V0CkNPTkZJR19NVERfQ0ZJX0kxPXkKQ09ORklHX01URF9DRklfSTI9eQojIENP TkZJR19NVERfQ0ZJX0k0IGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX0NGSV9JOCBpcyBub3Qgc2V0 CiMgQ09ORklHX01URF9SQU0gaXMgbm90IHNldAojIENPTkZJR19NVERfUk9NIGlzIG5vdCBzZXQK IyBDT05GSUdfTVREX0FCU0VOVCBpcyBub3Qgc2V0CgojCiMgTWFwcGluZyBkcml2ZXJzIGZvciBj aGlwIGFjY2VzcwojCiMgQ09ORklHX01URF9DT01QTEVYX01BUFBJTkdTIGlzIG5vdCBzZXQKIyBD T05GSUdfTVREX1RTNTUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9JTlRFTF9WUl9OT1IgaXMg bm90IHNldAojIENPTkZJR19NVERfUExBVFJBTSBpcyBub3Qgc2V0CgojCiMgU2VsZi1jb250YWlu ZWQgTVREIGRldmljZSBkcml2ZXJzCiMKIyBDT05GSUdfTVREX1BNQzU1MSBpcyBub3Qgc2V0CiMg Q09ORklHX01URF9TTFJBTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9QSFJBTSBpcyBub3Qgc2V0 CiMgQ09ORklHX01URF9NVERSQU0gaXMgbm90IHNldAojIENPTkZJR19NVERfQkxPQ0syTVREIGlz IG5vdCBzZXQKCiMKIyBEaXNrLU9uLUNoaXAgRGV2aWNlIERyaXZlcnMKIwojIENPTkZJR19NVERf RE9DRzMgaXMgbm90IHNldAojIENPTkZJR19NVERfTkFORCBpcyBub3Qgc2V0CiMgQ09ORklHX01U RF9PTkVOQU5EIGlzIG5vdCBzZXQKCiMKIyBMUEREUiBmbGFzaCBtZW1vcnkgZHJpdmVycwojCiMg Q09ORklHX01URF9MUEREUiBpcyBub3Qgc2V0CkNPTkZJR19NVERfVUJJPW0KQ09ORklHX01URF9V QklfV0xfVEhSRVNIT0xEPTQwOTYKQ09ORklHX01URF9VQklfQkVCX1JFU0VSVkU9MgojIENPTkZJ R19NVERfVUJJX0dMVUVCSSBpcyBub3Qgc2V0CkNPTkZJR19QQVJQT1JUPW0KQ09ORklHX1BBUlBP UlRfUEM9bQpDT05GSUdfUEFSUE9SVF9TRVJJQUw9bQojIENPTkZJR19QQVJQT1JUX1BDX0ZJRk8g aXMgbm90IHNldAojIENPTkZJR19QQVJQT1JUX1BDX1NVUEVSSU8gaXMgbm90IHNldApDT05GSUdf UEFSUE9SVF9QQ19QQ01DSUE9bQojIENPTkZJR19QQVJQT1JUX0dTQyBpcyBub3Qgc2V0CiMgQ09O RklHX1BBUlBPUlRfQVg4ODc5NiBpcyBub3Qgc2V0CkNPTkZJR19QQVJQT1JUXzEyODQ9eQpDT05G SUdfUEFSUE9SVF9OT1RfUEM9eQpDT05GSUdfUE5QPXkKIyBDT05GSUdfUE5QX0RFQlVHX01FU1NB R0VTIGlzIG5vdCBzZXQKCiMKIyBQcm90b2NvbHMKIwpDT05GSUdfUE5QQUNQST15CkNPTkZJR19C TEtfREVWPXkKQ09ORklHX0JMS19ERVZfRkQ9bQojIENPTkZJR19QQVJJREUgaXMgbm90IHNldApD T05GSUdfQkxLX0RFVl9QQ0lFU1NEX01USVAzMlhYPW0KQ09ORklHX0JMS19DUFFfREE9bQpDT05G SUdfQkxLX0NQUV9DSVNTX0RBPW0KQ09ORklHX0NJU1NfU0NTSV9UQVBFPXkKQ09ORklHX0JMS19E RVZfREFDOTYwPW0KQ09ORklHX0JMS19ERVZfVU1FTT1tCiMgQ09ORklHX0JMS19ERVZfQ09XX0NP TU1PTiBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0xPT1A9eQpDT05GSUdfQkxLX0RFVl9MT09Q X01JTl9DT1VOVD04CkNPTkZJR19CTEtfREVWX0NSWVBUT0xPT1A9bQpDT05GSUdfQkxLX0RFVl9E UkJEPW0KIyBDT05GSUdfRFJCRF9GQVVMVF9JTkpFQ1RJT04gaXMgbm90IHNldApDT05GSUdfQkxL X0RFVl9OQkQ9bQpDT05GSUdfQkxLX0RFVl9OVk1FPW0KQ09ORklHX0JMS19ERVZfT1NEPW0KQ09O RklHX0JMS19ERVZfU1g4PW0KIyBDT05GSUdfQkxLX0RFVl9VQiBpcyBub3Qgc2V0CkNPTkZJR19C TEtfREVWX1JBTT1tCkNPTkZJR19CTEtfREVWX1JBTV9DT1VOVD0xNgpDT05GSUdfQkxLX0RFVl9S QU1fU0laRT0xNjM4NAojIENPTkZJR19CTEtfREVWX1hJUCBpcyBub3Qgc2V0CkNPTkZJR19DRFJP TV9QS1RDRFZEPW0KQ09ORklHX0NEUk9NX1BLVENEVkRfQlVGRkVSUz04CiMgQ09ORklHX0NEUk9N X1BLVENEVkRfV0NBQ0hFIGlzIG5vdCBzZXQKQ09ORklHX0FUQV9PVkVSX0VUSD1tCkNPTkZJR19Y RU5fQkxLREVWX0ZST05URU5EPXkKQ09ORklHX1hFTl9CTEtERVZfQkFDS0VORD15CkNPTkZJR19W SVJUSU9fQkxLPW0KIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVW X1JCRD1tCgojCiMgTWlzYyBkZXZpY2VzCiMKQ09ORklHX1NFTlNPUlNfTElTM0xWMDJEPW0KIyBD T05GSUdfQUQ1MjVYX0RQT1QgaXMgbm90IHNldAojIENPTkZJR19JQk1fQVNNIGlzIG5vdCBzZXQK IyBDT05GSUdfUEhBTlRPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOVEVMX01JRF9QVEkgaXMgbm90 IHNldApDT05GSUdfU0dJX0lPQzQ9bQpDT05GSUdfVElGTV9DT1JFPW0KQ09ORklHX1RJRk1fN1hY MT1tCiMgQ09ORklHX0lDUzkzMlM0MDEgaXMgbm90IHNldApDT05GSUdfRU5DTE9TVVJFX1NFUlZJ Q0VTPW0KQ09ORklHX0hQX0lMTz1tCkNPTkZJR19BUERTOTgwMkFMUz1tCkNPTkZJR19JU0wyOTAw Mz1tCkNPTkZJR19JU0wyOTAyMD1tCkNPTkZJR19TRU5TT1JTX1RTTDI1NTA9bQojIENPTkZJR19T RU5TT1JTX0JIMTc4MCBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0JIMTc3MD1tCkNPTkZJR19T RU5TT1JTX0FQRFM5OTBYPW0KIyBDT05GSUdfSE1DNjM1MiBpcyBub3Qgc2V0CiMgQ09ORklHX0RT MTY4MiBpcyBub3Qgc2V0CkNPTkZJR19WTVdBUkVfQkFMTE9PTj1tCiMgQ09ORklHX0JNUDA4NV9J MkMgaXMgbm90IHNldApDT05GSUdfUENIX1BIVUI9bQojIENPTkZJR19VU0JfU1dJVENIX0ZTQTk0 ODAgaXMgbm90IHNldAojIENPTkZJR19DMlBPUlQgaXMgbm90IHNldAoKIwojIEVFUFJPTSBzdXBw b3J0CiMKQ09ORklHX0VFUFJPTV9BVDI0PW0KQ09ORklHX0VFUFJPTV9MRUdBQ1k9bQpDT05GSUdf RUVQUk9NX01BWDY4NzU9bQpDT05GSUdfRUVQUk9NXzkzQ1g2PW0KQ09ORklHX0NCNzEwX0NPUkU9 bQojIENPTkZJR19DQjcxMF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19DQjcxMF9ERUJVR19BU1NV TVBUSU9OUz15CgojCiMgVGV4YXMgSW5zdHJ1bWVudHMgc2hhcmVkIHRyYW5zcG9ydCBsaW5lIGRp c2NpcGxpbmUKIwpDT05GSUdfU0VOU09SU19MSVMzX0kyQz1tCgojCiMgQWx0ZXJhIEZQR0EgZmly bXdhcmUgZG93bmxvYWQgbW9kdWxlCiMKQ09ORklHX0FMVEVSQV9TVEFQTD1tCkNPTkZJR19JTlRF TF9NRUk9bQpDT05GSUdfSEFWRV9JREU9eQojIENPTkZJR19JREUgaXMgbm90IHNldAoKIwojIFND U0kgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfU0NTSV9NT0Q9eQpDT05GSUdfUkFJRF9BVFRSUz1t CkNPTkZJR19TQ1NJPXkKQ09ORklHX1NDU0lfRE1BPXkKQ09ORklHX1NDU0lfVEdUPW0KQ09ORklH X1NDU0lfTkVUTElOSz15CkNPTkZJR19TQ1NJX1BST0NfRlM9eQoKIwojIFNDU0kgc3VwcG9ydCB0 eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pCiMKQ09ORklHX0JMS19ERVZfU0Q9eQpDT05GSUdfQ0hS X0RFVl9TVD1tCkNPTkZJR19DSFJfREVWX09TU1Q9bQpDT05GSUdfQkxLX0RFVl9TUj15CkNPTkZJ R19CTEtfREVWX1NSX1ZFTkRPUj15CkNPTkZJR19DSFJfREVWX1NHPXkKQ09ORklHX0NIUl9ERVZf U0NIPW0KQ09ORklHX1NDU0lfRU5DTE9TVVJFPW0KQ09ORklHX1NDU0lfTVVMVElfTFVOPXkKQ09O RklHX1NDU0lfQ09OU1RBTlRTPXkKQ09ORklHX1NDU0lfTE9HR0lORz15CkNPTkZJR19TQ1NJX1ND QU5fQVNZTkM9eQoKIwojIFNDU0kgVHJhbnNwb3J0cwojCkNPTkZJR19TQ1NJX1NQSV9BVFRSUz1t CkNPTkZJR19TQ1NJX0ZDX0FUVFJTPW0KQ09ORklHX1NDU0lfRkNfVEdUX0FUVFJTPXkKQ09ORklH X1NDU0lfSVNDU0lfQVRUUlM9bQpDT05GSUdfU0NTSV9TQVNfQVRUUlM9bQpDT05GSUdfU0NTSV9T QVNfTElCU0FTPW0KQ09ORklHX1NDU0lfU0FTX0FUQT15CkNPTkZJR19TQ1NJX1NBU19IT1NUX1NN UD15CkNPTkZJR19TQ1NJX1NSUF9BVFRSUz1tCkNPTkZJR19TQ1NJX1NSUF9UR1RfQVRUUlM9eQpD T05GSUdfU0NTSV9MT1dMRVZFTD15CkNPTkZJR19JU0NTSV9UQ1A9bQpDT05GSUdfSVNDU0lfQk9P VF9TWVNGUz1tCkNPTkZJR19TQ1NJX0NYR0IzX0lTQ1NJPW0KQ09ORklHX1NDU0lfQ1hHQjRfSVND U0k9bQpDT05GSUdfU0NTSV9CTlgyX0lTQ1NJPW0KQ09ORklHX1NDU0lfQk5YMlhfRkNPRT1tCkNP TkZJR19CRTJJU0NTST1tCkNPTkZJR19CTEtfREVWXzNXX1hYWFhfUkFJRD1tCkNPTkZJR19TQ1NJ X0hQU0E9bQpDT05GSUdfU0NTSV8zV185WFhYPW0KQ09ORklHX1NDU0lfM1dfU0FTPW0KQ09ORklH X1NDU0lfQUNBUkQ9bQpDT05GSUdfU0NTSV9BQUNSQUlEPW0KQ09ORklHX1NDU0lfQUlDN1hYWD1t CkNPTkZJR19BSUM3WFhYX0NNRFNfUEVSX0RFVklDRT00CkNPTkZJR19BSUM3WFhYX1JFU0VUX0RF TEFZX01TPTE1MDAwCiMgQ09ORklHX0FJQzdYWFhfREVCVUdfRU5BQkxFIGlzIG5vdCBzZXQKQ09O RklHX0FJQzdYWFhfREVCVUdfTUFTSz0wCiMgQ09ORklHX0FJQzdYWFhfUkVHX1BSRVRUWV9QUklO VCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX0FJQzdYWFhfT0xEPW0KQ09ORklHX1NDU0lfQUlDNzlY WD1tCkNPTkZJR19BSUM3OVhYX0NNRFNfUEVSX0RFVklDRT00CkNPTkZJR19BSUM3OVhYX1JFU0VU X0RFTEFZX01TPTE1MDAwCiMgQ09ORklHX0FJQzc5WFhfREVCVUdfRU5BQkxFIGlzIG5vdCBzZXQK Q09ORklHX0FJQzc5WFhfREVCVUdfTUFTSz0wCiMgQ09ORklHX0FJQzc5WFhfUkVHX1BSRVRUWV9Q UklOVCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX0FJQzk0WFg9bQojIENPTkZJR19BSUM5NFhYX0RF QlVHIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfTVZTQVM9bQojIENPTkZJR19TQ1NJX01WU0FTX0RF QlVHIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfTVZTQVNfVEFTS0xFVD15CkNPTkZJR19TQ1NJX01W VU1JPW0KIyBDT05GSUdfU0NTSV9EUFRfSTJPIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfQURWQU5T WVM9bQpDT05GSUdfU0NTSV9BUkNNU1I9bQpDT05GSUdfTUVHQVJBSURfTkVXR0VOPXkKQ09ORklH X01FR0FSQUlEX01NPW0KQ09ORklHX01FR0FSQUlEX01BSUxCT1g9bQpDT05GSUdfTUVHQVJBSURf TEVHQUNZPW0KQ09ORklHX01FR0FSQUlEX1NBUz1tCkNPTkZJR19TQ1NJX01QVDJTQVM9bQpDT05G SUdfU0NTSV9NUFQyU0FTX01BWF9TR0U9MTI4CkNPTkZJR19TQ1NJX01QVDJTQVNfTE9HR0lORz15 CkNPTkZJR19TQ1NJX1VGU0hDRD1tCkNPTkZJR19TQ1NJX0hQVElPUD1tCkNPTkZJR19TQ1NJX0JV U0xPR0lDPW0KQ09ORklHX1ZNV0FSRV9QVlNDU0k9bQpDT05GSUdfSFlQRVJWX1NUT1JBR0U9bQpD T05GSUdfTElCRkM9bQpDT05GSUdfTElCRkNPRT1tCkNPTkZJR19GQ09FPW0KQ09ORklHX0ZDT0Vf Rk5JQz1tCiMgQ09ORklHX1NDU0lfRE1YMzE5MUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0VB VEEgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldApDT05G SUdfU0NTSV9HRFRIPW0KQ09ORklHX1NDU0lfSVNDST1tCkNPTkZJR19TQ1NJX0lQUz1tCkNPTkZJ R19TQ1NJX0lOSVRJTz1tCkNPTkZJR19TQ1NJX0lOSUExMDA9bQojIENPTkZJR19TQ1NJX1BQQSBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSU1NIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfU1RFWD1t CkNPTkZJR19TQ1NJX1NZTTUzQzhYWF8yPW0KQ09ORklHX1NDU0lfU1lNNTNDOFhYX0RNQV9BRERS RVNTSU5HX01PREU9MQpDT05GSUdfU0NTSV9TWU01M0M4WFhfREVGQVVMVF9UQUdTPTE2CkNPTkZJ R19TQ1NJX1NZTTUzQzhYWF9NQVhfVEFHUz02NApDT05GSUdfU0NTSV9TWU01M0M4WFhfTU1JTz15 CiMgQ09ORklHX1NDU0lfSVBSIGlzIG5vdCBzZXQKQ09ORklHX1NDU0lfUUxPR0lDXzEyODA9bQpD T05GSUdfU0NTSV9RTEFfRkM9bQpDT05GSUdfVENNX1FMQTJYWFg9bQpDT05GSUdfU0NTSV9RTEFf SVNDU0k9bQpDT05GSUdfU0NTSV9MUEZDPW0KIyBDT05GSUdfU0NTSV9MUEZDX0RFQlVHX0ZTIGlz IG5vdCBzZXQKQ09ORklHX1NDU0lfREMzOTV4PW0KQ09ORklHX1NDU0lfREMzOTBUPW0KQ09ORklH X1NDU0lfREVCVUc9bQpDT05GSUdfU0NTSV9QTUNSQUlEPW0KQ09ORklHX1NDU0lfUE04MDAxPW0K Q09ORklHX1NDU0lfU1JQPW0KQ09ORklHX1NDU0lfQkZBX0ZDPW0KQ09ORklHX1NDU0lfVklSVElP PW0KIyBDT05GSUdfU0NTSV9MT1dMRVZFTF9QQ01DSUEgaXMgbm90IHNldApDT05GSUdfU0NTSV9E SD15CkNPTkZJR19TQ1NJX0RIX1JEQUM9bQpDT05GSUdfU0NTSV9ESF9IUF9TVz1tCkNPTkZJR19T Q1NJX0RIX0VNQz1tCkNPTkZJR19TQ1NJX0RIX0FMVUE9bQpDT05GSUdfU0NTSV9PU0RfSU5JVElB VE9SPW0KQ09ORklHX1NDU0lfT1NEX1VMRD1tCkNPTkZJR19TQ1NJX09TRF9EUFJJTlRfU0VOU0U9 MQojIENPTkZJR19TQ1NJX09TRF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BVEE9eQojIENPTkZJ R19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZFUkJPU0VfRVJST1I9eQpD T05GSUdfQVRBX0FDUEk9eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRyb2xsZXJzIHdpdGgg bm9uLVNGRiBuYXRpdmUgaW50ZXJmYWNlCiMKQ09ORklHX1NBVEFfQUhDST15CkNPTkZJR19TQVRB X0FIQ0lfUExBVEZPUk09bQpDT05GSUdfU0FUQV9JTklDMTYyWD1tCkNPTkZJR19TQVRBX0FDQVJE X0FIQ0k9bQpDT05GSUdfU0FUQV9TSUwyND1tCkNPTkZJR19BVEFfU0ZGPXkKCiMKIyBTRkYgY29u dHJvbGxlcnMgd2l0aCBjdXN0b20gRE1BIGludGVyZmFjZQojCkNPTkZJR19QRENfQURNQT1tCkNP TkZJR19TQVRBX1FTVE9SPW0KQ09ORklHX1NBVEFfU1g0PW0KQ09ORklHX0FUQV9CTURNQT15Cgoj CiMgU0FUQSBTRkYgY29udHJvbGxlcnMgd2l0aCBCTURNQQojCkNPTkZJR19BVEFfUElJWD15CiMg Q09ORklHX1NBVEFfSElHSEJBTksgaXMgbm90IHNldApDT05GSUdfU0FUQV9NVj1tCkNPTkZJR19T QVRBX05WPW0KQ09ORklHX1NBVEFfUFJPTUlTRT1tCkNPTkZJR19TQVRBX1NJTD1tCkNPTkZJR19T QVRBX1NJUz1tCkNPTkZJR19TQVRBX1NWVz1tCkNPTkZJR19TQVRBX1VMST1tCkNPTkZJR19TQVRB X1ZJQT1tCkNPTkZJR19TQVRBX1ZJVEVTU0U9bQoKIwojIFBBVEEgU0ZGIGNvbnRyb2xsZXJzIHdp dGggQk1ETUEKIwpDT05GSUdfUEFUQV9BTEk9bQpDT05GSUdfUEFUQV9BTUQ9bQpDT05GSUdfUEFU QV9BUkFTQU5fQ0Y9bQpDT05GSUdfUEFUQV9BUlRPUD1tCkNPTkZJR19QQVRBX0FUSUlYUD1tCkNP TkZJR19QQVRBX0FUUDg2N1g9bQpDT05GSUdfUEFUQV9DTUQ2NFg9bQpDT05GSUdfUEFUQV9DUzU1 MjA9bQpDT05GSUdfUEFUQV9DUzU1MzA9bQpDT05GSUdfUEFUQV9DUzU1MzY9bQpDT05GSUdfUEFU QV9DWVBSRVNTPW0KQ09ORklHX1BBVEFfRUZBUj1tCkNPTkZJR19QQVRBX0hQVDM2Nj1tCkNPTkZJ R19QQVRBX0hQVDM3WD1tCkNPTkZJR19QQVRBX0hQVDNYMk49bQpDT05GSUdfUEFUQV9IUFQzWDM9 bQojIENPTkZJR19QQVRBX0hQVDNYM19ETUEgaXMgbm90IHNldApDT05GSUdfUEFUQV9JVDgyMTM9 bQpDT05GSUdfUEFUQV9JVDgyMVg9bQpDT05GSUdfUEFUQV9KTUlDUk9OPW0KQ09ORklHX1BBVEFf TUFSVkVMTD1tCkNPTkZJR19QQVRBX05FVENFTEw9bQpDT05GSUdfUEFUQV9OSU5KQTMyPW0KQ09O RklHX1BBVEFfTlM4NzQxNT1tCkNPTkZJR19QQVRBX09MRFBJSVg9bQpDT05GSUdfUEFUQV9PUFRJ RE1BPW0KQ09ORklHX1BBVEFfUERDMjAyN1g9bQpDT05GSUdfUEFUQV9QRENfT0xEPW0KIyBDT05G SUdfUEFUQV9SQURJU1lTIGlzIG5vdCBzZXQKQ09ORklHX1BBVEFfUkRDPW0KIyBDT05GSUdfUEFU QV9TQzEyMDAgaXMgbm90IHNldApDT05GSUdfUEFUQV9TQ0g9bQpDT05GSUdfUEFUQV9TRVJWRVJX T1JLUz1tCkNPTkZJR19QQVRBX1NJTDY4MD1tCkNPTkZJR19QQVRBX1NJUz1tCkNPTkZJR19QQVRB X1RPU0hJQkE9bQpDT05GSUdfUEFUQV9UUklGTEVYPW0KQ09ORklHX1BBVEFfVklBPW0KQ09ORklH X1BBVEFfV0lOQk9ORD1tCgojCiMgUElPLW9ubHkgU0ZGIGNvbnRyb2xsZXJzCiMKQ09ORklHX1BB VEFfQ01ENjQwX1BDST1tCkNPTkZJR19QQVRBX01QSUlYPW0KQ09ORklHX1BBVEFfTlM4NzQxMD1t CkNPTkZJR19QQVRBX09QVEk9bQpDT05GSUdfUEFUQV9QQ01DSUE9bQojIENPTkZJR19QQVRBX1Ja MTAwMCBpcyBub3Qgc2V0CgojCiMgR2VuZXJpYyBmYWxsYmFjayAvIGxlZ2FjeSBkcml2ZXJzCiMK Q09ORklHX1BBVEFfQUNQST1tCkNPTkZJR19BVEFfR0VORVJJQz1tCiMgQ09ORklHX1BBVEFfTEVH QUNZIGlzIG5vdCBzZXQKQ09ORklHX01EPXkKQ09ORklHX0JMS19ERVZfTUQ9eQpDT05GSUdfTURf QVVUT0RFVEVDVD15CkNPTkZJR19NRF9MSU5FQVI9bQpDT05GSUdfTURfUkFJRDA9bQpDT05GSUdf TURfUkFJRDE9bQpDT05GSUdfTURfUkFJRDEwPW0KQ09ORklHX01EX1JBSUQ0NTY9bQojIENPTkZJ R19NVUxUSUNPUkVfUkFJRDQ1NiBpcyBub3Qgc2V0CkNPTkZJR19NRF9NVUxUSVBBVEg9bQpDT05G SUdfTURfRkFVTFRZPW0KQ09ORklHX0JMS19ERVZfRE09eQpDT05GSUdfRE1fREVCVUc9eQpDT05G SUdfRE1fQlVGSU89bQpDT05GSUdfRE1fUEVSU0lTVEVOVF9EQVRBPW0KQ09ORklHX0RNX0NSWVBU PW0KQ09ORklHX0RNX1NOQVBTSE9UPXkKQ09ORklHX0RNX1RISU5fUFJPVklTSU9OSU5HPW0KIyBD T05GSUdfRE1fREVCVUdfQkxPQ0tfU1RBQ0tfVFJBQ0lORyBpcyBub3Qgc2V0CkNPTkZJR19ETV9N SVJST1I9eQpDT05GSUdfRE1fUkFJRD1tCkNPTkZJR19ETV9MT0dfVVNFUlNQQUNFPW0KQ09ORklH X0RNX1pFUk89eQpDT05GSUdfRE1fTVVMVElQQVRIPW0KQ09ORklHX0RNX01VTFRJUEFUSF9RTD1t CkNPTkZJR19ETV9NVUxUSVBBVEhfU1Q9bQojIENPTkZJR19ETV9ERUxBWSBpcyBub3Qgc2V0CkNP TkZJR19ETV9VRVZFTlQ9eQpDT05GSUdfRE1fRkxBS0VZPW0KQ09ORklHX0RNX1ZFUklUWT1tCkNP TkZJR19UQVJHRVRfQ09SRT1tCkNPTkZJR19UQ01fSUJMT0NLPW0KQ09ORklHX1RDTV9GSUxFSU89 bQpDT05GSUdfVENNX1BTQ1NJPW0KQ09ORklHX0xPT1BCQUNLX1RBUkdFVD1tCkNPTkZJR19UQ01f RkM9bQpDT05GSUdfSVNDU0lfVEFSR0VUPW0KQ09ORklHX1NCUF9UQVJHRVQ9bQpDT05GSUdfRlVT SU9OPXkKQ09ORklHX0ZVU0lPTl9TUEk9bQpDT05GSUdfRlVTSU9OX0ZDPW0KQ09ORklHX0ZVU0lP Tl9TQVM9bQpDT05GSUdfRlVTSU9OX01BWF9TR0U9NDAKQ09ORklHX0ZVU0lPTl9DVEw9bQpDT05G SUdfRlVTSU9OX0xBTj1tCkNPTkZJR19GVVNJT05fTE9HR0lORz15CgojCiMgSUVFRSAxMzk0IChG aXJlV2lyZSkgc3VwcG9ydAojCkNPTkZJR19GSVJFV0lSRT1tCkNPTkZJR19GSVJFV0lSRV9PSENJ PW0KQ09ORklHX0ZJUkVXSVJFX1NCUDI9bQpDT05GSUdfRklSRVdJUkVfTkVUPW0KQ09ORklHX0ZJ UkVXSVJFX05PU1k9bQojIENPTkZJR19JMk8gaXMgbm90IHNldApDT05GSUdfTUFDSU5UT1NIX0RS SVZFUlM9eQpDT05GSUdfTUFDX0VNVU1PVVNFQlROPXkKQ09ORklHX05FVERFVklDRVM9eQpDT05G SUdfTkVUX0NPUkU9eQpDT05GSUdfQk9ORElORz1tCkNPTkZJR19EVU1NWT1tCkNPTkZJR19FUVVB TElaRVI9bQpDT05GSUdfTkVUX0ZDPXkKQ09ORklHX01JST1tCkNPTkZJR19JRUVFODAyMTU0X0RS SVZFUlM9bQpDT05GSUdfSUVFRTgwMjE1NF9GQUtFSEFSRD1tCkNPTkZJR19JRUVFODAyMTU0X0ZB S0VMQj1tCkNPTkZJR19JRkI9bQpDT05GSUdfTkVUX1RFQU09bQpDT05GSUdfTkVUX1RFQU1fTU9E RV9CUk9BRENBU1Q9bQpDT05GSUdfTkVUX1RFQU1fTU9ERV9ST1VORFJPQklOPW0KQ09ORklHX05F VF9URUFNX01PREVfQUNUSVZFQkFDS1VQPW0KQ09ORklHX05FVF9URUFNX01PREVfTE9BREJBTEFO Q0U9bQpDT05GSUdfTUFDVkxBTj1tCkNPTkZJR19NQUNWVEFQPW0KQ09ORklHX05FVENPTlNPTEU9 bQpDT05GSUdfTkVUQ09OU09MRV9EWU5BTUlDPXkKQ09ORklHX05FVFBPTEw9eQpDT05GSUdfTkVU UE9MTF9UUkFQPXkKQ09ORklHX05FVF9QT0xMX0NPTlRST0xMRVI9eQpDT05GSUdfVFVOPW0KQ09O RklHX1ZFVEg9bQpDT05GSUdfVklSVElPX05FVD1tCkNPTkZJR19TVU5HRU1fUEhZPW0KIyBDT05G SUdfQVJDTkVUIGlzIG5vdCBzZXQKQ09ORklHX0FUTV9EUklWRVJTPXkKIyBDT05GSUdfQVRNX0RV TU1ZIGlzIG5vdCBzZXQKQ09ORklHX0FUTV9UQ1A9bQojIENPTkZJR19BVE1fTEFOQUkgaXMgbm90 IHNldApDT05GSUdfQVRNX0VOST1tCiMgQ09ORklHX0FUTV9FTklfREVCVUcgaXMgbm90IHNldAoj IENPTkZJR19BVE1fRU5JX1RVTkVfQlVSU1QgaXMgbm90IHNldApDT05GSUdfQVRNX0ZJUkVTVFJF QU09bQojIENPTkZJR19BVE1fWkFUTSBpcyBub3Qgc2V0CkNPTkZJR19BVE1fTklDU1RBUj1tCiMg Q09ORklHX0FUTV9OSUNTVEFSX1VTRV9TVU5JIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNX05JQ1NU QVJfVVNFX0lEVDc3MTA1IGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNX0lEVDc3MjUyIGlzIG5vdCBz ZXQKIyBDT05GSUdfQVRNX0FNQkFTU0FET1IgaXMgbm90IHNldAojIENPTkZJR19BVE1fSE9SSVpP TiBpcyBub3Qgc2V0CiMgQ09ORklHX0FUTV9JQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FUTV9GT1JF MjAwRSBpcyBub3Qgc2V0CkNPTkZJR19BVE1fSEU9bQojIENPTkZJR19BVE1fSEVfVVNFX1NVTkkg aXMgbm90IHNldApDT05GSUdfQVRNX1NPTE9TPW0KCiMKIyBDQUlGIHRyYW5zcG9ydCBkcml2ZXJz CiMKCiMKIyBEaXN0cmlidXRlZCBTd2l0Y2ggQXJjaGl0ZWN0dXJlIGRyaXZlcnMKIwpDT05GSUdf TkVUX0RTQV9NVjg4RTZYWFg9bQpDT05GSUdfTkVUX0RTQV9NVjg4RTYwNjA9bQpDT05GSUdfTkVU X0RTQV9NVjg4RTZYWFhfTkVFRF9QUFU9eQpDT05GSUdfTkVUX0RTQV9NVjg4RTYxMzE9bQpDT05G SUdfTkVUX0RTQV9NVjg4RTYxMjNfNjFfNjU9bQpDT05GSUdfRVRIRVJORVQ9eQpDT05GSUdfTURJ Tz1tCkNPTkZJR19ORVRfVkVORE9SXzNDT009eQpDT05GSUdfUENNQ0lBXzNDNTc0PW0KQ09ORklH X1BDTUNJQV8zQzU4OT1tCkNPTkZJR19WT1JURVg9bQpDT05GSUdfVFlQSE9PTj1tCkNPTkZJR19O RVRfVkVORE9SX0FEQVBURUM9eQpDT05GSUdfQURBUFRFQ19TVEFSRklSRT1tCkNPTkZJR19ORVRf VkVORE9SX0FMVEVPTj15CkNPTkZJR19BQ0VOSUM9bQojIENPTkZJR19BQ0VOSUNfT01JVF9USUdP Tl9JIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQU1EPXkKQ09ORklHX0FNRDgxMTFfRVRI PW0KQ09ORklHX1BDTkVUMzI9bQpDT05GSUdfUENNQ0lBX05NQ0xBTj1tCkNPTkZJR19ORVRfVkVO RE9SX0FUSEVST1M9eQpDT05GSUdfQVRMMj1tCkNPTkZJR19BVEwxPW0KQ09ORklHX0FUTDFFPW0K Q09ORklHX0FUTDFDPW0KQ09ORklHX05FVF9WRU5ET1JfQlJPQURDT009eQpDT05GSUdfQjQ0PW0K Q09ORklHX0I0NF9QQ0lfQVVUT1NFTEVDVD15CkNPTkZJR19CNDRfUENJQ09SRV9BVVRPU0VMRUNU PXkKQ09ORklHX0I0NF9QQ0k9eQpDT05GSUdfQk5YMj1tCkNPTkZJR19DTklDPW0KQ09ORklHX1RJ R09OMz1tCkNPTkZJR19CTlgyWD1tCkNPTkZJR19ORVRfVkVORE9SX0JST0NBREU9eQpDT05GSUdf Qk5BPW0KQ09ORklHX05FVF9DQUxYRURBX1hHTUFDPW0KQ09ORklHX05FVF9WRU5ET1JfQ0hFTFNJ Tz15CkNPTkZJR19DSEVMU0lPX1QxPW0KQ09ORklHX0NIRUxTSU9fVDFfMUc9eQpDT05GSUdfQ0hF TFNJT19UMz1tCkNPTkZJR19DSEVMU0lPX1Q0PW0KQ09ORklHX0NIRUxTSU9fVDRWRj1tCkNPTkZJ R19ORVRfVkVORE9SX0NJU0NPPXkKQ09ORklHX0VOSUM9bQpDT05GSUdfRE5FVD1tCkNPTkZJR19O RVRfVkVORE9SX0RFQz15CkNPTkZJR19ORVRfVFVMSVA9eQpDT05GSUdfREUyMTA0WD1tCkNPTkZJ R19ERTIxMDRYX0RTTD0wCkNPTkZJR19UVUxJUD1tCiMgQ09ORklHX1RVTElQX01XSSBpcyBub3Qg c2V0CkNPTkZJR19UVUxJUF9NTUlPPXkKIyBDT05GSUdfVFVMSVBfTkFQSSBpcyBub3Qgc2V0CkNP TkZJR19ERTRYNT1tCkNPTkZJR19XSU5CT05EXzg0MD1tCkNPTkZJR19ETTkxMDI9bQpDT05GSUdf VUxJNTI2WD1tCkNPTkZJR19QQ01DSUFfWElSQ09NPW0KQ09ORklHX05FVF9WRU5ET1JfRExJTks9 eQpDT05GSUdfREU2MDA9bQpDT05GSUdfREU2MjA9bQpDT05GSUdfREwySz1tCkNPTkZJR19TVU5E QU5DRT1tCiMgQ09ORklHX1NVTkRBTkNFX01NSU8gaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRP Ul9FTVVMRVg9eQpDT05GSUdfQkUyTkVUPW0KQ09ORklHX05FVF9WRU5ET1JfRVhBUj15CkNPTkZJ R19TMklPPW0KQ09ORklHX1ZYR0U9bQojIENPTkZJR19WWEdFX0RFQlVHX1RSQUNFX0FMTCBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9WRU5ET1JfRlVKSVRTVSBpcyBub3Qgc2V0CiMgQ09ORklHX05F VF9WRU5ET1JfSFAgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9JTlRFTD15CkNPTkZJR19F MTAwPW0KQ09ORklHX0UxMDAwPW0KQ09ORklHX0UxMDAwRT1tCkNPTkZJR19JR0I9bQpDT05GSUdf SUdCX0RDQT15CkNPTkZJR19JR0JfUFRQPXkKQ09ORklHX0lHQlZGPW0KQ09ORklHX0lYR0I9bQpD T05GSUdfSVhHQkU9bQpDT05GSUdfSVhHQkVfSFdNT049eQpDT05GSUdfSVhHQkVfRENBPXkKQ09O RklHX0lYR0JFX0RDQj15CkNPTkZJR19JWEdCRV9QVFA9eQpDT05GSUdfSVhHQkVWRj1tCiMgQ09O RklHX05FVF9WRU5ET1JfSTgyNVhYIGlzIG5vdCBzZXQKQ09ORklHX0lQMTAwMD1tCkNPTkZJR19K TUU9bQpDT05GSUdfTkVUX1ZFTkRPUl9NQVJWRUxMPXkKQ09ORklHX1NLR0U9bQojIENPTkZJR19T S0dFX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1NLR0VfR0VORVNJUz15CkNPTkZJR19TS1kyPW0K IyBDT05GSUdfU0tZMl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX01FTExBTk9Y PXkKQ09ORklHX01MWDRfRU49bQpDT05GSUdfTUxYNF9FTl9EQ0I9eQpDT05GSUdfTUxYNF9DT1JF PW0KQ09ORklHX01MWDRfREVCVUc9eQpDT05GSUdfTkVUX1ZFTkRPUl9NSUNSRUw9eQojIENPTkZJ R19LUzg4NDIgaXMgbm90IHNldAojIENPTkZJR19LUzg4NTFfTUxMIGlzIG5vdCBzZXQKQ09ORklH X0tTWjg4NFhfUENJPW0KQ09ORklHX05FVF9WRU5ET1JfTVlSST15CkNPTkZJR19NWVJJMTBHRT1t CkNPTkZJR19NWVJJMTBHRV9EQ0E9eQpDT05GSUdfRkVBTE5YPW0KQ09ORklHX05FVF9WRU5ET1Jf TkFUU0VNST15CkNPTkZJR19OQVRTRU1JPW0KQ09ORklHX05TODM4MjA9bQpDT05GSUdfTkVUX1ZF TkRPUl84MzkwPXkKQ09ORklHX1BDTUNJQV9BWE5FVD1tCkNPTkZJR19ORTJLX1BDST1tCkNPTkZJ R19QQ01DSUFfUENORVQ9bQpDT05GSUdfTkVUX1ZFTkRPUl9OVklESUE9eQpDT05GSUdfRk9SQ0VE RVRIPW0KQ09ORklHX05FVF9WRU5ET1JfT0tJPXkKQ09ORklHX1BDSF9HQkU9bQojIENPTkZJR19Q Q0hfUFRQIGlzIG5vdCBzZXQKQ09ORklHX0VUSE9DPW0KQ09ORklHX05FVF9QQUNLRVRfRU5HSU5F PXkKQ09ORklHX0hBTUFDSEk9bQpDT05GSUdfWUVMTE9XRklOPW0KQ09ORklHX05FVF9WRU5ET1Jf UUxPR0lDPXkKQ09ORklHX1FMQTNYWFg9bQpDT05GSUdfUUxDTklDPW0KQ09ORklHX1FMR0U9bQpD T05GSUdfTkVUWEVOX05JQz15CkNPTkZJR19ORVRfVkVORE9SX1JFQUxURUs9eQpDT05GSUdfQVRQ PW0KQ09ORklHXzgxMzlDUD1tCkNPTkZJR184MTM5VE9PPW0KIyBDT05GSUdfODEzOVRPT19QSU8g aXMgbm90IHNldAojIENPTkZJR184MTM5VE9PX1RVTkVfVFdJU1RFUiBpcyBub3Qgc2V0CkNPTkZJ R184MTM5VE9PXzgxMjk9eQojIENPTkZJR184MTM5X09MRF9SWF9SRVNFVCBpcyBub3Qgc2V0CkNP TkZJR19SODE2OT1tCkNPTkZJR19ORVRfVkVORE9SX1JEQz15CkNPTkZJR19SNjA0MD1tCiMgQ09O RklHX05FVF9WRU5ET1JfU0VFUSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1NJTEFOPXkK Q09ORklHX1NDOTIwMzE9bQpDT05GSUdfTkVUX1ZFTkRPUl9TSVM9eQpDT05GSUdfU0lTOTAwPW0K Q09ORklHX1NJUzE5MD1tCkNPTkZJR19TRkM9bQojIENPTkZJR19TRkNfTVREIGlzIG5vdCBzZXQK Q09ORklHX1NGQ19NQ0RJX01PTj15CkNPTkZJR19TRkNfU1JJT1Y9eQpDT05GSUdfTkVUX1ZFTkRP Ul9TTVNDPXkKQ09ORklHX1BDTUNJQV9TTUM5MUM5Mj1tCkNPTkZJR19FUElDMTAwPW0KQ09ORklH X1NNU0M5NDIwPW0KQ09ORklHX05FVF9WRU5ET1JfU1RNSUNSTz15CkNPTkZJR19TVE1NQUNfRVRI PW0KIyBDT05GSUdfU1RNTUFDX1BMQVRGT1JNIGlzIG5vdCBzZXQKIyBDT05GSUdfU1RNTUFDX1BD SSBpcyBub3Qgc2V0CiMgQ09ORklHX1NUTU1BQ19ERUJVR19GUyBpcyBub3Qgc2V0CiMgQ09ORklH X1NUTU1BQ19EQSBpcyBub3Qgc2V0CkNPTkZJR19TVE1NQUNfUklORz15CiMgQ09ORklHX1NUTU1B Q19DSEFJTkVEIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfU1VOPXkKQ09ORklHX0hBUFBZ TUVBTD1tCkNPTkZJR19TVU5HRU09bQpDT05GSUdfQ0FTU0lOST1tCkNPTkZJR19OSVU9bQpDT05G SUdfTkVUX1ZFTkRPUl9URUhVVEk9eQpDT05GSUdfVEVIVVRJPW0KQ09ORklHX05FVF9WRU5ET1Jf VEk9eQpDT05GSUdfVExBTj1tCkNPTkZJR19ORVRfVkVORE9SX1ZJQT15CkNPTkZJR19WSUFfUkhJ TkU9bQpDT05GSUdfVklBX1JISU5FX01NSU89eQpDT05GSUdfVklBX1ZFTE9DSVRZPW0KQ09ORklH X05FVF9WRU5ET1JfV0laTkVUPXkKQ09ORklHX1dJWk5FVF9XNTEwMD1tCkNPTkZJR19XSVpORVRf VzUzMDA9bQojIENPTkZJR19XSVpORVRfQlVTX0RJUkVDVCBpcyBub3Qgc2V0CiMgQ09ORklHX1dJ Wk5FVF9CVVNfSU5ESVJFQ1QgaXMgbm90IHNldApDT05GSUdfV0laTkVUX0JVU19BTlk9eQpDT05G SUdfTkVUX1ZFTkRPUl9YSVJDT009eQpDT05GSUdfUENNQ0lBX1hJUkMyUFM9bQojIENPTkZJR19G RERJIGlzIG5vdCBzZXQKIyBDT05GSUdfSElQUEkgaXMgbm90IHNldAojIENPTkZJR19ORVRfU0Ix MDAwIGlzIG5vdCBzZXQKQ09ORklHX1BIWUxJQj15CgojCiMgTUlJIFBIWSBkZXZpY2UgZHJpdmVy cwojCkNPTkZJR19BTURfUEhZPW0KQ09ORklHX01BUlZFTExfUEhZPW0KQ09ORklHX0RBVklDT01f UEhZPW0KQ09ORklHX1FTRU1JX1BIWT1tCkNPTkZJR19MWFRfUEhZPW0KQ09ORklHX0NJQ0FEQV9Q SFk9bQpDT05GSUdfVklURVNTRV9QSFk9bQpDT05GSUdfU01TQ19QSFk9bQpDT05GSUdfQlJPQURD T01fUEhZPW0KQ09ORklHX0JDTTg3WFhfUEhZPW0KQ09ORklHX0lDUExVU19QSFk9bQpDT05GSUdf UkVBTFRFS19QSFk9bQpDT05GSUdfTkFUSU9OQUxfUEhZPW0KQ09ORklHX1NURTEwWFA9bQpDT05G SUdfTFNJX0VUMTAxMUNfUEhZPW0KQ09ORklHX01JQ1JFTF9QSFk9bQpDT05GSUdfRklYRURfUEhZ PXkKQ09ORklHX01ESU9fQklUQkFORz1tCiMgQ09ORklHX1BMSVAgaXMgbm90IHNldApDT05GSUdf UFBQPW0KQ09ORklHX1BQUF9CU0RDT01QPW0KQ09ORklHX1BQUF9ERUZMQVRFPW0KQ09ORklHX1BQ UF9GSUxURVI9eQpDT05GSUdfUFBQX01QUEU9bQpDT05GSUdfUFBQX01VTFRJTElOSz15CkNPTkZJ R19QUFBPQVRNPW0KQ09ORklHX1BQUE9FPW0KQ09ORklHX1BQVFA9bQpDT05GSUdfUFBQT0wyVFA9 bQpDT05GSUdfUFBQX0FTWU5DPW0KQ09ORklHX1BQUF9TWU5DX1RUWT1tCkNPTkZJR19TTElQPW0K Q09ORklHX1NMSEM9bQpDT05GSUdfU0xJUF9DT01QUkVTU0VEPXkKQ09ORklHX1NMSVBfU01BUlQ9 eQojIENPTkZJR19TTElQX01PREVfU0xJUDYgaXMgbm90IHNldAoKIwojIFVTQiBOZXR3b3JrIEFk YXB0ZXJzCiMKQ09ORklHX1VTQl9DQVRDPW0KQ09ORklHX1VTQl9LQVdFVEg9bQpDT05GSUdfVVNC X1BFR0FTVVM9bQpDT05GSUdfVVNCX1JUTDgxNTA9bQpDT05GSUdfVVNCX1VTQk5FVD1tCkNPTkZJ R19VU0JfTkVUX0FYODgxN1g9bQpDT05GSUdfVVNCX05FVF9DRENFVEhFUj1tCkNPTkZJR19VU0Jf TkVUX0NEQ19FRU09bQpDT05GSUdfVVNCX05FVF9DRENfTkNNPW0KQ09ORklHX1VTQl9ORVRfRE05 NjAxPW0KQ09ORklHX1VTQl9ORVRfU01TQzc1WFg9bQpDT05GSUdfVVNCX05FVF9TTVNDOTVYWD1t CkNPTkZJR19VU0JfTkVUX0dMNjIwQT1tCkNPTkZJR19VU0JfTkVUX05FVDEwODA9bQpDT05GSUdf VVNCX05FVF9QTFVTQj1tCkNPTkZJR19VU0JfTkVUX01DUzc4MzA9bQpDT05GSUdfVVNCX05FVF9S TkRJU19IT1NUPW0KQ09ORklHX1VTQl9ORVRfQ0RDX1NVQlNFVD1tCkNPTkZJR19VU0JfQUxJX001 NjMyPXkKQ09ORklHX1VTQl9BTjI3MjA9eQpDT05GSUdfVVNCX0JFTEtJTj15CkNPTkZJR19VU0Jf QVJNTElOVVg9eQpDT05GSUdfVVNCX0VQU09OMjg4OD15CkNPTkZJR19VU0JfS0MyMTkwPXkKQ09O RklHX1VTQl9ORVRfWkFVUlVTPW0KQ09ORklHX1VTQl9ORVRfQ1g4MjMxMF9FVEg9bQpDT05GSUdf VVNCX05FVF9LQUxNSUE9bQpDT05GSUdfVVNCX05FVF9RTUlfV1dBTj1tCkNPTkZJR19VU0JfSFNP PW0KQ09ORklHX1VTQl9ORVRfSU5UNTFYMT1tCkNPTkZJR19VU0JfSVBIRVRIPW0KQ09ORklHX1VT Ql9TSUVSUkFfTkVUPW0KQ09ORklHX1VTQl9WTDYwMD1tCkNPTkZJR19XTEFOPXkKIyBDT05GSUdf UENNQ0lBX1JBWUNTIGlzIG5vdCBzZXQKIyBDT05GSUdfTElCRVJUQVNfVEhJTkZJUk0gaXMgbm90 IHNldAojIENPTkZJR19BSVJPIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNRUwgaXMgbm90IHNldApD T05GSUdfQVQ3NkM1MFhfVVNCPW0KIyBDT05GSUdfQUlST19DUyBpcyBub3Qgc2V0CiMgQ09ORklH X1BDTUNJQV9XTDM1MDEgaXMgbm90IHNldAojIENPTkZJR19QUklTTTU0IGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1pEMTIwMSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfTkVUX1JORElTX1dMQU49bQpD T05GSUdfUlRMODE4MD1tCkNPTkZJR19SVEw4MTg3PW0KQ09ORklHX1JUTDgxODdfTEVEUz15CiMg Q09ORklHX0FETTgyMTEgaXMgbm90IHNldApDT05GSUdfTUFDODAyMTFfSFdTSU09bQpDT05GSUdf TVdMOEs9bQpDT05GSUdfQVRIX0NPTU1PTj1tCiMgQ09ORklHX0FUSF9ERUJVRyBpcyBub3Qgc2V0 CkNPTkZJR19BVEg1Sz1tCkNPTkZJR19BVEg1S19ERUJVRz15CiMgQ09ORklHX0FUSDVLX1RSQUNF UiBpcyBub3Qgc2V0CkNPTkZJR19BVEg1S19QQ0k9eQpDT05GSUdfQVRIOUtfSFc9bQpDT05GSUdf QVRIOUtfQ09NTU9OPW0KQ09ORklHX0FUSDlLX0JUQ09FWF9TVVBQT1JUPXkKQ09ORklHX0FUSDlL PW0KQ09ORklHX0FUSDlLX1BDST15CkNPTkZJR19BVEg5S19BSEI9eQpDT05GSUdfQVRIOUtfREVC VUdGUz15CiMgQ09ORklHX0FUSDlLX01BQ19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19BVEg5S19S QVRFX0NPTlRST0w9eQpDT05GSUdfQVRIOUtfSFRDPW0KIyBDT05GSUdfQVRIOUtfSFRDX0RFQlVH RlMgaXMgbm90IHNldApDT05GSUdfQ0FSTDkxNzA9bQpDT05GSUdfQ0FSTDkxNzBfTEVEUz15CiMg Q09ORklHX0NBUkw5MTcwX0RFQlVHRlMgaXMgbm90IHNldApDT05GSUdfQ0FSTDkxNzBfV1BDPXkK IyBDT05GSUdfQ0FSTDkxNzBfSFdSTkcgaXMgbm90IHNldApDT05GSUdfQVRINktMPW0KQ09ORklH X0FUSDZLTF9TRElPPW0KQ09ORklHX0FUSDZLTF9VU0I9bQpDT05GSUdfQVRINktMX0RFQlVHPXkK Q09ORklHX0I0Mz1tCkNPTkZJR19CNDNfQkNNQT15CiMgQ09ORklHX0I0M19CQ01BX0VYVFJBIGlz IG5vdCBzZXQKQ09ORklHX0I0M19TU0I9eQpDT05GSUdfQjQzX1BDSV9BVVRPU0VMRUNUPXkKQ09O RklHX0I0M19QQ0lDT1JFX0FVVE9TRUxFQ1Q9eQpDT05GSUdfQjQzX1BDTUNJQT15CkNPTkZJR19C NDNfU0RJTz15CkNPTkZJR19CNDNfQkNNQV9QSU89eQpDT05GSUdfQjQzX1BJTz15CkNPTkZJR19C NDNfUEhZX049eQpDT05GSUdfQjQzX1BIWV9MUD15CkNPTkZJR19CNDNfUEhZX0hUPXkKQ09ORklH X0I0M19MRURTPXkKQ09ORklHX0I0M19IV1JORz15CiMgQ09ORklHX0I0M19ERUJVRyBpcyBub3Qg c2V0CkNPTkZJR19CNDNMRUdBQ1k9bQpDT05GSUdfQjQzTEVHQUNZX1BDSV9BVVRPU0VMRUNUPXkK Q09ORklHX0I0M0xFR0FDWV9QQ0lDT1JFX0FVVE9TRUxFQ1Q9eQpDT05GSUdfQjQzTEVHQUNZX0xF RFM9eQpDT05GSUdfQjQzTEVHQUNZX0hXUk5HPXkKIyBDT05GSUdfQjQzTEVHQUNZX0RFQlVHIGlz IG5vdCBzZXQKQ09ORklHX0I0M0xFR0FDWV9ETUE9eQpDT05GSUdfQjQzTEVHQUNZX1BJTz15CkNP TkZJR19CNDNMRUdBQ1lfRE1BX0FORF9QSU9fTU9ERT15CiMgQ09ORklHX0I0M0xFR0FDWV9ETUFf TU9ERSBpcyBub3Qgc2V0CiMgQ09ORklHX0I0M0xFR0FDWV9QSU9fTU9ERSBpcyBub3Qgc2V0CkNP TkZJR19CUkNNVVRJTD1tCkNPTkZJR19CUkNNU01BQz1tCkNPTkZJR19CUkNNRk1BQz1tCkNPTkZJ R19CUkNNRk1BQ19TRElPPXkKQ09ORklHX0JSQ01GTUFDX1NESU9fT09CPXkKQ09ORklHX0JSQ01G TUFDX1VTQj15CiMgQ09ORklHX0JSQ01EQkcgaXMgbm90IHNldAojIENPTkZJR19IT1NUQVAgaXMg bm90IHNldApDT05GSUdfSVBXMjEwMD1tCkNPTkZJR19JUFcyMTAwX01PTklUT1I9eQojIENPTkZJ R19JUFcyMTAwX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0lQVzIyMDA9bQpDT05GSUdfSVBXMjIw MF9NT05JVE9SPXkKQ09ORklHX0lQVzIyMDBfUkFESU9UQVA9eQpDT05GSUdfSVBXMjIwMF9QUk9N SVNDVU9VUz15CkNPTkZJR19JUFcyMjAwX1FPUz15CiMgQ09ORklHX0lQVzIyMDBfREVCVUcgaXMg bm90IHNldApDT05GSUdfTElCSVBXPW0KIyBDT05GSUdfTElCSVBXX0RFQlVHIGlzIG5vdCBzZXQK Q09ORklHX0lXTFdJRkk9bQpDT05GSUdfSVdMRFZNPW0KCiMKIyBEZWJ1Z2dpbmcgT3B0aW9ucwoj CkNPTkZJR19JV0xXSUZJX0RFQlVHPXkKQ09ORklHX0lXTFdJRklfREVCVUdGUz15CiMgQ09ORklH X0lXTFdJRklfREVCVUdfRVhQRVJJTUVOVEFMX1VDT0RFIGlzIG5vdCBzZXQKIyBDT05GSUdfSVdM V0lGSV9ERVZJQ0VfVFJBQ0lORyBpcyBub3Qgc2V0CiMgQ09ORklHX0lXTFdJRklfUDJQIGlzIG5v dCBzZXQKIyBDT05GSUdfSVdMV0lGSV9FWFBFUklNRU5UQUxfTUZQIGlzIG5vdCBzZXQKQ09ORklH X0lXTEVHQUNZPW0KQ09ORklHX0lXTDQ5NjU9bQpDT05GSUdfSVdMMzk0NT1tCgojCiMgaXdsMzk0 NSAvIGl3bDQ5NjUgRGVidWdnaW5nIE9wdGlvbnMKIwpDT05GSUdfSVdMRUdBQ1lfREVCVUc9eQpD T05GSUdfSVdMRUdBQ1lfREVCVUdGUz15CkNPTkZJR19MSUJFUlRBUz1tCkNPTkZJR19MSUJFUlRB U19VU0I9bQpDT05GSUdfTElCRVJUQVNfQ1M9bQpDT05GSUdfTElCRVJUQVNfU0RJTz1tCiMgQ09O RklHX0xJQkVSVEFTX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0xJQkVSVEFTX01FU0g9eQpDT05G SUdfSEVSTUVTPW0KIyBDT05GSUdfSEVSTUVTX1BSSVNNIGlzIG5vdCBzZXQKQ09ORklHX0hFUk1F U19DQUNIRV9GV19PTl9JTklUPXkKQ09ORklHX1BMWF9IRVJNRVM9bQojIENPTkZJR19UTURfSEVS TUVTIGlzIG5vdCBzZXQKQ09ORklHX05PUlRFTF9IRVJNRVM9bQpDT05GSUdfUENNQ0lBX0hFUk1F Uz1tCiMgQ09ORklHX1BDTUNJQV9TUEVDVFJVTSBpcyBub3Qgc2V0CkNPTkZJR19PUklOT0NPX1VT Qj1tCkNPTkZJR19QNTRfQ09NTU9OPW0KQ09ORklHX1A1NF9VU0I9bQpDT05GSUdfUDU0X1BDST1t CkNPTkZJR19QNTRfTEVEUz15CkNPTkZJR19SVDJYMDA9bQpDT05GSUdfUlQyNDAwUENJPW0KQ09O RklHX1JUMjUwMFBDST1tCkNPTkZJR19SVDYxUENJPW0KQ09ORklHX1JUMjgwMFBDST1tCkNPTkZJ R19SVDI4MDBQQ0lfUlQzM1hYPXkKQ09ORklHX1JUMjgwMFBDSV9SVDM1WFg9eQpDT05GSUdfUlQy ODAwUENJX1JUNTNYWD15CkNPTkZJR19SVDI4MDBQQ0lfUlQzMjkwPXkKQ09ORklHX1JUMjUwMFVT Qj1tCkNPTkZJR19SVDczVVNCPW0KQ09ORklHX1JUMjgwMFVTQj1tCkNPTkZJR19SVDI4MDBVU0Jf UlQzM1hYPXkKQ09ORklHX1JUMjgwMFVTQl9SVDM1WFg9eQpDT05GSUdfUlQyODAwVVNCX1JUNTNY WD15CkNPTkZJR19SVDI4MDBVU0JfVU5LTk9XTj15CkNPTkZJR19SVDI4MDBfTElCPW0KQ09ORklH X1JUMlgwMF9MSUJfUENJPW0KQ09ORklHX1JUMlgwMF9MSUJfVVNCPW0KQ09ORklHX1JUMlgwMF9M SUI9bQpDT05GSUdfUlQyWDAwX0xJQl9GSVJNV0FSRT15CkNPTkZJR19SVDJYMDBfTElCX0NSWVBU Tz15CkNPTkZJR19SVDJYMDBfTElCX0xFRFM9eQpDT05GSUdfUlQyWDAwX0xJQl9ERUJVR0ZTPXkK IyBDT05GSUdfUlQyWDAwX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1JUTDgxOTJDRT1tCkNPTkZJ R19SVEw4MTkyU0U9bQpDT05GSUdfUlRMODE5MkRFPW0KQ09ORklHX1JUTDgxOTJDVT1tCkNPTkZJ R19SVExXSUZJPW0KIyBDT05GSUdfUlRMV0lGSV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19SVEw4 MTkyQ19DT01NT049bQojIENPTkZJR19XTF9USSBpcyBub3Qgc2V0CkNPTkZJR19aRDEyMTFSVz1t CiMgQ09ORklHX1pEMTIxMVJXX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX01XSUZJRVg9bQpDT05G SUdfTVdJRklFWF9TRElPPW0KQ09ORklHX01XSUZJRVhfUENJRT1tCkNPTkZJR19NV0lGSUVYX1VT Qj1tCgojCiMgV2lNQVggV2lyZWxlc3MgQnJvYWRiYW5kIGRldmljZXMKIwpDT05GSUdfV0lNQVhf STI0MDBNPW0KQ09ORklHX1dJTUFYX0kyNDAwTV9VU0I9bQpDT05GSUdfV0lNQVhfSTI0MDBNX0RF QlVHX0xFVkVMPTgKIyBDT05GSUdfV0FOIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9ORVRERVZfRlJP TlRFTkQ9eQpDT05GSUdfWEVOX05FVERFVl9CQUNLRU5EPXkKQ09ORklHX1ZNWE5FVDM9bQpDT05G SUdfSFlQRVJWX05FVD1tCkNPTkZJR19JU0ROPXkKQ09ORklHX0lTRE5fSTRMPW0KQ09ORklHX0lT RE5fUFBQPXkKQ09ORklHX0lTRE5fUFBQX1ZKPXkKQ09ORklHX0lTRE5fTVBQPXkKQ09ORklHX0lQ UFBfRklMVEVSPXkKIyBDT05GSUdfSVNETl9QUFBfQlNEQ09NUCBpcyBub3Qgc2V0CkNPTkZJR19J U0ROX0FVRElPPXkKQ09ORklHX0lTRE5fVFRZX0ZBWD15CgojCiMgSVNETiBmZWF0dXJlIHN1Ym1v ZHVsZXMKIwpDT05GSUdfSVNETl9ESVZFUlNJT049bQoKIwojIElTRE40TGludXggaGFyZHdhcmUg ZHJpdmVycwojCgojCiMgUGFzc2l2ZSBjYXJkcwojCkNPTkZJR19JU0ROX0RSVl9ISVNBWD1tCgoj CiMgRC1jaGFubmVsIHByb3RvY29sIGZlYXR1cmVzCiMKQ09ORklHX0hJU0FYX0VVUk89eQpDT05G SUdfREVfQU9DPXkKQ09ORklHX0hJU0FYX05PX1NFTkRDT01QTEVURT15CkNPTkZJR19ISVNBWF9O T19MTEM9eQpDT05GSUdfSElTQVhfTk9fS0VZUEFEPXkKQ09ORklHX0hJU0FYXzFUUjY9eQpDT05G SUdfSElTQVhfTkkxPXkKQ09ORklHX0hJU0FYX01BWF9DQVJEUz04CgojCiMgSGlTYXggc3VwcG9y dGVkIGNhcmRzCiMKQ09ORklHX0hJU0FYXzE2XzM9eQpDT05GSUdfSElTQVhfVEVMRVNQQ0k9eQpD T05GSUdfSElTQVhfUzBCT1g9eQpDT05GSUdfSElTQVhfRlJJVFpQQ0k9eQpDT05GSUdfSElTQVhf QVZNX0ExX1BDTUNJQT15CkNPTkZJR19ISVNBWF9FTFNBPXkKQ09ORklHX0hJU0FYX0RJRUhMRElW QT15CkNPTkZJR19ISVNBWF9TRURMQkFVRVI9eQpDT05GSUdfSElTQVhfTkVUSkVUPXkKQ09ORklH X0hJU0FYX05FVEpFVF9VPXkKQ09ORklHX0hJU0FYX05JQ0NZPXkKQ09ORklHX0hJU0FYX0JLTV9B NFQ9eQpDT05GSUdfSElTQVhfU0NUX1FVQURSTz15CkNPTkZJR19ISVNBWF9HQVpFTD15CkNPTkZJ R19ISVNBWF9IRkNfUENJPXkKQ09ORklHX0hJU0FYX1c2NjkyPXkKQ09ORklHX0hJU0FYX0hGQ19T WD15CkNPTkZJR19ISVNBWF9FTlRFUk5PV19QQ0k9eQojIENPTkZJR19ISVNBWF9ERUJVRyBpcyBu b3Qgc2V0CgojCiMgSGlTYXggUENNQ0lBIGNhcmQgc2VydmljZSBtb2R1bGVzCiMKQ09ORklHX0hJ U0FYX1NFRExCQVVFUl9DUz1tCkNPTkZJR19ISVNBWF9FTFNBX0NTPW0KQ09ORklHX0hJU0FYX0FW TV9BMV9DUz1tCkNPTkZJR19ISVNBWF9URUxFU19DUz1tCgojCiMgSGlTYXggc3ViIGRyaXZlciBt b2R1bGVzCiMKQ09ORklHX0hJU0FYX1NUNTQ4MT1tCiMgQ09ORklHX0hJU0FYX0hGQ1VTQiBpcyBu b3Qgc2V0CkNPTkZJR19ISVNBWF9IRkM0UzhTPW0KQ09ORklHX0hJU0FYX0ZSSVRaX1BDSVBOUD1t CgojCiMgQWN0aXZlIGNhcmRzCiMKQ09ORklHX0lTRE5fQ0FQST1tCkNPTkZJR19JU0ROX0RSVl9B Vk1CMV9WRVJCT1NFX1JFQVNPTj15CiMgQ09ORklHX0NBUElfVFJBQ0UgaXMgbm90IHNldApDT05G SUdfSVNETl9DQVBJX01JRERMRVdBUkU9eQpDT05GSUdfSVNETl9DQVBJX0NBUEkyMD1tCkNPTkZJ R19JU0ROX0NBUElfQ0FQSURSVj1tCgojCiMgQ0FQSSBoYXJkd2FyZSBkcml2ZXJzCiMKQ09ORklH X0NBUElfQVZNPXkKQ09ORklHX0lTRE5fRFJWX0FWTUIxX0IxUENJPW0KQ09ORklHX0lTRE5fRFJW X0FWTUIxX0IxUENJVjQ9eQpDT05GSUdfSVNETl9EUlZfQVZNQjFfQjFQQ01DSUE9bQpDT05GSUdf SVNETl9EUlZfQVZNQjFfQVZNX0NTPW0KQ09ORklHX0lTRE5fRFJWX0FWTUIxX1QxUENJPW0KQ09O RklHX0lTRE5fRFJWX0FWTUIxX0M0PW0KQ09ORklHX0NBUElfRUlDT049eQpDT05GSUdfSVNETl9E SVZBUz1tCkNPTkZJR19JU0ROX0RJVkFTX0JSSVBDST15CkNPTkZJR19JU0ROX0RJVkFTX1BSSVBD ST15CkNPTkZJR19JU0ROX0RJVkFTX0RJVkFDQVBJPW0KQ09ORklHX0lTRE5fRElWQVNfVVNFUklE ST1tCkNPTkZJR19JU0ROX0RJVkFTX01BSU5UPW0KQ09ORklHX0lTRE5fRFJWX0dJR0FTRVQ9bQpD T05GSUdfR0lHQVNFVF9DQVBJPXkKIyBDT05GSUdfR0lHQVNFVF9JNEwgaXMgbm90IHNldAojIENP TkZJR19HSUdBU0VUX0RVTU1ZTEwgaXMgbm90IHNldApDT05GSUdfR0lHQVNFVF9CQVNFPW0KQ09O RklHX0dJR0FTRVRfTTEwNT1tCkNPTkZJR19HSUdBU0VUX00xMDE9bQojIENPTkZJR19HSUdBU0VU X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0hZU0ROPW0KQ09ORklHX0hZU0ROX0NBUEk9eQpDT05G SUdfTUlTRE49bQpDT05GSUdfTUlTRE5fRFNQPW0KQ09ORklHX01JU0ROX0wxT0lQPW0KCiMKIyBt SVNETiBoYXJkd2FyZSBkcml2ZXJzCiMKQ09ORklHX01JU0ROX0hGQ1BDST1tCkNPTkZJR19NSVNE Tl9IRkNNVUxUST1tCkNPTkZJR19NSVNETl9IRkNVU0I9bQpDT05GSUdfTUlTRE5fQVZNRlJJVFo9 bQpDT05GSUdfTUlTRE5fU1BFRURGQVg9bQpDT05GSUdfTUlTRE5fSU5GSU5FT049bQpDT05GSUdf TUlTRE5fVzY2OTI9bQpDT05GSUdfTUlTRE5fTkVUSkVUPW0KQ09ORklHX01JU0ROX0lQQUM9bQpD T05GSUdfTUlTRE5fSVNBUj1tCkNPTkZJR19JU0ROX0hETEM9bQoKIwojIElucHV0IGRldmljZSBz dXBwb3J0CiMKQ09ORklHX0lOUFVUPXkKQ09ORklHX0lOUFVUX0ZGX01FTUxFU1M9eQpDT05GSUdf SU5QVVRfUE9MTERFVj1tCkNPTkZJR19JTlBVVF9TUEFSU0VLTUFQPW0KIyBDT05GSUdfSU5QVVRf TUFUUklYS01BUCBpcyBub3Qgc2V0CgojCiMgVXNlcmxhbmQgaW50ZXJmYWNlcwojCkNPTkZJR19J TlBVVF9NT1VTRURFVj15CiMgQ09ORklHX0lOUFVUX01PVVNFREVWX1BTQVVYIGlzIG5vdCBzZXQK Q09ORklHX0lOUFVUX01PVVNFREVWX1NDUkVFTl9YPTEwMjQKQ09ORklHX0lOUFVUX01PVVNFREVW X1NDUkVFTl9ZPTc2OApDT05GSUdfSU5QVVRfSk9ZREVWPW0KQ09ORklHX0lOUFVUX0VWREVWPXkK IyBDT05GSUdfSU5QVVRfRVZCVUcgaXMgbm90IHNldAoKIwojIElucHV0IERldmljZSBEcml2ZXJz CiMKQ09ORklHX0lOUFVUX0tFWUJPQVJEPXkKIyBDT05GSUdfS0VZQk9BUkRfQURQNTU4OCBpcyBu b3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1ODkgaXMgbm90IHNldApDT05GSUdfS0VZQk9B UkRfQVRLQkQ9eQojIENPTkZJR19LRVlCT0FSRF9RVDEwNzAgaXMgbm90IHNldAojIENPTkZJR19L RVlCT0FSRF9RVDIxNjAgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9MS0tCRCBpcyBub3Qg c2V0CiMgQ09ORklHX0tFWUJPQVJEX1RDQTY0MTYgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FS RF9UQ0E4NDE4IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTE04MzIzIGlzIG5vdCBzZXQK IyBDT05GSUdfS0VZQk9BUkRfTE04MzMzIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTUFY NzM1OSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX01DUyBpcyBub3Qgc2V0CiMgQ09ORklH X0tFWUJPQVJEX01QUjEyMSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX05FV1RPTiBpcyBu b3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX09QRU5DT1JFUyBpcyBub3Qgc2V0CiMgQ09ORklHX0tF WUJPQVJEX1NUT1dBV0FZIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfU1VOS0JEIGlzIG5v dCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfT01BUDQgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FS RF9YVEtCRCBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9NT1VTRT15CkNPTkZJR19NT1VTRV9QUzI9 eQpDT05GSUdfTU9VU0VfUFMyX0FMUFM9eQpDT05GSUdfTU9VU0VfUFMyX0xPR0lQUzJQUD15CkNP TkZJR19NT1VTRV9QUzJfU1lOQVBUSUNTPXkKQ09ORklHX01PVVNFX1BTMl9MSUZFQk9PSz15CkNP TkZJR19NT1VTRV9QUzJfVFJBQ0tQT0lOVD15CkNPTkZJR19NT1VTRV9QUzJfRUxBTlRFQ0g9eQpD T05GSUdfTU9VU0VfUFMyX1NFTlRFTElDPXkKIyBDT05GSUdfTU9VU0VfUFMyX1RPVUNIS0lUIGlz IG5vdCBzZXQKQ09ORklHX01PVVNFX1NFUklBTD1tCkNPTkZJR19NT1VTRV9BUFBMRVRPVUNIPW0K Q09ORklHX01PVVNFX0JDTTU5NzQ9bQpDT05GSUdfTU9VU0VfVlNYWFhBQT1tCkNPTkZJR19NT1VT RV9TWU5BUFRJQ1NfSTJDPW0KQ09ORklHX01PVVNFX1NZTkFQVElDU19VU0I9bQpDT05GSUdfSU5Q VVRfSk9ZU1RJQ0s9eQpDT05GSUdfSk9ZU1RJQ0tfQU5BTE9HPW0KQ09ORklHX0pPWVNUSUNLX0Ez RD1tCkNPTkZJR19KT1lTVElDS19BREk9bQpDT05GSUdfSk9ZU1RJQ0tfQ09CUkE9bQpDT05GSUdf Sk9ZU1RJQ0tfR0YySz1tCkNPTkZJR19KT1lTVElDS19HUklQPW0KQ09ORklHX0pPWVNUSUNLX0dS SVBfTVA9bQpDT05GSUdfSk9ZU1RJQ0tfR1VJTExFTU9UPW0KQ09ORklHX0pPWVNUSUNLX0lOVEVS QUNUPW0KQ09ORklHX0pPWVNUSUNLX1NJREVXSU5ERVI9bQpDT05GSUdfSk9ZU1RJQ0tfVE1EQz1t CkNPTkZJR19KT1lTVElDS19JRk9SQ0U9bQpDT05GSUdfSk9ZU1RJQ0tfSUZPUkNFX1VTQj15CkNP TkZJR19KT1lTVElDS19JRk9SQ0VfMjMyPXkKQ09ORklHX0pPWVNUSUNLX1dBUlJJT1I9bQpDT05G SUdfSk9ZU1RJQ0tfTUFHRUxMQU49bQpDT05GSUdfSk9ZU1RJQ0tfU1BBQ0VPUkI9bQpDT05GSUdf Sk9ZU1RJQ0tfU1BBQ0VCQUxMPW0KQ09ORklHX0pPWVNUSUNLX1NUSU5HRVI9bQpDT05GSUdfSk9Z U1RJQ0tfVFdJREpPWT1tCkNPTkZJR19KT1lTVElDS19aSEVOSFVBPW0KQ09ORklHX0pPWVNUSUNL X0RCOT1tCkNPTkZJR19KT1lTVElDS19HQU1FQ09OPW0KQ09ORklHX0pPWVNUSUNLX1RVUkJPR1JB Rlg9bQojIENPTkZJR19KT1lTVElDS19BUzUwMTEgaXMgbm90IHNldApDT05GSUdfSk9ZU1RJQ0tf Sk9ZRFVNUD1tCkNPTkZJR19KT1lTVElDS19YUEFEPW0KQ09ORklHX0pPWVNUSUNLX1hQQURfRkY9 eQpDT05GSUdfSk9ZU1RJQ0tfWFBBRF9MRURTPXkKQ09ORklHX0pPWVNUSUNLX1dBTEtFUkEwNzAx PW0KQ09ORklHX0lOUFVUX1RBQkxFVD15CkNPTkZJR19UQUJMRVRfVVNCX0FDRUNBRD1tCkNPTkZJ R19UQUJMRVRfVVNCX0FJUFRFSz1tCkNPTkZJR19UQUJMRVRfVVNCX0dUQ089bQpDT05GSUdfVEFC TEVUX1VTQl9IQU5XQU5HPW0KQ09ORklHX1RBQkxFVF9VU0JfS0JUQUI9bQpDT05GSUdfVEFCTEVU X1VTQl9XQUNPTT1tCkNPTkZJR19JTlBVVF9UT1VDSFNDUkVFTj15CiMgQ09ORklHX1RPVUNIU0NS RUVOX0FENzg3OSBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9BVE1FTF9NWFQ9bQojIENP TkZJR19UT1VDSFNDUkVFTl9CVTIxMDEzIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5f Q1lUVFNQX0NPUkUgaXMgbm90IHNldApDT05GSUdfVE9VQ0hTQ1JFRU5fRFlOQVBSTz1tCiMgQ09O RklHX1RPVUNIU0NSRUVOX0hBTVBTSElSRSBpcyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9F RVRJPW0KQ09ORklHX1RPVUNIU0NSRUVOX0VHQUxBWD1tCkNPTkZJR19UT1VDSFNDUkVFTl9GVUpJ VFNVPW0KQ09ORklHX1RPVUNIU0NSRUVOX0lMSTIxMFg9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fR1VO WkU9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fRUxPPW0KQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4 MDAxPW0KQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX0kyQz1tCiMgQ09ORklHX1RPVUNIU0NSRUVO X01BWDExODAxIGlzIG5vdCBzZXQKQ09ORklHX1RPVUNIU0NSRUVOX01DUzUwMDA9bQpDT05GSUdf VE9VQ0hTQ1JFRU5fTU1TMTE0PW0KQ09ORklHX1RPVUNIU0NSRUVOX01UT1VDSD1tCkNPTkZJR19U T1VDSFNDUkVFTl9JTkVYSU89bQpDT05GSUdfVE9VQ0hTQ1JFRU5fTUs3MTI9bQpDT05GSUdfVE9V Q0hTQ1JFRU5fUEVOTU9VTlQ9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fRURUX0ZUNVgwNj1tCkNPTkZJ R19UT1VDSFNDUkVFTl9UT1VDSFJJR0hUPW0KQ09ORklHX1RPVUNIU0NSRUVOX1RPVUNIV0lOPW0K Q09ORklHX1RPVUNIU0NSRUVOX1BJWENJUj1tCiMgQ09ORklHX1RPVUNIU0NSRUVOX1dNOTdYWCBp cyBub3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfQ09NUE9TSVRFPW0KQ09ORklHX1RPVUNI U0NSRUVOX1VTQl9FR0FMQVg9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX1BBTkpJVD15CkNPTkZJ R19UT1VDSFNDUkVFTl9VU0JfM009eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0lUTT15CkNPTkZJ R19UT1VDSFNDUkVFTl9VU0JfRVRVUkJPPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9HVU5aRT15 CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfRE1DX1RTQzEwPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VT Ql9JUlRPVUNIPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9JREVBTFRFSz15CkNPTkZJR19UT1VD SFNDUkVFTl9VU0JfR0VORVJBTF9UT1VDSD15CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfR09UT1A9 eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0pBU1RFQz15CkNPTkZJR19UT1VDSFNDUkVFTl9VU0Jf RUxPPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9FMkk9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNC X1pZVFJPTklDPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9FVFRfVEM0NVVTQj15CkNPTkZJR19U T1VDSFNDUkVFTl9VU0JfTkVYSU89eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0VBU1lUT1VDSD15 CkNPTkZJR19UT1VDSFNDUkVFTl9UT1VDSElUMjEzPW0KQ09ORklHX1RPVUNIU0NSRUVOX1RTQ19T RVJJTz1tCkNPTkZJR19UT1VDSFNDUkVFTl9UU0MyMDA3PW0KQ09ORklHX1RPVUNIU0NSRUVOX1NU MTIzMj1tCiMgQ09ORklHX1RPVUNIU0NSRUVOX1RQUzY1MDdYIGlzIG5vdCBzZXQKQ09ORklHX0lO UFVUX01JU0M9eQojIENPTkZJR19JTlBVVF9BRDcxNFggaXMgbm90IHNldAojIENPTkZJR19JTlBV VF9CTUExNTAgaXMgbm90IHNldApDT05GSUdfSU5QVVRfUENTUEtSPW0KQ09ORklHX0lOUFVUX01N QTg0NTA9bQpDT05GSUdfSU5QVVRfTVBVMzA1MD1tCkNPTkZJR19JTlBVVF9BUEFORUw9bQpDT05G SUdfSU5QVVRfQVRMQVNfQlROUz1tCkNPTkZJR19JTlBVVF9BVElfUkVNT1RFMj1tCkNPTkZJR19J TlBVVF9LRVlTUEFOX1JFTU9URT1tCkNPTkZJR19JTlBVVF9LWFRKOT1tCiMgQ09ORklHX0lOUFVU X0tYVEo5X1BPTExFRF9NT0RFIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1BPV0VSTUFURT1tCkNP TkZJR19JTlBVVF9ZRUFMSU5LPW0KQ09ORklHX0lOUFVUX0NNMTA5PW0KQ09ORklHX0lOUFVUX1VJ TlBVVD1tCiMgQ09ORklHX0lOUFVUX1BDRjg1NzQgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9B RFhMMzRYIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX0NNQTMwMDA9bQpDT05GSUdfSU5QVVRfQ01B MzAwMF9JMkM9bQpDT05GSUdfSU5QVVRfWEVOX0tCRERFVl9GUk9OVEVORD15CgojCiMgSGFyZHdh cmUgSS9PIHBvcnRzCiMKQ09ORklHX1NFUklPPXkKQ09ORklHX1NFUklPX0k4MDQyPXkKQ09ORklH X1NFUklPX1NFUlBPUlQ9eQojIENPTkZJR19TRVJJT19DVDgyQzcxMCBpcyBub3Qgc2V0CiMgQ09O RklHX1NFUklPX1BBUktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BDSVBTMiBpcyBub3Qg c2V0CkNPTkZJR19TRVJJT19MSUJQUzI9eQpDT05GSUdfU0VSSU9fUkFXPW0KQ09ORklHX1NFUklP X0FMVEVSQV9QUzI9bQojIENPTkZJR19TRVJJT19QUzJNVUxUIGlzIG5vdCBzZXQKQ09ORklHX0dB TUVQT1JUPW0KQ09ORklHX0dBTUVQT1JUX05TNTU4PW0KQ09ORklHX0dBTUVQT1JUX0w0PW0KQ09O RklHX0dBTUVQT1JUX0VNVTEwSzE9bQpDT05GSUdfR0FNRVBPUlRfRk04MDE9bQoKIwojIENoYXJh Y3RlciBkZXZpY2VzCiMKQ09ORklHX0NSQVNIPW0KQ09ORklHX1ZUPXkKQ09ORklHX0NPTlNPTEVf VFJBTlNMQVRJT05TPXkKQ09ORklHX1ZUX0NPTlNPTEU9eQpDT05GSUdfVlRfQ09OU09MRV9TTEVF UD15CkNPTkZJR19IV19DT05TT0xFPXkKQ09ORklHX1ZUX0hXX0NPTlNPTEVfQklORElORz15CkNP TkZJR19VTklYOThfUFRZUz15CkNPTkZJR19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTPXkKIyBD T05GSUdfTEVHQUNZX1BUWVMgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJEPXkK Q09ORklHX1JPQ0tFVFBPUlQ9bQpDT05GSUdfQ1lDTEFERVM9bQojIENPTkZJR19DWVpfSU5UUiBp cyBub3Qgc2V0CiMgQ09ORklHX01PWEFfSU5URUxMSU8gaXMgbm90IHNldAojIENPTkZJR19NT1hB X1NNQVJUSU8gaXMgbm90IHNldApDT05GSUdfU1lOQ0xJTks9bQpDT05GSUdfU1lOQ0xJTktNUD1t CkNPTkZJR19TWU5DTElOS19HVD1tCkNPTkZJR19OT1pPTUk9bQojIENPTkZJR19JU0kgaXMgbm90 IHNldApDT05GSUdfTl9IRExDPW0KQ09ORklHX05fR1NNPW0KIyBDT05GSUdfVFJBQ0VfU0lOSyBp cyBub3Qgc2V0CiMgQ09ORklHX0RFVktNRU0gaXMgbm90IHNldAojIENPTkZJR19TVEFMRFJWIGlz IG5vdCBzZXQKCiMKIyBTZXJpYWwgZHJpdmVycwojCkNPTkZJR19TRVJJQUxfODI1MD15CkNPTkZJ R19TRVJJQUxfODI1MF9DT05TT0xFPXkKQ09ORklHX0ZJWF9FQVJMWUNPTl9NRU09eQpDT05GSUdf U0VSSUFMXzgyNTBfUENJPXkKQ09ORklHX1NFUklBTF84MjUwX1BOUD15CkNPTkZJR19TRVJJQUxf ODI1MF9DUz1tCkNPTkZJR19TRVJJQUxfODI1MF9OUl9VQVJUUz0zMgpDT05GSUdfU0VSSUFMXzgy NTBfUlVOVElNRV9VQVJUUz00CkNPTkZJR19TRVJJQUxfODI1MF9FWFRFTkRFRD15CkNPTkZJR19T RVJJQUxfODI1MF9NQU5ZX1BPUlRTPXkKQ09ORklHX1NFUklBTF84MjUwX1NIQVJFX0lSUT15CiMg Q09ORklHX1NFUklBTF84MjUwX0RFVEVDVF9JUlEgaXMgbm90IHNldApDT05GSUdfU0VSSUFMXzgy NTBfUlNBPXkKCiMKIyBOb24tODI1MCBzZXJpYWwgcG9ydCBzdXBwb3J0CiMKIyBDT05GSUdfU0VS SUFMX01GRF9IU1UgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX0NPUkU9eQpDT05GSUdfU0VSSUFM X0NPUkVfQ09OU09MRT15CkNPTkZJR19DT05TT0xFX1BPTEw9eQpDT05GSUdfU0VSSUFMX0pTTT1t CiMgQ09ORklHX1NFUklBTF9USU1CRVJEQUxFIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0FM VEVSQV9KVEFHVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFfVUFSVCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NFUklBTF9QQ0hfVUFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklB TF9YSUxJTlhfUFNfVUFSVCBpcyBub3Qgc2V0CkNPTkZJR19QUklOVEVSPW0KQ09ORklHX0xQX0NP TlNPTEU9eQpDT05GSUdfUFBERVY9bQpDT05GSUdfSFZDX0RSSVZFUj15CkNPTkZJR19IVkNfSVJR PXkKQ09ORklHX0hWQ19YRU49eQpDT05GSUdfSFZDX1hFTl9GUk9OVEVORD15CkNPTkZJR19WSVJU SU9fQ09OU09MRT15CkNPTkZJR19JUE1JX0hBTkRMRVI9bQojIENPTkZJR19JUE1JX1BBTklDX0VW RU5UIGlzIG5vdCBzZXQKQ09ORklHX0lQTUlfREVWSUNFX0lOVEVSRkFDRT1tCkNPTkZJR19JUE1J X1NJPW0KQ09ORklHX0lQTUlfV0FUQ0hET0c9bQpDT05GSUdfSVBNSV9QT1dFUk9GRj1tCkNPTkZJ R19IV19SQU5ET009eQpDT05GSUdfSFdfUkFORE9NX1RJTUVSSU9NRU09bQpDT05GSUdfSFdfUkFO RE9NX0lOVEVMPW0KQ09ORklHX0hXX1JBTkRPTV9BTUQ9bQpDT05GSUdfSFdfUkFORE9NX1ZJQT1t CkNPTkZJR19IV19SQU5ET01fVklSVElPPW0KQ09ORklHX05WUkFNPXkKQ09ORklHX1IzOTY0PW0K IyBDT05GSUdfQVBQTElDT00gaXMgbm90IHNldAoKIwojIFBDTUNJQSBjaGFyYWN0ZXIgZGV2aWNl cwojCiMgQ09ORklHX1NZTkNMSU5LX0NTIGlzIG5vdCBzZXQKQ09ORklHX0NBUkRNQU5fNDAwMD1t CkNPTkZJR19DQVJETUFOXzQwNDA9bQpDT05GSUdfSVBXSVJFTEVTUz1tCkNPTkZJR19NV0FWRT1t CkNPTkZJR19SQVdfRFJJVkVSPXkKQ09ORklHX01BWF9SQVdfREVWUz04MTkyCkNPTkZJR19IUEVU PXkKIyBDT05GSUdfSFBFVF9NTUFQIGlzIG5vdCBzZXQKQ09ORklHX0hBTkdDSEVDS19USU1FUj1t CkNPTkZJR19UQ0dfVFBNPW0KQ09ORklHX1RDR19USVM9bQpDT05GSUdfVENHX05TQz1tCkNPTkZJ R19UQ0dfQVRNRUw9bQpDT05GSUdfVENHX0lORklORU9OPW0KQ09ORklHX1RFTENMT0NLPW0KQ09O RklHX0RFVlBPUlQ9eQpDT05GSUdfSTJDPW0KQ09ORklHX0kyQ19CT0FSRElORk89eQpDT05GSUdf STJDX0NPTVBBVD15CkNPTkZJR19JMkNfQ0hBUkRFVj1tCiMgQ09ORklHX0kyQ19NVVggaXMgbm90 IHNldApDT05GSUdfSTJDX0hFTFBFUl9BVVRPPXkKQ09ORklHX0kyQ19TTUJVUz1tCkNPTkZJR19J MkNfQUxHT0JJVD1tCkNPTkZJR19JMkNfQUxHT1BDQT1tCgojCiMgSTJDIEhhcmR3YXJlIEJ1cyBz dXBwb3J0CiMKCiMKIyBQQyBTTUJ1cyBob3N0IGNvbnRyb2xsZXIgZHJpdmVycwojCiMgQ09ORklH X0kyQ19BTEkxNTM1IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FMSTE1NjMgaXMgbm90IHNldAoj IENPTkZJR19JMkNfQUxJMTVYMyBpcyBub3Qgc2V0CkNPTkZJR19JMkNfQU1ENzU2PW0KQ09ORklH X0kyQ19BTUQ3NTZfUzQ4ODI9bQpDT05GSUdfSTJDX0FNRDgxMTE9bQpDT05GSUdfSTJDX0k4MDE9 bQpDT05GSUdfSTJDX0lTQ0g9bQpDT05GSUdfSTJDX1BJSVg0PW0KQ09ORklHX0kyQ19ORk9SQ0Uy PW0KQ09ORklHX0kyQ19ORk9SQ0UyX1M0OTg1PW0KIyBDT05GSUdfSTJDX1NJUzU1OTUgaXMgbm90 IHNldAojIENPTkZJR19JMkNfU0lTNjMwIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19TSVM5Nlg9bQpD T05GSUdfSTJDX1ZJQT1tCkNPTkZJR19JMkNfVklBUFJPPW0KCiMKIyBBQ1BJIGRyaXZlcnMKIwpD T05GSUdfSTJDX1NDTUk9bQoKIwojIEkyQyBzeXN0ZW0gYnVzIGRyaXZlcnMgKG1vc3RseSBlbWJl ZGRlZCAvIHN5c3RlbS1vbi1jaGlwKQojCiMgQ09ORklHX0kyQ19ERVNJR05XQVJFX1BDSSBpcyBu b3Qgc2V0CiMgQ09ORklHX0kyQ19FRzIwVCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19JTlRFTF9N SUQgaXMgbm90IHNldAojIENPTkZJR19JMkNfT0NPUkVTIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19Q Q0FfUExBVEZPUk09bQojIENPTkZJR19JMkNfUFhBX1BDSSBpcyBub3Qgc2V0CkNPTkZJR19JMkNf U0lNVEVDPW0KIyBDT05GSUdfSTJDX1hJTElOWCBpcyBub3Qgc2V0CgojCiMgRXh0ZXJuYWwgSTJD L1NNQnVzIGFkYXB0ZXIgZHJpdmVycwojCkNPTkZJR19JMkNfRElPTEFOX1UyQz1tCkNPTkZJR19J MkNfUEFSUE9SVD1tCkNPTkZJR19JMkNfUEFSUE9SVF9MSUdIVD1tCiMgQ09ORklHX0kyQ19UQU9T X0VWTSBpcyBub3Qgc2V0CkNPTkZJR19JMkNfVElOWV9VU0I9bQoKIwojIE90aGVyIEkyQy9TTUJ1 cyBidXMgZHJpdmVycwojCkNPTkZJR19JMkNfU1RVQj1tCiMgQ09ORklHX0kyQ19ERUJVR19DT1JF IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0RFQlVHX0FMR08gaXMgbm90IHNldAojIENPTkZJR19J MkNfREVCVUdfQlVTIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJIGlzIG5vdCBzZXQKIyBDT05GSUdf SFNJIGlzIG5vdCBzZXQKCiMKIyBQUFMgc3VwcG9ydAojCkNPTkZJR19QUFM9bQojIENPTkZJR19Q UFNfREVCVUcgaXMgbm90IHNldAoKIwojIFBQUyBjbGllbnRzIHN1cHBvcnQKIwojIENPTkZJR19Q UFNfQ0xJRU5UX0tUSU1FUiBpcyBub3Qgc2V0CkNPTkZJR19QUFNfQ0xJRU5UX0xESVNDPW0KQ09O RklHX1BQU19DTElFTlRfUEFSUE9SVD1tCkNPTkZJR19QUFNfQ0xJRU5UX0dQSU89bQoKIwojIFBQ UyBnZW5lcmF0b3JzIHN1cHBvcnQKIwoKIwojIFBUUCBjbG9jayBzdXBwb3J0CiMKQ09ORklHX1BU UF8xNTg4X0NMT0NLPW0KQ09ORklHX0RQODM2NDBfUEhZPW0KQ09ORklHX1BUUF8xNTg4X0NMT0NL X1BDSD1tCkNPTkZJR19BUkNIX1dBTlRfT1BUSU9OQUxfR1BJT0xJQj15CiMgQ09ORklHX0dQSU9M SUIgaXMgbm90IHNldApDT05GSUdfVzE9bQpDT05GSUdfVzFfQ09OPXkKCiMKIyAxLXdpcmUgQnVz IE1hc3RlcnMKIwojIENPTkZJR19XMV9NQVNURVJfTUFUUk9YIGlzIG5vdCBzZXQKQ09ORklHX1cx X01BU1RFUl9EUzI0OTA9bQpDT05GSUdfVzFfTUFTVEVSX0RTMjQ4Mj1tCkNPTkZJR19XMV9NQVNU RVJfRFMxV009bQoKIwojIDEtd2lyZSBTbGF2ZXMKIwpDT05GSUdfVzFfU0xBVkVfVEhFUk09bQpD T05GSUdfVzFfU0xBVkVfU01FTT1tCkNPTkZJR19XMV9TTEFWRV9EUzI0MDg9bQpDT05GSUdfVzFf U0xBVkVfRFMyNDIzPW0KQ09ORklHX1cxX1NMQVZFX0RTMjQzMT1tCkNPTkZJR19XMV9TTEFWRV9E UzI0MzM9bQpDT05GSUdfVzFfU0xBVkVfRFMyNDMzX0NSQz15CkNPTkZJR19XMV9TTEFWRV9EUzI3 NjA9bQpDT05GSUdfVzFfU0xBVkVfRFMyNzgwPW0KQ09ORklHX1cxX1NMQVZFX0RTMjc4MT1tCkNP TkZJR19XMV9TTEFWRV9EUzI4RTA0PW0KQ09ORklHX1cxX1NMQVZFX0JRMjcwMDA9bQpDT05GSUdf UE9XRVJfU1VQUExZPXkKIyBDT05GSUdfUE9XRVJfU1VQUExZX0RFQlVHIGlzIG5vdCBzZXQKIyBD T05GSUdfUERBX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9QT1dFUiBpcyBub3Qgc2V0 CiMgQ09ORklHX0JBVFRFUllfRFMyNzYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3 ODAgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX0RTMjc4MSBpcyBub3Qgc2V0CiMgQ09ORklH X0JBVFRFUllfRFMyNzgyIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9TQlMgaXMgbm90IHNl dAojIENPTkZJR19CQVRURVJZX0JRMjd4MDAgaXMgbm90IHNldAojIENPTkZJR19CQVRURVJZX01B WDE3MDQwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9NQVgxNzA0MiBpcyBub3Qgc2V0CiMg Q09ORklHX0NIQVJHRVJfSVNQMTcwNCBpcyBub3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTUFYODkw MyBpcyBub3Qgc2V0CiMgQ09ORklHX0NIQVJHRVJfTFA4NzI3IGlzIG5vdCBzZXQKQ09ORklHX0NI QVJHRVJfU01CMzQ3PW0KIyBDT05GSUdfUE9XRVJfQVZTIGlzIG5vdCBzZXQKQ09ORklHX0hXTU9O PXkKQ09ORklHX0hXTU9OX1ZJRD1tCiMgQ09ORklHX0hXTU9OX0RFQlVHX0NISVAgaXMgbm90IHNl dAoKIwojIE5hdGl2ZSBkcml2ZXJzCiMKQ09ORklHX1NFTlNPUlNfQUJJVFVHVVJVPW0KQ09ORklH X1NFTlNPUlNfQUJJVFVHVVJVMz1tCkNPTkZJR19TRU5TT1JTX0FENzQxND1tCkNPTkZJR19TRU5T T1JTX0FENzQxOD1tCkNPTkZJR19TRU5TT1JTX0FETTEwMjE9bQpDT05GSUdfU0VOU09SU19BRE0x MDI1PW0KQ09ORklHX1NFTlNPUlNfQURNMTAyNj1tCkNPTkZJR19TRU5TT1JTX0FETTEwMjk9bQpD T05GSUdfU0VOU09SU19BRE0xMDMxPW0KQ09ORklHX1NFTlNPUlNfQURNOTI0MD1tCkNPTkZJR19T RU5TT1JTX0FEVDc0MTE9bQpDT05GSUdfU0VOU09SU19BRFQ3NDYyPW0KQ09ORklHX1NFTlNPUlNf QURUNzQ3MD1tCkNPTkZJR19TRU5TT1JTX0FEVDc0NzU9bQpDT05GSUdfU0VOU09SU19BU0M3NjIx PW0KQ09ORklHX1NFTlNPUlNfSzhURU1QPW0KQ09ORklHX1NFTlNPUlNfSzEwVEVNUD1tCkNPTkZJ R19TRU5TT1JTX0ZBTTE1SF9QT1dFUj1tCkNPTkZJR19TRU5TT1JTX0FTQjEwMD1tCkNPTkZJR19T RU5TT1JTX0FUWFAxPW0KQ09ORklHX1NFTlNPUlNfRFM2MjA9bQpDT05GSUdfU0VOU09SU19EUzE2 MjE9bQpDT05GSUdfU0VOU09SU19JNUtfQU1CPW0KQ09ORklHX1NFTlNPUlNfRjcxODA1Rj1tCkNP TkZJR19TRU5TT1JTX0Y3MTg4MkZHPW0KQ09ORklHX1NFTlNPUlNfRjc1Mzc1Uz1tCkNPTkZJR19T RU5TT1JTX0ZTQ0hNRD1tCkNPTkZJR19TRU5TT1JTX0c3NjBBPW0KQ09ORklHX1NFTlNPUlNfR0w1 MThTTT1tCkNPTkZJR19TRU5TT1JTX0dMNTIwU009bQojIENPTkZJR19TRU5TT1JTX0hJSDYxMzAg aXMgbm90IHNldApDT05GSUdfU0VOU09SU19DT1JFVEVNUD1tCkNPTkZJR19TRU5TT1JTX0lCTUFF TT1tCkNPTkZJR19TRU5TT1JTX0lCTVBFWD1tCkNPTkZJR19TRU5TT1JTX0lUODc9bQojIENPTkZJ R19TRU5TT1JTX0pDNDIgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19MSU5FQUdFPW0KQ09ORklH X1NFTlNPUlNfTE02Mz1tCkNPTkZJR19TRU5TT1JTX0xNNzM9bQpDT05GSUdfU0VOU09SU19MTTc1 PW0KQ09ORklHX1NFTlNPUlNfTE03Nz1tCkNPTkZJR19TRU5TT1JTX0xNNzg9bQpDT05GSUdfU0VO U09SU19MTTgwPW0KQ09ORklHX1NFTlNPUlNfTE04Mz1tCkNPTkZJR19TRU5TT1JTX0xNODU9bQpD T05GSUdfU0VOU09SU19MTTg3PW0KQ09ORklHX1NFTlNPUlNfTE05MD1tCkNPTkZJR19TRU5TT1JT X0xNOTI9bQpDT05GSUdfU0VOU09SU19MTTkzPW0KQ09ORklHX1NFTlNPUlNfTFRDNDE1MT1tCkNP TkZJR19TRU5TT1JTX0xUQzQyMTU9bQpDT05GSUdfU0VOU09SU19MVEM0MjQ1PW0KQ09ORklHX1NF TlNPUlNfTFRDNDI2MT1tCkNPTkZJR19TRU5TT1JTX0xNOTUyNDE9bQpDT05GSUdfU0VOU09SU19M TTk1MjQ1PW0KQ09ORklHX1NFTlNPUlNfTUFYMTYwNjU9bQpDT05GSUdfU0VOU09SU19NQVgxNjE5 PW0KQ09ORklHX1NFTlNPUlNfTUFYMTY2OD1tCkNPTkZJR19TRU5TT1JTX01BWDY2Mzk9bQpDT05G SUdfU0VOU09SU19NQVg2NjQyPW0KQ09ORklHX1NFTlNPUlNfTUFYNjY1MD1tCkNPTkZJR19TRU5T T1JTX01DUDMwMjE9bQpDT05GSUdfU0VOU09SU19OVENfVEhFUk1JU1RPUj1tCkNPTkZJR19TRU5T T1JTX1BDODczNjA9bQpDT05GSUdfU0VOU09SU19QQzg3NDI3PW0KQ09ORklHX1NFTlNPUlNfUENG ODU5MT1tCkNPTkZJR19QTUJVUz1tCkNPTkZJR19TRU5TT1JTX1BNQlVTPW0KQ09ORklHX1NFTlNP UlNfQURNMTI3NT1tCkNPTkZJR19TRU5TT1JTX0xNMjUwNjY9bQpDT05GSUdfU0VOU09SU19MVEMy OTc4PW0KQ09ORklHX1NFTlNPUlNfTUFYMTYwNjQ9bQpDT05GSUdfU0VOU09SU19NQVgzNDQ0MD1t CkNPTkZJR19TRU5TT1JTX01BWDg2ODg9bQpDT05GSUdfU0VOU09SU19VQ0Q5MDAwPW0KQ09ORklH X1NFTlNPUlNfVUNEOTIwMD1tCkNPTkZJR19TRU5TT1JTX1pMNjEwMD1tCkNPTkZJR19TRU5TT1JT X1NIVDIxPW0KQ09ORklHX1NFTlNPUlNfU0lTNTU5NT1tCiMgQ09ORklHX1NFTlNPUlNfU01NNjY1 IGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfRE1FMTczNz1tCkNPTkZJR19TRU5TT1JTX0VNQzE0 MDM9bQojIENPTkZJR19TRU5TT1JTX0VNQzIxMDMgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19F TUM2VzIwMT1tCkNPTkZJR19TRU5TT1JTX1NNU0M0N00xPW0KQ09ORklHX1NFTlNPUlNfU01TQzQ3 TTE5Mj1tCkNPTkZJR19TRU5TT1JTX1NNU0M0N0IzOTc9bQpDT05GSUdfU0VOU09SU19TQ0g1NlhY X0NPTU1PTj1tCkNPTkZJR19TRU5TT1JTX1NDSDU2Mjc9bQpDT05GSUdfU0VOU09SU19TQ0g1NjM2 PW0KQ09ORklHX1NFTlNPUlNfQURTMTAxNT1tCkNPTkZJR19TRU5TT1JTX0FEUzc4Mjg9bQpDT05G SUdfU0VOU09SU19BTUM2ODIxPW0KQ09ORklHX1NFTlNPUlNfSU5BMlhYPW0KQ09ORklHX1NFTlNP UlNfVEhNQzUwPW0KQ09ORklHX1NFTlNPUlNfVE1QMTAyPW0KQ09ORklHX1NFTlNPUlNfVE1QNDAx PW0KQ09ORklHX1NFTlNPUlNfVE1QNDIxPW0KQ09ORklHX1NFTlNPUlNfVklBX0NQVVRFTVA9bQpD T05GSUdfU0VOU09SU19WSUE2ODZBPW0KQ09ORklHX1NFTlNPUlNfVlQxMjExPW0KQ09ORklHX1NF TlNPUlNfVlQ4MjMxPW0KQ09ORklHX1NFTlNPUlNfVzgzNzgxRD1tCkNPTkZJR19TRU5TT1JTX1c4 Mzc5MUQ9bQpDT05GSUdfU0VOU09SU19XODM3OTJEPW0KQ09ORklHX1NFTlNPUlNfVzgzNzkzPW0K Q09ORklHX1NFTlNPUlNfVzgzNzk1PW0KIyBDT05GSUdfU0VOU09SU19XODM3OTVfRkFOQ1RSTCBp cyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX1c4M0w3ODVUUz1tCkNPTkZJR19TRU5TT1JTX1c4M0w3 ODZORz1tCkNPTkZJR19TRU5TT1JTX1c4MzYyN0hGPW0KQ09ORklHX1NFTlNPUlNfVzgzNjI3RUhG PW0KQ09ORklHX1NFTlNPUlNfQVBQTEVTTUM9bQoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJR19T RU5TT1JTX0FDUElfUE9XRVI9bQpDT05GSUdfU0VOU09SU19BVEswMTEwPW0KQ09ORklHX1RIRVJN QUw9eQpDT05GSUdfVEhFUk1BTF9IV01PTj15CkNPTkZJR19XQVRDSERPRz15CkNPTkZJR19XQVRD SERPR19DT1JFPXkKIyBDT05GSUdfV0FUQ0hET0dfTk9XQVlPVVQgaXMgbm90IHNldAoKIwojIFdh dGNoZG9nIERldmljZSBEcml2ZXJzCiMKQ09ORklHX1NPRlRfV0FUQ0hET0c9bQojIENPTkZJR19B Q1FVSVJFX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FEVkFOVEVDSF9XRFQgaXMgbm90IHNldApD T05GSUdfQUxJTTE1MzVfV0RUPW0KQ09ORklHX0FMSU03MTAxX1dEVD1tCkNPTkZJR19GNzE4MDhF X1dEVD1tCkNPTkZJR19TUDUxMDBfVENPPW0KIyBDT05GSUdfU0M1MjBfV0RUIGlzIG5vdCBzZXQK Q09ORklHX1NCQ19GSVRQQzJfV0FUQ0hET0c9bQojIENPTkZJR19FVVJPVEVDSF9XRFQgaXMgbm90 IHNldApDT05GSUdfSUI3MDBfV0RUPW0KQ09ORklHX0lCTUFTUj1tCiMgQ09ORklHX1dBRkVSX1dE VCBpcyBub3Qgc2V0CkNPTkZJR19JNjMwMEVTQl9XRFQ9bQpDT05GSUdfSUU2WFhfV0RUPW0KQ09O RklHX0lUQ09fV0RUPW0KQ09ORklHX0lUQ09fVkVORE9SX1NVUFBPUlQ9eQpDT05GSUdfSVQ4NzEy Rl9XRFQ9bQpDT05GSUdfSVQ4N19XRFQ9bQpDT05GSUdfSFBfV0FUQ0hET0c9bQpDT05GSUdfSFBX RFRfTk1JX0RFQ09ESU5HPXkKIyBDT05GSUdfU0MxMjAwX1dEVCBpcyBub3Qgc2V0CiMgQ09ORklH X1BDODc0MTNfV0RUIGlzIG5vdCBzZXQKQ09ORklHX05WX1RDTz1tCiMgQ09ORklHXzYwWFhfV0RU IGlzIG5vdCBzZXQKIyBDT05GSUdfU0JDODM2MF9XRFQgaXMgbm90IHNldAojIENPTkZJR19DUFU1 X1dEVCBpcyBub3Qgc2V0CkNPTkZJR19TTVNDX1NDSDMxMVhfV0RUPW0KIyBDT05GSUdfU01TQzM3 Qjc4N19XRFQgaXMgbm90IHNldApDT05GSUdfVklBX1dEVD1tCkNPTkZJR19XODM2MjdIRl9XRFQ9 bQpDT05GSUdfVzgzNjk3SEZfV0RUPW0KQ09ORklHX1c4MzY5N1VHX1dEVD1tCkNPTkZJR19XODM4 NzdGX1dEVD1tCkNPTkZJR19XODM5NzdGX1dEVD1tCkNPTkZJR19NQUNIWl9XRFQ9bQojIENPTkZJ R19TQkNfRVBYX0MzX1dBVENIRE9HIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9XRFQ9eQoKIwojIFBD SS1iYXNlZCBXYXRjaGRvZyBDYXJkcwojCkNPTkZJR19QQ0lQQ1dBVENIRE9HPW0KQ09ORklHX1dE VFBDST1tCgojCiMgVVNCLWJhc2VkIFdhdGNoZG9nIENhcmRzCiMKQ09ORklHX1VTQlBDV0FUQ0hE T0c9bQpDT05GSUdfU1NCX1BPU1NJQkxFPXkKCiMKIyBTb25pY3MgU2lsaWNvbiBCYWNrcGxhbmUK IwpDT05GSUdfU1NCPW0KQ09ORklHX1NTQl9TUFJPTT15CkNPTkZJR19TU0JfQkxPQ0tJTz15CkNP TkZJR19TU0JfUENJSE9TVF9QT1NTSUJMRT15CkNPTkZJR19TU0JfUENJSE9TVD15CkNPTkZJR19T U0JfQjQzX1BDSV9CUklER0U9eQpDT05GSUdfU1NCX1BDTUNJQUhPU1RfUE9TU0lCTEU9eQpDT05G SUdfU1NCX1BDTUNJQUhPU1Q9eQpDT05GSUdfU1NCX1NESU9IT1NUX1BPU1NJQkxFPXkKQ09ORklH X1NTQl9TRElPSE9TVD15CiMgQ09ORklHX1NTQl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TU0Jf RFJJVkVSX1BDSUNPUkVfUE9TU0lCTEU9eQpDT05GSUdfU1NCX0RSSVZFUl9QQ0lDT1JFPXkKQ09O RklHX0JDTUFfUE9TU0lCTEU9eQoKIwojIEJyb2FkY29tIHNwZWNpZmljIEFNQkEKIwpDT05GSUdf QkNNQT1tCkNPTkZJR19CQ01BX0JMT0NLSU89eQpDT05GSUdfQkNNQV9IT1NUX1BDSV9QT1NTSUJM RT15CkNPTkZJR19CQ01BX0hPU1RfUENJPXkKQ09ORklHX0JDTUFfRFJJVkVSX0dNQUNfQ01OPXkK IyBDT05GSUdfQkNNQV9ERUJVRyBpcyBub3Qgc2V0CgojCiMgTXVsdGlmdW5jdGlvbiBkZXZpY2Ug ZHJpdmVycwojCkNPTkZJR19NRkRfQ09SRT1tCkNPTkZJR19NRkRfU001MDE9bQojIENPTkZJR19I VENfUEFTSUMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0xNMzUzMyBpcyBub3Qgc2V0CiMgQ09O RklHX1RQUzYxMDVYIGlzIG5vdCBzZXQKIyBDT05GSUdfVFBTNjUwN1ggaXMgbm90IHNldAojIENP TkZJR19NRkRfVFBTNjUyMTcgaXMgbm90IHNldAojIENPTkZJR19NRkRfVE1JTyBpcyBub3Qgc2V0 CiMgQ09ORklHX01GRF9BUklaT05BX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9QQ0Y1MDYz MyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQzEzWFhYX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklH X0FCWDUwMF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0NTNTUzNSBpcyBub3Qgc2V0CkNP TkZJR19MUENfU0NIPW0KQ09ORklHX0xQQ19JQ0g9bQojIENPTkZJR19NRkRfUkRDMzIxWCBpcyBu b3Qgc2V0CiMgQ09ORklHX01GRF9KQU5aX0NNT0RJTyBpcyBub3Qgc2V0CkNPTkZJR19NRkRfVlg4 NTU9bQpDT05GSUdfTUZEX1dMMTI3M19DT1JFPW0KIyBDT05GSUdfUkVHVUxBVE9SIGlzIG5vdCBz ZXQKQ09ORklHX01FRElBX1NVUFBPUlQ9bQoKIwojIE11bHRpbWVkaWEgY29yZSBzdXBwb3J0CiMK Q09ORklHX01FRElBX0NBTUVSQV9TVVBQT1JUPXkKQ09ORklHX01FRElBX0FOQUxPR19UVl9TVVBQ T1JUPXkKQ09ORklHX01FRElBX0RJR0lUQUxfVFZfU1VQUE9SVD15CkNPTkZJR19NRURJQV9SQURJ T19TVVBQT1JUPXkKQ09ORklHX01FRElBX1JDX1NVUFBPUlQ9eQpDT05GSUdfTUVESUFfQ09OVFJP TExFUj15CkNPTkZJR19WSURFT19ERVY9bQpDT05GSUdfVklERU9fVjRMMl9DT01NT049bQpDT05G SUdfVklERU9fVjRMMl9TVUJERVZfQVBJPXkKQ09ORklHX0RWQl9DT1JFPW0KQ09ORklHX0RWQl9O RVQ9eQoKIwojIE1lZGlhIGRyaXZlcnMKIwpDT05GSUdfVklERU9fU0FBNzE0Nj1tCkNPTkZJR19W SURFT19TQUE3MTQ2X1ZWPW0KQ09ORklHX1JDX0NPUkU9bQpDT05GSUdfUkNfTUFQPW0KQ09ORklH X1JDX0RFQ09ERVJTPXkKQ09ORklHX0xJUkM9bQpDT05GSUdfSVJfTElSQ19DT0RFQz1tCkNPTkZJ R19JUl9ORUNfREVDT0RFUj1tCkNPTkZJR19JUl9SQzVfREVDT0RFUj1tCkNPTkZJR19JUl9SQzZf REVDT0RFUj1tCkNPTkZJR19JUl9KVkNfREVDT0RFUj1tCkNPTkZJR19JUl9TT05ZX0RFQ09ERVI9 bQpDT05GSUdfSVJfUkM1X1NaX0RFQ09ERVI9bQpDT05GSUdfSVJfU0FOWU9fREVDT0RFUj1tCkNP TkZJR19JUl9NQ0VfS0JEX0RFQ09ERVI9bQpDT05GSUdfUkNfREVWSUNFUz15CkNPTkZJR19SQ19B VElfUkVNT1RFPW0KQ09ORklHX0lSX0VORT1tCkNPTkZJR19JUl9JTU9OPW0KQ09ORklHX0lSX01D RVVTQj1tCkNPTkZJR19JUl9JVEVfQ0lSPW0KQ09ORklHX0lSX0ZJTlRFSz1tCkNPTkZJR19JUl9O VVZPVE9OPW0KQ09ORklHX0lSX1JFRFJBVDM9bQpDT05GSUdfSVJfU1RSRUFNWkFQPW0KQ09ORklH X0lSX1dJTkJPTkRfQ0lSPW0KQ09ORklHX0lSX0lHVUFOQT1tCkNPTkZJR19SQ19MT09QQkFDSz1t CkNPTkZJR19JUl9HUElPX0NJUj1tCkNPTkZJR19NRURJQV9BVFRBQ0g9eQpDT05GSUdfTUVESUFf VFVORVI9bQojIENPTkZJR19NRURJQV9UVU5FUl9DVVNUT01JU0UgaXMgbm90IHNldApDT05GSUdf TUVESUFfVFVORVJfU0lNUExFPW0KQ09ORklHX01FRElBX1RVTkVSX1REQTgyOTA9bQpDT05GSUdf TUVESUFfVFVORVJfVERBODI3WD1tCkNPTkZJR19NRURJQV9UVU5FUl9UREExODI3MT1tCkNPTkZJ R19NRURJQV9UVU5FUl9UREE5ODg3PW0KQ09ORklHX01FRElBX1RVTkVSX1RFQTU3NjE9bQpDT05G SUdfTUVESUFfVFVORVJfVEVBNTc2Nz1tCkNPTkZJR19NRURJQV9UVU5FUl9NVDIwWFg9bQpDT05G SUdfTUVESUFfVFVORVJfTVQyMDYwPW0KQ09ORklHX01FRElBX1RVTkVSX01UMjA2Mz1tCkNPTkZJ R19NRURJQV9UVU5FUl9NVDIyNjY9bQpDT05GSUdfTUVESUFfVFVORVJfTVQyMTMxPW0KQ09ORklH X01FRElBX1RVTkVSX1FUMTAxMD1tCkNPTkZJR19NRURJQV9UVU5FUl9YQzIwMjg9bQpDT05GSUdf TUVESUFfVFVORVJfWEM1MDAwPW0KQ09ORklHX01FRElBX1RVTkVSX1hDNDAwMD1tCkNPTkZJR19N RURJQV9UVU5FUl9NWEw1MDA1Uz1tCkNPTkZJR19NRURJQV9UVU5FUl9NWEw1MDA3VD1tCkNPTkZJ R19NRURJQV9UVU5FUl9NQzQ0UzgwMz1tCkNPTkZJR19NRURJQV9UVU5FUl9NQVgyMTY1PW0KQ09O RklHX01FRElBX1RVTkVSX1REQTE4MjE4PW0KQ09ORklHX01FRElBX1RVTkVSX0ZDMDAxMT1tCkNP TkZJR19NRURJQV9UVU5FUl9GQzAwMTI9bQpDT05GSUdfTUVESUFfVFVORVJfRkMwMDEzPW0KQ09O RklHX01FRElBX1RVTkVSX1REQTE4MjEyPW0KQ09ORklHX01FRElBX1RVTkVSX1RVQTkwMDE9bQpD T05GSUdfVklERU9fVjRMMj1tCkNPTkZJR19WSURFT0JVRl9HRU49bQpDT05GSUdfVklERU9CVUZf RE1BX1NHPW0KQ09ORklHX1ZJREVPQlVGX1ZNQUxMT0M9bQpDT05GSUdfVklERU9CVUZfRFZCPW0K Q09ORklHX1ZJREVPX0JUQ1g9bQpDT05GSUdfVklERU9fVFZFRVBST009bQpDT05GSUdfVklERU9f VFVORVI9bQpDT05GSUdfVklERU9CVUYyX0NPUkU9bQpDT05GSUdfVklERU9CVUYyX01FTU9QUz1t CkNPTkZJR19WSURFT0JVRjJfVk1BTExPQz1tCkNPTkZJR19WSURFT19DQVBUVVJFX0RSSVZFUlM9 eQojIENPTkZJR19WSURFT19BRFZfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19WSURFT19GSVhF RF9NSU5PUl9SQU5HRVMgaXMgbm90IHNldApDT05GSUdfVklERU9fSEVMUEVSX0NISVBTX0FVVE89 eQpDT05GSUdfVklERU9fSVJfSTJDPW0KCiMKIyBBdWRpbyBkZWNvZGVycywgcHJvY2Vzc29ycyBh bmQgbWl4ZXJzCiMKQ09ORklHX1ZJREVPX1RWQVVESU89bQpDT05GSUdfVklERU9fVERBNzQzMj1t CkNPTkZJR19WSURFT19UREE5ODQwPW0KQ09ORklHX1ZJREVPX1RFQTY0MTVDPW0KQ09ORklHX1ZJ REVPX1RFQTY0MjA9bQpDT05GSUdfVklERU9fTVNQMzQwMD1tCkNPTkZJR19WSURFT19DUzUzNDU9 bQpDT05GSUdfVklERU9fQ1M1M0wzMkE9bQpDT05GSUdfVklERU9fV004Nzc1PW0KQ09ORklHX1ZJ REVPX1dNODczOT1tCkNPTkZJR19WSURFT19WUDI3U01QWD1tCgojCiMgUkRTIGRlY29kZXJzCiMK Q09ORklHX1ZJREVPX1NBQTY1ODg9bQoKIwojIFZpZGVvIGRlY29kZXJzCiMKQ09ORklHX1ZJREVP X0JUODE5PW0KQ09ORklHX1ZJREVPX0JUODU2PW0KQ09ORklHX1ZJREVPX0JUODY2PW0KQ09ORklH X1ZJREVPX0tTMDEyNz1tCkNPTkZJR19WSURFT19TQUE3MTEwPW0KQ09ORklHX1ZJREVPX1NBQTcx MVg9bQpDT05GSUdfVklERU9fVFZQNTE1MD1tCkNPTkZJR19WSURFT19WUFgzMjIwPW0KCiMKIyBW aWRlbyBhbmQgYXVkaW8gZGVjb2RlcnMKIwpDT05GSUdfVklERU9fU0FBNzE3WD1tCkNPTkZJR19W SURFT19DWDI1ODQwPW0KCiMKIyBNUEVHIHZpZGVvIGVuY29kZXJzCiMKQ09ORklHX1ZJREVPX0NY MjM0MVg9bQoKIwojIFZpZGVvIGVuY29kZXJzCiMKQ09ORklHX1ZJREVPX1NBQTcxMjc9bQpDT05G SUdfVklERU9fU0FBNzE4NT1tCkNPTkZJR19WSURFT19BRFY3MTcwPW0KQ09ORklHX1ZJREVPX0FE VjcxNzU9bQoKIwojIENhbWVyYSBzZW5zb3IgZGV2aWNlcwojCkNPTkZJR19WSURFT19NVDlWMDEx PW0KCiMKIyBGbGFzaCBkZXZpY2VzCiMKCiMKIyBWaWRlbyBpbXByb3ZlbWVudCBjaGlwcwojCkNP TkZJR19WSURFT19VUEQ2NDAzMUE9bQpDT05GSUdfVklERU9fVVBENjQwODM9bQoKIwojIE1pc2Nl bGFuZW91cyBoZWxwZXIgY2hpcHMKIwpDT05GSUdfVklERU9fTTUyNzkwPW0KIyBDT05GSUdfVklE RU9fVklWSSBpcyBub3Qgc2V0CkNPTkZJR19WNExfVVNCX0RSSVZFUlM9eQoKIwojIFdlYmNhbSBk ZXZpY2VzCiMKQ09ORklHX1VTQl9WSURFT19DTEFTUz1tCkNPTkZJR19VU0JfVklERU9fQ0xBU1Nf SU5QVVRfRVZERVY9eQpDT05GSUdfVVNCX0dTUENBPW0KQ09ORklHX1VTQl9NNTYwMj1tCkNPTkZJ R19VU0JfU1RWMDZYWD1tCkNPTkZJR19VU0JfR0w4NjA9bQpDT05GSUdfVVNCX0dTUENBX0JFTlE9 bQpDT05GSUdfVVNCX0dTUENBX0NPTkVYPW0KQ09ORklHX1VTQl9HU1BDQV9DUElBMT1tCkNPTkZJ R19VU0JfR1NQQ0FfRVRPTVM9bQpDT05GSUdfVVNCX0dTUENBX0ZJTkVQSVg9bQpDT05GSUdfVVNC X0dTUENBX0pFSUxJTko9bQpDT05GSUdfVVNCX0dTUENBX0pMMjAwNUJDRD1tCkNPTkZJR19VU0Jf R1NQQ0FfS0lORUNUPW0KQ09ORklHX1VTQl9HU1BDQV9LT05JQ0E9bQpDT05GSUdfVVNCX0dTUENB X01BUlM9bQpDT05GSUdfVVNCX0dTUENBX01SOTczMTBBPW0KQ09ORklHX1VTQl9HU1BDQV9OVzgw WD1tCkNPTkZJR19VU0JfR1NQQ0FfT1Y1MTk9bQpDT05GSUdfVVNCX0dTUENBX09WNTM0PW0KQ09O RklHX1VTQl9HU1BDQV9PVjUzNF85PW0KQ09ORklHX1VTQl9HU1BDQV9QQUMyMDc9bQpDT05GSUdf VVNCX0dTUENBX1BBQzczMDI9bQpDT05GSUdfVVNCX0dTUENBX1BBQzczMTE9bQpDT05GSUdfVVNC X0dTUENBX1NFNDAxPW0KQ09ORklHX1VTQl9HU1BDQV9TTjlDMjAyOD1tCkNPTkZJR19VU0JfR1NQ Q0FfU045QzIwWD1tCkNPTkZJR19VU0JfR1NQQ0FfU09OSVhCPW0KQ09ORklHX1VTQl9HU1BDQV9T T05JWEo9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1MDA9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1 MDE9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1MDU9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1MDY9 bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1MDg9bQpDT05GSUdfVVNCX0dTUENBX1NQQ0E1NjE9bQpD T05GSUdfVVNCX0dTUENBX1NQQ0ExNTI4PW0KQ09ORklHX1VTQl9HU1BDQV9TUTkwNT1tCkNPTkZJ R19VU0JfR1NQQ0FfU1E5MDVDPW0KQ09ORklHX1VTQl9HU1BDQV9TUTkzMFg9bQpDT05GSUdfVVNC X0dTUENBX1NUSzAxND1tCkNPTkZJR19VU0JfR1NQQ0FfU1RWMDY4MD1tCkNPTkZJR19VU0JfR1NQ Q0FfU1VOUExVUz1tCkNPTkZJR19VU0JfR1NQQ0FfVDYxMz1tCkNPTkZJR19VU0JfR1NQQ0FfVE9Q Uk89bQpDT05GSUdfVVNCX0dTUENBX1RWODUzMj1tCkNPTkZJR19VU0JfR1NQQ0FfVkMwMzJYPW0K Q09ORklHX1VTQl9HU1BDQV9WSUNBTT1tCkNPTkZJR19VU0JfR1NQQ0FfWElSTElOS19DSVQ9bQpD T05GSUdfVVNCX0dTUENBX1pDM1hYPW0KQ09ORklHX1VTQl9QV0M9bQojIENPTkZJR19VU0JfUFdD X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9QV0NfSU5QVVRfRVZERVY9eQpDT05GSUdfVklE RU9fQ1BJQTI9bQpDT05GSUdfVVNCX1pSMzY0WFg9bQpDT05GSUdfVVNCX1NUS1dFQkNBTT1tCkNP TkZJR19VU0JfUzIyNTU9bQojIENPTkZJR19VU0JfU045QzEwMiBpcyBub3Qgc2V0CgojCiMgV2Vi Y2FtIGFuZC9vciBUViBVU0IgZGV2aWNlcwojCkNPTkZJR19WSURFT19FTTI4WFg9bQpDT05GSUdf VklERU9fRU0yOFhYX0FMU0E9bQpDT05GSUdfVklERU9fRU0yOFhYX0RWQj1tCkNPTkZJR19WSURF T19FTTI4WFhfUkM9bQoKIwojIFRWIFVTQiBkZXZpY2VzCiMKQ09ORklHX1ZJREVPX0FVMDgyOD1t CkNPTkZJR19WSURFT19QVlJVU0IyPW0KQ09ORklHX1ZJREVPX1BWUlVTQjJfU1lTRlM9eQpDT05G SUdfVklERU9fUFZSVVNCMl9EVkI9eQojIENPTkZJR19WSURFT19QVlJVU0IyX0RFQlVHSUZDIGlz IG5vdCBzZXQKQ09ORklHX1ZJREVPX0hEUFZSPW0KQ09ORklHX1ZJREVPX1RMRzIzMDA9bQpDT05G SUdfVklERU9fQ1gyMzFYWD1tCkNPTkZJR19WSURFT19DWDIzMVhYX1JDPXkKQ09ORklHX1ZJREVP X0NYMjMxWFhfQUxTQT1tCkNPTkZJR19WSURFT19DWDIzMVhYX0RWQj1tCkNPTkZJR19WSURFT19U TTYwMDA9bQpDT05GSUdfVklERU9fVE02MDAwX0FMU0E9bQpDT05GSUdfVklERU9fVE02MDAwX0RW Qj1tCkNPTkZJR19WSURFT19VU0JWSVNJT049bQpDT05GSUdfVjRMX1BDSV9EUklWRVJTPXkKQ09O RklHX1ZJREVPX0JUODQ4PW0KQ09ORklHX1ZJREVPX0JUODQ4X0RWQj15CkNPTkZJR19WSURFT19D WDE4PW0KQ09ORklHX1ZJREVPX0NYMThfQUxTQT1tCkNPTkZJR19WSURFT19DWDIzODg1PW0KQ09O RklHX01FRElBX0FMVEVSQV9DST1tCiMgQ09ORklHX1ZJREVPX0NYMjU4MjEgaXMgbm90IHNldApD T05GSUdfVklERU9fQ1g4OD1tCkNPTkZJR19WSURFT19DWDg4X0FMU0E9bQpDT05GSUdfVklERU9f Q1g4OF9CTEFDS0JJUkQ9bQpDT05GSUdfVklERU9fQ1g4OF9EVkI9bQpDT05GSUdfVklERU9fQ1g4 OF9WUDMwNTQ9bQpDT05GSUdfVklERU9fQ1g4OF9NUEVHPW0KQ09ORklHX1ZJREVPX0hFWElVTV9H RU1JTkk9bQpDT05GSUdfVklERU9fSEVYSVVNX09SSU9OPW0KQ09ORklHX1ZJREVPX0lWVFY9bQpD T05GSUdfVklERU9fRkJfSVZUVj1tCkNPTkZJR19WSURFT19NRVlFPW0KQ09ORklHX1ZJREVPX01Y Qj1tCkNPTkZJR19WSURFT19TQUE3MTM0PW0KQ09ORklHX1ZJREVPX1NBQTcxMzRfQUxTQT1tCkNP TkZJR19WSURFT19TQUE3MTM0X1JDPXkKQ09ORklHX1ZJREVPX1NBQTcxMzRfRFZCPW0KQ09ORklH X1ZJREVPX1NBQTcxNjQ9bQpDT05GSUdfVklERU9fWk9SQU49bQpDT05GSUdfVklERU9fWk9SQU5f REMzMD1tCkNPTkZJR19WSURFT19aT1JBTl9aUjM2MDYwPW0KQ09ORklHX1ZJREVPX1pPUkFOX0JV Wj1tCkNPTkZJR19WSURFT19aT1JBTl9EQzEwPW0KQ09ORklHX1ZJREVPX1pPUkFOX0xNTDMzPW0K Q09ORklHX1ZJREVPX1pPUkFOX0xNTDMzUjEwPW0KQ09ORklHX1ZJREVPX1pPUkFOX0FWUzZFWUVT PW0KIyBDT05GSUdfVjRMX0lTQV9QQVJQT1JUX0RSSVZFUlMgaXMgbm90IHNldAojIENPTkZJR19W NExfUExBVEZPUk1fRFJJVkVSUyBpcyBub3Qgc2V0CkNPTkZJR19WNExfTUVNMk1FTV9EUklWRVJT PXkKIyBDT05GSUdfVklERU9fTUVNMk1FTV9URVNUREVWIGlzIG5vdCBzZXQKQ09ORklHX1JBRElP X0FEQVBURVJTPXkKQ09ORklHX1JBRElPX1NJNDcwWD15CkNPTkZJR19VU0JfU0k0NzBYPW0KQ09O RklHX0kyQ19TSTQ3MFg9bQpDT05GSUdfVVNCX01SODAwPW0KQ09ORklHX1VTQl9EU0JSPW0KQ09O RklHX1JBRElPX01BWElSQURJTz1tCkNPTkZJR19SQURJT19TSEFSSz1tCkNPTkZJR19SQURJT19T SEFSSzI9bQpDT05GSUdfSTJDX1NJNDcxMz1tCkNPTkZJR19SQURJT19TSTQ3MTM9bQpDT05GSUdf VVNCX0tFRU5FPW0KQ09ORklHX1JBRElPX1RFQTU3NjQ9bQpDT05GSUdfUkFESU9fU0FBNzcwNkg9 bQojIENPTkZJR19SQURJT19URUY2ODYyIGlzIG5vdCBzZXQKQ09ORklHX1JBRElPX1dMMTI3Mz1t CgojCiMgVGV4YXMgSW5zdHJ1bWVudHMgV0wxMjh4IEZNIGRyaXZlciAoU1QgYmFzZWQpCiMKQ09O RklHX0RWQl9NQVhfQURBUFRFUlM9OApDT05GSUdfRFZCX0RZTkFNSUNfTUlOT1JTPXkKQ09ORklH X0RWQl9DQVBUVVJFX0RSSVZFUlM9eQoKIwojIFN1cHBvcnRlZCBTQUE3MTQ2IGJhc2VkIFBDSSBB ZGFwdGVycwojCkNPTkZJR19UVFBDSV9FRVBST009bQpDT05GSUdfRFZCX0FWNzExMD1tCkNPTkZJ R19EVkJfQVY3MTEwX09TRD15CkNPTkZJR19EVkJfQlVER0VUX0NPUkU9bQpDT05GSUdfRFZCX0JV REdFVD1tCkNPTkZJR19EVkJfQlVER0VUX0NJPW0KQ09ORklHX0RWQl9CVURHRVRfQVY9bQpDT05G SUdfRFZCX0JVREdFVF9QQVRDSD1tCgojCiMgU3VwcG9ydGVkIFVTQiBBZGFwdGVycwojCkNPTkZJ R19EVkJfVVNCPW0KIyBDT05GSUdfRFZCX1VTQl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19EVkJf VVNCX0E4MDA9bQpDT05GSUdfRFZCX1VTQl9ESUJVU0JfTUI9bQojIENPTkZJR19EVkJfVVNCX0RJ QlVTQl9NQl9GQVVMVFkgaXMgbm90IHNldApDT05GSUdfRFZCX1VTQl9ESUJVU0JfTUM9bQpDT05G SUdfRFZCX1VTQl9ESUIwNzAwPW0KQ09ORklHX0RWQl9VU0JfVU1UXzAxMD1tCkNPTkZJR19EVkJf VVNCX0NYVVNCPW0KQ09ORklHX0RWQl9VU0JfTTkyMFg9bQpDT05GSUdfRFZCX1VTQl9HTDg2MT1t CkNPTkZJR19EVkJfVVNCX0FVNjYxMD1tCkNPTkZJR19EVkJfVVNCX0RJR0lUVj1tCkNPTkZJR19E VkJfVVNCX1ZQNzA0NT1tCkNPTkZJR19EVkJfVVNCX1ZQNzAyWD1tCkNPTkZJR19EVkJfVVNCX0dQ OFBTSz1tCkNPTkZJR19EVkJfVVNCX05PVkFfVF9VU0IyPW0KQ09ORklHX0RWQl9VU0JfVFRVU0Iy PW0KQ09ORklHX0RWQl9VU0JfRFRUMjAwVT1tCkNPTkZJR19EVkJfVVNCX09QRVJBMT1tCkNPTkZJ R19EVkJfVVNCX0FGOTAwNT1tCkNPTkZJR19EVkJfVVNCX0FGOTAwNV9SRU1PVEU9bQpDT05GSUdf RFZCX1VTQl9QQ1RWNDUyRT1tCkNPTkZJR19EVkJfVVNCX0RXMjEwMj1tCkNPTkZJR19EVkJfVVNC X0NJTkVSR1lfVDI9bQpDT05GSUdfRFZCX1VTQl9BTllTRUU9bQpDT05GSUdfRFZCX1VTQl9EVFY1 MTAwPW0KQ09ORklHX0RWQl9VU0JfQUY5MDE1PW0KQ09ORklHX0RWQl9VU0JfQ0U2MjMwPW0KQ09O RklHX0RWQl9VU0JfRlJJSU89bQpDT05GSUdfRFZCX1VTQl9FQzE2OD1tCkNPTkZJR19EVkJfVVNC X0FaNjAwNz1tCkNPTkZJR19EVkJfVVNCX0FaNjAyNz1tCkNPTkZJR19EVkJfVVNCX0xNRTI1MTA9 bQpDT05GSUdfRFZCX1VTQl9URUNITklTQVRfVVNCMj1tCkNPTkZJR19EVkJfVVNCX0lUOTEzWD1t CkNPTkZJR19EVkJfVVNCX01YTDExMVNGPW0KQ09ORklHX0RWQl9VU0JfUlRMMjhYWFU9bQpDT05G SUdfRFZCX1VTQl9BRjkwMzU9bQpDT05GSUdfRFZCX1RUVVNCX0JVREdFVD1tCkNPTkZJR19EVkJf VFRVU0JfREVDPW0KQ09ORklHX1NNU19TSUFOT19NRFRWPW0KCiMKIyBTaWFubyBtb2R1bGUgY29t cG9uZW50cwojCkNPTkZJR19TTVNfVVNCX0RSVj1tCkNPTkZJR19TTVNfU0RJT19EUlY9bQoKIwoj IFN1cHBvcnRlZCBGbGV4Q29wSUkgKEIyQzIpIEFkYXB0ZXJzCiMKQ09ORklHX0RWQl9CMkMyX0ZM RVhDT1A9bQpDT05GSUdfRFZCX0IyQzJfRkxFWENPUF9QQ0k9bQpDT05GSUdfRFZCX0IyQzJfRkxF WENPUF9VU0I9bQojIENPTkZJR19EVkJfQjJDMl9GTEVYQ09QX0RFQlVHIGlzIG5vdCBzZXQKCiMK IyBTdXBwb3J0ZWQgQlQ4NzggQWRhcHRlcnMKIwpDT05GSUdfRFZCX0JUOFhYPW0KCiMKIyBTdXBw b3J0ZWQgUGx1dG8yIEFkYXB0ZXJzCiMKQ09ORklHX0RWQl9QTFVUTzI9bQoKIwojIFN1cHBvcnRl ZCBTRE1DIERNMTEwNSBBZGFwdGVycwojCkNPTkZJR19EVkJfRE0xMTA1PW0KCiMKIyBTdXBwb3J0 ZWQgRmlyZVdpcmUgKElFRUUgMTM5NCkgQWRhcHRlcnMKIwpDT05GSUdfRFZCX0ZJUkVEVFY9bQpD T05GSUdfRFZCX0ZJUkVEVFZfSU5QVVQ9eQoKIwojIFN1cHBvcnRlZCBFYXJ0aHNvZnQgUFQxIEFk YXB0ZXJzCiMKQ09ORklHX0RWQl9QVDE9bQoKIwojIFN1cHBvcnRlZCBNYW50aXMgQWRhcHRlcnMK IwpDT05GSUdfTUFOVElTX0NPUkU9bQpDT05GSUdfRFZCX01BTlRJUz1tCkNPTkZJR19EVkJfSE9Q UEVSPW0KCiMKIyBTdXBwb3J0ZWQgbkdlbmUgQWRhcHRlcnMKIwpDT05GSUdfRFZCX05HRU5FPW0K CiMKIyBTdXBwb3J0ZWQgZGRicmlkZ2UgKCdPY3RvcHVzJykgQWRhcHRlcnMKIwpDT05GSUdfRFZC X0REQlJJREdFPW0KCiMKIyBTdXBwb3J0ZWQgRFZCIEZyb250ZW5kcwojCgojCiMgTXVsdGlzdGFu ZGFyZCAoc2F0ZWxsaXRlKSBmcm9udGVuZHMKIwpDT05GSUdfRFZCX1NUQjA4OTk9bQpDT05GSUdf RFZCX1NUQjYxMDA9bQpDT05GSUdfRFZCX1NUVjA5MHg9bQpDT05GSUdfRFZCX1NUVjYxMTB4PW0K CiMKIyBNdWx0aXN0YW5kYXJkIChjYWJsZSArIHRlcnJlc3RyaWFsKSBmcm9udGVuZHMKIwpDT05G SUdfRFZCX0RSWEs9bQpDT05GSUdfRFZCX1REQTE4MjcxQzJERD1tCgojCiMgRFZCLVMgKHNhdGVs bGl0ZSkgZnJvbnRlbmRzCiMKQ09ORklHX0RWQl9DWDI0MTEwPW0KQ09ORklHX0RWQl9DWDI0MTIz PW0KQ09ORklHX0RWQl9NVDMxMj1tCkNPTkZJR19EVkJfWkwxMDAzNj1tCkNPTkZJR19EVkJfWkwx MDAzOT1tCkNPTkZJR19EVkJfUzVIMTQyMD1tCkNPTkZJR19EVkJfU1RWMDI4OD1tCkNPTkZJR19E VkJfU1RCNjAwMD1tCkNPTkZJR19EVkJfU1RWMDI5OT1tCkNPTkZJR19EVkJfU1RWNjExMD1tCkNP TkZJR19EVkJfU1RWMDkwMD1tCkNPTkZJR19EVkJfVERBODA4Mz1tCkNPTkZJR19EVkJfVERBMTAw ODY9bQpDT05GSUdfRFZCX1REQTgyNjE9bQpDT05GSUdfRFZCX1ZFUzFYOTM9bQpDT05GSUdfRFZC X1RVTkVSX0lURDEwMDA9bQpDT05GSUdfRFZCX1RVTkVSX0NYMjQxMTM9bQpDT05GSUdfRFZCX1RE QTgyNlg9bQpDT05GSUdfRFZCX1RVQTYxMDA9bQpDT05GSUdfRFZCX0NYMjQxMTY9bQpDT05GSUdf RFZCX1NJMjFYWD1tCkNPTkZJR19EVkJfRFMzMDAwPW0KQ09ORklHX0RWQl9NQjg2QTE2PW0KQ09O RklHX0RWQl9UREExMDA3MT1tCgojCiMgRFZCLVQgKHRlcnJlc3RyaWFsKSBmcm9udGVuZHMKIwpD T05GSUdfRFZCX1NQODg3MD1tCkNPTkZJR19EVkJfU1A4ODdYPW0KQ09ORklHX0RWQl9DWDIyNzAw PW0KQ09ORklHX0RWQl9DWDIyNzAyPW0KQ09ORklHX0RWQl9EUlhEPW0KQ09ORklHX0RWQl9MNjQ3 ODE9bQpDT05GSUdfRFZCX1REQTEwMDRYPW0KQ09ORklHX0RWQl9OWFQ2MDAwPW0KQ09ORklHX0RW Ql9NVDM1Mj1tCkNPTkZJR19EVkJfWkwxMDM1Mz1tCkNPTkZJR19EVkJfRElCMzAwME1CPW0KQ09O RklHX0RWQl9ESUIzMDAwTUM9bQpDT05GSUdfRFZCX0RJQjcwMDBNPW0KQ09ORklHX0RWQl9ESUI3 MDAwUD1tCkNPTkZJR19EVkJfVERBMTAwNDg9bQpDT05GSUdfRFZCX0FGOTAxMz1tCkNPTkZJR19E VkJfRUMxMDA9bQpDT05GSUdfRFZCX1NUVjAzNjc9bQpDT05GSUdfRFZCX0NYRDI4MjBSPW0KQ09O RklHX0RWQl9SVEwyODMwPW0KQ09ORklHX0RWQl9SVEwyODMyPW0KCiMKIyBEVkItQyAoY2FibGUp IGZyb250ZW5kcwojCkNPTkZJR19EVkJfVkVTMTgyMD1tCkNPTkZJR19EVkJfVERBMTAwMjE9bQpD T05GSUdfRFZCX1REQTEwMDIzPW0KQ09ORklHX0RWQl9TVFYwMjk3PW0KCiMKIyBBVFNDIChOb3J0 aCBBbWVyaWNhbi9Lb3JlYW4gVGVycmVzdHJpYWwvQ2FibGUgRFRWKSBmcm9udGVuZHMKIwpDT05G SUdfRFZCX05YVDIwMFg9bQpDT05GSUdfRFZCX09SNTEyMTE9bQpDT05GSUdfRFZCX09SNTExMzI9 bQpDT05GSUdfRFZCX0JDTTM1MTA9bQpDT05GSUdfRFZCX0xHRFQzMzBYPW0KQ09ORklHX0RWQl9M R0RUMzMwNT1tCkNPTkZJR19EVkJfTEcyMTYwPW0KQ09ORklHX0RWQl9TNUgxNDA5PW0KQ09ORklH X0RWQl9BVTg1MjI9bQpDT05GSUdfRFZCX0FVODUyMl9EVFY9bQpDT05GSUdfRFZCX0FVODUyMl9W NEw9bQpDT05GSUdfRFZCX1M1SDE0MTE9bQoKIwojIElTREItVCAodGVycmVzdHJpYWwpIGZyb250 ZW5kcwojCkNPTkZJR19EVkJfUzkyMT1tCkNPTkZJR19EVkJfRElCODAwMD1tCkNPTkZJR19EVkJf TUI4NkEyMFM9bQoKIwojIERpZ2l0YWwgdGVycmVzdHJpYWwgb25seSB0dW5lcnMvUExMCiMKQ09O RklHX0RWQl9QTEw9bQpDT05GSUdfRFZCX1RVTkVSX0RJQjAwNzA9bQpDT05GSUdfRFZCX1RVTkVS X0RJQjAwOTA9bQoKIwojIFNFQyBjb250cm9sIGRldmljZXMgZm9yIERWQi1TCiMKQ09ORklHX0RW Ql9MTkJQMjE9bQpDT05GSUdfRFZCX0xOQlAyMj1tCkNPTkZJR19EVkJfSVNMNjQwNT1tCkNPTkZJ R19EVkJfSVNMNjQyMT1tCkNPTkZJR19EVkJfSVNMNjQyMz1tCkNPTkZJR19EVkJfQTgyOTM9bQpD T05GSUdfRFZCX0xHUzhHWFg9bQpDT05GSUdfRFZCX0FUQk04ODMwPW0KQ09ORklHX0RWQl9UREE2 NjV4PW0KQ09ORklHX0RWQl9JWDI1MDVWPW0KQ09ORklHX0RWQl9JVDkxM1hfRkU9bQpDT05GSUdf RFZCX004OFJTMjAwMD1tCkNPTkZJR19EVkJfQUY5MDMzPW0KCiMKIyBUb29scyB0byBkZXZlbG9w IG5ldyBmcm9udGVuZHMKIwojIENPTkZJR19EVkJfRFVNTVlfRkUgaXMgbm90IHNldAoKIwojIEdy YXBoaWNzIHN1cHBvcnQKIwpDT05GSUdfQUdQPXkKQ09ORklHX0FHUF9BTUQ2ND15CkNPTkZJR19B R1BfSU5URUw9eQpDT05GSUdfQUdQX1NJUz15CkNPTkZJR19BR1BfVklBPXkKQ09ORklHX1ZHQV9B UkI9eQpDT05GSUdfVkdBX0FSQl9NQVhfR1BVUz0xNgpDT05GSUdfVkdBX1NXSVRDSEVST089eQpD T05GSUdfRFJNPW0KQ09ORklHX0RSTV9VU0I9bQpDT05GSUdfRFJNX0tNU19IRUxQRVI9bQpDT05G SUdfRFJNX0xPQURfRURJRF9GSVJNV0FSRT15CkNPTkZJR19EUk1fVFRNPW0KIyBDT05GSUdfRFJN X1RERlggaXMgbm90IHNldAojIENPTkZJR19EUk1fUjEyOCBpcyBub3Qgc2V0CkNPTkZJR19EUk1f UkFERU9OPW0KQ09ORklHX0RSTV9SQURFT05fS01TPXkKQ09ORklHX0RSTV9OT1VWRUFVPW0KQ09O RklHX0RSTV9OT1VWRUFVX0JBQ0tMSUdIVD15CkNPTkZJR19EUk1fTk9VVkVBVV9ERUJVRz15Cgoj CiMgSTJDIGVuY29kZXIgb3IgaGVscGVyIGNoaXBzCiMKQ09ORklHX0RSTV9JMkNfQ0g3MDA2PW0K Q09ORklHX0RSTV9JMkNfU0lMMTY0PW0KIyBDT05GSUdfRFJNX0k4MTAgaXMgbm90IHNldApDT05G SUdfRFJNX0k5MTU9bQpDT05GSUdfRFJNX0k5MTVfS01TPXkKIyBDT05GSUdfRFJNX01HQSBpcyBu b3Qgc2V0CiMgQ09ORklHX0RSTV9TSVMgaXMgbm90IHNldApDT05GSUdfRFJNX1ZJQT1tCiMgQ09O RklHX0RSTV9TQVZBR0UgaXMgbm90IHNldApDT05GSUdfRFJNX1ZNV0dGWD1tCiMgQ09ORklHX0RS TV9WTVdHRlhfRkJDT04gaXMgbm90IHNldApDT05GSUdfRFJNX0dNQTUwMD1tCiMgQ09ORklHX0RS TV9HTUE2MDAgaXMgbm90IHNldApDT05GSUdfRFJNX0dNQTM2MDA9eQpDT05GSUdfRFJNX1VETD1t CkNPTkZJR19EUk1fQVNUPW0KQ09ORklHX0RSTV9NR0FHMjAwPW0KQ09ORklHX0RSTV9DSVJSVVNf UUVNVT1tCiMgQ09ORklHX1NUVUJfUE9VTFNCTyBpcyBub3Qgc2V0CkNPTkZJR19WR0FTVEFURT1t CkNPTkZJR19WSURFT19PVVRQVVRfQ09OVFJPTD1tCkNPTkZJR19GQj15CiMgQ09ORklHX0ZJUk1X QVJFX0VESUQgaXMgbm90IHNldAojIENPTkZJR19GQl9EREMgaXMgbm90IHNldApDT05GSUdfRkJf Qk9PVF9WRVNBX1NVUFBPUlQ9eQpDT05GSUdfRkJfQ0ZCX0ZJTExSRUNUPXkKQ09ORklHX0ZCX0NG Ql9DT1BZQVJFQT15CkNPTkZJR19GQl9DRkJfSU1BR0VCTElUPXkKIyBDT05GSUdfRkJfQ0ZCX1JF Vl9QSVhFTFNfSU5fQllURSBpcyBub3Qgc2V0CkNPTkZJR19GQl9TWVNfRklMTFJFQ1Q9eQpDT05G SUdfRkJfU1lTX0NPUFlBUkVBPXkKQ09ORklHX0ZCX1NZU19JTUFHRUJMSVQ9eQojIENPTkZJR19G Ql9GT1JFSUdOX0VORElBTiBpcyBub3Qgc2V0CkNPTkZJR19GQl9TWVNfRk9QUz15CiMgQ09ORklH X0ZCX1dNVF9HRV9ST1BTIGlzIG5vdCBzZXQKQ09ORklHX0ZCX0RFRkVSUkVEX0lPPXkKIyBDT05G SUdfRkJfU1ZHQUxJQiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01BQ01PREVTIGlzIG5vdCBzZXQK Q09ORklHX0ZCX0JBQ0tMSUdIVD15CiMgQ09ORklHX0ZCX01PREVfSEVMUEVSUyBpcyBub3Qgc2V0 CkNPTkZJR19GQl9USUxFQkxJVFRJTkc9eQoKIwojIEZyYW1lIGJ1ZmZlciBoYXJkd2FyZSBkcml2 ZXJzCiMKIyBDT05GSUdfRkJfQ0lSUlVTIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUE0yIGlzIG5v dCBzZXQKIyBDT05GSUdfRkJfQ1lCRVIyMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVJDIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfQVNJTElBTlQgaXMgbm90IHNldAojIENPTkZJR19GQl9JTVNU VCBpcyBub3Qgc2V0CkNPTkZJR19GQl9WR0ExNj1tCiMgQ09ORklHX0ZCX1VWRVNBIGlzIG5vdCBz ZXQKQ09ORklHX0ZCX1ZFU0E9eQpDT05GSUdfRkJfRUZJPXkKIyBDT05GSUdfRkJfTjQxMSBpcyBu b3Qgc2V0CiMgQ09ORklHX0ZCX0hHQSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1MxRDEzWFhYIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfTlZJRElBIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUklWQSBp cyBub3Qgc2V0CiMgQ09ORklHX0ZCX0k3NDAgaXMgbm90IHNldAojIENPTkZJR19GQl9MRTgwNTc4 IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfTUFUUk9YIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUkFE RU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVRZMTI4IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf QVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUzMgaXMgbm90IHNldAojIENPTkZJR19GQl9TQVZB R0UgaXMgbm90IHNldAojIENPTkZJR19GQl9TSVMgaXMgbm90IHNldAojIENPTkZJR19GQl9WSUEg aXMgbm90IHNldAojIENPTkZJR19GQl9ORU9NQUdJQyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0tZ Uk8gaXMgbm90IHNldAojIENPTkZJR19GQl8zREZYIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1ZPT0RP TzE9bQojIENPTkZJR19GQl9WVDg2MjMgaXMgbm90IHNldAojIENPTkZJR19GQl9UUklERU5UIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUE0zIGlzIG5v dCBzZXQKIyBDT05GSUdfRkJfQ0FSTUlORSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0dFT0RFIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfVE1JTyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1NNNTAxIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfU01TQ1VGWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1VETCBp cyBub3Qgc2V0CkNPTkZJR19GQl9WSVJUVUFMPW0KQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD15 CiMgQ09ORklHX0ZCX01FVFJPTk9NRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01CODYyWFggaXMg bm90IHNldAojIENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVVP X0sxOTBYIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhZTk9TX1ZJREVPIGlzIG5vdCBzZXQKQ09ORklH X0JBQ0tMSUdIVF9MQ0RfU1VQUE9SVD15CkNPTkZJR19MQ0RfQ0xBU1NfREVWSUNFPW0KQ09ORklH X0xDRF9QTEFURk9STT1tCkNPTkZJR19CQUNLTElHSFRfQ0xBU1NfREVWSUNFPXkKIyBDT05GSUdf QkFDS0xJR0hUX0dFTkVSSUMgaXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX1BST0dFQVI9bQpD T05GSUdfQkFDS0xJR0hUX0FQUExFPW0KIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFSQSBpcyBub3Qg c2V0CiMgQ09ORklHX0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJ R0hUX0FEUDg4NzAgaXMgbm90IHNldApDT05GSUdfQkFDS0xJR0hUX0xQODU1WD1tCgojCiMgQ29u c29sZSBkaXNwbGF5IGRyaXZlciBzdXBwb3J0CiMKQ09ORklHX1ZHQV9DT05TT0xFPXkKQ09ORklH X1ZHQUNPTl9TT0ZUX1NDUk9MTEJBQ0s9eQpDT05GSUdfVkdBQ09OX1NPRlRfU0NST0xMQkFDS19T SVpFPTY0CkNPTkZJR19EVU1NWV9DT05TT0xFPXkKQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNPTEU9 eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRV9ERVRFQ1RfUFJJTUFSWT15CkNPTkZJR19GUkFN RUJVRkZFUl9DT05TT0xFX1JPVEFUSU9OPXkKIyBDT05GSUdfRk9OVFMgaXMgbm90IHNldApDT05G SUdfRk9OVF84eDg9eQpDT05GSUdfRk9OVF84eDE2PXkKQ09ORklHX0xPR089eQojIENPTkZJR19M T0dPX0xJTlVYX01PTk8gaXMgbm90IHNldAojIENPTkZJR19MT0dPX0xJTlVYX1ZHQTE2IGlzIG5v dCBzZXQKQ09ORklHX0xPR09fTElOVVhfQ0xVVDIyND15CkNPTkZJR19TT1VORD1tCkNPTkZJR19T T1VORF9PU1NfQ09SRT15CkNPTkZJR19TT1VORF9PU1NfQ09SRV9QUkVDTEFJTT15CkNPTkZJR19T TkQ9bQpDT05GSUdfU05EX1RJTUVSPW0KQ09ORklHX1NORF9QQ009bQpDT05GSUdfU05EX0hXREVQ PW0KQ09ORklHX1NORF9SQVdNSURJPW0KQ09ORklHX1NORF9KQUNLPXkKQ09ORklHX1NORF9TRVFV RU5DRVI9bQpDT05GSUdfU05EX1NFUV9EVU1NWT1tCkNPTkZJR19TTkRfT1NTRU1VTD15CkNPTkZJ R19TTkRfTUlYRVJfT1NTPW0KQ09ORklHX1NORF9QQ01fT1NTPW0KQ09ORklHX1NORF9QQ01fT1NT X1BMVUdJTlM9eQpDT05GSUdfU05EX1NFUVVFTkNFUl9PU1M9eQpDT05GSUdfU05EX0hSVElNRVI9 bQpDT05GSUdfU05EX1NFUV9IUlRJTUVSX0RFRkFVTFQ9eQpDT05GSUdfU05EX0RZTkFNSUNfTUlO T1JTPXkKIyBDT05GSUdfU05EX1NVUFBPUlRfT0xEX0FQSSBpcyBub3Qgc2V0CkNPTkZJR19TTkRf VkVSQk9TRV9QUk9DRlM9eQpDT05GSUdfU05EX1ZFUkJPU0VfUFJJTlRLPXkKQ09ORklHX1NORF9E RUJVRz15CiMgQ09ORklHX1NORF9ERUJVR19WRVJCT1NFIGlzIG5vdCBzZXQKQ09ORklHX1NORF9Q Q01fWFJVTl9ERUJVRz15CkNPTkZJR19TTkRfVk1BU1RFUj15CkNPTkZJR19TTkRfS0NUTF9KQUNL PXkKQ09ORklHX1NORF9ETUFfU0dCVUY9eQpDT05GSUdfU05EX1JBV01JRElfU0VRPW0KQ09ORklH X1NORF9PUEwzX0xJQl9TRVE9bQojIENPTkZJR19TTkRfT1BMNF9MSUJfU0VRIGlzIG5vdCBzZXQK IyBDT05GSUdfU05EX1NCQVdFX1NFUSBpcyBub3Qgc2V0CkNPTkZJR19TTkRfRU1VMTBLMV9TRVE9 bQpDT05GSUdfU05EX01QVTQwMV9VQVJUPW0KQ09ORklHX1NORF9PUEwzX0xJQj1tCkNPTkZJR19T TkRfVlhfTElCPW0KQ09ORklHX1NORF9BQzk3X0NPREVDPW0KQ09ORklHX1NORF9EUklWRVJTPXkK Q09ORklHX1NORF9QQ1NQPW0KQ09ORklHX1NORF9EVU1NWT1tCkNPTkZJR19TTkRfQUxPT1A9bQpD T05GSUdfU05EX1ZJUk1JREk9bQpDT05GSUdfU05EX01UUEFWPW0KQ09ORklHX1NORF9NVFM2ND1t CkNPTkZJR19TTkRfU0VSSUFMX1UxNjU1MD1tCkNPTkZJR19TTkRfTVBVNDAxPW0KQ09ORklHX1NO RF9QT1JUTUFOMlg0PW0KQ09ORklHX1NORF9BQzk3X1BPV0VSX1NBVkU9eQpDT05GSUdfU05EX0FD OTdfUE9XRVJfU0FWRV9ERUZBVUxUPTAKQ09ORklHX1NORF9TQl9DT01NT049bQpDT05GSUdfU05E X1NCMTZfRFNQPW0KQ09ORklHX1NORF9URUE1NzVYPW0KQ09ORklHX1NORF9QQ0k9eQpDT05GSUdf U05EX0FEMTg4OT1tCkNPTkZJR19TTkRfQUxTMzAwPW0KQ09ORklHX1NORF9BTFM0MDAwPW0KQ09O RklHX1NORF9BTEk1NDUxPW0KQ09ORklHX1NORF9BU0lIUEk9bQpDT05GSUdfU05EX0FUSUlYUD1t CkNPTkZJR19TTkRfQVRJSVhQX01PREVNPW0KQ09ORklHX1NORF9BVTg4MTA9bQpDT05GSUdfU05E X0FVODgyMD1tCkNPTkZJR19TTkRfQVU4ODMwPW0KIyBDT05GSUdfU05EX0FXMiBpcyBub3Qgc2V0 CkNPTkZJR19TTkRfQVpUMzMyOD1tCkNPTkZJR19TTkRfQlQ4N1g9bQojIENPTkZJR19TTkRfQlQ4 N1hfT1ZFUkNMT0NLIGlzIG5vdCBzZXQKQ09ORklHX1NORF9DQTAxMDY9bQpDT05GSUdfU05EX0NN SVBDST1tCkNPTkZJR19TTkRfT1hZR0VOX0xJQj1tCkNPTkZJR19TTkRfT1hZR0VOPW0KQ09ORklH X1NORF9DUzQyODE9bQpDT05GSUdfU05EX0NTNDZYWD1tCkNPTkZJR19TTkRfQ1M0NlhYX05FV19E U1A9eQpDT05GSUdfU05EX0NTNTUzMD1tCkNPTkZJR19TTkRfQ1M1NTM1QVVESU89bQpDT05GSUdf U05EX0NUWEZJPW0KQ09ORklHX1NORF9EQVJMQTIwPW0KQ09ORklHX1NORF9HSU5BMjA9bQpDT05G SUdfU05EX0xBWUxBMjA9bQpDT05GSUdfU05EX0RBUkxBMjQ9bQpDT05GSUdfU05EX0dJTkEyND1t CkNPTkZJR19TTkRfTEFZTEEyND1tCkNPTkZJR19TTkRfTU9OQT1tCkNPTkZJR19TTkRfTUlBPW0K Q09ORklHX1NORF9FQ0hPM0c9bQpDT05GSUdfU05EX0lORElHTz1tCkNPTkZJR19TTkRfSU5ESUdP SU89bQpDT05GSUdfU05EX0lORElHT0RKPW0KQ09ORklHX1NORF9JTkRJR09JT1g9bQpDT05GSUdf U05EX0lORElHT0RKWD1tCkNPTkZJR19TTkRfRU1VMTBLMT1tCkNPTkZJR19TTkRfRU1VMTBLMVg9 bQpDT05GSUdfU05EX0VOUzEzNzA9bQpDT05GSUdfU05EX0VOUzEzNzE9bQpDT05GSUdfU05EX0VT MTkzOD1tCkNPTkZJR19TTkRfRVMxOTY4PW0KQ09ORklHX1NORF9FUzE5NjhfSU5QVVQ9eQpDT05G SUdfU05EX0VTMTk2OF9SQURJTz15CkNPTkZJR19TTkRfRk04MDE9bQpDT05GSUdfU05EX0ZNODAx X1RFQTU3NVhfQk9PTD15CkNPTkZJR19TTkRfSERBX0lOVEVMPW0KQ09ORklHX1NORF9IREFfUFJF QUxMT0NfU0laRT00MDk2CkNPTkZJR19TTkRfSERBX0hXREVQPXkKQ09ORklHX1NORF9IREFfUkVD T05GSUc9eQpDT05GSUdfU05EX0hEQV9JTlBVVF9CRUVQPXkKQ09ORklHX1NORF9IREFfSU5QVVRf QkVFUF9NT0RFPTAKQ09ORklHX1NORF9IREFfSU5QVVRfSkFDSz15CkNPTkZJR19TTkRfSERBX1BB VENIX0xPQURFUj15CkNPTkZJR19TTkRfSERBX0NPREVDX1JFQUxURUs9eQpDT05GSUdfU05EX0hE QV9DT0RFQ19BTkFMT0c9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19TSUdNQVRFTD15CkNPTkZJR19T TkRfSERBX0NPREVDX1ZJQT15CkNPTkZJR19TTkRfSERBX0NPREVDX0hETUk9eQpDT05GSUdfU05E X0hEQV9DT0RFQ19DSVJSVVM9eQpDT05GSUdfU05EX0hEQV9DT0RFQ19DT05FWEFOVD15CkNPTkZJ R19TTkRfSERBX0NPREVDX0NBMDExMD15CkNPTkZJR19TTkRfSERBX0NPREVDX0NBMDEzMj15CkNP TkZJR19TTkRfSERBX0NPREVDX0NNRURJQT15CkNPTkZJR19TTkRfSERBX0NPREVDX1NJMzA1ND15 CkNPTkZJR19TTkRfSERBX0dFTkVSSUM9eQpDT05GSUdfU05EX0hEQV9QT1dFUl9TQVZFPXkKQ09O RklHX1NORF9IREFfUE9XRVJfU0FWRV9ERUZBVUxUPTAKQ09ORklHX1NORF9IRFNQPW0KQ09ORklH X1NORF9IRFNQTT1tCkNPTkZJR19TTkRfSUNFMTcxMj1tCkNPTkZJR19TTkRfSUNFMTcyND1tCkNP TkZJR19TTkRfSU5URUw4WDA9bQpDT05GSUdfU05EX0lOVEVMOFgwTT1tCkNPTkZJR19TTkRfS09S RzEyMTI9bQpDT05GSUdfU05EX0xPTEE9bQpDT05GSUdfU05EX0xYNjQ2NEVTPW0KQ09ORklHX1NO RF9NQUVTVFJPMz1tCkNPTkZJR19TTkRfTUFFU1RSTzNfSU5QVVQ9eQpDT05GSUdfU05EX01JWEFS VD1tCkNPTkZJR19TTkRfTk0yNTY9bQpDT05GSUdfU05EX1BDWEhSPW0KQ09ORklHX1NORF9SSVBU SURFPW0KQ09ORklHX1NORF9STUUzMj1tCkNPTkZJR19TTkRfUk1FOTY9bQpDT05GSUdfU05EX1JN RTk2NTI9bQpDT05GSUdfU05EX1NPTklDVklCRVM9bQpDT05GSUdfU05EX1RSSURFTlQ9bQpDT05G SUdfU05EX1ZJQTgyWFg9bQpDT05GSUdfU05EX1ZJQTgyWFhfTU9ERU09bQpDT05GSUdfU05EX1ZJ UlRVT1NPPW0KQ09ORklHX1NORF9WWDIyMj1tCkNPTkZJR19TTkRfWU1GUENJPW0KQ09ORklHX1NO RF9VU0I9eQpDT05GSUdfU05EX1VTQl9BVURJTz1tCkNPTkZJR19TTkRfVVNCX1VBMTAxPW0KQ09O RklHX1NORF9VU0JfVVNYMlk9bQpDT05GSUdfU05EX1VTQl9DQUlBUT1tCkNPTkZJR19TTkRfVVNC X0NBSUFRX0lOUFVUPXkKQ09ORklHX1NORF9VU0JfVVMxMjJMPW0KQ09ORklHX1NORF9VU0JfNkZJ UkU9bQpDT05GSUdfU05EX0ZJUkVXSVJFPXkKQ09ORklHX1NORF9GSVJFV0lSRV9MSUI9bQpDT05G SUdfU05EX0ZJUkVXSVJFX1NQRUFLRVJTPW0KQ09ORklHX1NORF9JU0lHSFQ9bQojIENPTkZJR19T TkRfUENNQ0lBIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQyBpcyBub3Qgc2V0CiMgQ09ORklH X1NPVU5EX1BSSU1FIGlzIG5vdCBzZXQKQ09ORklHX0FDOTdfQlVTPW0KCiMKIyBISUQgc3VwcG9y dAojCkNPTkZJR19ISUQ9eQpDT05GSUdfSElEX0JBVFRFUllfU1RSRU5HVEg9eQpDT05GSUdfSElE UkFXPXkKQ09ORklHX1VISUQ9bQpDT05GSUdfSElEX0dFTkVSSUM9eQoKIwojIFNwZWNpYWwgSElE IGRyaXZlcnMKIwpDT05GSUdfSElEX0E0VEVDSD15CkNPTkZJR19ISURfQUNSVVg9bQpDT05GSUdf SElEX0FDUlVYX0ZGPXkKQ09ORklHX0hJRF9BUFBMRT15CkNPTkZJR19ISURfQVVSRUFMPW0KQ09O RklHX0hJRF9CRUxLSU49eQpDT05GSUdfSElEX0NIRVJSWT15CkNPTkZJR19ISURfQ0hJQ09OWT15 CkNPTkZJR19ISURfUFJPRElLRVlTPW0KQ09ORklHX0hJRF9DWVBSRVNTPXkKQ09ORklHX0hJRF9E UkFHT05SSVNFPW0KQ09ORklHX0RSQUdPTlJJU0VfRkY9eQpDT05GSUdfSElEX0VNU19GRj1tCkNP TkZJR19ISURfRUxFQ09NPW0KQ09ORklHX0hJRF9FWktFWT15CkNPTkZJR19ISURfSE9MVEVLPW0K Q09ORklHX0hPTFRFS19GRj15CkNPTkZJR19ISURfS0VZVE9VQ0g9bQpDT05GSUdfSElEX0tZRT1t CkNPTkZJR19ISURfVUNMT0dJQz1tCkNPTkZJR19ISURfV0FMVE9QPW0KQ09ORklHX0hJRF9HWVJB VElPTj1tCkNPTkZJR19ISURfVFdJTkhBTj1tCkNPTkZJR19ISURfS0VOU0lOR1RPTj15CkNPTkZJ R19ISURfTENQT1dFUj1tCkNPTkZJR19ISURfTEVOT1ZPX1RQS0JEPW0KQ09ORklHX0hJRF9MT0dJ VEVDSD15CkNPTkZJR19ISURfTE9HSVRFQ0hfREo9bQpDT05GSUdfTE9HSVRFQ0hfRkY9eQpDT05G SUdfTE9HSVJVTUJMRVBBRDJfRkY9eQpDT05GSUdfTE9HSUc5NDBfRkY9eQpDT05GSUdfTE9HSVdI RUVMU19GRj15CkNPTkZJR19ISURfTUFHSUNNT1VTRT1tCkNPTkZJR19ISURfTUlDUk9TT0ZUPXkK Q09ORklHX0hJRF9NT05URVJFWT15CkNPTkZJR19ISURfTVVMVElUT1VDSD1tCkNPTkZJR19ISURf TlRSSUc9eQpDT05GSUdfSElEX09SVEVLPW0KQ09ORklHX0hJRF9QQU5USEVSTE9SRD1tCkNPTkZJ R19QQU5USEVSTE9SRF9GRj15CkNPTkZJR19ISURfUEVUQUxZTlg9bQpDT05GSUdfSElEX1BJQ09M Q0Q9bQpDT05GSUdfSElEX1BJQ09MQ0RfRkI9eQpDT05GSUdfSElEX1BJQ09MQ0RfQkFDS0xJR0hU PXkKQ09ORklHX0hJRF9QSUNPTENEX0xDRD15CkNPTkZJR19ISURfUElDT0xDRF9MRURTPXkKQ09O RklHX0hJRF9QUklNQVg9bQpDT05GSUdfSElEX1JPQ0NBVD1tCkNPTkZJR19ISURfU0FJVEVLPW0K Q09ORklHX0hJRF9TQU1TVU5HPW0KQ09ORklHX0hJRF9TT05ZPW0KQ09ORklHX0hJRF9TUEVFRExJ Tks9bQpDT05GSUdfSElEX1NVTlBMVVM9bQpDT05GSUdfSElEX0dSRUVOQVNJQT1tCkNPTkZJR19H UkVFTkFTSUFfRkY9eQpDT05GSUdfSElEX0hZUEVSVl9NT1VTRT1tCkNPTkZJR19ISURfU01BUlRK T1lQTFVTPW0KQ09ORklHX1NNQVJUSk9ZUExVU19GRj15CkNPTkZJR19ISURfVElWTz1tCkNPTkZJ R19ISURfVE9QU0VFRD1tCkNPTkZJR19ISURfVEhSVVNUTUFTVEVSPW0KQ09ORklHX1RIUlVTVE1B U1RFUl9GRj15CkNPTkZJR19ISURfV0FDT009bQpDT05GSUdfSElEX1dJSU1PVEU9bQpDT05GSUdf SElEX1dJSU1PVEVfRVhUPXkKQ09ORklHX0hJRF9aRVJPUExVUz1tCkNPTkZJR19aRVJPUExVU19G Rj15CkNPTkZJR19ISURfWllEQUNST049bQoKIwojIFVTQiBISUQgc3VwcG9ydAojCkNPTkZJR19V U0JfSElEPXkKQ09ORklHX0hJRF9QSUQ9eQpDT05GSUdfVVNCX0hJRERFVj15CkNPTkZJR19VU0Jf QVJDSF9IQVNfT0hDST15CkNPTkZJR19VU0JfQVJDSF9IQVNfRUhDST15CkNPTkZJR19VU0JfQVJD SF9IQVNfWEhDST15CkNPTkZJR19VU0JfU1VQUE9SVD15CkNPTkZJR19VU0JfQ09NTU9OPXkKQ09O RklHX1VTQl9BUkNIX0hBU19IQ0Q9eQpDT05GSUdfVVNCPXkKIyBDT05GSUdfVVNCX0RFQlVHIGlz IG5vdCBzZXQKQ09ORklHX1VTQl9BTk5PVU5DRV9ORVdfREVWSUNFUz15CgojCiMgTWlzY2VsbGFu ZW91cyBVU0Igb3B0aW9ucwojCiMgQ09ORklHX1VTQl9EWU5BTUlDX01JTk9SUyBpcyBub3Qgc2V0 CkNPTkZJR19VU0JfU1VTUEVORD15CiMgQ09ORklHX1VTQl9PVEcgaXMgbm90IHNldApDT05GSUdf VVNCX01PTj15CkNPTkZJR19VU0JfV1VTQj1tCkNPTkZJR19VU0JfV1VTQl9DQkFGPW0KIyBDT05G SUdfVVNCX1dVU0JfQ0JBRl9ERUJVRyBpcyBub3Qgc2V0CgojCiMgVVNCIEhvc3QgQ29udHJvbGxl ciBEcml2ZXJzCiMKIyBDT05GSUdfVVNCX0M2N1gwMF9IQ0QgaXMgbm90IHNldApDT05GSUdfVVNC X1hIQ0lfSENEPXkKIyBDT05GSUdfVVNCX1hIQ0lfSENEX0RFQlVHR0lORyBpcyBub3Qgc2V0CkNP TkZJR19VU0JfRUhDSV9IQ0Q9eQpDT05GSUdfVVNCX0VIQ0lfUk9PVF9IVUJfVFQ9eQpDT05GSUdf VVNCX0VIQ0lfVFRfTkVXU0NIRUQ9eQojIENPTkZJR19VU0JfT1hVMjEwSFBfSENEIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0lTUDExNlhfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0lTUDE3 NjBfSENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9JU1AxMzYyX0hDRD1tCkNPTkZJR19VU0JfT0hD SV9IQ0Q9eQojIENPTkZJR19VU0JfT0hDSV9IQ0RfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJ R19VU0JfRUhDSV9IQ0RfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJR19VU0JfT0hDSV9CSUdf RU5ESUFOX0RFU0MgaXMgbm90IHNldAojIENPTkZJR19VU0JfT0hDSV9CSUdfRU5ESUFOX01NSU8g aXMgbm90IHNldApDT05GSUdfVVNCX09IQ0lfTElUVExFX0VORElBTj15CkNPTkZJR19VU0JfVUhD SV9IQ0Q9eQpDT05GSUdfVVNCX1UxMzJfSENEPW0KQ09ORklHX1VTQl9TTDgxMV9IQ0Q9bQpDT05G SUdfVVNCX1NMODExX0hDRF9JU089eQojIENPTkZJR19VU0JfU0w4MTFfQ1MgaXMgbm90IHNldAoj IENPTkZJR19VU0JfUjhBNjY1OTdfSENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9XSENJX0hDRD1t CkNPTkZJR19VU0JfSFdBX0hDRD1tCiMgQ09ORklHX1VTQl9IQ0RfQkNNQSBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9IQ0RfU1NCIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0NISVBJREVBIGlzIG5v dCBzZXQKCiMKIyBVU0IgRGV2aWNlIENsYXNzIGRyaXZlcnMKIwpDT05GSUdfVVNCX0FDTT1tCkNP TkZJR19VU0JfUFJJTlRFUj1tCkNPTkZJR19VU0JfV0RNPW0KQ09ORklHX1VTQl9UTUM9bQoKIwoj IE5PVEU6IFVTQl9TVE9SQUdFIGRlcGVuZHMgb24gU0NTSSBidXQgQkxLX0RFVl9TRCBtYXkKIwoK IwojIGFsc28gYmUgbmVlZGVkOyBzZWUgVVNCX1NUT1JBR0UgSGVscCBmb3IgbW9yZSBpbmZvCiMK Q09ORklHX1VTQl9TVE9SQUdFPW0KIyBDT05GSUdfVVNCX1NUT1JBR0VfREVCVUcgaXMgbm90IHNl dApDT05GSUdfVVNCX1NUT1JBR0VfUkVBTFRFSz1tCkNPTkZJR19SRUFMVEVLX0FVVE9QTT15CkNP TkZJR19VU0JfU1RPUkFHRV9EQVRBRkFCPW0KQ09ORklHX1VTQl9TVE9SQUdFX0ZSRUVDT009bQpD T05GSUdfVVNCX1NUT1JBR0VfSVNEMjAwPW0KQ09ORklHX1VTQl9TVE9SQUdFX1VTQkFUPW0KQ09O RklHX1VTQl9TVE9SQUdFX1NERFIwOT1tCkNPTkZJR19VU0JfU1RPUkFHRV9TRERSNTU9bQpDT05G SUdfVVNCX1NUT1JBR0VfSlVNUFNIT1Q9bQpDT05GSUdfVVNCX1NUT1JBR0VfQUxBVURBPW0KQ09O RklHX1VTQl9TVE9SQUdFX09ORVRPVUNIPW0KQ09ORklHX1VTQl9TVE9SQUdFX0tBUk1BPW0KQ09O RklHX1VTQl9TVE9SQUdFX0NZUFJFU1NfQVRBQ0I9bQpDT05GSUdfVVNCX1NUT1JBR0VfRU5FX1VC NjI1MD1tCiMgQ09ORklHX1VTQl9VQVMgaXMgbm90IHNldAojIENPTkZJR19VU0JfTElCVVNVQUwg aXMgbm90IHNldAoKIwojIFVTQiBJbWFnaW5nIGRldmljZXMKIwpDT05GSUdfVVNCX01EQzgwMD1t CkNPTkZJR19VU0JfTUlDUk9URUs9bQoKIwojIFVTQiBwb3J0IGRyaXZlcnMKIwpDT05GSUdfVVNC X1VTUzcyMD1tCkNPTkZJR19VU0JfU0VSSUFMPXkKQ09ORklHX1VTQl9TRVJJQUxfQ09OU09MRT15 CkNPTkZJR19VU0JfRVpVU0I9eQpDT05GSUdfVVNCX1NFUklBTF9HRU5FUklDPXkKQ09ORklHX1VT Ql9TRVJJQUxfQUlSQ0FCTEU9bQpDT05GSUdfVVNCX1NFUklBTF9BUkszMTE2PW0KQ09ORklHX1VT Ql9TRVJJQUxfQkVMS0lOPW0KQ09ORklHX1VTQl9TRVJJQUxfQ0gzNDE9bQpDT05GSUdfVVNCX1NF UklBTF9XSElURUhFQVQ9bQpDT05GSUdfVVNCX1NFUklBTF9ESUdJX0FDQ0VMRVBPUlQ9bQpDT05G SUdfVVNCX1NFUklBTF9DUDIxMFg9bQpDT05GSUdfVVNCX1NFUklBTF9DWVBSRVNTX004PW0KQ09O RklHX1VTQl9TRVJJQUxfRU1QRUc9bQpDT05GSUdfVVNCX1NFUklBTF9GVERJX1NJTz1tCkNPTkZJ R19VU0JfU0VSSUFMX0ZVTlNPRlQ9bQpDT05GSUdfVVNCX1NFUklBTF9WSVNPUj1tCkNPTkZJR19V U0JfU0VSSUFMX0lQQVE9bQpDT05GSUdfVVNCX1NFUklBTF9JUj1tCkNPTkZJR19VU0JfU0VSSUFM X0VER0VQT1JUPW0KQ09ORklHX1VTQl9TRVJJQUxfRURHRVBPUlRfVEk9bQojIENPTkZJR19VU0Jf U0VSSUFMX0Y4MTIzMiBpcyBub3Qgc2V0CkNPTkZJR19VU0JfU0VSSUFMX0dBUk1JTj1tCkNPTkZJ R19VU0JfU0VSSUFMX0lQVz1tCkNPTkZJR19VU0JfU0VSSUFMX0lVVT1tCkNPTkZJR19VU0JfU0VS SUFMX0tFWVNQQU5fUERBPW0KQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTj1tCkNPTkZJR19VU0Jf U0VSSUFMX0tMU0k9bQpDT05GSUdfVVNCX1NFUklBTF9LT0JJTF9TQ1Q9bQpDT05GSUdfVVNCX1NF UklBTF9NQ1RfVTIzMj1tCiMgQ09ORklHX1VTQl9TRVJJQUxfTUVUUk8gaXMgbm90IHNldApDT05G SUdfVVNCX1NFUklBTF9NT1M3NzIwPW0KQ09ORklHX1VTQl9TRVJJQUxfTU9TNzcxNV9QQVJQT1JU PXkKQ09ORklHX1VTQl9TRVJJQUxfTU9TNzg0MD1tCkNPTkZJR19VU0JfU0VSSUFMX01PVE9ST0xB PW0KQ09ORklHX1VTQl9TRVJJQUxfTkFWTUFOPW0KQ09ORklHX1VTQl9TRVJJQUxfUEwyMzAzPW0K Q09ORklHX1VTQl9TRVJJQUxfT1RJNjg1OD1tCkNPTkZJR19VU0JfU0VSSUFMX1FDQVVYPW0KQ09O RklHX1VTQl9TRVJJQUxfUVVBTENPTU09bQpDT05GSUdfVVNCX1NFUklBTF9TUENQOFg1PW0KQ09O RklHX1VTQl9TRVJJQUxfSFA0WD1tCkNPTkZJR19VU0JfU0VSSUFMX1NBRkU9bQpDT05GSUdfVVNC X1NFUklBTF9TQUZFX1BBRERFRD15CkNPTkZJR19VU0JfU0VSSUFMX1NJRU1FTlNfTVBJPW0KQ09O RklHX1VTQl9TRVJJQUxfU0lFUlJBV0lSRUxFU1M9bQpDT05GSUdfVVNCX1NFUklBTF9TWU1CT0w9 bQpDT05GSUdfVVNCX1NFUklBTF9UST1tCkNPTkZJR19VU0JfU0VSSUFMX0NZQkVSSkFDSz1tCkNP TkZJR19VU0JfU0VSSUFMX1hJUkNPTT1tCkNPTkZJR19VU0JfU0VSSUFMX1dXQU49bQpDT05GSUdf VVNCX1NFUklBTF9PUFRJT049bQpDT05GSUdfVVNCX1NFUklBTF9PTU5JTkVUPW0KQ09ORklHX1VT Ql9TRVJJQUxfT1BUSUNPTj1tCkNPTkZJR19VU0JfU0VSSUFMX1ZJVk9QQVlfU0VSSUFMPW0KIyBD T05GSUdfVVNCX1NFUklBTF9aSU8gaXMgbm90IHNldApDT05GSUdfVVNCX1NFUklBTF9TU1UxMDA9 bQpDT05GSUdfVVNCX1NFUklBTF9RVDI9bQpDT05GSUdfVVNCX1NFUklBTF9ERUJVRz1tCgojCiMg VVNCIE1pc2NlbGxhbmVvdXMgZHJpdmVycwojCkNPTkZJR19VU0JfRU1JNjI9bQpDT05GSUdfVVNC X0VNSTI2PW0KQ09ORklHX1VTQl9BRFVUVVg9bQpDT05GSUdfVVNCX1NFVlNFRz1tCiMgQ09ORklH X1VTQl9SSU81MDAgaXMgbm90IHNldApDT05GSUdfVVNCX0xFR09UT1dFUj1tCkNPTkZJR19VU0Jf TENEPW0KQ09ORklHX1VTQl9MRUQ9bQojIENPTkZJR19VU0JfQ1lQUkVTU19DWTdDNjMgaXMgbm90 IHNldAojIENPTkZJR19VU0JfQ1lUSEVSTSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfSURNT1VTRT1t CkNPTkZJR19VU0JfRlRESV9FTEFOPW0KQ09ORklHX1VTQl9BUFBMRURJU1BMQVk9bQpDT05GSUdf VVNCX1NJU1VTQlZHQT1tCkNPTkZJR19VU0JfU0lTVVNCVkdBX0NPTj15CkNPTkZJR19VU0JfTEQ9 bQpDT05GSUdfVVNCX1RSQU5DRVZJQlJBVE9SPW0KQ09ORklHX1VTQl9JT1dBUlJJT1I9bQojIENP TkZJR19VU0JfVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfSVNJR0hURlc9bQpDT05GSUdfVVNC X1lVUkVYPW0KCiMKIyBVU0IgUGh5c2ljYWwgTGF5ZXIgZHJpdmVycwojCiMgQ09ORklHX1VTQl9J U1AxMzAxIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9BVE09bQpDT05GSUdfVVNCX1NQRUVEVE9VQ0g9 bQpDT05GSUdfVVNCX0NYQUNSVT1tCkNPTkZJR19VU0JfVUVBR0xFQVRNPW0KQ09ORklHX1VTQl9Y VVNCQVRNPW0KIyBDT05GSUdfVVNCX0dBREdFVCBpcyBub3Qgc2V0CgojCiMgT1RHIGFuZCByZWxh dGVkIGluZnJhc3RydWN0dXJlCiMKQ09ORklHX1VTQl9PVEdfVVRJTFM9eQpDT05GSUdfTk9QX1VT Ql9YQ0VJVj1tCkNPTkZJR19VV0I9bQpDT05GSUdfVVdCX0hXQT1tCkNPTkZJR19VV0JfV0hDST1t CkNPTkZJR19VV0JfSTE0ODBVPW0KQ09ORklHX01NQz1tCiMgQ09ORklHX01NQ19ERUJVRyBpcyBu b3Qgc2V0CiMgQ09ORklHX01NQ19VTlNBRkVfUkVTVU1FIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1D X0NMS0dBVEUgaXMgbm90IHNldAoKIwojIE1NQy9TRC9TRElPIENhcmQgRHJpdmVycwojCkNPTkZJ R19NTUNfQkxPQ0s9bQpDT05GSUdfTU1DX0JMT0NLX01JTk9SUz04CkNPTkZJR19NTUNfQkxPQ0tf Qk9VTkNFPXkKQ09ORklHX1NESU9fVUFSVD1tCiMgQ09ORklHX01NQ19URVNUIGlzIG5vdCBzZXQK CiMKIyBNTUMvU0QvU0RJTyBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCkNPTkZJR19NTUNfU0RI Q0k9bQpDT05GSUdfTU1DX1NESENJX1BDST1tCkNPTkZJR19NTUNfUklDT0hfTU1DPXkKQ09ORklH X01NQ19TREhDSV9QTFRGTT1tCkNPTkZJR19NTUNfV0JTRD1tCkNPTkZJR19NTUNfVElGTV9TRD1t CkNPTkZJR19NTUNfU0RSSUNPSF9DUz1tCkNPTkZJR19NTUNfQ0I3MTA9bQpDT05GSUdfTU1DX1ZJ QV9TRE1NQz1tCkNPTkZJR19NTUNfVlVCMzAwPW0KQ09ORklHX01NQ19VU0hDPW0KQ09ORklHX01F TVNUSUNLPW0KIyBDT05GSUdfTUVNU1RJQ0tfREVCVUcgaXMgbm90IHNldAoKIwojIE1lbW9yeVN0 aWNrIGRyaXZlcnMKIwojIENPTkZJR19NRU1TVElDS19VTlNBRkVfUkVTVU1FIGlzIG5vdCBzZXQK Q09ORklHX01TUFJPX0JMT0NLPW0KCiMKIyBNZW1vcnlTdGljayBIb3N0IENvbnRyb2xsZXIgRHJp dmVycwojCkNPTkZJR19NRU1TVElDS19USUZNX01TPW0KQ09ORklHX01FTVNUSUNLX0pNSUNST05f MzhYPW0KQ09ORklHX01FTVNUSUNLX1I1OTI9bQpDT05GSUdfTkVXX0xFRFM9eQpDT05GSUdfTEVE U19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwpDT05GSUdfTEVEU19MTTM1MzA9bQojIENPTkZJ R19MRURTX1BDQTk1MzIgaXMgbm90IHNldApDT05GSUdfTEVEU19MUDM5NDQ9bQpDT05GSUdfTEVE U19MUDU1MjE9bQpDT05GSUdfTEVEU19MUDU1MjM9bQpDT05GSUdfTEVEU19DTEVWT19NQUlMPW0K IyBDT05GSUdfTEVEU19QQ0E5NTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19QQ0E5NjMzIGlz IG5vdCBzZXQKIyBDT05GSUdfTEVEU19CRDI4MDIgaXMgbm90IHNldApDT05GSUdfTEVEU19JTlRF TF9TUzQyMDA9bQpDT05GSUdfTEVEU19ERUxMX05FVEJPT0tTPW0KIyBDT05GSUdfTEVEU19UQ0E2 NTA3IGlzIG5vdCBzZXQKQ09ORklHX0xFRFNfTE0zNTU2PW0KIyBDT05GSUdfTEVEU19PVDIwMCBp cyBub3Qgc2V0CkNPTkZJR19MRURTX0JMSU5LTT1tCkNPTkZJR19MRURTX1RSSUdHRVJTPXkKCiMK IyBMRUQgVHJpZ2dlcnMKIwpDT05GSUdfTEVEU19UUklHR0VSX1RJTUVSPW0KQ09ORklHX0xFRFNf VFJJR0dFUl9PTkVTSE9UPW0KQ09ORklHX0xFRFNfVFJJR0dFUl9IRUFSVEJFQVQ9bQpDT05GSUdf TEVEU19UUklHR0VSX0JBQ0tMSUdIVD1tCkNPTkZJR19MRURTX1RSSUdHRVJfREVGQVVMVF9PTj1t CgojCiMgaXB0YWJsZXMgdHJpZ2dlciBpcyB1bmRlciBOZXRmaWx0ZXIgY29uZmlnIChMRUQgdGFy Z2V0KQojCkNPTkZJR19MRURTX1RSSUdHRVJfVFJBTlNJRU5UPW0KQ09ORklHX0FDQ0VTU0lCSUxJ VFk9eQpDT05GSUdfQTExWV9CUkFJTExFX0NPTlNPTEU9eQpDT05GSUdfSU5GSU5JQkFORD1tCkNP TkZJR19JTkZJTklCQU5EX1VTRVJfTUFEPW0KQ09ORklHX0lORklOSUJBTkRfVVNFUl9BQ0NFU1M9 bQpDT05GSUdfSU5GSU5JQkFORF9VU0VSX01FTT15CkNPTkZJR19JTkZJTklCQU5EX0FERFJfVFJB TlM9eQpDT05GSUdfSU5GSU5JQkFORF9NVEhDQT1tCkNPTkZJR19JTkZJTklCQU5EX01USENBX0RF QlVHPXkKQ09ORklHX0lORklOSUJBTkRfSVBBVEg9bQpDT05GSUdfSU5GSU5JQkFORF9RSUI9bQpD T05GSUdfSU5GSU5JQkFORF9BTVNPMTEwMD1tCiMgQ09ORklHX0lORklOSUJBTkRfQU1TTzExMDBf REVCVUcgaXMgbm90IHNldApDT05GSUdfSU5GSU5JQkFORF9DWEdCMz1tCiMgQ09ORklHX0lORklO SUJBTkRfQ1hHQjNfREVCVUcgaXMgbm90IHNldApDT05GSUdfSU5GSU5JQkFORF9DWEdCND1tCkNP TkZJR19NTFg0X0lORklOSUJBTkQ9bQpDT05GSUdfSU5GSU5JQkFORF9ORVM9bQojIENPTkZJR19J TkZJTklCQU5EX05FU19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0lORklOSUJBTkRfT0NSRE1B IGlzIG5vdCBzZXQKQ09ORklHX0lORklOSUJBTkRfSVBPSUI9bQpDT05GSUdfSU5GSU5JQkFORF9J UE9JQl9DTT15CkNPTkZJR19JTkZJTklCQU5EX0lQT0lCX0RFQlVHPXkKQ09ORklHX0lORklOSUJB TkRfSVBPSUJfREVCVUdfREFUQT15CkNPTkZJR19JTkZJTklCQU5EX1NSUD1tCkNPTkZJR19JTkZJ TklCQU5EX1NSUFQ9bQpDT05GSUdfSU5GSU5JQkFORF9JU0VSPW0KQ09ORklHX0VEQUM9eQoKIwoj IFJlcG9ydGluZyBzdWJzeXN0ZW1zCiMKQ09ORklHX0VEQUNfTEVHQUNZX1NZU0ZTPXkKIyBDT05G SUdfRURBQ19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19FREFDX0RFQ09ERV9NQ0U9bQpDT05GSUdf RURBQ19NQ0VfSU5KPW0KQ09ORklHX0VEQUNfTU1fRURBQz1tCkNPTkZJR19FREFDX0FNRDY0PW0K IyBDT05GSUdfRURBQ19BTUQ2NF9FUlJPUl9JTkpFQ1RJT04gaXMgbm90IHNldApDT05GSUdfRURB Q19FNzUyWD1tCkNPTkZJR19FREFDX0k4Mjk3NVg9bQpDT05GSUdfRURBQ19JMzAwMD1tCkNPTkZJ R19FREFDX0kzMjAwPW0KQ09ORklHX0VEQUNfWDM4PW0KQ09ORklHX0VEQUNfSTU0MDA9bQpDT05G SUdfRURBQ19JN0NPUkU9bQpDT05GSUdfRURBQ19JNTAwMD1tCkNPTkZJR19FREFDX0k1MTAwPW0K Q09ORklHX0VEQUNfSTczMDA9bQpDT05GSUdfRURBQ19TQlJJREdFPW0KQ09ORklHX1JUQ19MSUI9 eQpDT05GSUdfUlRDX0NMQVNTPXkKQ09ORklHX1JUQ19IQ1RPU1lTPXkKQ09ORklHX1JUQ19IQ1RP U1lTX0RFVklDRT0icnRjMCIKIyBDT05GSUdfUlRDX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBSVEMg aW50ZXJmYWNlcwojCkNPTkZJR19SVENfSU5URl9TWVNGUz15CkNPTkZJR19SVENfSU5URl9QUk9D PXkKQ09ORklHX1JUQ19JTlRGX0RFVj15CiMgQ09ORklHX1JUQ19JTlRGX0RFVl9VSUVfRU1VTCBp cyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfVEVTVCBpcyBub3Qgc2V0CgojCiMgSTJDIFJUQyBk cml2ZXJzCiMKQ09ORklHX1JUQ19EUlZfRFMxMzA3PW0KQ09ORklHX1JUQ19EUlZfRFMxMzc0PW0K Q09ORklHX1JUQ19EUlZfRFMxNjcyPW0KQ09ORklHX1JUQ19EUlZfRFMzMjMyPW0KQ09ORklHX1JU Q19EUlZfTUFYNjkwMD1tCkNPTkZJR19SVENfRFJWX1JTNUMzNzI9bQpDT05GSUdfUlRDX0RSVl9J U0wxMjA4PW0KQ09ORklHX1JUQ19EUlZfSVNMMTIwMjI9bQpDT05GSUdfUlRDX0RSVl9YMTIwNT1t CkNPTkZJR19SVENfRFJWX1BDRjg1NjM9bQpDT05GSUdfUlRDX0RSVl9QQ0Y4NTgzPW0KQ09ORklH X1JUQ19EUlZfTTQxVDgwPW0KQ09ORklHX1JUQ19EUlZfTTQxVDgwX1dEVD15CkNPTkZJR19SVENf RFJWX0JRMzJLPW0KIyBDT05GSUdfUlRDX0RSVl9TMzUzOTBBIGlzIG5vdCBzZXQKQ09ORklHX1JU Q19EUlZfRk0zMTMwPW0KQ09ORklHX1JUQ19EUlZfUlg4NTgxPW0KQ09ORklHX1JUQ19EUlZfUlg4 MDI1PW0KQ09ORklHX1JUQ19EUlZfRU0zMDI3PW0KQ09ORklHX1JUQ19EUlZfUlYzMDI5QzI9bQoK IwojIFNQSSBSVEMgZHJpdmVycwojCgojCiMgUGxhdGZvcm0gUlRDIGRyaXZlcnMKIwpDT05GSUdf UlRDX0RSVl9DTU9TPXkKQ09ORklHX1JUQ19EUlZfRFMxMjg2PW0KQ09ORklHX1JUQ19EUlZfRFMx NTExPW0KQ09ORklHX1JUQ19EUlZfRFMxNTUzPW0KQ09ORklHX1JUQ19EUlZfRFMxNzQyPW0KQ09O RklHX1JUQ19EUlZfU1RLMTdUQTg9bQojIENPTkZJR19SVENfRFJWX000OFQ4NiBpcyBub3Qgc2V0 CkNPTkZJR19SVENfRFJWX000OFQzNT1tCkNPTkZJR19SVENfRFJWX000OFQ1OT1tCkNPTkZJR19S VENfRFJWX01TTTYyNDI9bQpDT05GSUdfUlRDX0RSVl9CUTQ4MDI9bQpDT05GSUdfUlRDX0RSVl9S UDVDMDE9bQpDT05GSUdfUlRDX0RSVl9WMzAyMD1tCgojCiMgb24tQ1BVIFJUQyBkcml2ZXJzCiMK Q09ORklHX0RNQURFVklDRVM9eQojIENPTkZJR19ETUFERVZJQ0VTX0RFQlVHIGlzIG5vdCBzZXQK CiMKIyBETUEgRGV2aWNlcwojCiMgQ09ORklHX0lOVEVMX01JRF9ETUFDIGlzIG5vdCBzZXQKQ09O RklHX0lOVEVMX0lPQVRETUE9bQojIENPTkZJR19USU1CX0RNQSBpcyBub3Qgc2V0CkNPTkZJR19Q Q0hfRE1BPW0KQ09ORklHX0RNQV9FTkdJTkU9eQoKIwojIERNQSBDbGllbnRzCiMKQ09ORklHX05F VF9ETUE9eQpDT05GSUdfQVNZTkNfVFhfRE1BPXkKIyBDT05GSUdfRE1BVEVTVCBpcyBub3Qgc2V0 CkNPTkZJR19EQ0E9bQpDT05GSUdfQVVYRElTUExBWT15CkNPTkZJR19LUzAxMDg9bQpDT05GSUdf S1MwMTA4X1BPUlQ9MHgzNzgKQ09ORklHX0tTMDEwOF9ERUxBWT0yCkNPTkZJR19DRkFHMTI4NjRC PW0KQ09ORklHX0NGQUcxMjg2NEJfUkFURT0yMApDT05GSUdfVUlPPW0KQ09ORklHX1VJT19DSUY9 bQojIENPTkZJR19VSU9fUERSViBpcyBub3Qgc2V0CiMgQ09ORklHX1VJT19QRFJWX0dFTklSUSBp cyBub3Qgc2V0CkNPTkZJR19VSU9fQUVDPW0KQ09ORklHX1VJT19TRVJDT1MzPW0KQ09ORklHX1VJ T19QQ0lfR0VORVJJQz1tCiMgQ09ORklHX1VJT19ORVRYIGlzIG5vdCBzZXQKQ09ORklHX1ZGSU9f SU9NTVVfVFlQRTE9bQpDT05GSUdfVkZJTz1tCkNPTkZJR19WRklPX1BDST1tCkNPTkZJR19WSVJU SU89eQpDT05GSUdfVklSVElPX1JJTkc9eQoKIwojIFZpcnRpbyBkcml2ZXJzCiMKQ09ORklHX1ZJ UlRJT19QQ0k9eQpDT05GSUdfVklSVElPX0JBTExPT049bQpDT05GSUdfVklSVElPX01NSU89bQoj IENPTkZJR19WSVJUSU9fTU1JT19DTURMSU5FX0RFVklDRVMgaXMgbm90IHNldAoKIwojIE1pY3Jv c29mdCBIeXBlci1WIGd1ZXN0IHN1cHBvcnQKIwpDT05GSUdfSFlQRVJWPW0KQ09ORklHX0hZUEVS Vl9VVElMUz1tCgojCiMgWGVuIGRyaXZlciBzdXBwb3J0CiMKQ09ORklHX1hFTl9CQUxMT09OPXkK Q09ORklHX1hFTl9TRUxGQkFMTE9PTklORz15CkNPTkZJR19YRU5fU0NSVUJfUEFHRVM9eQpDT05G SUdfWEVOX0RFVl9FVlRDSE49eQpDT05GSUdfWEVOX0JBQ0tFTkQ9eQpDT05GSUdfWEVORlM9eQpD T05GSUdfWEVOX0NPTVBBVF9YRU5GUz15CkNPTkZJR19YRU5fU1lTX0hZUEVSVklTT1I9eQpDT05G SUdfWEVOX1hFTkJVU19GUk9OVEVORD15CkNPTkZJR19YRU5fR05UREVWPXkKQ09ORklHX1hFTl9H UkFOVF9ERVZfQUxMT0M9eQpDT05GSUdfU1dJT1RMQl9YRU49eQpDT05GSUdfWEVOX1RNRU09eQpD T05GSUdfWEVOX1BDSURFVl9CQUNLRU5EPXkKQ09ORklHX1hFTl9QUklWQ01EPXkKQ09ORklHX1hF Tl9BQ1BJX1BST0NFU1NPUj15CiMgQ09ORklHX1hFTl9NQ0VfTE9HIGlzIG5vdCBzZXQKQ09ORklH X1NUQUdJTkc9eQojIENPTkZJR19FVDEzMVggaXMgbm90IHNldAojIENPTkZJR19TTElDT1NTIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCSVBfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1czNVVORCBp cyBub3Qgc2V0CiMgQ09ORklHX1BSSVNNMl9VU0IgaXMgbm90IHNldAojIENPTkZJR19FQ0hPIGlz IG5vdCBzZXQKIyBDT05GSUdfQ09NRURJIGlzIG5vdCBzZXQKIyBDT05GSUdfQVNVU19PTEVEIGlz IG5vdCBzZXQKIyBDT05GSUdfUEFORUwgaXMgbm90IHNldAojIENPTkZJR19SODE4N1NFIGlzIG5v dCBzZXQKIyBDT05GSUdfUlRMODE5MlUgaXMgbm90IHNldAojIENPTkZJR19SVExMSUIgaXMgbm90 IHNldApDT05GSUdfUjg3MTJVPW0KIyBDT05GSUdfUlRTX1BTVE9SIGlzIG5vdCBzZXQKIyBDT05G SUdfUlRTNTEzOSBpcyBub3Qgc2V0CiMgQ09ORklHX1RSQU5aUE9SVCBpcyBub3Qgc2V0CiMgQ09O RklHX0lERV9QSElTT04gaXMgbm90IHNldAojIENPTkZJR19MSU5FNl9VU0IgaXMgbm90IHNldAoj IENPTkZJR19VU0JfU0VSSUFMX1FVQVRFQ0gyIGlzIG5vdCBzZXQKIyBDT05GSUdfVlQ2NjU1IGlz IG5vdCBzZXQKIyBDT05GSUdfVlQ2NjU2IGlzIG5vdCBzZXQKIyBDT05GSUdfRFhfU0VQIGlzIG5v dCBzZXQKIyBDT05GSUdfWlNNQUxMT0MgaXMgbm90IHNldAojIENPTkZJR19XTEFHUzQ5X0gyIGlz IG5vdCBzZXQKIyBDT05GSUdfV0xBR1M0OV9IMjUgaXMgbm90IHNldAojIENPTkZJR19GQl9TTTdY WCBpcyBub3Qgc2V0CkNPTkZJR19DUllTVEFMSEQ9bQojIENPTkZJR19GQl9YR0kgaXMgbm90IHNl dAojIENPTkZJR19BQ1BJX1FVSUNLU1RBUlQgaXMgbm90IHNldAojIENPTkZJR19VU0JfRU5FU1RP UkFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0JDTV9XSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZU MTAwMCBpcyBub3Qgc2V0CgojCiMgU3BlYWt1cCBjb25zb2xlIHNwZWVjaAojCiMgQ09ORklHX1NQ RUFLVVAgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9TWU5BUFRJQ1NfSTJDX1JNSTQg aXMgbm90IHNldApDT05GSUdfU1RBR0lOR19NRURJQT15CiMgQ09ORklHX0RWQl9BUzEwMiBpcyBu b3Qgc2V0CiMgQ09ORklHX0RWQl9DWEQyMDk5IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fRFQz MTU1IGlzIG5vdCBzZXQKIyBDT05GSUdfRUFTWUNBUCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVP X0dPNzAwNyBpcyBub3Qgc2V0CiMgQ09ORklHX1NPTE82WDEwIGlzIG5vdCBzZXQKQ09ORklHX0xJ UkNfU1RBR0lORz15CkNPTkZJR19MSVJDX0JUODI5PW0KQ09ORklHX0xJUkNfSUdPUlBMVUdVU0I9 bQpDT05GSUdfTElSQ19JTU9OPW0KQ09ORklHX0xJUkNfUEFSQUxMRUw9bQpDT05GSUdfTElSQ19T QVNFTT1tCkNPTkZJR19MSVJDX1NFUklBTD1tCkNPTkZJR19MSVJDX1NFUklBTF9UUkFOU01JVFRF Uj15CkNPTkZJR19MSVJDX1NJUj1tCkNPTkZJR19MSVJDX1RUVVNCSVI9bQpDT05GSUdfTElSQ19a SUxPRz1tCgojCiMgQW5kcm9pZAojCiMgQ09ORklHX0FORFJPSUQgaXMgbm90IHNldAojIENPTkZJ R19QSE9ORSBpcyBub3Qgc2V0CiMgQ09ORklHX1JBTVNURVIgaXMgbm90IHNldAojIENPTkZJR19V U0JfV1BBTl9IQ0QgaXMgbm90IHNldAojIENPTkZJR19JUEFDS19CVVMgaXMgbm90IHNldAojIENP TkZJR19XSU1BWF9HRE03MlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1NSX1dJRkkgaXMgbm90IHNl dApDT05GSUdfWDg2X1BMQVRGT1JNX0RFVklDRVM9eQpDT05GSUdfQUNFUl9XTUk9bQpDT05GSUdf QUNFUkhERj1tCkNPTkZJR19BU1VTX0xBUFRPUD1tCkNPTkZJR19ERUxMX0xBUFRPUD1tCkNPTkZJ R19ERUxMX1dNST1tCkNPTkZJR19ERUxMX1dNSV9BSU89bQpDT05GSUdfRlVKSVRTVV9MQVBUT1A9 bQojIENPTkZJR19GVUpJVFNVX0xBUFRPUF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GVUpJVFNV X1RBQkxFVD1tCkNPTkZJR19BTUlMT19SRktJTEw9bQpDT05GSUdfSFBfQUNDRUw9bQpDT05GSUdf SFBfV01JPW0KQ09ORklHX01TSV9MQVBUT1A9bQpDT05GSUdfUEFOQVNPTklDX0xBUFRPUD1tCkNP TkZJR19DT01QQUxfTEFQVE9QPW0KQ09ORklHX1NPTllfTEFQVE9QPW0KQ09ORklHX1NPTllQSV9D T01QQVQ9eQpDT05GSUdfSURFQVBBRF9MQVBUT1A9bQpDT05GSUdfVEhJTktQQURfQUNQST1tCkNP TkZJR19USElOS1BBRF9BQ1BJX0FMU0FfU1VQUE9SVD15CiMgQ09ORklHX1RISU5LUEFEX0FDUElf REVCVUdGQUNJTElUSUVTIGlzIG5vdCBzZXQKIyBDT05GSUdfVEhJTktQQURfQUNQSV9ERUJVRyBp cyBub3Qgc2V0CiMgQ09ORklHX1RISU5LUEFEX0FDUElfVU5TQUZFX0xFRFMgaXMgbm90IHNldApD T05GSUdfVEhJTktQQURfQUNQSV9WSURFTz15CkNPTkZJR19USElOS1BBRF9BQ1BJX0hPVEtFWV9Q T0xMPXkKQ09ORklHX1NFTlNPUlNfSERBUFM9bQojIENPTkZJR19JTlRFTF9NRU5MT1cgaXMgbm90 IHNldApDT05GSUdfRUVFUENfTEFQVE9QPW0KQ09ORklHX0FTVVNfV01JPW0KQ09ORklHX0FTVVNf TkJfV01JPW0KQ09ORklHX0VFRVBDX1dNST1tCkNPTkZJR19BQ1BJX1dNST1tCkNPTkZJR19NU0lf V01JPW0KQ09ORklHX1RPUFNUQVJfTEFQVE9QPW0KQ09ORklHX0FDUElfVE9TSElCQT1tCkNPTkZJ R19UT1NISUJBX0JUX1JGS0lMTD1tCkNPTkZJR19BQ1BJX0NNUEM9bQpDT05GSUdfSU5URUxfSVBT PW0KIyBDT05GSUdfSUJNX1JUTCBpcyBub3Qgc2V0CiMgQ09ORklHX1hPMTVfRUJPT0sgaXMgbm90 IHNldApDT05GSUdfU0FNU1VOR19MQVBUT1A9bQpDT05GSUdfTVhNX1dNST1tCkNPTkZJR19JTlRF TF9PQUtUUkFJTD1tCkNPTkZJR19TQU1TVU5HX1ExMD1tCkNPTkZJR19BUFBMRV9HTVVYPW0KCiMK IyBIYXJkd2FyZSBTcGlubG9jayBkcml2ZXJzCiMKQ09ORklHX0NMS0VWVF9JODI1Mz15CkNPTkZJ R19JODI1M19MT0NLPXkKQ09ORklHX0NMS0JMRF9JODI1Mz15CkNPTkZJR19JT01NVV9BUEk9eQpD T05GSUdfSU9NTVVfU1VQUE9SVD15CkNPTkZJR19BTURfSU9NTVU9eQpDT05GSUdfQU1EX0lPTU1V X1NUQVRTPXkKQ09ORklHX0FNRF9JT01NVV9WMj1tCkNPTkZJR19ETUFSX1RBQkxFPXkKQ09ORklH X0lOVEVMX0lPTU1VPXkKIyBDT05GSUdfSU5URUxfSU9NTVVfREVGQVVMVF9PTiBpcyBub3Qgc2V0 CkNPTkZJR19JTlRFTF9JT01NVV9GTE9QUFlfV0E9eQpDT05GSUdfSVJRX1JFTUFQPXkKCiMKIyBS ZW1vdGVwcm9jIGRyaXZlcnMgKEVYUEVSSU1FTlRBTCkKIwoKIwojIFJwbXNnIGRyaXZlcnMgKEVY UEVSSU1FTlRBTCkKIwojIENPTkZJR19WSVJUX0RSSVZFUlMgaXMgbm90IHNldAojIENPTkZJR19Q TV9ERVZGUkVRIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhUQ09OIGlzIG5vdCBzZXQKIyBDT05GSUdf TUVNT1JZIGlzIG5vdCBzZXQKIyBDT05GSUdfSUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfVk1FX0JV UyBpcyBub3Qgc2V0CiMgQ09ORklHX1BXTSBpcyBub3Qgc2V0CgojCiMgRmlybXdhcmUgRHJpdmVy cwojCkNPTkZJR19FREQ9bQojIENPTkZJR19FRERfT0ZGIGlzIG5vdCBzZXQKQ09ORklHX0ZJUk1X QVJFX01FTU1BUD15CkNPTkZJR19FRklfVkFSUz15CkNPTkZJR19ERUxMX1JCVT1tCkNPTkZJR19E Q0RCQVM9bQpDT05GSUdfRE1JSUQ9eQpDT05GSUdfRE1JX1NZU0ZTPXkKQ09ORklHX0lTQ1NJX0lC RlRfRklORD15CkNPTkZJR19JU0NTSV9JQkZUPW0KIyBDT05GSUdfR09PR0xFX0ZJUk1XQVJFIGlz IG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMKIwpDT05GSUdfRENBQ0hFX1dPUkRfQUNDRVNTPXkK IyBDT05GSUdfRVhUMl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDNfRlMgaXMgbm90IHNldApD T05GSUdfRVhUNF9GUz15CkNPTkZJR19FWFQ0X1VTRV9GT1JfRVhUMjM9eQpDT05GSUdfRVhUNF9G U19YQVRUUj15CkNPTkZJR19FWFQ0X0ZTX1BPU0lYX0FDTD15CkNPTkZJR19FWFQ0X0ZTX1NFQ1VS SVRZPXkKIyBDT05GSUdfRVhUNF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19KQkQyPXkKIyBDT05G SUdfSkJEMl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GU19NQkNBQ0hFPXkKQ09ORklHX1JFSVNF UkZTX0ZTPW0KIyBDT05GSUdfUkVJU0VSRlNfQ0hFQ0sgaXMgbm90IHNldApDT05GSUdfUkVJU0VS RlNfUFJPQ19JTkZPPXkKQ09ORklHX1JFSVNFUkZTX0ZTX1hBVFRSPXkKQ09ORklHX1JFSVNFUkZT X0ZTX1BPU0lYX0FDTD15CkNPTkZJR19SRUlTRVJGU19GU19TRUNVUklUWT15CkNPTkZJR19KRlNf RlM9bQpDT05GSUdfSkZTX1BPU0lYX0FDTD15CkNPTkZJR19KRlNfU0VDVVJJVFk9eQojIENPTkZJ R19KRlNfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19KRlNfU1RBVElTVElDUyBpcyBub3Qgc2V0 CkNPTkZJR19YRlNfRlM9bQpDT05GSUdfWEZTX1FVT1RBPXkKQ09ORklHX1hGU19QT1NJWF9BQ0w9 eQojIENPTkZJR19YRlNfUlQgaXMgbm90IHNldAojIENPTkZJR19YRlNfREVCVUcgaXMgbm90IHNl dApDT05GSUdfR0ZTMl9GUz1tCkNPTkZJR19HRlMyX0ZTX0xPQ0tJTkdfRExNPXkKQ09ORklHX09D RlMyX0ZTPW0KQ09ORklHX09DRlMyX0ZTX08yQ0I9bQpDT05GSUdfT0NGUzJfRlNfVVNFUlNQQUNF X0NMVVNURVI9bQojIENPTkZJR19PQ0ZTMl9GU19TVEFUUyBpcyBub3Qgc2V0CiMgQ09ORklHX09D RlMyX0RFQlVHX01BU0tMT0cgaXMgbm90IHNldAojIENPTkZJR19PQ0ZTMl9ERUJVR19GUyBpcyBu b3Qgc2V0CkNPTkZJR19CVFJGU19GUz1tCkNPTkZJR19CVFJGU19GU19QT1NJWF9BQ0w9eQojIENP TkZJR19CVFJGU19GU19DSEVDS19JTlRFR1JJVFkgaXMgbm90IHNldApDT05GSUdfTklMRlMyX0ZT PW0KQ09ORklHX0ZTX1BPU0lYX0FDTD15CkNPTkZJR19FWFBPUlRGUz15CkNPTkZJR19GSUxFX0xP Q0tJTkc9eQpDT05GSUdfRlNOT1RJRlk9eQpDT05GSUdfRE5PVElGWT15CkNPTkZJR19JTk9USUZZ X1VTRVI9eQpDT05GSUdfRkFOT1RJRlk9eQpDT05GSUdfRkFOT1RJRllfQUNDRVNTX1BFUk1JU1NJ T05TPXkKQ09ORklHX1FVT1RBPXkKQ09ORklHX1FVT1RBX05FVExJTktfSU5URVJGQUNFPXkKIyBD T05GSUdfUFJJTlRfUVVPVEFfV0FSTklORyBpcyBub3Qgc2V0CiMgQ09ORklHX1FVT1RBX0RFQlVH IGlzIG5vdCBzZXQKQ09ORklHX1FVT1RBX1RSRUU9eQojIENPTkZJR19RRk1UX1YxIGlzIG5vdCBz ZXQKQ09ORklHX1FGTVRfVjI9eQpDT05GSUdfUVVPVEFDVEw9eQpDT05GSUdfUVVPVEFDVExfQ09N UEFUPXkKQ09ORklHX0FVVE9GUzRfRlM9eQpDT05GSUdfRlVTRV9GUz1tCkNPTkZJR19DVVNFPW0K Q09ORklHX0dFTkVSSUNfQUNMPXkKCiMKIyBDYWNoZXMKIwpDT05GSUdfRlNDQUNIRT1tCkNPTkZJ R19GU0NBQ0hFX1NUQVRTPXkKIyBDT05GSUdfRlNDQUNIRV9ISVNUT0dSQU0gaXMgbm90IHNldAoj IENPTkZJR19GU0NBQ0hFX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0ZTQ0FDSEVfT0JKRUNUX0xJ U1Q9eQpDT05GSUdfQ0FDSEVGSUxFUz1tCiMgQ09ORklHX0NBQ0hFRklMRVNfREVCVUcgaXMgbm90 IHNldAojIENPTkZJR19DQUNIRUZJTEVTX0hJU1RPR1JBTSBpcyBub3Qgc2V0CgojCiMgQ0QtUk9N L0RWRCBGaWxlc3lzdGVtcwojCkNPTkZJR19JU085NjYwX0ZTPXkKQ09ORklHX0pPTElFVD15CkNP TkZJR19aSVNPRlM9eQpDT05GSUdfVURGX0ZTPW0KQ09ORklHX1VERl9OTFM9eQoKIwojIERPUy9G QVQvTlQgRmlsZXN5c3RlbXMKIwpDT05GSUdfRkFUX0ZTPW0KQ09ORklHX01TRE9TX0ZTPW0KQ09O RklHX1ZGQVRfRlM9bQpDT05GSUdfRkFUX0RFRkFVTFRfQ09ERVBBR0U9NDM3CkNPTkZJR19GQVRf REVGQVVMVF9JT0NIQVJTRVQ9ImFzY2lpIgojIENPTkZJR19OVEZTX0ZTIGlzIG5vdCBzZXQKCiMK IyBQc2V1ZG8gZmlsZXN5c3RlbXMKIwpDT05GSUdfUFJPQ19GUz15CkNPTkZJR19QUk9DX0tDT1JF PXkKQ09ORklHX1BST0NfVk1DT1JFPXkKQ09ORklHX1BST0NfU1lTQ1RMPXkKQ09ORklHX1BST0Nf UEFHRV9NT05JVE9SPXkKQ09ORklHX1NZU0ZTPXkKQ09ORklHX1RNUEZTPXkKQ09ORklHX1RNUEZT X1BPU0lYX0FDTD15CkNPTkZJR19UTVBGU19YQVRUUj15CkNPTkZJR19IVUdFVExCRlM9eQpDT05G SUdfSFVHRVRMQl9QQUdFPXkKQ09ORklHX0NPTkZJR0ZTX0ZTPXkKQ09ORklHX01JU0NfRklMRVNZ U1RFTVM9eQojIENPTkZJR19BREZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0FGRlNfRlM9bQpDT05G SUdfRUNSWVBUX0ZTPW0KQ09ORklHX0hGU19GUz1tCkNPTkZJR19IRlNQTFVTX0ZTPW0KQ09ORklH X0JFRlNfRlM9bQojIENPTkZJR19CRUZTX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQkZTX0ZT IGlzIG5vdCBzZXQKIyBDT05GSUdfRUZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSkZGUzJfRlMg aXMgbm90IHNldApDT05GSUdfVUJJRlNfRlM9bQojIENPTkZJR19VQklGU19GU19BRFZBTkNFRF9D T01QUiBpcyBub3Qgc2V0CkNPTkZJR19VQklGU19GU19MWk89eQpDT05GSUdfVUJJRlNfRlNfWkxJ Qj15CiMgQ09ORklHX0xPR0ZTIGlzIG5vdCBzZXQKQ09ORklHX0NSQU1GUz1tCkNPTkZJR19TUVVB U0hGUz1tCkNPTkZJR19TUVVBU0hGU19YQVRUUj15CkNPTkZJR19TUVVBU0hGU19aTElCPXkKQ09O RklHX1NRVUFTSEZTX0xaTz15CkNPTkZJR19TUVVBU0hGU19YWj15CiMgQ09ORklHX1NRVUFTSEZT XzRLX0RFVkJMS19TSVpFIGlzIG5vdCBzZXQKIyBDT05GSUdfU1FVQVNIRlNfRU1CRURERUQgaXMg bm90IHNldApDT05GSUdfU1FVQVNIRlNfRlJBR01FTlRfQ0FDSEVfU0laRT0zCiMgQ09ORklHX1ZY RlNfRlMgaXMgbm90IHNldApDT05GSUdfTUlOSVhfRlM9bQojIENPTkZJR19PTUZTX0ZTIGlzIG5v dCBzZXQKIyBDT05GSUdfSFBGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1FOWDRGU19GUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1FOWDZGU19GUyBpcyBub3Qgc2V0CkNPTkZJR19ST01GU19GUz1tCkNP TkZJR19ST01GU19CQUNLRURfQllfQkxPQ0s9eQojIENPTkZJR19ST01GU19CQUNLRURfQllfTVRE IGlzIG5vdCBzZXQKIyBDT05GSUdfUk9NRlNfQkFDS0VEX0JZX0JPVEggaXMgbm90IHNldApDT05G SUdfUk9NRlNfT05fQkxPQ0s9eQpDT05GSUdfUFNUT1JFPXkKIyBDT05GSUdfUFNUT1JFX0NPTlNP TEUgaXMgbm90IHNldAojIENPTkZJR19QU1RPUkVfRlRSQUNFIGlzIG5vdCBzZXQKQ09ORklHX1BT VE9SRV9SQU09bQpDT05GSUdfU1lTVl9GUz1tCkNPTkZJR19VRlNfRlM9bQojIENPTkZJR19VRlNf RlNfV1JJVEUgaXMgbm90IHNldAojIENPTkZJR19VRlNfREVCVUcgaXMgbm90IHNldAojIENPTkZJ R19FWE9GU19GUyBpcyBub3Qgc2V0CkNPTkZJR19PUkU9bQpDT05GSUdfTkVUV09SS19GSUxFU1lT VEVNUz15CkNPTkZJR19ORlNfRlM9bQpDT05GSUdfTkZTX1YyPW0KQ09ORklHX05GU19WMz1tCkNP TkZJR19ORlNfVjNfQUNMPXkKQ09ORklHX05GU19WND1tCiMgQ09ORklHX05GU19TV0FQIGlzIG5v dCBzZXQKQ09ORklHX05GU19WNF8xPXkKQ09ORklHX1BORlNfRklMRV9MQVlPVVQ9bQpDT05GSUdf UE5GU19CTE9DSz1tCkNPTkZJR19QTkZTX09CSkxBWU9VVD1tCkNPTkZJR19ORlNfVjRfMV9JTVBM RU1FTlRBVElPTl9JRF9ET01BSU49Imtlcm5lbC5vcmciCkNPTkZJR19ORlNfRlNDQUNIRT15CiMg Q09ORklHX05GU19VU0VfTEVHQUNZX0ROUyBpcyBub3Qgc2V0CkNPTkZJR19ORlNfVVNFX0tFUk5F TF9ETlM9eQpDT05GSUdfTkZTX0RFQlVHPXkKQ09ORklHX05GU0Q9bQpDT05GSUdfTkZTRF9WMl9B Q0w9eQpDT05GSUdfTkZTRF9WMz15CkNPTkZJR19ORlNEX1YzX0FDTD15CkNPTkZJR19ORlNEX1Y0 PXkKIyBDT05GSUdfTkZTRF9GQVVMVF9JTkpFQ1RJT04gaXMgbm90IHNldApDT05GSUdfTE9DS0Q9 bQpDT05GSUdfTE9DS0RfVjQ9eQpDT05GSUdfTkZTX0FDTF9TVVBQT1JUPW0KQ09ORklHX05GU19D T01NT049eQpDT05GSUdfU1VOUlBDPW0KQ09ORklHX1NVTlJQQ19HU1M9bQpDT05GSUdfU1VOUlBD X0JBQ0tDSEFOTkVMPXkKQ09ORklHX1NVTlJQQ19YUFJUX1JETUE9bQpDT05GSUdfUlBDU0VDX0dT U19LUkI1PW0KQ09ORklHX1NVTlJQQ19ERUJVRz15CkNPTkZJR19DRVBIX0ZTPW0KQ09ORklHX0NJ RlM9bQpDT05GSUdfQ0lGU19TVEFUUz15CiMgQ09ORklHX0NJRlNfU1RBVFMyIGlzIG5vdCBzZXQK Q09ORklHX0NJRlNfV0VBS19QV19IQVNIPXkKQ09ORklHX0NJRlNfVVBDQUxMPXkKQ09ORklHX0NJ RlNfWEFUVFI9eQpDT05GSUdfQ0lGU19QT1NJWD15CiMgQ09ORklHX0NJRlNfREVCVUcyIGlzIG5v dCBzZXQKQ09ORklHX0NJRlNfREZTX1VQQ0FMTD15CkNPTkZJR19DSUZTX0ZTQ0FDSEU9eQpDT05G SUdfQ0lGU19BQ0w9eQpDT05GSUdfTkNQX0ZTPW0KQ09ORklHX05DUEZTX1BBQ0tFVF9TSUdOSU5H PXkKQ09ORklHX05DUEZTX0lPQ1RMX0xPQ0tJTkc9eQpDT05GSUdfTkNQRlNfU1RST05HPXkKQ09O RklHX05DUEZTX05GU19OUz15CkNPTkZJR19OQ1BGU19PUzJfTlM9eQpDT05GSUdfTkNQRlNfU01B TExET1M9eQpDT05GSUdfTkNQRlNfTkxTPXkKQ09ORklHX05DUEZTX0VYVFJBUz15CkNPTkZJR19D T0RBX0ZTPW0KIyBDT05GSUdfQUZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHXzlQX0ZTPW0KQ09ORklH XzlQX0ZTQ0FDSEU9eQpDT05GSUdfOVBfRlNfUE9TSVhfQUNMPXkKQ09ORklHX05MUz15CkNPTkZJ R19OTFNfREVGQVVMVD0idXRmOCIKQ09ORklHX05MU19DT0RFUEFHRV80Mzc9eQpDT05GSUdfTkxT X0NPREVQQUdFXzczNz1tCkNPTkZJR19OTFNfQ09ERVBBR0VfNzc1PW0KQ09ORklHX05MU19DT0RF UEFHRV84NTA9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg1Mj1tCkNPTkZJR19OTFNfQ09ERVBBR0Vf ODU1PW0KQ09ORklHX05MU19DT0RFUEFHRV84NTc9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg2MD1t CkNPTkZJR19OTFNfQ09ERVBBR0VfODYxPW0KQ09ORklHX05MU19DT0RFUEFHRV84NjI9bQpDT05G SUdfTkxTX0NPREVQQUdFXzg2Mz1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODY0PW0KQ09ORklHX05M U19DT0RFUEFHRV84NjU9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg2Nj1tCkNPTkZJR19OTFNfQ09E RVBBR0VfODY5PW0KQ09ORklHX05MU19DT0RFUEFHRV85MzY9bQpDT05GSUdfTkxTX0NPREVQQUdF Xzk1MD1tCkNPTkZJR19OTFNfQ09ERVBBR0VfOTMyPW0KQ09ORklHX05MU19DT0RFUEFHRV85NDk9 bQpDT05GSUdfTkxTX0NPREVQQUdFXzg3ND1tCkNPTkZJR19OTFNfSVNPODg1OV84PW0KQ09ORklH X05MU19DT0RFUEFHRV8xMjUwPW0KQ09ORklHX05MU19DT0RFUEFHRV8xMjUxPW0KQ09ORklHX05M U19BU0NJST15CkNPTkZJR19OTFNfSVNPODg1OV8xPW0KQ09ORklHX05MU19JU084ODU5XzI9bQpD T05GSUdfTkxTX0lTTzg4NTlfMz1tCkNPTkZJR19OTFNfSVNPODg1OV80PW0KQ09ORklHX05MU19J U084ODU5XzU9bQpDT05GSUdfTkxTX0lTTzg4NTlfNj1tCkNPTkZJR19OTFNfSVNPODg1OV83PW0K Q09ORklHX05MU19JU084ODU5Xzk9bQpDT05GSUdfTkxTX0lTTzg4NTlfMTM9bQpDT05GSUdfTkxT X0lTTzg4NTlfMTQ9bQpDT05GSUdfTkxTX0lTTzg4NTlfMTU9bQpDT05GSUdfTkxTX0tPSThfUj1t CkNPTkZJR19OTFNfS09JOF9VPW0KQ09ORklHX05MU19NQUNfUk9NQU49bQpDT05GSUdfTkxTX01B Q19DRUxUSUM9bQpDT05GSUdfTkxTX01BQ19DRU5URVVSTz1tCkNPTkZJR19OTFNfTUFDX0NST0FU SUFOPW0KQ09ORklHX05MU19NQUNfQ1lSSUxMSUM9bQpDT05GSUdfTkxTX01BQ19HQUVMSUM9bQpD T05GSUdfTkxTX01BQ19HUkVFSz1tCkNPTkZJR19OTFNfTUFDX0lDRUxBTkQ9bQpDT05GSUdfTkxT X01BQ19JTlVJVD1tCkNPTkZJR19OTFNfTUFDX1JPTUFOSUFOPW0KQ09ORklHX05MU19NQUNfVFVS S0lTSD1tCkNPTkZJR19OTFNfVVRGOD1tCkNPTkZJR19ETE09bQpDT05GSUdfRExNX0RFQlVHPXkK CiMKIyBLZXJuZWwgaGFja2luZwojCkNPTkZJR19UUkFDRV9JUlFGTEFHU19TVVBQT1JUPXkKQ09O RklHX1BSSU5US19USU1FPXkKQ09ORklHX0RFRkFVTFRfTUVTU0FHRV9MT0dMRVZFTD00CiMgQ09O RklHX0VOQUJMRV9XQVJOX0RFUFJFQ0FURUQgaXMgbm90IHNldApDT05GSUdfRU5BQkxFX01VU1Rf Q0hFQ0s9eQpDT05GSUdfRlJBTUVfV0FSTj0yMDQ4CkNPTkZJR19NQUdJQ19TWVNSUT15CkNPTkZJ R19TVFJJUF9BU01fU1lNUz15CiMgQ09ORklHX1JFQURBQkxFX0FTTSBpcyBub3Qgc2V0CkNPTkZJ R19VTlVTRURfU1lNQk9MUz15CkNPTkZJR19ERUJVR19GUz15CkNPTkZJR19IRUFERVJTX0NIRUNL PXkKIyBDT05GSUdfREVCVUdfU0VDVElPTl9NSVNNQVRDSCBpcyBub3Qgc2V0CkNPTkZJR19ERUJV R19LRVJORUw9eQpDT05GSUdfREVCVUdfU0hJUlE9eQpDT05GSUdfTE9DS1VQX0RFVEVDVE9SPXkK Q09ORklHX0hBUkRMT0NLVVBfREVURUNUT1I9eQojIENPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tV UF9QQU5JQyBpcyBub3Qgc2V0CkNPTkZJR19CT09UUEFSQU1fSEFSRExPQ0tVUF9QQU5JQ19WQUxV RT0wCiMgQ09ORklHX0JPT1RQQVJBTV9TT0ZUTE9DS1VQX1BBTklDIGlzIG5vdCBzZXQKQ09ORklH X0JPT1RQQVJBTV9TT0ZUTE9DS1VQX1BBTklDX1ZBTFVFPTAKIyBDT05GSUdfUEFOSUNfT05fT09Q UyBpcyBub3Qgc2V0CkNPTkZJR19QQU5JQ19PTl9PT1BTX1ZBTFVFPTAKIyBDT05GSUdfREVURUNU X0hVTkdfVEFTSyBpcyBub3Qgc2V0CkNPTkZJR19TQ0hFRF9ERUJVRz15CkNPTkZJR19TQ0hFRFNU QVRTPXkKQ09ORklHX1RJTUVSX1NUQVRTPXkKIyBDT05GSUdfREVCVUdfT0JKRUNUUyBpcyBub3Qg c2V0CiMgQ09ORklHX1NMVUJfREVCVUdfT04gaXMgbm90IHNldAojIENPTkZJR19TTFVCX1NUQVRT IGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfS01FTUxFQUsgaXMgbm90IHNldAojIENPTkZJR19E RUJVR19SVF9NVVRFWEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRfTVVURVhfVEVTVEVSIGlzIG5v dCBzZXQKIyBDT05GSUdfREVCVUdfU1BJTkxPQ0sgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19N VVRFWEVTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTE9DS19BTExPQyBpcyBub3Qgc2V0CiMg Q09ORklHX1BST1ZFX0xPQ0tJTkcgaXMgbm90IHNldApDT05GSUdfU1BBUlNFX1JDVV9QT0lOVEVS PXkKIyBDT05GSUdfTE9DS19TVEFUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfQVRPTUlDX1NM RUVQIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTE9DS0lOR19BUElfU0VMRlRFU1RTIGlzIG5v dCBzZXQKQ09ORklHX1NUQUNLVFJBQ0U9eQojIENPTkZJR19ERUJVR19TVEFDS19VU0FHRSBpcyBu b3Qgc2V0CiMgQ09ORklHX0RFQlVHX0tPQkpFQ1QgaXMgbm90IHNldApDT05GSUdfREVCVUdfQlVH VkVSQk9TRT15CkNPTkZJR19ERUJVR19JTkZPPXkKIyBDT05GSUdfREVCVUdfSU5GT19SRURVQ0VE IGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX1ZNPXkKIyBDT05GSUdfREVCVUdfVklSVFVBTCBpcyBu b3Qgc2V0CiMgQ09ORklHX0RFQlVHX1dSSVRFQ09VTlQgaXMgbm90IHNldApDT05GSUdfREVCVUdf TUVNT1JZX0lOSVQ9eQpDT05GSUdfREVCVUdfTElTVD15CiMgQ09ORklHX1RFU1RfTElTVF9TT1JU IGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0cgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19O T1RJRklFUlMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19DUkVERU5USUFMUyBpcyBub3Qgc2V0 CkNPTkZJR19BUkNIX1dBTlRfRlJBTUVfUE9JTlRFUlM9eQpDT05GSUdfRlJBTUVfUE9JTlRFUj15 CkNPTkZJR19CT09UX1BSSU5US19ERUxBWT15CiMgQ09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMg bm90IHNldApDT05GSUdfUkNVX0NQVV9TVEFMTF9USU1FT1VUPTYwCiMgQ09ORklHX1JDVV9DUFVf U1RBTExfSU5GTyBpcyBub3Qgc2V0CiMgQ09ORklHX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09O RklHX0tQUk9CRVNfU0FOSVRZX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19CQUNLVFJBQ0VfU0VM Rl9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfQkxPQ0tfRVhUX0RFVlQgaXMgbm90IHNl dAojIENPTkZJR19ERUJVR19GT1JDRV9XRUFLX1BFUl9DUFUgaXMgbm90IHNldAojIENPTkZJR19E RUJVR19QRVJfQ1BVX01BUFMgaXMgbm90IHNldAojIENPTkZJR19MS0RUTSBpcyBub3Qgc2V0CiMg Q09ORklHX05PVElGSUVSX0VSUk9SX0lOSkVDVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZBVUxU X0lOSkVDVElPTiBpcyBub3Qgc2V0CkNPTkZJR19MQVRFTkNZVE9QPXkKIyBDT05GSUdfREVCVUdf UEFHRUFMTE9DIGlzIG5vdCBzZXQKQ09ORklHX1VTRVJfU1RBQ0tUUkFDRV9TVVBQT1JUPXkKQ09O RklHX05PUF9UUkFDRVI9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9UUkFDRVI9eQpDT05GSUdfSEFW RV9GVU5DVElPTl9HUkFQSF9UUkFDRVI9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9HUkFQSF9GUF9U RVNUPXkKQ09ORklHX0hBVkVfRlVOQ1RJT05fVFJBQ0VfTUNPVU5UX1RFU1Q9eQpDT05GSUdfSEFW RV9EWU5BTUlDX0ZUUkFDRT15CkNPTkZJR19IQVZFX0ZUUkFDRV9NQ09VTlRfUkVDT1JEPXkKQ09O RklHX0hBVkVfU1lTQ0FMTF9UUkFDRVBPSU5UUz15CkNPTkZJR19IQVZFX0NfUkVDT1JETUNPVU5U PXkKQ09ORklHX1RSQUNFUl9NQVhfVFJBQ0U9eQpDT05GSUdfUklOR19CVUZGRVI9eQpDT05GSUdf RVZFTlRfVFJBQ0lORz15CkNPTkZJR19FVkVOVF9QT1dFUl9UUkFDSU5HX0RFUFJFQ0FURUQ9eQpD T05GSUdfQ09OVEVYVF9TV0lUQ0hfVFJBQ0VSPXkKQ09ORklHX1JJTkdfQlVGRkVSX0FMTE9XX1NX QVA9eQpDT05GSUdfVFJBQ0lORz15CkNPTkZJR19HRU5FUklDX1RSQUNFUj15CkNPTkZJR19UUkFD SU5HX1NVUFBPUlQ9eQpDT05GSUdfRlRSQUNFPXkKQ09ORklHX0ZVTkNUSU9OX1RSQUNFUj15CkNP TkZJR19GVU5DVElPTl9HUkFQSF9UUkFDRVI9eQojIENPTkZJR19JUlFTT0ZGX1RSQUNFUiBpcyBu b3Qgc2V0CkNPTkZJR19TQ0hFRF9UUkFDRVI9eQpDT05GSUdfRlRSQUNFX1NZU0NBTExTPXkKQ09O RklHX0JSQU5DSF9QUk9GSUxFX05PTkU9eQojIENPTkZJR19QUk9GSUxFX0FOTk9UQVRFRF9CUkFO Q0hFUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BST0ZJTEVfQUxMX0JSQU5DSEVTIGlzIG5vdCBzZXQK Q09ORklHX1NUQUNLX1RSQUNFUj15CkNPTkZJR19CTEtfREVWX0lPX1RSQUNFPXkKQ09ORklHX0tQ Uk9CRV9FVkVOVD15CkNPTkZJR19VUFJPQkVfRVZFTlQ9eQpDT05GSUdfUFJPQkVfRVZFTlRTPXkK Q09ORklHX0RZTkFNSUNfRlRSQUNFPXkKQ09ORklHX0ZVTkNUSU9OX1BST0ZJTEVSPXkKQ09ORklH X0ZUUkFDRV9NQ09VTlRfUkVDT1JEPXkKIyBDT05GSUdfRlRSQUNFX1NUQVJUVVBfVEVTVCBpcyBu b3Qgc2V0CiMgQ09ORklHX01NSU9UUkFDRSBpcyBub3Qgc2V0CkNPTkZJR19SSU5HX0JVRkZFUl9C RU5DSE1BUks9bQpDT05GSUdfUFJPVklERV9PSENJMTM5NF9ETUFfSU5JVD15CiMgQ09ORklHX0ZJ UkVXSVJFX09IQ0lfUkVNT1RFX0RNQSBpcyBub3Qgc2V0CkNPTkZJR19CVUlMRF9ET0NTUkM9eQpD T05GSUdfRFlOQU1JQ19ERUJVRz15CiMgQ09ORklHX0RNQV9BUElfREVCVUcgaXMgbm90IHNldApD T05GSUdfQVRPTUlDNjRfU0VMRlRFU1Q9eQpDT05GSUdfQVNZTkNfUkFJRDZfVEVTVD1tCiMgQ09O RklHX1NBTVBMRVMgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNIX0tHREI9eQpDT05GSUdfS0dE Qj15CkNPTkZJR19LR0RCX1NFUklBTF9DT05TT0xFPXkKQ09ORklHX0tHREJfVEVTVFM9eQojIENP TkZJR19LR0RCX1RFU1RTX09OX0JPT1QgaXMgbm90IHNldApDT05GSUdfS0dEQl9MT1dfTEVWRUxf VFJBUD15CkNPTkZJR19LR0RCX0tEQj15CkNPTkZJR19LREJfS0VZQk9BUkQ9eQpDT05GSUdfSEFW RV9BUkNIX0tNRU1DSEVDSz15CkNPTkZJR19URVNUX0tTVFJUT1g9eQpDT05GSUdfU1RSSUNUX0RF Vk1FTT15CiMgQ09ORklHX1g4Nl9WRVJCT1NFX0JPT1RVUCBpcyBub3Qgc2V0CkNPTkZJR19FQVJM WV9QUklOVEs9eQpDT05GSUdfRUFSTFlfUFJJTlRLX0RCR1A9eQpDT05GSUdfREVCVUdfU1RBQ0tP VkVSRkxPVz15CiMgQ09ORklHX1g4Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9E QVRBPXkKQ09ORklHX0RFQlVHX1JPREFUQV9URVNUPXkKQ09ORklHX0RFQlVHX1NFVF9NT0RVTEVf Uk9OWD15CkNPTkZJR19ERUJVR19OWF9URVNUPW0KIyBDT05GSUdfREVCVUdfVExCRkxVU0ggaXMg bm90IHNldAojIENPTkZJR19JT01NVV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0lPTU1VX1NU UkVTUyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX01NSU9UUkFDRV9TVVBQT1JUPXkKQ09ORklHX1g4 Nl9ERUNPREVSX1NFTEZURVNUPXkKQ09ORklHX0lPX0RFTEFZX1RZUEVfMFg4MD0wCkNPTkZJR19J T19ERUxBWV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9VREVMQVk9MgpDT05GSUdf SU9fREVMQVlfVFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9eQojIENPTkZJR19JT19E RUxBWV8wWEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURFTEFZIGlzIG5vdCBzZXQK IyBDT05GSUdfSU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPX0RFTEFZ X1RZUEU9MApDT05GSUdfREVCVUdfQk9PVF9QQVJBTVM9eQojIENPTkZJR19DUEFfREVCVUcgaXMg bm90IHNldApDT05GSUdfT1BUSU1JWkVfSU5MSU5JTkc9eQojIENPTkZJR19ERUJVR19TVFJJQ1Rf VVNFUl9DT1BZX0NIRUNLUyBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX05NSV9TRUxGVEVTVCBp cyBub3Qgc2V0CgojCiMgU2VjdXJpdHkgb3B0aW9ucwojCkNPTkZJR19LRVlTPXkKQ09ORklHX1RS VVNURURfS0VZUz1tCkNPTkZJR19FTkNSWVBURURfS0VZUz1tCkNPTkZJR19LRVlTX0RFQlVHX1BS T0NfS0VZUz15CiMgQ09ORklHX1NFQ1VSSVRZX0RNRVNHX1JFU1RSSUNUIGlzIG5vdCBzZXQKQ09O RklHX1NFQ1VSSVRZPXkKQ09ORklHX1NFQ1VSSVRZRlM9eQpDT05GSUdfU0VDVVJJVFlfTkVUV09S Sz15CkNPTkZJR19TRUNVUklUWV9ORVRXT1JLX1hGUk09eQojIENPTkZJR19TRUNVUklUWV9QQVRI IGlzIG5vdCBzZXQKQ09ORklHX0lOVEVMX1RYVD15CkNPTkZJR19MU01fTU1BUF9NSU5fQUREUj02 NTUzNgpDT05GSUdfU0VDVVJJVFlfU0VMSU5VWD15CkNPTkZJR19TRUNVUklUWV9TRUxJTlVYX0JP T1RQQVJBTT15CkNPTkZJR19TRUNVUklUWV9TRUxJTlVYX0JPT1RQQVJBTV9WQUxVRT0xCkNPTkZJ R19TRUNVUklUWV9TRUxJTlVYX0RJU0FCTEU9eQpDT05GSUdfU0VDVVJJVFlfU0VMSU5VWF9ERVZF TE9QPXkKQ09ORklHX1NFQ1VSSVRZX1NFTElOVVhfQVZDX1NUQVRTPXkKQ09ORklHX1NFQ1VSSVRZ X1NFTElOVVhfQ0hFQ0tSRVFQUk9UX1ZBTFVFPTEKIyBDT05GSUdfU0VDVVJJVFlfU0VMSU5VWF9Q T0xJQ1lEQl9WRVJTSU9OX01BWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZX1NNQUNLIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlfVE9NT1lPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VD VVJJVFlfQVBQQVJNT1IgaXMgbm90IHNldAojIENPTkZJR19TRUNVUklUWV9ZQU1BIGlzIG5vdCBz ZXQKIyBDT05GSUdfSU1BIGlzIG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfU0VDVVJJVFlfU0VMSU5V WD15CiMgQ09ORklHX0RFRkFVTFRfU0VDVVJJVFlfREFDIGlzIG5vdCBzZXQKQ09ORklHX0RFRkFV TFRfU0VDVVJJVFk9InNlbGludXgiCkNPTkZJR19YT1JfQkxPQ0tTPW0KQ09ORklHX0FTWU5DX0NP UkU9bQpDT05GSUdfQVNZTkNfTUVNQ1BZPW0KQ09ORklHX0FTWU5DX1hPUj1tCkNPTkZJR19BU1lO Q19QUT1tCkNPTkZJR19BU1lOQ19SQUlENl9SRUNPVj1tCkNPTkZJR19BU1lOQ19UWF9ESVNBQkxF X1BRX1ZBTF9ETUE9eQpDT05GSUdfQVNZTkNfVFhfRElTQUJMRV9YT1JfVkFMX0RNQT15CkNPTkZJ R19DUllQVE89eQoKIwojIENyeXB0byBjb3JlIG9yIGhlbHBlcgojCkNPTkZJR19DUllQVE9fRklQ Uz15CkNPTkZJR19DUllQVE9fQUxHQVBJPXkKQ09ORklHX0NSWVBUT19BTEdBUEkyPXkKQ09ORklH X0NSWVBUT19BRUFEPXkKQ09ORklHX0NSWVBUT19BRUFEMj15CkNPTkZJR19DUllQVE9fQkxLQ0lQ SEVSPXkKQ09ORklHX0NSWVBUT19CTEtDSVBIRVIyPXkKQ09ORklHX0NSWVBUT19IQVNIPXkKQ09O RklHX0NSWVBUT19IQVNIMj15CkNPTkZJR19DUllQVE9fUk5HPXkKQ09ORklHX0NSWVBUT19STkcy PXkKQ09ORklHX0NSWVBUT19QQ09NUD1tCkNPTkZJR19DUllQVE9fUENPTVAyPXkKQ09ORklHX0NS WVBUT19NQU5BR0VSPXkKQ09ORklHX0NSWVBUT19NQU5BR0VSMj15CkNPTkZJR19DUllQVE9fVVNF Uj1tCiMgQ09ORklHX0NSWVBUT19NQU5BR0VSX0RJU0FCTEVfVEVTVFMgaXMgbm90IHNldApDT05G SUdfQ1JZUFRPX0dGMTI4TVVMPXkKQ09ORklHX0NSWVBUT19OVUxMPW0KQ09ORklHX0NSWVBUT19Q Q1JZUFQ9bQpDT05GSUdfQ1JZUFRPX1dPUktRVUVVRT15CkNPTkZJR19DUllQVE9fQ1JZUFREPXkK Q09ORklHX0NSWVBUT19BVVRIRU5DPW0KQ09ORklHX0NSWVBUT19URVNUPW0KQ09ORklHX0NSWVBU T19BQkxLX0hFTFBFUl9YODY9eQpDT05GSUdfQ1JZUFRPX0dMVUVfSEVMUEVSX1g4Nj1tCgojCiMg QXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhCiMKQ09ORklHX0NS WVBUT19DQ009bQpDT05GSUdfQ1JZUFRPX0dDTT1tCkNPTkZJR19DUllQVE9fU0VRSVY9eQoKIwoj IEJsb2NrIG1vZGVzCiMKQ09ORklHX0NSWVBUT19DQkM9eQpDT05GSUdfQ1JZUFRPX0NUUj15CkNP TkZJR19DUllQVE9fQ1RTPW0KQ09ORklHX0NSWVBUT19FQ0I9eQpDT05GSUdfQ1JZUFRPX0xSVz15 CkNPTkZJR19DUllQVE9fUENCQz1tCkNPTkZJR19DUllQVE9fWFRTPXkKCiMKIyBIYXNoIG1vZGVz CiMKQ09ORklHX0NSWVBUT19ITUFDPXkKQ09ORklHX0NSWVBUT19YQ0JDPW0KQ09ORklHX0NSWVBU T19WTUFDPW0KCiMKIyBEaWdlc3QKIwpDT05GSUdfQ1JZUFRPX0NSQzMyQz15CkNPTkZJR19DUllQ VE9fQ1JDMzJDX0lOVEVMPW0KQ09ORklHX0NSWVBUT19HSEFTSD1tCkNPTkZJR19DUllQVE9fTUQ0 PW0KQ09ORklHX0NSWVBUT19NRDU9eQpDT05GSUdfQ1JZUFRPX01JQ0hBRUxfTUlDPW0KQ09ORklH X0NSWVBUT19STUQxMjg9bQpDT05GSUdfQ1JZUFRPX1JNRDE2MD1tCkNPTkZJR19DUllQVE9fUk1E MjU2PW0KQ09ORklHX0NSWVBUT19STUQzMjA9bQpDT05GSUdfQ1JZUFRPX1NIQTE9eQpDT05GSUdf Q1JZUFRPX1NIQTFfU1NTRTM9bQpDT05GSUdfQ1JZUFRPX1NIQTI1Nj15CkNPTkZJR19DUllQVE9f U0hBNTEyPW0KQ09ORklHX0NSWVBUT19UR1IxOTI9bQpDT05GSUdfQ1JZUFRPX1dQNTEyPW0KQ09O RklHX0NSWVBUT19HSEFTSF9DTE1VTF9OSV9JTlRFTD1tCgojCiMgQ2lwaGVycwojCkNPTkZJR19D UllQVE9fQUVTPXkKQ09ORklHX0NSWVBUT19BRVNfWDg2XzY0PXkKQ09ORklHX0NSWVBUT19BRVNf TklfSU5URUw9eQpDT05GSUdfQ1JZUFRPX0FOVUJJUz1tCkNPTkZJR19DUllQVE9fQVJDND1tCkNP TkZJR19DUllQVE9fQkxPV0ZJU0g9bQpDT05GSUdfQ1JZUFRPX0JMT1dGSVNIX0NPTU1PTj1tCkNP TkZJR19DUllQVE9fQkxPV0ZJU0hfWDg2XzY0PW0KQ09ORklHX0NSWVBUT19DQU1FTExJQT1tCkNP TkZJR19DUllQVE9fQ0FNRUxMSUFfWDg2XzY0PW0KQ09ORklHX0NSWVBUT19DQVNUNT1tCkNPTkZJ R19DUllQVE9fQ0FTVDY9bQpDT05GSUdfQ1JZUFRPX0RFUz1tCkNPTkZJR19DUllQVE9fRkNSWVBU PW0KQ09ORklHX0NSWVBUT19LSEFaQUQ9bQpDT05GSUdfQ1JZUFRPX1NBTFNBMjA9bQpDT05GSUdf Q1JZUFRPX1NBTFNBMjBfWDg2XzY0PW0KQ09ORklHX0NSWVBUT19TRUVEPW0KQ09ORklHX0NSWVBU T19TRVJQRU5UPW0KQ09ORklHX0NSWVBUT19TRVJQRU5UX1NTRTJfWDg2XzY0PW0KQ09ORklHX0NS WVBUT19TRVJQRU5UX0FWWF9YODZfNjQ9bQpDT05GSUdfQ1JZUFRPX1RFQT1tCkNPTkZJR19DUllQ VE9fVFdPRklTSD1tCkNPTkZJR19DUllQVE9fVFdPRklTSF9DT01NT049bQpDT05GSUdfQ1JZUFRP X1RXT0ZJU0hfWDg2XzY0PW0KQ09ORklHX0NSWVBUT19UV09GSVNIX1g4Nl82NF8zV0FZPW0KQ09O RklHX0NSWVBUT19UV09GSVNIX0FWWF9YODZfNjQ9bQoKIwojIENvbXByZXNzaW9uCiMKQ09ORklH X0NSWVBUT19ERUZMQVRFPW0KQ09ORklHX0NSWVBUT19aTElCPW0KQ09ORklHX0NSWVBUT19MWk89 bQoKIwojIFJhbmRvbSBOdW1iZXIgR2VuZXJhdGlvbgojCkNPTkZJR19DUllQVE9fQU5TSV9DUFJO Rz1tCkNPTkZJR19DUllQVE9fVVNFUl9BUEk9eQpDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX0hBU0g9 eQpDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX1NLQ0lQSEVSPXkKQ09ORklHX0NSWVBUT19IVz15CkNP TkZJR19DUllQVE9fREVWX1BBRExPQ0s9bQpDT05GSUdfQ1JZUFRPX0RFVl9QQURMT0NLX0FFUz1t CkNPTkZJR19DUllQVE9fREVWX1BBRExPQ0tfU0hBPW0KQ09ORklHX0FTWU1NRVRSSUNfS0VZX1RZ UEU9eQpDT05GSUdfQVNZTU1FVFJJQ19QVUJMSUNfS0VZX1NVQlRZUEU9eQpDT05GSUdfUFVCTElD X0tFWV9BTEdPX1JTQT15CkNPTkZJR19YNTA5X0NFUlRJRklDQVRFX1BBUlNFUj15CkNPTkZJR19F RklfU0lHTkFUVVJFX0xJU1RfUEFSU0VSPXkKQ09ORklHX0hBVkVfS1ZNPXkKQ09ORklHX0hBVkVf S1ZNX0lSUUNISVA9eQpDT05GSUdfSEFWRV9LVk1fRVZFTlRGRD15CkNPTkZJR19LVk1fQVBJQ19B UkNISVRFQ1RVUkU9eQpDT05GSUdfS1ZNX01NSU89eQpDT05GSUdfS1ZNX0FTWU5DX1BGPXkKQ09O RklHX0hBVkVfS1ZNX01TST15CkNPTkZJR19WSVJUVUFMSVpBVElPTj15CkNPTkZJR19LVk09bQpD T05GSUdfS1ZNX0lOVEVMPW0KQ09ORklHX0tWTV9BTUQ9bQpDT05GSUdfS1ZNX01NVV9BVURJVD15 CkNPTkZJR19WSE9TVF9ORVQ9bQpDT05GSUdfVENNX1ZIT1NUPW0KQ09ORklHX0JJTkFSWV9QUklO VEY9eQoKIwojIExpYnJhcnkgcm91dGluZXMKIwpDT05GSUdfUkFJRDZfUFE9bQpDT05GSUdfQklU UkVWRVJTRT15CkNPTkZJR19HRU5FUklDX1NUUk5DUFlfRlJPTV9VU0VSPXkKQ09ORklHX0dFTkVS SUNfU1RSTkxFTl9VU0VSPXkKQ09ORklHX0dFTkVSSUNfRklORF9GSVJTVF9CSVQ9eQpDT05GSUdf R0VORVJJQ19QQ0lfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19JT01BUD15CkNPTkZJR19HRU5FUklD X0lPPXkKQ09ORklHX0NSQ19DQ0lUVD1tCkNPTkZJR19DUkMxNj15CkNPTkZJR19DUkNfVDEwRElG PXkKQ09ORklHX0NSQ19JVFVfVD1tCkNPTkZJR19DUkMzMj15CiMgQ09ORklHX0NSQzMyX1NFTEZU RVNUIGlzIG5vdCBzZXQKQ09ORklHX0NSQzMyX1NMSUNFQlk4PXkKIyBDT05GSUdfQ1JDMzJfU0xJ Q0VCWTQgaXMgbm90IHNldAojIENPTkZJR19DUkMzMl9TQVJXQVRFIGlzIG5vdCBzZXQKIyBDT05G SUdfQ1JDMzJfQklUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JDNyBpcyBub3Qgc2V0CkNPTkZJR19M SUJDUkMzMkM9bQpDT05GSUdfQ1JDOD1tCkNPTkZJR19aTElCX0lORkxBVEU9eQpDT05GSUdfWkxJ Ql9ERUZMQVRFPW0KQ09ORklHX0xaT19DT01QUkVTUz15CkNPTkZJR19MWk9fREVDT01QUkVTUz15 CkNPTkZJR19YWl9ERUM9eQpDT05GSUdfWFpfREVDX1g4Nj15CkNPTkZJR19YWl9ERUNfUE9XRVJQ Qz15CkNPTkZJR19YWl9ERUNfSUE2ND15CkNPTkZJR19YWl9ERUNfQVJNPXkKQ09ORklHX1haX0RF Q19BUk1USFVNQj15CkNPTkZJR19YWl9ERUNfU1BBUkM9eQpDT05GSUdfWFpfREVDX0JDSj15CiMg Q09ORklHX1haX0RFQ19URVNUIGlzIG5vdCBzZXQKQ09ORklHX0RFQ09NUFJFU1NfR1pJUD15CkNP TkZJR19ERUNPTVBSRVNTX0JaSVAyPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpNQT15CkNPTkZJR19E RUNPTVBSRVNTX1haPXkKQ09ORklHX0RFQ09NUFJFU1NfTFpPPXkKQ09ORklHX0dFTkVSSUNfQUxM T0NBVE9SPXkKQ09ORklHX1JFRURfU09MT01PTj1tCkNPTkZJR19SRUVEX1NPTE9NT05fRU5DOD15 CkNPTkZJR19SRUVEX1NPTE9NT05fREVDOD15CkNPTkZJR19URVhUU0VBUkNIPXkKQ09ORklHX1RF WFRTRUFSQ0hfS01QPW0KQ09ORklHX1RFWFRTRUFSQ0hfQk09bQpDT05GSUdfVEVYVFNFQVJDSF9G U009bQpDT05GSUdfQlRSRUU9eQpDT05GSUdfSEFTX0lPTUVNPXkKQ09ORklHX0hBU19JT1BPUlQ9 eQpDT05GSUdfSEFTX0RNQT15CkNPTkZJR19DSEVDS19TSUdOQVRVUkU9eQpDT05GSUdfQ1BVX1JN QVA9eQpDT05GSUdfRFFMPXkKQ09ORklHX05MQVRUUj15CkNPTkZJR19BUkNIX0hBU19BVE9NSUM2 NF9ERUNfSUZfUE9TSVRJVkU9eQpDT05GSUdfTFJVX0NBQ0hFPW0KQ09ORklHX0FWRVJBR0U9eQpD T05GSUdfQ0xaX1RBQj15CkNPTkZJR19DT1JESUM9bQojIENPTkZJR19ERFIgaXMgbm90IHNldApD T05GSUdfTVBJTElCPXkKQ09ORklHX09JRF9SRUdJU1RSWT15Cg== --14dae9340959d5aa6f04d7246e42 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 --14dae9340959d5aa6f04d7246e42-- From xen-users-bounces@lists.xen.org Tue Mar 05 03:44:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 03:44: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 1UCimF-0001j5-4i; Tue, 05 Mar 2013 03:42:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCimD-0001j0-WD for xen-users@lists.xen.org; Tue, 05 Mar 2013 03:42:54 +0000 Received: from [85.158.139.83:56971] by server-11.bemta-5.messagelabs.com id FF/7B-27486-DB965315; Tue, 05 Mar 2013 03:42:53 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1362454971!23610942!1 X-Originating-IP: [209.85.223.172] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31896 invoked from network); 5 Mar 2013 03:42:52 -0000 Received: from mail-ie0-f172.google.com (HELO mail-ie0-f172.google.com) (209.85.223.172) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 03:42:52 -0000 Received: by mail-ie0-f172.google.com with SMTP id c10so7282723ieb.31 for ; Mon, 04 Mar 2013 19:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=/X0U0USimWPIF5X+VVN7aPZdRARarAkBVDil9GWLzf0=; b=cFwEDTZq4Yq17haDG5LOizNS9Y8U9YYFMCOTPELbFjmip5aRe6fnhdwM5wsmD8OPtr 0d2HQ/qIur6LTEaaD96WtE+D3NgSwzQ8PpbPZBQC6r2oe+croQbewFevK59tUr/OTosO eND5onjR09JE8gd9pMWlOgv7rV5xd25MvzAA1ukBa+CD9JtqyjG4WkPZO7FYEqysW2el IIchQDAs0t1l/2n14l5qN/qrm3luH9yJThXVOsHdny+2lautumkAA0Tb9lzVEldSfOaP h47Bd1CUZ42oDcZr0Bg6UcqV2zjK7FhJepa8ZIosfGhywRx8nR0AJ4ypZUtCK/jvuE18 3oIw== MIME-Version: 1.0 X-Received: by 10.50.196.130 with SMTP id im2mr4553111igc.90.1362454970386; Mon, 04 Mar 2013 19:42:50 -0800 (PST) Received: by 10.42.41.5 with HTTP; Mon, 4 Mar 2013 19:42:50 -0800 (PST) Date: Mon, 4 Mar 2013 20:42:50 -0700 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============0967088119958665017==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0967088119958665017== Content-Type: multipart/alternative; boundary=14dae9341071884f1204d725440c --14dae9341071884f1204d725440c Content-Type: text/plain; charset=ISO-8859-1 Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had compiled xen on up to date arch linux and is willing to share package. --14dae9341071884f1204d725440c Content-Type: text/html; charset=ISO-8859-1 Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had compiled xen on up to date arch linux and is willing to share package.
--14dae9341071884f1204d725440c-- --===============0967088119958665017== 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 --===============0967088119958665017==-- From xen-users-bounces@lists.xen.org Tue Mar 05 03:44:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 03:44: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 1UCimF-0001j5-4i; Tue, 05 Mar 2013 03:42:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCimD-0001j0-WD for xen-users@lists.xen.org; Tue, 05 Mar 2013 03:42:54 +0000 Received: from [85.158.139.83:56971] by server-11.bemta-5.messagelabs.com id FF/7B-27486-DB965315; Tue, 05 Mar 2013 03:42:53 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1362454971!23610942!1 X-Originating-IP: [209.85.223.172] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31896 invoked from network); 5 Mar 2013 03:42:52 -0000 Received: from mail-ie0-f172.google.com (HELO mail-ie0-f172.google.com) (209.85.223.172) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 03:42:52 -0000 Received: by mail-ie0-f172.google.com with SMTP id c10so7282723ieb.31 for ; Mon, 04 Mar 2013 19:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=/X0U0USimWPIF5X+VVN7aPZdRARarAkBVDil9GWLzf0=; b=cFwEDTZq4Yq17haDG5LOizNS9Y8U9YYFMCOTPELbFjmip5aRe6fnhdwM5wsmD8OPtr 0d2HQ/qIur6LTEaaD96WtE+D3NgSwzQ8PpbPZBQC6r2oe+croQbewFevK59tUr/OTosO eND5onjR09JE8gd9pMWlOgv7rV5xd25MvzAA1ukBa+CD9JtqyjG4WkPZO7FYEqysW2el IIchQDAs0t1l/2n14l5qN/qrm3luH9yJThXVOsHdny+2lautumkAA0Tb9lzVEldSfOaP h47Bd1CUZ42oDcZr0Bg6UcqV2zjK7FhJepa8ZIosfGhywRx8nR0AJ4ypZUtCK/jvuE18 3oIw== MIME-Version: 1.0 X-Received: by 10.50.196.130 with SMTP id im2mr4553111igc.90.1362454970386; Mon, 04 Mar 2013 19:42:50 -0800 (PST) Received: by 10.42.41.5 with HTTP; Mon, 4 Mar 2013 19:42:50 -0800 (PST) Date: Mon, 4 Mar 2013 20:42:50 -0700 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============0967088119958665017==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0967088119958665017== Content-Type: multipart/alternative; boundary=14dae9341071884f1204d725440c --14dae9341071884f1204d725440c Content-Type: text/plain; charset=ISO-8859-1 Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had compiled xen on up to date arch linux and is willing to share package. --14dae9341071884f1204d725440c Content-Type: text/html; charset=ISO-8859-1 Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had compiled xen on up to date arch linux and is willing to share package.
--14dae9341071884f1204d725440c-- --===============0967088119958665017== 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 --===============0967088119958665017==-- From xen-users-bounces@lists.xen.org Tue Mar 05 04:16:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:16: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 1UCjI5-0002mz-Vn; Tue, 05 Mar 2013 04:15:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjI4-0002mu-1z for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:15:48 +0000 Received: from [193.109.254.147:38146] by server-6.bemta-14.messagelabs.com id D3/19-31180-37175315; Tue, 05 Mar 2013 04:15:47 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1362456943!8491554!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwOTI=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30685 invoked from network); 5 Mar 2013 04:15:46 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:15:46 -0000 X-IronPort-AV: E=Sophos;i="4.84,784,1355097600"; d="scan'208";a="10568064" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 05 Mar 2013 04:15:28 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Mon, 4 Mar 2013 23:15:28 -0500 Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UCjHj-0003Sl-J0; Tue, 05 Mar 2013 04:15:28 +0000 Message-ID: <1362456768.8941.29.camel@hastur.hellion.org.uk> From: Ian Campbell To: Matthias Date: Tue, 5 Mar 2013 04:12:48 +0000 In-Reply-To: References: X-Mailer: Evolution 3.4.4-2 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Qemu confusion X-BeenThere: xen-users@lists.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, 2013-03-04 at 21:07 +0000, Matthias wrote: > Hi everybody, > > I'm currently a little confused about the status of the different qemu > trees for xen unstable.. from what I've gathered so far, there are 3 > different trees: > > 1) Qemu-Xen-Unstable (Repo: > http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-unstable.git;a=shortlog;h=refs/heads/master > ) > This is the default repository which is download while xen-unstable is build Right. This is the thing called "qemu-xen-traditional" in an xl configuration file. > 2) Qemu-Upstream-Unstable (Repo: > http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-unstable.git;a=shortlog;h=refs/heads/master > ) > I don't really know what this is. This is the Xen stable branch of upstream qemu, which corresponds to "qemu-xen" in an xl configuration file. It is essentially the upstream qemu stable branch with Xen specific stable backports > 3) Qemu Upstream (Repo: git://git.qemu.org/qemu.git ) > This is the 'real' Qemu repository from the Qemu project. Not sure whast you mean by "real". This is the upstream qemu.git tree, which is upstream for the #2 tree above. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 05 04:16:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:16: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 1UCjI5-0002mz-Vn; Tue, 05 Mar 2013 04:15:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjI4-0002mu-1z for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:15:48 +0000 Received: from [193.109.254.147:38146] by server-6.bemta-14.messagelabs.com id D3/19-31180-37175315; Tue, 05 Mar 2013 04:15:47 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1362456943!8491554!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwOTI=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30685 invoked from network); 5 Mar 2013 04:15:46 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:15:46 -0000 X-IronPort-AV: E=Sophos;i="4.84,784,1355097600"; d="scan'208";a="10568064" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 05 Mar 2013 04:15:28 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Mon, 4 Mar 2013 23:15:28 -0500 Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UCjHj-0003Sl-J0; Tue, 05 Mar 2013 04:15:28 +0000 Message-ID: <1362456768.8941.29.camel@hastur.hellion.org.uk> From: Ian Campbell To: Matthias Date: Tue, 5 Mar 2013 04:12:48 +0000 In-Reply-To: References: X-Mailer: Evolution 3.4.4-2 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Qemu confusion X-BeenThere: xen-users@lists.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, 2013-03-04 at 21:07 +0000, Matthias wrote: > Hi everybody, > > I'm currently a little confused about the status of the different qemu > trees for xen unstable.. from what I've gathered so far, there are 3 > different trees: > > 1) Qemu-Xen-Unstable (Repo: > http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-unstable.git;a=shortlog;h=refs/heads/master > ) > This is the default repository which is download while xen-unstable is build Right. This is the thing called "qemu-xen-traditional" in an xl configuration file. > 2) Qemu-Upstream-Unstable (Repo: > http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-unstable.git;a=shortlog;h=refs/heads/master > ) > I don't really know what this is. This is the Xen stable branch of upstream qemu, which corresponds to "qemu-xen" in an xl configuration file. It is essentially the upstream qemu stable branch with Xen specific stable backports > 3) Qemu Upstream (Repo: git://git.qemu.org/qemu.git ) > This is the 'real' Qemu repository from the Qemu project. Not sure whast you mean by "real". This is the upstream qemu.git tree, which is upstream for the #2 tree above. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 05 04:26:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:26: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 1UCjRS-0003El-OC; Tue, 05 Mar 2013 04:25:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjRR-0003Ee-3F for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:25:29 +0000 Received: from [85.158.139.211:53927] by server-16.bemta-5.messagelabs.com id 63/D1-02543-8B375315; Tue, 05 Mar 2013 04:25:28 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1362457524!18467519!1 X-Originating-IP: [209.85.128.178] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7033 invoked from network); 5 Mar 2013 04:25:26 -0000 Received: from mail-ve0-f178.google.com (HELO mail-ve0-f178.google.com) (209.85.128.178) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:25:26 -0000 Received: by mail-ve0-f178.google.com with SMTP id db10so5414417veb.9 for ; Mon, 04 Mar 2013 20:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=t5ob0sw9A4JjvdNb6Wa/qOidG0woCU8rjLaBxiTc5js=; b=Y1KOsQlAHaViF/vIkMB8pL+NxuiBN41aPNlc5ArGwnY6cxC7y0ojJn1uvp0RjXbmvB IzH1wWOam8KIkPpNr3V8LPsmGtv+j7RrzDPTqKBJnwaw8KDYsbgrOdd7/NBZ4yLQBwYH ct/Yr7/ouJneHVER7LJzvVjw7kngJNziA1efN92BOkX8kG8NdvvHGeIB4C9ae6v3X4MF L6TQ/XM3SR4yqiM3GoNq9olpzAOn5rnuN2sePxC7d9paqGv8+8X7Cvb12F/VGo6p9Pmw jC2D/br5n1WZKvIpWPR2gMQVmDdK+n3AVwHJe/IwnK0RvzO5qEFRpKcPnhXeLLvm2OqZ 5dYw== MIME-Version: 1.0 X-Received: by 10.220.39.69 with SMTP id f5mr8985364vce.45.1362457524482; Mon, 04 Mar 2013 20:25:24 -0800 (PST) Received: by 10.58.169.100 with HTTP; Mon, 4 Mar 2013 20:25:24 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 23:25:24 -0500 Message-ID: From: Casey DeLorme To: Guilherme Suzuki Cc: "xen-users@lists.xen.org" , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5085851249447375055==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5085851249447375055== Content-Type: multipart/alternative; boundary=bcaec54eebbac4bbcf04d725dc31 --bcaec54eebbac4bbcf04d725dc31 Content-Type: text/plain; charset=UTF-8 Hello Guilherme, was following your exchange and wanted to see how this turned out. Secondary Passthrough works with AMD, but for primary you need to apply custom patches. There is another email chain circling the mailing list with links to some fresh patches. As Matthias mentioned, passthrough is working, but I am quite certain FLR is interfering which has led to driver related BSoD's. My understanding is that FLR allows a virtual machine to issue a reset to a piece of hardware, and without it that device's state cannot be cleared. Consumer cards do not come with FLR, and no patch for this is available. What this means is that when you first boot your virtual machine, the card is initialized and performs just fine. When you shut down Windows 7 or XP and start either one back up you may encounter a BSoD. This is because the card is being initialized a second time. For me and many others rebooting has led to degraded performance instead of a BSoD, which can be fixed by manually ejecting the card with the "safely eject media" tool. However experiences vary. I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it is working just fine. I have had this working in both Windows 7 and Windows 8, but I have no experience with XP. Keeping in mind that your experience may vary, here is my route to success: First, backup your Windows HVM before attempting to pass any PCI devices. Make certain that Dom0 has been freshly booted to ensure that the PCI card only initializes once. The leading cause to trouble from my experience is passing the card more than once at any point during the installation, which leads to a BSoD during the process OR a badly damaged install which can range from BSoD on reboot only to gradual buggy experiences and BSoD's on first boot. Prior to passing the PCI card to Windows 7 or Windows 8 be sure to turn off all automatic driver installation settings (there are more than one). If using Windows 8 do not add the card to the configuration, instead let it boot and then use `xl pci-attach`, since Windows 8 will attempt to install a driver at boot time and reboot without ever displaying anything on screen. Once the installation has completed it may ask you to reboot, instead shut down Windows and reboot Dom0 then start Windows again. This avoids any post-install processes from attempting to communicate with the card in its buggy (previously initialized) state, which could muck up the installation. I have used the above rules successfully more than a dozen times now, and never once had a BSoD when I followed them. Finally, the reason for the backup at the beginning is that anytime I failed to follow the above rules, I was not able to fix the problem by removing and installing the drivers again. In fact, that never once worked and I wasted a few days trying several times without success. So in short, if you fail don't bother removing the drivers and trying again, instead restore from an image backup of the machine that has never once seen your PCI device. I hope this information helps. Sincerely, Casey DeLorme On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki wrote: > Matthias, hi! > > I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the same on > and on (*VGA passthru worked only as secondary device and dom0 freshly > rebooted*). As requested, I'm sending you the hvm configuration files > from windows-xp and windows-7, my lspci -vv, uname and the kernel > configuration file. > > Do you have any idea how I can make this work? > > > > 2013/3/4 Guilherme Suzuki > >> Alright! >> >> I'm gonna try catalyst 12-10 (after deinstalling and checking if the >> passthru works rebooting and so on). >> >> I'll send my domU config as soon as I get home. >> >> One more question: does it matter if I use intel onboard graphics with >> the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason >> primary VGA passthru did not work... >> >> Thx, xen guys are awesome! =D >> >> On Mar 4, 2013 2:07 PM, "Matthias" >> wrote: >> >> Hi, >> >> good news, since you said your winxp was able to boot with vga >> passthrough just fine, your FLR seems to work fine and this might >> 'only' be a driver-related problem. >> >> What you can do is deinstall your catalyst drivers. After rebooting, >> Win7 will fallback on a windows-standard driver for the vga but when >> it correctly says the vga name (like ATI Radeion HD whatever Series), >> it actually is falling back to an older catalyst version which is >> shipped per default with windows. I have found this much more stable >> on reboots then the newest driver. Also, deinstall Catalyst / Vision >> control center and at best everything the catalyst installer lets you >> deinstall. >> >> If vga passthrough works without all the drivers and you really want >> the latest and greatest catalyst, i recommend not using the latest >> 13-1 because it creates a similar behavior you mentioned on my >> machine. But catalyst 12-10 seems to work fine, so i would advice you >> trying that one. >> >> >> If it still doesn't work with deinstalled drivers, we can try a patch >> i'm currently testing.. But this the patch is somewhat complicated to >> install, let's stick with the simple things for the moment. >> >> Also, your domU config still would be of help ruling out some >> misconfiguration there.. >> >> >> >> 2013/3/4 Guilherme Suzuki : >> >> > Sorry (hit send). >> > >> > So, the radeon device tells it couldnt start itself (code 10) and cirrus >> > d... >> >> > > > -- > Grato, > > ** *Guilherme Suzuki* > Consultor em TI para projetos Microsoft > *http://www.guilhermesuzuki.com* > 11 - 992360535 > 11 - 20990757 > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --bcaec54eebbac4bbcf04d725dc31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Guilherme, was following your exchange and want= ed to see how this turned out.

Secondary Passthrou= gh works with AMD, but for primary you need to apply custom patches. =C2=A0= There is another email chain circling the mailing list with links to some f= resh patches.

As Matthias mentioned, passthrough is working, but I am= quite certain FLR is interfering which has led to driver related BSoD'= s.

My understanding is that FLR allows a virtual m= achine to issue a reset to a piece of hardware, and without it that device&= #39;s state cannot be cleared. =C2=A0Consumer cards do not come with FLR, a= nd no patch for this is available.

What this means is that when you first boot your virtua= l machine, the card is initialized and performs just fine. =C2=A0When you s= hut down Windows 7 or XP and start either one back up you may encounter a B= SoD. =C2=A0This is because the card is being initialized a second time.

For me and many others rebooting has led to degraded pe= rformance instead of a BSoD, which can be fixed by manually ejecting the ca= rd with the "safely eject media" tool. =C2=A0However experiences = vary.


I am using an AMD Radeon HD 6870 with 12= .10 catalyst drivers, and it is working just fine. =C2=A0I have had this wo= rking in both Windows 7 and Windows 8, but I have no experience with XP.

Keeping in mind that your experience may vary, here is = my route to success:

First, backup your Windows HV= M before attempting to pass any PCI devices.

Make = certain that Dom0 has been freshly booted to ensure that the PCI card only = initializes once. =C2=A0The leading cause to trouble from my experience is = passing the card more than once at any point during the installation, which= leads to a BSoD during the process OR a badly damaged install which can ra= nge from BSoD on reboot only to gradual buggy experiences and BSoD's on= first boot.

Prior to passing the PCI card to Windows 7 or Win= dows 8 be sure to turn off all automatic driver installation settings (ther= e are more than one). =C2=A0If using Windows 8 do not add the card to the c= onfiguration, instead let it boot and then use `xl pci-attach`, since Windo= ws 8 will attempt to install a driver at boot time and reboot without ever = displaying anything on screen.

Once the installation has completed it may ask you to r= eboot, instead shut down Windows and reboot Dom0 then start Windows again. = =C2=A0This avoids any post-install processes from attempting to communicate= with the card in its buggy (previously initialized) state, which could muc= k up the installation.

I have used the above rules successfully more than a do= zen times now, and never once had a BSoD when I followed them.
Finally, the reason for the backup at the beginning is that an= ytime I failed to follow the above rules, I was not able to fix the problem= by removing and installing the drivers again. =C2=A0In fact, that never on= ce worked and I wasted a few days trying several times without success. =C2= =A0So in short, if you fail don't bother removing the drivers and tryin= g again, instead restore from an image backup of the machine that has never= once seen your PCI device.


I hope this information helps.

Sincerely,

Casey DeLorme


On Mon, Mar= 4, 2013 at 9:43 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
Matthias, hi!
=
I've tried Catalyst 12.10 and even 12.1, but xen behavior kep= t the same on and on (VGA passthru worked only as secondary device and d= om0 freshly rebooted). As requested, I'm sending you the hvm config= uration files from windows-xp and windows-7, my lspci -vv, uname and the ke= rnel configuration file.

Do you have any idea how I can make this work?

=


2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>= ;

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the= passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with t= he dom0 and xen-pciback(radeon device pci)? Cause that would be the reason = primary VGA passthru did not work...

Thx, xen guys are awesome! =3DD

On Mar 4, 2013 2:07 PM, "Ma= tthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch i'm currently testing.. But this the patch is somewhat complicated to install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Sorry (hit send).
>
> So, the radeon device tells= it couldnt start itself (code 10) and cirrus
> d...




--
Grato,
<= br>
= Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=C2=A0

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--bcaec54eebbac4bbcf04d725dc31-- --===============5085851249447375055== 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 --===============5085851249447375055==-- From xen-users-bounces@lists.xen.org Tue Mar 05 04:26:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:26: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 1UCjRS-0003El-OC; Tue, 05 Mar 2013 04:25:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjRR-0003Ee-3F for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:25:29 +0000 Received: from [85.158.139.211:53927] by server-16.bemta-5.messagelabs.com id 63/D1-02543-8B375315; Tue, 05 Mar 2013 04:25:28 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1362457524!18467519!1 X-Originating-IP: [209.85.128.178] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7033 invoked from network); 5 Mar 2013 04:25:26 -0000 Received: from mail-ve0-f178.google.com (HELO mail-ve0-f178.google.com) (209.85.128.178) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:25:26 -0000 Received: by mail-ve0-f178.google.com with SMTP id db10so5414417veb.9 for ; Mon, 04 Mar 2013 20:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=t5ob0sw9A4JjvdNb6Wa/qOidG0woCU8rjLaBxiTc5js=; b=Y1KOsQlAHaViF/vIkMB8pL+NxuiBN41aPNlc5ArGwnY6cxC7y0ojJn1uvp0RjXbmvB IzH1wWOam8KIkPpNr3V8LPsmGtv+j7RrzDPTqKBJnwaw8KDYsbgrOdd7/NBZ4yLQBwYH ct/Yr7/ouJneHVER7LJzvVjw7kngJNziA1efN92BOkX8kG8NdvvHGeIB4C9ae6v3X4MF L6TQ/XM3SR4yqiM3GoNq9olpzAOn5rnuN2sePxC7d9paqGv8+8X7Cvb12F/VGo6p9Pmw jC2D/br5n1WZKvIpWPR2gMQVmDdK+n3AVwHJe/IwnK0RvzO5qEFRpKcPnhXeLLvm2OqZ 5dYw== MIME-Version: 1.0 X-Received: by 10.220.39.69 with SMTP id f5mr8985364vce.45.1362457524482; Mon, 04 Mar 2013 20:25:24 -0800 (PST) Received: by 10.58.169.100 with HTTP; Mon, 4 Mar 2013 20:25:24 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 23:25:24 -0500 Message-ID: From: Casey DeLorme To: Guilherme Suzuki Cc: "xen-users@lists.xen.org" , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5085851249447375055==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5085851249447375055== Content-Type: multipart/alternative; boundary=bcaec54eebbac4bbcf04d725dc31 --bcaec54eebbac4bbcf04d725dc31 Content-Type: text/plain; charset=UTF-8 Hello Guilherme, was following your exchange and wanted to see how this turned out. Secondary Passthrough works with AMD, but for primary you need to apply custom patches. There is another email chain circling the mailing list with links to some fresh patches. As Matthias mentioned, passthrough is working, but I am quite certain FLR is interfering which has led to driver related BSoD's. My understanding is that FLR allows a virtual machine to issue a reset to a piece of hardware, and without it that device's state cannot be cleared. Consumer cards do not come with FLR, and no patch for this is available. What this means is that when you first boot your virtual machine, the card is initialized and performs just fine. When you shut down Windows 7 or XP and start either one back up you may encounter a BSoD. This is because the card is being initialized a second time. For me and many others rebooting has led to degraded performance instead of a BSoD, which can be fixed by manually ejecting the card with the "safely eject media" tool. However experiences vary. I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it is working just fine. I have had this working in both Windows 7 and Windows 8, but I have no experience with XP. Keeping in mind that your experience may vary, here is my route to success: First, backup your Windows HVM before attempting to pass any PCI devices. Make certain that Dom0 has been freshly booted to ensure that the PCI card only initializes once. The leading cause to trouble from my experience is passing the card more than once at any point during the installation, which leads to a BSoD during the process OR a badly damaged install which can range from BSoD on reboot only to gradual buggy experiences and BSoD's on first boot. Prior to passing the PCI card to Windows 7 or Windows 8 be sure to turn off all automatic driver installation settings (there are more than one). If using Windows 8 do not add the card to the configuration, instead let it boot and then use `xl pci-attach`, since Windows 8 will attempt to install a driver at boot time and reboot without ever displaying anything on screen. Once the installation has completed it may ask you to reboot, instead shut down Windows and reboot Dom0 then start Windows again. This avoids any post-install processes from attempting to communicate with the card in its buggy (previously initialized) state, which could muck up the installation. I have used the above rules successfully more than a dozen times now, and never once had a BSoD when I followed them. Finally, the reason for the backup at the beginning is that anytime I failed to follow the above rules, I was not able to fix the problem by removing and installing the drivers again. In fact, that never once worked and I wasted a few days trying several times without success. So in short, if you fail don't bother removing the drivers and trying again, instead restore from an image backup of the machine that has never once seen your PCI device. I hope this information helps. Sincerely, Casey DeLorme On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki wrote: > Matthias, hi! > > I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the same on > and on (*VGA passthru worked only as secondary device and dom0 freshly > rebooted*). As requested, I'm sending you the hvm configuration files > from windows-xp and windows-7, my lspci -vv, uname and the kernel > configuration file. > > Do you have any idea how I can make this work? > > > > 2013/3/4 Guilherme Suzuki > >> Alright! >> >> I'm gonna try catalyst 12-10 (after deinstalling and checking if the >> passthru works rebooting and so on). >> >> I'll send my domU config as soon as I get home. >> >> One more question: does it matter if I use intel onboard graphics with >> the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason >> primary VGA passthru did not work... >> >> Thx, xen guys are awesome! =D >> >> On Mar 4, 2013 2:07 PM, "Matthias" >> wrote: >> >> Hi, >> >> good news, since you said your winxp was able to boot with vga >> passthrough just fine, your FLR seems to work fine and this might >> 'only' be a driver-related problem. >> >> What you can do is deinstall your catalyst drivers. After rebooting, >> Win7 will fallback on a windows-standard driver for the vga but when >> it correctly says the vga name (like ATI Radeion HD whatever Series), >> it actually is falling back to an older catalyst version which is >> shipped per default with windows. I have found this much more stable >> on reboots then the newest driver. Also, deinstall Catalyst / Vision >> control center and at best everything the catalyst installer lets you >> deinstall. >> >> If vga passthrough works without all the drivers and you really want >> the latest and greatest catalyst, i recommend not using the latest >> 13-1 because it creates a similar behavior you mentioned on my >> machine. But catalyst 12-10 seems to work fine, so i would advice you >> trying that one. >> >> >> If it still doesn't work with deinstalled drivers, we can try a patch >> i'm currently testing.. But this the patch is somewhat complicated to >> install, let's stick with the simple things for the moment. >> >> Also, your domU config still would be of help ruling out some >> misconfiguration there.. >> >> >> >> 2013/3/4 Guilherme Suzuki : >> >> > Sorry (hit send). >> > >> > So, the radeon device tells it couldnt start itself (code 10) and cirrus >> > d... >> >> > > > -- > Grato, > > ** *Guilherme Suzuki* > Consultor em TI para projetos Microsoft > *http://www.guilhermesuzuki.com* > 11 - 992360535 > 11 - 20990757 > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --bcaec54eebbac4bbcf04d725dc31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Guilherme, was following your exchange and want= ed to see how this turned out.

Secondary Passthrou= gh works with AMD, but for primary you need to apply custom patches. =C2=A0= There is another email chain circling the mailing list with links to some f= resh patches.

As Matthias mentioned, passthrough is working, but I am= quite certain FLR is interfering which has led to driver related BSoD'= s.

My understanding is that FLR allows a virtual m= achine to issue a reset to a piece of hardware, and without it that device&= #39;s state cannot be cleared. =C2=A0Consumer cards do not come with FLR, a= nd no patch for this is available.

What this means is that when you first boot your virtua= l machine, the card is initialized and performs just fine. =C2=A0When you s= hut down Windows 7 or XP and start either one back up you may encounter a B= SoD. =C2=A0This is because the card is being initialized a second time.

For me and many others rebooting has led to degraded pe= rformance instead of a BSoD, which can be fixed by manually ejecting the ca= rd with the "safely eject media" tool. =C2=A0However experiences = vary.


I am using an AMD Radeon HD 6870 with 12= .10 catalyst drivers, and it is working just fine. =C2=A0I have had this wo= rking in both Windows 7 and Windows 8, but I have no experience with XP.

Keeping in mind that your experience may vary, here is = my route to success:

First, backup your Windows HV= M before attempting to pass any PCI devices.

Make = certain that Dom0 has been freshly booted to ensure that the PCI card only = initializes once. =C2=A0The leading cause to trouble from my experience is = passing the card more than once at any point during the installation, which= leads to a BSoD during the process OR a badly damaged install which can ra= nge from BSoD on reboot only to gradual buggy experiences and BSoD's on= first boot.

Prior to passing the PCI card to Windows 7 or Win= dows 8 be sure to turn off all automatic driver installation settings (ther= e are more than one). =C2=A0If using Windows 8 do not add the card to the c= onfiguration, instead let it boot and then use `xl pci-attach`, since Windo= ws 8 will attempt to install a driver at boot time and reboot without ever = displaying anything on screen.

Once the installation has completed it may ask you to r= eboot, instead shut down Windows and reboot Dom0 then start Windows again. = =C2=A0This avoids any post-install processes from attempting to communicate= with the card in its buggy (previously initialized) state, which could muc= k up the installation.

I have used the above rules successfully more than a do= zen times now, and never once had a BSoD when I followed them.
Finally, the reason for the backup at the beginning is that an= ytime I failed to follow the above rules, I was not able to fix the problem= by removing and installing the drivers again. =C2=A0In fact, that never on= ce worked and I wasted a few days trying several times without success. =C2= =A0So in short, if you fail don't bother removing the drivers and tryin= g again, instead restore from an image backup of the machine that has never= once seen your PCI device.


I hope this information helps.

Sincerely,

Casey DeLorme


On Mon, Mar= 4, 2013 at 9:43 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
Matthias, hi!
=
I've tried Catalyst 12.10 and even 12.1, but xen behavior kep= t the same on and on (VGA passthru worked only as secondary device and d= om0 freshly rebooted). As requested, I'm sending you the hvm config= uration files from windows-xp and windows-7, my lspci -vv, uname and the ke= rnel configuration file.

Do you have any idea how I can make this work?

=


2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>= ;

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the= passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with t= he dom0 and xen-pciback(radeon device pci)? Cause that would be the reason = primary VGA passthru did not work...

Thx, xen guys are awesome! =3DD

On Mar 4, 2013 2:07 PM, "Ma= tthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch i'm currently testing.. But this the patch is somewhat complicated to install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:

> Sorry (hit send).
>
> So, the radeon device tells= it couldnt start itself (code 10) and cirrus
> d...




--
Grato,
<= br>
= Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=C2=A0

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--bcaec54eebbac4bbcf04d725dc31-- --===============5085851249447375055== 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 --===============5085851249447375055==-- From xen-users-bounces@lists.xen.org Tue Mar 05 04:32:57 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:32: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 1UCjXn-0003YF-SD; Tue, 05 Mar 2013 04:32:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjXm-0003Y9-MQ for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:32:02 +0000 Received: from [85.158.139.211:35895] by server-16.bemta-5.messagelabs.com id F6/25-02543-14575315; Tue, 05 Mar 2013 04:32:01 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1362457921!18467936!1 X-Originating-IP: [74.125.82.41] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23261 invoked from network); 5 Mar 2013 04:32:01 -0000 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:32:01 -0000 Received: by mail-wg0-f41.google.com with SMTP id ds1so2321635wgb.4 for ; Mon, 04 Mar 2013 20:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1u8EnIC21SXdDjDwhiglcgMvfKP4a3WaSxZRIB4CyIM=; b=UAc5kYKNWxbkpRO5GcfmiCwXyzCGk7RpXichJgQqn7wY2kUr5zrcbq0kJpNhL0ZYdf 2hdUCkRwHOUjqIP17sHjpOi9WJ9v30YZXGOXgxBOlnS3XMNAQFVW8CgNHZ/UCP9i/BY1 6OgVn2yWFI0AMy/ehHGYZPrgqHyFYgNQ3BF2+Cg2Jo+vx+OvPrU8fp4jSCWnDk36VJ92 9tkWxNT0EbH6eYosYH2Gmw/+bQw394EgTVaBD7MxLf+8WtVLlUjBGinkO11ftKa+9PiK k5bZcGakb85agf9/XnLIskgDmJTOFyO8CYQtKjq8L2tOGON4/L2jwnJn1ZBaqC5Quzft +b3Q== X-Received: by 10.194.7.196 with SMTP id l4mr36255489wja.28.1362457916621; Mon, 04 Mar 2013 20:31:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Mon, 4 Mar 2013 20:31:36 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Mon, 4 Mar 2013 23:31:36 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============1423766357381919612==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1423766357381919612== Content-Type: multipart/alternative; boundary=047d7b5d4576244b6004d725f43d --047d7b5d4576244b6004d725f43d Content-Type: text/plain; charset=UTF-8 On Mon, Mar 4, 2013 at 10:42 PM, jacek burghardt wrote: > Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had > compiled xen on up to date arch linux and is willing to share package. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > There's a nice AUR package that I've been using without problems. Link: https://aur.archlinux.org/packages/xen-hg-unstable/ I've been running it on Arch with no major issues. I just finished doing a pretty thorough rewrite of the Xen article on the archwiki. https://wiki.archlinux.org/index.php/Xen Let me know if there's anything missing from that article, as I haven't done a full install from scratch in a while. -- --Zootboy Sent from some sort of computing device. --047d7b5d4576244b6004d725f43d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 4, 2013 at 10:42 PM, jacek burghardt= <jaceksburghardt@gmail.com> wrote:
Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had com= piled xen on up to date arch linux and is willing to share package.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

There's a nice AUR packa= ge that I've been using without problems. Link: https://aur.archlinux.org/packages= /xen-hg-unstable/

I've been running it on Arch with no major issues. I just finished = doing a pretty thorough rewrite of the Xen article on the archwiki. https://wiki.archlinux.org/in= dex.php/Xen

Let me know if there's anything missing from that article, as I hav= en't done a full install from scratch in a while.

=
--
--Zootboy

Sent from some sort of computing device.<= /div>
--047d7b5d4576244b6004d725f43d-- --===============1423766357381919612== 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 --===============1423766357381919612==-- From xen-users-bounces@lists.xen.org Tue Mar 05 04:32:57 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:32: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 1UCjXn-0003YF-SD; Tue, 05 Mar 2013 04:32:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjXm-0003Y9-MQ for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:32:02 +0000 Received: from [85.158.139.211:35895] by server-16.bemta-5.messagelabs.com id F6/25-02543-14575315; Tue, 05 Mar 2013 04:32:01 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1362457921!18467936!1 X-Originating-IP: [74.125.82.41] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23261 invoked from network); 5 Mar 2013 04:32:01 -0000 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:32:01 -0000 Received: by mail-wg0-f41.google.com with SMTP id ds1so2321635wgb.4 for ; Mon, 04 Mar 2013 20:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1u8EnIC21SXdDjDwhiglcgMvfKP4a3WaSxZRIB4CyIM=; b=UAc5kYKNWxbkpRO5GcfmiCwXyzCGk7RpXichJgQqn7wY2kUr5zrcbq0kJpNhL0ZYdf 2hdUCkRwHOUjqIP17sHjpOi9WJ9v30YZXGOXgxBOlnS3XMNAQFVW8CgNHZ/UCP9i/BY1 6OgVn2yWFI0AMy/ehHGYZPrgqHyFYgNQ3BF2+Cg2Jo+vx+OvPrU8fp4jSCWnDk36VJ92 9tkWxNT0EbH6eYosYH2Gmw/+bQw394EgTVaBD7MxLf+8WtVLlUjBGinkO11ftKa+9PiK k5bZcGakb85agf9/XnLIskgDmJTOFyO8CYQtKjq8L2tOGON4/L2jwnJn1ZBaqC5Quzft +b3Q== X-Received: by 10.194.7.196 with SMTP id l4mr36255489wja.28.1362457916621; Mon, 04 Mar 2013 20:31:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Mon, 4 Mar 2013 20:31:36 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Mon, 4 Mar 2013 23:31:36 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============1423766357381919612==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1423766357381919612== Content-Type: multipart/alternative; boundary=047d7b5d4576244b6004d725f43d --047d7b5d4576244b6004d725f43d Content-Type: text/plain; charset=UTF-8 On Mon, Mar 4, 2013 at 10:42 PM, jacek burghardt wrote: > Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had > compiled xen on up to date arch linux and is willing to share package. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > There's a nice AUR package that I've been using without problems. Link: https://aur.archlinux.org/packages/xen-hg-unstable/ I've been running it on Arch with no major issues. I just finished doing a pretty thorough rewrite of the Xen article on the archwiki. https://wiki.archlinux.org/index.php/Xen Let me know if there's anything missing from that article, as I haven't done a full install from scratch in a while. -- --Zootboy Sent from some sort of computing device. --047d7b5d4576244b6004d725f43d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 4, 2013 at 10:42 PM, jacek burghardt= <jaceksburghardt@gmail.com> wrote:
Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had com= piled xen on up to date arch linux and is willing to share package.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

There's a nice AUR packa= ge that I've been using without problems. Link: https://aur.archlinux.org/packages= /xen-hg-unstable/

I've been running it on Arch with no major issues. I just finished = doing a pretty thorough rewrite of the Xen article on the archwiki. https://wiki.archlinux.org/in= dex.php/Xen

Let me know if there's anything missing from that article, as I hav= en't done a full install from scratch in a while.

=
--
--Zootboy

Sent from some sort of computing device.<= /div>
--047d7b5d4576244b6004d725f43d-- --===============1423766357381919612== 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 --===============1423766357381919612==-- From xen-users-bounces@lists.xen.org Tue Mar 05 04:44:13 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:44: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 1UCjim-000433-I0; Tue, 05 Mar 2013 04:43:24 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjik-00042u-GG for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:43:22 +0000 Received: from [85.158.138.51:20085] by server-11.bemta-3.messagelabs.com id 2B/DB-01263-9E775315; Tue, 05 Mar 2013 04:43:21 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1362458599!28568993!1 X-Originating-IP: [209.85.210.179] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6018 invoked from network); 5 Mar 2013 04:43:20 -0000 Received: from mail-ia0-f179.google.com (HELO mail-ia0-f179.google.com) (209.85.210.179) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:43:20 -0000 Received: by mail-ia0-f179.google.com with SMTP id x24so5661040iak.10 for ; Mon, 04 Mar 2013 20:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QyjnPvrS21zQt9HIQsutgZcrNxEHyZ4hQZtZYHxy9IY=; b=itTPQUC7ToZXo8AH5Xh57efcaqoT3xBR7vwEIXtVj9xEaZDV3jWCmWw2J4Cc2Gr8Za HKwtctmOVKyHecenFnw4CiV7ik69SYlSs8CnyDYUypDifyD8rdP9uyBHoNq8eRZQhMu5 b8nht8e5tSqe49uEeO3PREvk1G6t1xWDQ1/aYC7XY5HSpzYFcZwMsqQ95Os68I+cCPqS GbZqRGcfBKrm+Hk4Tw5dasD8YwgTzORdKQdmPXASz7bG08jt/Oapna3DBvUpQq+cwfuP UIg/baPhGXi1Ad+iPh7hL0k5tDZ9WN7QWq9vLKEMMmGmegx2myysFWdlDzeYcqKPwTxu uciQ== MIME-Version: 1.0 X-Received: by 10.42.91.209 with SMTP id q17mr25931161icm.50.1362458598945; Mon, 04 Mar 2013 20:43:18 -0800 (PST) Received: by 10.42.41.5 with HTTP; Mon, 4 Mar 2013 20:43:18 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 21:43:18 -0700 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============0738000915535838843==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0738000915535838843== Content-Type: multipart/alternative; boundary=90e6ba5bbe13cfc37f04d7261cd1 --90e6ba5bbe13cfc37f04d7261cd1 Content-Type: text/plain; charset=ISO-8859-1 When did you compile this package last time ? Can you share buidl package ? On Mon, Mar 4, 2013 at 9:31 PM, Sean Greenslade wrote: > On Mon, Mar 4, 2013 at 10:42 PM, jacek burghardt < > jaceksburghardt@gmail.com> wrote: > >> Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had >> compiled xen on up to date arch linux and is willing to share package. >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users >> > > There's a nice AUR package that I've been using without problems. Link: > https://aur.archlinux.org/packages/xen-hg-unstable/ > > I've been running it on Arch with no major issues. I just finished doing a > pretty thorough rewrite of the Xen article on the archwiki. > https://wiki.archlinux.org/index.php/Xen > > Let me know if there's anything missing from that article, as I haven't > done a full install from scratch in a while. > > > -- > --Zootboy > > Sent from some sort of computing device. > --90e6ba5bbe13cfc37f04d7261cd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When did you compile this package last time ? Can you share buidl package ?=

On Mon, Mar 4, 2013 at 9:31 PM, Sean Gr= eenslade <zootboysean@gmail.com> wrote:
On Mon, Mar 4, 2013 at 10:42 PM, jacek burghardt <jaceksburghardt= @gmail.com> wrote:
Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had com= piled xen on up to date arch linux and is willing to share package.

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

There's a nice AUR packa= ge that I've been using without problems. Link: https://aur.arch= linux.org/packages/xen-hg-unstable/

I've been running it on Arch with no major issues. I just finished = doing a pretty thorough rewrite of the Xen article on the archwiki. https://wik= i.archlinux.org/index.php/Xen

Let me know if there's anything missing from that article, as I hav= en't done a full install from scratch in a while.


--
--Zootboy
Sent from some sort of computing device.

--90e6ba5bbe13cfc37f04d7261cd1-- --===============0738000915535838843== 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 --===============0738000915535838843==-- From xen-users-bounces@lists.xen.org Tue Mar 05 04:44:13 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:44: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 1UCjim-000433-I0; Tue, 05 Mar 2013 04:43:24 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjik-00042u-GG for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:43:22 +0000 Received: from [85.158.138.51:20085] by server-11.bemta-3.messagelabs.com id 2B/DB-01263-9E775315; Tue, 05 Mar 2013 04:43:21 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1362458599!28568993!1 X-Originating-IP: [209.85.210.179] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6018 invoked from network); 5 Mar 2013 04:43:20 -0000 Received: from mail-ia0-f179.google.com (HELO mail-ia0-f179.google.com) (209.85.210.179) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:43:20 -0000 Received: by mail-ia0-f179.google.com with SMTP id x24so5661040iak.10 for ; Mon, 04 Mar 2013 20:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QyjnPvrS21zQt9HIQsutgZcrNxEHyZ4hQZtZYHxy9IY=; b=itTPQUC7ToZXo8AH5Xh57efcaqoT3xBR7vwEIXtVj9xEaZDV3jWCmWw2J4Cc2Gr8Za HKwtctmOVKyHecenFnw4CiV7ik69SYlSs8CnyDYUypDifyD8rdP9uyBHoNq8eRZQhMu5 b8nht8e5tSqe49uEeO3PREvk1G6t1xWDQ1/aYC7XY5HSpzYFcZwMsqQ95Os68I+cCPqS GbZqRGcfBKrm+Hk4Tw5dasD8YwgTzORdKQdmPXASz7bG08jt/Oapna3DBvUpQq+cwfuP UIg/baPhGXi1Ad+iPh7hL0k5tDZ9WN7QWq9vLKEMMmGmegx2myysFWdlDzeYcqKPwTxu uciQ== MIME-Version: 1.0 X-Received: by 10.42.91.209 with SMTP id q17mr25931161icm.50.1362458598945; Mon, 04 Mar 2013 20:43:18 -0800 (PST) Received: by 10.42.41.5 with HTTP; Mon, 4 Mar 2013 20:43:18 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Mar 2013 21:43:18 -0700 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============0738000915535838843==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0738000915535838843== Content-Type: multipart/alternative; boundary=90e6ba5bbe13cfc37f04d7261cd1 --90e6ba5bbe13cfc37f04d7261cd1 Content-Type: text/plain; charset=ISO-8859-1 When did you compile this package last time ? Can you share buidl package ? On Mon, Mar 4, 2013 at 9:31 PM, Sean Greenslade wrote: > On Mon, Mar 4, 2013 at 10:42 PM, jacek burghardt < > jaceksburghardt@gmail.com> wrote: > >> Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had >> compiled xen on up to date arch linux and is willing to share package. >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users >> > > There's a nice AUR package that I've been using without problems. Link: > https://aur.archlinux.org/packages/xen-hg-unstable/ > > I've been running it on Arch with no major issues. I just finished doing a > pretty thorough rewrite of the Xen article on the archwiki. > https://wiki.archlinux.org/index.php/Xen > > Let me know if there's anything missing from that article, as I haven't > done a full install from scratch in a while. > > > -- > --Zootboy > > Sent from some sort of computing device. > --90e6ba5bbe13cfc37f04d7261cd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When did you compile this package last time ? Can you share buidl package ?=

On Mon, Mar 4, 2013 at 9:31 PM, Sean Gr= eenslade <zootboysean@gmail.com> wrote:
On Mon, Mar 4, 2013 at 10:42 PM, jacek burghardt <jaceksburghardt= @gmail.com> wrote:
Is anyone using xen 4.3 unstable on arch linux.? I wonder if anyone had com= piled xen on up to date arch linux and is willing to share package.

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

There's a nice AUR packa= ge that I've been using without problems. Link: https://aur.arch= linux.org/packages/xen-hg-unstable/

I've been running it on Arch with no major issues. I just finished = doing a pretty thorough rewrite of the Xen article on the archwiki. https://wik= i.archlinux.org/index.php/Xen

Let me know if there's anything missing from that article, as I hav= en't done a full install from scratch in a while.


--
--Zootboy
Sent from some sort of computing device.

--90e6ba5bbe13cfc37f04d7261cd1-- --===============0738000915535838843== 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 --===============0738000915535838843==-- From xen-users-bounces@lists.xen.org Tue Mar 05 04:50:15 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:50: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 1UCjon-0004RU-1v; Tue, 05 Mar 2013 04:49:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjol-0004RL-Cz for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:49:35 +0000 Received: from [85.158.139.83:63339] by server-2.bemta-5.messagelabs.com id 32/5F-23989-E5975315; Tue, 05 Mar 2013 04:49:34 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1362458973!18879093!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19423 invoked from network); 5 Mar 2013 04:49:34 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:49:34 -0000 Received: by mail-wg0-f50.google.com with SMTP id es5so5119628wgb.29 for ; Mon, 04 Mar 2013 20:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Pl3uDNzdKtQTsfwjX1m/n92n8VLfYT1Q8rJ05wuUKXQ=; b=mAMnJDdHknr56vLY6EAAfmKChP6As2IEBhUYzQqfLWSBfARRwL5DZ1iFxicC5sfvaC 69B+C/pT8pYruPxZhizJ5v0FFo+i7UNihqlleiLu8bGG7CgA3nU9C4lNRD7BLbYKRQI5 Jy3yn4oyW4ByA1oKEql64nfJB7Bbold6wE22NoMgX9NmFvxMer7AtUN1V4HM73u+aGKG Br2rX8iTbNWeHo4yzfUuqUu9SMBO1Li9yxkgTVFiFH7rb60r7Q6l51Od2kgLRSDuXEG6 WSbH0bXJgO3jTflOniox3y1ptIvYn9QkIEyefVMseBtMgM1ruzd43u927Ldu4S5C4exc hNeA== X-Received: by 10.180.78.168 with SMTP id c8mr7526216wix.27.1362458973770; Mon, 04 Mar 2013 20:49:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Mon, 4 Mar 2013 20:49:13 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Mon, 4 Mar 2013 23:49:13 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============8050571438965395993==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8050571438965395993== Content-Type: multipart/alternative; boundary=f46d043c08d8271cef04d72633ba --f46d043c08d8271cef04d72633ba Content-Type: text/plain; charset=UTF-8 On Mon, Mar 4, 2013 at 11:43 PM, jacek burghardt wrote: > When did you compile this package last time ? Can you share buidl package > ? > > (Try not to top post) Last build is Feb. 13, hg rev 26527. http://mastermind.rh.rit.edu/xen-hg-unstable-26527-1-x86_64.pkg.tar.xz I can't promise it'll stay up for long. You should really build it yourself if you plan on playing with the unstable branch. -- --Zootboy Sent from some sort of computing device. --f46d043c08d8271cef04d72633ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 4, 2013 at 11:43 PM, jacek b= urghardt <jaceksburghardt@gmail.com> wrote:
When did you compile this package last time ? Can you share buidl package ?=

<= /div>(Try not to top post)

Last build is Feb. 13, hg rev 26527.

http://mastermind.rh.rit.edu/xen-hg-unstable-26527-1-x86_64.pkg= .tar.xz

I can't promise it'll stay up for long. You shou= ld really build it yourself if you plan on playing with the unstable branch= .

--
--Zootboy

Sent from some sort of computing device.<= /div>
--f46d043c08d8271cef04d72633ba-- --===============8050571438965395993== 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 --===============8050571438965395993==-- From xen-users-bounces@lists.xen.org Tue Mar 05 04:50:15 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 04:50: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 1UCjon-0004RU-1v; Tue, 05 Mar 2013 04:49:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCjol-0004RL-Cz for xen-users@lists.xen.org; Tue, 05 Mar 2013 04:49:35 +0000 Received: from [85.158.139.83:63339] by server-2.bemta-5.messagelabs.com id 32/5F-23989-E5975315; Tue, 05 Mar 2013 04:49:34 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1362458973!18879093!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19423 invoked from network); 5 Mar 2013 04:49:34 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 04:49:34 -0000 Received: by mail-wg0-f50.google.com with SMTP id es5so5119628wgb.29 for ; Mon, 04 Mar 2013 20:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Pl3uDNzdKtQTsfwjX1m/n92n8VLfYT1Q8rJ05wuUKXQ=; b=mAMnJDdHknr56vLY6EAAfmKChP6As2IEBhUYzQqfLWSBfARRwL5DZ1iFxicC5sfvaC 69B+C/pT8pYruPxZhizJ5v0FFo+i7UNihqlleiLu8bGG7CgA3nU9C4lNRD7BLbYKRQI5 Jy3yn4oyW4ByA1oKEql64nfJB7Bbold6wE22NoMgX9NmFvxMer7AtUN1V4HM73u+aGKG Br2rX8iTbNWeHo4yzfUuqUu9SMBO1Li9yxkgTVFiFH7rb60r7Q6l51Od2kgLRSDuXEG6 WSbH0bXJgO3jTflOniox3y1ptIvYn9QkIEyefVMseBtMgM1ruzd43u927Ldu4S5C4exc hNeA== X-Received: by 10.180.78.168 with SMTP id c8mr7526216wix.27.1362458973770; Mon, 04 Mar 2013 20:49:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Mon, 4 Mar 2013 20:49:13 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Mon, 4 Mar 2013 23:49:13 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============8050571438965395993==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8050571438965395993== Content-Type: multipart/alternative; boundary=f46d043c08d8271cef04d72633ba --f46d043c08d8271cef04d72633ba Content-Type: text/plain; charset=UTF-8 On Mon, Mar 4, 2013 at 11:43 PM, jacek burghardt wrote: > When did you compile this package last time ? Can you share buidl package > ? > > (Try not to top post) Last build is Feb. 13, hg rev 26527. http://mastermind.rh.rit.edu/xen-hg-unstable-26527-1-x86_64.pkg.tar.xz I can't promise it'll stay up for long. You should really build it yourself if you plan on playing with the unstable branch. -- --Zootboy Sent from some sort of computing device. --f46d043c08d8271cef04d72633ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 4, 2013 at 11:43 PM, jacek b= urghardt <jaceksburghardt@gmail.com> wrote:
When did you compile this package last time ? Can you share buidl package ?=

<= /div>(Try not to top post)

Last build is Feb. 13, hg rev 26527.

http://mastermind.rh.rit.edu/xen-hg-unstable-26527-1-x86_64.pkg= .tar.xz

I can't promise it'll stay up for long. You shou= ld really build it yourself if you plan on playing with the unstable branch= .

--
--Zootboy

Sent from some sort of computing device.<= /div>
--f46d043c08d8271cef04d72633ba-- --===============8050571438965395993== 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 --===============8050571438965395993==-- From xen-users-bounces@lists.xen.org Tue Mar 05 08:37:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 08:37: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 1UCnLq-0000CY-MJ; Tue, 05 Mar 2013 08:35:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCnLo-0000CK-Iu for xen-users@lists.xen.org; Tue, 05 Mar 2013 08:35:57 +0000 Received: from [85.158.138.51:32598] by server-7.bemta-3.messagelabs.com id F9/C2-06591-B6EA5315; Tue, 05 Mar 2013 08:35:55 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-7.tower-174.messagelabs.com!1362472553!21459818!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=2.9 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDcxODUw\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDcxODUw\n, BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23832 invoked from network); 5 Mar 2013 08:35:54 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 08:35:54 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MRlnN-1UNXtY0zhB-00Szx7; Tue, 05 Mar 2013 09:35:53 +0100 Message-ID: <5135AE68.6050602@brockmann-consult.de> Date: Tue, 05 Mar 2013 09:35:52 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:UJWCWaCReXbkR1cBG8x3FMTo7A+fAtAXkj5FkBwsGA8 vp08oUZbQ2SnwsKwY3lxkzI93yMJ8w9ppbFmiH4eWUJH6J8RMp 0pQUq17bcXqmo0N33qFBgDvXdAao7lDqAdygQC00LbOF2ZmFM1 azJ5OFKpnQvZBQTVS6YjQ0apkImWrioaYEsMXa3373ZZbxgJMa dNRiQfScmn60LoEyggZkHVgiDINhCXbcimPxFapXjoaytTMwEg C+tobybus3E7p/sR6Z8rEadDEnINd7z47mXVUa0ellOtjxbzlM 7wVhedoSwFg/iL0qnI/wtf5M0hZr+GbLgUinXefoSTDNOXcrB5 IejSGIt+vcUIrh4jTSQFDMh/7DmADGI94qRjTkDQl Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8557016447274764218==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============8557016447274764218== Content-Type: multipart/alternative; boundary="------------070009010306020707040108" This is a multi-part message in MIME format. --------------070009010306020707040108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A few things I can add... My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10. I *never* got windows xp to use the passed through gfx card unless I set "stdvga=1" (which means to replace the cirrus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD) I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead of a "shutdown" and "start", like Casey described. However, when this happens, I can simply "xm destroy ..." and "xm create ..." again, and it works 100%. I have never needed to reboot dom0 to start a vm, except: 1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me) 2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen) And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think). On 2013-03-05 05:25, Casey DeLorme wrote: > Hello Guilherme, was following your exchange and wanted to see how > this turned out. > > Secondary Passthrough works with AMD, but for primary you need to > apply custom patches. There is another email chain circling the > mailing list with links to some fresh patches. > > As Matthias mentioned, passthrough is working, but I am quite certain > FLR is interfering which has led to driver related BSoD's. > > My understanding is that FLR allows a virtual machine to issue a reset > to a piece of hardware, and without it that device's state cannot be > cleared. Consumer cards do not come with FLR, and no patch for this > is available. > > What this means is that when you first boot your virtual machine, the > card is initialized and performs just fine. When you shut down > Windows 7 or XP and start either one back up you may encounter a BSoD. > This is because the card is being initialized a second time. > > For me and many others rebooting has led to degraded performance > instead of a BSoD, which can be fixed by manually ejecting the card > with the "safely eject media" tool. However experiences vary. > > > I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it > is working just fine. I have had this working in both Windows 7 and > Windows 8, but I have no experience with XP. > > Keeping in mind that your experience may vary, here is my route to > success: > > First, backup your Windows HVM before attempting to pass any PCI devices. > > Make certain that Dom0 has been freshly booted to ensure that the PCI > card only initializes once. The leading cause to trouble from my > experience is passing the card more than once at any point during the > installation, which leads to a BSoD during the process OR a badly > damaged install which can range from BSoD on reboot only to gradual > buggy experiences and BSoD's on first boot. > > Prior to passing the PCI card to Windows 7 or Windows 8 be sure to > turn off all automatic driver installation settings (there are more > than one). If using Windows 8 do not add the card to the > configuration, instead let it boot and then use `xl pci-attach`, since > Windows 8 will attempt to install a driver at boot time and reboot > without ever displaying anything on screen. > > Once the installation has completed it may ask you to reboot, instead > shut down Windows and reboot Dom0 then start Windows again. This > avoids any post-install processes from attempting to communicate with > the card in its buggy (previously initialized) state, which could muck > up the installation. > > I have used the above rules successfully more than a dozen times now, > and never once had a BSoD when I followed them. > > Finally, the reason for the backup at the beginning is that anytime I > failed to follow the above rules, I was not able to fix the problem by > removing and installing the drivers again. In fact, that never once > worked and I wasted a few days trying several times without success. > So in short, if you fail don't bother removing the drivers and trying > again, instead restore from an image backup of the machine that has > never once seen your PCI device. > > > I hope this information helps. > > Sincerely, > > Casey DeLorme > > > On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki > wrote: > > Matthias, hi! > > I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the > same on and on (_VGA passthru worked only as secondary device and > dom0 freshly rebooted_). As requested, I'm sending you the hvm > configuration files from windows-xp and windows-7, my lspci -vv, > uname and the kernel configuration file. > > Do you have any idea how I can make this work? > > > > 2013/3/4 Guilherme Suzuki > > > Alright! > > I'm gonna try catalyst 12-10 (after deinstalling and checking > if the passthru works rebooting and so on). > > I'll send my domU config as soon as I get home. > > One more question: does it matter if I use intel onboard > graphics with the dom0 and xen-pciback(radeon device pci)? > Cause that would be the reason primary VGA passthru did not > work... > > Thx, xen guys are awesome! =D > >> On Mar 4, 2013 2:07 PM, "Matthias" >> > > wrote: >> >> Hi, >> >> good news, since you said your winxp was able to boot with vga >> passthrough just fine, your FLR seems to work fine and this might >> 'only' be a driver-related problem. >> >> What you can do is deinstall your catalyst drivers. After >> rebooting, >> Win7 will fallback on a windows-standard driver for the vga >> but when >> it correctly says the vga name (like ATI Radeion HD whatever >> Series), >> it actually is falling back to an older catalyst version which is >> shipped per default with windows. I have found this much more >> stable >> on reboots then the newest driver. Also, deinstall Catalyst / >> Vision >> control center and at best everything the catalyst installer >> lets you >> deinstall. >> >> If vga passthrough works without all the drivers and you >> really want >> the latest and greatest catalyst, i recommend not using the >> latest >> 13-1 because it creates a similar behavior you mentioned on my >> machine. But catalyst 12-10 seems to work fine, so i would >> advice you >> trying that one. >> >> >> If it still doesn't work with deinstalled drivers, we can try >> a patch >> i'm currently testing.. But this the patch is somewhat >> complicated to >> install, let's stick with the simple things for the moment. >> >> Also, your domU config still would be of help ruling out some >> misconfiguration there.. >> >> >> >> 2013/3/4 Guilherme Suzuki > >: >> > Sorry (hit send). >> > >> > So, the radeon device tells it couldnt start itself (code >> 10) and cirrus >> > d... > > > > > -- > Grato, > > *Guilherme Suzuki* > Consultor em TI para projetos Microsoft > *http://www.guilhermesuzuki.com* > 11 - 992360535 > 11 - 20990757 > > > > _______________________________________________ > 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 -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --------------070009010306020707040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
A few things I can add...

My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10.

I *never* got windows xp to use the passed through gfx card unless I set "stdvga=1" (which means to replace the cirrus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD)

I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead of a "shutdown" and "start", like Casey described. However, when this happens, I can simply "xm destroy ..." and "xm create ..." again, and it works 100%.

I have never needed to reboot dom0 to start a vm, except:
1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me)
2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen)

And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think).



On 2013-03-05 05:25, Casey DeLorme wrote:
Hello Guilherme, was following your exchange and wanted to see how this turned out.

Secondary Passthrough works with AMD, but for primary you need to apply custom patches.  There is another email chain circling the mailing list with links to some fresh patches.

As Matthias mentioned, passthrough is working, but I am quite certain FLR is interfering which has led to driver related BSoD's.

My understanding is that FLR allows a virtual machine to issue a reset to a piece of hardware, and without it that device's state cannot be cleared.  Consumer cards do not come with FLR, and no patch for this is available.

What this means is that when you first boot your virtual machine, the card is initialized and performs just fine.  When you shut down Windows 7 or XP and start either one back up you may encounter a BSoD.  This is because the card is being initialized a second time.

For me and many others rebooting has led to degraded performance instead of a BSoD, which can be fixed by manually ejecting the card with the "safely eject media" tool.  However experiences vary.


I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it is working just fine.  I have had this working in both Windows 7 and Windows 8, but I have no experience with XP.

Keeping in mind that your experience may vary, here is my route to success:

First, backup your Windows HVM before attempting to pass any PCI devices.

Make certain that Dom0 has been freshly booted to ensure that the PCI card only initializes once.  The leading cause to trouble from my experience is passing the card more than once at any point during the installation, which leads to a BSoD during the process OR a badly damaged install which can range from BSoD on reboot only to gradual buggy experiences and BSoD's on first boot.

Prior to passing the PCI card to Windows 7 or Windows 8 be sure to turn off all automatic driver installation settings (there are more than one).  If using Windows 8 do not add the card to the configuration, instead let it boot and then use `xl pci-attach`, since Windows 8 will attempt to install a driver at boot time and reboot without ever displaying anything on screen.

Once the installation has completed it may ask you to reboot, instead shut down Windows and reboot Dom0 then start Windows again.  This avoids any post-install processes from attempting to communicate with the card in its buggy (previously initialized) state, which could muck up the installation.

I have used the above rules successfully more than a dozen times now, and never once had a BSoD when I followed them.

Finally, the reason for the backup at the beginning is that anytime I failed to follow the above rules, I was not able to fix the problem by removing and installing the drivers again.  In fact, that never once worked and I wasted a few days trying several times without success.  So in short, if you fail don't bother removing the drivers and trying again, instead restore from an image backup of the machine that has never once seen your PCI device.


I hope this information helps.

Sincerely,

Casey DeLorme


On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
Matthias, hi!

I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the same on and on (VGA passthru worked only as secondary device and dom0 freshly rebooted). As requested, I'm sending you the hvm configuration files from windows-xp and windows-7, my lspci -vv, uname and the kernel configuration file.

Do you have any idea how I can make this work?



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason primary VGA passthru did not work...

Thx, xen guys are awesome! =D

On Mar 4, 2013 2:07 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch
i'm currently testing.. But this the patch is somewhat complicated to
install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:
> Sorry (hit send).
>
> So, the radeon device tells it couldnt start itself (code 10) and cirrus
> d...



--
Grato,

Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
11 - 992360535
11 - 20990757
 

_______________________________________________
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


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------
--------------070009010306020707040108-- --===============8557016447274764218== 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 --===============8557016447274764218==-- From xen-users-bounces@lists.xen.org Tue Mar 05 08:37:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 08:37: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 1UCnLq-0000CY-MJ; Tue, 05 Mar 2013 08:35:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCnLo-0000CK-Iu for xen-users@lists.xen.org; Tue, 05 Mar 2013 08:35:57 +0000 Received: from [85.158.138.51:32598] by server-7.bemta-3.messagelabs.com id F9/C2-06591-B6EA5315; Tue, 05 Mar 2013 08:35:55 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-7.tower-174.messagelabs.com!1362472553!21459818!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=2.9 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDcxODUw\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDcxODUw\n, BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23832 invoked from network); 5 Mar 2013 08:35:54 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 08:35:54 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MRlnN-1UNXtY0zhB-00Szx7; Tue, 05 Mar 2013 09:35:53 +0100 Message-ID: <5135AE68.6050602@brockmann-consult.de> Date: Tue, 05 Mar 2013 09:35:52 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:UJWCWaCReXbkR1cBG8x3FMTo7A+fAtAXkj5FkBwsGA8 vp08oUZbQ2SnwsKwY3lxkzI93yMJ8w9ppbFmiH4eWUJH6J8RMp 0pQUq17bcXqmo0N33qFBgDvXdAao7lDqAdygQC00LbOF2ZmFM1 azJ5OFKpnQvZBQTVS6YjQ0apkImWrioaYEsMXa3373ZZbxgJMa dNRiQfScmn60LoEyggZkHVgiDINhCXbcimPxFapXjoaytTMwEg C+tobybus3E7p/sR6Z8rEadDEnINd7z47mXVUa0ellOtjxbzlM 7wVhedoSwFg/iL0qnI/wtf5M0hZr+GbLgUinXefoSTDNOXcrB5 IejSGIt+vcUIrh4jTSQFDMh/7DmADGI94qRjTkDQl Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8557016447274764218==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============8557016447274764218== Content-Type: multipart/alternative; boundary="------------070009010306020707040108" This is a multi-part message in MIME format. --------------070009010306020707040108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A few things I can add... My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10. I *never* got windows xp to use the passed through gfx card unless I set "stdvga=1" (which means to replace the cirrus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD) I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead of a "shutdown" and "start", like Casey described. However, when this happens, I can simply "xm destroy ..." and "xm create ..." again, and it works 100%. I have never needed to reboot dom0 to start a vm, except: 1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me) 2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen) And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think). On 2013-03-05 05:25, Casey DeLorme wrote: > Hello Guilherme, was following your exchange and wanted to see how > this turned out. > > Secondary Passthrough works with AMD, but for primary you need to > apply custom patches. There is another email chain circling the > mailing list with links to some fresh patches. > > As Matthias mentioned, passthrough is working, but I am quite certain > FLR is interfering which has led to driver related BSoD's. > > My understanding is that FLR allows a virtual machine to issue a reset > to a piece of hardware, and without it that device's state cannot be > cleared. Consumer cards do not come with FLR, and no patch for this > is available. > > What this means is that when you first boot your virtual machine, the > card is initialized and performs just fine. When you shut down > Windows 7 or XP and start either one back up you may encounter a BSoD. > This is because the card is being initialized a second time. > > For me and many others rebooting has led to degraded performance > instead of a BSoD, which can be fixed by manually ejecting the card > with the "safely eject media" tool. However experiences vary. > > > I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it > is working just fine. I have had this working in both Windows 7 and > Windows 8, but I have no experience with XP. > > Keeping in mind that your experience may vary, here is my route to > success: > > First, backup your Windows HVM before attempting to pass any PCI devices. > > Make certain that Dom0 has been freshly booted to ensure that the PCI > card only initializes once. The leading cause to trouble from my > experience is passing the card more than once at any point during the > installation, which leads to a BSoD during the process OR a badly > damaged install which can range from BSoD on reboot only to gradual > buggy experiences and BSoD's on first boot. > > Prior to passing the PCI card to Windows 7 or Windows 8 be sure to > turn off all automatic driver installation settings (there are more > than one). If using Windows 8 do not add the card to the > configuration, instead let it boot and then use `xl pci-attach`, since > Windows 8 will attempt to install a driver at boot time and reboot > without ever displaying anything on screen. > > Once the installation has completed it may ask you to reboot, instead > shut down Windows and reboot Dom0 then start Windows again. This > avoids any post-install processes from attempting to communicate with > the card in its buggy (previously initialized) state, which could muck > up the installation. > > I have used the above rules successfully more than a dozen times now, > and never once had a BSoD when I followed them. > > Finally, the reason for the backup at the beginning is that anytime I > failed to follow the above rules, I was not able to fix the problem by > removing and installing the drivers again. In fact, that never once > worked and I wasted a few days trying several times without success. > So in short, if you fail don't bother removing the drivers and trying > again, instead restore from an image backup of the machine that has > never once seen your PCI device. > > > I hope this information helps. > > Sincerely, > > Casey DeLorme > > > On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki > wrote: > > Matthias, hi! > > I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the > same on and on (_VGA passthru worked only as secondary device and > dom0 freshly rebooted_). As requested, I'm sending you the hvm > configuration files from windows-xp and windows-7, my lspci -vv, > uname and the kernel configuration file. > > Do you have any idea how I can make this work? > > > > 2013/3/4 Guilherme Suzuki > > > Alright! > > I'm gonna try catalyst 12-10 (after deinstalling and checking > if the passthru works rebooting and so on). > > I'll send my domU config as soon as I get home. > > One more question: does it matter if I use intel onboard > graphics with the dom0 and xen-pciback(radeon device pci)? > Cause that would be the reason primary VGA passthru did not > work... > > Thx, xen guys are awesome! =D > >> On Mar 4, 2013 2:07 PM, "Matthias" >> > > wrote: >> >> Hi, >> >> good news, since you said your winxp was able to boot with vga >> passthrough just fine, your FLR seems to work fine and this might >> 'only' be a driver-related problem. >> >> What you can do is deinstall your catalyst drivers. After >> rebooting, >> Win7 will fallback on a windows-standard driver for the vga >> but when >> it correctly says the vga name (like ATI Radeion HD whatever >> Series), >> it actually is falling back to an older catalyst version which is >> shipped per default with windows. I have found this much more >> stable >> on reboots then the newest driver. Also, deinstall Catalyst / >> Vision >> control center and at best everything the catalyst installer >> lets you >> deinstall. >> >> If vga passthrough works without all the drivers and you >> really want >> the latest and greatest catalyst, i recommend not using the >> latest >> 13-1 because it creates a similar behavior you mentioned on my >> machine. But catalyst 12-10 seems to work fine, so i would >> advice you >> trying that one. >> >> >> If it still doesn't work with deinstalled drivers, we can try >> a patch >> i'm currently testing.. But this the patch is somewhat >> complicated to >> install, let's stick with the simple things for the moment. >> >> Also, your domU config still would be of help ruling out some >> misconfiguration there.. >> >> >> >> 2013/3/4 Guilherme Suzuki > >: >> > Sorry (hit send). >> > >> > So, the radeon device tells it couldnt start itself (code >> 10) and cirrus >> > d... > > > > > -- > Grato, > > *Guilherme Suzuki* > Consultor em TI para projetos Microsoft > *http://www.guilhermesuzuki.com* > 11 - 992360535 > 11 - 20990757 > > > > _______________________________________________ > 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 -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --------------070009010306020707040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
A few things I can add...

My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10.

I *never* got windows xp to use the passed through gfx card unless I set "stdvga=1" (which means to replace the cirrus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD)

I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead of a "shutdown" and "start", like Casey described. However, when this happens, I can simply "xm destroy ..." and "xm create ..." again, and it works 100%.

I have never needed to reboot dom0 to start a vm, except:
1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me)
2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen)

And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think).



On 2013-03-05 05:25, Casey DeLorme wrote:
Hello Guilherme, was following your exchange and wanted to see how this turned out.

Secondary Passthrough works with AMD, but for primary you need to apply custom patches.  There is another email chain circling the mailing list with links to some fresh patches.

As Matthias mentioned, passthrough is working, but I am quite certain FLR is interfering which has led to driver related BSoD's.

My understanding is that FLR allows a virtual machine to issue a reset to a piece of hardware, and without it that device's state cannot be cleared.  Consumer cards do not come with FLR, and no patch for this is available.

What this means is that when you first boot your virtual machine, the card is initialized and performs just fine.  When you shut down Windows 7 or XP and start either one back up you may encounter a BSoD.  This is because the card is being initialized a second time.

For me and many others rebooting has led to degraded performance instead of a BSoD, which can be fixed by manually ejecting the card with the "safely eject media" tool.  However experiences vary.


I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it is working just fine.  I have had this working in both Windows 7 and Windows 8, but I have no experience with XP.

Keeping in mind that your experience may vary, here is my route to success:

First, backup your Windows HVM before attempting to pass any PCI devices.

Make certain that Dom0 has been freshly booted to ensure that the PCI card only initializes once.  The leading cause to trouble from my experience is passing the card more than once at any point during the installation, which leads to a BSoD during the process OR a badly damaged install which can range from BSoD on reboot only to gradual buggy experiences and BSoD's on first boot.

Prior to passing the PCI card to Windows 7 or Windows 8 be sure to turn off all automatic driver installation settings (there are more than one).  If using Windows 8 do not add the card to the configuration, instead let it boot and then use `xl pci-attach`, since Windows 8 will attempt to install a driver at boot time and reboot without ever displaying anything on screen.

Once the installation has completed it may ask you to reboot, instead shut down Windows and reboot Dom0 then start Windows again.  This avoids any post-install processes from attempting to communicate with the card in its buggy (previously initialized) state, which could muck up the installation.

I have used the above rules successfully more than a dozen times now, and never once had a BSoD when I followed them.

Finally, the reason for the backup at the beginning is that anytime I failed to follow the above rules, I was not able to fix the problem by removing and installing the drivers again.  In fact, that never once worked and I wasted a few days trying several times without success.  So in short, if you fail don't bother removing the drivers and trying again, instead restore from an image backup of the machine that has never once seen your PCI device.


I hope this information helps.

Sincerely,

Casey DeLorme


On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
Matthias, hi!

I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the same on and on (VGA passthru worked only as secondary device and dom0 freshly rebooted). As requested, I'm sending you the hvm configuration files from windows-xp and windows-7, my lspci -vv, uname and the kernel configuration file.

Do you have any idea how I can make this work?



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason primary VGA passthru did not work...

Thx, xen guys are awesome! =D

On Mar 4, 2013 2:07 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch
i'm currently testing.. But this the patch is somewhat complicated to
install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:
> Sorry (hit send).
>
> So, the radeon device tells it couldnt start itself (code 10) and cirrus
> d...



--
Grato,

Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
11 - 992360535
11 - 20990757
 

_______________________________________________
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


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------
--------------070009010306020707040108-- --===============8557016447274764218== 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 --===============8557016447274764218==-- From xen-users-bounces@lists.xen.org Tue Mar 05 08:40:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 08:40: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 1UCnPN-0000Rh-Ln; Tue, 05 Mar 2013 08:39:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCnPM-0000RZ-Ea for xen-users@lists.xen.org; Tue, 05 Mar 2013 08:39:37 +0000 Received: from [85.158.139.211:31958] by server-5.bemta-5.messagelabs.com id 96/B2-02762-74FA5315; Tue, 05 Mar 2013 08:39:35 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-10.tower-206.messagelabs.com!1362472752!17977771!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=2.4 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDcxODUw\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDcxODUw\n, BODY_RANDOM_LONG, HTML_50_60, HTML_MESSAGE,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15972 invoked from network); 5 Mar 2013 08:39:13 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 08:39:13 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LfSYr-1UaYUc2I25-00p2wC; Tue, 05 Mar 2013 09:39:07 +0100 Message-ID: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 05 Mar 2013 09:39:07 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Casey DeLorme References: In-Reply-To: X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:FKYgP36Vvk3oaJu6OWHB9hgdiFrZuT709HZmWyP62wN BUfcjRJ5dvuNwN9Q5I30i9EkJnPnnD3p9fuZLeCXTa55gOjpQ/ ymnz9Tvyg7Xbod31cAcsiqH8a9Rru7d3Dq82Cy1L1T7R8i0sgA XAsufOPINvD4YqArKPr8vuPdDnRqCyMPaNfFSGT7a/CbFqDB0m CsVOycpNC7ES5Ka+SFfsIRxjZsClWrayOek+EbsZTUc1PCi9pM QLPhK869RkIE0BFzo79Q12MiGTnqoWKcm0erK2AhGjDlWBd/Z3 dqaQjPdN/OFC09ncmy5VSHmOaJNaD6iRIvrdrTZfh+Z14nv+hd 5J2S2VVYUHN4+GXTzLTi3Gl/AZgzFaahIv+NADQuX Cc: Matthias , Guilherme Suzuki , xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============6389669649966058501==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============6389669649966058501== Content-Type: multipart/alternative; boundary="------------020502040803010102080600" This is a multi-part message in MIME format. --------------020502040803010102080600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got 2. On 2013-03-05 09:35, Peter Maloney wrote: > A few things I can add... > > My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst > version 12-10. > > I *never* got windows xp to use the passed through gfx card unless I > set "stdvga=1" (which means to replace the cirrus logic card (that > works in winxp) with another (that doesn't work in xp), so it then > uses the secondary gpu like I wanted. Win7 and 8 work without this. > (and FYI xp is the worst performer by far, maybe from a xen bug that > only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a > bug affecting just AMD) > > I very rarely get any problem booting and getting graphics to work, > and never on the first boot. Every time there is an error, it is from > a "restart" (such as a windows update) instead of a "shutdown" and > "start", like Casey described. However, when this happens, I can > simply "xm destroy ..." and "xm create ..." again, and it works 100%. > > I have never needed to reboot dom0 to start a vm, except: > 1. to get my USB IRQ to work again in dom0 (without this, my keyboard > and mouse are laggy and miss keystrokes). I have passed through a USB > controller that lacks FLR, so if the vm dies incorrectly [not a > shutdown], dom0 broadcasts that it is disabling an irq. If I start the > domu again, the usb works fine in domu, but never dom0 until reboot. > (I've only caused this with crashing domu's from kernel oopses from > #2, and with gplpv network drivers which never seem to work right for me) > 2. testing broken kernels (3.7-rc2, etc. with broken network) (in this > case, every domu I try to create after the first problem starts with a > blank screen, and vnc usually is blank or just says "parallell0" > instead of a console screen) > > And last, contradictory to what the others said, win7 gfx passthrough > never worked for me without installing the catalyst drivers first in > winxp or win7. Win8 worked though, one time even in the installer > (depends on whether the monitor is plugged in at the right time I think). > > > > On 2013-03-05 05:25, Casey DeLorme wrote: >> Hello Guilherme, was following your exchange and wanted to see how >> this turned out. >> >> Secondary Passthrough works with AMD, but for primary you need to >> apply custom patches. There is another email chain circling the >> mailing list with links to some fresh patches. >> >> As Matthias mentioned, passthrough is working, but I am quite certain >> FLR is interfering which has led to driver related BSoD's. >> >> My understanding is that FLR allows a virtual machine to issue a >> reset to a piece of hardware, and without it that device's state >> cannot be cleared. Consumer cards do not come with FLR, and no patch >> for this is available. >> >> What this means is that when you first boot your virtual machine, the >> card is initialized and performs just fine. When you shut down >> Windows 7 or XP and start either one back up you may encounter a >> BSoD. This is because the card is being initialized a second time. >> >> For me and many others rebooting has led to degraded performance >> instead of a BSoD, which can be fixed by manually ejecting the card >> with the "safely eject media" tool. However experiences vary. >> >> >> I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it >> is working just fine. I have had this working in both Windows 7 and >> Windows 8, but I have no experience with XP. >> >> Keeping in mind that your experience may vary, here is my route to >> success: >> >> First, backup your Windows HVM before attempting to pass any PCI devices. >> >> Make certain that Dom0 has been freshly booted to ensure that the PCI >> card only initializes once. The leading cause to trouble from my >> experience is passing the card more than once at any point during the >> installation, which leads to a BSoD during the process OR a badly >> damaged install which can range from BSoD on reboot only to gradual >> buggy experiences and BSoD's on first boot. >> >> Prior to passing the PCI card to Windows 7 or Windows 8 be sure to >> turn off all automatic driver installation settings (there are more >> than one). If using Windows 8 do not add the card to the >> configuration, instead let it boot and then use `xl pci-attach`, >> since Windows 8 will attempt to install a driver at boot time and >> reboot without ever displaying anything on screen. >> >> Once the installation has completed it may ask you to reboot, instead >> shut down Windows and reboot Dom0 then start Windows again. This >> avoids any post-install processes from attempting to communicate with >> the card in its buggy (previously initialized) state, which could >> muck up the installation. >> >> I have used the above rules successfully more than a dozen times now, >> and never once had a BSoD when I followed them. >> >> Finally, the reason for the backup at the beginning is that anytime I >> failed to follow the above rules, I was not able to fix the problem >> by removing and installing the drivers again. In fact, that never >> once worked and I wasted a few days trying several times without >> success. So in short, if you fail don't bother removing the drivers >> and trying again, instead restore from an image backup of the machine >> that has never once seen your PCI device. >> >> >> I hope this information helps. >> >> Sincerely, >> >> Casey DeLorme >> >> >> On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki >> > wrote: >> >> Matthias, hi! >> >> I've tried Catalyst 12.10 and even 12.1, but xen behavior kept >> the same on and on (_VGA passthru worked only as secondary device >> and dom0 freshly rebooted_). As requested, I'm sending you the >> hvm configuration files from windows-xp and windows-7, my lspci >> -vv, uname and the kernel configuration file. >> >> Do you have any idea how I can make this work? >> >> >> >> 2013/3/4 Guilherme Suzuki > > >> >> Alright! >> >> I'm gonna try catalyst 12-10 (after deinstalling and checking >> if the passthru works rebooting and so on). >> >> I'll send my domU config as soon as I get home. >> >> One more question: does it matter if I use intel onboard >> graphics with the dom0 and xen-pciback(radeon device pci)? >> Cause that would be the reason primary VGA passthru did not >> work... >> >> Thx, xen guys are awesome! =D >> >>> On Mar 4, 2013 2:07 PM, "Matthias" >>> >> > wrote: >>> >>> Hi, >>> >>> good news, since you said your winxp was able to boot with vga >>> passthrough just fine, your FLR seems to work fine and this >>> might >>> 'only' be a driver-related problem. >>> >>> What you can do is deinstall your catalyst drivers. After >>> rebooting, >>> Win7 will fallback on a windows-standard driver for the vga >>> but when >>> it correctly says the vga name (like ATI Radeion HD whatever >>> Series), >>> it actually is falling back to an older catalyst version >>> which is >>> shipped per default with windows. I have found this much >>> more stable >>> on reboots then the newest driver. Also, deinstall Catalyst >>> / Vision >>> control center and at best everything the catalyst installer >>> lets you >>> deinstall. >>> >>> If vga passthrough works without all the drivers and you >>> really want >>> the latest and greatest catalyst, i recommend not using the >>> latest >>> 13-1 because it creates a similar behavior you mentioned on my >>> machine. But catalyst 12-10 seems to work fine, so i would >>> advice you >>> trying that one. >>> >>> >>> If it still doesn't work with deinstalled drivers, we can >>> try a patch >>> i'm currently testing.. But this the patch is somewhat >>> complicated to >>> install, let's stick with the simple things for the moment. >>> >>> Also, your domU config still would be of help ruling out some >>> misconfiguration there.. >>> >>> >>> >>> 2013/3/4 Guilherme Suzuki >> >: >>> > Sorry (hit send). >>> > >>> > So, the radeon device tells it couldnt start itself (code >>> 10) and cirrus >>> > d... >> >> >> >> >> -- >> Grato, >> >> *Guilherme Suzuki* >> Consultor em TI para projetos Microsoft >> *http://www.guilhermesuzuki.com* >> 11 - 992360535 >> 11 - 20990757 >> >> >> >> _______________________________________________ >> 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 > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str. 2 > 21502 Geesthacht > Germany > Tel: +49 4152 889 300 > Fax: +49 4152 889 333 > E-mail: peter.maloney@brockmann-consult.de > Internet: http://www.brockmann-consult.de > -------------------------------------------- -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --------------020502040803010102080600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got 2.


On 2013-03-05 09:35, Peter Maloney wrote:
A few things I can add...

My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10.

I *never* got windows xp to use the passed through gfx card unless I set "stdvga=1" (which means to replace the cirrus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD)

I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead of a "shutdown" and "start", like Casey described. However, when this happens, I can simply "xm destroy ..." and "xm create ..." again, and it works 100%.

I have never needed to reboot dom0 to start a vm, except:
1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me)
2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen)

And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think).



On 2013-03-05 05:25, Casey DeLorme wrote:
Hello Guilherme, was following your exchange and wanted to see how this turned out.

Secondary Passthrough works with AMD, but for primary you need to apply custom patches.  There is another email chain circling the mailing list with links to some fresh patches.

As Matthias mentioned, passthrough is working, but I am quite certain FLR is interfering which has led to driver related BSoD's.

My understanding is that FLR allows a virtual machine to issue a reset to a piece of hardware, and without it that device's state cannot be cleared.  Consumer cards do not come with FLR, and no patch for this is available.

What this means is that when you first boot your virtual machine, the card is initialized and performs just fine.  When you shut down Windows 7 or XP and start either one back up you may encounter a BSoD.  This is because the card is being initialized a second time.

For me and many others rebooting has led to degraded performance instead of a BSoD, which can be fixed by manually ejecting the card with the "safely eject media" tool.  However experiences vary.


I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it is working just fine.  I have had this working in both Windows 7 and Windows 8, but I have no experience with XP.

Keeping in mind that your experience may vary, here is my route to success:

First, backup your Windows HVM before attempting to pass any PCI devices.

Make certain that Dom0 has been freshly booted to ensure that the PCI card only initializes once.  The leading cause to trouble from my experience is passing the card more than once at any point during the installation, which leads to a BSoD during the process OR a badly damaged install which can range from BSoD on reboot only to gradual buggy experiences and BSoD's on first boot.

Prior to passing the PCI card to Windows 7 or Windows 8 be sure to turn off all automatic driver installation settings (there are more than one).  If using Windows 8 do not add the card to the configuration, instead let it boot and then use `xl pci-attach`, since Windows 8 will attempt to install a driver at boot time and reboot without ever displaying anything on screen.

Once the installation has completed it may ask you to reboot, instead shut down Windows and reboot Dom0 then start Windows again.  This avoids any post-install processes from attempting to communicate with the card in its buggy (previously initialized) state, which could muck up the installation.

I have used the above rules successfully more than a dozen times now, and never once had a BSoD when I followed them.

Finally, the reason for the backup at the beginning is that anytime I failed to follow the above rules, I was not able to fix the problem by removing and installing the drivers again.  In fact, that never once worked and I wasted a few days trying several times without success.  So in short, if you fail don't bother removing the drivers and trying again, instead restore from an image backup of the machine that has never once seen your PCI device.


I hope this information helps.

Sincerely,

Casey DeLorme


On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
Matthias, hi!

I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the same on and on (VGA passthru worked only as secondary device and dom0 freshly rebooted). As requested, I'm sending you the hvm configuration files from windows-xp and windows-7, my lspci -vv, uname and the kernel configuration file.

Do you have any idea how I can make this work?



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason primary VGA passthru did not work...

Thx, xen guys are awesome! =D

On Mar 4, 2013 2:07 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch
i'm currently testing.. But this the patch is somewhat complicated to
install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:
> Sorry (hit send).
>
> So, the radeon device tells it couldnt start itself (code 10) and cirrus
> d...



--
Grato,

Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
11 - 992360535
11 - 20990757
 

_______________________________________________
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


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------
--------------020502040803010102080600-- --===============6389669649966058501== 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 --===============6389669649966058501==-- From xen-users-bounces@lists.xen.org Tue Mar 05 08:40:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 08:40: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 1UCnPN-0000Rh-Ln; Tue, 05 Mar 2013 08:39:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCnPM-0000RZ-Ea for xen-users@lists.xen.org; Tue, 05 Mar 2013 08:39:37 +0000 Received: from [85.158.139.211:31958] by server-5.bemta-5.messagelabs.com id 96/B2-02762-74FA5315; Tue, 05 Mar 2013 08:39:35 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-10.tower-206.messagelabs.com!1362472752!17977771!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=2.4 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDcxODUw\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDcxODUw\n, BODY_RANDOM_LONG, HTML_50_60, HTML_MESSAGE,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15972 invoked from network); 5 Mar 2013 08:39:13 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 08:39:13 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LfSYr-1UaYUc2I25-00p2wC; Tue, 05 Mar 2013 09:39:07 +0100 Message-ID: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 05 Mar 2013 09:39:07 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Casey DeLorme References: In-Reply-To: X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:FKYgP36Vvk3oaJu6OWHB9hgdiFrZuT709HZmWyP62wN BUfcjRJ5dvuNwN9Q5I30i9EkJnPnnD3p9fuZLeCXTa55gOjpQ/ ymnz9Tvyg7Xbod31cAcsiqH8a9Rru7d3Dq82Cy1L1T7R8i0sgA XAsufOPINvD4YqArKPr8vuPdDnRqCyMPaNfFSGT7a/CbFqDB0m CsVOycpNC7ES5Ka+SFfsIRxjZsClWrayOek+EbsZTUc1PCi9pM QLPhK869RkIE0BFzo79Q12MiGTnqoWKcm0erK2AhGjDlWBd/Z3 dqaQjPdN/OFC09ncmy5VSHmOaJNaD6iRIvrdrTZfh+Z14nv+hd 5J2S2VVYUHN4+GXTzLTi3Gl/AZgzFaahIv+NADQuX Cc: Matthias , Guilherme Suzuki , xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============6389669649966058501==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============6389669649966058501== Content-Type: multipart/alternative; boundary="------------020502040803010102080600" This is a multi-part message in MIME format. --------------020502040803010102080600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got 2. On 2013-03-05 09:35, Peter Maloney wrote: > A few things I can add... > > My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst > version 12-10. > > I *never* got windows xp to use the passed through gfx card unless I > set "stdvga=1" (which means to replace the cirrus logic card (that > works in winxp) with another (that doesn't work in xp), so it then > uses the secondary gpu like I wanted. Win7 and 8 work without this. > (and FYI xp is the worst performer by far, maybe from a xen bug that > only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a > bug affecting just AMD) > > I very rarely get any problem booting and getting graphics to work, > and never on the first boot. Every time there is an error, it is from > a "restart" (such as a windows update) instead of a "shutdown" and > "start", like Casey described. However, when this happens, I can > simply "xm destroy ..." and "xm create ..." again, and it works 100%. > > I have never needed to reboot dom0 to start a vm, except: > 1. to get my USB IRQ to work again in dom0 (without this, my keyboard > and mouse are laggy and miss keystrokes). I have passed through a USB > controller that lacks FLR, so if the vm dies incorrectly [not a > shutdown], dom0 broadcasts that it is disabling an irq. If I start the > domu again, the usb works fine in domu, but never dom0 until reboot. > (I've only caused this with crashing domu's from kernel oopses from > #2, and with gplpv network drivers which never seem to work right for me) > 2. testing broken kernels (3.7-rc2, etc. with broken network) (in this > case, every domu I try to create after the first problem starts with a > blank screen, and vnc usually is blank or just says "parallell0" > instead of a console screen) > > And last, contradictory to what the others said, win7 gfx passthrough > never worked for me without installing the catalyst drivers first in > winxp or win7. Win8 worked though, one time even in the installer > (depends on whether the monitor is plugged in at the right time I think). > > > > On 2013-03-05 05:25, Casey DeLorme wrote: >> Hello Guilherme, was following your exchange and wanted to see how >> this turned out. >> >> Secondary Passthrough works with AMD, but for primary you need to >> apply custom patches. There is another email chain circling the >> mailing list with links to some fresh patches. >> >> As Matthias mentioned, passthrough is working, but I am quite certain >> FLR is interfering which has led to driver related BSoD's. >> >> My understanding is that FLR allows a virtual machine to issue a >> reset to a piece of hardware, and without it that device's state >> cannot be cleared. Consumer cards do not come with FLR, and no patch >> for this is available. >> >> What this means is that when you first boot your virtual machine, the >> card is initialized and performs just fine. When you shut down >> Windows 7 or XP and start either one back up you may encounter a >> BSoD. This is because the card is being initialized a second time. >> >> For me and many others rebooting has led to degraded performance >> instead of a BSoD, which can be fixed by manually ejecting the card >> with the "safely eject media" tool. However experiences vary. >> >> >> I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it >> is working just fine. I have had this working in both Windows 7 and >> Windows 8, but I have no experience with XP. >> >> Keeping in mind that your experience may vary, here is my route to >> success: >> >> First, backup your Windows HVM before attempting to pass any PCI devices. >> >> Make certain that Dom0 has been freshly booted to ensure that the PCI >> card only initializes once. The leading cause to trouble from my >> experience is passing the card more than once at any point during the >> installation, which leads to a BSoD during the process OR a badly >> damaged install which can range from BSoD on reboot only to gradual >> buggy experiences and BSoD's on first boot. >> >> Prior to passing the PCI card to Windows 7 or Windows 8 be sure to >> turn off all automatic driver installation settings (there are more >> than one). If using Windows 8 do not add the card to the >> configuration, instead let it boot and then use `xl pci-attach`, >> since Windows 8 will attempt to install a driver at boot time and >> reboot without ever displaying anything on screen. >> >> Once the installation has completed it may ask you to reboot, instead >> shut down Windows and reboot Dom0 then start Windows again. This >> avoids any post-install processes from attempting to communicate with >> the card in its buggy (previously initialized) state, which could >> muck up the installation. >> >> I have used the above rules successfully more than a dozen times now, >> and never once had a BSoD when I followed them. >> >> Finally, the reason for the backup at the beginning is that anytime I >> failed to follow the above rules, I was not able to fix the problem >> by removing and installing the drivers again. In fact, that never >> once worked and I wasted a few days trying several times without >> success. So in short, if you fail don't bother removing the drivers >> and trying again, instead restore from an image backup of the machine >> that has never once seen your PCI device. >> >> >> I hope this information helps. >> >> Sincerely, >> >> Casey DeLorme >> >> >> On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki >> > wrote: >> >> Matthias, hi! >> >> I've tried Catalyst 12.10 and even 12.1, but xen behavior kept >> the same on and on (_VGA passthru worked only as secondary device >> and dom0 freshly rebooted_). As requested, I'm sending you the >> hvm configuration files from windows-xp and windows-7, my lspci >> -vv, uname and the kernel configuration file. >> >> Do you have any idea how I can make this work? >> >> >> >> 2013/3/4 Guilherme Suzuki > > >> >> Alright! >> >> I'm gonna try catalyst 12-10 (after deinstalling and checking >> if the passthru works rebooting and so on). >> >> I'll send my domU config as soon as I get home. >> >> One more question: does it matter if I use intel onboard >> graphics with the dom0 and xen-pciback(radeon device pci)? >> Cause that would be the reason primary VGA passthru did not >> work... >> >> Thx, xen guys are awesome! =D >> >>> On Mar 4, 2013 2:07 PM, "Matthias" >>> >> > wrote: >>> >>> Hi, >>> >>> good news, since you said your winxp was able to boot with vga >>> passthrough just fine, your FLR seems to work fine and this >>> might >>> 'only' be a driver-related problem. >>> >>> What you can do is deinstall your catalyst drivers. After >>> rebooting, >>> Win7 will fallback on a windows-standard driver for the vga >>> but when >>> it correctly says the vga name (like ATI Radeion HD whatever >>> Series), >>> it actually is falling back to an older catalyst version >>> which is >>> shipped per default with windows. I have found this much >>> more stable >>> on reboots then the newest driver. Also, deinstall Catalyst >>> / Vision >>> control center and at best everything the catalyst installer >>> lets you >>> deinstall. >>> >>> If vga passthrough works without all the drivers and you >>> really want >>> the latest and greatest catalyst, i recommend not using the >>> latest >>> 13-1 because it creates a similar behavior you mentioned on my >>> machine. But catalyst 12-10 seems to work fine, so i would >>> advice you >>> trying that one. >>> >>> >>> If it still doesn't work with deinstalled drivers, we can >>> try a patch >>> i'm currently testing.. But this the patch is somewhat >>> complicated to >>> install, let's stick with the simple things for the moment. >>> >>> Also, your domU config still would be of help ruling out some >>> misconfiguration there.. >>> >>> >>> >>> 2013/3/4 Guilherme Suzuki >> >: >>> > Sorry (hit send). >>> > >>> > So, the radeon device tells it couldnt start itself (code >>> 10) and cirrus >>> > d... >> >> >> >> >> -- >> Grato, >> >> *Guilherme Suzuki* >> Consultor em TI para projetos Microsoft >> *http://www.guilhermesuzuki.com* >> 11 - 992360535 >> 11 - 20990757 >> >> >> >> _______________________________________________ >> 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 > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str. 2 > 21502 Geesthacht > Germany > Tel: +49 4152 889 300 > Fax: +49 4152 889 333 > E-mail: peter.maloney@brockmann-consult.de > Internet: http://www.brockmann-consult.de > -------------------------------------------- -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --------------020502040803010102080600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got 2.


On 2013-03-05 09:35, Peter Maloney wrote:
A few things I can add...

My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10.

I *never* got windows xp to use the passed through gfx card unless I set "stdvga=1" (which means to replace the cirrus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD)

I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead of a "shutdown" and "start", like Casey described. However, when this happens, I can simply "xm destroy ..." and "xm create ..." again, and it works 100%.

I have never needed to reboot dom0 to start a vm, except:
1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me)
2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen)

And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think).



On 2013-03-05 05:25, Casey DeLorme wrote:
Hello Guilherme, was following your exchange and wanted to see how this turned out.

Secondary Passthrough works with AMD, but for primary you need to apply custom patches.  There is another email chain circling the mailing list with links to some fresh patches.

As Matthias mentioned, passthrough is working, but I am quite certain FLR is interfering which has led to driver related BSoD's.

My understanding is that FLR allows a virtual machine to issue a reset to a piece of hardware, and without it that device's state cannot be cleared.  Consumer cards do not come with FLR, and no patch for this is available.

What this means is that when you first boot your virtual machine, the card is initialized and performs just fine.  When you shut down Windows 7 or XP and start either one back up you may encounter a BSoD.  This is because the card is being initialized a second time.

For me and many others rebooting has led to degraded performance instead of a BSoD, which can be fixed by manually ejecting the card with the "safely eject media" tool.  However experiences vary.


I am using an AMD Radeon HD 6870 with 12.10 catalyst drivers, and it is working just fine.  I have had this working in both Windows 7 and Windows 8, but I have no experience with XP.

Keeping in mind that your experience may vary, here is my route to success:

First, backup your Windows HVM before attempting to pass any PCI devices.

Make certain that Dom0 has been freshly booted to ensure that the PCI card only initializes once.  The leading cause to trouble from my experience is passing the card more than once at any point during the installation, which leads to a BSoD during the process OR a badly damaged install which can range from BSoD on reboot only to gradual buggy experiences and BSoD's on first boot.

Prior to passing the PCI card to Windows 7 or Windows 8 be sure to turn off all automatic driver installation settings (there are more than one).  If using Windows 8 do not add the card to the configuration, instead let it boot and then use `xl pci-attach`, since Windows 8 will attempt to install a driver at boot time and reboot without ever displaying anything on screen.

Once the installation has completed it may ask you to reboot, instead shut down Windows and reboot Dom0 then start Windows again.  This avoids any post-install processes from attempting to communicate with the card in its buggy (previously initialized) state, which could muck up the installation.

I have used the above rules successfully more than a dozen times now, and never once had a BSoD when I followed them.

Finally, the reason for the backup at the beginning is that anytime I failed to follow the above rules, I was not able to fix the problem by removing and installing the drivers again.  In fact, that never once worked and I wasted a few days trying several times without success.  So in short, if you fail don't bother removing the drivers and trying again, instead restore from an image backup of the machine that has never once seen your PCI device.


I hope this information helps.

Sincerely,

Casey DeLorme


On Mon, Mar 4, 2013 at 9:43 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
Matthias, hi!

I've tried Catalyst 12.10 and even 12.1, but xen behavior kept the same on and on (VGA passthru worked only as secondary device and dom0 freshly rebooted). As requested, I'm sending you the hvm configuration files from windows-xp and windows-7, my lspci -vv, uname and the kernel configuration file.

Do you have any idea how I can make this work?



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>

Alright!

I'm gonna try catalyst 12-10 (after deinstalling and checking if the passthru works rebooting and so on).

I'll send my domU config as soon as I get home.

One more question: does it matter if I use intel onboard graphics with the dom0 and xen-pciback(radeon device pci)? Cause that would be the reason primary VGA passthru did not work...

Thx, xen guys are awesome! =D

On Mar 4, 2013 2:07 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

good news, since you said your winxp was able to boot with vga
passthrough just fine, your FLR seems to work fine and this might
'only' be a driver-related problem.

What you can do is deinstall your catalyst drivers. After rebooting,
Win7 will fallback on a windows-standard driver for the vga but when
it correctly says the vga name (like ATI Radeion HD whatever Series),
it actually is falling back to an older catalyst version which is
shipped per default with windows. I have found this much more stable
on reboots then the newest driver. Also, deinstall Catalyst / Vision
control center and at best everything the catalyst installer lets you
deinstall.

If vga passthrough works without all the drivers and you really want
the latest and greatest catalyst, i recommend not using the latest
13-1 because it creates a similar behavior you mentioned on my
machine. But catalyst 12-10 seems to work fine, so i would advice you
trying that one.


If it still doesn't work with deinstalled drivers, we can try a patch
i'm currently testing.. But this the patch is somewhat complicated to
install, let's stick with the simple things for the moment.

Also, your domU config still would be of help ruling out some
misconfiguration there..



2013/3/4 Guilherme Suzuki <suzuki.gui@gmail.com>:
> Sorry (hit send).
>
> So, the radeon device tells it couldnt start itself (code 10) and cirrus
> d...



--
Grato,

Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
11 - 992360535
11 - 20990757
 

_______________________________________________
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


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------
--------------020502040803010102080600-- --===============6389669649966058501== 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 --===============6389669649966058501==-- From xen-users-bounces@lists.xen.org Tue Mar 05 11:40:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 11:40: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 1UCqDf-0004On-S2; Tue, 05 Mar 2013 11:39:43 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCqDd-0004Oi-Pj for xen-users@lists.xen.org; Tue, 05 Mar 2013 11:39:42 +0000 Received: from [85.158.137.99:50929] by server-14.bemta-3.messagelabs.com id 23/8C-27076-C79D5315; Tue, 05 Mar 2013 11:39:40 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1362483578!19212718!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11502 invoked from network); 5 Mar 2013 11:39:39 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 11:39:39 -0000 Received: by mail-ie0-f173.google.com with SMTP id 9so7662165iec.18 for ; Tue, 05 Mar 2013 03:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jRY8YDpYOAY1wLcKhCF6VdLKoYTaHY0X4U3c5nEoT1E=; b=cFrgEZJJUyuI6Pu5sz+RG7ar+aAI4bAzqLTyW7lV1OCWFfCbZfXPbfU3H//iltd+1K 9awfh3gzy48v6KwvMwSy8c+7sVX9vgT+dnC3q/3TWtCINamvN+PuzBQ3xqSSYeVxFrLT gW0VicnvWr47ZTLcFbZNtDkFjJrZuhluAF4Q0oDbaPiYT0SY72JWtBBcwF8h/n/pbtvT QZxUIE8sZUse0WKE+NOEc2WZPDtLk4kJta+7xLEKo4hiJAKcUfoRLKDKIDGIiZaFlEFQ z+WCRkCKqqpAvGM8M8ap8CqXKG9LjSExLcxuAWMg1CsdFjZxr1sa9tzvuD/qp1yTioB4 zWXw== MIME-Version: 1.0 X-Received: by 10.50.140.67 with SMTP id re3mr5714825igb.100.1362483577739; Tue, 05 Mar 2013 03:39:37 -0800 (PST) Received: by 10.64.92.198 with HTTP; Tue, 5 Mar 2013 03:39:36 -0800 (PST) Received: by 10.64.92.198 with HTTP; Tue, 5 Mar 2013 03:39:36 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 5 Mar 2013 08:39:36 -0300 Message-ID: From: Guilherme Suzuki To: Peter Maloney Cc: xen-users@lists.xen.org, Casey DeLorme , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============7741359540481604803==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7741359540481604803== Content-Type: multipart/alternative; boundary=e89a8f838b95a9e3a104d72bed54 --e89a8f838b95a9e3a104d72bed54 Content-Type: text/plain; charset=ISO-8859-1 Casey DeLorme, I noticed what you have said... it works for me only for the first time (dom0 just booted). Peter Maloney, I did not know that xm destroy and xm create could make things work again! But it got me thinking, cause I'm passing thru a USB controller FLR disabled. Let me try this: I'll prepare another installation with fedora 18, install xen from RPM (since I downloaded the unstable source code, rev 26667), and start over without passingthru everything that I wanted at once (just the VGA) to see what happens. I'm gonna do this, installing from RPM, based on what the wiki says (secondary VGA passthru will work out-of-box). I'll let you guys know... On Mar 5, 2013 5:39 AM, "Peter Maloney" wrote: grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got 2. On 2013-03-05 09:35, Peter Maloney wrote: A few things I can add... My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10. I *never* got windows xp to use the passed through gfx card unless I set "stdvga=1" (which means to replace the cirrus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD) I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead of a "shutdown" and "start", like Casey described. However, when this happens, I can simply "xm destroy ..." and "xm create ..." again, and it works 100%. I have never needed to reboot dom0 to start a vm, except: 1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me) 2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen) And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think). > > > > On 2013-03-05 05:25, Casey DeLorme wrote: >> >> Hello Guilherme, was following your exchange and wanted to see how this turned out. >> >> Seco... -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --e89a8f838b95a9e3a104d72bed54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Casey DeLorme, I noticed what you have said... it works for me only for = the first time (dom0 just booted).

Peter Maloney, I did not know that xm destroy and xm create could make t= hings work again! But it got me thinking, cause I'm passing thru a USB = controller FLR disabled.

Let me try this: I'll prepare another installation with fedora 18, i= nstall xen from RPM (since I downloaded the unstable source code, rev 26667= ), and start over without passingthru everything that I wanted at once (jus= t the VGA) to see what happens.

I'm gonna do this, installing from RPM, based on what the wiki says = (secondary VGA passthru will work out-of-box). I'll let you guys know..= .

On Mar 5, 2013 5:39 AM, "Peter Maloney" <peter.maloney@brockmann-consult.de&= gt; wrote:

=20 =20 =20

grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if yo= u got 2.


On 2013-03-05 09:35, Peter Maloney wrote:
A few things I can add...

My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10.

I *never* got windows xp to use the passed through gfx card unless I set "stdvga=3D1" (which means to replace the cir= rus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD)

I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead= of a "shutdown" and "start", like Casey described. H= owever, when this happens, I can simply "xm destroy ..." and "xm creat= e ..." again, and it works 100%.

I have never needed to reboot dom0 to start a vm, except:
1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me)
2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen)

And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think).


>>
>
> On 2013-03-05 05:25, Casey DeLorme wrote:

=

>>
>> Hello Guilherme, was = following your exchange and wanted to see how this turned out.
>>
>> Seco...

--=20

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: htt=
p://www.brockmann-consult.de
--------------------------------------------


--=20

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: htt=
p://www.brockmann-consult.de
--------------------------------------------

--e89a8f838b95a9e3a104d72bed54-- --===============7741359540481604803== 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 --===============7741359540481604803==-- From xen-users-bounces@lists.xen.org Tue Mar 05 11:40:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 11:40: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 1UCqDf-0004On-S2; Tue, 05 Mar 2013 11:39:43 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCqDd-0004Oi-Pj for xen-users@lists.xen.org; Tue, 05 Mar 2013 11:39:42 +0000 Received: from [85.158.137.99:50929] by server-14.bemta-3.messagelabs.com id 23/8C-27076-C79D5315; Tue, 05 Mar 2013 11:39:40 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1362483578!19212718!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11502 invoked from network); 5 Mar 2013 11:39:39 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 11:39:39 -0000 Received: by mail-ie0-f173.google.com with SMTP id 9so7662165iec.18 for ; Tue, 05 Mar 2013 03:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jRY8YDpYOAY1wLcKhCF6VdLKoYTaHY0X4U3c5nEoT1E=; b=cFrgEZJJUyuI6Pu5sz+RG7ar+aAI4bAzqLTyW7lV1OCWFfCbZfXPbfU3H//iltd+1K 9awfh3gzy48v6KwvMwSy8c+7sVX9vgT+dnC3q/3TWtCINamvN+PuzBQ3xqSSYeVxFrLT gW0VicnvWr47ZTLcFbZNtDkFjJrZuhluAF4Q0oDbaPiYT0SY72JWtBBcwF8h/n/pbtvT QZxUIE8sZUse0WKE+NOEc2WZPDtLk4kJta+7xLEKo4hiJAKcUfoRLKDKIDGIiZaFlEFQ z+WCRkCKqqpAvGM8M8ap8CqXKG9LjSExLcxuAWMg1CsdFjZxr1sa9tzvuD/qp1yTioB4 zWXw== MIME-Version: 1.0 X-Received: by 10.50.140.67 with SMTP id re3mr5714825igb.100.1362483577739; Tue, 05 Mar 2013 03:39:37 -0800 (PST) Received: by 10.64.92.198 with HTTP; Tue, 5 Mar 2013 03:39:36 -0800 (PST) Received: by 10.64.92.198 with HTTP; Tue, 5 Mar 2013 03:39:36 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 5 Mar 2013 08:39:36 -0300 Message-ID: From: Guilherme Suzuki To: Peter Maloney Cc: xen-users@lists.xen.org, Casey DeLorme , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============7741359540481604803==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7741359540481604803== Content-Type: multipart/alternative; boundary=e89a8f838b95a9e3a104d72bed54 --e89a8f838b95a9e3a104d72bed54 Content-Type: text/plain; charset=ISO-8859-1 Casey DeLorme, I noticed what you have said... it works for me only for the first time (dom0 just booted). Peter Maloney, I did not know that xm destroy and xm create could make things work again! But it got me thinking, cause I'm passing thru a USB controller FLR disabled. Let me try this: I'll prepare another installation with fedora 18, install xen from RPM (since I downloaded the unstable source code, rev 26667), and start over without passingthru everything that I wanted at once (just the VGA) to see what happens. I'm gonna do this, installing from RPM, based on what the wiki says (secondary VGA passthru will work out-of-box). I'll let you guys know... On Mar 5, 2013 5:39 AM, "Peter Maloney" wrote: grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got 2. On 2013-03-05 09:35, Peter Maloney wrote: A few things I can add... My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10. I *never* got windows xp to use the passed through gfx card unless I set "stdvga=1" (which means to replace the cirrus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD) I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead of a "shutdown" and "start", like Casey described. However, when this happens, I can simply "xm destroy ..." and "xm create ..." again, and it works 100%. I have never needed to reboot dom0 to start a vm, except: 1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me) 2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen) And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think). > > > > On 2013-03-05 05:25, Casey DeLorme wrote: >> >> Hello Guilherme, was following your exchange and wanted to see how this turned out. >> >> Seco... -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --e89a8f838b95a9e3a104d72bed54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Casey DeLorme, I noticed what you have said... it works for me only for = the first time (dom0 just booted).

Peter Maloney, I did not know that xm destroy and xm create could make t= hings work again! But it got me thinking, cause I'm passing thru a USB = controller FLR disabled.

Let me try this: I'll prepare another installation with fedora 18, i= nstall xen from RPM (since I downloaded the unstable source code, rev 26667= ), and start over without passingthru everything that I wanted at once (jus= t the VGA) to see what happens.

I'm gonna do this, installing from RPM, based on what the wiki says = (secondary VGA passthru will work out-of-box). I'll let you guys know..= .

On Mar 5, 2013 5:39 AM, "Peter Maloney" <peter.maloney@brockmann-consult.de&= gt; wrote:

=20 =20 =20

grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if yo= u got 2.


On 2013-03-05 09:35, Peter Maloney wrote:
A few things I can add...

My card is a Sapphire Radeon HD 6770. And I'm currently using catalyst version 12-10.

I *never* got windows xp to use the passed through gfx card unless I set "stdvga=3D1" (which means to replace the cir= rus logic card (that works in winxp) with another (that doesn't work in xp), so it then uses the secondary gpu like I wanted. Win7 and 8 work without this. (and FYI xp is the worst performer by far, maybe from a xen bug that only affects AMD cpus, and 4.2.x is unusably slow in xp, definitely a bug affecting just AMD)

I very rarely get any problem booting and getting graphics to work, and never on the first boot. Every time there is an error, it is from a "restart" (such as a windows update) instead= of a "shutdown" and "start", like Casey described. H= owever, when this happens, I can simply "xm destroy ..." and "xm creat= e ..." again, and it works 100%.

I have never needed to reboot dom0 to start a vm, except:
1. to get my USB IRQ to work again in dom0 (without this, my keyboard and mouse are laggy and miss keystrokes). I have passed through a USB controller that lacks FLR, so if the vm dies incorrectly [not a shutdown], dom0 broadcasts that it is disabling an irq. If I start the domu again, the usb works fine in domu, but never dom0 until reboot. (I've only caused this with crashing domu's from kernel oopses from #2, and with gplpv network drivers which never seem to work right for me)
2. testing broken kernels (3.7-rc2, etc. with broken network) (in this case, every domu I try to create after the first problem starts with a blank screen, and vnc usually is blank or just says "parallell0" instead of a console screen)

And last, contradictory to what the others said, win7 gfx passthrough never worked for me without installing the catalyst drivers first in winxp or win7. Win8 worked though, one time even in the installer (depends on whether the monitor is plugged in at the right time I think).


>>
>
> On 2013-03-05 05:25, Casey DeLorme wrote:

=

>>
>> Hello Guilherme, was = following your exchange and wanted to see how this turned out.
>>
>> Seco...

--=20

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: htt=
p://www.brockmann-consult.de
--------------------------------------------


--=20

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: htt=
p://www.brockmann-consult.de
--------------------------------------------

--e89a8f838b95a9e3a104d72bed54-- --===============7741359540481604803== 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 --===============7741359540481604803==-- From xen-users-bounces@lists.xen.org Tue Mar 05 11:46:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 11:46: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 1UCqJO-0004er-0c; Tue, 05 Mar 2013 11:45:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCqJM-0004eg-Tr for xen-users@lists.xen.org; Tue, 05 Mar 2013 11:45:37 +0000 Received: from [85.158.138.51:32895] by server-3.bemta-3.messagelabs.com id 13/8B-26934-BDAD5315; Tue, 05 Mar 2013 11:45:31 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1362483929!28628791!1 X-Originating-IP: [209.85.210.180] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6059 invoked from network); 5 Mar 2013 11:45:30 -0000 Received: from mail-ia0-f180.google.com (HELO mail-ia0-f180.google.com) (209.85.210.180) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 11:45:30 -0000 Received: by mail-ia0-f180.google.com with SMTP id f27so5836523iae.39 for ; Tue, 05 Mar 2013 03:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0eWotMIlXbrceJC+jh98BD9+OEDbRqS/X+3Np3J74ZQ=; b=oDRRvJPk/J7pDF9D2flhouzzy2jlh53EwSWDJcEPSo5969IWJbvmM6LaQveXfP9zuR T2fL7/R4dcHtob0bVRKb1yg9Gkb6Rzq1x0RQ3ts2G148tdogg3vU1dUtwVkgQyGpx0LS OxtQxjEAuaP6wPCRjUAqwZZCqIw5mR2pPX2z9mwj4ClVwjfWIrM0gC+FApApV74MKOiF BLmTPbz+bBsYcMys/1mdURvHxAXZs/jS9yYkqSjzyP3EjMqXaAZAQCq+Ju07qeuZGkdr lxUXqT84ZuvxfaArL1kq9zJPHzC/qR9ZWlHE28VcigX4aZaOijGhw/Iosik8H9qNzZyb 65AA== MIME-Version: 1.0 X-Received: by 10.42.150.131 with SMTP id a3mr10051621icw.8.1362483929101; Tue, 05 Mar 2013 03:45:29 -0800 (PST) Received: by 10.64.92.198 with HTTP; Tue, 5 Mar 2013 03:45:29 -0800 (PST) Received: by 10.64.92.198 with HTTP; Tue, 5 Mar 2013 03:45:29 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 5 Mar 2013 08:45:29 -0300 Message-ID: From: Guilherme Suzuki To: Peter Maloney Cc: xen-users@lists.xen.org, Casey DeLorme , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============1840813454261860315==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1840813454261860315== Content-Type: multipart/alternative; boundary=90e6ba6e83589b40d404d72c029c --90e6ba6e83589b40d404d72c029c Content-Type: text/plain; charset=ISO-8859-1 Ow, by the way, thanks guys for the support! Who tells that linux guys can't get help? Have a good day... :) On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" wrote: Casey DeLorme, I noticed what you have said... it works for me only for the first time (dom0 just booted). Peter Maloney, I did not know that xm destroy and xm create could make things work again! But it got me thinking, cause I'm passing thru a USB controller FLR disabled. Let me try this: I'll prepare another installation with fedora 18, install xen from RPM (since I downloaded the unstable source code, rev 26667), and start over without passingthru everything that I wanted at once (just the VGA) to see what happens. I'm gonna do this, installing from RPM, based on what the wiki says (secondary VGA passthru will work out-of-box). I'll let you guys know... On Mar 5, 2013 5:39 AM, "Peter Maloney" wrote: grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got... > > A few things I can add... > > My card is a Sapphire Radeon HD 6770. And I'm currently using cata... > > >> > >> Hello Guilherme, was following your exchange and wanted to see how this turned out. > >... >> Seco... > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-... -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str... --90e6ba6e83589b40d404d72c029c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Ow, by the way, thanks guys for the support!

Who tells that linux guys can't get help? Have a good day... :)

On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Case= y DeLorme, I noticed what you have said... it works for me only for the fir= st time (dom0 just booted).

Peter Maloney, I did not know that xm destroy and xm create could make t= hings work again! But it got me thinking, cause I'm passing thru a USB = controller FLR disabled.

Let me try this: I'll prepare another installation with fedora 18, i= nstall xen from RPM (since I downloaded the unstable source code, rev 26667= ), and start over without passingthru everything that I wanted at once (jus= t the VGA) to see what happens.

I'm gonna do this, installing from RPM, based on what the wiki says = (secondary VGA passthru will work out-of-box). I'll let you guys know..= .



On Mar 5, 2013 5:39 AM, "Peter M= aloney" <pete= r.maloney@brockmann-consult.de> wrote:

grr Thunderbird doesn't cc everyone when I h= it "reply list", sorry for the double message if you got...

>
> A fe= w things I can add...
>
> My card is a Sapphire Radeon HD 6770. And I'm currently us= ing cata...


>
> >>
> >> Hello Guilherme, was following = your exchange and wanted to see how this turned out.
> >...

>> Seco...


>
> --
>
> ------------------------------------= --------
> Peter Maloney
> Brockmann Consult
> Max-...





--

--------= ------------------------------------
Peter Maloney
Brockmann Consult<= br>Max-Planck-Str...

--90e6ba6e83589b40d404d72c029c-- --===============1840813454261860315== 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 --===============1840813454261860315==-- From xen-users-bounces@lists.xen.org Tue Mar 05 11:46:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 11:46: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 1UCqJO-0004er-0c; Tue, 05 Mar 2013 11:45:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCqJM-0004eg-Tr for xen-users@lists.xen.org; Tue, 05 Mar 2013 11:45:37 +0000 Received: from [85.158.138.51:32895] by server-3.bemta-3.messagelabs.com id 13/8B-26934-BDAD5315; Tue, 05 Mar 2013 11:45:31 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1362483929!28628791!1 X-Originating-IP: [209.85.210.180] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6059 invoked from network); 5 Mar 2013 11:45:30 -0000 Received: from mail-ia0-f180.google.com (HELO mail-ia0-f180.google.com) (209.85.210.180) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 11:45:30 -0000 Received: by mail-ia0-f180.google.com with SMTP id f27so5836523iae.39 for ; Tue, 05 Mar 2013 03:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0eWotMIlXbrceJC+jh98BD9+OEDbRqS/X+3Np3J74ZQ=; b=oDRRvJPk/J7pDF9D2flhouzzy2jlh53EwSWDJcEPSo5969IWJbvmM6LaQveXfP9zuR T2fL7/R4dcHtob0bVRKb1yg9Gkb6Rzq1x0RQ3ts2G148tdogg3vU1dUtwVkgQyGpx0LS OxtQxjEAuaP6wPCRjUAqwZZCqIw5mR2pPX2z9mwj4ClVwjfWIrM0gC+FApApV74MKOiF BLmTPbz+bBsYcMys/1mdURvHxAXZs/jS9yYkqSjzyP3EjMqXaAZAQCq+Ju07qeuZGkdr lxUXqT84ZuvxfaArL1kq9zJPHzC/qR9ZWlHE28VcigX4aZaOijGhw/Iosik8H9qNzZyb 65AA== MIME-Version: 1.0 X-Received: by 10.42.150.131 with SMTP id a3mr10051621icw.8.1362483929101; Tue, 05 Mar 2013 03:45:29 -0800 (PST) Received: by 10.64.92.198 with HTTP; Tue, 5 Mar 2013 03:45:29 -0800 (PST) Received: by 10.64.92.198 with HTTP; Tue, 5 Mar 2013 03:45:29 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 5 Mar 2013 08:45:29 -0300 Message-ID: From: Guilherme Suzuki To: Peter Maloney Cc: xen-users@lists.xen.org, Casey DeLorme , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============1840813454261860315==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1840813454261860315== Content-Type: multipart/alternative; boundary=90e6ba6e83589b40d404d72c029c --90e6ba6e83589b40d404d72c029c Content-Type: text/plain; charset=ISO-8859-1 Ow, by the way, thanks guys for the support! Who tells that linux guys can't get help? Have a good day... :) On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" wrote: Casey DeLorme, I noticed what you have said... it works for me only for the first time (dom0 just booted). Peter Maloney, I did not know that xm destroy and xm create could make things work again! But it got me thinking, cause I'm passing thru a USB controller FLR disabled. Let me try this: I'll prepare another installation with fedora 18, install xen from RPM (since I downloaded the unstable source code, rev 26667), and start over without passingthru everything that I wanted at once (just the VGA) to see what happens. I'm gonna do this, installing from RPM, based on what the wiki says (secondary VGA passthru will work out-of-box). I'll let you guys know... On Mar 5, 2013 5:39 AM, "Peter Maloney" wrote: grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got... > > A few things I can add... > > My card is a Sapphire Radeon HD 6770. And I'm currently using cata... > > >> > >> Hello Guilherme, was following your exchange and wanted to see how this turned out. > >... >> Seco... > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-... -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str... --90e6ba6e83589b40d404d72c029c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Ow, by the way, thanks guys for the support!

Who tells that linux guys can't get help? Have a good day... :)

On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Case= y DeLorme, I noticed what you have said... it works for me only for the fir= st time (dom0 just booted).

Peter Maloney, I did not know that xm destroy and xm create could make t= hings work again! But it got me thinking, cause I'm passing thru a USB = controller FLR disabled.

Let me try this: I'll prepare another installation with fedora 18, i= nstall xen from RPM (since I downloaded the unstable source code, rev 26667= ), and start over without passingthru everything that I wanted at once (jus= t the VGA) to see what happens.

I'm gonna do this, installing from RPM, based on what the wiki says = (secondary VGA passthru will work out-of-box). I'll let you guys know..= .



On Mar 5, 2013 5:39 AM, "Peter M= aloney" <pete= r.maloney@brockmann-consult.de> wrote:

grr Thunderbird doesn't cc everyone when I h= it "reply list", sorry for the double message if you got...

>
> A fe= w things I can add...
>
> My card is a Sapphire Radeon HD 6770. And I'm currently us= ing cata...


>
> >>
> >> Hello Guilherme, was following = your exchange and wanted to see how this turned out.
> >...

>> Seco...


>
> --
>
> ------------------------------------= --------
> Peter Maloney
> Brockmann Consult
> Max-...





--

--------= ------------------------------------
Peter Maloney
Brockmann Consult<= br>Max-Planck-Str...

--90e6ba6e83589b40d404d72c029c-- --===============1840813454261860315== 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 --===============1840813454261860315==-- From xen-users-bounces@lists.xen.org Tue Mar 05 17:23:51 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 17:23: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 1UCvZb-000764-Op; Tue, 05 Mar 2013 17:22:43 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCvZZ-00075z-TH for xen-users@lists.xen.org; Tue, 05 Mar 2013 17:22:42 +0000 Received: from [85.158.137.99:19481] by server-5.bemta-3.messagelabs.com id 08/E5-30636-1E926315; Tue, 05 Mar 2013 17:22:41 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1362504159!17035537!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDI1NzE=\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17469 invoked from network); 5 Mar 2013 17:22:40 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 17:22:40 -0000 X-IronPort-AV: E=Sophos;i="4.84,787,1355097600"; d="scan'208";a="11267189" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 05 Mar 2013 17:22:39 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Mar 2013 12:22:38 -0500 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UCvZW-0007Lz-BK; Tue, 05 Mar 2013 17:22:38 +0000 Date: Tue, 5 Mar 2013 17:22:38 +0000 From: Wei Liu To: Mohammad Reza Gerami Message-ID: <20130305172238.GA11446@zion.uk.xensource.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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, Mar 02, 2013 at 09:23:46AM +0000, Mohammad Reza Gerami wrote: > Dear Friends > > I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I have 64 > I installed CentOS 6.3 64 bit and install my software > but when I run job and check, Maximum 16 core use in my system > What do you mean by "run job and check"? How many CPUs are there in your /proc/cpuinfo? If you're seeing 64 CPUs, you're probably hitting limits in your guests. Wei. > what is your idea? > > thank you > _______________________________________________ > 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 Mar 05 17:23:51 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 17:23: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 1UCvZb-000764-Op; Tue, 05 Mar 2013 17:22:43 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCvZZ-00075z-TH for xen-users@lists.xen.org; Tue, 05 Mar 2013 17:22:42 +0000 Received: from [85.158.137.99:19481] by server-5.bemta-3.messagelabs.com id 08/E5-30636-1E926315; Tue, 05 Mar 2013 17:22:41 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1362504159!17035537!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDI1NzE=\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17469 invoked from network); 5 Mar 2013 17:22:40 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 17:22:40 -0000 X-IronPort-AV: E=Sophos;i="4.84,787,1355097600"; d="scan'208";a="11267189" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 05 Mar 2013 17:22:39 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.318.1; Tue, 5 Mar 2013 12:22:38 -0500 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UCvZW-0007Lz-BK; Tue, 05 Mar 2013 17:22:38 +0000 Date: Tue, 5 Mar 2013 17:22:38 +0000 From: Wei Liu To: Mohammad Reza Gerami Message-ID: <20130305172238.GA11446@zion.uk.xensource.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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, Mar 02, 2013 at 09:23:46AM +0000, Mohammad Reza Gerami wrote: > Dear Friends > > I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I have 64 > I installed CentOS 6.3 64 bit and install my software > but when I run job and check, Maximum 16 core use in my system > What do you mean by "run job and check"? How many CPUs are there in your /proc/cpuinfo? If you're seeing 64 CPUs, you're probably hitting limits in your guests. Wei. > what is your idea? > > thank you > _______________________________________________ > 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 Mar 05 17:46:18 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 17:46: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 1UCvvR-0008EY-Ga; Tue, 05 Mar 2013 17:45:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCvvP-0008EI-4M; Tue, 05 Mar 2013 17:45:15 +0000 Received: from [85.158.138.51:55810] by server-12.bemta-3.messagelabs.com id 17/87-01357-52F26315; Tue, 05 Mar 2013 17:45:09 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1362505508!21140380!1 X-Originating-IP: [74.125.82.172] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12293 invoked from network); 5 Mar 2013 17:45:09 -0000 Received: from mail-we0-f172.google.com (HELO mail-we0-f172.google.com) (74.125.82.172) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 17:45:09 -0000 Received: by mail-we0-f172.google.com with SMTP id d46so2353738wer.31 for ; Tue, 05 Mar 2013 09:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=IIydHyDgilChOFKir3AzZ1WwCLly6/OF4INViQb28ss=; b=XNkd5Azd4oXzvQI8svYPJJqgvoHiH4tICbtE9CKB3ipXfQETaL0D4PdYbBVxyVLcXR dc3+whV8kOvM1VlEXPgmDyVHzguU/0EwTbLTwB5Fa8W0gOjjfgKS16dlLmm/bnXighe3 a+rgViP/eHh+cUi0O9NA0oQzMkXBuSQU8DdMAjXT9iKnYvDPvZnSBm4C/KwHcD8tBqdw BzgYQKhiNtjWcut4h2jR5S7bAGRui8bjGWV/qaSAMmTUnl+q6dZBvNjzabUfDdNAsk26 gCOBh6WTQaefO0YdM3bHNhWLJkANL7hx3H77pYEEV5HKG7sqVEzlOhxQ5PXaIBqOewTR Yx1g== X-Received: by 10.180.84.162 with SMTP id a2mr20444160wiz.14.1362505501116; Tue, 05 Mar 2013 09:45:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 5 Mar 2013 09:44:40 -0800 (PST) In-Reply-To: References: From: Matthias Date: Tue, 5 Mar 2013 18:44:40 +0100 Message-ID: To: xen-users@lists.xen.org Cc: xen-devel@lists.xen.org Subject: Re: [Xen-users] dual vga passthrough issue in xen unstable X-BeenThere: xen-users@lists.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 did some furthor testing and found out that this is perfectly reproducable and keeps crashing everytime. I tested this with different kernel (3.7.4 and 3.8.2), different domU config options (pae, apic, acpi, pci_msitranslate, pci_permissive, pci_powermanagement etc.) and with both traditional and upstream QEMU. So since this seems to be a bug and not some usage issue, I'm including xen-devel on this. Any help on resolving or even debugging this furthor would be welcome. (System: Debian Wheezy, Vanilla 3.8.2 kernel, latest xen-unstable staging git tree) 2013/3/3 Matthias : > Hi, > > I have the following problem: > > I have two vga cards, an AMD HD5450 and a HD5700.. When I hide both > via pciback.hide at boot time, start a win7 domU passing through one > of the cards, vga passthrough works fine, but when i then shutdown the > win7 domU, the whole dom0 hangs and i have to reset the whole server. > > When I do the same with only one vga hidden and one for the dom0, it > works without problems. > > Logs don't show something suspiciously and i don't know how i can > debug this, so unfortunatly i'm in a bit of a dead end here. Does > anyone have an idea what can cause this or how i can resolve this? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 05 17:46:18 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 17:46: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 1UCvvR-0008EY-Ga; Tue, 05 Mar 2013 17:45:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCvvP-0008EI-4M; Tue, 05 Mar 2013 17:45:15 +0000 Received: from [85.158.138.51:55810] by server-12.bemta-3.messagelabs.com id 17/87-01357-52F26315; Tue, 05 Mar 2013 17:45:09 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1362505508!21140380!1 X-Originating-IP: [74.125.82.172] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12293 invoked from network); 5 Mar 2013 17:45:09 -0000 Received: from mail-we0-f172.google.com (HELO mail-we0-f172.google.com) (74.125.82.172) by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 17:45:09 -0000 Received: by mail-we0-f172.google.com with SMTP id d46so2353738wer.31 for ; Tue, 05 Mar 2013 09:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=IIydHyDgilChOFKir3AzZ1WwCLly6/OF4INViQb28ss=; b=XNkd5Azd4oXzvQI8svYPJJqgvoHiH4tICbtE9CKB3ipXfQETaL0D4PdYbBVxyVLcXR dc3+whV8kOvM1VlEXPgmDyVHzguU/0EwTbLTwB5Fa8W0gOjjfgKS16dlLmm/bnXighe3 a+rgViP/eHh+cUi0O9NA0oQzMkXBuSQU8DdMAjXT9iKnYvDPvZnSBm4C/KwHcD8tBqdw BzgYQKhiNtjWcut4h2jR5S7bAGRui8bjGWV/qaSAMmTUnl+q6dZBvNjzabUfDdNAsk26 gCOBh6WTQaefO0YdM3bHNhWLJkANL7hx3H77pYEEV5HKG7sqVEzlOhxQ5PXaIBqOewTR Yx1g== X-Received: by 10.180.84.162 with SMTP id a2mr20444160wiz.14.1362505501116; Tue, 05 Mar 2013 09:45:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 5 Mar 2013 09:44:40 -0800 (PST) In-Reply-To: References: From: Matthias Date: Tue, 5 Mar 2013 18:44:40 +0100 Message-ID: To: xen-users@lists.xen.org Cc: xen-devel@lists.xen.org Subject: Re: [Xen-users] dual vga passthrough issue in xen unstable X-BeenThere: xen-users@lists.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 did some furthor testing and found out that this is perfectly reproducable and keeps crashing everytime. I tested this with different kernel (3.7.4 and 3.8.2), different domU config options (pae, apic, acpi, pci_msitranslate, pci_permissive, pci_powermanagement etc.) and with both traditional and upstream QEMU. So since this seems to be a bug and not some usage issue, I'm including xen-devel on this. Any help on resolving or even debugging this furthor would be welcome. (System: Debian Wheezy, Vanilla 3.8.2 kernel, latest xen-unstable staging git tree) 2013/3/3 Matthias : > Hi, > > I have the following problem: > > I have two vga cards, an AMD HD5450 and a HD5700.. When I hide both > via pciback.hide at boot time, start a win7 domU passing through one > of the cards, vga passthrough works fine, but when i then shutdown the > win7 domU, the whole dom0 hangs and i have to reset the whole server. > > When I do the same with only one vga hidden and one for the dom0, it > works without problems. > > Logs don't show something suspiciously and i don't know how i can > debug this, so unfortunatly i'm in a bit of a dead end here. Does > anyone have an idea what can cause this or how i can resolve this? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 05 17:58:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 17:58: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 1UCw7T-0000cR-Iv; Tue, 05 Mar 2013 17:57:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCw7R-0000c8-Kv for xen-users@lists.xen.org; Tue, 05 Mar 2013 17:57:42 +0000 Received: from [193.109.254.147:12283] by server-4.bemta-14.messagelabs.com id 08/A1-17387-51236315; Tue, 05 Mar 2013 17:57:41 +0000 X-Env-Sender: fiala@mfiala.net X-Msg-Ref: server-5.tower-27.messagelabs.com!1362506258!6319471!1 X-Originating-IP: [194.79.52.12] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12736 invoked from network); 5 Mar 2013 17:57:38 -0000 Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12) by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 5 Mar 2013 17:57:38 -0000 Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232] helo=[192.168.95.34]) by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UCw7O-0005VD-1g; Tue, 05 Mar 2013 18:57:38 +0100 Message-ID: <5136320C.8090008@mfiala.net> Date: Tue, 05 Mar 2013 18:57:32 +0100 From: Michal Fiala User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jan Hejl References: <5134D887.5010401@mfiala.net> <5134E323.5080506@excello.cz> <5134E74B.6020409@mfiala.net> In-Reply-To: <5134E74B.6020409@mfiala.net> X-Enigmail-Version: 1.5.1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Exactly set dom0/U memory, increase vcpu count X-BeenThere: xen-users@lists.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 solved, see bellow On 03/04/2013 07:26 PM, Michal Fiala wrote: > On 03/04/2013 07:08 PM, Jan Hejl wrote: >> Hi Michal, > > Hi > >> >> 1) Could you please post your dom0 kernel config options related to XEN? >> Simply with "zgrep XEN /proc/config.gz" or "grep XEN >> /usr/src/linux/.config" ? > > rajvir3 dom0 # grep XEN .config > CONFIG_XEN=y > CONFIG_XEN_DOM0=y > CONFIG_XEN_PRIVILEGED_GUEST=y > CONFIG_XEN_PVHVM=y > CONFIG_XEN_MAX_DOMAIN_MEMORY=128 > CONFIG_XEN_SAVE_RESTORE=y > # CONFIG_XEN_DEBUG_FS is not set > CONFIG_PCI_XEN=y > CONFIG_XEN_PCIDEV_FRONTEND=y > CONFIG_XEN_BLKDEV_FRONTEND=y > CONFIG_XEN_BLKDEV_BACKEND=y > CONFIG_XEN_NETDEV_FRONTEND=y > CONFIG_XEN_NETDEV_BACKEND=y > CONFIG_HVC_XEN=y > # CONFIG_XEN_WDT is not set > CONFIG_XEN_BALLOON=y > CONFIG_XEN_SCRUB_PAGES=y > CONFIG_XEN_DEV_EVTCHN=y > CONFIG_XEN_BACKEND=y > CONFIG_XENFS=y > CONFIG_XEN_COMPAT_XENFS=y > CONFIG_XEN_SYS_HYPERVISOR=y > CONFIG_XEN_XENBUS_FRONTEND=y > CONFIG_XEN_GNTDEV=m > CONFIG_XEN_GRANT_DEV_ALLOC=m > CONFIG_SWIOTLB_XEN=y > CONFIG_XEN_PCIDEV_BACKEND=m > >> >> 2) Is CONFIG_HOTPLUG_CPU enabled in your kernel image? > > Yes > > rajvir3 dom0 # grep CONFIG_HOTPLUG_CPU .config > CONFIG_HOTPLUG_CPU=y > > Michal > >> >> Thanks >> Jan >> >> On 03/04/2013 06:23 PM, Michal Fiala wrote: >>> hallo, >>> >>> I have updated xen server to >>> >>> xen-4.2.1-r2 >>> xen-tools-4.2.1-r1 >>> kernel gentoo-sources-3.2.39 >>> >>> I have found 2 problems >>> >>> 1) Can not exactly set dom0, domU memory >>> >>> I dedicate 4G of memory to dom0 via kernel parameter: >>> >>> dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin >>> >>> Bud the real total memory is set to 2618M after reboot. I have found >>> article describing this behavior >>> (http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone), >>> >>> so I have run >>> >>> echo $((4*1024*1024)) > >>> /sys/devices/system/xen_memory/xen_memory0/target_kb >>> >>> The total memory was se to 3687M. This is better, but not enough. >>> >>> I have tested kernel 3.7, there is not such problem. I would like to use >>> longterm kernel 3.2 so I would like to stay with 3.2. >>> >>> Similar problem exists with domU, config looks like >>> >>> kernel = '/etc/xen/kernels/linux-3.2.39-gentoo' >>> name = 'test1' >>> memory = '4000' >>> maxmem = '12000' >>> vcpus = '8' >>> cpus = '^0,^1,^2,^3' >>> extra = 'elevator=noop gentoo=nodevfs' >>> root = '/dev/xvda1 ro' >>> disk = [ >>> 'phy:/dev/vg1/test1_root,xvda1,w', >>> 'phy:/dev/vg1/test1_var,xvda2,w', >>> ] >>> vif = [ >>> 'mac=00:16:3e:24:11:38,bridge=br0', >>> ] >>> >>> After boot, test1 domain has 3704M total memory (free -m), xm list test1 >>> shows 4000M. >>> >>> When I increase memory amount via xm mem-set test1 8000, then xm list >>> test1 really shows 8000M, but domU has 7704M total memory (free -m). >>> >>> from xend.log >>> [2013-03-04 18:10:18 4627] DEBUG (XendDomainInfo:1467) Setting memory >>> target of domain test1 (1) to 8000 MiB. Xen wiki recommends using last stable kernel, it means 3.8. I have used 3.8.2, where is the problem with dom0 memory solved. domU memory allocation was changed, see http://www.gossamer-threads.com/lists/xen/users/270487?do=post_view_flat >>> >>> 2) I am not able to increase vcpu count to domU. >>> After boot domU test1, it has really 8 vcpus, I am able to decrease >>> vcpus by xm vcpu-set test1 4. Cpus count inside test1 really decreases >>> to 4. Now I would like to increase vcpu count via xm vcpu-list test1 6, >>> but unsuccessfully. >>> >>> rajvir3 configs # xm vcpu-list test1 >>> Name ID VCPU CPU State Time(s) CPU >>> Affinity >>> test1 1 0 15 -b- 3.7 12-23 >>> test1 1 1 23 -b- 2.8 12-23 >>> test1 1 2 18 -b- 1.2 12-23 >>> test1 1 3 20 -b- 1.2 12-23 >>> test1 1 4 16 -b- 1.0 12-23 >>> test1 1 5 12 -b- 3.5 12-23 >>> test1 1 6 19 -b- 0.9 12-23 >>> test1 1 7 14 -b- 0.9 12-23 >>> >>> rajvir3 configs # xm vcpu-set test1 4 >>> >>> rajvir3 configs # xm vcpu-list test1 >>> Name ID VCPU CPU State Time(s) CPU >>> Affinity >>> test1 1 0 15 -b- 3.7 12-23 >>> test1 1 1 23 -b- 2.9 12-23 >>> test1 1 2 18 -b- 1.3 12-23 >>> test1 1 3 20 -b- 1.2 12-23 >>> test1 1 4 - --p 1.0 12-23 >>> test1 1 5 - --p 3.5 12-23 >>> test1 1 6 - --p 1.0 12-23 >>> test1 1 7 - --p 0.9 12-23 >>> >>> rajvir3 configs # xm vcpu-set test1 6 >>> >>> rajvir3 configs # xm vcpu-list test1 >>> Name ID VCPU CPU State Time(s) CPU >>> Affinity >>> test1 1 0 15 -b- 3.8 12-23 >>> test1 1 1 23 -b- 2.9 12-23 >>> test1 1 2 18 -b- 1.3 12-23 >>> test1 1 3 20 -b- 1.3 12-23 >>> test1 1 4 - --p 1.0 12-23 >>> test1 1 5 - --p 3.5 12-23 >>> test1 1 6 - --p 1.0 12-23 >>> test1 1 7 - --p 0.9 12-23 >>> >>> from xend.log >>> >>> [2013-03-04 18:12:58 4627] INFO (XendDomainInfo:1978) Set VCPU count on >>> domain test1 to 4 >>> [2013-03-04 18:14:51 4627] INFO (XendDomainInfo:1978) Set VCPU count on >>> domain test1 to 6 >>> >>> I was not able to increase vcpu count also in kernel 3.7. My domU did not have udev rules to hotplug cpus, follow these instructions http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug >>> >>> Where could be the problem? >>> >>> Thanks >>> >>> Michal >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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 Mar 05 17:58:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 17:58: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 1UCw7T-0000cR-Iv; Tue, 05 Mar 2013 17:57:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCw7R-0000c8-Kv for xen-users@lists.xen.org; Tue, 05 Mar 2013 17:57:42 +0000 Received: from [193.109.254.147:12283] by server-4.bemta-14.messagelabs.com id 08/A1-17387-51236315; Tue, 05 Mar 2013 17:57:41 +0000 X-Env-Sender: fiala@mfiala.net X-Msg-Ref: server-5.tower-27.messagelabs.com!1362506258!6319471!1 X-Originating-IP: [194.79.52.12] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12736 invoked from network); 5 Mar 2013 17:57:38 -0000 Received: from hosweb1.mobil.cz (HELO hosweb1.mobil.cz) (194.79.52.12) by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 5 Mar 2013 17:57:38 -0000 Received: from pra11-b232.adsl.dial-up.cz ([193.86.128.232] helo=[192.168.95.34]) by hosweb1.mobil.cz with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UCw7O-0005VD-1g; Tue, 05 Mar 2013 18:57:38 +0100 Message-ID: <5136320C.8090008@mfiala.net> Date: Tue, 05 Mar 2013 18:57:32 +0100 From: Michal Fiala User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jan Hejl References: <5134D887.5010401@mfiala.net> <5134E323.5080506@excello.cz> <5134E74B.6020409@mfiala.net> In-Reply-To: <5134E74B.6020409@mfiala.net> X-Enigmail-Version: 1.5.1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Exactly set dom0/U memory, increase vcpu count X-BeenThere: xen-users@lists.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 solved, see bellow On 03/04/2013 07:26 PM, Michal Fiala wrote: > On 03/04/2013 07:08 PM, Jan Hejl wrote: >> Hi Michal, > > Hi > >> >> 1) Could you please post your dom0 kernel config options related to XEN? >> Simply with "zgrep XEN /proc/config.gz" or "grep XEN >> /usr/src/linux/.config" ? > > rajvir3 dom0 # grep XEN .config > CONFIG_XEN=y > CONFIG_XEN_DOM0=y > CONFIG_XEN_PRIVILEGED_GUEST=y > CONFIG_XEN_PVHVM=y > CONFIG_XEN_MAX_DOMAIN_MEMORY=128 > CONFIG_XEN_SAVE_RESTORE=y > # CONFIG_XEN_DEBUG_FS is not set > CONFIG_PCI_XEN=y > CONFIG_XEN_PCIDEV_FRONTEND=y > CONFIG_XEN_BLKDEV_FRONTEND=y > CONFIG_XEN_BLKDEV_BACKEND=y > CONFIG_XEN_NETDEV_FRONTEND=y > CONFIG_XEN_NETDEV_BACKEND=y > CONFIG_HVC_XEN=y > # CONFIG_XEN_WDT is not set > CONFIG_XEN_BALLOON=y > CONFIG_XEN_SCRUB_PAGES=y > CONFIG_XEN_DEV_EVTCHN=y > CONFIG_XEN_BACKEND=y > CONFIG_XENFS=y > CONFIG_XEN_COMPAT_XENFS=y > CONFIG_XEN_SYS_HYPERVISOR=y > CONFIG_XEN_XENBUS_FRONTEND=y > CONFIG_XEN_GNTDEV=m > CONFIG_XEN_GRANT_DEV_ALLOC=m > CONFIG_SWIOTLB_XEN=y > CONFIG_XEN_PCIDEV_BACKEND=m > >> >> 2) Is CONFIG_HOTPLUG_CPU enabled in your kernel image? > > Yes > > rajvir3 dom0 # grep CONFIG_HOTPLUG_CPU .config > CONFIG_HOTPLUG_CPU=y > > Michal > >> >> Thanks >> Jan >> >> On 03/04/2013 06:23 PM, Michal Fiala wrote: >>> hallo, >>> >>> I have updated xen server to >>> >>> xen-4.2.1-r2 >>> xen-tools-4.2.1-r1 >>> kernel gentoo-sources-3.2.39 >>> >>> I have found 2 problems >>> >>> 1) Can not exactly set dom0, domU memory >>> >>> I dedicate 4G of memory to dom0 via kernel parameter: >>> >>> dom0_mem=4G,max:4G dom0_max_vcpus=4 dom0_vcpus_pin >>> >>> Bud the real total memory is set to 2618M after reboot. I have found >>> article describing this behavior >>> (http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone), >>> >>> so I have run >>> >>> echo $((4*1024*1024)) > >>> /sys/devices/system/xen_memory/xen_memory0/target_kb >>> >>> The total memory was se to 3687M. This is better, but not enough. >>> >>> I have tested kernel 3.7, there is not such problem. I would like to use >>> longterm kernel 3.2 so I would like to stay with 3.2. >>> >>> Similar problem exists with domU, config looks like >>> >>> kernel = '/etc/xen/kernels/linux-3.2.39-gentoo' >>> name = 'test1' >>> memory = '4000' >>> maxmem = '12000' >>> vcpus = '8' >>> cpus = '^0,^1,^2,^3' >>> extra = 'elevator=noop gentoo=nodevfs' >>> root = '/dev/xvda1 ro' >>> disk = [ >>> 'phy:/dev/vg1/test1_root,xvda1,w', >>> 'phy:/dev/vg1/test1_var,xvda2,w', >>> ] >>> vif = [ >>> 'mac=00:16:3e:24:11:38,bridge=br0', >>> ] >>> >>> After boot, test1 domain has 3704M total memory (free -m), xm list test1 >>> shows 4000M. >>> >>> When I increase memory amount via xm mem-set test1 8000, then xm list >>> test1 really shows 8000M, but domU has 7704M total memory (free -m). >>> >>> from xend.log >>> [2013-03-04 18:10:18 4627] DEBUG (XendDomainInfo:1467) Setting memory >>> target of domain test1 (1) to 8000 MiB. Xen wiki recommends using last stable kernel, it means 3.8. I have used 3.8.2, where is the problem with dom0 memory solved. domU memory allocation was changed, see http://www.gossamer-threads.com/lists/xen/users/270487?do=post_view_flat >>> >>> 2) I am not able to increase vcpu count to domU. >>> After boot domU test1, it has really 8 vcpus, I am able to decrease >>> vcpus by xm vcpu-set test1 4. Cpus count inside test1 really decreases >>> to 4. Now I would like to increase vcpu count via xm vcpu-list test1 6, >>> but unsuccessfully. >>> >>> rajvir3 configs # xm vcpu-list test1 >>> Name ID VCPU CPU State Time(s) CPU >>> Affinity >>> test1 1 0 15 -b- 3.7 12-23 >>> test1 1 1 23 -b- 2.8 12-23 >>> test1 1 2 18 -b- 1.2 12-23 >>> test1 1 3 20 -b- 1.2 12-23 >>> test1 1 4 16 -b- 1.0 12-23 >>> test1 1 5 12 -b- 3.5 12-23 >>> test1 1 6 19 -b- 0.9 12-23 >>> test1 1 7 14 -b- 0.9 12-23 >>> >>> rajvir3 configs # xm vcpu-set test1 4 >>> >>> rajvir3 configs # xm vcpu-list test1 >>> Name ID VCPU CPU State Time(s) CPU >>> Affinity >>> test1 1 0 15 -b- 3.7 12-23 >>> test1 1 1 23 -b- 2.9 12-23 >>> test1 1 2 18 -b- 1.3 12-23 >>> test1 1 3 20 -b- 1.2 12-23 >>> test1 1 4 - --p 1.0 12-23 >>> test1 1 5 - --p 3.5 12-23 >>> test1 1 6 - --p 1.0 12-23 >>> test1 1 7 - --p 0.9 12-23 >>> >>> rajvir3 configs # xm vcpu-set test1 6 >>> >>> rajvir3 configs # xm vcpu-list test1 >>> Name ID VCPU CPU State Time(s) CPU >>> Affinity >>> test1 1 0 15 -b- 3.8 12-23 >>> test1 1 1 23 -b- 2.9 12-23 >>> test1 1 2 18 -b- 1.3 12-23 >>> test1 1 3 20 -b- 1.3 12-23 >>> test1 1 4 - --p 1.0 12-23 >>> test1 1 5 - --p 3.5 12-23 >>> test1 1 6 - --p 1.0 12-23 >>> test1 1 7 - --p 0.9 12-23 >>> >>> from xend.log >>> >>> [2013-03-04 18:12:58 4627] INFO (XendDomainInfo:1978) Set VCPU count on >>> domain test1 to 4 >>> [2013-03-04 18:14:51 4627] INFO (XendDomainInfo:1978) Set VCPU count on >>> domain test1 to 6 >>> >>> I was not able to increase vcpu count also in kernel 3.7. My domU did not have udev rules to hotplug cpus, follow these instructions http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug >>> >>> Where could be the problem? >>> >>> Thanks >>> >>> Michal >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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 Mar 05 19:16:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 19:16: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 1UCxKk-0003Aq-L4; Tue, 05 Mar 2013 19:15:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCxKi-0003Ag-HP for xen-users@lists.xen.org; Tue, 05 Mar 2013 19:15:29 +0000 Received: from [85.158.137.99:62674] by server-16.bemta-3.messagelabs.com id 17/57-20692-F4446315; Tue, 05 Mar 2013 19:15:27 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1362510916!12580897!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogNTI4MzQxNSAoYWJhbmRvbmVkOiByZW11c2hhLndpa2lkb 3Qu\nY29tKQ==\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6736 invoked from network); 5 Mar 2013 19:15:16 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 19:15:16 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so6150373wgb.0 for ; Tue, 05 Mar 2013 11:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=v4bnPXpPqkc6WwzBKIkgF0I1C7/RIJ6UxsPCP64zOSY=; b=NPFgzebhyu6NPHakvdD1GU2d/E+OkPDx6jsqNCMBYbH7EgmymvJRVvR1bXWBWkY0W8 p/qjuXZXTpUcdkbM7no930XAjF/eKVnlaKrIymdT6iccSLPDaDnl1ePF3SwvoxmKAK2C y2r3l5fbHex1dCkOWnUEPjlCdCAWP85N2pXnLxZHN1144x+VrPIp2iI3xz87gGpi3v2v qCCzBw03mAAZatRcLvSRuERN8ZWlDizX+W4cc4GhBI4ZEuWZgcUioa8lYLMM5VPZTtMm LRgKJ29i+aA9wDT/ghSsMFReecfLBfhFGP6l1wMs7btrfCgyGsTMudltBQqO8UUSUcZX hO8A== MIME-Version: 1.0 X-Received: by 10.194.109.136 with SMTP id hs8mr39110031wjb.8.1362510915695; Tue, 05 Mar 2013 11:15:15 -0800 (PST) Received: by 10.216.236.13 with HTTP; Tue, 5 Mar 2013 11:15:15 -0800 (PST) Date: Tue, 5 Mar 2013 20:15:15 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: [Xen-users] Network buffering problem with remus X-BeenThere: xen-users@lists.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="===============6243658492312646515==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6243658492312646515== Content-Type: multipart/alternative; boundary=089e0102e17221faef04d7324b0f --089e0102e17221faef04d7324b0f Content-Type: text/plain; charset=ISO-8859-1 Dear all, I used Xen version: 4.2.2-pre compiled from sources with kernel 3.2.0-29-generic ~$ dmesg | grep Xen\ version [ 0.000000] Xen version: 4.2.2-pre (preserve-AD) ~$ uname -a Linux comp1 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux I want to run remus, since 3.x kernel didn't have sch_plug module so I have to manually install it as suggested on this pages http://webcache.googleusercontent.com/search?q=cache:PO7wd7F6rksJ:benchmarktest.wordpress.com/2012/07/05/enabling-remus-on-xen-4-2-using-linux-3-x/+&cd=9&hl=en&ct=clnk&gl=id However, the rems is running but the network buffering wasn't as I expected, it seem the network buffering not running properly. I found this discussion (http://remusha.wikidot.com/forum/t-459019) about sch_plug that have impact on network buffering, I try to apply the patch and even used the old sch_plug but seem its still not working. I have try to do simple measurement with ping command but still didn't got satisfying result. Ping domU no migration : C:\Users\rdc>ping 192.168.129.55 -t Pinging 192.168.129.55 with 32 bytes of data: Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=2ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=3ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=4ms TTL=64 Ping domU with migration but without network bufering : C:\Users\rdc>ping 192.168.129.55 -t Pinging 192.168.129.55 with 32 bytes of data: Reply from 192.168.129.55: bytes=32 time=7ms TTL=64 Reply from 192.168.129.55: bytes=32 time=8ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=11ms TTL=64 Reply from 192.168.129.55: bytes=32 time=3ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=3ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=3ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=2ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=2ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=12ms TTL=64 Ping domU with migration and network bufering : C:\Users\rdc>ping 192.168.129.55 -t Pinging 192.168.129.55 with 32 bytes of data: Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=6ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=4ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Here some sampe of remus output (with network buffering) : user1@comp1:~$ sudo remus 1 10.10.10.3 WARNING: suspend event channel unavailable, falling back to slow xenstore signalling PROF: suspending at 1362510384.568230 PROF: resumed at 1362510384.599588 PROF: flushed memory at 1362510384.625585 PROF: suspending at 1362510384.983182 PROF: resumed at 1362510385.008558 PROF: flushed memory at 1362510385.019639 PROF: suspending at 1362510385.399379 PROF: resumed at 1362510385.424484 PROF: flushed memory at 1362510385.429970 PROF: suspending at 1362510385.812891 PROF: resumed at 1362510385.841359 PROF: flushed memory at 1362510385.848946 PROF: suspending at 1362510386.223116 PROF: resumed at 1362510386.243883 PROF: flushed memory at 1362510386.254029 PROF: suspending at 1362510386.633252 PROF: resumed at 1362510386.660347 PROF: flushed memory at 1362510386.671028 PROF: suspending at 1362510387.045260 PROF: resumed at 1362510387.068308 PROF: flushed memory at 1362510387.078506 PROF: suspending at 1362510387.458226 Does anybody could help me with this problem? Regards, Agya --089e0102e17221faef04d7324b0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

I used=A0
~$ dmesg | grep Xen\ version
[ =A0 =A00.000000] Xen version:= 4.2.2-pre (preserve-AD)

~$ uname -a
Linux comp1 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 = x86_64 x86_64 x86_64 GNU/Linux

I want to run remus, since 3.x kernel didn't = have sch_plug module so I have to manually install it as suggested on this = pages=A0http:= //webcache.googleusercontent.com/search?q=3Dcache:PO7wd7F6rksJ:benchmarktes= t.wordpress.com/2012/07/05/enabling-remus-on-xen-4-2-using-linux-3-x/+&= cd=3D9&hl=3Den&ct=3Dclnk&gl=3Did

However, the rems is running but the network buffering = wasn't as I expected, it seem the network buffering not running properl= y. I found this discussion (http://remusha.wikidot.com/forum/t-459019) about sch_plug that h= ave impact on network buffering, I try to apply the patch and even used the= old sch_plug but seem its still not working.

=A0I have try to do simple measurement with p= ing command but still didn't got satisfying result.

Ping domU no migration :
C:\Users\rdc>ping 192.168.= 129.55 -t

Pinging 192.168.129.55 with 32 bytes of data:
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms T= TL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1m= s TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D2ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1m= s TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D3m= s TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D4ms TTL=3D= 64

Ping domU with migration but without network b= ufering :
C:\Users\rdc>ping 192.168.129.55 -t

P= inging 192.168.129.55 with 32 bytes of data:
Reply from=A0192.168.129.55: bytes=3D32 time=3D7ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D8ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1m= s TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D11= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D3ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D3ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D3ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D2ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D2ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D12ms TTL= =3D64


Ping domU with migration and = network bufering :
C:\Users\rdc>ping 192.168.129.55 -t

P= inging 192.168.129.55 with 32 bytes of data:
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time= =3D6ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D4ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64

Here some sampe of remus output (with network buf= fering) :
user1@comp1:~$ sudo remus 1 10.10.10.3
WARNING: suspend event channel una= vailable, falling back to slow xenstore signalling
PROF: suspending at 1362510384.568230
PROF: resumed at = 1362510384.599588
PROF: flushed memory at 1362510384.625585
=
PROF: suspending at 1362510384.983182
PROF: resumed at 13625= 10385.008558
PROF: flushed memory at 1362510385.019639
PROF: suspending a= t 1362510385.399379
PROF: resumed at 1362510385.424484
= PROF: flushed memory at 1362510385.429970
PROF: suspending at 136= 2510385.812891
PROF: resumed at 1362510385.841359
PROF: flushed memory at 1= 362510385.848946
PROF: suspending at 1362510386.223116
= PROF: resumed at 1362510386.243883
PROF: flushed memory at 136251= 0386.254029
PROF: suspending at 1362510386.633252
PROF: resumed at 13625= 10386.660347
PROF: flushed memory at 1362510386.671028
= PROF: suspending at 1362510387.045260
PROF: resumed at 1362510387= .068308
PROF: flushed memory at 1362510387.078506
PROF: suspending a= t 1362510387.458226


Doe= s anybody could help me with this problem?

Regards= ,

Agya
--089e0102e17221faef04d7324b0f-- --===============6243658492312646515== 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 --===============6243658492312646515==-- From xen-users-bounces@lists.xen.org Tue Mar 05 19:16:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 19:16: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 1UCxKk-0003Aq-L4; Tue, 05 Mar 2013 19:15:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCxKi-0003Ag-HP for xen-users@lists.xen.org; Tue, 05 Mar 2013 19:15:29 +0000 Received: from [85.158.137.99:62674] by server-16.bemta-3.messagelabs.com id 17/57-20692-F4446315; Tue, 05 Mar 2013 19:15:27 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-6.tower-217.messagelabs.com!1362510916!12580897!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_23,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,surbl: (ASYNC_NO) c3VyYmxfcmVjaGVja19kZWxheTogNTI4MzQxNSAoYWJhbmRvbmVkOiByZW11c2hhLndpa2lkb 3Qu\nY29tKQ==\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6736 invoked from network); 5 Mar 2013 19:15:16 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 5 Mar 2013 19:15:16 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so6150373wgb.0 for ; Tue, 05 Mar 2013 11:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=v4bnPXpPqkc6WwzBKIkgF0I1C7/RIJ6UxsPCP64zOSY=; b=NPFgzebhyu6NPHakvdD1GU2d/E+OkPDx6jsqNCMBYbH7EgmymvJRVvR1bXWBWkY0W8 p/qjuXZXTpUcdkbM7no930XAjF/eKVnlaKrIymdT6iccSLPDaDnl1ePF3SwvoxmKAK2C y2r3l5fbHex1dCkOWnUEPjlCdCAWP85N2pXnLxZHN1144x+VrPIp2iI3xz87gGpi3v2v qCCzBw03mAAZatRcLvSRuERN8ZWlDizX+W4cc4GhBI4ZEuWZgcUioa8lYLMM5VPZTtMm LRgKJ29i+aA9wDT/ghSsMFReecfLBfhFGP6l1wMs7btrfCgyGsTMudltBQqO8UUSUcZX hO8A== MIME-Version: 1.0 X-Received: by 10.194.109.136 with SMTP id hs8mr39110031wjb.8.1362510915695; Tue, 05 Mar 2013 11:15:15 -0800 (PST) Received: by 10.216.236.13 with HTTP; Tue, 5 Mar 2013 11:15:15 -0800 (PST) Date: Tue, 5 Mar 2013 20:15:15 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: [Xen-users] Network buffering problem with remus X-BeenThere: xen-users@lists.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="===============6243658492312646515==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6243658492312646515== Content-Type: multipart/alternative; boundary=089e0102e17221faef04d7324b0f --089e0102e17221faef04d7324b0f Content-Type: text/plain; charset=ISO-8859-1 Dear all, I used Xen version: 4.2.2-pre compiled from sources with kernel 3.2.0-29-generic ~$ dmesg | grep Xen\ version [ 0.000000] Xen version: 4.2.2-pre (preserve-AD) ~$ uname -a Linux comp1 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux I want to run remus, since 3.x kernel didn't have sch_plug module so I have to manually install it as suggested on this pages http://webcache.googleusercontent.com/search?q=cache:PO7wd7F6rksJ:benchmarktest.wordpress.com/2012/07/05/enabling-remus-on-xen-4-2-using-linux-3-x/+&cd=9&hl=en&ct=clnk&gl=id However, the rems is running but the network buffering wasn't as I expected, it seem the network buffering not running properly. I found this discussion (http://remusha.wikidot.com/forum/t-459019) about sch_plug that have impact on network buffering, I try to apply the patch and even used the old sch_plug but seem its still not working. I have try to do simple measurement with ping command but still didn't got satisfying result. Ping domU no migration : C:\Users\rdc>ping 192.168.129.55 -t Pinging 192.168.129.55 with 32 bytes of data: Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=2ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=3ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=4ms TTL=64 Ping domU with migration but without network bufering : C:\Users\rdc>ping 192.168.129.55 -t Pinging 192.168.129.55 with 32 bytes of data: Reply from 192.168.129.55: bytes=32 time=7ms TTL=64 Reply from 192.168.129.55: bytes=32 time=8ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=11ms TTL=64 Reply from 192.168.129.55: bytes=32 time=3ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=3ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=3ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=2ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=2ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=12ms TTL=64 Ping domU with migration and network bufering : C:\Users\rdc>ping 192.168.129.55 -t Pinging 192.168.129.55 with 32 bytes of data: Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=6ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=4ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time=1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Reply from 192.168.129.55: bytes=32 time<1ms TTL=64 Here some sampe of remus output (with network buffering) : user1@comp1:~$ sudo remus 1 10.10.10.3 WARNING: suspend event channel unavailable, falling back to slow xenstore signalling PROF: suspending at 1362510384.568230 PROF: resumed at 1362510384.599588 PROF: flushed memory at 1362510384.625585 PROF: suspending at 1362510384.983182 PROF: resumed at 1362510385.008558 PROF: flushed memory at 1362510385.019639 PROF: suspending at 1362510385.399379 PROF: resumed at 1362510385.424484 PROF: flushed memory at 1362510385.429970 PROF: suspending at 1362510385.812891 PROF: resumed at 1362510385.841359 PROF: flushed memory at 1362510385.848946 PROF: suspending at 1362510386.223116 PROF: resumed at 1362510386.243883 PROF: flushed memory at 1362510386.254029 PROF: suspending at 1362510386.633252 PROF: resumed at 1362510386.660347 PROF: flushed memory at 1362510386.671028 PROF: suspending at 1362510387.045260 PROF: resumed at 1362510387.068308 PROF: flushed memory at 1362510387.078506 PROF: suspending at 1362510387.458226 Does anybody could help me with this problem? Regards, Agya --089e0102e17221faef04d7324b0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

I used=A0
~$ dmesg | grep Xen\ version
[ =A0 =A00.000000] Xen version:= 4.2.2-pre (preserve-AD)

~$ uname -a
Linux comp1 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 = x86_64 x86_64 x86_64 GNU/Linux

I want to run remus, since 3.x kernel didn't = have sch_plug module so I have to manually install it as suggested on this = pages=A0http:= //webcache.googleusercontent.com/search?q=3Dcache:PO7wd7F6rksJ:benchmarktes= t.wordpress.com/2012/07/05/enabling-remus-on-xen-4-2-using-linux-3-x/+&= cd=3D9&hl=3Den&ct=3Dclnk&gl=3Did

However, the rems is running but the network buffering = wasn't as I expected, it seem the network buffering not running properl= y. I found this discussion (http://remusha.wikidot.com/forum/t-459019) about sch_plug that h= ave impact on network buffering, I try to apply the patch and even used the= old sch_plug but seem its still not working.

=A0I have try to do simple measurement with p= ing command but still didn't got satisfying result.

Ping domU no migration :
C:\Users\rdc>ping 192.168.= 129.55 -t

Pinging 192.168.129.55 with 32 bytes of data:
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms T= TL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1m= s TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D2ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1m= s TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D3m= s TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D4ms TTL=3D= 64

Ping domU with migration but without network b= ufering :
C:\Users\rdc>ping 192.168.129.55 -t

P= inging 192.168.129.55 with 32 bytes of data:
Reply from=A0192.168.129.55: bytes=3D32 time=3D7ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D8ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1m= s TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time=3D11= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D3ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D3ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D3ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D2ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D2ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D12ms TTL= =3D64


Ping domU with migration and = network bufering :
C:\Users\rdc>ping 192.168.129.55 -t

P= inging 192.168.129.55 with 32 bytes of data:
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time= =3D6ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D4ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time=3D1ms TTL=3D= 64
Reply from=A0192.168.129.55: bytes=3D32 time<1= ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64
Reply from=A0192.168.129.55: bytes=3D32 time<1ms TTL= =3D64
Reply from=A0192.168.129.55: bytes=3D32 time&l= t;1ms TTL=3D64

Here some sampe of remus output (with network buf= fering) :
user1@comp1:~$ sudo remus 1 10.10.10.3
WARNING: suspend event channel una= vailable, falling back to slow xenstore signalling
PROF: suspending at 1362510384.568230
PROF: resumed at = 1362510384.599588
PROF: flushed memory at 1362510384.625585
=
PROF: suspending at 1362510384.983182
PROF: resumed at 13625= 10385.008558
PROF: flushed memory at 1362510385.019639
PROF: suspending a= t 1362510385.399379
PROF: resumed at 1362510385.424484
= PROF: flushed memory at 1362510385.429970
PROF: suspending at 136= 2510385.812891
PROF: resumed at 1362510385.841359
PROF: flushed memory at 1= 362510385.848946
PROF: suspending at 1362510386.223116
= PROF: resumed at 1362510386.243883
PROF: flushed memory at 136251= 0386.254029
PROF: suspending at 1362510386.633252
PROF: resumed at 13625= 10386.660347
PROF: flushed memory at 1362510386.671028
= PROF: suspending at 1362510387.045260
PROF: resumed at 1362510387= .068308
PROF: flushed memory at 1362510387.078506
PROF: suspending a= t 1362510387.458226


Doe= s anybody could help me with this problem?

Regards= ,

Agya
--089e0102e17221faef04d7324b0f-- --===============6243658492312646515== 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 --===============6243658492312646515==-- From xen-users-bounces@lists.xen.org Tue Mar 05 21:57:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 21:57:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCzqB-0006id-CR; Tue, 05 Mar 2013 21:56:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCzqA-0006iS-DB for xen-users@lists.xen.org; Tue, 05 Mar 2013 21:56:06 +0000 Received: from [85.158.143.99:61772] by server-2.bemta-4.messagelabs.com id 85/10-12656-5F966315; Tue, 05 Mar 2013 21:56:05 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1362520563!27363016!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31867 invoked from network); 5 Mar 2013 21:56:04 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Mar 2013 21:56:04 -0000 Received: from [201.122.115.101] (port=40439 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UCzq6-00043t-IC for xen-users@lists.xen.org; Tue, 05 Mar 2013 15:56:02 -0600 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id A8DCAA209 for ; Tue, 5 Mar 2013 15:51:19 -0600 (CST) Message-ID: <513669F0.7040306@ondore.com> Date: Tue, 05 Mar 2013 15:56:00 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: XenUsers References: In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] [Xen-API] Problem with parameter "GRUB_CMDLINE_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: 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 SGVsbG8uCgpFbCAwNS8wMy8xMyAxMjozMiwgRWR1YXJkbyBMw7pjaW8gQS4gQ29zdGEgZXNjcmli acOzOgo+PiBJIGhhdmUgY29uZmlndXJlZCB0aGUgZmlsZSAiL2V0Yy9kZWZhdWx0L2dydWIiIG9u ICJEb20wIiB3aXRoIHRoZQo+PiBmb2xsb3dpbmcgcGFyYW1ldGVyLi4uCj4+Cj4+ICcKPj4gR1JV Ql9DTURMSU5FX1hFTj0iZG9tMF9tZW09MTZHLG1heDoxNkcgZG9tMF9tYXhfdmNwdXM9OCIKPiAg IC0gS291em5ldHNvdiAtPiBBc3N1bWluZyB5b3VyIG1hY2hpbmUgaGFzIHRoaXMgYW1vdW50IG9m IG1lbW9yeSwgSSBtYXkgc3VnZ2VzdCB0aGlzCj4gdHJvdWJsZXNob290aW5nIGFjdGlvbnMuLi4K PiAgIC0gTMO6Y2lvIC0+IFllcywgdGhlIHNlcnZlciBoYXMgMTI4IEdCISA9XQpPay4gSXMgYWxs IHRoYXQgbWVtb3J5IHZpc2libGUgdG8gdGhlIGh5cGVydmlzb3I/IHhlbnRvcCBzaGFsbCBzaG93 IGl0LgoKPj4gdXBkYXRlLWdydWIKPiAgIC0gS291em5ldHNvdiAtPiBBZnRlciB0aGlzIGNvbW1h bmQsIGNoZWNrIC9ib290L2dydWIvZ3J1Yi5jb25mIChvciBtZW51Lmxpc3QsIGlmIEdydWIgdjEK PiBpcyB1c2VkKS4gTWFrZSBzdXJlIFhlbidzIGVudHJ5IGhhcyB0aGUgZGVzaXJlZCBwYXJhbWV0 ZXIuIE90aGVyd2lzZSwKPiBpdCdzIHlvdXIgdXBkYXRlLWdydWIgc2NyaXB0IGZhdWx0Lgo+ICAg LSBMw7pjaW8gLT4gVGhlIGNvbW1hbmQgInVwZGF0ZS1ncnViIiBydW5zIGNvcnJlY3RseS4gTm8g ZXJyb3IgaXMgcmV0dXJuZWQhClRoZSBwb2ludCB3YXMgdG8gbG9vayBhdCB0aGUgcmVzdWx0LCBu b3QgYXQgdGhlIGVycm9yIG91dHB1dCwgaW5zcGVjdGluZyAKdGhlIHJlc3VsdGluZyBHcnViIGNv bmZpZ3VyYXRpb24gZmlsZS4gV2VsbCwgeW91ciBuZXh0IGFuc3dlciBkaXNjYXJkcyAKR3J1YiBh cyB0aGUgY2F1c2UuCgo+PiByZWJvb3QgLWggMAo+ICAgLSBLb3V6bmV0c292IC0+IFdoaWxlIHJl Ym9vdGluZywgaW5zcGVjdCBYZW4ncyBjb21tYW5kIGxpbmUgaW4gdGhlIGJvb3QgbG9hZGVyIChw cmVzcwo+ICdFJyBvdmVyIEdydWIncyBtZW51IGVudHJ5KS4gTWFrZSBzdXJlIHRoZSBkZXNpcmVk IHBhcmFtZXRlciBpcyB0aGVyZS4KPiBPdGhlcndpc2UsIHlvdXIgYm9vdCBsb2FkZXIgaXMgdXNp bmcgYSB3cm9uZyBjb25maWcgZmlsZSAob3IgeW91IGhhdmUKPiB1cGRhdGVkIGEgd3Jvbmcgb25l KS4KPiAgIC0gTMO6Y2lvIC0+IFRoZSAiYm9vdCBsb2FkZXIiIGNvbnRhaW5zIHRoaXMgbGluZSAi bXVsdGlib290IC94ZW4tNC4xLWFtZDY0Lmd6IHBsYWNlaG9sZGVyIGRvbTBfbWVtPTE2RyxtYXg6 MTZHIGRvbTBfbWF4X3ZjcHVzPTgiIGFtb25nIG90aGVyIHRoaW5ncy4KVGhhdCBzZWVtcyBmaW5l LCB3ZSBjYW4gZGlzY2FyZCBib290IGxvYWRlciBhcyB0aGUgY2F1c2Ugb2YgdGhlIGlzc3VlLgoK VGhlIHJlZmVyZW5jZSBbMV0gaXMgbm90IGNsZWFyIGFib3V0IGlmICJtYXg6IiBhbmQgIm1pbjoi IGFyZSBvcHRpb25hbCAKYm90aCBvciBlYWNoLCBpLmUuIGl0IHRoZXkgaGF2ZSB0byBiZSB1c2Vk IGJvdGggb3Igbm9uZSwgb3IgbWF5IGJlIHVzZWQgCmluZGl2aWR1YWxseS4gV2h5IGRvbid0IHlv dSB0cnkgdG8gc2V0IGEgZml4ZWQgYW1vdW50IG9mIFJBTSB0byBEb20wLCBhcyAKImRvbTBfbWVt PTE2RyIsIHdpdGhvdXQgYSAibWF4OiI/CkV2ZW4gaWYgdGhhdCBpcyBub3QgZXhhY3RseSB3aGF0 IHlvdSBpbnRlbmQsIGF0IGxlYXN0IGl0IHdvdWxkIHRlbGwgdXMgCmlmIHRoZXJlIGlzIGEgcHJv YmxlbSBncmFiYmluZyB0aGUgd2hvbGUgZG9tMF9tZW0gdmFyaWFibGUsIG9yIHBhcnNpbmcgCml0 J3MgdmFsdWUuCgpBbHNvLCBpbnNwZWN0IGNhcmVmdWxseSB5b3VyIFhlbidzIGRtZXNnICh4bSBk bWVzZyksIG1heWJlIGl0IG1lbnRpb25zIApzb21ldGhpbmcgYWJvdXQgUkFNIGFzc2lnbm1lbnQg dG8gRG9tMC4KCj4+IEJ1dCB3aGVuIHRoZSAiRG9tMCIgcmV0dXJucywgSSBoYXZlIG9ubHkganVz dCAiMzQ2NTU5MiIgb2YgdG90YWwgbWVtb3J5Lgo+ICAgLSBLb3V6bmV0c292IC0+IE9uY2UgYm9v dGVkLCBjaGVjayB3aXRoIHhlbnRvcCBvciAieG0gbGlzdCIgb3IgInhsIGxpc3QiIChkZXBlbmRz IG9uCj4gd2hhdCB0b29sc3RhY2sgeW91IGFyZSB1c2luZykuIEluc3BlY3QsIGhvdyBtdWNoIG1l bW9yeSBkaWQgWGVuIGFzc2lnbmVkCj4gdG8gRG9tYWluLTAgYWthIERvbTAuCj4gICAtIEzDumNp byAtPiAieGVudG9wIiBzaG93cyB0aGlzOgo+ICIKPiAgICAgICAgTkFNRSAgU1RBVEUgICBDUFUo c2VjKSBDUFUoJSkgICAgIE1FTShrKSBNRU0oJSkgIE1BWE1FTShrKSBNQVhNRU0oJSkgVkNQVVMK PiAgICBEb21haW4tMCAtLS0tLXIgICAgICAgMTEzMSAgMTE0LjAgICAgMzg3Nzg4OCAgICAyLjkg ICAgMzg3Nzg4OCAgICAgICAyLjkgICAgIDgKPiAiClRoYWlzIHN1Z2dlc3RzIHRoYXQgaXQncyBl bnRpcmVseSBoeXBlcnZpc29yJ3MgaXNzdWUuIERvbTAgaXMgYXNzaWduZWQgCndpdGggbG93IFJB TS4KCj4gICAtIEtvdXpuZXRzb3YgLT4gTm90ZSwgdGhhdCBpZiB5b3VyIERvbTAgaXMgYSAzMiBi aXRzIHN5c3RlbSwgaXQgd29uJ3QgYmUgYWJsZSB0byBzZWUKPiBtb3JlIFJBTSB1bmxlc3Mgc29t ZSB3b3JrYXJvdW5kIGlzIGFjdGl2YXRlZCwgbGlrZSB1c2luZyB4ODZfNjQga2VybmVsCj4gb3Ig YWN0aXZhdGluZyBQQUUuCj4gICAtIEzDumNpbyAtPiBUaGlzIGlzIG15IERvbTA6ICJVYnVudHUg MTIuMDQuMSBMVFMgKEdOVS9MaW51eCAzLjIuMC0yOS1nZW5lcmljIHg4Nl82NCkiCk9rLgoKUmVm ZXJlbmNlczoKWzFdIGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9YZW5IeXBlcnZpc29yQm9v dE9wdGlvbnMKCi0tIApBbGV4YW5kcmUgS291em5ldHNvdgoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVz ZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Tue Mar 05 21:57:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 05 Mar 2013 21:57:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCzqB-0006id-CR; Tue, 05 Mar 2013 21:56:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UCzqA-0006iS-DB for xen-users@lists.xen.org; Tue, 05 Mar 2013 21:56:06 +0000 Received: from [85.158.143.99:61772] by server-2.bemta-4.messagelabs.com id 85/10-12656-5F966315; Tue, 05 Mar 2013 21:56:05 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1362520563!27363016!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31867 invoked from network); 5 Mar 2013 21:56:04 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Mar 2013 21:56:04 -0000 Received: from [201.122.115.101] (port=40439 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UCzq6-00043t-IC for xen-users@lists.xen.org; Tue, 05 Mar 2013 15:56:02 -0600 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id A8DCAA209 for ; Tue, 5 Mar 2013 15:51:19 -0600 (CST) Message-ID: <513669F0.7040306@ondore.com> Date: Tue, 05 Mar 2013 15:56:00 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: XenUsers References: In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] [Xen-API] Problem with parameter "GRUB_CMDLINE_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: 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 SGVsbG8uCgpFbCAwNS8wMy8xMyAxMjozMiwgRWR1YXJkbyBMw7pjaW8gQS4gQ29zdGEgZXNjcmli acOzOgo+PiBJIGhhdmUgY29uZmlndXJlZCB0aGUgZmlsZSAiL2V0Yy9kZWZhdWx0L2dydWIiIG9u ICJEb20wIiB3aXRoIHRoZQo+PiBmb2xsb3dpbmcgcGFyYW1ldGVyLi4uCj4+Cj4+ICcKPj4gR1JV Ql9DTURMSU5FX1hFTj0iZG9tMF9tZW09MTZHLG1heDoxNkcgZG9tMF9tYXhfdmNwdXM9OCIKPiAg IC0gS291em5ldHNvdiAtPiBBc3N1bWluZyB5b3VyIG1hY2hpbmUgaGFzIHRoaXMgYW1vdW50IG9m IG1lbW9yeSwgSSBtYXkgc3VnZ2VzdCB0aGlzCj4gdHJvdWJsZXNob290aW5nIGFjdGlvbnMuLi4K PiAgIC0gTMO6Y2lvIC0+IFllcywgdGhlIHNlcnZlciBoYXMgMTI4IEdCISA9XQpPay4gSXMgYWxs IHRoYXQgbWVtb3J5IHZpc2libGUgdG8gdGhlIGh5cGVydmlzb3I/IHhlbnRvcCBzaGFsbCBzaG93 IGl0LgoKPj4gdXBkYXRlLWdydWIKPiAgIC0gS291em5ldHNvdiAtPiBBZnRlciB0aGlzIGNvbW1h bmQsIGNoZWNrIC9ib290L2dydWIvZ3J1Yi5jb25mIChvciBtZW51Lmxpc3QsIGlmIEdydWIgdjEK PiBpcyB1c2VkKS4gTWFrZSBzdXJlIFhlbidzIGVudHJ5IGhhcyB0aGUgZGVzaXJlZCBwYXJhbWV0 ZXIuIE90aGVyd2lzZSwKPiBpdCdzIHlvdXIgdXBkYXRlLWdydWIgc2NyaXB0IGZhdWx0Lgo+ICAg LSBMw7pjaW8gLT4gVGhlIGNvbW1hbmQgInVwZGF0ZS1ncnViIiBydW5zIGNvcnJlY3RseS4gTm8g ZXJyb3IgaXMgcmV0dXJuZWQhClRoZSBwb2ludCB3YXMgdG8gbG9vayBhdCB0aGUgcmVzdWx0LCBu b3QgYXQgdGhlIGVycm9yIG91dHB1dCwgaW5zcGVjdGluZyAKdGhlIHJlc3VsdGluZyBHcnViIGNv bmZpZ3VyYXRpb24gZmlsZS4gV2VsbCwgeW91ciBuZXh0IGFuc3dlciBkaXNjYXJkcyAKR3J1YiBh cyB0aGUgY2F1c2UuCgo+PiByZWJvb3QgLWggMAo+ICAgLSBLb3V6bmV0c292IC0+IFdoaWxlIHJl Ym9vdGluZywgaW5zcGVjdCBYZW4ncyBjb21tYW5kIGxpbmUgaW4gdGhlIGJvb3QgbG9hZGVyIChw cmVzcwo+ICdFJyBvdmVyIEdydWIncyBtZW51IGVudHJ5KS4gTWFrZSBzdXJlIHRoZSBkZXNpcmVk IHBhcmFtZXRlciBpcyB0aGVyZS4KPiBPdGhlcndpc2UsIHlvdXIgYm9vdCBsb2FkZXIgaXMgdXNp bmcgYSB3cm9uZyBjb25maWcgZmlsZSAob3IgeW91IGhhdmUKPiB1cGRhdGVkIGEgd3Jvbmcgb25l KS4KPiAgIC0gTMO6Y2lvIC0+IFRoZSAiYm9vdCBsb2FkZXIiIGNvbnRhaW5zIHRoaXMgbGluZSAi bXVsdGlib290IC94ZW4tNC4xLWFtZDY0Lmd6IHBsYWNlaG9sZGVyIGRvbTBfbWVtPTE2RyxtYXg6 MTZHIGRvbTBfbWF4X3ZjcHVzPTgiIGFtb25nIG90aGVyIHRoaW5ncy4KVGhhdCBzZWVtcyBmaW5l LCB3ZSBjYW4gZGlzY2FyZCBib290IGxvYWRlciBhcyB0aGUgY2F1c2Ugb2YgdGhlIGlzc3VlLgoK VGhlIHJlZmVyZW5jZSBbMV0gaXMgbm90IGNsZWFyIGFib3V0IGlmICJtYXg6IiBhbmQgIm1pbjoi IGFyZSBvcHRpb25hbCAKYm90aCBvciBlYWNoLCBpLmUuIGl0IHRoZXkgaGF2ZSB0byBiZSB1c2Vk IGJvdGggb3Igbm9uZSwgb3IgbWF5IGJlIHVzZWQgCmluZGl2aWR1YWxseS4gV2h5IGRvbid0IHlv dSB0cnkgdG8gc2V0IGEgZml4ZWQgYW1vdW50IG9mIFJBTSB0byBEb20wLCBhcyAKImRvbTBfbWVt PTE2RyIsIHdpdGhvdXQgYSAibWF4OiI/CkV2ZW4gaWYgdGhhdCBpcyBub3QgZXhhY3RseSB3aGF0 IHlvdSBpbnRlbmQsIGF0IGxlYXN0IGl0IHdvdWxkIHRlbGwgdXMgCmlmIHRoZXJlIGlzIGEgcHJv YmxlbSBncmFiYmluZyB0aGUgd2hvbGUgZG9tMF9tZW0gdmFyaWFibGUsIG9yIHBhcnNpbmcgCml0 J3MgdmFsdWUuCgpBbHNvLCBpbnNwZWN0IGNhcmVmdWxseSB5b3VyIFhlbidzIGRtZXNnICh4bSBk bWVzZyksIG1heWJlIGl0IG1lbnRpb25zIApzb21ldGhpbmcgYWJvdXQgUkFNIGFzc2lnbm1lbnQg dG8gRG9tMC4KCj4+IEJ1dCB3aGVuIHRoZSAiRG9tMCIgcmV0dXJucywgSSBoYXZlIG9ubHkganVz dCAiMzQ2NTU5MiIgb2YgdG90YWwgbWVtb3J5Lgo+ICAgLSBLb3V6bmV0c292IC0+IE9uY2UgYm9v dGVkLCBjaGVjayB3aXRoIHhlbnRvcCBvciAieG0gbGlzdCIgb3IgInhsIGxpc3QiIChkZXBlbmRz IG9uCj4gd2hhdCB0b29sc3RhY2sgeW91IGFyZSB1c2luZykuIEluc3BlY3QsIGhvdyBtdWNoIG1l bW9yeSBkaWQgWGVuIGFzc2lnbmVkCj4gdG8gRG9tYWluLTAgYWthIERvbTAuCj4gICAtIEzDumNp byAtPiAieGVudG9wIiBzaG93cyB0aGlzOgo+ICIKPiAgICAgICAgTkFNRSAgU1RBVEUgICBDUFUo c2VjKSBDUFUoJSkgICAgIE1FTShrKSBNRU0oJSkgIE1BWE1FTShrKSBNQVhNRU0oJSkgVkNQVVMK PiAgICBEb21haW4tMCAtLS0tLXIgICAgICAgMTEzMSAgMTE0LjAgICAgMzg3Nzg4OCAgICAyLjkg ICAgMzg3Nzg4OCAgICAgICAyLjkgICAgIDgKPiAiClRoYWlzIHN1Z2dlc3RzIHRoYXQgaXQncyBl bnRpcmVseSBoeXBlcnZpc29yJ3MgaXNzdWUuIERvbTAgaXMgYXNzaWduZWQgCndpdGggbG93IFJB TS4KCj4gICAtIEtvdXpuZXRzb3YgLT4gTm90ZSwgdGhhdCBpZiB5b3VyIERvbTAgaXMgYSAzMiBi aXRzIHN5c3RlbSwgaXQgd29uJ3QgYmUgYWJsZSB0byBzZWUKPiBtb3JlIFJBTSB1bmxlc3Mgc29t ZSB3b3JrYXJvdW5kIGlzIGFjdGl2YXRlZCwgbGlrZSB1c2luZyB4ODZfNjQga2VybmVsCj4gb3Ig YWN0aXZhdGluZyBQQUUuCj4gICAtIEzDumNpbyAtPiBUaGlzIGlzIG15IERvbTA6ICJVYnVudHUg MTIuMDQuMSBMVFMgKEdOVS9MaW51eCAzLjIuMC0yOS1nZW5lcmljIHg4Nl82NCkiCk9rLgoKUmVm ZXJlbmNlczoKWzFdIGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9YZW5IeXBlcnZpc29yQm9v dE9wdGlvbnMKCi0tIApBbGV4YW5kcmUgS291em5ldHNvdgoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVz ZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Wed Mar 06 02:27:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 02: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 1UD43J-0005VT-Eu; Wed, 06 Mar 2013 02:25:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD43H-0005VO-Ih for xen-users@lists.xen.org; Wed, 06 Mar 2013 02:25:55 +0000 Received: from [85.158.138.51:46984] by server-9.bemta-3.messagelabs.com id 8C/1D-32531-039A6315; Wed, 06 Mar 2013 02:25:52 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1362536751!24497194!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22126 invoked from network); 6 Mar 2013 02:25:52 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 02:25:52 -0000 Received: by mail-wi0-f170.google.com with SMTP id hm11so2876278wib.1 for ; Tue, 05 Mar 2013 18:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jPa3ZOYLtGMjUsVi8makwhSuakc+phmJlzzCWkF/TNw=; b=I046tlBb/7/xMK2e9Q+/FMmVli2lyTTFP1hEZ+iKQxVozFCThi20w48NT6GHLs4vpm dMDxh3H2PaPk6yTh+QVw4sqjf03FbC3NtMUwpa2F6blMP+sOkkMSKLTXAzWKotwoy4Nx 9Nk3lPrQDUoUzusMzXN0FmNyOo/2TJJ2j1ghbzyDht5vRgDUDRKjg7stZfDlXm+RF/5r rTDoVVMsaWm60PxwFWM8jlhOC8lN9Cs2Pl+MFr2K7SNaUIbTlTATE+LgtTokBzohZEa3 bQhpVdXrLKZOCCMoFa/dT03B3P4EeUZkNn05ESnVPH4BV2nUsmlLeGsuruqvKGWSzwQ9 nZfw== X-Received: by 10.194.7.196 with SMTP id l4mr43506522wja.28.1362536751715; Tue, 05 Mar 2013 18:25:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Tue, 5 Mar 2013 18:25:31 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Tue, 5 Mar 2013 21:25:31 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============7325050481143422556==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7325050481143422556== Content-Type: multipart/alternative; boundary=047d7b5d4576145b6404d7384fc4 --047d7b5d4576145b6404d7384fc4 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 5, 2013 at 10:20 AM, jacek burghardt wrote: > I did quick testing and I get the same error on your last version that > on the one I compiled myself. I am looking forward to you testing the > package and see if you are getting same error > > Bringing this back on-list as this may be pertinent to others. I just updated my server to the latest 4.3-unstable (26666) and all domains (PV and HVM) failed to run. Turns out the package "nss" is now needed for Xen. For arch, just run "pacman -S nss" and you're golden. I've asked the maintainer of the xen-hg-unstable AUR package to add it to the deps list, too. -- --Zootboy Sent from some sort of computing device. --047d7b5d4576145b6404d7384fc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 5, 2013 at 10:20 AM, jacek burgh= ardt <jaceksburghardt@gmail.com> wrote:
I did quick testing and I get the same error on your last version that
on the one I compiled myself. I am looking forward to you testing the
package and see if you are getting same error

Bringing this back on-list as this may be pe= rtinent to others. I just updated my server to the latest 4.3-unstable (266= 66) and all domains (PV and HVM) failed to run. Turns out the package "= ;nss" is now needed for Xen.

For arch, just run "pacman -S nss" and you're golden. I&#= 39;ve asked the maintainer of the xen-hg-unstable AUR package to add it to = the deps list, too.


--
--Zootboy

Sent from some sort of computing device.
--047d7b5d4576145b6404d7384fc4-- --===============7325050481143422556== 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 --===============7325050481143422556==-- From xen-users-bounces@lists.xen.org Wed Mar 06 02:27:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 02: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 1UD43J-0005VT-Eu; Wed, 06 Mar 2013 02:25:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD43H-0005VO-Ih for xen-users@lists.xen.org; Wed, 06 Mar 2013 02:25:55 +0000 Received: from [85.158.138.51:46984] by server-9.bemta-3.messagelabs.com id 8C/1D-32531-039A6315; Wed, 06 Mar 2013 02:25:52 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1362536751!24497194!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22126 invoked from network); 6 Mar 2013 02:25:52 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 02:25:52 -0000 Received: by mail-wi0-f170.google.com with SMTP id hm11so2876278wib.1 for ; Tue, 05 Mar 2013 18:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jPa3ZOYLtGMjUsVi8makwhSuakc+phmJlzzCWkF/TNw=; b=I046tlBb/7/xMK2e9Q+/FMmVli2lyTTFP1hEZ+iKQxVozFCThi20w48NT6GHLs4vpm dMDxh3H2PaPk6yTh+QVw4sqjf03FbC3NtMUwpa2F6blMP+sOkkMSKLTXAzWKotwoy4Nx 9Nk3lPrQDUoUzusMzXN0FmNyOo/2TJJ2j1ghbzyDht5vRgDUDRKjg7stZfDlXm+RF/5r rTDoVVMsaWm60PxwFWM8jlhOC8lN9Cs2Pl+MFr2K7SNaUIbTlTATE+LgtTokBzohZEa3 bQhpVdXrLKZOCCMoFa/dT03B3P4EeUZkNn05ESnVPH4BV2nUsmlLeGsuruqvKGWSzwQ9 nZfw== X-Received: by 10.194.7.196 with SMTP id l4mr43506522wja.28.1362536751715; Tue, 05 Mar 2013 18:25:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Tue, 5 Mar 2013 18:25:31 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Tue, 5 Mar 2013 21:25:31 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============7325050481143422556==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7325050481143422556== Content-Type: multipart/alternative; boundary=047d7b5d4576145b6404d7384fc4 --047d7b5d4576145b6404d7384fc4 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 5, 2013 at 10:20 AM, jacek burghardt wrote: > I did quick testing and I get the same error on your last version that > on the one I compiled myself. I am looking forward to you testing the > package and see if you are getting same error > > Bringing this back on-list as this may be pertinent to others. I just updated my server to the latest 4.3-unstable (26666) and all domains (PV and HVM) failed to run. Turns out the package "nss" is now needed for Xen. For arch, just run "pacman -S nss" and you're golden. I've asked the maintainer of the xen-hg-unstable AUR package to add it to the deps list, too. -- --Zootboy Sent from some sort of computing device. --047d7b5d4576145b6404d7384fc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 5, 2013 at 10:20 AM, jacek burgh= ardt <jaceksburghardt@gmail.com> wrote:
I did quick testing and I get the same error on your last version that
on the one I compiled myself. I am looking forward to you testing the
package and see if you are getting same error

Bringing this back on-list as this may be pe= rtinent to others. I just updated my server to the latest 4.3-unstable (266= 66) and all domains (PV and HVM) failed to run. Turns out the package "= ;nss" is now needed for Xen.

For arch, just run "pacman -S nss" and you're golden. I&#= 39;ve asked the maintainer of the xen-hg-unstable AUR package to add it to = the deps list, too.


--
--Zootboy

Sent from some sort of computing device.
--047d7b5d4576145b6404d7384fc4-- --===============7325050481143422556== 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 --===============7325050481143422556==-- From xen-users-bounces@lists.xen.org Wed Mar 06 04:35:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 04:35: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 1UD63Q-0006md-UA; Wed, 06 Mar 2013 04:34:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD63P-0006mY-Ov for xen-users@lists.xen.org; Wed, 06 Mar 2013 04:34:11 +0000 Received: from [85.158.139.83:31267] by server-12.bemta-5.messagelabs.com id 3B/E6-11486-147C6315; Wed, 06 Mar 2013 04:34:09 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1362544446!23823092!1 X-Originating-IP: [209.85.223.182] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16546 invoked from network); 6 Mar 2013 04:34:07 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 04:34:07 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so8921395iea.27 for ; Tue, 05 Mar 2013 20:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1iJGOZP5t0kQxz2kADBl9XhKLrZQbsnebgTe1ASOb3w=; b=xusZpPHWPa3HzrkkxK3m/Zs/pRmMh4oic7mAUxc4+kQvO2HY5Fx/Jlc523EPwGv3gm 0TC1YbijASRycsaGIddaWv3jaG20dO0lQjEMXmxoFlSiVIsUXJvseTTxtpzGz7THlYiF SE5H+rdjZQGbrnyGVg1O3k9RS02Nqi9s/XA9f5udr7F3S8FgQLsejmELZlmOIKAKgy4s DvdNoticZkZBcR7wO3EY06uRqxZnXw/olJfs9kfRG3volpRifrWni8vkWDT7SL4GMOAp R0GoqeDqh3bIzOTTdZbemP52ZJir5fPHAFIwwhggxZMwVAf+tVOEEda3TrqgFGPY4TTx h7bA== MIME-Version: 1.0 X-Received: by 10.50.196.130 with SMTP id im2mr8773481igc.90.1362544445717; Tue, 05 Mar 2013 20:34:05 -0800 (PST) Received: by 10.42.41.5 with HTTP; Tue, 5 Mar 2013 20:34:05 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Mar 2013 21:34:05 -0700 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============3289764063946124383==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3289764063946124383== Content-Type: multipart/alternative; boundary=14dae9341071ada1cb04d73a1962 --14dae9341071ada1cb04d73a1962 Content-Type: text/plain; charset=ISO-8859-1 Well i believe there is bug in xen and spice. When i tried to compile 26657 rev and it fails at booting hvm . On Tue, Mar 5, 2013 at 7:25 PM, Sean Greenslade wrote: > > On Tue, Mar 5, 2013 at 10:20 AM, jacek burghardt < > jaceksburghardt@gmail.com> wrote: > >> I did quick testing and I get the same error on your last version that >> on the one I compiled myself. I am looking forward to you testing the >> package and see if you are getting same error >> >> Bringing this back on-list as this may be pertinent to others. I just > updated my server to the latest 4.3-unstable (26666) and all domains (PV > and HVM) failed to run. Turns out the package "nss" is now needed for Xen. > > For arch, just run "pacman -S nss" and you're golden. I've asked the > maintainer of the xen-hg-unstable AUR package to add it to the deps list, > too. > > > > -- > --Zootboy > > Sent from some sort of computing device. > --14dae9341071ada1cb04d73a1962 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well i believe there is bug in xen and spice. When i tried to compile 26657= rev and it fails at booting hvm .

On Tue= , Mar 5, 2013 at 7:25 PM, Sean Greenslade <zootboysean@gmail.com&g= t; wrote:

On Tue, Mar 5, 2013 at 10:20 AM, jacek burghardt <= ;jaceksburgh= ardt@gmail.com> wrote:
I did quick testing and I get the same error on your last version that
on the one I compiled myself. I am looking forward to you testing the
package and see if you are getting same error

Bringing this back on-list as this may= be pertinent to others. I just updated my server to the latest 4.3-unstabl= e (26666) and all domains (PV and HVM) failed to run. Turns out the package= "nss" is now needed for Xen.

For arch, just run "pacman -S nss" and you're golden. I&#= 39;ve asked the maintainer of the xen-hg-unstable AUR package to add it to = the deps list, too.



--
--Zootboy

Sent from some sort of computing device.

--14dae9341071ada1cb04d73a1962-- --===============3289764063946124383== 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 --===============3289764063946124383==-- From xen-users-bounces@lists.xen.org Wed Mar 06 04:35:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 04:35: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 1UD63Q-0006md-UA; Wed, 06 Mar 2013 04:34:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD63P-0006mY-Ov for xen-users@lists.xen.org; Wed, 06 Mar 2013 04:34:11 +0000 Received: from [85.158.139.83:31267] by server-12.bemta-5.messagelabs.com id 3B/E6-11486-147C6315; Wed, 06 Mar 2013 04:34:09 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1362544446!23823092!1 X-Originating-IP: [209.85.223.182] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16546 invoked from network); 6 Mar 2013 04:34:07 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 04:34:07 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so8921395iea.27 for ; Tue, 05 Mar 2013 20:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1iJGOZP5t0kQxz2kADBl9XhKLrZQbsnebgTe1ASOb3w=; b=xusZpPHWPa3HzrkkxK3m/Zs/pRmMh4oic7mAUxc4+kQvO2HY5Fx/Jlc523EPwGv3gm 0TC1YbijASRycsaGIddaWv3jaG20dO0lQjEMXmxoFlSiVIsUXJvseTTxtpzGz7THlYiF SE5H+rdjZQGbrnyGVg1O3k9RS02Nqi9s/XA9f5udr7F3S8FgQLsejmELZlmOIKAKgy4s DvdNoticZkZBcR7wO3EY06uRqxZnXw/olJfs9kfRG3volpRifrWni8vkWDT7SL4GMOAp R0GoqeDqh3bIzOTTdZbemP52ZJir5fPHAFIwwhggxZMwVAf+tVOEEda3TrqgFGPY4TTx h7bA== MIME-Version: 1.0 X-Received: by 10.50.196.130 with SMTP id im2mr8773481igc.90.1362544445717; Tue, 05 Mar 2013 20:34:05 -0800 (PST) Received: by 10.42.41.5 with HTTP; Tue, 5 Mar 2013 20:34:05 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Mar 2013 21:34:05 -0700 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============3289764063946124383==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3289764063946124383== Content-Type: multipart/alternative; boundary=14dae9341071ada1cb04d73a1962 --14dae9341071ada1cb04d73a1962 Content-Type: text/plain; charset=ISO-8859-1 Well i believe there is bug in xen and spice. When i tried to compile 26657 rev and it fails at booting hvm . On Tue, Mar 5, 2013 at 7:25 PM, Sean Greenslade wrote: > > On Tue, Mar 5, 2013 at 10:20 AM, jacek burghardt < > jaceksburghardt@gmail.com> wrote: > >> I did quick testing and I get the same error on your last version that >> on the one I compiled myself. I am looking forward to you testing the >> package and see if you are getting same error >> >> Bringing this back on-list as this may be pertinent to others. I just > updated my server to the latest 4.3-unstable (26666) and all domains (PV > and HVM) failed to run. Turns out the package "nss" is now needed for Xen. > > For arch, just run "pacman -S nss" and you're golden. I've asked the > maintainer of the xen-hg-unstable AUR package to add it to the deps list, > too. > > > > -- > --Zootboy > > Sent from some sort of computing device. > --14dae9341071ada1cb04d73a1962 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well i believe there is bug in xen and spice. When i tried to compile 26657= rev and it fails at booting hvm .

On Tue= , Mar 5, 2013 at 7:25 PM, Sean Greenslade <zootboysean@gmail.com&g= t; wrote:

On Tue, Mar 5, 2013 at 10:20 AM, jacek burghardt <= ;jaceksburgh= ardt@gmail.com> wrote:
I did quick testing and I get the same error on your last version that
on the one I compiled myself. I am looking forward to you testing the
package and see if you are getting same error

Bringing this back on-list as this may= be pertinent to others. I just updated my server to the latest 4.3-unstabl= e (26666) and all domains (PV and HVM) failed to run. Turns out the package= "nss" is now needed for Xen.

For arch, just run "pacman -S nss" and you're golden. I&#= 39;ve asked the maintainer of the xen-hg-unstable AUR package to add it to = the deps list, too.



--
--Zootboy

Sent from some sort of computing device.

--14dae9341071ada1cb04d73a1962-- --===============3289764063946124383== 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 --===============3289764063946124383==-- From xen-users-bounces@lists.xen.org Wed Mar 06 04:51:56 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 04:51: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 1UD6JW-00079G-Oe; Wed, 06 Mar 2013 04:50:50 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD6JV-00079A-GS for xen-users@lists.xen.org; Wed, 06 Mar 2013 04:50:49 +0000 Received: from [193.109.254.147:57809] by server-2.bemta-14.messagelabs.com id 22/29-14115-82BC6315; Wed, 06 Mar 2013 04:50:48 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1362545448!3621898!1 X-Originating-IP: [74.125.82.52] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25423 invoked from network); 6 Mar 2013 04:50:48 -0000 Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com) (74.125.82.52) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 04:50:48 -0000 Received: by mail-wg0-f52.google.com with SMTP id 12so6900234wgh.19 for ; Tue, 05 Mar 2013 20:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ThFVHrrJb9W7m/mEEhNqAjP+7QqLor1XI7/mfe91niM=; b=DMHWGpb3T//XYXAJzJXksk7s0dqjwA56wnrcxDeweZmYWaVYJo4Nc2ZdO6D9KDS4io h77nDYIiJ1uLVNoMqh4+hQZcetiT1Ernnn4jBrIWXnGvy6D74KLNRTuujxvZ6x35ZRI3 HiSKsZqt7FZXbovMwap3DLJFgOblKmBepk9uGw92zXH+9Dpff+7vY/I0xZllHfJrqTai fJE0eK5Gl0n+pr6Iyb+Ly6bVb0EHld1G+eUrkNqLgn4iBhF+ByU8V1D93kRZrbgpBROq S6xOcgI4g2CVPyzYaISEMDTGVbtIvv9VKTgXs8NX43aj7gfer9DmQlrfso88usTkk7/D URUg== X-Received: by 10.194.60.195 with SMTP id j3mr43774173wjr.33.1362545447910; Tue, 05 Mar 2013 20:50:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Tue, 5 Mar 2013 20:50:27 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Tue, 5 Mar 2013 23:50:27 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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, Mar 5, 2013 at 11:34 PM, jacek burghardt wrote: > Well i believe there is bug in xen and spice. When i tried to compile 26657 > rev and it fails at booting hvm . > Did you install nss (and maybe lib32-nss)? Can you boot a PV domain OK? Also, the rev that I got working was 26666. That's the one I linked to the second time and that one works with PV and HVM domains. Also, some specific error messages wouldn't hurt. "fails at booting" doesn't give much to go on. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 06 04:51:56 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 04:51: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 1UD6JW-00079G-Oe; Wed, 06 Mar 2013 04:50:50 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD6JV-00079A-GS for xen-users@lists.xen.org; Wed, 06 Mar 2013 04:50:49 +0000 Received: from [193.109.254.147:57809] by server-2.bemta-14.messagelabs.com id 22/29-14115-82BC6315; Wed, 06 Mar 2013 04:50:48 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1362545448!3621898!1 X-Originating-IP: [74.125.82.52] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25423 invoked from network); 6 Mar 2013 04:50:48 -0000 Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com) (74.125.82.52) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 04:50:48 -0000 Received: by mail-wg0-f52.google.com with SMTP id 12so6900234wgh.19 for ; Tue, 05 Mar 2013 20:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ThFVHrrJb9W7m/mEEhNqAjP+7QqLor1XI7/mfe91niM=; b=DMHWGpb3T//XYXAJzJXksk7s0dqjwA56wnrcxDeweZmYWaVYJo4Nc2ZdO6D9KDS4io h77nDYIiJ1uLVNoMqh4+hQZcetiT1Ernnn4jBrIWXnGvy6D74KLNRTuujxvZ6x35ZRI3 HiSKsZqt7FZXbovMwap3DLJFgOblKmBepk9uGw92zXH+9Dpff+7vY/I0xZllHfJrqTai fJE0eK5Gl0n+pr6Iyb+Ly6bVb0EHld1G+eUrkNqLgn4iBhF+ByU8V1D93kRZrbgpBROq S6xOcgI4g2CVPyzYaISEMDTGVbtIvv9VKTgXs8NX43aj7gfer9DmQlrfso88usTkk7/D URUg== X-Received: by 10.194.60.195 with SMTP id j3mr43774173wjr.33.1362545447910; Tue, 05 Mar 2013 20:50:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Tue, 5 Mar 2013 20:50:27 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Tue, 5 Mar 2013 23:50:27 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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, Mar 5, 2013 at 11:34 PM, jacek burghardt wrote: > Well i believe there is bug in xen and spice. When i tried to compile 26657 > rev and it fails at booting hvm . > Did you install nss (and maybe lib32-nss)? Can you boot a PV domain OK? Also, the rev that I got working was 26666. That's the one I linked to the second time and that one works with PV and HVM domains. Also, some specific error messages wouldn't hurt. "fails at booting" doesn't give much to go on. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 06 05:42:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 05:42: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 1UD76W-0007t3-1p; Wed, 06 Mar 2013 05:41:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD76U-0007sP-3a for xen-users@lists.xen.org; Wed, 06 Mar 2013 05:41:26 +0000 Received: from [193.109.254.147:24442] by server-5.bemta-14.messagelabs.com id E9/AE-09030-507D6315; Wed, 06 Mar 2013 05:41:25 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1362548482!8739492!1 X-Originating-IP: [209.85.223.182] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16635 invoked from network); 6 Mar 2013 05:41:23 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 05:41:23 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so8958466iea.13 for ; Tue, 05 Mar 2013 21:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BdOJCodvwul+pAsER9JJiDTMjgDd5MippaASZUdTZjI=; b=rr0Y7xK3WA1i3NCMsR/WEivopvBgTp8ATyMxGvd7Klezu8Ahj/ro1VzCXGm2V+HHsC HS2hVDaK1TN6hmk6c29Uet6VGUzrClND+hhIMt0fXiAOZaIOkuFHy5HbMwfIWeHkYb0N KudHbpU//bbXtA+tvRpcD+JjQ9VqYZfTIDg4MsHqM+XaM8Fw3RU8VXUCd8eQc7la+AJP 9b/O+cexquH1XkQkwyi91Nb34eDtrMzWy0JDs6wHwwCSuDtxDuRcC1LD+NsgGCoUr4gi Zts/h5sGNyGWYT5XrpPLo00Lyy/2LLYx0OCfAwviMUQiJqO6Ih64zxdI+Y9ys+w8i4Lj PZhw== MIME-Version: 1.0 X-Received: by 10.50.17.163 with SMTP id p3mr8985202igd.90.1362548482157; Tue, 05 Mar 2013 21:41:22 -0800 (PST) Received: by 10.42.41.5 with HTTP; Tue, 5 Mar 2013 21:41:22 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Mar 2013 22:41:22 -0700 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============7274435036516968684==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7274435036516968684== Content-Type: multipart/alternative; boundary=14dae93407cf44b13004d73b0acb --14dae93407cf44b13004d73b0acb Content-Type: text/plain; charset=ISO-8859-1 I get this error and I had installed nss for while. libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl_dm.c:1262:libxl__destroy_device_model: could not find device-model's pid for dom 11 libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_model failed for 11 On Tue, Mar 5, 2013 at 9:34 PM, jacek burghardt wrote: > Well i believe there is bug in xen and spice. When i tried to compile > 26657 rev and it fails at booting hvm . > > > On Tue, Mar 5, 2013 at 7:25 PM, Sean Greenslade wrote: > >> >> On Tue, Mar 5, 2013 at 10:20 AM, jacek burghardt < >> jaceksburghardt@gmail.com> wrote: >> >>> I did quick testing and I get the same error on your last version that >>> on the one I compiled myself. I am looking forward to you testing the >>> package and see if you are getting same error >>> >>> Bringing this back on-list as this may be pertinent to others. I just >> updated my server to the latest 4.3-unstable (26666) and all domains (PV >> and HVM) failed to run. Turns out the package "nss" is now needed for Xen. >> >> For arch, just run "pacman -S nss" and you're golden. I've asked the >> maintainer of the xen-hg-unstable AUR package to add it to the deps list, >> too. >> >> >> >> -- >> --Zootboy >> >> Sent from some sort of computing device. >> > > --14dae93407cf44b13004d73b0acb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I get this error and I had installed nss for while.
libxl: error: libxl= _dom.c:612:libxl__build_hvm: hvm building failed
libxl: error: libxl_cre= ate.c:900:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: er= ror: libxl_dm.c:1262:libxl__destroy_device_model: could not find device-mod= el's pid for dom 11
libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_mode= l failed for 11

On Tue, Mar 5, 2013 at 9:= 34 PM, jacek burghardt <jaceksburghardt@gmail.com> w= rote:
Well i believe there is bug in xen and spice= . When i tried to compile 26657 rev and it fails at booting hvm .


On Tue, Mar 5, 2013 at= 7:25 PM, Sean Greenslade <zootboysean@gmail.com> wrote:=

On Tue, = Mar 5, 2013 at 10:20 AM, jacek burghardt <jaceksburghardt@gmail.co= m> wrote:
I did quick testing and I get the same error on your last version that
on the one I compiled myself. I am looking forward to you testing the
package and see if you are getting same error

Bringing this back on-list as this may= be pertinent to others. I just updated my server to the latest 4.3-unstabl= e (26666) and all domains (PV and HVM) failed to run. Turns out the package= "nss" is now needed for Xen.

For arch, just run "pacman -S nss" and you're golden. I&#= 39;ve asked the maintainer of the xen-hg-unstable AUR package to add it to = the deps list, too.



--
--Zootboy

Sent from some sort of computing device.


--14dae93407cf44b13004d73b0acb-- --===============7274435036516968684== 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 --===============7274435036516968684==-- From xen-users-bounces@lists.xen.org Wed Mar 06 05:42:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 05:42: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 1UD76W-0007t3-1p; Wed, 06 Mar 2013 05:41:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD76U-0007sP-3a for xen-users@lists.xen.org; Wed, 06 Mar 2013 05:41:26 +0000 Received: from [193.109.254.147:24442] by server-5.bemta-14.messagelabs.com id E9/AE-09030-507D6315; Wed, 06 Mar 2013 05:41:25 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1362548482!8739492!1 X-Originating-IP: [209.85.223.182] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16635 invoked from network); 6 Mar 2013 05:41:23 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 05:41:23 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so8958466iea.13 for ; Tue, 05 Mar 2013 21:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BdOJCodvwul+pAsER9JJiDTMjgDd5MippaASZUdTZjI=; b=rr0Y7xK3WA1i3NCMsR/WEivopvBgTp8ATyMxGvd7Klezu8Ahj/ro1VzCXGm2V+HHsC HS2hVDaK1TN6hmk6c29Uet6VGUzrClND+hhIMt0fXiAOZaIOkuFHy5HbMwfIWeHkYb0N KudHbpU//bbXtA+tvRpcD+JjQ9VqYZfTIDg4MsHqM+XaM8Fw3RU8VXUCd8eQc7la+AJP 9b/O+cexquH1XkQkwyi91Nb34eDtrMzWy0JDs6wHwwCSuDtxDuRcC1LD+NsgGCoUr4gi Zts/h5sGNyGWYT5XrpPLo00Lyy/2LLYx0OCfAwviMUQiJqO6Ih64zxdI+Y9ys+w8i4Lj PZhw== MIME-Version: 1.0 X-Received: by 10.50.17.163 with SMTP id p3mr8985202igd.90.1362548482157; Tue, 05 Mar 2013 21:41:22 -0800 (PST) Received: by 10.42.41.5 with HTTP; Tue, 5 Mar 2013 21:41:22 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Mar 2013 22:41:22 -0700 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============7274435036516968684==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7274435036516968684== Content-Type: multipart/alternative; boundary=14dae93407cf44b13004d73b0acb --14dae93407cf44b13004d73b0acb Content-Type: text/plain; charset=ISO-8859-1 I get this error and I had installed nss for while. libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl_dm.c:1262:libxl__destroy_device_model: could not find device-model's pid for dom 11 libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_model failed for 11 On Tue, Mar 5, 2013 at 9:34 PM, jacek burghardt wrote: > Well i believe there is bug in xen and spice. When i tried to compile > 26657 rev and it fails at booting hvm . > > > On Tue, Mar 5, 2013 at 7:25 PM, Sean Greenslade wrote: > >> >> On Tue, Mar 5, 2013 at 10:20 AM, jacek burghardt < >> jaceksburghardt@gmail.com> wrote: >> >>> I did quick testing and I get the same error on your last version that >>> on the one I compiled myself. I am looking forward to you testing the >>> package and see if you are getting same error >>> >>> Bringing this back on-list as this may be pertinent to others. I just >> updated my server to the latest 4.3-unstable (26666) and all domains (PV >> and HVM) failed to run. Turns out the package "nss" is now needed for Xen. >> >> For arch, just run "pacman -S nss" and you're golden. I've asked the >> maintainer of the xen-hg-unstable AUR package to add it to the deps list, >> too. >> >> >> >> -- >> --Zootboy >> >> Sent from some sort of computing device. >> > > --14dae93407cf44b13004d73b0acb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I get this error and I had installed nss for while.
libxl: error: libxl= _dom.c:612:libxl__build_hvm: hvm building failed
libxl: error: libxl_cre= ate.c:900:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: er= ror: libxl_dm.c:1262:libxl__destroy_device_model: could not find device-mod= el's pid for dom 11
libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_mode= l failed for 11

On Tue, Mar 5, 2013 at 9:= 34 PM, jacek burghardt <jaceksburghardt@gmail.com> w= rote:
Well i believe there is bug in xen and spice= . When i tried to compile 26657 rev and it fails at booting hvm .


On Tue, Mar 5, 2013 at= 7:25 PM, Sean Greenslade <zootboysean@gmail.com> wrote:=

On Tue, = Mar 5, 2013 at 10:20 AM, jacek burghardt <jaceksburghardt@gmail.co= m> wrote:
I did quick testing and I get the same error on your last version that
on the one I compiled myself. I am looking forward to you testing the
package and see if you are getting same error

Bringing this back on-list as this may= be pertinent to others. I just updated my server to the latest 4.3-unstabl= e (26666) and all domains (PV and HVM) failed to run. Turns out the package= "nss" is now needed for Xen.

For arch, just run "pacman -S nss" and you're golden. I&#= 39;ve asked the maintainer of the xen-hg-unstable AUR package to add it to = the deps list, too.



--
--Zootboy

Sent from some sort of computing device.


--14dae93407cf44b13004d73b0acb-- --===============7274435036516968684== 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 --===============7274435036516968684==-- From xen-users-bounces@lists.xen.org Wed Mar 06 11:09:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 11:09: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 1UDCCh-0004yn-G1; Wed, 06 Mar 2013 11:08:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDCCf-0004yh-Bc for xen-users@lists.xen.org; Wed, 06 Mar 2013 11:08:09 +0000 Received: from [85.158.139.83:54915] by server-16.bemta-5.messagelabs.com id 21/0C-02543-89327315; Wed, 06 Mar 2013 11:08:08 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1362568086!23487576!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDE2Mzg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11926 invoked from network); 6 Mar 2013 11:08:08 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 11:08:08 -0000 X-IronPort-AV: E=Sophos;i="4.84,794,1355097600"; d="scan'208";a="11460326" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 06 Mar 2013 11:08:06 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.318.1; Wed, 6 Mar 2013 06:08:05 -0500 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UDCCb-0006cs-Ko; Wed, 06 Mar 2013 11:08:05 +0000 Date: Wed, 6 Mar 2013 11:08:05 +0000 From: Wei Liu To: Mohammad Reza Gerami Message-ID: <20130306110805.GA13535@zion.uk.xensource.com> References: <20130305172238.GA11446@zion.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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 Please don't top-post. On Wed, Mar 06, 2013 at 05:54:37AM +0000, Mohammad Reza Gerami wrote: > Dear Wei Liu > Thanks for your response > I have 4 cpu with 8 core, and with hyper threat I have 64, but my application run with root or other only use maximum 16 core > my OS is centos 6.3 64bit , where can I check for limitation of cpus? > tnx a lot > As I said in my previous email, check out /proc/cpuinfo. If you see only 16 CPUs, you need to check your Xen / guest configuration. If you can see 64 CPUs, it should be your guest or application configuration problem. Wei. > On Tue, Mar 5, 2013 at 8:52 PM, Wei Liu > wrote: > On Sat, Mar 02, 2013 at 09:23:46AM +0000, Mohammad Reza Gerami wrote: > > Dear Friends > > > > I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I have 64 > > I installed CentOS 6.3 64 bit and install my software > > but when I run job and check, Maximum 16 core use in my system > > > > What do you mean by "run job and check"? How many CPUs are there in your > /proc/cpuinfo? If you're seeing 64 CPUs, you're probably hitting limits > in your guests. > > > Wei. > > > what is your idea? > > > > thank you > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > > > > -- > *Best Regards > Mohammad Reza Gerami > > > > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 06 11:09:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 11:09: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 1UDCCh-0004yn-G1; Wed, 06 Mar 2013 11:08:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDCCf-0004yh-Bc for xen-users@lists.xen.org; Wed, 06 Mar 2013 11:08:09 +0000 Received: from [85.158.139.83:54915] by server-16.bemta-5.messagelabs.com id 21/0C-02543-89327315; Wed, 06 Mar 2013 11:08:08 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1362568086!23487576!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDE2Mzg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11926 invoked from network); 6 Mar 2013 11:08:08 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 11:08:08 -0000 X-IronPort-AV: E=Sophos;i="4.84,794,1355097600"; d="scan'208";a="11460326" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 06 Mar 2013 11:08:06 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.318.1; Wed, 6 Mar 2013 06:08:05 -0500 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UDCCb-0006cs-Ko; Wed, 06 Mar 2013 11:08:05 +0000 Date: Wed, 6 Mar 2013 11:08:05 +0000 From: Wei Liu To: Mohammad Reza Gerami Message-ID: <20130306110805.GA13535@zion.uk.xensource.com> References: <20130305172238.GA11446@zion.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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 Please don't top-post. On Wed, Mar 06, 2013 at 05:54:37AM +0000, Mohammad Reza Gerami wrote: > Dear Wei Liu > Thanks for your response > I have 4 cpu with 8 core, and with hyper threat I have 64, but my application run with root or other only use maximum 16 core > my OS is centos 6.3 64bit , where can I check for limitation of cpus? > tnx a lot > As I said in my previous email, check out /proc/cpuinfo. If you see only 16 CPUs, you need to check your Xen / guest configuration. If you can see 64 CPUs, it should be your guest or application configuration problem. Wei. > On Tue, Mar 5, 2013 at 8:52 PM, Wei Liu > wrote: > On Sat, Mar 02, 2013 at 09:23:46AM +0000, Mohammad Reza Gerami wrote: > > Dear Friends > > > > I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I have 64 > > I installed CentOS 6.3 64 bit and install my software > > but when I run job and check, Maximum 16 core use in my system > > > > What do you mean by "run job and check"? How many CPUs are there in your > /proc/cpuinfo? If you're seeing 64 CPUs, you're probably hitting limits > in your guests. > > > Wei. > > > what is your idea? > > > > thank you > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > > > > -- > *Best Regards > Mohammad Reza Gerami > > > > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 06 11:23:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 11:23: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 1UDCQK-0005tm-5c; Wed, 06 Mar 2013 11:22:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDCQI-0005te-D9 for xen-users@lists.xen.org; Wed, 06 Mar 2013 11:22:14 +0000 Received: from [85.158.139.83:8930] by server-16.bemta-5.messagelabs.com id E1/9F-02543-5E627315; Wed, 06 Mar 2013 11:22:13 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1362568931!20093088!1 X-Originating-IP: [209.85.223.176] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11123 invoked from network); 6 Mar 2013 11:22:12 -0000 Received: from mail-ie0-f176.google.com (HELO mail-ie0-f176.google.com) (209.85.223.176) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 11:22:12 -0000 Received: by mail-ie0-f176.google.com with SMTP id k13so9202585iea.21 for ; Wed, 06 Mar 2013 03:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0a3IQ0ONWyxU4p4UfvvDGDoQgL0bRpjstvQ5OjwfGrQ=; b=YRAXYYoToRxtuahn7lU+z3Ehmm0rjKlzAt5RbedtFOM3CrWHo5IKQOdS9y/Vb9q5ys WNsQKfBuL42Rn2Okle62wQDNs3xZF1b1olrU4OkWPN16rlIvLKr2Mjm7W1X8aZFqQA+k NM0sitS6IFeF5NQGhZaxcS/StqdlEOQh4h2s9lLu2x8H4UIe5FWM+nZGc8FbH3aGJrxt K3ImV/gi/ghi/l/ZrCvHakcsfhjXPdMr0gdPL/YH3Vx9VWSh61VLZGocU2V3RkzefPTe KdfR1+mwoLhP8X324ylGaWYX0HNoDTDW1QFWRXwasLHs+SokdAxJ/vQkqjKJRAKONF3F 6leg== MIME-Version: 1.0 X-Received: by 10.50.7.240 with SMTP id m16mr10213020iga.91.1362568931106; Wed, 06 Mar 2013 03:22:11 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 03:22:10 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 03:22:10 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 08:22:10 -0300 Message-ID: From: Guilherme Suzuki To: Peter Maloney Cc: xen-users@lists.xen.org, Casey DeLorme , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8003257600367370733==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8003257600367370733== Content-Type: multipart/alternative; boundary=f46d0447976d1ee86404d73fcdab --f46d0447976d1ee86404d73fcdab Content-Type: text/plain; charset=ISO-8859-1 I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel modules) and brought Xen from RPM source (version 4.21) I had the same results everyone's has achieved with consumer cards (it only works with dom0 freshly booted) This time, though, I tried primary VGA passthru from the intel onboard, which does have FLR. And it worked smoothly! Doing a little research, FLR is not the unique way of refreshing a device (theres d3d0, bus and a few others). I'll send an email to AMD and see if they can help us resetting theirs VGAs without rebooting the computer everytime. Have a nice day On Mar 5, 2013 8:45 AM, "Guilherme Suzuki" wrote: Ow, by the way, thanks guys for the support! Who tells that linux guys can't get help? Have a good day... :) On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" wrote: Casey DeLorme, I noticed... On Mar 5, 2013 5:39 AM, "Peter Maloney" wrote: grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got... > > > > > A few things I can add... > > > My card is a Sapphire Radeon HD 6770. And I'm currently using cata... > > > > > > >> > > >> Hello Guilherme, was following your exchange and wanted to see how this turne... > >... >> Seco... > > > > > > -- > > > > -------------------------------------------- > > Peter Maloney > > Brockman... > Max-... -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str... --f46d0447976d1ee86404d73fcdab Content-Type: text/html; charset=ISO-8859-1

I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel modules) and brought Xen from RPM source (version 4.21)

I had the same results everyone's has achieved with consumer cards (it only works with dom0 freshly booted)

This time, though, I tried primary VGA passthru from the intel onboard, which does have FLR. And it worked smoothly!

Doing a little research, FLR is not the unique way of refreshing a device (theres d3d0, bus and a few others). I'll send an email to AMD and see if they can help us resetting theirs VGAs without rebooting the computer everytime.

Have a nice day

On Mar 5, 2013 8:45 AM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Ow, by the way, thanks guys for the support!

Who tells that linux guys can't get help? Have a good day... :)



On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Casey DeLorme, I noticed...





On Mar 5, 2013 5:39 AM, "Peter Maloney" <peter.maloney@brockmann-consult.de> wrote:

grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got...


>
> >
> > A few things I can add...
> >

> My card is a Sapphire Radeon HD 6770. And I'm currently using cata...


>
>
> >
> > >>
> > >> Hello Guilherme, was following your exchange and wanted to see how this turne...

> >...

>> Seco...


>
>
> >
> > --
> >
> > --------------------------------------------
> > Peter Maloney
> > Brockman...

> Max-...







--

--------------------------------------------
Peter Maloney
Brockmann Consult

Max-Planck-Str...

--f46d0447976d1ee86404d73fcdab-- --===============8003257600367370733== 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 --===============8003257600367370733==-- From xen-users-bounces@lists.xen.org Wed Mar 06 11:23:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 11:23: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 1UDCQK-0005tm-5c; Wed, 06 Mar 2013 11:22:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDCQI-0005te-D9 for xen-users@lists.xen.org; Wed, 06 Mar 2013 11:22:14 +0000 Received: from [85.158.139.83:8930] by server-16.bemta-5.messagelabs.com id E1/9F-02543-5E627315; Wed, 06 Mar 2013 11:22:13 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1362568931!20093088!1 X-Originating-IP: [209.85.223.176] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11123 invoked from network); 6 Mar 2013 11:22:12 -0000 Received: from mail-ie0-f176.google.com (HELO mail-ie0-f176.google.com) (209.85.223.176) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 11:22:12 -0000 Received: by mail-ie0-f176.google.com with SMTP id k13so9202585iea.21 for ; Wed, 06 Mar 2013 03:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0a3IQ0ONWyxU4p4UfvvDGDoQgL0bRpjstvQ5OjwfGrQ=; b=YRAXYYoToRxtuahn7lU+z3Ehmm0rjKlzAt5RbedtFOM3CrWHo5IKQOdS9y/Vb9q5ys WNsQKfBuL42Rn2Okle62wQDNs3xZF1b1olrU4OkWPN16rlIvLKr2Mjm7W1X8aZFqQA+k NM0sitS6IFeF5NQGhZaxcS/StqdlEOQh4h2s9lLu2x8H4UIe5FWM+nZGc8FbH3aGJrxt K3ImV/gi/ghi/l/ZrCvHakcsfhjXPdMr0gdPL/YH3Vx9VWSh61VLZGocU2V3RkzefPTe KdfR1+mwoLhP8X324ylGaWYX0HNoDTDW1QFWRXwasLHs+SokdAxJ/vQkqjKJRAKONF3F 6leg== MIME-Version: 1.0 X-Received: by 10.50.7.240 with SMTP id m16mr10213020iga.91.1362568931106; Wed, 06 Mar 2013 03:22:11 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 03:22:10 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 03:22:10 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 08:22:10 -0300 Message-ID: From: Guilherme Suzuki To: Peter Maloney Cc: xen-users@lists.xen.org, Casey DeLorme , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8003257600367370733==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8003257600367370733== Content-Type: multipart/alternative; boundary=f46d0447976d1ee86404d73fcdab --f46d0447976d1ee86404d73fcdab Content-Type: text/plain; charset=ISO-8859-1 I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel modules) and brought Xen from RPM source (version 4.21) I had the same results everyone's has achieved with consumer cards (it only works with dom0 freshly booted) This time, though, I tried primary VGA passthru from the intel onboard, which does have FLR. And it worked smoothly! Doing a little research, FLR is not the unique way of refreshing a device (theres d3d0, bus and a few others). I'll send an email to AMD and see if they can help us resetting theirs VGAs without rebooting the computer everytime. Have a nice day On Mar 5, 2013 8:45 AM, "Guilherme Suzuki" wrote: Ow, by the way, thanks guys for the support! Who tells that linux guys can't get help? Have a good day... :) On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" wrote: Casey DeLorme, I noticed... On Mar 5, 2013 5:39 AM, "Peter Maloney" wrote: grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got... > > > > > A few things I can add... > > > My card is a Sapphire Radeon HD 6770. And I'm currently using cata... > > > > > > >> > > >> Hello Guilherme, was following your exchange and wanted to see how this turne... > >... >> Seco... > > > > > > -- > > > > -------------------------------------------- > > Peter Maloney > > Brockman... > Max-... -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str... --f46d0447976d1ee86404d73fcdab Content-Type: text/html; charset=ISO-8859-1

I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel modules) and brought Xen from RPM source (version 4.21)

I had the same results everyone's has achieved with consumer cards (it only works with dom0 freshly booted)

This time, though, I tried primary VGA passthru from the intel onboard, which does have FLR. And it worked smoothly!

Doing a little research, FLR is not the unique way of refreshing a device (theres d3d0, bus and a few others). I'll send an email to AMD and see if they can help us resetting theirs VGAs without rebooting the computer everytime.

Have a nice day

On Mar 5, 2013 8:45 AM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Ow, by the way, thanks guys for the support!

Who tells that linux guys can't get help? Have a good day... :)



On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Casey DeLorme, I noticed...





On Mar 5, 2013 5:39 AM, "Peter Maloney" <peter.maloney@brockmann-consult.de> wrote:

grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the double message if you got...


>
> >
> > A few things I can add...
> >

> My card is a Sapphire Radeon HD 6770. And I'm currently using cata...


>
>
> >
> > >>
> > >> Hello Guilherme, was following your exchange and wanted to see how this turne...

> >...

>> Seco...


>
>
> >
> > --
> >
> > --------------------------------------------
> > Peter Maloney
> > Brockman...

> Max-...







--

--------------------------------------------
Peter Maloney
Brockmann Consult

Max-Planck-Str...

--f46d0447976d1ee86404d73fcdab-- --===============8003257600367370733== 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 --===============8003257600367370733==-- From xen-users-bounces@lists.xen.org Wed Mar 06 12:23:23 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 12:23: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 1UDDMS-0008J0-5X; Wed, 06 Mar 2013 12:22:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDDMQ-0008Io-T8 for xen-users@lists.xen.org; Wed, 06 Mar 2013 12:22:19 +0000 Received: from [85.158.138.51:60380] by server-1.bemta-3.messagelabs.com id 4A/BA-13706-AF437315; Wed, 06 Mar 2013 12:22:18 +0000 X-Env-Sender: i.salvat.ojem@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1362572536!11921791!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10252 invoked from network); 6 Mar 2013 12:22:17 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 12:22:17 -0000 Received: by mail-ee0-f43.google.com with SMTP id c50so5702477eek.16 for ; Wed, 06 Mar 2013 04:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=0hBC12iueh8AHqlF56e8WSGs+dsn6tO3ouXinfa+Za8=; b=E4rcBTWwmcN5S2DbIQl6LeFyIoOWf/aOwpTs9r7Ixt4RkmrQbfi0gBtGCyTvHyL4jC xE9y5LkDpd27BAtGYQQ07RN0wVKcB9PVFJEiuoZmem415wP8gLfZ5UnU6RvmV8Pf7Rib QR3htiCCy/29ekq59kBW4uHxv+YHzl/bO4c7Sy+Gk027IGjmhpM9XEkZpjE/NljArmDD faDgC0ZyFynDV2OB98c2T0fOfDIt+aq00ZOeuCA5OuEXc60NN9ETVzM7bZfWwQISBr0H cpLwxJl9LSMCV2tIAO6nsVMsoacs7AgfCv/p3eAezN18RJXfJmCyAjqLj0pwzRGf7KEj XArw== X-Received: by 10.14.218.71 with SMTP id j47mr80984615eep.28.1362572536784; Wed, 06 Mar 2013 04:22:16 -0800 (PST) Received: from [10.12.48.72] ([80.30.82.67]) by mx.google.com with ESMTPS id z45sm21690870eeu.10.2013.03.06.04.22.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 04:22:14 -0800 (PST) Message-ID: <513734F4.6060700@gmail.com> Date: Wed, 06 Mar 2013 13:22:12 +0100 From: =?ISO-8859-1?Q?I=F1igo_Salvat?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] XEN 4.1.2 physical machine crash randomly X-BeenThere: xen-users@lists.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="===============5646931488408153040==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5646931488408153040== Content-Type: multipart/alternative; boundary="------------010406070407070704070905" This is a multi-part message in MIME format. --------------010406070407070704070905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, We have a xen machine running on debian 6 (xen 4.0.1) with 5 windows HVM (huge load) that use dedicated iscsi disks for each VM on an openfiler 2.3 device. We are trying to update to ubuntu 12.04 on the same machine (xen 4.1.2). Once we solved all the small bug (qemu-linaro -> qemu) and adapt the config files to the new version of XEN, we where able to start all the HVM's. While the load is low the every thing works great, but when every body starts working the system crash. Due the crash there are no logs or anything I can look at. Any idea? Thanks for your help and sorry about my very bad english. Iñigo Salvat --------------010406070407070704070905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

We have a xen machine running on debian 6 (xen 4.0.1) with 5 windows HVM (huge load) that use dedicated iscsi disks for each VM on an openfiler 2.3 device.

We are trying to update to ubuntu 12.04 on the same machine (xen 4.1.2). Once we solved all the small bug (qemu-linaro -> qemu) and adapt the config files to the new version of XEN, we where able to start all the HVM's.

While the load is low the every thing works great, but when every body starts working the system crash. Due the crash there are no logs or anything I can look at.

Any idea?

Thanks for your help and sorry about my very bad english.

Iñigo Salvat
--------------010406070407070704070905-- --===============5646931488408153040== 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 --===============5646931488408153040==-- From xen-users-bounces@lists.xen.org Wed Mar 06 12:23:23 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 12:23: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 1UDDMS-0008J0-5X; Wed, 06 Mar 2013 12:22:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDDMQ-0008Io-T8 for xen-users@lists.xen.org; Wed, 06 Mar 2013 12:22:19 +0000 Received: from [85.158.138.51:60380] by server-1.bemta-3.messagelabs.com id 4A/BA-13706-AF437315; Wed, 06 Mar 2013 12:22:18 +0000 X-Env-Sender: i.salvat.ojem@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1362572536!11921791!1 X-Originating-IP: [74.125.83.43] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10252 invoked from network); 6 Mar 2013 12:22:17 -0000 Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com) (74.125.83.43) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 12:22:17 -0000 Received: by mail-ee0-f43.google.com with SMTP id c50so5702477eek.16 for ; Wed, 06 Mar 2013 04:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=0hBC12iueh8AHqlF56e8WSGs+dsn6tO3ouXinfa+Za8=; b=E4rcBTWwmcN5S2DbIQl6LeFyIoOWf/aOwpTs9r7Ixt4RkmrQbfi0gBtGCyTvHyL4jC xE9y5LkDpd27BAtGYQQ07RN0wVKcB9PVFJEiuoZmem415wP8gLfZ5UnU6RvmV8Pf7Rib QR3htiCCy/29ekq59kBW4uHxv+YHzl/bO4c7Sy+Gk027IGjmhpM9XEkZpjE/NljArmDD faDgC0ZyFynDV2OB98c2T0fOfDIt+aq00ZOeuCA5OuEXc60NN9ETVzM7bZfWwQISBr0H cpLwxJl9LSMCV2tIAO6nsVMsoacs7AgfCv/p3eAezN18RJXfJmCyAjqLj0pwzRGf7KEj XArw== X-Received: by 10.14.218.71 with SMTP id j47mr80984615eep.28.1362572536784; Wed, 06 Mar 2013 04:22:16 -0800 (PST) Received: from [10.12.48.72] ([80.30.82.67]) by mx.google.com with ESMTPS id z45sm21690870eeu.10.2013.03.06.04.22.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 04:22:14 -0800 (PST) Message-ID: <513734F4.6060700@gmail.com> Date: Wed, 06 Mar 2013 13:22:12 +0100 From: =?ISO-8859-1?Q?I=F1igo_Salvat?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] XEN 4.1.2 physical machine crash randomly X-BeenThere: xen-users@lists.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="===============5646931488408153040==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5646931488408153040== Content-Type: multipart/alternative; boundary="------------010406070407070704070905" This is a multi-part message in MIME format. --------------010406070407070704070905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, We have a xen machine running on debian 6 (xen 4.0.1) with 5 windows HVM (huge load) that use dedicated iscsi disks for each VM on an openfiler 2.3 device. We are trying to update to ubuntu 12.04 on the same machine (xen 4.1.2). Once we solved all the small bug (qemu-linaro -> qemu) and adapt the config files to the new version of XEN, we where able to start all the HVM's. While the load is low the every thing works great, but when every body starts working the system crash. Due the crash there are no logs or anything I can look at. Any idea? Thanks for your help and sorry about my very bad english. Iñigo Salvat --------------010406070407070704070905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

We have a xen machine running on debian 6 (xen 4.0.1) with 5 windows HVM (huge load) that use dedicated iscsi disks for each VM on an openfiler 2.3 device.

We are trying to update to ubuntu 12.04 on the same machine (xen 4.1.2). Once we solved all the small bug (qemu-linaro -> qemu) and adapt the config files to the new version of XEN, we where able to start all the HVM's.

While the load is low the every thing works great, but when every body starts working the system crash. Due the crash there are no logs or anything I can look at.

Any idea?

Thanks for your help and sorry about my very bad english.

Iñigo Salvat
--------------010406070407070704070905-- --===============5646931488408153040== 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 --===============5646931488408153040==-- From xen-users-bounces@lists.xen.org Wed Mar 06 12:34:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 12:34: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 1UDDWZ-0000Dg-0t; Wed, 06 Mar 2013 12:32:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDDWX-0000Da-Iu for xen-users@lists.xen.org; Wed, 06 Mar 2013 12:32:45 +0000 Received: from [85.158.139.211:49098] by server-13.bemta-5.messagelabs.com id D7/40-16871-C6737315; Wed, 06 Mar 2013 12:32:44 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1362573162!18246940!1 X-Originating-IP: [209.85.223.182] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1526 invoked from network); 6 Mar 2013 12:32:44 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 12:32:44 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so9355512iea.27 for ; Wed, 06 Mar 2013 04:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wSQckjuNE9mAc4BeWzu81Z0D3NRyTBvr7xPg+/ByoHo=; b=djmvjO4hNzPl+AjBHIPVZQIIJdNDNKRUzKuQEAcMnlzsiRzC0Fy7Ag63yUDBktLxO5 i6EyGoQac7QFJ0Fr5C2KAbSBX8y7yvnK0xQgf1DRL29KC91CPd9favZ0aEzXErSgqdOu y7qU/p5RmsNBv1iP0mIsAgI4QKWyNhr476wCPQw1kv86T+4Km6k9Q74KuP1Fp2cue5Tb XmbVk8DG3NfinndsnBTjvJryVr5GBwjcSFhcbD/mZFVGqd+Wrvvsr0q5ni4U+VpY0Tri rtoNHG0OMji2G7FTvbedNpswPed5YCRlozPJybLzdXP5UNDtuAHzsMP+VANS+tZ7Wyc5 MkIA== MIME-Version: 1.0 X-Received: by 10.50.13.228 with SMTP id k4mr10486236igc.30.1362573162261; Wed, 06 Mar 2013 04:32:42 -0800 (PST) Received: by 10.42.41.5 with HTTP; Wed, 6 Mar 2013 04:32:42 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Mar 2013 05:32:42 -0700 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============0332640297919226970==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0332640297919226970== Content-Type: multipart/alternative; boundary=f46d04462d4651374004d740c98a --f46d04462d4651374004d740c98a Content-Type: text/plain; charset=ISO-8859-1 I had nss installed when I compiled the package I did not install lib32-nss I will try that. It seems that creation of hvm was rewritten in source code I don't know that what is causing issue. I compiled 26527 with spice myself and that worked fine On Tue, Mar 5, 2013 at 9:50 PM, Sean Greenslade wrote: > On Tue, Mar 5, 2013 at 11:34 PM, jacek burghardt > wrote: > > Well i believe there is bug in xen and spice. When i tried to compile > 26657 > > rev and it fails at booting hvm . > > > > Did you install nss (and maybe lib32-nss)? Can you boot a PV domain > OK? Also, the rev that I got working was 26666. That's the one I > linked to the second time and that one works with PV and HVM domains. > > Also, some specific error messages wouldn't hurt. "fails at booting" > doesn't give much to go on. > > -- > --Zootboy > > Sent from some sort of computing device. > --f46d04462d4651374004d740c98a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had nss installed when I compiled the package I did not install lib32-nss= I will try that. It seems that creation of hvm was rewritten in source cod= e I don't know that what is causing issue. I compiled 26527 with spice = myself and that worked fine


On Tue, Mar 5, 2013 at 9:50 PM, Sean Gre= enslade <zootboysean@gmail.com> wrote:
On Tue, Mar 5, 2013 at 11:34 PM, jacek = burghardt
<jaceksbu= rghardt@gmail.com> wrote:
> Well i believe there is bug in xen and spice. When i tried to compile = 26657
> rev and it fails at booting hvm .
>

Did you install nss (and maybe lib32-nss)? Can you boot a PV domain OK? Also, the rev that I got working was 26666. That's the one I
linked to the second time and that one works with PV and HVM domains.

Also, some specific error messages wouldn't hurt. "fails at bootin= g"
doesn't give much to go on.

--
--Zootboy

Sent from some sort of computing device.

--f46d04462d4651374004d740c98a-- --===============0332640297919226970== 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 --===============0332640297919226970==-- From xen-users-bounces@lists.xen.org Wed Mar 06 12:34:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 12:34: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 1UDDWZ-0000Dg-0t; Wed, 06 Mar 2013 12:32:47 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDDWX-0000Da-Iu for xen-users@lists.xen.org; Wed, 06 Mar 2013 12:32:45 +0000 Received: from [85.158.139.211:49098] by server-13.bemta-5.messagelabs.com id D7/40-16871-C6737315; Wed, 06 Mar 2013 12:32:44 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1362573162!18246940!1 X-Originating-IP: [209.85.223.182] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1526 invoked from network); 6 Mar 2013 12:32:44 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 12:32:44 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so9355512iea.27 for ; Wed, 06 Mar 2013 04:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wSQckjuNE9mAc4BeWzu81Z0D3NRyTBvr7xPg+/ByoHo=; b=djmvjO4hNzPl+AjBHIPVZQIIJdNDNKRUzKuQEAcMnlzsiRzC0Fy7Ag63yUDBktLxO5 i6EyGoQac7QFJ0Fr5C2KAbSBX8y7yvnK0xQgf1DRL29KC91CPd9favZ0aEzXErSgqdOu y7qU/p5RmsNBv1iP0mIsAgI4QKWyNhr476wCPQw1kv86T+4Km6k9Q74KuP1Fp2cue5Tb XmbVk8DG3NfinndsnBTjvJryVr5GBwjcSFhcbD/mZFVGqd+Wrvvsr0q5ni4U+VpY0Tri rtoNHG0OMji2G7FTvbedNpswPed5YCRlozPJybLzdXP5UNDtuAHzsMP+VANS+tZ7Wyc5 MkIA== MIME-Version: 1.0 X-Received: by 10.50.13.228 with SMTP id k4mr10486236igc.30.1362573162261; Wed, 06 Mar 2013 04:32:42 -0800 (PST) Received: by 10.42.41.5 with HTTP; Wed, 6 Mar 2013 04:32:42 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Mar 2013 05:32:42 -0700 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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="===============0332640297919226970==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0332640297919226970== Content-Type: multipart/alternative; boundary=f46d04462d4651374004d740c98a --f46d04462d4651374004d740c98a Content-Type: text/plain; charset=ISO-8859-1 I had nss installed when I compiled the package I did not install lib32-nss I will try that. It seems that creation of hvm was rewritten in source code I don't know that what is causing issue. I compiled 26527 with spice myself and that worked fine On Tue, Mar 5, 2013 at 9:50 PM, Sean Greenslade wrote: > On Tue, Mar 5, 2013 at 11:34 PM, jacek burghardt > wrote: > > Well i believe there is bug in xen and spice. When i tried to compile > 26657 > > rev and it fails at booting hvm . > > > > Did you install nss (and maybe lib32-nss)? Can you boot a PV domain > OK? Also, the rev that I got working was 26666. That's the one I > linked to the second time and that one works with PV and HVM domains. > > Also, some specific error messages wouldn't hurt. "fails at booting" > doesn't give much to go on. > > -- > --Zootboy > > Sent from some sort of computing device. > --f46d04462d4651374004d740c98a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had nss installed when I compiled the package I did not install lib32-nss= I will try that. It seems that creation of hvm was rewritten in source cod= e I don't know that what is causing issue. I compiled 26527 with spice = myself and that worked fine


On Tue, Mar 5, 2013 at 9:50 PM, Sean Gre= enslade <zootboysean@gmail.com> wrote:
On Tue, Mar 5, 2013 at 11:34 PM, jacek = burghardt
<jaceksbu= rghardt@gmail.com> wrote:
> Well i believe there is bug in xen and spice. When i tried to compile = 26657
> rev and it fails at booting hvm .
>

Did you install nss (and maybe lib32-nss)? Can you boot a PV domain OK? Also, the rev that I got working was 26666. That's the one I
linked to the second time and that one works with PV and HVM domains.

Also, some specific error messages wouldn't hurt. "fails at bootin= g"
doesn't give much to go on.

--
--Zootboy

Sent from some sort of computing device.

--f46d04462d4651374004d740c98a-- --===============0332640297919226970== 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 --===============0332640297919226970==-- From xen-users-bounces@lists.xen.org Wed Mar 06 12:36:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 12:36: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 1UDDZZ-0000O5-S9; Wed, 06 Mar 2013 12:35:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDDZY-0000Nx-En for xen-users@lists.xen.org; Wed, 06 Mar 2013 12:35:52 +0000 Received: from [85.158.139.211:22876] by server-1.bemta-5.messagelabs.com id FD/EE-14063-72837315; Wed, 06 Mar 2013 12:35:51 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1362573350!18284312!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 677 invoked from network); 6 Mar 2013 12:35:50 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 12:35:50 -0000 Received: by mail-wg0-f48.google.com with SMTP id 16so7269894wgi.3 for ; Wed, 06 Mar 2013 04:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=yoD6ZxLFSIpXvCgrN/qtimfj5u9hh2JmoCk8YZVEWpY=; b=WhtpCynKnE1jvoQAAbFuyOcL7NWZezM50VTItMpY7g2mJJnY0IFoE0mSbslnoDjosc vrqCC27Em1swt4x4ZzN1Pl62HvVV+ubODh8yQDONHIq8WVnqsKEiC1EE9k+eKRuLZI45 +yt/riB35ORf5ehGGGK8CNxGUM9XicT3BvvFCijgSf7YegLDXFgqhK57EO0ywA2qDaNx //jcyneY2jtyEqRyEJaJr7vzqjxWkrkPnq/1KIcOMeV/lLnqyS5Cb11nbc2Gx8kw7Xqh f12S68AAHfiE3KeHXiXzzU3h0ilcuN7gMMz+SyUXVrTuOhP5hGFuVuNwJO+Jzc3LMcuC vw6Q== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr46519576wjb.15.1362573350015; Wed, 06 Mar 2013 04:35:50 -0800 (PST) Received: by 10.216.236.13 with HTTP; Wed, 6 Mar 2013 04:35:49 -0800 (PST) Date: Wed, 6 Mar 2013 13:35:49 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============4626986723149292646==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4626986723149292646== Content-Type: multipart/alternative; boundary=089e010d85748218d304d740d40f --089e010d85748218d304d740d40f Content-Type: text/plain; charset=ISO-8859-1 Hi all, Today I got problem below and my domU become unresponsive and I should restart the pc to make it running properly again. [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 seconds. [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 seconds. [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 seconds. [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 seconds. [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 seconds. [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 seconds. [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 seconds. [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 seconds. [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 seconds. [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Does any body have clue regarding this problem? Regards, Agya --089e010d85748218d304d740d40f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya
--089e010d85748218d304d740d40f-- --===============4626986723149292646== 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 --===============4626986723149292646==-- From xen-users-bounces@lists.xen.org Wed Mar 06 12:36:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 12:36: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 1UDDZZ-0000O5-S9; Wed, 06 Mar 2013 12:35:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDDZY-0000Nx-En for xen-users@lists.xen.org; Wed, 06 Mar 2013 12:35:52 +0000 Received: from [85.158.139.211:22876] by server-1.bemta-5.messagelabs.com id FD/EE-14063-72837315; Wed, 06 Mar 2013 12:35:51 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1362573350!18284312!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 677 invoked from network); 6 Mar 2013 12:35:50 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 12:35:50 -0000 Received: by mail-wg0-f48.google.com with SMTP id 16so7269894wgi.3 for ; Wed, 06 Mar 2013 04:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=yoD6ZxLFSIpXvCgrN/qtimfj5u9hh2JmoCk8YZVEWpY=; b=WhtpCynKnE1jvoQAAbFuyOcL7NWZezM50VTItMpY7g2mJJnY0IFoE0mSbslnoDjosc vrqCC27Em1swt4x4ZzN1Pl62HvVV+ubODh8yQDONHIq8WVnqsKEiC1EE9k+eKRuLZI45 +yt/riB35ORf5ehGGGK8CNxGUM9XicT3BvvFCijgSf7YegLDXFgqhK57EO0ywA2qDaNx //jcyneY2jtyEqRyEJaJr7vzqjxWkrkPnq/1KIcOMeV/lLnqyS5Cb11nbc2Gx8kw7Xqh f12S68AAHfiE3KeHXiXzzU3h0ilcuN7gMMz+SyUXVrTuOhP5hGFuVuNwJO+Jzc3LMcuC vw6Q== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr46519576wjb.15.1362573350015; Wed, 06 Mar 2013 04:35:50 -0800 (PST) Received: by 10.216.236.13 with HTTP; Wed, 6 Mar 2013 04:35:49 -0800 (PST) Date: Wed, 6 Mar 2013 13:35:49 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============4626986723149292646==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4626986723149292646== Content-Type: multipart/alternative; boundary=089e010d85748218d304d740d40f --089e010d85748218d304d740d40f Content-Type: text/plain; charset=ISO-8859-1 Hi all, Today I got problem below and my domU become unresponsive and I should restart the pc to make it running properly again. [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 seconds. [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 seconds. [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 seconds. [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 seconds. [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 seconds. [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 seconds. [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 seconds. [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 seconds. [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 seconds. [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Does any body have clue regarding this problem? Regards, Agya --089e010d85748218d304d740d40f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya
--089e010d85748218d304d740d40f-- --===============4626986723149292646== 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 --===============4626986723149292646==-- From xen-users-bounces@lists.xen.org Wed Mar 06 13:15:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 13:15: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 1UDEBg-0004vi-HR; Wed, 06 Mar 2013 13:15:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDEBf-0004vT-8A for xen-users@lists.xen.org; Wed, 06 Mar 2013 13:15:15 +0000 Received: from [85.158.138.51:40035] by server-13.bemta-3.messagelabs.com id 11/55-25744-26147315; Wed, 06 Mar 2013 13:15:14 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1362575709!28843596!1 X-Originating-IP: [209.85.214.177] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23397 invoked from network); 6 Mar 2013 13:15:10 -0000 Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com) (209.85.214.177) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 13:15:10 -0000 Received: by mail-ob0-f177.google.com with SMTP id eh20so3538888obb.36 for ; Wed, 06 Mar 2013 05:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5IlcZ9nUzV+6GSNHP41pfqg/Krasrvp5OE92EacRjlI=; b=H5Ef1mffSSzANmc0PzMuS+PPdG3tY79Ug2yz60AZ6fPox9v1c67TdBYvFBQlZ7Q+Xl X1cszcEonLXpYyFwPHJgrHIQi50Lv6zt1c3jxsaDnEwiGR5rNcaaeiNi7UC3xSFUadui phrFAnh2AhhiR4p8aWJWpuErlbgZ6+YJkMaGdGGY5GDxeHK88CygyW8/5vZcawUhl15n y+f5ExEz8IkpF841bgEXwibkNp9LIrRWkZ+jlnwRBbIlSGWUXEadhZ+b96/Jq1PL5hV6 UQu58No5kcxyaYj1u5hiElLed6EJk6YynC9NtooxeIea1nmgOWXWFeWYWC5NrGqFLg4Z /w7Q== MIME-Version: 1.0 X-Received: by 10.182.157.104 with SMTP id wl8mr22600934obb.79.1362575709116; Wed, 06 Mar 2013 05:15:09 -0800 (PST) Received: by 10.60.57.102 with HTTP; Wed, 6 Mar 2013 05:15:08 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 08:15:08 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============7102839579877330091==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7102839579877330091== Content-Type: multipart/alternative; boundary=f46d044281a01f1e1204d741616c --f46d044281a01f1e1204d741616c Content-Type: text/plain; charset=ISO-8859-1 I haven't read every message in this string, so forgive me if I'm missing something. But just a comment with regard to what was previously stated by another: "I recommend not using the latest 13-1 because it creates a similar behavior you mentioned on my machine. But catalyst 12-10 seems to work fine, so i would advice you trying that one." Although I've read that others have had success with Catalyst 12.10, in my case, that driver was not stable for GPU passthrough with an AMD Radeon HD 6670 and a Windows 7 guest. However, *Catalyst 12.3* on a clean install of Windows 7 (on which no other version of Catalyst has ever been installed) works well for me. (I've read that removal process for Catalyst isn't complete, so a clean install is better.) Hope the above helps. GizmoChicken On Wed, Mar 6, 2013 at 6:22 AM, Guilherme Suzuki wrote: > I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel > modules) and brought Xen from RPM source (version 4.21) > > I had the same results everyone's has achieved with consumer cards (it > only works with dom0 freshly booted) > > This time, though, I tried primary VGA passthru from the intel onboard, > which does have FLR. And it worked smoothly! > > Doing a little research, FLR is not the unique way of refreshing a device > (theres d3d0, bus and a few others). I'll send an email to AMD and see if > they can help us resetting theirs VGAs without rebooting the computer > everytime. > > Have a nice day > > On Mar 5, 2013 8:45 AM, "Guilherme Suzuki" wrote: > > Ow, by the way, thanks guys for the support! > > Who tells that linux guys can't get help? Have a good day... :) > > > > On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" wrote: > > Casey DeLorme, I noticed... > > > > > > On Mar 5, 2013 5:39 AM, "Peter Maloney" < > peter.maloney@brockmann-consult.de> wrote: > > grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the > double message if you got... > > > > > > > > > > A few things I can add... > > > > > My card is a Sapphire Radeon HD 6770. And I'm currently using cata... > > > > > > > > > > > > >> > > > >> Hello Guilherme, was following your exchange and wanted to see how > this turne... > > >... > > >> Seco... > > > > > > > > > > > > -- > > > > > > -------------------------------------------- > > > Peter Maloney > > > Brockman... > > Max-... > > > > > > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str... > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --f46d044281a01f1e1204d741616c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I haven't read every message in this string, so forgive me if I'm m= issing something.=A0 But just a comment with regard to what was previously = stated by another:

"I recommend= not using the latest 13-1 because it creates a similar behavior you mentio= ned on my machine. But catalyst 12-10 seems to work fine, so i would advice= you trying that one."

Although I've read that others have had success with Catalyst= 12.10, in my case, that driver was not stable for GPU passthrough with an = AMD Radeon HD 6670 and a Windows 7 guest.

However, Catalyst 12= .3 on a clean install of Windows 7 (on which no other version of Ca= talyst has ever been installed) works well for me.=A0 (I've read that r= emoval process for Catalyst isn't complete, so a clean install is bette= r.)

Hope the above helps.

GizmoChicken



On Wed, Mar 6, 2013 at 6:22 AM, Guilherme Suzuki <suzuki.g= ui@gmail.com> wrote:

I reinstall Fedora 18, kernel 3.6-10 with= embedded xen (not as kernel modules) and brought Xen from RPM source (vers= ion 4.21)

I had the same results everyone's has achieved with consumer cards (= it only works with dom0 freshly booted)

This time, though, I tried primary VGA passthru from the intel onboard, = which does have FLR. And it worked smoothly!

Doing a little research, FLR is not the unique way of refreshing a devic= e (theres d3d0, bus and a few others). I'll send an email to AMD and se= e if they can help us resetting theirs VGAs without rebooting the computer = everytime.

Have a nice day

On Mar 5, 2013 8:45 AM, "Guilherme Suzuki&quo= t; <suzuki.gui= @gmail.com> wrote:

Ow, by the way, thanks guys for the sup= port!

Who tells that linux guys can't get help? Have a good day... :)



On Mar 5, 2013 8:39 AM, "Guilherme Suzuki&qu= ot; <suzuki.gu= i@gmail.com> wrote:

Casey DeLorme, I noticed...=





On Mar 5, 2013 5:39 AM, "Peter Maloney" <peter.malo= ney@brockmann-consult.de> wrote:

grr Thunderbird doesn't cc everyone when I h= it "reply list", sorry for the double message if you got...


>
> >
> > A few things I can add...
> >

> My card is a Sapphire Radeon HD 67= 70. And I'm currently using cata...


>
>
> >
> > >>=
> > >> Hello Guilherme, was following your exchange and wan= ted to see how this turne...

> >...

>> Seco...


&= gt;
>
> >
> > --
> >
> > -------= -------------------------------------
> > Peter Maloney
> > Brockman...

> Max-...







--
--------------------------------------------
Peter Maloney
Brock= mann Consult

Max-Planck-Str...


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--f46d044281a01f1e1204d741616c-- --===============7102839579877330091== 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 --===============7102839579877330091==-- From xen-users-bounces@lists.xen.org Wed Mar 06 13:15:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 13:15: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 1UDEBg-0004vi-HR; Wed, 06 Mar 2013 13:15:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDEBf-0004vT-8A for xen-users@lists.xen.org; Wed, 06 Mar 2013 13:15:15 +0000 Received: from [85.158.138.51:40035] by server-13.bemta-3.messagelabs.com id 11/55-25744-26147315; Wed, 06 Mar 2013 13:15:14 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-8.tower-174.messagelabs.com!1362575709!28843596!1 X-Originating-IP: [209.85.214.177] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23397 invoked from network); 6 Mar 2013 13:15:10 -0000 Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com) (209.85.214.177) by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 13:15:10 -0000 Received: by mail-ob0-f177.google.com with SMTP id eh20so3538888obb.36 for ; Wed, 06 Mar 2013 05:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5IlcZ9nUzV+6GSNHP41pfqg/Krasrvp5OE92EacRjlI=; b=H5Ef1mffSSzANmc0PzMuS+PPdG3tY79Ug2yz60AZ6fPox9v1c67TdBYvFBQlZ7Q+Xl X1cszcEonLXpYyFwPHJgrHIQi50Lv6zt1c3jxsaDnEwiGR5rNcaaeiNi7UC3xSFUadui phrFAnh2AhhiR4p8aWJWpuErlbgZ6+YJkMaGdGGY5GDxeHK88CygyW8/5vZcawUhl15n y+f5ExEz8IkpF841bgEXwibkNp9LIrRWkZ+jlnwRBbIlSGWUXEadhZ+b96/Jq1PL5hV6 UQu58No5kcxyaYj1u5hiElLed6EJk6YynC9NtooxeIea1nmgOWXWFeWYWC5NrGqFLg4Z /w7Q== MIME-Version: 1.0 X-Received: by 10.182.157.104 with SMTP id wl8mr22600934obb.79.1362575709116; Wed, 06 Mar 2013 05:15:09 -0800 (PST) Received: by 10.60.57.102 with HTTP; Wed, 6 Mar 2013 05:15:08 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 08:15:08 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============7102839579877330091==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7102839579877330091== Content-Type: multipart/alternative; boundary=f46d044281a01f1e1204d741616c --f46d044281a01f1e1204d741616c Content-Type: text/plain; charset=ISO-8859-1 I haven't read every message in this string, so forgive me if I'm missing something. But just a comment with regard to what was previously stated by another: "I recommend not using the latest 13-1 because it creates a similar behavior you mentioned on my machine. But catalyst 12-10 seems to work fine, so i would advice you trying that one." Although I've read that others have had success with Catalyst 12.10, in my case, that driver was not stable for GPU passthrough with an AMD Radeon HD 6670 and a Windows 7 guest. However, *Catalyst 12.3* on a clean install of Windows 7 (on which no other version of Catalyst has ever been installed) works well for me. (I've read that removal process for Catalyst isn't complete, so a clean install is better.) Hope the above helps. GizmoChicken On Wed, Mar 6, 2013 at 6:22 AM, Guilherme Suzuki wrote: > I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel > modules) and brought Xen from RPM source (version 4.21) > > I had the same results everyone's has achieved with consumer cards (it > only works with dom0 freshly booted) > > This time, though, I tried primary VGA passthru from the intel onboard, > which does have FLR. And it worked smoothly! > > Doing a little research, FLR is not the unique way of refreshing a device > (theres d3d0, bus and a few others). I'll send an email to AMD and see if > they can help us resetting theirs VGAs without rebooting the computer > everytime. > > Have a nice day > > On Mar 5, 2013 8:45 AM, "Guilherme Suzuki" wrote: > > Ow, by the way, thanks guys for the support! > > Who tells that linux guys can't get help? Have a good day... :) > > > > On Mar 5, 2013 8:39 AM, "Guilherme Suzuki" wrote: > > Casey DeLorme, I noticed... > > > > > > On Mar 5, 2013 5:39 AM, "Peter Maloney" < > peter.maloney@brockmann-consult.de> wrote: > > grr Thunderbird doesn't cc everyone when I hit "reply list", sorry for the > double message if you got... > > > > > > > > > > A few things I can add... > > > > > My card is a Sapphire Radeon HD 6770. And I'm currently using cata... > > > > > > > > > > > > >> > > > >> Hello Guilherme, was following your exchange and wanted to see how > this turne... > > >... > > >> Seco... > > > > > > > > > > > > -- > > > > > > -------------------------------------------- > > > Peter Maloney > > > Brockman... > > Max-... > > > > > > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str... > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --f46d044281a01f1e1204d741616c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I haven't read every message in this string, so forgive me if I'm m= issing something.=A0 But just a comment with regard to what was previously = stated by another:

"I recommend= not using the latest 13-1 because it creates a similar behavior you mentio= ned on my machine. But catalyst 12-10 seems to work fine, so i would advice= you trying that one."

Although I've read that others have had success with Catalyst= 12.10, in my case, that driver was not stable for GPU passthrough with an = AMD Radeon HD 6670 and a Windows 7 guest.

However, Catalyst 12= .3 on a clean install of Windows 7 (on which no other version of Ca= talyst has ever been installed) works well for me.=A0 (I've read that r= emoval process for Catalyst isn't complete, so a clean install is bette= r.)

Hope the above helps.

GizmoChicken



On Wed, Mar 6, 2013 at 6:22 AM, Guilherme Suzuki <suzuki.g= ui@gmail.com> wrote:

I reinstall Fedora 18, kernel 3.6-10 with= embedded xen (not as kernel modules) and brought Xen from RPM source (vers= ion 4.21)

I had the same results everyone's has achieved with consumer cards (= it only works with dom0 freshly booted)

This time, though, I tried primary VGA passthru from the intel onboard, = which does have FLR. And it worked smoothly!

Doing a little research, FLR is not the unique way of refreshing a devic= e (theres d3d0, bus and a few others). I'll send an email to AMD and se= e if they can help us resetting theirs VGAs without rebooting the computer = everytime.

Have a nice day

On Mar 5, 2013 8:45 AM, "Guilherme Suzuki&quo= t; <suzuki.gui= @gmail.com> wrote:

Ow, by the way, thanks guys for the sup= port!

Who tells that linux guys can't get help? Have a good day... :)



On Mar 5, 2013 8:39 AM, "Guilherme Suzuki&qu= ot; <suzuki.gu= i@gmail.com> wrote:

Casey DeLorme, I noticed...=





On Mar 5, 2013 5:39 AM, "Peter Maloney" <peter.malo= ney@brockmann-consult.de> wrote:

grr Thunderbird doesn't cc everyone when I h= it "reply list", sorry for the double message if you got...


>
> >
> > A few things I can add...
> >

> My card is a Sapphire Radeon HD 67= 70. And I'm currently using cata...


>
>
> >
> > >>=
> > >> Hello Guilherme, was following your exchange and wan= ted to see how this turne...

> >...

>> Seco...


&= gt;
>
> >
> > --
> >
> > -------= -------------------------------------
> > Peter Maloney
> > Brockman...

> Max-...







--
--------------------------------------------
Peter Maloney
Brock= mann Consult

Max-Planck-Str...


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--f46d044281a01f1e1204d741616c-- --===============7102839579877330091== 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 --===============7102839579877330091==-- From xen-users-bounces@lists.xen.org Wed Mar 06 13:32:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 13:32: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 1UDERy-0005ny-Ad; Wed, 06 Mar 2013 13:32:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDERw-0005np-P9 for xen-users@lists.xen.org; Wed, 06 Mar 2013 13:32:05 +0000 Received: from [85.158.137.99:2381] by server-11.bemta-3.messagelabs.com id EC/44-01263-F4547315; Wed, 06 Mar 2013 13:31:59 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1362576533!14666401!1 X-Originating-IP: [209.85.223.170] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1759 invoked from network); 6 Mar 2013 13:28:55 -0000 Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com) (209.85.223.170) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 13:28:55 -0000 Received: by mail-ie0-f170.google.com with SMTP id c11so9557686ieb.29 for ; Wed, 06 Mar 2013 05:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=THJhyjk8xK8lTC7CEvwjTwRbnAPjyS2/YbSv3yr3/Qo=; b=pLU8JSqF/piHqn1ukP1Y+0396roEGPNtncmoCIRnQoFKnDuk69UMW9OWltJwk3Qn5o BdprdES6+ZqNPmTL2t1ajKWTGL4WsxavnplkUXdSROSGnErGvvZ0Fhy9ALsop7RP2lJ8 5stvll2m/ZNJSW6qbYZxA0RcecHCckns8QxuzH8YuuL26o5C8ROtv1pROS0iKjgWgMX6 Q88vIs9GLJ3mO6vFQRqIgE5j9GdhasCmUQxhBdmtuhY5M3G2DYVDZ7x7KdcWgEfzyaxa uqtFUXwtIxKkLqoS7NjMQi2by6Kl9goPdTu4xcrYm3FpUl7z3c6yGDiRR+cAWekBTSme 7u6A== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr10568338igc.91.1362576533321; Wed, 06 Mar 2013 05:28:53 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 05:28:53 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 05:28:53 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 10:28:53 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8164185437165464194==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8164185437165464194== Content-Type: multipart/alternative; boundary=14dae93403453f802e04d74192f5 --14dae93403453f802e04d74192f5 Content-Type: text/plain; charset=ISO-8859-1 Gizmo, hi! Have you been able to reboot your VM and get everything working fine? On Mar 6, 2013 10:15 AM, "Gizmo Chicken" wrote: I haven't read every message in this string, so forgive me if I'm missing something. But just a comment with regard to what was previously stated by another: "I recommend not using the latest 13-1 because it creates a similar behavior you mentioned on my m... Although I've read that others have had success with Catalyst 12.10, in my case, that driver was not stable for GPU passthrough with an AMD Radeon HD 6670 and a Windows 7 guest. However, *Catalyst 12.3* on a clean install of Windows 7 (on which no other version of Catalyst has ever been installed) works well for me. (I've read that removal process for Catalyst isn't complete, so a clean install is better.) Hope the above helps. GizmoChicken On Wed, Mar 6, 2013 at 6:22 AM, Guilherme Suzuki wrote: > > > > I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel > modules) and brought Xen f... > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org... > --14dae93403453f802e04d74192f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Gizmo, hi!

Have you been able to reboot your VM and get everything working fine?

On Mar 6, 2013 10:15 AM, "Gizmo Chicken&q= uot; <gizmochicken@gmail.com> wrote:

I haven't read every message in this string, so fo= rgive me if I'm missing something.=A0 But just a comment with regard to= what was previously stated by another:



"I recommend not using the latest 13-1= because it creates a similar behavior you mentioned on my m...

A= lthough I've read that others have had success with Catalyst 12.10, in = my case, that driver was not stable for GPU passthrough with an AMD Radeon = HD 6670 and a Windows 7 guest.

However, Catalyst 12.3 on a clean install of Windows 7 (o= n which no other version of Catalyst has ever been installed) works well fo= r me.=A0 (I've read that removal process for Catalyst isn't complet= e, so a clean install is better.)

Hope the above helps.

GizmoChicken



On Wed, Mar 6, 2013 at 6:22 AM, Gui= lherme Suzuki <suzuki.gui@gmail.= com> wrote:

>
> I re= install Fedora 18, kernel 3.6-10 with embedded xen (not as kernel modules) = and brought Xen f...

> ___________________________________________= ____
> Xen-users mailing list
> Xen-users@lists.xen.org...


--14dae93403453f802e04d74192f5-- --===============8164185437165464194== 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 --===============8164185437165464194==-- From xen-users-bounces@lists.xen.org Wed Mar 06 13:32:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 13:32: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 1UDERy-0005ny-Ad; Wed, 06 Mar 2013 13:32:06 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDERw-0005np-P9 for xen-users@lists.xen.org; Wed, 06 Mar 2013 13:32:05 +0000 Received: from [85.158.137.99:2381] by server-11.bemta-3.messagelabs.com id EC/44-01263-F4547315; Wed, 06 Mar 2013 13:31:59 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1362576533!14666401!1 X-Originating-IP: [209.85.223.170] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1759 invoked from network); 6 Mar 2013 13:28:55 -0000 Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com) (209.85.223.170) by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 13:28:55 -0000 Received: by mail-ie0-f170.google.com with SMTP id c11so9557686ieb.29 for ; Wed, 06 Mar 2013 05:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=THJhyjk8xK8lTC7CEvwjTwRbnAPjyS2/YbSv3yr3/Qo=; b=pLU8JSqF/piHqn1ukP1Y+0396roEGPNtncmoCIRnQoFKnDuk69UMW9OWltJwk3Qn5o BdprdES6+ZqNPmTL2t1ajKWTGL4WsxavnplkUXdSROSGnErGvvZ0Fhy9ALsop7RP2lJ8 5stvll2m/ZNJSW6qbYZxA0RcecHCckns8QxuzH8YuuL26o5C8ROtv1pROS0iKjgWgMX6 Q88vIs9GLJ3mO6vFQRqIgE5j9GdhasCmUQxhBdmtuhY5M3G2DYVDZ7x7KdcWgEfzyaxa uqtFUXwtIxKkLqoS7NjMQi2by6Kl9goPdTu4xcrYm3FpUl7z3c6yGDiRR+cAWekBTSme 7u6A== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr10568338igc.91.1362576533321; Wed, 06 Mar 2013 05:28:53 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 05:28:53 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 05:28:53 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 10:28:53 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8164185437165464194==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8164185437165464194== Content-Type: multipart/alternative; boundary=14dae93403453f802e04d74192f5 --14dae93403453f802e04d74192f5 Content-Type: text/plain; charset=ISO-8859-1 Gizmo, hi! Have you been able to reboot your VM and get everything working fine? On Mar 6, 2013 10:15 AM, "Gizmo Chicken" wrote: I haven't read every message in this string, so forgive me if I'm missing something. But just a comment with regard to what was previously stated by another: "I recommend not using the latest 13-1 because it creates a similar behavior you mentioned on my m... Although I've read that others have had success with Catalyst 12.10, in my case, that driver was not stable for GPU passthrough with an AMD Radeon HD 6670 and a Windows 7 guest. However, *Catalyst 12.3* on a clean install of Windows 7 (on which no other version of Catalyst has ever been installed) works well for me. (I've read that removal process for Catalyst isn't complete, so a clean install is better.) Hope the above helps. GizmoChicken On Wed, Mar 6, 2013 at 6:22 AM, Guilherme Suzuki wrote: > > > > I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel > modules) and brought Xen f... > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org... > --14dae93403453f802e04d74192f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Gizmo, hi!

Have you been able to reboot your VM and get everything working fine?

On Mar 6, 2013 10:15 AM, "Gizmo Chicken&q= uot; <gizmochicken@gmail.com> wrote:

I haven't read every message in this string, so fo= rgive me if I'm missing something.=A0 But just a comment with regard to= what was previously stated by another:



"I recommend not using the latest 13-1= because it creates a similar behavior you mentioned on my m...

A= lthough I've read that others have had success with Catalyst 12.10, in = my case, that driver was not stable for GPU passthrough with an AMD Radeon = HD 6670 and a Windows 7 guest.

However, Catalyst 12.3 on a clean install of Windows 7 (o= n which no other version of Catalyst has ever been installed) works well fo= r me.=A0 (I've read that removal process for Catalyst isn't complet= e, so a clean install is better.)

Hope the above helps.

GizmoChicken



On Wed, Mar 6, 2013 at 6:22 AM, Gui= lherme Suzuki <suzuki.gui@gmail.= com> wrote:

>
> I re= install Fedora 18, kernel 3.6-10 with embedded xen (not as kernel modules) = and brought Xen f...

> ___________________________________________= ____
> Xen-users mailing list
> Xen-users@lists.xen.org...


--14dae93403453f802e04d74192f5-- --===============8164185437165464194== 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 --===============8164185437165464194==-- From xen-users-bounces@lists.xen.org Wed Mar 06 14:46:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 14:46: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 1UDFbC-0000Va-63; Wed, 06 Mar 2013 14:45:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDFbA-0000VB-9E for xen-users@lists.xen.org; Wed, 06 Mar 2013 14:45:40 +0000 Received: from [85.158.139.83:48256] by server-16.bemta-5.messagelabs.com id E0/0D-02543-39657315; Wed, 06 Mar 2013 14:45:39 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-15.tower-182.messagelabs.com!1362581110!27399731!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMDQ1MA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30017 invoked from network); 6 Mar 2013 14:45:10 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-15.tower-182.messagelabs.com with SMTP; 6 Mar 2013 14:45:10 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:62411) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UDFZA-0007Gr-9Q (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Wed, 06 Mar 2013 14:43:36 +0000 Message-ID: <513755FE.4050401@cam.ac.uk> Date: Wed, 06 Mar 2013 14:43:10 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] Problems creating a simple hvm domU X-BeenThere: xen-users@lists.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'm probably doing something stupid but I've been pulling my hair out trying to create my first hvm domU. I have xen 4.2.1 installed (from source) on Ubuntu 12.10. My config file for the vm is as follows: #windows.cfg builder='hvm' memory = 2048 name = "Windows7Test" disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'destroy' boot="c" sdl=0 vnc=1 vnclisten="127.0.0.1" vncunused=1 vncconsole=0 vncpasswd="" stdvga=1 serial='pty' keymap='gb' I've made this as simple as possible whilst enabling vnc so that I should be able to view the vm. Note at this stage I don't even want to get to a windows install, I just want to start the vm. Calling xl -vvv create -c windows.cfg gives Parsing config from windowsTest.cfg libxl: debug: libxl_create.c:1174:do_domain_create: ao 0x89fc10: create: how=(nil) callback=(nil) poller=0x89fa10 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hda, backend tap unsuitable because blktap not available libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend qdisk libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, skipping bootloader libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x89ffc0: deregister unregistered libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=25, free_memkb=2816 libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 12 cpus and 2816 KB free selected xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9df68 xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19df68 xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019df68 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 xc: detail: elf_load_binary: phdr 0 at 0x0x7f20001ff000 -> 0x0x7f2000293df5 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=qdisk libxl: debug: libxl_dm.c:1142:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-dm with arguments: libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: /usr/lib/xen/bin/qemu-dm libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -d libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 20 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -domain-name libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: Windows7Test libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vnc libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 127.0.0.1:0 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vncunused libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -k libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: gb libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -serial libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: pty libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -videoram libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 8 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -std-vga libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -boot libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: c libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -acpi libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vcpu_avail libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 0x01 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -net libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: none libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -M libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: xenfv libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x8a01f8 wpath=/local/domain/0/device-model/20/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:1187:do_domain_create: ao 0x89fc10: inprogress: poller=0x89fa10, flags=i libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x8a01f8 wpath=/local/domain/0/device-model/20/state token=3/0: event epath=/local/domain/0/device-model/20/state libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x8a01f8 wpath=/local/domain/0/device-model/20/state token=3/0: deregister slotnum=3 libxl: error: libxl_dm.c:1212:device_model_spawn_outcome: domain 20 device model: spawn failed (rc=-3) libxl: debug: libxl_event.c:1677:libxl__ao_progress_report: ao 0x89fc10: progress report: callback queued aop=0x8a33f0 libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x89fc10: complete, rc=0 libxl: debug: libxl_event.c:1090:egc_run_callbacks: ao 0x89fc10: progress report: callback aop=0x8a33f0 libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x89fc10: destroy Daemon running with PID 5631 xenconsole: Could not read tty from store: No such file or directory libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 2 xc: debug: hypercall buffer: total allocations:1154 total releases:1154 xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 xc: debug: hypercall buffer: cache current size:4 xc: debug: hypercall buffer: cache hits:1145 misses:4 toobig:5 A domain is created and can be seen with xl list but it is not running. I do not know how to get any more debug information than this and all I can discern is that the spawn failed (rc=-3). Any help would be greatly appreciated. Matt _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 06 14:46:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 14:46: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 1UDFbC-0000Va-63; Wed, 06 Mar 2013 14:45:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDFbA-0000VB-9E for xen-users@lists.xen.org; Wed, 06 Mar 2013 14:45:40 +0000 Received: from [85.158.139.83:48256] by server-16.bemta-5.messagelabs.com id E0/0D-02543-39657315; Wed, 06 Mar 2013 14:45:39 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-15.tower-182.messagelabs.com!1362581110!27399731!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMDQ1MA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30017 invoked from network); 6 Mar 2013 14:45:10 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-15.tower-182.messagelabs.com with SMTP; 6 Mar 2013 14:45:10 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:62411) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UDFZA-0007Gr-9Q (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Wed, 06 Mar 2013 14:43:36 +0000 Message-ID: <513755FE.4050401@cam.ac.uk> Date: Wed, 06 Mar 2013 14:43:10 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] Problems creating a simple hvm domU X-BeenThere: xen-users@lists.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'm probably doing something stupid but I've been pulling my hair out trying to create my first hvm domU. I have xen 4.2.1 installed (from source) on Ubuntu 12.10. My config file for the vm is as follows: #windows.cfg builder='hvm' memory = 2048 name = "Windows7Test" disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'destroy' boot="c" sdl=0 vnc=1 vnclisten="127.0.0.1" vncunused=1 vncconsole=0 vncpasswd="" stdvga=1 serial='pty' keymap='gb' I've made this as simple as possible whilst enabling vnc so that I should be able to view the vm. Note at this stage I don't even want to get to a windows install, I just want to start the vm. Calling xl -vvv create -c windows.cfg gives Parsing config from windowsTest.cfg libxl: debug: libxl_create.c:1174:do_domain_create: ao 0x89fc10: create: how=(nil) callback=(nil) poller=0x89fa10 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hda, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=hda, backend tap unsuitable because blktap not available libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend qdisk libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, skipping bootloader libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x89ffc0: deregister unregistered libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=25, free_memkb=2816 libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 12 cpus and 2816 KB free selected xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9df68 xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19df68 xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000019df68 TOTAL: 0000000000000000->000000007f800000 ENTRY ADDRESS: 0000000000100000 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000003fb 1GB PAGES: 0x0000000000000000 xc: detail: elf_load_binary: phdr 0 at 0x0x7f20001ff000 -> 0x0x7f2000293df5 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=qdisk libxl: debug: libxl_dm.c:1142:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-dm with arguments: libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: /usr/lib/xen/bin/qemu-dm libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -d libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 20 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -domain-name libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: Windows7Test libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vnc libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 127.0.0.1:0 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vncunused libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -k libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: gb libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -serial libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: pty libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -videoram libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 8 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -std-vga libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -boot libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: c libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -acpi libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -vcpu_avail libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: 0x01 libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -net libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: none libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: -M libxl: debug: libxl_dm.c:1144:libxl__spawn_local_dm: xenfv libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x8a01f8 wpath=/local/domain/0/device-model/20/state token=3/0: register slotnum=3 libxl: debug: libxl_create.c:1187:do_domain_create: ao 0x89fc10: inprogress: poller=0x89fa10, flags=i libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x8a01f8 wpath=/local/domain/0/device-model/20/state token=3/0: event epath=/local/domain/0/device-model/20/state libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x8a01f8 wpath=/local/domain/0/device-model/20/state token=3/0: deregister slotnum=3 libxl: error: libxl_dm.c:1212:device_model_spawn_outcome: domain 20 device model: spawn failed (rc=-3) libxl: debug: libxl_event.c:1677:libxl__ao_progress_report: ao 0x89fc10: progress report: callback queued aop=0x8a33f0 libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x89fc10: complete, rc=0 libxl: debug: libxl_event.c:1090:egc_run_callbacks: ao 0x89fc10: progress report: callback aop=0x8a33f0 libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x89fc10: destroy Daemon running with PID 5631 xenconsole: Could not read tty from store: No such file or directory libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 2 xc: debug: hypercall buffer: total allocations:1154 total releases:1154 xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 xc: debug: hypercall buffer: cache current size:4 xc: debug: hypercall buffer: cache hits:1145 misses:4 toobig:5 A domain is created and can be seen with xl list but it is not running. I do not know how to get any more debug information than this and all I can discern is that the spawn failed (rc=-3). Any help would be greatly appreciated. Matt _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 06 15:13:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 15:13: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 1UDG19-0001Pd-6y; Wed, 06 Mar 2013 15:12:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDG17-0001PY-Bj for xen-users@lists.xen.org; Wed, 06 Mar 2013 15:12:29 +0000 Received: from [85.158.139.83:9260] by server-12.bemta-5.messagelabs.com id 8D/59-11486-CDC57315; Wed, 06 Mar 2013 15:12:28 +0000 X-Env-Sender: aaron.cossey@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1362582747!23537310!1 X-Originating-IP: [74.125.82.44] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19128 invoked from network); 6 Mar 2013 15:12:27 -0000 Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com) (74.125.82.44) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 15:12:27 -0000 Received: by mail-wg0-f44.google.com with SMTP id dr12so7716136wgb.35 for ; Wed, 06 Mar 2013 07:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:cc:content-type; bh=WgZUG13QFtbIv7GbLQRUu0L0wU3irPixn6BYQyv+qdU=; b=elFGPTCK5S0s7UTt2P1QzMx1O+3ThmHm/8/OpAfSr9wRv3wf855oA8UB2gdJuLO6+0 ep4tC3Ofk/Ab8Wb/8ht7hBgB9sKKvZ38OUE2B0TiVej/TiVVi1hMls83VJzxYXy7HjZB XMbhoF8SEq+ziyxv7Muwpb7T8E9X65C+vyUD2Ti6Rl3tFd8z1jHtdrPOe6p8z5dU/DJ9 v436SKkd4M03QDSjAOqsorNbuHtDmKPQMa2DNWNFVe+Iy+lAvzaznBfiW9Te0D5Zk74U bPiHuxS8eQvPsjsJvuXxUCxWmeiT+cSqOALGZXDMvv4RZpdVeJuKfWLsPDMSpSSycKfI QVqA== MIME-Version: 1.0 X-Received: by 10.180.72.148 with SMTP id d20mr26698880wiv.31.1362582746795; Wed, 06 Mar 2013 07:12:26 -0800 (PST) Received: by 10.194.138.40 with HTTP; Wed, 6 Mar 2013 07:12:26 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Mar 2013 16:12:26 +0100 Message-ID: From: Aaron Cossey Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============7978791392890570328==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7978791392890570328== Content-Type: multipart/alternative; boundary=f46d043be21c99977504d7430442 --f46d043be21c99977504d7430442 Content-Type: text/plain; charset=ISO-8859-1 I've encountered this frequently due to high io load. If you have monitoring of load and io, did you see anything happen just before these errors started in the logs? Aaron Cossey aaron.cossey@gmail.com On Wed, Mar 6, 2013 at 1:35 PM, agya naila wrote: > Hi all, > > Today I got problem below and my domU become unresponsive and I should > restart the pc to make it running properly again. > > [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 seconds. > [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 > seconds. > [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 > seconds. > [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 > seconds. > [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 > seconds. > [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 > seconds. > [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 > seconds. > [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 > seconds. > [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 > seconds. > [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > > Does any body have clue regarding this problem? > > Regards, > > Agya > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --f46d043be21c99977504d7430442 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've=A0encountered=A0this frequently due to high io lo= ad. If you have monitoring of load and io, did you see anything happen just= before these errors started in the logs?
<= br clear=3D"all">

On Wed, Mar 6, 2013 at 1:35 PM, agya nai= la <agya.naila@gmail.com> wrote:
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--f46d043be21c99977504d7430442-- --===============7978791392890570328== 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 --===============7978791392890570328==-- From xen-users-bounces@lists.xen.org Wed Mar 06 15:13:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 15:13: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 1UDG19-0001Pd-6y; Wed, 06 Mar 2013 15:12:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDG17-0001PY-Bj for xen-users@lists.xen.org; Wed, 06 Mar 2013 15:12:29 +0000 Received: from [85.158.139.83:9260] by server-12.bemta-5.messagelabs.com id 8D/59-11486-CDC57315; Wed, 06 Mar 2013 15:12:28 +0000 X-Env-Sender: aaron.cossey@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1362582747!23537310!1 X-Originating-IP: [74.125.82.44] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19128 invoked from network); 6 Mar 2013 15:12:27 -0000 Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com) (74.125.82.44) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 15:12:27 -0000 Received: by mail-wg0-f44.google.com with SMTP id dr12so7716136wgb.35 for ; Wed, 06 Mar 2013 07:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:cc:content-type; bh=WgZUG13QFtbIv7GbLQRUu0L0wU3irPixn6BYQyv+qdU=; b=elFGPTCK5S0s7UTt2P1QzMx1O+3ThmHm/8/OpAfSr9wRv3wf855oA8UB2gdJuLO6+0 ep4tC3Ofk/Ab8Wb/8ht7hBgB9sKKvZ38OUE2B0TiVej/TiVVi1hMls83VJzxYXy7HjZB XMbhoF8SEq+ziyxv7Muwpb7T8E9X65C+vyUD2Ti6Rl3tFd8z1jHtdrPOe6p8z5dU/DJ9 v436SKkd4M03QDSjAOqsorNbuHtDmKPQMa2DNWNFVe+Iy+lAvzaznBfiW9Te0D5Zk74U bPiHuxS8eQvPsjsJvuXxUCxWmeiT+cSqOALGZXDMvv4RZpdVeJuKfWLsPDMSpSSycKfI QVqA== MIME-Version: 1.0 X-Received: by 10.180.72.148 with SMTP id d20mr26698880wiv.31.1362582746795; Wed, 06 Mar 2013 07:12:26 -0800 (PST) Received: by 10.194.138.40 with HTTP; Wed, 6 Mar 2013 07:12:26 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Mar 2013 16:12:26 +0100 Message-ID: From: Aaron Cossey Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============7978791392890570328==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7978791392890570328== Content-Type: multipart/alternative; boundary=f46d043be21c99977504d7430442 --f46d043be21c99977504d7430442 Content-Type: text/plain; charset=ISO-8859-1 I've encountered this frequently due to high io load. If you have monitoring of load and io, did you see anything happen just before these errors started in the logs? Aaron Cossey aaron.cossey@gmail.com On Wed, Mar 6, 2013 at 1:35 PM, agya naila wrote: > Hi all, > > Today I got problem below and my domU become unresponsive and I should > restart the pc to make it running properly again. > > [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 seconds. > [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 > seconds. > [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 > seconds. > [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 > seconds. > [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 > seconds. > [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 > seconds. > [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 > seconds. > [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 > seconds. > [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 > seconds. > [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > > Does any body have clue regarding this problem? > > Regards, > > Agya > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --f46d043be21c99977504d7430442 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've=A0encountered=A0this frequently due to high io lo= ad. If you have monitoring of load and io, did you see anything happen just= before these errors started in the logs?
<= br clear=3D"all">

On Wed, Mar 6, 2013 at 1:35 PM, agya nai= la <agya.naila@gmail.com> wrote:
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--f46d043be21c99977504d7430442-- --===============7978791392890570328== 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 --===============7978791392890570328==-- From xen-users-bounces@lists.xen.org Wed Mar 06 15:44:06 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 15:44: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 1UDGUr-0002PP-QL; Wed, 06 Mar 2013 15:43:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDGUq-0002PH-9o for xen-users@lists.xen.org; Wed, 06 Mar 2013 15:43:12 +0000 Received: from [85.158.139.83:30339] by server-10.bemta-5.messagelabs.com id 74/B9-23714-F0467315; Wed, 06 Mar 2013 15:43:11 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1362584590!20259434!1 X-Originating-IP: [74.125.82.176] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17872 invoked from network); 6 Mar 2013 15:43:10 -0000 Received: from mail-we0-f176.google.com (HELO mail-we0-f176.google.com) (74.125.82.176) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 15:43:10 -0000 Received: by mail-we0-f176.google.com with SMTP id s43so8000235wey.21 for ; Wed, 06 Mar 2013 07:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=OIlwlQq/iWZ9DRSsKGIH6p/LakJ5jBx9MEWzXGedkD0=; b=pyGrMBYrh3JEvsGj0YqmZOWxK8bKZoRI4tAq9ONF41GTLavadg28A4lO8fRJqtNQTm OL5oSSAQhZmRHlBlJP9zxwwwOuBjsvikk4BJksPJHv8eqXFAmAt4fAlh8WqPAwLq9nRS 79c7ep5kg+w+BTcxY0Wl63q947c0nnj+4xDLN6Tv4jhrpFCYlKzflN7e6SM0oFx9RZ/o fvTJp0lsEW4IWklAcf7gVPQlP8vdqKgr1Wzh3ETCMPD36fneF7xKlp7AeQ6yAphvicYw OfZ+qJLGhtUt+OyZX3RKFz+1nKI2a8q7rIjPu2CtWbqCnLao/dlAQXd98F8MN06oJhTE EEIQ== X-Received: by 10.194.60.195 with SMTP id j3mr47750569wjr.33.1362584586304; Wed, 06 Mar 2013 07:43:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Wed, 6 Mar 2013 07:42:46 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Wed, 6 Mar 2013 10:42:46 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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, Mar 6, 2013 at 12:41 AM, jacek burghardt wrote: > I get this error and I had installed nss for while. > libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed > libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot (re-)build > domain: -3 > libxl: error: libxl_dm.c:1262:libxl__destroy_device_model: could not find > device-model's pid for dom 11 > libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_model > failed for 11 That was the same error I got on 26666, and installing nss on the dom0 host fixed it. Unfortunately, I don't know anything about spice, so I can't be of much help with that. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 06 15:44:06 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 15:44: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 1UDGUr-0002PP-QL; Wed, 06 Mar 2013 15:43:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDGUq-0002PH-9o for xen-users@lists.xen.org; Wed, 06 Mar 2013 15:43:12 +0000 Received: from [85.158.139.83:30339] by server-10.bemta-5.messagelabs.com id 74/B9-23714-F0467315; Wed, 06 Mar 2013 15:43:11 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1362584590!20259434!1 X-Originating-IP: [74.125.82.176] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17872 invoked from network); 6 Mar 2013 15:43:10 -0000 Received: from mail-we0-f176.google.com (HELO mail-we0-f176.google.com) (74.125.82.176) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 15:43:10 -0000 Received: by mail-we0-f176.google.com with SMTP id s43so8000235wey.21 for ; Wed, 06 Mar 2013 07:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=OIlwlQq/iWZ9DRSsKGIH6p/LakJ5jBx9MEWzXGedkD0=; b=pyGrMBYrh3JEvsGj0YqmZOWxK8bKZoRI4tAq9ONF41GTLavadg28A4lO8fRJqtNQTm OL5oSSAQhZmRHlBlJP9zxwwwOuBjsvikk4BJksPJHv8eqXFAmAt4fAlh8WqPAwLq9nRS 79c7ep5kg+w+BTcxY0Wl63q947c0nnj+4xDLN6Tv4jhrpFCYlKzflN7e6SM0oFx9RZ/o fvTJp0lsEW4IWklAcf7gVPQlP8vdqKgr1Wzh3ETCMPD36fneF7xKlp7AeQ6yAphvicYw OfZ+qJLGhtUt+OyZX3RKFz+1nKI2a8q7rIjPu2CtWbqCnLao/dlAQXd98F8MN06oJhTE EEIQ== X-Received: by 10.194.60.195 with SMTP id j3mr47750569wjr.33.1362584586304; Wed, 06 Mar 2013 07:43:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.120.193 with HTTP; Wed, 6 Mar 2013 07:42:46 -0800 (PST) In-Reply-To: References: From: Sean Greenslade Date: Wed, 6 Mar 2013 10:42:46 -0500 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] xen on arch linux X-BeenThere: xen-users@lists.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, Mar 6, 2013 at 12:41 AM, jacek burghardt wrote: > I get this error and I had installed nss for while. > libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed > libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot (re-)build > domain: -3 > libxl: error: libxl_dm.c:1262:libxl__destroy_device_model: could not find > device-model's pid for dom 11 > libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_model > failed for 11 That was the same error I got on 26666, and installing nss on the dom0 host fixed it. Unfortunately, I don't know anything about spice, so I can't be of much help with that. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 06 16:31:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 16:31:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDHDz-00047l-Tl; Wed, 06 Mar 2013 16:29:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDHDy-00047g-KG for xen-users@lists.xen.org; Wed, 06 Mar 2013 16:29:51 +0000 Received: from [85.158.143.99:13978] by server-2.bemta-4.messagelabs.com id 0C/C3-12656-DFE67315; Wed, 06 Mar 2013 16:29:49 +0000 X-Env-Sender: eisgert@yahoo.de X-Msg-Ref: server-6.tower-216.messagelabs.com!1362587389!21601115!1 X-Originating-IP: [77.238.189.203] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28101 invoked from network); 6 Mar 2013 16:29:49 -0000 Received: from nm8-vm0.bullet.mail.ird.yahoo.com (HELO nm8-vm0.bullet.mail.ird.yahoo.com) (77.238.189.203) by server-6.tower-216.messagelabs.com with SMTP; 6 Mar 2013 16:29:49 -0000 Received: from [77.238.189.50] by nm8.bullet.mail.ird.yahoo.com with NNFMP; 06 Mar 2013 16:28:34 -0000 Received: from [212.82.108.112] by tm3.bullet.mail.ird.yahoo.com with NNFMP; 06 Mar 2013 16:28:34 -0000 Received: from [127.0.0.1] by omp1021.mail.ird.yahoo.com with NNFMP; 06 Mar 2013 16:28:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 154172.18615.bm@omp1021.mail.ird.yahoo.com Received: (qmail 50932 invoked by uid 60001); 6 Mar 2013 16:28:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1362587314; bh=kKwKWIOituNQZ+UNN7yGzdKZMjf0Ku5m9eF6a5pK2m4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Eq6XxH8EIb9KhfzlRq2SDXr+bQdatPqukx/Ynn+0JVDs6wFfI9M0h7QGCZtJHVZNaNQEg91GWrCJG4VlooRFNrHha/KayeWpOYzdDiz4XjevJmPnYsa0aT7unYSDOB7h47ib3y37jwTvHOfhqq06viAhBpcXkuHpVeCNhAGmTFg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=m5UHP6A225UlMtypWHhOBLpctq1z9wr+06e4m3KuzwKgbkDid8NX+kYk7pyt9fcle0z5aTAjmGyGgOkaz4ZecoEJ+TA3oiwtJDxDfudTvQ776hDyqbwsZjFTNkvhUJasYEW9tI0GwmnrTTN9upwjVpeDjPI1Rp1/o5b++DwoJws=; X-YMail-OSG: b4LllNUVM1m3mOCFe_yzlwCjM7wPdYITmtbOIx8sKku273F q8AluxpGbwknia6KCcm9itGjnHyRn9UW8I__6bjUL8mtZWbPT7SqWtC8ZH9m tUx.IuGBUjNO3_60EvXf2oolnQ_QuVw8HfxZJOoXnEtnV6vVv36JdX7RSPQk .4fhJ7LsbCmULFTume7TdPyxVMBamJnEoi7C8DoHTvq_XCn2gJ3gacT2KK39 Tzi70dPVEUjNCfUfXNCOone9QaVzczpkoXxIi4KQ1d8s01lJm1vNe0.EWTkZ zVq8N.M66zJfDAd4v81YvMBW3jmFX_3Np4i7Z7RNNHnc82Onf3.EccJAvIBf MMjEQUOl1dGPXRKwZiXX9zjBEfwlLyqHlzAMuDOMKOgqS2I5XCWMsE3Cj6OC B_u1v61C.3ckDYLPCV7NeUvo- Received: from [178.2.183.185] by web132105.mail.ird.yahoo.com via HTTP; Wed, 06 Mar 2013 16:28:33 GMT X-Rocket-MIMEInfo: 001.001, SGVsbG8sDQoNCmhvdyBjYW4gSSBwYXNzdGhyb3VnaCBteSBMYXB0b3AgS2V5Ym9hcmQgdG8gYSBXaW5kb3dzIEd1ZXN0PyBJdCBpcyBub3Qgd29ya2luZyBieSBkZWZhdWx0LiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIG15IGtleWJvYXJkOiAvZGV2L2lucHV0L2J5LXBhdGgvcGxhdGZvcm0taTgwNDItc2VyaW8tMC1ldmVudC1rYmQuIENhbiB5b3UgZ2l2ZSBtZSBzb21lIHBvaW50ZXJzIGhvdyB0byBwYXNzIHRoaXMgdGhyb3VnaD8NCg0KQXMgSSBzZWFyY2hlZCBoaWdoIGFuZCBsb3cgc2luY2UgU3VuZGF5LCABMAEBAQE- X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514 Message-ID: <1362587313.49675.YahooMailClassic@web132105.mail.ird.yahoo.com> Date: Wed, 6 Mar 2013 16:28:33 +0000 (GMT) From: Gert Eis To: xen-users@lists.xen.org MIME-Version: 1.0 Subject: [Xen-users] How can I use my Laptop Keyboard in domU? X-BeenThere: xen-users@lists.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="===============3557489658483974606==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3557489658483974606== Content-Type: multipart/alternative; boundary="-1133388179-689445807-1362587313=:49675" ---1133388179-689445807-1362587313=:49675 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, how can I passthrough my Laptop Keyboard to a Windows Guest? It is not work= ing by default. I think this should be my keyboard: /dev/input/by-path/plat= form-i8042-serio-0-event-kbd. Can you give me some pointers how to pass thi= s through? As I searched high and low since Sunday, it would really help me a lot. Tha= nk you. Best regards,=20 Gert Eis ---1133388179-689445807-1362587313=:49675 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello,

how can I passthrough my Laptop= Keyboard to a Windows Guest? It is not working by default. I think this sh= ould be my keyboard: /dev/input/by-path/platform-i8042-serio-0-event-kbd. C= an you give me some pointers how to pass this through?

As I searched= high and low since Sunday, it would really help me a lot. Thank you.
Best regards,
Gert Eis
---1133388179-689445807-1362587313=:49675-- --===============3557489658483974606== 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 --===============3557489658483974606==-- From xen-users-bounces@lists.xen.org Wed Mar 06 16:31:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 16:31:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDHDz-00047l-Tl; Wed, 06 Mar 2013 16:29:51 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDHDy-00047g-KG for xen-users@lists.xen.org; Wed, 06 Mar 2013 16:29:51 +0000 Received: from [85.158.143.99:13978] by server-2.bemta-4.messagelabs.com id 0C/C3-12656-DFE67315; Wed, 06 Mar 2013 16:29:49 +0000 X-Env-Sender: eisgert@yahoo.de X-Msg-Ref: server-6.tower-216.messagelabs.com!1362587389!21601115!1 X-Originating-IP: [77.238.189.203] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28101 invoked from network); 6 Mar 2013 16:29:49 -0000 Received: from nm8-vm0.bullet.mail.ird.yahoo.com (HELO nm8-vm0.bullet.mail.ird.yahoo.com) (77.238.189.203) by server-6.tower-216.messagelabs.com with SMTP; 6 Mar 2013 16:29:49 -0000 Received: from [77.238.189.50] by nm8.bullet.mail.ird.yahoo.com with NNFMP; 06 Mar 2013 16:28:34 -0000 Received: from [212.82.108.112] by tm3.bullet.mail.ird.yahoo.com with NNFMP; 06 Mar 2013 16:28:34 -0000 Received: from [127.0.0.1] by omp1021.mail.ird.yahoo.com with NNFMP; 06 Mar 2013 16:28:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 154172.18615.bm@omp1021.mail.ird.yahoo.com Received: (qmail 50932 invoked by uid 60001); 6 Mar 2013 16:28:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1362587314; bh=kKwKWIOituNQZ+UNN7yGzdKZMjf0Ku5m9eF6a5pK2m4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Eq6XxH8EIb9KhfzlRq2SDXr+bQdatPqukx/Ynn+0JVDs6wFfI9M0h7QGCZtJHVZNaNQEg91GWrCJG4VlooRFNrHha/KayeWpOYzdDiz4XjevJmPnYsa0aT7unYSDOB7h47ib3y37jwTvHOfhqq06viAhBpcXkuHpVeCNhAGmTFg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=m5UHP6A225UlMtypWHhOBLpctq1z9wr+06e4m3KuzwKgbkDid8NX+kYk7pyt9fcle0z5aTAjmGyGgOkaz4ZecoEJ+TA3oiwtJDxDfudTvQ776hDyqbwsZjFTNkvhUJasYEW9tI0GwmnrTTN9upwjVpeDjPI1Rp1/o5b++DwoJws=; X-YMail-OSG: b4LllNUVM1m3mOCFe_yzlwCjM7wPdYITmtbOIx8sKku273F q8AluxpGbwknia6KCcm9itGjnHyRn9UW8I__6bjUL8mtZWbPT7SqWtC8ZH9m tUx.IuGBUjNO3_60EvXf2oolnQ_QuVw8HfxZJOoXnEtnV6vVv36JdX7RSPQk .4fhJ7LsbCmULFTume7TdPyxVMBamJnEoi7C8DoHTvq_XCn2gJ3gacT2KK39 Tzi70dPVEUjNCfUfXNCOone9QaVzczpkoXxIi4KQ1d8s01lJm1vNe0.EWTkZ zVq8N.M66zJfDAd4v81YvMBW3jmFX_3Np4i7Z7RNNHnc82Onf3.EccJAvIBf MMjEQUOl1dGPXRKwZiXX9zjBEfwlLyqHlzAMuDOMKOgqS2I5XCWMsE3Cj6OC B_u1v61C.3ckDYLPCV7NeUvo- Received: from [178.2.183.185] by web132105.mail.ird.yahoo.com via HTTP; Wed, 06 Mar 2013 16:28:33 GMT X-Rocket-MIMEInfo: 001.001, SGVsbG8sDQoNCmhvdyBjYW4gSSBwYXNzdGhyb3VnaCBteSBMYXB0b3AgS2V5Ym9hcmQgdG8gYSBXaW5kb3dzIEd1ZXN0PyBJdCBpcyBub3Qgd29ya2luZyBieSBkZWZhdWx0LiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIG15IGtleWJvYXJkOiAvZGV2L2lucHV0L2J5LXBhdGgvcGxhdGZvcm0taTgwNDItc2VyaW8tMC1ldmVudC1rYmQuIENhbiB5b3UgZ2l2ZSBtZSBzb21lIHBvaW50ZXJzIGhvdyB0byBwYXNzIHRoaXMgdGhyb3VnaD8NCg0KQXMgSSBzZWFyY2hlZCBoaWdoIGFuZCBsb3cgc2luY2UgU3VuZGF5LCABMAEBAQE- X-Mailer: YahooMailClassic/15.1.4 YahooMailWebService/0.8.135.514 Message-ID: <1362587313.49675.YahooMailClassic@web132105.mail.ird.yahoo.com> Date: Wed, 6 Mar 2013 16:28:33 +0000 (GMT) From: Gert Eis To: xen-users@lists.xen.org MIME-Version: 1.0 Subject: [Xen-users] How can I use my Laptop Keyboard in domU? X-BeenThere: xen-users@lists.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="===============3557489658483974606==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3557489658483974606== Content-Type: multipart/alternative; boundary="-1133388179-689445807-1362587313=:49675" ---1133388179-689445807-1362587313=:49675 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, how can I passthrough my Laptop Keyboard to a Windows Guest? It is not work= ing by default. I think this should be my keyboard: /dev/input/by-path/plat= form-i8042-serio-0-event-kbd. Can you give me some pointers how to pass thi= s through? As I searched high and low since Sunday, it would really help me a lot. Tha= nk you. Best regards,=20 Gert Eis ---1133388179-689445807-1362587313=:49675 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello,

how can I passthrough my Laptop= Keyboard to a Windows Guest? It is not working by default. I think this sh= ould be my keyboard: /dev/input/by-path/platform-i8042-serio-0-event-kbd. C= an you give me some pointers how to pass this through?

As I searched= high and low since Sunday, it would really help me a lot. Thank you.
Best regards,
Gert Eis
---1133388179-689445807-1362587313=:49675-- --===============3557489658483974606== 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 --===============3557489658483974606==-- From xen-users-bounces@lists.xen.org Wed Mar 06 16:35:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 16:35: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 1UDHIW-0004K0-Sg; Wed, 06 Mar 2013 16:34:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDHIU-0004Jo-Kh for xen-users@lists.xen.org; Wed, 06 Mar 2013 16:34:30 +0000 Received: from [85.158.138.51:2847] by server-11.bemta-3.messagelabs.com id 69/17-01263-51077315; Wed, 06 Mar 2013 16:34:29 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1362587667!22886298!1 X-Originating-IP: [209.85.214.178] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11582 invoked from network); 6 Mar 2013 16:34:28 -0000 Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com) (209.85.214.178) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 16:34:28 -0000 Received: by mail-ob0-f178.google.com with SMTP id wd20so3606072obb.23 for ; Wed, 06 Mar 2013 08:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dkCVEDtnbCA5VkdQGZL1/FFFsKYFF6Y2FuI6My5Jqmo=; b=WtsJv1IgQMYK8zIBdks56XNiLHH2mi543PQWQYhPwLnVmZKewR9V49ISdNM2Eeb3g5 mHuV1o04R5T/QTWSTbRfBZwP5P/4foHZ3pukia80TD6KFCRPnBv+69FIw0IGv/4fHW9K tyIB6p1liTGn3MMDcAB9Lh6/pFJGrkjGBntq3EOp55hPDlGjRFi0TBH7Q49OoR6+4KjT FU85WLN6xTQkfOZnZmNI0ir5VoIQNgh0ORczqEnsduAG5ecX3WAUPb2JI9zcOJh/GN00 NvhDAfaI051Pz4YrTtF1exJoOheIRLCJbMbSvgDABYC5VRzVAd1xeBGVZZfs+RPICUru FlBQ== MIME-Version: 1.0 X-Received: by 10.182.114.97 with SMTP id jf1mr23258316obb.31.1362587667074; Wed, 06 Mar 2013 08:34:27 -0800 (PST) Received: by 10.60.57.102 with HTTP; Wed, 6 Mar 2013 08:34:26 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 11:34:26 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8160192451075067289==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8160192451075067289== Content-Type: multipart/alternative; boundary=f46d0444edf1df15ff04d744290a --f46d0444edf1df15ff04d744290a Content-Type: text/plain; charset=ISO-8859-1 Guilherme, It was a while back when I installed Catalyst 12.03, and I had lots of problems with other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgetting some of the details. But yes, if I remember correctly, Windows 7 Ultimate 64-bit booted up just fine after installing Catalyst 12.03 on a clean system. GizmoChicken On Wed, Mar 6, 2013 at 8:28 AM, Guilherme Suzuki wrote: > Gizmo, hi! > > Have you been able to reboot your VM and get everything working fine? > > On Mar 6, 2013 10:15 AM, "Gizmo Chicken" wrote: > > I haven't read every message in this string, so forgive me if I'm missing > something. But just a comment with regard to what was previously stated by > another: > > > > "I recommend not using the latest 13-1 because it creates a similar > behavior you mentioned on my m... > Although I've read that others have had success with Catalyst 12.10, in my > case, that driver was not stable for GPU passthrough with an AMD Radeon HD > 6670 and a Windows 7 guest. > > However, *Catalyst 12.3* on a clean install of Windows 7 (on which no > other version of Catalyst has ever been installed) works well for me. > (I've read that removal process for Catalyst isn't complete, so a clean > install is better.) > > Hope the above helps. > > GizmoChicken > > > > On Wed, Mar 6, 2013 at 6:22 AM, Guilherme Suzuki > wrote: > >> > >> > I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel >> modules) and brought Xen f... >> >> > _______________________________________________ >> > Xen-users mailing list >> > Xen-users@lists.xen.org... >> > > --f46d0444edf1df15ff04d744290a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Guilherme,

It was a while back when I installed Catalyst 12.03, and = I had lots of problems with=20 other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgett= ing some of the details.=A0 But yes, if I remember correctly, Windows 7 Ult= imate 64-bit booted up just fine after installing Catalyst 12.03 on a clean= system.

GizmoChicken



On Wed, Mar 6, 2= 013 at 8:28 AM, Guilherme Suzuki <suzuki.gui@gmail.com> w= rote:

Gizmo, hi!

Have you been able to reboot your VM and get everything working fine?

On Mar 6, 2013 10:15 AM,= "Gizmo Chicken" <gizmochicken@gmail.com> wrote:

I haven't = read every message in this string, so forgive me if I'm missing somethi= ng.=A0 But just a comment with regard to what was previously stated by anot= her:



"I recommend not using the latest 13-1= because it creates a similar behavior you mentioned on my m...

<= div class=3D"im">Although I've read that others have had success with C= atalyst 12.10, in my case, that driver was not stable for GPU passthrough w= ith an AMD Radeon HD 6670 and a Windows 7 guest.

However, Catalyst 12.3 on a clean install of Windows 7 (o= n which no other version of Catalyst has ever been installed) works well fo= r me.=A0 (I've read that removal process for Catalyst isn't complet= e, so a clean install is better.)

Hope the above helps.

GizmoChicken



On Wed, Mar= 6, 2013 at 6:22 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:

>
>= ; I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel mod= ules) and brought Xen f...

> ___________________________________________= ____
> Xen-users mailing list
> Xen-users@lists.xen.org...



--f46d0444edf1df15ff04d744290a-- --===============8160192451075067289== 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 --===============8160192451075067289==-- From xen-users-bounces@lists.xen.org Wed Mar 06 16:35:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 16:35: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 1UDHIW-0004K0-Sg; Wed, 06 Mar 2013 16:34:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDHIU-0004Jo-Kh for xen-users@lists.xen.org; Wed, 06 Mar 2013 16:34:30 +0000 Received: from [85.158.138.51:2847] by server-11.bemta-3.messagelabs.com id 69/17-01263-51077315; Wed, 06 Mar 2013 16:34:29 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1362587667!22886298!1 X-Originating-IP: [209.85.214.178] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11582 invoked from network); 6 Mar 2013 16:34:28 -0000 Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com) (209.85.214.178) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 16:34:28 -0000 Received: by mail-ob0-f178.google.com with SMTP id wd20so3606072obb.23 for ; Wed, 06 Mar 2013 08:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dkCVEDtnbCA5VkdQGZL1/FFFsKYFF6Y2FuI6My5Jqmo=; b=WtsJv1IgQMYK8zIBdks56XNiLHH2mi543PQWQYhPwLnVmZKewR9V49ISdNM2Eeb3g5 mHuV1o04R5T/QTWSTbRfBZwP5P/4foHZ3pukia80TD6KFCRPnBv+69FIw0IGv/4fHW9K tyIB6p1liTGn3MMDcAB9Lh6/pFJGrkjGBntq3EOp55hPDlGjRFi0TBH7Q49OoR6+4KjT FU85WLN6xTQkfOZnZmNI0ir5VoIQNgh0ORczqEnsduAG5ecX3WAUPb2JI9zcOJh/GN00 NvhDAfaI051Pz4YrTtF1exJoOheIRLCJbMbSvgDABYC5VRzVAd1xeBGVZZfs+RPICUru FlBQ== MIME-Version: 1.0 X-Received: by 10.182.114.97 with SMTP id jf1mr23258316obb.31.1362587667074; Wed, 06 Mar 2013 08:34:27 -0800 (PST) Received: by 10.60.57.102 with HTTP; Wed, 6 Mar 2013 08:34:26 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 11:34:26 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8160192451075067289==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8160192451075067289== Content-Type: multipart/alternative; boundary=f46d0444edf1df15ff04d744290a --f46d0444edf1df15ff04d744290a Content-Type: text/plain; charset=ISO-8859-1 Guilherme, It was a while back when I installed Catalyst 12.03, and I had lots of problems with other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgetting some of the details. But yes, if I remember correctly, Windows 7 Ultimate 64-bit booted up just fine after installing Catalyst 12.03 on a clean system. GizmoChicken On Wed, Mar 6, 2013 at 8:28 AM, Guilherme Suzuki wrote: > Gizmo, hi! > > Have you been able to reboot your VM and get everything working fine? > > On Mar 6, 2013 10:15 AM, "Gizmo Chicken" wrote: > > I haven't read every message in this string, so forgive me if I'm missing > something. But just a comment with regard to what was previously stated by > another: > > > > "I recommend not using the latest 13-1 because it creates a similar > behavior you mentioned on my m... > Although I've read that others have had success with Catalyst 12.10, in my > case, that driver was not stable for GPU passthrough with an AMD Radeon HD > 6670 and a Windows 7 guest. > > However, *Catalyst 12.3* on a clean install of Windows 7 (on which no > other version of Catalyst has ever been installed) works well for me. > (I've read that removal process for Catalyst isn't complete, so a clean > install is better.) > > Hope the above helps. > > GizmoChicken > > > > On Wed, Mar 6, 2013 at 6:22 AM, Guilherme Suzuki > wrote: > >> > >> > I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel >> modules) and brought Xen f... >> >> > _______________________________________________ >> > Xen-users mailing list >> > Xen-users@lists.xen.org... >> > > --f46d0444edf1df15ff04d744290a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Guilherme,

It was a while back when I installed Catalyst 12.03, and = I had lots of problems with=20 other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgett= ing some of the details.=A0 But yes, if I remember correctly, Windows 7 Ult= imate 64-bit booted up just fine after installing Catalyst 12.03 on a clean= system.

GizmoChicken



On Wed, Mar 6, 2= 013 at 8:28 AM, Guilherme Suzuki <suzuki.gui@gmail.com> w= rote:

Gizmo, hi!

Have you been able to reboot your VM and get everything working fine?

On Mar 6, 2013 10:15 AM,= "Gizmo Chicken" <gizmochicken@gmail.com> wrote:

I haven't = read every message in this string, so forgive me if I'm missing somethi= ng.=A0 But just a comment with regard to what was previously stated by anot= her:



"I recommend not using the latest 13-1= because it creates a similar behavior you mentioned on my m...

<= div class=3D"im">Although I've read that others have had success with C= atalyst 12.10, in my case, that driver was not stable for GPU passthrough w= ith an AMD Radeon HD 6670 and a Windows 7 guest.

However, Catalyst 12.3 on a clean install of Windows 7 (o= n which no other version of Catalyst has ever been installed) works well fo= r me.=A0 (I've read that removal process for Catalyst isn't complet= e, so a clean install is better.)

Hope the above helps.

GizmoChicken



On Wed, Mar= 6, 2013 at 6:22 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:

>
>= ; I reinstall Fedora 18, kernel 3.6-10 with embedded xen (not as kernel mod= ules) and brought Xen f...

> ___________________________________________= ____
> Xen-users mailing list
> Xen-users@lists.xen.org...



--f46d0444edf1df15ff04d744290a-- --===============8160192451075067289== 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 --===============8160192451075067289==-- From xen-users-bounces@lists.xen.org Wed Mar 06 16:47:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 16:47: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 1UDHU9-0004p1-II; Wed, 06 Mar 2013 16:46:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDHU8-0004ot-Cw for xen-users@lists.xen.org; Wed, 06 Mar 2013 16:46:32 +0000 Received: from [85.158.139.83:46829] by server-16.bemta-5.messagelabs.com id 6B/BD-02543-7E277315; Wed, 06 Mar 2013 16:46:31 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1362588371!27424256!1 X-Originating-IP: [209.85.223.171] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3921 invoked from network); 6 Mar 2013 16:46:13 -0000 Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com) (209.85.223.171) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 16:46:13 -0000 Received: by mail-ie0-f171.google.com with SMTP id 10so9775299ied.30 for ; Wed, 06 Mar 2013 08:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TohFqg71YcnzY4HIRed+f3pFJMBUdIV5prWqEZXj/zY=; b=Z0Ih5FX2GagavokBd8JByxdj0iNlroBl2z+xzj2m7SOmEx4jE++cXPKgGzoj3m7r8y Cv5gOxnSttOtCmjaJbfVJKCj/EOI00fkgS48kdQnb1pvN0dkStVAS+N38CpVmLNeSBHg m9sg6FOxNmF6I8KwEux7HIAl6zfu4WG+vWQwajjOa/rcVf6c4IlVHFLZGwaxNNcNnn4r iUKd1IqkAHGYlUEJA1GKZBP/jnosCyJUl1E4TL35mofcQTwMA5tRbSfM9oXFrhQJWlIa A5LYlerCQJN3MUCGdfQkBPWbv/c1S+YNS9IBSJ9EhS7IhW4xmXVxueZbBequNN4954RE Hw/g== MIME-Version: 1.0 X-Received: by 10.50.46.202 with SMTP id x10mr11624846igm.87.1362588370925; Wed, 06 Mar 2013 08:46:10 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 08:46:10 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 08:46:10 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 13:46:10 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8446081831177108382==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8446081831177108382== Content-Type: multipart/alternative; boundary=14dae9340debd34f9604d74453ed --14dae9340debd34f9604d74453ed Content-Type: text/plain; charset=ISO-8859-1 Hmm I see... cause my major problem right now is rebooting domU with secondary VGA adapter passedthrough. Windows 7 ultimate 64bits N says to me: the device cannot start (code 43). It will only come back alive again if I reboot dom0 as well. Which version of windows are you using? On Mar 6, 2013 1:34 PM, "Gizmo Chicken" wrote: Guilherme, It was a while back when I installed Catalyst 12.03, and I had lots of problems with other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgetting some of the details. But yes, if I remember correctly, Windows 7 Ultimate 64-bit booted up just fine after installing Catalyst 12.03 on a clean system. GizmoChicken On Wed, Mar 6, 2013 at 8:28 AM, Guilherme Suzuki wrote: > > Gizmo, hi! > ... --14dae9340debd34f9604d74453ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hmm I see... cause my major problem right now is rebooting domU with sec= ondary VGA adapter passedthrough.

Windows 7 ultimate 64bits N says to me: the device cannot start (code 43= ). It will only come back alive again if I reboot dom0 as well.

Which version of windows are you using?

On Mar 6, 2013 1:34 PM, "Gizmo Chicken&qu= ot; <gizmochicken@gmail.com> wrote:

Guilherme,

It was a while back when I installed = Catalyst 12.03, and I had lots of problems with=20 other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgett= ing some of the details.=A0 But yes, if I remember correctly, Windows 7 Ult= imate 64-bit booted up just fine after installing Catalyst 12.03 on a clean= system.

GizmoChicken





On Wed, Mar 6, 2= 013 at 8:28 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
> Gizmo, hi!
> ...

--14dae9340debd34f9604d74453ed-- --===============8446081831177108382== 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 --===============8446081831177108382==-- From xen-users-bounces@lists.xen.org Wed Mar 06 16:47:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 16:47: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 1UDHU9-0004p1-II; Wed, 06 Mar 2013 16:46:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDHU8-0004ot-Cw for xen-users@lists.xen.org; Wed, 06 Mar 2013 16:46:32 +0000 Received: from [85.158.139.83:46829] by server-16.bemta-5.messagelabs.com id 6B/BD-02543-7E277315; Wed, 06 Mar 2013 16:46:31 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1362588371!27424256!1 X-Originating-IP: [209.85.223.171] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3921 invoked from network); 6 Mar 2013 16:46:13 -0000 Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com) (209.85.223.171) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 16:46:13 -0000 Received: by mail-ie0-f171.google.com with SMTP id 10so9775299ied.30 for ; Wed, 06 Mar 2013 08:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TohFqg71YcnzY4HIRed+f3pFJMBUdIV5prWqEZXj/zY=; b=Z0Ih5FX2GagavokBd8JByxdj0iNlroBl2z+xzj2m7SOmEx4jE++cXPKgGzoj3m7r8y Cv5gOxnSttOtCmjaJbfVJKCj/EOI00fkgS48kdQnb1pvN0dkStVAS+N38CpVmLNeSBHg m9sg6FOxNmF6I8KwEux7HIAl6zfu4WG+vWQwajjOa/rcVf6c4IlVHFLZGwaxNNcNnn4r iUKd1IqkAHGYlUEJA1GKZBP/jnosCyJUl1E4TL35mofcQTwMA5tRbSfM9oXFrhQJWlIa A5LYlerCQJN3MUCGdfQkBPWbv/c1S+YNS9IBSJ9EhS7IhW4xmXVxueZbBequNN4954RE Hw/g== MIME-Version: 1.0 X-Received: by 10.50.46.202 with SMTP id x10mr11624846igm.87.1362588370925; Wed, 06 Mar 2013 08:46:10 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 08:46:10 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 08:46:10 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 13:46:10 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8446081831177108382==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8446081831177108382== Content-Type: multipart/alternative; boundary=14dae9340debd34f9604d74453ed --14dae9340debd34f9604d74453ed Content-Type: text/plain; charset=ISO-8859-1 Hmm I see... cause my major problem right now is rebooting domU with secondary VGA adapter passedthrough. Windows 7 ultimate 64bits N says to me: the device cannot start (code 43). It will only come back alive again if I reboot dom0 as well. Which version of windows are you using? On Mar 6, 2013 1:34 PM, "Gizmo Chicken" wrote: Guilherme, It was a while back when I installed Catalyst 12.03, and I had lots of problems with other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgetting some of the details. But yes, if I remember correctly, Windows 7 Ultimate 64-bit booted up just fine after installing Catalyst 12.03 on a clean system. GizmoChicken On Wed, Mar 6, 2013 at 8:28 AM, Guilherme Suzuki wrote: > > Gizmo, hi! > ... --14dae9340debd34f9604d74453ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hmm I see... cause my major problem right now is rebooting domU with sec= ondary VGA adapter passedthrough.

Windows 7 ultimate 64bits N says to me: the device cannot start (code 43= ). It will only come back alive again if I reboot dom0 as well.

Which version of windows are you using?

On Mar 6, 2013 1:34 PM, "Gizmo Chicken&qu= ot; <gizmochicken@gmail.com> wrote:

Guilherme,

It was a while back when I installed = Catalyst 12.03, and I had lots of problems with=20 other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgett= ing some of the details.=A0 But yes, if I remember correctly, Windows 7 Ult= imate 64-bit booted up just fine after installing Catalyst 12.03 on a clean= system.

GizmoChicken





On Wed, Mar 6, 2= 013 at 8:28 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
> Gizmo, hi!
> ...

--14dae9340debd34f9604d74453ed-- --===============8446081831177108382== 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 --===============8446081831177108382==-- From xen-users-bounces@lists.xen.org Wed Mar 06 17:20:26 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 17:20: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 1UDI03-00076X-2R; Wed, 06 Mar 2013 17:19:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDI00-00076O-Rs for xen-users@lists.xen.org; Wed, 06 Mar 2013 17:19:29 +0000 Received: from [193.109.254.147:15240] by server-15.bemta-14.messagelabs.com id 2E/BB-14305-0AA77315; Wed, 06 Mar 2013 17:19:28 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1362590263!8881789!1 X-Originating-IP: [209.85.214.180] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23171 invoked from network); 6 Mar 2013 17:17:45 -0000 Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com) (209.85.214.180) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 17:17:45 -0000 Received: by mail-ob0-f180.google.com with SMTP id ef5so3757877obb.11 for ; Wed, 06 Mar 2013 09:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cBf+lTS1h+d4URnE7mNO1/KXGioMWnryI5vgdHzXLBg=; b=rateoo5BTI3AhY8ajp77jzHuMzJm9Pqs2RIn6PLxBh7u2SOeUFu2/a8gvmdfTDhh+x ZkKWsPwEVoez6aP49NyIJOvU3UJnGVWOZsg3FZp1k8fCm1dUw4QVc2/tbTcV37tJK9LD sChRSm9WTkHdfSMnHqP6dp1f5QpjdTTcK+t1nXBw6M9QN6EdutfZkoKNHJUkUlmeld0+ XFWnHLrFvZLYpB34+1g5lWEtiV421qBm/Zfdk2GmOUnoxm4Owrw3x9wBs5tZmAz3zAz4 Z5zG+0PvAM6w5T2K7nl5pZjxK/srrAvvfDZjW/RzhkGRcmW0JOCKSSw3FbsACTMiXlIN waCQ== MIME-Version: 1.0 X-Received: by 10.182.0.111 with SMTP id 15mr23409573obd.27.1362590262606; Wed, 06 Mar 2013 09:17:42 -0800 (PST) Received: by 10.60.57.102 with HTTP; Wed, 6 Mar 2013 09:17:42 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 12:17:42 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5390052679588165340==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5390052679588165340== Content-Type: multipart/alternative; boundary=f46d043c7f7c93c45104d744c44f --f46d043c7f7c93c45104d744c44f Content-Type: text/plain; charset=ISO-8859-1 I used Windows 7 Ultimate 64-bit. Also, here's a link to one of the tutorials that I followed in part, though I think the tutorial recommends a different driver: http://forums.linuxmint.com/viewtopic.php?f=42&t=112013 But as I said, it has been some time since created that VM. And in fact, I don't currently use it. Rather, I'm now currently experimenting with GPU passthrough using Windows 7 Ultimate 64-bit VM on an XCP 1.6 host, which offers an easier means for getting everything configured. In that VM, Catalyst 12.3 also works great. If interested in trying XCP 1.6 as a host, here's a link to its download page: http://xen.org/download/xcp/index_1.6.0.html Note that, if you want to try XCP, you'll also need to download XenCenter to manage XCP. You can learn more about how to get a free version of XenCenter here: http://citrixxperience.com/2012/02/24/download-and-install-citrix-xencenter-6-0/ GizmoChicken On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki wrote: > Hmm I see... cause my major problem right now is rebooting domU with > secondary VGA adapter passedthrough. > > Windows 7 ultimate 64bits N says to me: the device cannot start (code 43). > It will only come back alive again if I reboot dom0 as well. > > Which version of windows are you using? > > On Mar 6, 2013 1:34 PM, "Gizmo Chicken" wrote: > > Guilherme, > > It was a while back when I installed Catalyst 12.03, and I had lots of > problems with other Catalyst drivers (including Catalyst 12.10), so maybe > I'm forgetting some of the details. But yes, if I remember correctly, > Windows 7 Ultimate 64-bit booted up just fine after installing Catalyst > 12.03 on a clean system. > > GizmoChicken > > > > > > On Wed, Mar 6, 2013 at 8:28 AM, Guilherme Suzuki > wrote: > > > > Gizmo, hi! > > > ... > > --f46d043c7f7c93c45104d744c44f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I used Windows 7 Ultimate 64-bit.=A0 Also, here's a link to one of the= =20 tutorials that I followed in part, though I think the tutorial recommends a= different driver:=A0=20 http://forums.linuxmint.com/viewtopic.php?f=3D42&t=3D112013
But=20 as I said, it has been some time since created that VM.=A0 And in fact, I= =20 don't currently use it.=A0 Rather, I'm now currently experimenting = with=20 GPU passthrough using Windows 7 Ultimate 64-bit VM on an XCP 1.6 host,=20 which offers an easier means for getting everything configured.=A0 In that VM, Catalyst 12.3 also works great.=A0

If interested in trying XCP= 1.6 as a host, here's a link to its download page:=A0 http://xen.org/download/xcp/index_= 1.6.0.html=A0

Note that, if you want to try XCP, you'll also need to download XenCenter t= o manage XCP.=A0 You can learn more about how to get a free version of=20 XenCenter here:=A0=20 http://citrixxperience.com/2012/02/24/download-and-instal= l-citrix-xencenter-6-0/

GizmoChicken


On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki <suzuki.gui@gmail.com= > wrote:

Hmm I see... cause my major problem right now is rebooting domU with sec= ondary VGA adapter passedthrough.

Windows 7 ultimate 64bits N says to me: the device cannot start (code 43= ). It will only come back alive again if I reboot dom0 as well.

Which version of windows are you using?

On Mar 6, 2013 1:34 PM, "Gizmo C= hicken" <gizmochicken@gmail.com> wrote:

Guilherme,

It was a while back when I installed Catalyst 12.03, and I had lots of prob= lems with=20 other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgett= ing some of the details.=A0 But yes, if I remember correctly, Windows 7 Ult= imate 64-bit booted up just fine after installing Catalyst 12.03 on a clean= system.

GizmoChicken





On Wed, Mar 6, 2013 at 8:28 AM, Guilherme Suz= uki <suzuki.gu= i@gmail.com> wrote:
>
> Gizmo, hi!
>
...


--f46d043c7f7c93c45104d744c44f-- --===============5390052679588165340== 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 --===============5390052679588165340==-- From xen-users-bounces@lists.xen.org Wed Mar 06 17:20:26 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 17:20: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 1UDI03-00076X-2R; Wed, 06 Mar 2013 17:19:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDI00-00076O-Rs for xen-users@lists.xen.org; Wed, 06 Mar 2013 17:19:29 +0000 Received: from [193.109.254.147:15240] by server-15.bemta-14.messagelabs.com id 2E/BB-14305-0AA77315; Wed, 06 Mar 2013 17:19:28 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1362590263!8881789!1 X-Originating-IP: [209.85.214.180] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23171 invoked from network); 6 Mar 2013 17:17:45 -0000 Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com) (209.85.214.180) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 17:17:45 -0000 Received: by mail-ob0-f180.google.com with SMTP id ef5so3757877obb.11 for ; Wed, 06 Mar 2013 09:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cBf+lTS1h+d4URnE7mNO1/KXGioMWnryI5vgdHzXLBg=; b=rateoo5BTI3AhY8ajp77jzHuMzJm9Pqs2RIn6PLxBh7u2SOeUFu2/a8gvmdfTDhh+x ZkKWsPwEVoez6aP49NyIJOvU3UJnGVWOZsg3FZp1k8fCm1dUw4QVc2/tbTcV37tJK9LD sChRSm9WTkHdfSMnHqP6dp1f5QpjdTTcK+t1nXBw6M9QN6EdutfZkoKNHJUkUlmeld0+ XFWnHLrFvZLYpB34+1g5lWEtiV421qBm/Zfdk2GmOUnoxm4Owrw3x9wBs5tZmAz3zAz4 Z5zG+0PvAM6w5T2K7nl5pZjxK/srrAvvfDZjW/RzhkGRcmW0JOCKSSw3FbsACTMiXlIN waCQ== MIME-Version: 1.0 X-Received: by 10.182.0.111 with SMTP id 15mr23409573obd.27.1362590262606; Wed, 06 Mar 2013 09:17:42 -0800 (PST) Received: by 10.60.57.102 with HTTP; Wed, 6 Mar 2013 09:17:42 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 12:17:42 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5390052679588165340==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5390052679588165340== Content-Type: multipart/alternative; boundary=f46d043c7f7c93c45104d744c44f --f46d043c7f7c93c45104d744c44f Content-Type: text/plain; charset=ISO-8859-1 I used Windows 7 Ultimate 64-bit. Also, here's a link to one of the tutorials that I followed in part, though I think the tutorial recommends a different driver: http://forums.linuxmint.com/viewtopic.php?f=42&t=112013 But as I said, it has been some time since created that VM. And in fact, I don't currently use it. Rather, I'm now currently experimenting with GPU passthrough using Windows 7 Ultimate 64-bit VM on an XCP 1.6 host, which offers an easier means for getting everything configured. In that VM, Catalyst 12.3 also works great. If interested in trying XCP 1.6 as a host, here's a link to its download page: http://xen.org/download/xcp/index_1.6.0.html Note that, if you want to try XCP, you'll also need to download XenCenter to manage XCP. You can learn more about how to get a free version of XenCenter here: http://citrixxperience.com/2012/02/24/download-and-install-citrix-xencenter-6-0/ GizmoChicken On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki wrote: > Hmm I see... cause my major problem right now is rebooting domU with > secondary VGA adapter passedthrough. > > Windows 7 ultimate 64bits N says to me: the device cannot start (code 43). > It will only come back alive again if I reboot dom0 as well. > > Which version of windows are you using? > > On Mar 6, 2013 1:34 PM, "Gizmo Chicken" wrote: > > Guilherme, > > It was a while back when I installed Catalyst 12.03, and I had lots of > problems with other Catalyst drivers (including Catalyst 12.10), so maybe > I'm forgetting some of the details. But yes, if I remember correctly, > Windows 7 Ultimate 64-bit booted up just fine after installing Catalyst > 12.03 on a clean system. > > GizmoChicken > > > > > > On Wed, Mar 6, 2013 at 8:28 AM, Guilherme Suzuki > wrote: > > > > Gizmo, hi! > > > ... > > --f46d043c7f7c93c45104d744c44f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I used Windows 7 Ultimate 64-bit.=A0 Also, here's a link to one of the= =20 tutorials that I followed in part, though I think the tutorial recommends a= different driver:=A0=20 http://forums.linuxmint.com/viewtopic.php?f=3D42&t=3D112013
But=20 as I said, it has been some time since created that VM.=A0 And in fact, I= =20 don't currently use it.=A0 Rather, I'm now currently experimenting = with=20 GPU passthrough using Windows 7 Ultimate 64-bit VM on an XCP 1.6 host,=20 which offers an easier means for getting everything configured.=A0 In that VM, Catalyst 12.3 also works great.=A0

If interested in trying XCP= 1.6 as a host, here's a link to its download page:=A0 http://xen.org/download/xcp/index_= 1.6.0.html=A0

Note that, if you want to try XCP, you'll also need to download XenCenter t= o manage XCP.=A0 You can learn more about how to get a free version of=20 XenCenter here:=A0=20 http://citrixxperience.com/2012/02/24/download-and-instal= l-citrix-xencenter-6-0/

GizmoChicken


On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki <suzuki.gui@gmail.com= > wrote:

Hmm I see... cause my major problem right now is rebooting domU with sec= ondary VGA adapter passedthrough.

Windows 7 ultimate 64bits N says to me: the device cannot start (code 43= ). It will only come back alive again if I reboot dom0 as well.

Which version of windows are you using?

On Mar 6, 2013 1:34 PM, "Gizmo C= hicken" <gizmochicken@gmail.com> wrote:

Guilherme,

It was a while back when I installed Catalyst 12.03, and I had lots of prob= lems with=20 other Catalyst drivers (including Catalyst 12.10), so maybe I'm forgett= ing some of the details.=A0 But yes, if I remember correctly, Windows 7 Ult= imate 64-bit booted up just fine after installing Catalyst 12.03 on a clean= system.

GizmoChicken





On Wed, Mar 6, 2013 at 8:28 AM, Guilherme Suz= uki <suzuki.gu= i@gmail.com> wrote:
>
> Gizmo, hi!
>
...


--f46d043c7f7c93c45104d744c44f-- --===============5390052679588165340== 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 --===============5390052679588165340==-- From xen-users-bounces@lists.xen.org Wed Mar 06 19:40:26 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 19:40: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 1UDKBB-0002yI-IH; Wed, 06 Mar 2013 19:39:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDKBA-0002yA-Jv for xen-users@lists.xen.org; Wed, 06 Mar 2013 19:39:08 +0000 Received: from [85.158.143.99:51180] by server-3.bemta-4.messagelabs.com id EF/03-02186-B5B97315; Wed, 06 Mar 2013 19:39:07 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1362598745!16403613!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11266 invoked from network); 6 Mar 2013 19:39:06 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 19:39:06 -0000 Received: by mail-ie0-f175.google.com with SMTP id c12so10048076ieb.34 for ; Wed, 06 Mar 2013 11:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=l/jN2qW+XhuC/u9MmiRXvJCPFwYuAzYhfNUv6blkoK8=; b=vjEYCgqHkSCGHjB/kywElbszkpPtarYni+p1SWU7hJ1uja7KFa67AC4fWEVV64fCeI n68/Mt4OZdKZbgYEdKpliGA2O5JwdY3UBLVx4TmKdbuc6VChj9LvBKPDEh21E8B7KpJQ MZ1OQHSe6E55TBjzLQDu3XObYaHt6tSgGWSEEW6Aj2z9GuQx3QJ9toGWDIi11dn+5e0E QbYYAgMp6sbO/V9IyAbnR+I52lejtAchfi/sks3gou0qvN9wXLRAqFxOKwlT59APEQiA u7whxIxjVCa5TEhKob+T3N4wISqFDQPGxZy9RU5matI4vbZ6J/R/Qaspb0PiUgyGMGhy 8BhQ== MIME-Version: 1.0 X-Received: by 10.50.46.202 with SMTP id x10mr12260233igm.87.1362598744925; Wed, 06 Mar 2013 11:39:04 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 11:39:04 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 11:39:04 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 16:39:04 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============0898003856908982339==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0898003856908982339== Content-Type: multipart/alternative; boundary=14dae9340deb29adbc04d746be9e --14dae9340deb29adbc04d746be9e Content-Type: text/plain; charset=ISO-8859-1 Nice to know that! I'll uninstall Xen easily with yum and try XCP. I'll let you know how things turned out. On Mar 6, 2013 2:17 PM, "Gizmo Chicken" wrote: I used Windows 7 Ultimate 64-bit. Also, here's a link to one of the tutorials that I followed in part, though I think the tutorial recommends a different driver: http://forums.linuxmint.com/viewtopic.php?f=42&t=112013 But as I said, it has been some time since created that VM. And in fact, I don't currently use it. Rather, I'm now currently experimenting with GPU passthrough using Windows 7 Ultimate 64-bit VM on an XCP 1.6 host, which offers an easier means for getting everything configured. In that VM, Catalyst 12.3 also works great. If interested in trying XCP 1.6 as a host, here's a link to its download page: http://xen.org/download/xcp/index_1.6.0.html Note that, if you want to try XCP, you'll also need to download XenCenter to manage XCP. You can learn more about how to get a free version of XenCenter here: http://citrixxperience.com/2012/02/24/download-and-install-citrix-xencenter-6-0/ GizmoChicken On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki wrote: > > Hmm I see... ... --14dae9340deb29adbc04d746be9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Nice to know that! I'll uninstall Xen easily with yum and try XCP.

I'll let you know how things turned out.

On Mar 6, 2013 2:17 PM, "Gizmo Chicken&qu= ot; <gizmochicken@gmail.com> wrote:

I used Windows 7 Ultimate 64-bit.=A0 Also, here's a= link to one of the=20 tutorials that I followed in part, though I think the tutorial recommends a= different driver:=A0=20 http://forums.linuxmint.com/viewtopic.php?f=3D42&t= =3D112013

But=20 as I said, it has been some time since created that VM.=A0 And in fact, I= =20 don't currently use it.=A0 Rather, I'm now currently experimenting = with=20 GPU passthrough using Windows 7 Ultimate 64-bit VM on an XCP 1.6 host,=20 which offers an easier means for getting everything configured.=A0 In that VM, Catalyst 12.3 also works great.=A0

If interested in trying XCP= 1.6 as a host, here's a link to its download page:=A0 http://xen.org/d= ownload/xcp/index_1.6.0.html=A0

Note that, if you want to try XCP, you'll also need to download XenCenter t= o manage XCP.=A0 You can learn more about how to get a free version of=20 XenCenter here:=A0=20 http://citrixxperience.com/2012/02/24/d= ownload-and-install-citrix-xencenter-6-0/

GizmoChicken




On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
&= gt; Hmm I see... ...

--14dae9340deb29adbc04d746be9e-- --===============0898003856908982339== 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 --===============0898003856908982339==-- From xen-users-bounces@lists.xen.org Wed Mar 06 19:40:26 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 19:40: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 1UDKBB-0002yI-IH; Wed, 06 Mar 2013 19:39:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDKBA-0002yA-Jv for xen-users@lists.xen.org; Wed, 06 Mar 2013 19:39:08 +0000 Received: from [85.158.143.99:51180] by server-3.bemta-4.messagelabs.com id EF/03-02186-B5B97315; Wed, 06 Mar 2013 19:39:07 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1362598745!16403613!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11266 invoked from network); 6 Mar 2013 19:39:06 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 19:39:06 -0000 Received: by mail-ie0-f175.google.com with SMTP id c12so10048076ieb.34 for ; Wed, 06 Mar 2013 11:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=l/jN2qW+XhuC/u9MmiRXvJCPFwYuAzYhfNUv6blkoK8=; b=vjEYCgqHkSCGHjB/kywElbszkpPtarYni+p1SWU7hJ1uja7KFa67AC4fWEVV64fCeI n68/Mt4OZdKZbgYEdKpliGA2O5JwdY3UBLVx4TmKdbuc6VChj9LvBKPDEh21E8B7KpJQ MZ1OQHSe6E55TBjzLQDu3XObYaHt6tSgGWSEEW6Aj2z9GuQx3QJ9toGWDIi11dn+5e0E QbYYAgMp6sbO/V9IyAbnR+I52lejtAchfi/sks3gou0qvN9wXLRAqFxOKwlT59APEQiA u7whxIxjVCa5TEhKob+T3N4wISqFDQPGxZy9RU5matI4vbZ6J/R/Qaspb0PiUgyGMGhy 8BhQ== MIME-Version: 1.0 X-Received: by 10.50.46.202 with SMTP id x10mr12260233igm.87.1362598744925; Wed, 06 Mar 2013 11:39:04 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 11:39:04 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 11:39:04 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 16:39:04 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============0898003856908982339==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0898003856908982339== Content-Type: multipart/alternative; boundary=14dae9340deb29adbc04d746be9e --14dae9340deb29adbc04d746be9e Content-Type: text/plain; charset=ISO-8859-1 Nice to know that! I'll uninstall Xen easily with yum and try XCP. I'll let you know how things turned out. On Mar 6, 2013 2:17 PM, "Gizmo Chicken" wrote: I used Windows 7 Ultimate 64-bit. Also, here's a link to one of the tutorials that I followed in part, though I think the tutorial recommends a different driver: http://forums.linuxmint.com/viewtopic.php?f=42&t=112013 But as I said, it has been some time since created that VM. And in fact, I don't currently use it. Rather, I'm now currently experimenting with GPU passthrough using Windows 7 Ultimate 64-bit VM on an XCP 1.6 host, which offers an easier means for getting everything configured. In that VM, Catalyst 12.3 also works great. If interested in trying XCP 1.6 as a host, here's a link to its download page: http://xen.org/download/xcp/index_1.6.0.html Note that, if you want to try XCP, you'll also need to download XenCenter to manage XCP. You can learn more about how to get a free version of XenCenter here: http://citrixxperience.com/2012/02/24/download-and-install-citrix-xencenter-6-0/ GizmoChicken On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki wrote: > > Hmm I see... ... --14dae9340deb29adbc04d746be9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Nice to know that! I'll uninstall Xen easily with yum and try XCP.

I'll let you know how things turned out.

On Mar 6, 2013 2:17 PM, "Gizmo Chicken&qu= ot; <gizmochicken@gmail.com> wrote:

I used Windows 7 Ultimate 64-bit.=A0 Also, here's a= link to one of the=20 tutorials that I followed in part, though I think the tutorial recommends a= different driver:=A0=20 http://forums.linuxmint.com/viewtopic.php?f=3D42&t= =3D112013

But=20 as I said, it has been some time since created that VM.=A0 And in fact, I= =20 don't currently use it.=A0 Rather, I'm now currently experimenting = with=20 GPU passthrough using Windows 7 Ultimate 64-bit VM on an XCP 1.6 host,=20 which offers an easier means for getting everything configured.=A0 In that VM, Catalyst 12.3 also works great.=A0

If interested in trying XCP= 1.6 as a host, here's a link to its download page:=A0 http://xen.org/d= ownload/xcp/index_1.6.0.html=A0

Note that, if you want to try XCP, you'll also need to download XenCenter t= o manage XCP.=A0 You can learn more about how to get a free version of=20 XenCenter here:=A0=20 http://citrixxperience.com/2012/02/24/d= ownload-and-install-citrix-xencenter-6-0/

GizmoChicken




On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
&= gt; Hmm I see... ...

--14dae9340deb29adbc04d746be9e-- --===============0898003856908982339== 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 --===============0898003856908982339==-- From xen-users-bounces@lists.xen.org Wed Mar 06 20:08:28 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 20:08: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 1UDKcg-0003ps-34; Wed, 06 Mar 2013 20:07:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDKce-0003pn-At for xen-users@lists.xen.org; Wed, 06 Mar 2013 20:07:32 +0000 Received: from [85.158.139.83:25769] by server-14.bemta-5.messagelabs.com id 20/53-13158-302A7315; Wed, 06 Mar 2013 20:07:31 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1362600449!20296066!1 X-Originating-IP: [209.85.223.174] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28750 invoked from network); 6 Mar 2013 20:07:30 -0000 Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com) (209.85.223.174) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 20:07:30 -0000 Received: by mail-ie0-f174.google.com with SMTP id k10so9880687iea.19 for ; Wed, 06 Mar 2013 12:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ojU8758n8z9fuwx9aLppWfxOMMCfVif6PAPWvO6SCso=; b=IMwyKX8rXWFh7ao4DnyZh+X7JD+p7a+0FkDWEP72j+jix2HRgjElLzyzoKSjxtXoUU xNwl9DxrM5YYslCW/MtACLDoP3Js8AxNiLsjm6jNtuJk2SpCJ0vV2/cHTutz53DEZMXq eK0A0D1ePF75uiUKBB/rMllny8O35DKa3cVcOUrWMS/V276LRjCFYjTrstu0UPKQSJMV xYHx23tDvPziC9Ts6YdmkHPKwG9Y/DN0PlB1cIAgNNG9mwFrni5/DIdyIPbqZIwu5fOO uH8se49d4HMMSEI0h74in18AbzAzc+KbQWG6/DxIG6ucOJLNAs2R2z8xsouVfJcuKWxK mNmg== MIME-Version: 1.0 X-Received: by 10.50.46.202 with SMTP id x10mr12352464igm.87.1362600387246; Wed, 06 Mar 2013 12:06:27 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 12:06:27 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 12:06:27 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 17:06:27 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5931855173509267174==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5931855173509267174== Content-Type: multipart/alternative; boundary=14dae9340deb0dd0fe04d747206a --14dae9340deb0dd0fe04d747206a Content-Type: text/plain; charset=ISO-8859-1 Can you tell me what kernel version your distro's running with? On Mar 6, 2013 4:39 PM, "Guilherme Suzuki" wrote: Nice to know that! I'll uninstall Xen easily with yum and try XCP. I'll let you know how things turned out. > > On Mar 6, 2013 2:17 PM, "Gizmo Chicken" wrote: > > I used Windows 7 Ul... > > > > > On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki wrote: > > > Hmm I see... ... --14dae9340deb0dd0fe04d747206a Content-Type: text/html; charset=ISO-8859-1

Can you tell me what kernel version your distro's running with?

On Mar 6, 2013 4:39 PM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Nice to know that! I'll uninstall Xen easily with yum and try XCP.

I'll let you know how things turned out.


>
> On Mar 6, 2013 2:17 PM, "Gizmo Chicken" <gizmochicken@gmail.com> wrote:
>
> I used Windows 7 Ul...


>
>
>
>
> On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
> >

> Hmm I see... ...

--14dae9340deb0dd0fe04d747206a-- --===============5931855173509267174== 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 --===============5931855173509267174==-- From xen-users-bounces@lists.xen.org Wed Mar 06 20:08:28 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 06 Mar 2013 20:08: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 1UDKcg-0003ps-34; Wed, 06 Mar 2013 20:07:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDKce-0003pn-At for xen-users@lists.xen.org; Wed, 06 Mar 2013 20:07:32 +0000 Received: from [85.158.139.83:25769] by server-14.bemta-5.messagelabs.com id 20/53-13158-302A7315; Wed, 06 Mar 2013 20:07:31 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-11.tower-182.messagelabs.com!1362600449!20296066!1 X-Originating-IP: [209.85.223.174] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28750 invoked from network); 6 Mar 2013 20:07:30 -0000 Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com) (209.85.223.174) by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 20:07:30 -0000 Received: by mail-ie0-f174.google.com with SMTP id k10so9880687iea.19 for ; Wed, 06 Mar 2013 12:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ojU8758n8z9fuwx9aLppWfxOMMCfVif6PAPWvO6SCso=; b=IMwyKX8rXWFh7ao4DnyZh+X7JD+p7a+0FkDWEP72j+jix2HRgjElLzyzoKSjxtXoUU xNwl9DxrM5YYslCW/MtACLDoP3Js8AxNiLsjm6jNtuJk2SpCJ0vV2/cHTutz53DEZMXq eK0A0D1ePF75uiUKBB/rMllny8O35DKa3cVcOUrWMS/V276LRjCFYjTrstu0UPKQSJMV xYHx23tDvPziC9Ts6YdmkHPKwG9Y/DN0PlB1cIAgNNG9mwFrni5/DIdyIPbqZIwu5fOO uH8se49d4HMMSEI0h74in18AbzAzc+KbQWG6/DxIG6ucOJLNAs2R2z8xsouVfJcuKWxK mNmg== MIME-Version: 1.0 X-Received: by 10.50.46.202 with SMTP id x10mr12352464igm.87.1362600387246; Wed, 06 Mar 2013 12:06:27 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 12:06:27 -0800 (PST) Received: by 10.64.170.65 with HTTP; Wed, 6 Mar 2013 12:06:27 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Wed, 6 Mar 2013 17:06:27 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============5931855173509267174==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5931855173509267174== Content-Type: multipart/alternative; boundary=14dae9340deb0dd0fe04d747206a --14dae9340deb0dd0fe04d747206a Content-Type: text/plain; charset=ISO-8859-1 Can you tell me what kernel version your distro's running with? On Mar 6, 2013 4:39 PM, "Guilherme Suzuki" wrote: Nice to know that! I'll uninstall Xen easily with yum and try XCP. I'll let you know how things turned out. > > On Mar 6, 2013 2:17 PM, "Gizmo Chicken" wrote: > > I used Windows 7 Ul... > > > > > On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki wrote: > > > Hmm I see... ... --14dae9340deb0dd0fe04d747206a Content-Type: text/html; charset=ISO-8859-1

Can you tell me what kernel version your distro's running with?

On Mar 6, 2013 4:39 PM, "Guilherme Suzuki" <suzuki.gui@gmail.com> wrote:

Nice to know that! I'll uninstall Xen easily with yum and try XCP.

I'll let you know how things turned out.


>
> On Mar 6, 2013 2:17 PM, "Gizmo Chicken" <gizmochicken@gmail.com> wrote:
>
> I used Windows 7 Ul...


>
>
>
>
> On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
> >

> Hmm I see... ...

--14dae9340deb0dd0fe04d747206a-- --===============5931855173509267174== 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 --===============5931855173509267174==-- From xen-users-bounces@lists.xen.org Thu Mar 07 02:54:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 02:54: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 1UDQwx-0004in-5i; Thu, 07 Mar 2013 02:52:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDQww-0004ie-AD for xen-users@lists.xen.org; Thu, 07 Mar 2013 02:52:54 +0000 Received: from [193.109.254.147:58025] by server-14.bemta-14.messagelabs.com id 20/22-05867-50108315; Thu, 07 Mar 2013 02:52:53 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1362624771!6505854!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ5NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29521 invoked from network); 7 Mar 2013 02:52:52 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 02:52:52 -0000 X-IronPort-AV: E=Sophos;i="4.84,799,1355097600"; d="scan'208";a="11099165" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 07 Mar 2013 02:52:21 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.318.1; Wed, 6 Mar 2013 21:52:21 -0500 Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UDQwO-00055m-HX; Thu, 07 Mar 2013 02:52:21 +0000 Message-ID: <1362624579.8941.108.camel@hastur.hellion.org.uk> From: Ian Campbell To: Matthew Dean Date: Thu, 7 Mar 2013 02:49:39 +0000 In-Reply-To: <513755FE.4050401@cam.ac.uk> References: <513755FE.4050401@cam.ac.uk> X-Mailer: Evolution 3.4.4-2 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Problems creating a simple hvm domU X-BeenThere: xen-users@lists.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 > A domain is created and can be seen with xl list but it is not running. > I do not know how to get any more debug information than this and all I > can discern is that the spawn failed (rc=-3). Does /usr/lib/xen/bin/qemu-dm exist on your system? You might find some other clues under /var/log/xen/*Windows7Test*, especially the qemu-dm one. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 07 02:54:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 02:54: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 1UDQwx-0004in-5i; Thu, 07 Mar 2013 02:52:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDQww-0004ie-AD for xen-users@lists.xen.org; Thu, 07 Mar 2013 02:52:54 +0000 Received: from [193.109.254.147:58025] by server-14.bemta-14.messagelabs.com id 20/22-05867-50108315; Thu, 07 Mar 2013 02:52:53 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1362624771!6505854!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDQ5NjQ=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29521 invoked from network); 7 Mar 2013 02:52:52 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 02:52:52 -0000 X-IronPort-AV: E=Sophos;i="4.84,799,1355097600"; d="scan'208";a="11099165" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 07 Mar 2013 02:52:21 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.318.1; Wed, 6 Mar 2013 21:52:21 -0500 Received: from gateway-1.uk.xensource.com ([10.80.16.66] helo=[127.0.0.1]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UDQwO-00055m-HX; Thu, 07 Mar 2013 02:52:21 +0000 Message-ID: <1362624579.8941.108.camel@hastur.hellion.org.uk> From: Ian Campbell To: Matthew Dean Date: Thu, 7 Mar 2013 02:49:39 +0000 In-Reply-To: <513755FE.4050401@cam.ac.uk> References: <513755FE.4050401@cam.ac.uk> X-Mailer: Evolution 3.4.4-2 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Problems creating a simple hvm domU X-BeenThere: xen-users@lists.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 > A domain is created and can be seen with xl list but it is not running. > I do not know how to get any more debug information than this and all I > can discern is that the spawn failed (rc=-3). Does /usr/lib/xen/bin/qemu-dm exist on your system? You might find some other clues under /var/log/xen/*Windows7Test*, especially the qemu-dm one. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 07 09:58:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 09:58: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 1UDXZw-0003O0-6W; Thu, 07 Mar 2013 09:57:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDXZt-0003Nu-UJ for xen-users@lists.xen.org; Thu, 07 Mar 2013 09:57:34 +0000 Received: from [85.158.139.83:36099] by server-6.bemta-5.messagelabs.com id FD/3F-21466-D8468315; Thu, 07 Mar 2013 09:57:33 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1362650249!26919598!1 X-Originating-IP: [209.85.219.49] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31379 invoked from network); 7 Mar 2013 09:57:31 -0000 Received: from mail-oa0-f49.google.com (HELO mail-oa0-f49.google.com) (209.85.219.49) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 09:57:31 -0000 Received: by mail-oa0-f49.google.com with SMTP id j6so321210oag.8 for ; Thu, 07 Mar 2013 01:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=spDfUr3vSssbw8zHjfAnuPPI75XZWSFTF/oZ7xu4sK0=; b=kTMGWe6hFFWfe4E0yxlWi+BGZeXA89+ND4movWiU/JBaS6Z/g8ph9+BRBodO7qs8dz vWz+sjfoyUO1ICgW79epEHXF139I72ZWUYfYWFoM59grAhjOgH8FbkJiZGAm0uSDbVED LOVj16Ow/D8QQcdBVNUyMXS1QJWzdzWWlx5oFFgZfiPI9zTAB8f4UkqP350RvntzKN6B avSVqEtD0pY2CCZNOpJrum7++9GY9b7Eb1/S7E5us+f8oX2v8PIfN5VUGCA4NIavgpb3 DqlMspSon/Qr+2zX8aHbEL1mtiv3FTAlJhyqBut+IRZKrIgN9qVcXolHDy+srjTBOLlO QRxQ== MIME-Version: 1.0 X-Received: by 10.182.43.103 with SMTP id v7mr25270103obl.17.1362650248783; Thu, 07 Mar 2013 01:57:28 -0800 (PST) Received: by 10.60.57.102 with HTTP; Thu, 7 Mar 2013 01:57:28 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Thu, 7 Mar 2013 04:57:28 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============0871445844705372888==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0871445844705372888== Content-Type: multipart/alternative; boundary=f46d044794f3082d9704d752bcaa --f46d044794f3082d9704d752bcaa Content-Type: text/plain; charset=ISO-8859-1 Guilherme, Before moving further, let's verify: You do have IOMMU enabled in your BIOS, correct? If not, you need to enable it to get GPU passthrough to work. Now, back to XCP 1.6... XCP 1.6 is kind of a "black box" approach, in that you won't be able to simply install it over your current dom0, but instead you must *replace*your current dom0. That said, XCP 1.6 is based on CentOS 5.7 (Linux kernel v2.6.32.43). But be aware that XCP 1.6 won't give you a graphical desktop on dom0. So if you need a graphical desktop on dom0, XCP 1.6 won't be a long term solution for you. But given the ease of setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough. Also, be aware that, although GPU passthrough is pretty simple with XPC 1.6, strangely, *you'll have to do some digging on how to set up PCI-passthrough so that your mouse/keyboard/device is accessible from a guest VM.* It can be done, but the procedure isn't well-documented. When (and if) you get XPC 1.6 installed and GPU passthrough working, write back to me, and I'll try to help with the PCI passthrough. (One thing at a time.) If you must have graphical desktop on dom0, then you have another option, namely installing the *XCP-XAPI toolstack* (which is the toolstack used by XCP 1.6) on a desktop version of Ubuntu. In my case, I have successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop. If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials: http://www.chimos.de/stuff/xen-xcp-ubuntu-manual/xen-xcp-ubuntu-manual.txt http://blog.scottlowe.org/2012/06/28/installing-xcp-xapi-on-ubuntu-server-12-04-lts/ Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots of hacks and may be a bumpy process. So before you even try, I recommend that you *first* experiment with XCP 1.6 (the "black box" approach) to see if it works with your hardware and if XenCenter fits your needs. Hope the above help. GizmoChicken On Wed, Mar 6, 2013 at 3:06 PM, Guilherme Suzuki wrote: > Can you tell me what kernel version your distro's running with? > > On Mar 6, 2013 4:39 PM, "Guilherme Suzuki" wrote: > > Nice to know that! I'll uninstall Xen easily with yum and try XCP. > > I'll let you know how things turned out. > > > > > > On Mar 6, 2013 2:17 PM, "Gizmo Chicken" wrote: > > > > I used Windows 7 Ul... > > > > > > > > > > > > On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki > wrote: > > > > > Hmm I see... ... > > --f46d044794f3082d9704d752bcaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Guilherme,

Before moving further, let's verify:=A0 You do have I= OMMU enabled in your BIOS, correct?=A0 If not, you need to enable it to get= GPU passthrough to work.

Now, back to XCP 1.6...

XCP 1.6 is kind of a "black box" approach, in that you won't be = able to=20 simply install it over your current dom0, but instead you must replace your current dom0.=A0=A0 That said, XCP 1.6 is based on CentOS 5.7 (Linux= =20 kernel v2.6.32.43).=A0 But be aware that=A0 XCP 1.6 won't give you a=20 graphical desktop on dom0.=A0 So if you need a graphical desktop on dom0,= =20 XCP 1.6 won't be a long term solution for you.=A0 But given the ease of= =20 setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough.=A0

Also,= be=20 aware that, although GPU passthrough is pretty simple with XPC 1.6,=20 strangely, you'll have to do some digging on how to set up=20 PCI-passthrough so that your mouse/keyboard/device is accessible from a=20 guest VM.=A0 It can be done, but the procedure isn't well-documente= d.=A0 When (and if) you get XPC 1.6 installed and GPU passthrough working, = write back to me, and I'll try to help with the PCI passthrough.=A0 (On= e thing at a time.)

If you must have graphical desktop on dom0, then you have another option,=20 namely installing the XCP-XAPI toolstack (which is the toolstack use= d by XCP 1.6) on a desktop version of Ubuntu.=A0 In my case, I have=20 successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop.
<= br>If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials:

http://www.chimos.de/stuff/xen-xcp-ubuntu-manual/xen-xcp-ubuntu-ma= nual.txt
http://blog.scottlowe.org/2012/06/28/installing-xcp-x= api-on-ubuntu-server-12-04-lts/

Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots=20 of hacks and may be a bumpy process.=A0 So before you even try, I recommend= that you first experiment with XCP 1.6 (the "black box" approach) to see if it works with = your=20 hardware and if XenCenter fits your needs.

Hope the above help.
<= br>GizmoChicken



On Wed, Mar 6, 20= 13 at 3:06 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wr= ote:

Can you tell me what kernel version your distro's running with?

> I used Windows 7 Ul...


>
>
>
>
> On Wed, Mar 6, 2013 = at 11:46 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
> >

> Hmm I see... ...


--f46d044794f3082d9704d752bcaa-- --===============0871445844705372888== 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 --===============0871445844705372888==-- From xen-users-bounces@lists.xen.org Thu Mar 07 09:58:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 09:58: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 1UDXZw-0003O0-6W; Thu, 07 Mar 2013 09:57:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDXZt-0003Nu-UJ for xen-users@lists.xen.org; Thu, 07 Mar 2013 09:57:34 +0000 Received: from [85.158.139.83:36099] by server-6.bemta-5.messagelabs.com id FD/3F-21466-D8468315; Thu, 07 Mar 2013 09:57:33 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1362650249!26919598!1 X-Originating-IP: [209.85.219.49] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31379 invoked from network); 7 Mar 2013 09:57:31 -0000 Received: from mail-oa0-f49.google.com (HELO mail-oa0-f49.google.com) (209.85.219.49) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 09:57:31 -0000 Received: by mail-oa0-f49.google.com with SMTP id j6so321210oag.8 for ; Thu, 07 Mar 2013 01:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=spDfUr3vSssbw8zHjfAnuPPI75XZWSFTF/oZ7xu4sK0=; b=kTMGWe6hFFWfe4E0yxlWi+BGZeXA89+ND4movWiU/JBaS6Z/g8ph9+BRBodO7qs8dz vWz+sjfoyUO1ICgW79epEHXF139I72ZWUYfYWFoM59grAhjOgH8FbkJiZGAm0uSDbVED LOVj16Ow/D8QQcdBVNUyMXS1QJWzdzWWlx5oFFgZfiPI9zTAB8f4UkqP350RvntzKN6B avSVqEtD0pY2CCZNOpJrum7++9GY9b7Eb1/S7E5us+f8oX2v8PIfN5VUGCA4NIavgpb3 DqlMspSon/Qr+2zX8aHbEL1mtiv3FTAlJhyqBut+IRZKrIgN9qVcXolHDy+srjTBOLlO QRxQ== MIME-Version: 1.0 X-Received: by 10.182.43.103 with SMTP id v7mr25270103obl.17.1362650248783; Thu, 07 Mar 2013 01:57:28 -0800 (PST) Received: by 10.60.57.102 with HTTP; Thu, 7 Mar 2013 01:57:28 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Thu, 7 Mar 2013 04:57:28 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============0871445844705372888==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0871445844705372888== Content-Type: multipart/alternative; boundary=f46d044794f3082d9704d752bcaa --f46d044794f3082d9704d752bcaa Content-Type: text/plain; charset=ISO-8859-1 Guilherme, Before moving further, let's verify: You do have IOMMU enabled in your BIOS, correct? If not, you need to enable it to get GPU passthrough to work. Now, back to XCP 1.6... XCP 1.6 is kind of a "black box" approach, in that you won't be able to simply install it over your current dom0, but instead you must *replace*your current dom0. That said, XCP 1.6 is based on CentOS 5.7 (Linux kernel v2.6.32.43). But be aware that XCP 1.6 won't give you a graphical desktop on dom0. So if you need a graphical desktop on dom0, XCP 1.6 won't be a long term solution for you. But given the ease of setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough. Also, be aware that, although GPU passthrough is pretty simple with XPC 1.6, strangely, *you'll have to do some digging on how to set up PCI-passthrough so that your mouse/keyboard/device is accessible from a guest VM.* It can be done, but the procedure isn't well-documented. When (and if) you get XPC 1.6 installed and GPU passthrough working, write back to me, and I'll try to help with the PCI passthrough. (One thing at a time.) If you must have graphical desktop on dom0, then you have another option, namely installing the *XCP-XAPI toolstack* (which is the toolstack used by XCP 1.6) on a desktop version of Ubuntu. In my case, I have successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop. If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials: http://www.chimos.de/stuff/xen-xcp-ubuntu-manual/xen-xcp-ubuntu-manual.txt http://blog.scottlowe.org/2012/06/28/installing-xcp-xapi-on-ubuntu-server-12-04-lts/ Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots of hacks and may be a bumpy process. So before you even try, I recommend that you *first* experiment with XCP 1.6 (the "black box" approach) to see if it works with your hardware and if XenCenter fits your needs. Hope the above help. GizmoChicken On Wed, Mar 6, 2013 at 3:06 PM, Guilherme Suzuki wrote: > Can you tell me what kernel version your distro's running with? > > On Mar 6, 2013 4:39 PM, "Guilherme Suzuki" wrote: > > Nice to know that! I'll uninstall Xen easily with yum and try XCP. > > I'll let you know how things turned out. > > > > > > On Mar 6, 2013 2:17 PM, "Gizmo Chicken" wrote: > > > > I used Windows 7 Ul... > > > > > > > > > > > > On Wed, Mar 6, 2013 at 11:46 AM, Guilherme Suzuki > wrote: > > > > > Hmm I see... ... > > --f46d044794f3082d9704d752bcaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Guilherme,

Before moving further, let's verify:=A0 You do have I= OMMU enabled in your BIOS, correct?=A0 If not, you need to enable it to get= GPU passthrough to work.

Now, back to XCP 1.6...

XCP 1.6 is kind of a "black box" approach, in that you won't be = able to=20 simply install it over your current dom0, but instead you must replace your current dom0.=A0=A0 That said, XCP 1.6 is based on CentOS 5.7 (Linux= =20 kernel v2.6.32.43).=A0 But be aware that=A0 XCP 1.6 won't give you a=20 graphical desktop on dom0.=A0 So if you need a graphical desktop on dom0,= =20 XCP 1.6 won't be a long term solution for you.=A0 But given the ease of= =20 setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough.=A0

Also,= be=20 aware that, although GPU passthrough is pretty simple with XPC 1.6,=20 strangely, you'll have to do some digging on how to set up=20 PCI-passthrough so that your mouse/keyboard/device is accessible from a=20 guest VM.=A0 It can be done, but the procedure isn't well-documente= d.=A0 When (and if) you get XPC 1.6 installed and GPU passthrough working, = write back to me, and I'll try to help with the PCI passthrough.=A0 (On= e thing at a time.)

If you must have graphical desktop on dom0, then you have another option,=20 namely installing the XCP-XAPI toolstack (which is the toolstack use= d by XCP 1.6) on a desktop version of Ubuntu.=A0 In my case, I have=20 successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop.
<= br>If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials:

http://www.chimos.de/stuff/xen-xcp-ubuntu-manual/xen-xcp-ubuntu-ma= nual.txt
http://blog.scottlowe.org/2012/06/28/installing-xcp-x= api-on-ubuntu-server-12-04-lts/

Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots=20 of hacks and may be a bumpy process.=A0 So before you even try, I recommend= that you first experiment with XCP 1.6 (the "black box" approach) to see if it works with = your=20 hardware and if XenCenter fits your needs.

Hope the above help.
<= br>GizmoChicken



On Wed, Mar 6, 20= 13 at 3:06 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wr= ote:

Can you tell me what kernel version your distro's running with?

> I used Windows 7 Ul...


>
>
>
>
> On Wed, Mar 6, 2013 = at 11:46 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
> >

> Hmm I see... ...


--f46d044794f3082d9704d752bcaa-- --===============0871445844705372888== 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 --===============0871445844705372888==-- From xen-users-bounces@lists.xen.org Thu Mar 07 11:28:49 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 11:28: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 1UDYzE-0006SH-G5; Thu, 07 Mar 2013 11:27:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDYzD-0006SA-BV for xen-users@lists.xen.org; Thu, 07 Mar 2013 11:27:47 +0000 Received: from [85.158.138.51:34888] by server-9.bemta-3.messagelabs.com id EF/2D-32531-2B978315; Thu, 07 Mar 2013 11:27:46 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-11.tower-174.messagelabs.com!1362655656!27515761!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTMzMw==\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6067 invoked from network); 7 Mar 2013 11:27:36 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-11.tower-174.messagelabs.com with SMTP; 7 Mar 2013 11:27:36 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:51657) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UDYz2-0002EC-7F (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Thu, 07 Mar 2013 11:27:36 +0000 Message-ID: <51387988.2070705@cam.ac.uk> Date: Thu, 07 Mar 2013 11:27:04 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <513755FE.4050401@cam.ac.uk> <1362624579.8941.108.camel@hastur.hellion.org.uk> In-Reply-To: <1362624579.8941.108.camel@hastur.hellion.org.uk> Subject: Re: [Xen-users] Problems creating a simple hvm domU X-BeenThere: xen-users@lists.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 Good call Ian, and thanks for the quick reply. From the log file I deduced that the error was due to a missing keymap (gb). Interestingly even if I change the keymap in the vm config this still occurs, I assume because my system keymap is still set to gb. I've since sorted this problem by copying the 'en-gb' keymap to 'gb' and can now get the vm to enter a running state. I've now just got to sort out connecting to it via vnc. Hopefully I can manage to work that out without too many issues. Once again thanks for your help. Matt On 07/03/2013 02:49, Ian Campbell wrote: >> A domain is created and can be seen with xl list but it is not running. >> I do not know how to get any more debug information than this and all I >> can discern is that the spawn failed (rc=-3). > Does /usr/lib/xen/bin/qemu-dm exist on your system? > > You might find some other clues under /var/log/xen/*Windows7Test*, > especially the qemu-dm one. > > Ian. > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 07 11:28:49 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 11:28: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 1UDYzE-0006SH-G5; Thu, 07 Mar 2013 11:27:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDYzD-0006SA-BV for xen-users@lists.xen.org; Thu, 07 Mar 2013 11:27:47 +0000 Received: from [85.158.138.51:34888] by server-9.bemta-3.messagelabs.com id EF/2D-32531-2B978315; Thu, 07 Mar 2013 11:27:46 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-11.tower-174.messagelabs.com!1362655656!27515761!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTMzMw==\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6067 invoked from network); 7 Mar 2013 11:27:36 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-11.tower-174.messagelabs.com with SMTP; 7 Mar 2013 11:27:36 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:51657) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UDYz2-0002EC-7F (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Thu, 07 Mar 2013 11:27:36 +0000 Message-ID: <51387988.2070705@cam.ac.uk> Date: Thu, 07 Mar 2013 11:27:04 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <513755FE.4050401@cam.ac.uk> <1362624579.8941.108.camel@hastur.hellion.org.uk> In-Reply-To: <1362624579.8941.108.camel@hastur.hellion.org.uk> Subject: Re: [Xen-users] Problems creating a simple hvm domU X-BeenThere: xen-users@lists.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 Good call Ian, and thanks for the quick reply. From the log file I deduced that the error was due to a missing keymap (gb). Interestingly even if I change the keymap in the vm config this still occurs, I assume because my system keymap is still set to gb. I've since sorted this problem by copying the 'en-gb' keymap to 'gb' and can now get the vm to enter a running state. I've now just got to sort out connecting to it via vnc. Hopefully I can manage to work that out without too many issues. Once again thanks for your help. Matt On 07/03/2013 02:49, Ian Campbell wrote: >> A domain is created and can be seen with xl list but it is not running. >> I do not know how to get any more debug information than this and all I >> can discern is that the spawn failed (rc=-3). > Does /usr/lib/xen/bin/qemu-dm exist on your system? > > You might find some other clues under /var/log/xen/*Windows7Test*, > especially the qemu-dm one. > > Ian. > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 07 11:33:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 11:33: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 1UDZ3c-0006mn-RQ; Thu, 07 Mar 2013 11:32:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDZ3c-0006mf-2F for xen-users@lists.xen.org; Thu, 07 Mar 2013 11:32:20 +0000 Received: from [193.109.254.147:29120] by server-1.bemta-14.messagelabs.com id 2B/29-28280-3CA78315; Thu, 07 Mar 2013 11:32:19 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1362655149!8922419!1 X-Originating-IP: [209.85.223.180] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19346 invoked from network); 7 Mar 2013 11:19:10 -0000 Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com) (209.85.223.180) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 11:19:10 -0000 Received: by mail-ie0-f180.google.com with SMTP id bn7so363053ieb.25 for ; Thu, 07 Mar 2013 03:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=12LChGJtZhY54a2nqafUjqUK+GtY1FgFmv4uM5E4x94=; b=XchiNhbMeRJvMSkPiOBzL66WNOTdNZVdhVrTLZxJVyaeiEQN4vLD7Nfs/Q2S68Vdw1 +h+7m8ca4s4aYGws10N+OgjMiuoHwKr5nuLZ7QWSFk0WMPJ1Tf9RVNTSK5qfi7WwRIz8 RFZkZwVZmElsx0BgydXis4sA2DDmgAw0PVamt57OwQ97kFYPiLOu5DCkuBHJyFMLP1tx 2l+6lJfbfImP0sL2IexN6Z9jutg1d+KP9L5dqO1V7Jhula65Fe27OmT7ByYr4jNX3LZp NEL+p8dTT8YCEKFIu0D/P5/2+UmPCaugiVCprULhQV4rFYebvr5DzuB3Oe4JQ7cMhxKS 5ABg== MIME-Version: 1.0 X-Received: by 10.50.7.240 with SMTP id m16mr14040415iga.91.1362655148717; Thu, 07 Mar 2013 03:19:08 -0800 (PST) Received: by 10.64.170.65 with HTTP; Thu, 7 Mar 2013 03:19:07 -0800 (PST) Received: by 10.64.170.65 with HTTP; Thu, 7 Mar 2013 03:19:07 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Thu, 7 Mar 2013 08:19:07 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============1629646802911929359==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1629646802911929359== Content-Type: multipart/alternative; boundary=f46d0447976d173c4204d753e0d8 --f46d0447976d173c4204d753e0d8 Content-Type: text/plain; charset=ISO-8859-1 Gizmo, I've gone a little bit further than that. I managed to make things (vga passthru) working, but that only works with freshly booted dom0. On Mar 7, 2013 6:57 AM, "Gizmo Chicken" wrote: Guilherme, Before moving further, let's verify: You do have IOMMU enabled in your BIOS, correct? If not, you need to enable it to get GPU passthrough to work. Now, back to XCP 1.6... XCP 1.6 is kind of a "black box" approach, in that you won't be able to simply install it over your current dom0, but instead you must *replace*your current dom0. That said, XCP 1.6 is based on CentOS 5.7 (Linux kernel v2.6.32.43). But be aware that XCP 1.6 won't give you a graphical desktop on dom0. So if you need a graphical desktop on dom0, XCP 1.6 won't be a long term solution for you. But given the ease of setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough. Also, be aware that, although GPU passthrough is pretty simple with XPC 1.6, strangely, *you'll have to do some digging on how to set up PCI-passthrough so that your mouse/keyboard/device is accessible from a guest VM.* It can be done, but the procedure isn't well-documented. When (and if) you get XPC 1.6 installed and GPU passthrough working, write back to me, and I'll try to help with the PCI passthrough. (One thing at a time.) If you must have graphical desktop on dom0, then you have another option, namely installing the *XCP-XAPI toolstack* (which is the toolstack used by XCP 1.6) on a desktop version of Ubuntu. In my case, I have successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop. If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials: http://www.chimos.de/stuff/xen-xcp-ubuntu-manual/xen-xcp-ubuntu-manual.txt http://blog.scottlowe.org/2012/06/28/installing-xcp-xapi-on-ubuntu-server-12-04-lts/ Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots of hacks and may be a bumpy process. So before you even try, I recommend that you *first* experiment with XCP 1.6 (the "black box" approach) to see if it works with your hardware and if XenCenter fits your needs. Hope the above help. GizmoChicken On Wed, Mar 6, 2013 at 3:06 PM, Guilherme Suzuki wrote: > > Can you tell ... --f46d0447976d173c4204d753e0d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Gizmo, I've gone a little bit further than that. I managed to make t= hings (vga passthru) working, but that only works with freshly booted dom0.=

On Mar 7, 2013 6:57 AM, "Gizmo Chicken&qu= ot; <gizmochicken@gmail.com> wrote:

Guilherme,

Before moving further, let's veri= fy:=A0 You do have IOMMU enabled in your BIOS, correct?=A0 If not, you need= to enable it to get GPU passthrough to work.

Now, back to XCP 1.6...

XCP 1.6 is kind of a "black box" approach, in that you won't be = able to=20 simply install it over your current dom0, but instead you must replace your current dom0.=A0=A0 That said, XCP 1.6 is based on CentOS 5.7 (Linux= =20 kernel v2.6.32.43).=A0 But be aware that=A0 XCP 1.6 won't give you a=20 graphical desktop on dom0.=A0 So if you need a graphical desktop on dom0,= =20 XCP 1.6 won't be a long term solution for you.=A0 But given the ease of= =20 setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough.=A0

Also,= be=20 aware that, although GPU passthrough is pretty simple with XPC 1.6,=20 strangely, you'll have to do some digging on how to set up=20 PCI-passthrough so that your mouse/keyboard/device is accessible from a=20 guest VM.=A0 It can be done, but the procedure isn't well-documente= d.=A0 When (and if) you get XPC 1.6 installed and GPU passthrough working, = write back to me, and I'll try to help with the PCI passthrough.=A0 (On= e thing at a time.)

If you must have graphical desktop on dom0, then you have another option,=20 namely installing the XCP-XAPI toolstack (which is the toolstack use= d by XCP 1.6) on a desktop version of Ubuntu.=A0 In my case, I have=20 successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop.
<= br>If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials:

http://www.chimos.de/stuff/xen-xcp-ubuntu-manual= /xen-xcp-ubuntu-manual.txt
http://blog.scottlowe.org/2012/06/2= 8/installing-xcp-xapi-on-ubuntu-server-12-04-lts/

Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots=20 of hacks and may be a bumpy process.=A0 So before you even try, I recommend= that you first experiment with XCP 1.6 (the "black box" approach) to see if it works with = your=20 hardware and if XenCenter fits your needs.

Hope the above help.
<= br>GizmoChicken





On Wed, Mar 6, 20= 13 at 3:06 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
> Can you tell ...

--f46d0447976d173c4204d753e0d8-- --===============1629646802911929359== 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 --===============1629646802911929359==-- From xen-users-bounces@lists.xen.org Thu Mar 07 11:33:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 11:33: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 1UDZ3c-0006mn-RQ; Thu, 07 Mar 2013 11:32:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDZ3c-0006mf-2F for xen-users@lists.xen.org; Thu, 07 Mar 2013 11:32:20 +0000 Received: from [193.109.254.147:29120] by server-1.bemta-14.messagelabs.com id 2B/29-28280-3CA78315; Thu, 07 Mar 2013 11:32:19 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1362655149!8922419!1 X-Originating-IP: [209.85.223.180] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19346 invoked from network); 7 Mar 2013 11:19:10 -0000 Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com) (209.85.223.180) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 11:19:10 -0000 Received: by mail-ie0-f180.google.com with SMTP id bn7so363053ieb.25 for ; Thu, 07 Mar 2013 03:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=12LChGJtZhY54a2nqafUjqUK+GtY1FgFmv4uM5E4x94=; b=XchiNhbMeRJvMSkPiOBzL66WNOTdNZVdhVrTLZxJVyaeiEQN4vLD7Nfs/Q2S68Vdw1 +h+7m8ca4s4aYGws10N+OgjMiuoHwKr5nuLZ7QWSFk0WMPJ1Tf9RVNTSK5qfi7WwRIz8 RFZkZwVZmElsx0BgydXis4sA2DDmgAw0PVamt57OwQ97kFYPiLOu5DCkuBHJyFMLP1tx 2l+6lJfbfImP0sL2IexN6Z9jutg1d+KP9L5dqO1V7Jhula65Fe27OmT7ByYr4jNX3LZp NEL+p8dTT8YCEKFIu0D/P5/2+UmPCaugiVCprULhQV4rFYebvr5DzuB3Oe4JQ7cMhxKS 5ABg== MIME-Version: 1.0 X-Received: by 10.50.7.240 with SMTP id m16mr14040415iga.91.1362655148717; Thu, 07 Mar 2013 03:19:08 -0800 (PST) Received: by 10.64.170.65 with HTTP; Thu, 7 Mar 2013 03:19:07 -0800 (PST) Received: by 10.64.170.65 with HTTP; Thu, 7 Mar 2013 03:19:07 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Thu, 7 Mar 2013 08:19:07 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============1629646802911929359==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1629646802911929359== Content-Type: multipart/alternative; boundary=f46d0447976d173c4204d753e0d8 --f46d0447976d173c4204d753e0d8 Content-Type: text/plain; charset=ISO-8859-1 Gizmo, I've gone a little bit further than that. I managed to make things (vga passthru) working, but that only works with freshly booted dom0. On Mar 7, 2013 6:57 AM, "Gizmo Chicken" wrote: Guilherme, Before moving further, let's verify: You do have IOMMU enabled in your BIOS, correct? If not, you need to enable it to get GPU passthrough to work. Now, back to XCP 1.6... XCP 1.6 is kind of a "black box" approach, in that you won't be able to simply install it over your current dom0, but instead you must *replace*your current dom0. That said, XCP 1.6 is based on CentOS 5.7 (Linux kernel v2.6.32.43). But be aware that XCP 1.6 won't give you a graphical desktop on dom0. So if you need a graphical desktop on dom0, XCP 1.6 won't be a long term solution for you. But given the ease of setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough. Also, be aware that, although GPU passthrough is pretty simple with XPC 1.6, strangely, *you'll have to do some digging on how to set up PCI-passthrough so that your mouse/keyboard/device is accessible from a guest VM.* It can be done, but the procedure isn't well-documented. When (and if) you get XPC 1.6 installed and GPU passthrough working, write back to me, and I'll try to help with the PCI passthrough. (One thing at a time.) If you must have graphical desktop on dom0, then you have another option, namely installing the *XCP-XAPI toolstack* (which is the toolstack used by XCP 1.6) on a desktop version of Ubuntu. In my case, I have successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop. If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials: http://www.chimos.de/stuff/xen-xcp-ubuntu-manual/xen-xcp-ubuntu-manual.txt http://blog.scottlowe.org/2012/06/28/installing-xcp-xapi-on-ubuntu-server-12-04-lts/ Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots of hacks and may be a bumpy process. So before you even try, I recommend that you *first* experiment with XCP 1.6 (the "black box" approach) to see if it works with your hardware and if XenCenter fits your needs. Hope the above help. GizmoChicken On Wed, Mar 6, 2013 at 3:06 PM, Guilherme Suzuki wrote: > > Can you tell ... --f46d0447976d173c4204d753e0d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Gizmo, I've gone a little bit further than that. I managed to make t= hings (vga passthru) working, but that only works with freshly booted dom0.=

On Mar 7, 2013 6:57 AM, "Gizmo Chicken&qu= ot; <gizmochicken@gmail.com> wrote:

Guilherme,

Before moving further, let's veri= fy:=A0 You do have IOMMU enabled in your BIOS, correct?=A0 If not, you need= to enable it to get GPU passthrough to work.

Now, back to XCP 1.6...

XCP 1.6 is kind of a "black box" approach, in that you won't be = able to=20 simply install it over your current dom0, but instead you must replace your current dom0.=A0=A0 That said, XCP 1.6 is based on CentOS 5.7 (Linux= =20 kernel v2.6.32.43).=A0 But be aware that=A0 XCP 1.6 won't give you a=20 graphical desktop on dom0.=A0 So if you need a graphical desktop on dom0,= =20 XCP 1.6 won't be a long term solution for you.=A0 But given the ease of= =20 setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough.=A0

Also,= be=20 aware that, although GPU passthrough is pretty simple with XPC 1.6,=20 strangely, you'll have to do some digging on how to set up=20 PCI-passthrough so that your mouse/keyboard/device is accessible from a=20 guest VM.=A0 It can be done, but the procedure isn't well-documente= d.=A0 When (and if) you get XPC 1.6 installed and GPU passthrough working, = write back to me, and I'll try to help with the PCI passthrough.=A0 (On= e thing at a time.)

If you must have graphical desktop on dom0, then you have another option,=20 namely installing the XCP-XAPI toolstack (which is the toolstack use= d by XCP 1.6) on a desktop version of Ubuntu.=A0 In my case, I have=20 successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop.
<= br>If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials:

http://www.chimos.de/stuff/xen-xcp-ubuntu-manual= /xen-xcp-ubuntu-manual.txt
http://blog.scottlowe.org/2012/06/2= 8/installing-xcp-xapi-on-ubuntu-server-12-04-lts/

Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots=20 of hacks and may be a bumpy process.=A0 So before you even try, I recommend= that you first experiment with XCP 1.6 (the "black box" approach) to see if it works with = your=20 hardware and if XenCenter fits your needs.

Hope the above help.
<= br>GizmoChicken





On Wed, Mar 6, 20= 13 at 3:06 PM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
> Can you tell ...

--f46d0447976d173c4204d753e0d8-- --===============1629646802911929359== 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 --===============1629646802911929359==-- From xen-users-bounces@lists.xen.org Thu Mar 07 13:54:26 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 13:54: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 1UDbG3-0001M0-Nx; Thu, 07 Mar 2013 13:53:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDbG1-0001Lv-Mn for xen-users@lists.xen.org; Thu, 07 Mar 2013 13:53:18 +0000 Received: from [85.158.138.51:33805] by server-14.bemta-3.messagelabs.com id 55/FA-27076-8CB98315; Thu, 07 Mar 2013 13:53:12 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1362664389!21069259!1 X-Originating-IP: [209.85.219.44] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26665 invoked from network); 7 Mar 2013 13:53:10 -0000 Received: from mail-oa0-f44.google.com (HELO mail-oa0-f44.google.com) (209.85.219.44) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 13:53:10 -0000 Received: by mail-oa0-f44.google.com with SMTP id h1so577410oag.17 for ; Thu, 07 Mar 2013 05:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NXDTwO7ja509sgv2tuzJNuU1VbV+aKNz8lq6PYOT/bQ=; b=qoNJhHcSeh5hyFcczAMXAE13kjjHa9sX5IhW/XRm9TAD7Zcilx10oxCLCOBSXEJ5GV cSwIEtcKt8h3115xSqW6Bt1Qgd3GBEntTSaJ/K0kgI7hqTKReM5sdJdfxOIyN5V3yhE8 /NjYriswQMaRycIH8LN5XZ1czN1uNfGlyLsGgIvHV/b6esZvivHWSvQrtLybwk6Xk+gU UvUWelJ8NWZY80hTxOphjqIliCNk7Kh9hrFDS09VN3d2aB2xWIr+w5kWRoTsY/k6l+Sc M7nk2Ejpo+2GXdLKa7E0AkB6ASyzayFmekM1sHmqmLlBcXDG3ZfLRKywu2SQpwmiZJpi elyQ== MIME-Version: 1.0 X-Received: by 10.182.114.97 with SMTP id jf1mr26007940obb.31.1362664388404; Thu, 07 Mar 2013 05:53:08 -0800 (PST) Received: by 10.60.57.102 with HTTP; Thu, 7 Mar 2013 05:53:08 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Thu, 7 Mar 2013 08:53:08 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============6251783255312281042==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6251783255312281042== Content-Type: multipart/alternative; boundary=f46d0444edf1d1add404d7560698 --f46d0444edf1d1add404d7560698 Content-Type: text/plain; charset=ISO-8859-1 Guilherme, Okay. Good to know you are certain that IOMMU is activated. Like I wrote before, GPU passthrough is pretty easy to set up in XCP 1.6 when used in conjunction with XenCenter. And by "pretty easy to set up in XCP 1.6 when used in conjunction with XenCenter," I mean select your GPU from a drop-down menu kind of easy. So you might want to back up your current system (or swap out your hard drive) and install XCP 1.6, in conjunction with XenCenter, as a test. If GPU passthrough doesn't work for you in XCP 1.6 (which relies on Xen 4.1), then you probably have some other hardware problems that you need to straighten out. One note: My system has UEFI, but I have found that things work much better when I force to boot into "comparability mode" at all times. So if you have UEFI, you might want to try that, regardless what dom0 you select. Best of luck! GizmoChicken On Thu, Mar 7, 2013 at 6:19 AM, Guilherme Suzuki wrote: > Gizmo, I've gone a little bit further than that. I managed to make things > (vga passthru) working, but that only works with freshly booted dom0. > > On Mar 7, 2013 6:57 AM, "Gizmo Chicken" wrote: > > Guilherme, > > Before moving further, let's verify: You do have IOMMU enabled in your > BIOS, correct? If not, you need to enable it to get GPU passthrough to > work. > > Now, back to XCP 1.6... > > XCP 1.6 is kind of a "black box" approach, in that you won't be able to > simply install it over your current dom0, but instead you must *replace*your current dom0. That said, XCP 1.6 is based on CentOS 5.7 (Linux > kernel v2.6.32.43). But be aware that XCP 1.6 won't give you a graphical > desktop on dom0. So if you need a graphical desktop on dom0, XCP 1.6 won't > be a long term solution for you. But given the ease of setting up GPU > passthrough with XCP, it could be relatively easy way for you to verify > that your system is capable of passthrough. > > Also, be aware that, although GPU passthrough is pretty simple with XPC > 1.6, strangely, *you'll have to do some digging on how to set up > PCI-passthrough so that your mouse/keyboard/device is accessible from a > guest VM.* It can be done, but the procedure isn't well-documented. > When (and if) you get XPC 1.6 installed and GPU passthrough working, write > back to me, and I'll try to help with the PCI passthrough. (One thing at a > time.) > > If you must have graphical desktop on dom0, then you have another option, > namely installing the *XCP-XAPI toolstack* (which is the toolstack used > by XCP 1.6) on a desktop version of Ubuntu. In my case, I have > successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop. > > If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 > desktop if you do), here are two reasonably complete tutorials: > > http://www.chimos.de/stuff/xen-xcp-ubuntu-manual/xen-xcp-ubuntu-manual.txt > > http://blog.scottlowe.org/2012/06/28/installing-xcp-xapi-on-ubuntu-server-12-04-lts/ > > Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots of > hacks and may be a bumpy process. So before you even try, I recommend that > you *first* experiment with XCP 1.6 (the "black box" approach) to see if > it works with your hardware and if XenCenter fits your needs. > > Hope the above help. > > GizmoChicken > > > > > > On Wed, Mar 6, 2013 at 3:06 PM, Guilherme Suzuki > wrote: > > > > Can you tell ... > > --f46d0444edf1d1add404d7560698 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Guilherme,

Okay.=A0 Good to know you are certain that IOMMU is activ= ated.

Like I wrote before, GPU passthrough is pretty easy to set up = in XCP 1.6 when used in conjunction with XenCenter.=A0 And by "pretty = easy to set up in XCP 1.6 when used in conjunction with XenCenter," I = mean select your GPU from a drop-down menu kind of easy.=A0 So you might wa= nt to back up your current system (or swap out your hard drive) and install= XCP 1.6, in conjunction with XenCenter, as a test.=A0 If GPU passthrough d= oesn't work for you in XCP 1.6 (which relies on Xen 4.1), then you prob= ably have some other hardware problems that you need to straighten out.

One note:=A0 My system has UEFI, but I have found that things work much= better when I force to boot into "comparability mode" at all tim= es.=A0 So if you have UEFI, you might want to try that, regardless what dom= 0 you select.

Best of luck!

GizmoChicken



On Thu, Mar 7, 2013 at 6:19 AM, Guilherme Suzuki <= ;suzuki.gui@gmail= .com> wrote:

Gizmo, I've gone a little bit further= than that. I managed to make things (vga passthru) working, but that only = works with freshly booted dom0.

On Mar 7, 2013 6:57 AM, = "Gizmo Chicken" <gizmochicken@gmail.com> wrote:

Guilherme,
<= br> Before moving further, let's verify:=A0 You do have IOMMU enabled in yo= ur BIOS, correct?=A0 If not, you need to enable it to get GPU passthrough t= o work.

Now, back to XCP 1.6...

XCP 1.6 is kind of a "black box" approach, in that you won't be = able to=20 simply install it over your current dom0, but instead you must replace your current dom0.=A0=A0 That said, XCP 1.6 is based on CentOS 5.7 (Linux= =20 kernel v2.6.32.43).=A0 But be aware that=A0 XCP 1.6 won't give you a=20 graphical desktop on dom0.=A0 So if you need a graphical desktop on dom0,= =20 XCP 1.6 won't be a long term solution for you.=A0 But given the ease of= =20 setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough.=A0

Also,= be=20 aware that, although GPU passthrough is pretty simple with XPC 1.6,=20 strangely, you'll have to do some digging on how to set up=20 PCI-passthrough so that your mouse/keyboard/device is accessible from a=20 guest VM.=A0 It can be done, but the procedure isn't well-documente= d.=A0 When (and if) you get XPC 1.6 installed and GPU passthrough working, = write back to me, and I'll try to help with the PCI passthrough.=A0 (On= e thing at a time.)

If you must have graphical desktop on dom0, then you have another option,=20 namely installing the XCP-XAPI toolstack (which is the toolstack use= d by XCP 1.6) on a desktop version of Ubuntu.=A0 In my case, I have=20 successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop.
<= br>If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials:

http://www.chimos.de/stuff/xen-xcp-ubuntu-manual= /xen-xcp-ubuntu-manual.txt
http://blog.scottlowe.org/2012/06/2= 8/installing-xcp-xapi-on-ubuntu-server-12-04-lts/

Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots=20 of hacks and may be a bumpy process.=A0 So before you even try, I recommend= that you first experiment with XCP 1.6 (the "black box" approach) to see if it works with = your=20 hardware and if XenCenter fits your needs.

Hope the above help.
<= br>GizmoChicken





On Wed, Mar 6, 2013 at 3:06 PM, G= uilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
> Can you tell ...


--f46d0444edf1d1add404d7560698-- --===============6251783255312281042== 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 --===============6251783255312281042==-- From xen-users-bounces@lists.xen.org Thu Mar 07 13:54:26 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 13:54: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 1UDbG3-0001M0-Nx; Thu, 07 Mar 2013 13:53:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDbG1-0001Lv-Mn for xen-users@lists.xen.org; Thu, 07 Mar 2013 13:53:18 +0000 Received: from [85.158.138.51:33805] by server-14.bemta-3.messagelabs.com id 55/FA-27076-8CB98315; Thu, 07 Mar 2013 13:53:12 +0000 X-Env-Sender: gizmochicken@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1362664389!21069259!1 X-Originating-IP: [209.85.219.44] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26665 invoked from network); 7 Mar 2013 13:53:10 -0000 Received: from mail-oa0-f44.google.com (HELO mail-oa0-f44.google.com) (209.85.219.44) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 13:53:10 -0000 Received: by mail-oa0-f44.google.com with SMTP id h1so577410oag.17 for ; Thu, 07 Mar 2013 05:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NXDTwO7ja509sgv2tuzJNuU1VbV+aKNz8lq6PYOT/bQ=; b=qoNJhHcSeh5hyFcczAMXAE13kjjHa9sX5IhW/XRm9TAD7Zcilx10oxCLCOBSXEJ5GV cSwIEtcKt8h3115xSqW6Bt1Qgd3GBEntTSaJ/K0kgI7hqTKReM5sdJdfxOIyN5V3yhE8 /NjYriswQMaRycIH8LN5XZ1czN1uNfGlyLsGgIvHV/b6esZvivHWSvQrtLybwk6Xk+gU UvUWelJ8NWZY80hTxOphjqIliCNk7Kh9hrFDS09VN3d2aB2xWIr+w5kWRoTsY/k6l+Sc M7nk2Ejpo+2GXdLKa7E0AkB6ASyzayFmekM1sHmqmLlBcXDG3ZfLRKywu2SQpwmiZJpi elyQ== MIME-Version: 1.0 X-Received: by 10.182.114.97 with SMTP id jf1mr26007940obb.31.1362664388404; Thu, 07 Mar 2013 05:53:08 -0800 (PST) Received: by 10.60.57.102 with HTTP; Thu, 7 Mar 2013 05:53:08 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Thu, 7 Mar 2013 08:53:08 -0500 Message-ID: From: Gizmo Chicken To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============6251783255312281042==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6251783255312281042== Content-Type: multipart/alternative; boundary=f46d0444edf1d1add404d7560698 --f46d0444edf1d1add404d7560698 Content-Type: text/plain; charset=ISO-8859-1 Guilherme, Okay. Good to know you are certain that IOMMU is activated. Like I wrote before, GPU passthrough is pretty easy to set up in XCP 1.6 when used in conjunction with XenCenter. And by "pretty easy to set up in XCP 1.6 when used in conjunction with XenCenter," I mean select your GPU from a drop-down menu kind of easy. So you might want to back up your current system (or swap out your hard drive) and install XCP 1.6, in conjunction with XenCenter, as a test. If GPU passthrough doesn't work for you in XCP 1.6 (which relies on Xen 4.1), then you probably have some other hardware problems that you need to straighten out. One note: My system has UEFI, but I have found that things work much better when I force to boot into "comparability mode" at all times. So if you have UEFI, you might want to try that, regardless what dom0 you select. Best of luck! GizmoChicken On Thu, Mar 7, 2013 at 6:19 AM, Guilherme Suzuki wrote: > Gizmo, I've gone a little bit further than that. I managed to make things > (vga passthru) working, but that only works with freshly booted dom0. > > On Mar 7, 2013 6:57 AM, "Gizmo Chicken" wrote: > > Guilherme, > > Before moving further, let's verify: You do have IOMMU enabled in your > BIOS, correct? If not, you need to enable it to get GPU passthrough to > work. > > Now, back to XCP 1.6... > > XCP 1.6 is kind of a "black box" approach, in that you won't be able to > simply install it over your current dom0, but instead you must *replace*your current dom0. That said, XCP 1.6 is based on CentOS 5.7 (Linux > kernel v2.6.32.43). But be aware that XCP 1.6 won't give you a graphical > desktop on dom0. So if you need a graphical desktop on dom0, XCP 1.6 won't > be a long term solution for you. But given the ease of setting up GPU > passthrough with XCP, it could be relatively easy way for you to verify > that your system is capable of passthrough. > > Also, be aware that, although GPU passthrough is pretty simple with XPC > 1.6, strangely, *you'll have to do some digging on how to set up > PCI-passthrough so that your mouse/keyboard/device is accessible from a > guest VM.* It can be done, but the procedure isn't well-documented. > When (and if) you get XPC 1.6 installed and GPU passthrough working, write > back to me, and I'll try to help with the PCI passthrough. (One thing at a > time.) > > If you must have graphical desktop on dom0, then you have another option, > namely installing the *XCP-XAPI toolstack* (which is the toolstack used > by XCP 1.6) on a desktop version of Ubuntu. In my case, I have > successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop. > > If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 > desktop if you do), here are two reasonably complete tutorials: > > http://www.chimos.de/stuff/xen-xcp-ubuntu-manual/xen-xcp-ubuntu-manual.txt > > http://blog.scottlowe.org/2012/06/28/installing-xcp-xapi-on-ubuntu-server-12-04-lts/ > > Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots of > hacks and may be a bumpy process. So before you even try, I recommend that > you *first* experiment with XCP 1.6 (the "black box" approach) to see if > it works with your hardware and if XenCenter fits your needs. > > Hope the above help. > > GizmoChicken > > > > > > On Wed, Mar 6, 2013 at 3:06 PM, Guilherme Suzuki > wrote: > > > > Can you tell ... > > --f46d0444edf1d1add404d7560698 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Guilherme,

Okay.=A0 Good to know you are certain that IOMMU is activ= ated.

Like I wrote before, GPU passthrough is pretty easy to set up = in XCP 1.6 when used in conjunction with XenCenter.=A0 And by "pretty = easy to set up in XCP 1.6 when used in conjunction with XenCenter," I = mean select your GPU from a drop-down menu kind of easy.=A0 So you might wa= nt to back up your current system (or swap out your hard drive) and install= XCP 1.6, in conjunction with XenCenter, as a test.=A0 If GPU passthrough d= oesn't work for you in XCP 1.6 (which relies on Xen 4.1), then you prob= ably have some other hardware problems that you need to straighten out.

One note:=A0 My system has UEFI, but I have found that things work much= better when I force to boot into "comparability mode" at all tim= es.=A0 So if you have UEFI, you might want to try that, regardless what dom= 0 you select.

Best of luck!

GizmoChicken



On Thu, Mar 7, 2013 at 6:19 AM, Guilherme Suzuki <= ;suzuki.gui@gmail= .com> wrote:

Gizmo, I've gone a little bit further= than that. I managed to make things (vga passthru) working, but that only = works with freshly booted dom0.

On Mar 7, 2013 6:57 AM, = "Gizmo Chicken" <gizmochicken@gmail.com> wrote:

Guilherme,
<= br> Before moving further, let's verify:=A0 You do have IOMMU enabled in yo= ur BIOS, correct?=A0 If not, you need to enable it to get GPU passthrough t= o work.

Now, back to XCP 1.6...

XCP 1.6 is kind of a "black box" approach, in that you won't be = able to=20 simply install it over your current dom0, but instead you must replace your current dom0.=A0=A0 That said, XCP 1.6 is based on CentOS 5.7 (Linux= =20 kernel v2.6.32.43).=A0 But be aware that=A0 XCP 1.6 won't give you a=20 graphical desktop on dom0.=A0 So if you need a graphical desktop on dom0,= =20 XCP 1.6 won't be a long term solution for you.=A0 But given the ease of= =20 setting up GPU passthrough with XCP, it could be relatively easy way for you to verify that your system is capable of passthrough.=A0

Also,= be=20 aware that, although GPU passthrough is pretty simple with XPC 1.6,=20 strangely, you'll have to do some digging on how to set up=20 PCI-passthrough so that your mouse/keyboard/device is accessible from a=20 guest VM.=A0 It can be done, but the procedure isn't well-documente= d.=A0 When (and if) you get XPC 1.6 installed and GPU passthrough working, = write back to me, and I'll try to help with the PCI passthrough.=A0 (On= e thing at a time.)

If you must have graphical desktop on dom0, then you have another option,=20 namely installing the XCP-XAPI toolstack (which is the toolstack use= d by XCP 1.6) on a desktop version of Ubuntu.=A0 In my case, I have=20 successfully installed the XCP-XAPI toolstack on Ubuntu 12.10 desktop.
<= br>If you want to try XCP-XAPI toolstack on Ubuntu (I recommend Ubuntu 12.10 desktop if you do), here are two reasonably complete tutorials:

http://www.chimos.de/stuff/xen-xcp-ubuntu-manual= /xen-xcp-ubuntu-manual.txt
http://blog.scottlowe.org/2012/06/2= 8/installing-xcp-xapi-on-ubuntu-server-12-04-lts/

Be aware that installing the XCP-XAPI toolstack on Ubuntu requires lots=20 of hacks and may be a bumpy process.=A0 So before you even try, I recommend= that you first experiment with XCP 1.6 (the "black box" approach) to see if it works with = your=20 hardware and if XenCenter fits your needs.

Hope the above help.
<= br>GizmoChicken





On Wed, Mar 6, 2013 at 3:06 PM, G= uilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
> Can you tell ...


--f46d0444edf1d1add404d7560698-- --===============6251783255312281042== 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 --===============6251783255312281042==-- From xen-users-bounces@lists.xen.org Thu Mar 07 14:28:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 14:28: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 1UDbnI-0002nH-8j; Thu, 07 Mar 2013 14:27:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDbnH-0002n5-8y for xen-users@lists.xen.org; Thu, 07 Mar 2013 14:27:39 +0000 Received: from [85.158.143.99:14230] by server-2.bemta-4.messagelabs.com id 3B/AE-12656-AD3A8315; Thu, 07 Mar 2013 14:27:38 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1362666451!27404638!1 X-Originating-IP: [209.85.210.170] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15389 invoked from network); 7 Mar 2013 14:27:33 -0000 Received: from mail-ia0-f170.google.com (HELO mail-ia0-f170.google.com) (209.85.210.170) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 14:27:33 -0000 Received: by mail-ia0-f170.google.com with SMTP id h8so460548iaa.29 for ; Thu, 07 Mar 2013 06:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Gb6LC6CLcHYy6AhK7pZMWHGWevEG+jR2oOBmv9KQCkY=; b=gWMT4WKUKE7a2GZHUwNN/XBjQL2Qts2Sch7F3p2tsptGx3YYCZS8CJ/QbKcKXE1sbD 4U0S/QhdE7kBeXTD/VuTR1kw+KYy+pEMWE9aJJMRTGI0XEHp20/n8O19dggXv/KfnTT0 wMcWk2QsNg+LxpS54Ta4RfZ+sf6jekFQAWvHidAeqUUOkGhVZ4u7kr+H4e93t7DCRopy AVQhkWx7F8n5AWQ3sNxPL6hOWIn8ykJ9aF4SXpmYDeR6VirEt7vFrY3w2HAq6lsM9ziB MNA8szQxYAbZyUEK/nwQKWX9ApX0aisgztsUw1NH34hyQZyLPfKanwB6dsOQaDOXmXcq 38lw== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr14479790igc.91.1362666448807; Thu, 07 Mar 2013 06:27:28 -0800 (PST) Received: by 10.64.170.65 with HTTP; Thu, 7 Mar 2013 06:27:28 -0800 (PST) Received: by 10.64.170.65 with HTTP; Thu, 7 Mar 2013 06:27:28 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Thu, 7 Mar 2013 11:27:28 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============0103315878080226481==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0103315878080226481== Content-Type: multipart/alternative; boundary=14dae9340345a0ef3504d7568112 --14dae9340345a0ef3504d7568112 Content-Type: text/plain; charset=ISO-8859-1 Unfortuntely, XCP is not so easy to install on Fedora. One thing I noticed: kernel 3.8.1 has some improvements regarding Power Management and Reset functions as well. I'll head this way (downloading kernel, set it and installing). Current version my dom0 is running: 3.6-10. Thx for the help On Mar 7, 2013 10:53 AM, "Gizmo Chicken" wrote: Guilherme, Okay. Good to know you are certain that IOMMU is activated. Like I wrote before, GPU passthrough is pretty easy to set up in XCP 1.6 when used in conjunction with XenCenter. And by "pretty easy to set up in XCP 1.6 when used in conjunction with XenCenter," I mean select your GPU from a drop-down menu kind of easy. So you might want to back up your current system (or swap out your hard drive) and install XCP 1.6, in conjunction with XenCenter, as a test. If GPU passthrough doesn't work for you in XCP 1.6 (which relies on Xen 4.1), then you probably have some other hardware problems that you need to straighten out. One note: My system has UEFI, but I have found that things work much better when I force to boot into "comparability mode" at all times. So if you have UEFI, you might want to try that, regardless what dom0 you select. Best of luck! GizmoChicken On Thu, Mar 7, 2013 at 6:19 AM, Guilherme Suzuki wrote: > > Gizmo, I've g... --14dae9340345a0ef3504d7568112 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Unfortuntely, XCP is not so easy to install on Fedora.

One thing I noticed: kernel 3.8.1 has some improvements regarding Power = Management and Reset functions as well. I'll head this way (downloading= kernel, set it and installing).

Current version my dom0 is running: 3.6-10.

Thx for the help

On Mar 7, 2013 10:53 AM, "Gizmo Chicken&q= uot; <gizmochicken@gmail.com> wrote:

Guilherme,

Okay.=A0 Good to know you are certai= n that IOMMU is activated.

Like I wrote before, GPU passthrough is pretty easy to set up in XCP 1.= 6 when used in conjunction with XenCenter.=A0 And by "pretty easy to s= et up in XCP 1.6 when used in conjunction with XenCenter," I mean sele= ct your GPU from a drop-down menu kind of easy.=A0 So you might want to bac= k up your current system (or swap out your hard drive) and install XCP 1.6,= in conjunction with XenCenter, as a test.=A0 If GPU passthrough doesn'= t work for you in XCP 1.6 (which relies on Xen 4.1), then you probably have= some other hardware problems that you need to straighten out.

One note:=A0 My system has UEFI, but I have found that things work much= better when I force to boot into "comparability mode" at all tim= es.=A0 So if you have UEFI, you might want to try that, regardless what dom= 0 you select.

Best of luck!

GizmoChicken




On Thu, Mar 7, 2013 at 6:19 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
> = Gizmo, I've g...

--14dae9340345a0ef3504d7568112-- --===============0103315878080226481== 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 --===============0103315878080226481==-- From xen-users-bounces@lists.xen.org Thu Mar 07 14:28:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 14:28: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 1UDbnI-0002nH-8j; Thu, 07 Mar 2013 14:27:40 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDbnH-0002n5-8y for xen-users@lists.xen.org; Thu, 07 Mar 2013 14:27:39 +0000 Received: from [85.158.143.99:14230] by server-2.bemta-4.messagelabs.com id 3B/AE-12656-AD3A8315; Thu, 07 Mar 2013 14:27:38 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1362666451!27404638!1 X-Originating-IP: [209.85.210.170] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15389 invoked from network); 7 Mar 2013 14:27:33 -0000 Received: from mail-ia0-f170.google.com (HELO mail-ia0-f170.google.com) (209.85.210.170) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 14:27:33 -0000 Received: by mail-ia0-f170.google.com with SMTP id h8so460548iaa.29 for ; Thu, 07 Mar 2013 06:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Gb6LC6CLcHYy6AhK7pZMWHGWevEG+jR2oOBmv9KQCkY=; b=gWMT4WKUKE7a2GZHUwNN/XBjQL2Qts2Sch7F3p2tsptGx3YYCZS8CJ/QbKcKXE1sbD 4U0S/QhdE7kBeXTD/VuTR1kw+KYy+pEMWE9aJJMRTGI0XEHp20/n8O19dggXv/KfnTT0 wMcWk2QsNg+LxpS54Ta4RfZ+sf6jekFQAWvHidAeqUUOkGhVZ4u7kr+H4e93t7DCRopy AVQhkWx7F8n5AWQ3sNxPL6hOWIn8ykJ9aF4SXpmYDeR6VirEt7vFrY3w2HAq6lsM9ziB MNA8szQxYAbZyUEK/nwQKWX9ApX0aisgztsUw1NH34hyQZyLPfKanwB6dsOQaDOXmXcq 38lw== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr14479790igc.91.1362666448807; Thu, 07 Mar 2013 06:27:28 -0800 (PST) Received: by 10.64.170.65 with HTTP; Thu, 7 Mar 2013 06:27:28 -0800 (PST) Received: by 10.64.170.65 with HTTP; Thu, 7 Mar 2013 06:27:28 -0800 (PST) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Thu, 7 Mar 2013 11:27:28 -0300 Message-ID: From: Guilherme Suzuki To: Gizmo Chicken Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============0103315878080226481==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0103315878080226481== Content-Type: multipart/alternative; boundary=14dae9340345a0ef3504d7568112 --14dae9340345a0ef3504d7568112 Content-Type: text/plain; charset=ISO-8859-1 Unfortuntely, XCP is not so easy to install on Fedora. One thing I noticed: kernel 3.8.1 has some improvements regarding Power Management and Reset functions as well. I'll head this way (downloading kernel, set it and installing). Current version my dom0 is running: 3.6-10. Thx for the help On Mar 7, 2013 10:53 AM, "Gizmo Chicken" wrote: Guilherme, Okay. Good to know you are certain that IOMMU is activated. Like I wrote before, GPU passthrough is pretty easy to set up in XCP 1.6 when used in conjunction with XenCenter. And by "pretty easy to set up in XCP 1.6 when used in conjunction with XenCenter," I mean select your GPU from a drop-down menu kind of easy. So you might want to back up your current system (or swap out your hard drive) and install XCP 1.6, in conjunction with XenCenter, as a test. If GPU passthrough doesn't work for you in XCP 1.6 (which relies on Xen 4.1), then you probably have some other hardware problems that you need to straighten out. One note: My system has UEFI, but I have found that things work much better when I force to boot into "comparability mode" at all times. So if you have UEFI, you might want to try that, regardless what dom0 you select. Best of luck! GizmoChicken On Thu, Mar 7, 2013 at 6:19 AM, Guilherme Suzuki wrote: > > Gizmo, I've g... --14dae9340345a0ef3504d7568112 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Unfortuntely, XCP is not so easy to install on Fedora.

One thing I noticed: kernel 3.8.1 has some improvements regarding Power = Management and Reset functions as well. I'll head this way (downloading= kernel, set it and installing).

Current version my dom0 is running: 3.6-10.

Thx for the help

On Mar 7, 2013 10:53 AM, "Gizmo Chicken&q= uot; <gizmochicken@gmail.com> wrote:

Guilherme,

Okay.=A0 Good to know you are certai= n that IOMMU is activated.

Like I wrote before, GPU passthrough is pretty easy to set up in XCP 1.= 6 when used in conjunction with XenCenter.=A0 And by "pretty easy to s= et up in XCP 1.6 when used in conjunction with XenCenter," I mean sele= ct your GPU from a drop-down menu kind of easy.=A0 So you might want to bac= k up your current system (or swap out your hard drive) and install XCP 1.6,= in conjunction with XenCenter, as a test.=A0 If GPU passthrough doesn'= t work for you in XCP 1.6 (which relies on Xen 4.1), then you probably have= some other hardware problems that you need to straighten out.

One note:=A0 My system has UEFI, but I have found that things work much= better when I force to boot into "comparability mode" at all tim= es.=A0 So if you have UEFI, you might want to try that, regardless what dom= 0 you select.

Best of luck!

GizmoChicken




On Thu, Mar 7, 2013 at 6:19 AM, Guilherme Suzuki <suzuki.gui@gmail.com> wrote:
>
> = Gizmo, I've g...

--14dae9340345a0ef3504d7568112-- --===============0103315878080226481== 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 --===============0103315878080226481==-- From xen-users-bounces@lists.xen.org Thu Mar 07 17:36:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 17:36: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 1UDeiO-0001US-CG; Thu, 07 Mar 2013 17:34:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDeiL-0001U9-RF for xen-users@lists.xen.org; Thu, 07 Mar 2013 17:34:46 +0000 Received: from [85.158.139.83:42716] by server-2.bemta-5.messagelabs.com id 9C/BF-23989-5BFC8315; Thu, 07 Mar 2013 17:34:45 +0000 X-Env-Sender: sdiris@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1362677683!23759172!1 X-Originating-IP: [74.125.82.41] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10468 invoked from network); 7 Mar 2013 17:34:44 -0000 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 17:34:44 -0000 Received: by mail-wg0-f41.google.com with SMTP id ds1so7114536wgb.0 for ; Thu, 07 Mar 2013 09:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=7PFtTmVPUXY1vU7WdfDgQvPnUPk+kYeYNo6srdXarvc=; b=TFjwp+xQC3mganomVUfvjUB7YNp/B4FJcZo+VJ9UqOp9ZDWkVvjYXTIc2owamdeAg/ onZMv/EFpu9Rxy0DvuF3rS715X4xE2P+ShSwuwWpL6BYnbJ7SPUkIJP3pgG2czSPTLvE TQKCfLU+YSRseQY38ZzXOS3W2e+Xz0iFN642UwZ31Zawo5VDgPCF3wOOluEdIGOq0sQQ Zlfxr1EN6s2bxaVqUF/Ddu8z07QRRiIVSV1Y8sFn1IWGXr0snqcYP2u+LH5GgSiHaFed Sw9BdNs12LzGwzEvKYR5INbbAjKHxdeegQxsjuMRKbohcv2POPSd2Wfni1D1jhVIMmbS ZHng== X-Received: by 10.180.73.238 with SMTP id o14mr34894638wiv.32.1362677683586; Thu, 07 Mar 2013 09:34:43 -0800 (PST) Received: from yimingwin7 (c142.al.cl.cam.ac.uk. [128.232.110.142]) by mx.google.com with ESMTPS id n2sm34465535wiy.6.2013.03.07.09.34.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Mar 2013 09:34:42 -0800 (PST) From: "Yiming Zhang" To: Date: Thu, 7 Mar 2013 17:34:44 -0000 Message-ID: <001f01ce1b5a$0f711980$2e534c80$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4bVOU4O4TVJR/9QxmzZjo8tFwf1w== Content-Language: zh-cn Subject: [Xen-users] qdisk and blktap X-BeenThere: xen-users@lists.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="===============6785447883465519447==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multipart message in MIME format. --===============6785447883465519447== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CE1B5A.0F71DCD0" Content-Language: zh-cn This is a multipart message in MIME format. ------=_NextPart_000_0020_01CE1B5A.0F71DCD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, I am studying mini-os with Xen-4.2.1 on Ubuntu 12.04 (Precise 64, Kernel Linux 3.2). I configure the domain_config file by adding an entry: disk = [ 'file: disk-minios.img, hda, r' ]. When I start mini-os (using "xl create -c domain-config"), a test thread reads sectors in an infinite loop, which makes mini-os and dom0 not able to response anymore. I think it should not be a bug of mini-os. I noticed: (1) when I started xend using "/etc/init.d/xencommons start", it says "Starting QEMU as disk backend for dom0". (2) mini-os reports "backend at /local/domain/0/backend/qdisk/1/768" and "Failed to read /local/domain/0/backend/qdisk/1/768 /feature-flush-cache". I suspect it is because qdisk (the backend of blk driver) performs too bad (and doesn't support feature-flush-cache). So I want to use blktap as the backend driver. Can anyone tell me how to do this on Ubuntu 12.04? Thanks a lot! Yiming ------=_NextPart_000_0020_01CE1B5A.0F71DCD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = All,

 

I am studying mini-os with Xen-4.2.1 on Ubuntu 12.04 = (Precise 64, Kernel Linux 3.2). I configure the domain_config file by = adding an entry: disk =3D [ ‘file: disk-minios.img, hda, r’ = ]. When I start mini-os (using “xl create -c = domain-config”), a test thread reads sectors in an infinite loop, = which makes mini-os and dom0 not able to response anymore. =

 

I think it should not be a bug of mini-os. I = noticed:

(1) when I started xend using “/etc/init.d/xencommons = start”, it says “Starting QEMU as disk backend for = dom0”.

(2) mini-os reports “backend at = /local/domain/0/backend/qdisk/1/768” and “Failed to read = /local/domain/0/backend/qdisk/1/768 = /feature-flush-cache”.

 

I suspect it is because qdisk (the = backend of blk driver) performs too bad (and doesn’t support = feature-flush-cache). So I want to use blktap as the backend driver. Can = anyone tell me how to do this on Ubuntu 12.04?

 

Thanks a = lot!

Yiming

 

------=_NextPart_000_0020_01CE1B5A.0F71DCD0-- --===============6785447883465519447== 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 --===============6785447883465519447==-- From xen-users-bounces@lists.xen.org Thu Mar 07 17:36:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 17:36: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 1UDeiO-0001US-CG; Thu, 07 Mar 2013 17:34:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDeiL-0001U9-RF for xen-users@lists.xen.org; Thu, 07 Mar 2013 17:34:46 +0000 Received: from [85.158.139.83:42716] by server-2.bemta-5.messagelabs.com id 9C/BF-23989-5BFC8315; Thu, 07 Mar 2013 17:34:45 +0000 X-Env-Sender: sdiris@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1362677683!23759172!1 X-Originating-IP: [74.125.82.41] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10468 invoked from network); 7 Mar 2013 17:34:44 -0000 Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com) (74.125.82.41) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 17:34:44 -0000 Received: by mail-wg0-f41.google.com with SMTP id ds1so7114536wgb.0 for ; Thu, 07 Mar 2013 09:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=7PFtTmVPUXY1vU7WdfDgQvPnUPk+kYeYNo6srdXarvc=; b=TFjwp+xQC3mganomVUfvjUB7YNp/B4FJcZo+VJ9UqOp9ZDWkVvjYXTIc2owamdeAg/ onZMv/EFpu9Rxy0DvuF3rS715X4xE2P+ShSwuwWpL6BYnbJ7SPUkIJP3pgG2czSPTLvE TQKCfLU+YSRseQY38ZzXOS3W2e+Xz0iFN642UwZ31Zawo5VDgPCF3wOOluEdIGOq0sQQ Zlfxr1EN6s2bxaVqUF/Ddu8z07QRRiIVSV1Y8sFn1IWGXr0snqcYP2u+LH5GgSiHaFed Sw9BdNs12LzGwzEvKYR5INbbAjKHxdeegQxsjuMRKbohcv2POPSd2Wfni1D1jhVIMmbS ZHng== X-Received: by 10.180.73.238 with SMTP id o14mr34894638wiv.32.1362677683586; Thu, 07 Mar 2013 09:34:43 -0800 (PST) Received: from yimingwin7 (c142.al.cl.cam.ac.uk. [128.232.110.142]) by mx.google.com with ESMTPS id n2sm34465535wiy.6.2013.03.07.09.34.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Mar 2013 09:34:42 -0800 (PST) From: "Yiming Zhang" To: Date: Thu, 7 Mar 2013 17:34:44 -0000 Message-ID: <001f01ce1b5a$0f711980$2e534c80$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4bVOU4O4TVJR/9QxmzZjo8tFwf1w== Content-Language: zh-cn Subject: [Xen-users] qdisk and blktap X-BeenThere: xen-users@lists.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="===============6785447883465519447==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multipart message in MIME format. --===============6785447883465519447== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CE1B5A.0F71DCD0" Content-Language: zh-cn This is a multipart message in MIME format. ------=_NextPart_000_0020_01CE1B5A.0F71DCD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, I am studying mini-os with Xen-4.2.1 on Ubuntu 12.04 (Precise 64, Kernel Linux 3.2). I configure the domain_config file by adding an entry: disk = [ 'file: disk-minios.img, hda, r' ]. When I start mini-os (using "xl create -c domain-config"), a test thread reads sectors in an infinite loop, which makes mini-os and dom0 not able to response anymore. I think it should not be a bug of mini-os. I noticed: (1) when I started xend using "/etc/init.d/xencommons start", it says "Starting QEMU as disk backend for dom0". (2) mini-os reports "backend at /local/domain/0/backend/qdisk/1/768" and "Failed to read /local/domain/0/backend/qdisk/1/768 /feature-flush-cache". I suspect it is because qdisk (the backend of blk driver) performs too bad (and doesn't support feature-flush-cache). So I want to use blktap as the backend driver. Can anyone tell me how to do this on Ubuntu 12.04? Thanks a lot! Yiming ------=_NextPart_000_0020_01CE1B5A.0F71DCD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = All,

 

I am studying mini-os with Xen-4.2.1 on Ubuntu 12.04 = (Precise 64, Kernel Linux 3.2). I configure the domain_config file by = adding an entry: disk =3D [ ‘file: disk-minios.img, hda, r’ = ]. When I start mini-os (using “xl create -c = domain-config”), a test thread reads sectors in an infinite loop, = which makes mini-os and dom0 not able to response anymore. =

 

I think it should not be a bug of mini-os. I = noticed:

(1) when I started xend using “/etc/init.d/xencommons = start”, it says “Starting QEMU as disk backend for = dom0”.

(2) mini-os reports “backend at = /local/domain/0/backend/qdisk/1/768” and “Failed to read = /local/domain/0/backend/qdisk/1/768 = /feature-flush-cache”.

 

I suspect it is because qdisk (the = backend of blk driver) performs too bad (and doesn’t support = feature-flush-cache). So I want to use blktap as the backend driver. Can = anyone tell me how to do this on Ubuntu 12.04?

 

Thanks a = lot!

Yiming

 

------=_NextPart_000_0020_01CE1B5A.0F71DCD0-- --===============6785447883465519447== 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 --===============6785447883465519447==-- From xen-users-bounces@lists.xen.org Thu Mar 07 19:06:54 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 19:06: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 1UDg8P-0003KD-6k; Thu, 07 Mar 2013 19:05:45 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDg8N-0003K5-LG for xen-users@lists.xen.org; Thu, 07 Mar 2013 19:05:43 +0000 Received: from [85.158.139.211:52311] by server-9.bemta-5.messagelabs.com id 82/69-08547-605E8315; Thu, 07 Mar 2013 19:05:42 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-11.tower-206.messagelabs.com!1362683142!18099781!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTMzMw==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21567 invoked from network); 7 Mar 2013 19:05:42 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-11.tower-206.messagelabs.com with SMTP; 7 Mar 2013 19:05:42 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:53652) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UDg8M-0003Vr-6y (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Thu, 07 Mar 2013 19:05:42 +0000 Message-ID: <5138E4E6.9080001@cam.ac.uk> Date: Thu, 07 Mar 2013 19:05:10 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" Subject: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 all, I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU. in order to prepare the devices for passthrough I've used xl pci-assignable-add 83:00.0 xl pci-assignable-add 83:00.1 Where I've identified the device pci ids using lspci. This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager. Installing the ATI drivers however has meant that on further boots the machine never gets past the windows logo in the VNC window and no output is generated from the ATI card. It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software. Has anybody else experienced similar issues or have any advice as to how to get this to work? I'm a bit stumped and the wiki implies that this should 'just work'. Thank you in advance for any help. Matt Here is my machine config ########################################################### builder='hvm' memory = 2048 name = 'Windows7Test' vcpus=4 pae=1 acpi=1 apic=1 disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] pci = [ '83:00.0' , '83:00.1' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'destroy' boot='cd' sdl=0 vnc=1 vncconsole=0 vncpasswd='' vnclisten='172.24.226.84' stdvga=0 serial='pty' usbdevice='tablet' gfx_passthru=0 pci_power_mgmt=1 xen_platform_pci=1 pci_msitranslate=1 viridian=1 hpet=1 ############################################################ And the vm produces the following qemu log in /var/log/xen/ ############################################################ domid: 4 -videoram option does not work with cirrus vga device model. Videoram set to 4M. Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio') Using file /xen-guests/img/windows7Test.img in read-write mode Watching /local/domain/0/device-model/4/logdirty/cmd Watching /local/domain/0/device-model/4/command Watching /local/domain/4/cpu char device redirected to /dev/pts/3 qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 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/4/xen_extended_power_mgmt): read error 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. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 xs_read(/local/domain/4/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/4/log-throttling' medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 83:00.0 ... register_real_device: Enable MSI translation via per device option register_real_device: Enable power management pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c) pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004) pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001) pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000) pt_msi_setup: msi mapped with pirq 67 pci_intx: intx=1 register_real_device: Real physical device 83:00.0 registered successfuly! IRQ type = MSI-INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 83:00.1 ... register_real_device: Enable MSI translation via per device option register_real_device: Enable power management pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004) pt_msi_setup: msi mapped with pirq 66 pci_intx: intx=2 register_real_device: Real physical device 83:00.1 registered successfuly! IRQ type = MSI-INTx pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1 cirrus vga map change while on lfb mode pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1 pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1 pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1 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. pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0 pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0 pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0 pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0 pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0 pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0 pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation pci_intx: intx=1 pt_msi_disable: Unmap msi with pirq 67 pt_msgctrl_reg_write: setup msi for dev 20 pt_msi_setup: msi mapped with pirq 67 pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0 ###################################################################### _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 07 19:06:54 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 19:06: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 1UDg8P-0003KD-6k; Thu, 07 Mar 2013 19:05:45 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDg8N-0003K5-LG for xen-users@lists.xen.org; Thu, 07 Mar 2013 19:05:43 +0000 Received: from [85.158.139.211:52311] by server-9.bemta-5.messagelabs.com id 82/69-08547-605E8315; Thu, 07 Mar 2013 19:05:42 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-11.tower-206.messagelabs.com!1362683142!18099781!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTMzMw==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21567 invoked from network); 7 Mar 2013 19:05:42 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-11.tower-206.messagelabs.com with SMTP; 7 Mar 2013 19:05:42 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:53652) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UDg8M-0003Vr-6y (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Thu, 07 Mar 2013 19:05:42 +0000 Message-ID: <5138E4E6.9080001@cam.ac.uk> Date: Thu, 07 Mar 2013 19:05:10 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" Subject: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 all, I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU. in order to prepare the devices for passthrough I've used xl pci-assignable-add 83:00.0 xl pci-assignable-add 83:00.1 Where I've identified the device pci ids using lspci. This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager. Installing the ATI drivers however has meant that on further boots the machine never gets past the windows logo in the VNC window and no output is generated from the ATI card. It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software. Has anybody else experienced similar issues or have any advice as to how to get this to work? I'm a bit stumped and the wiki implies that this should 'just work'. Thank you in advance for any help. Matt Here is my machine config ########################################################### builder='hvm' memory = 2048 name = 'Windows7Test' vcpus=4 pae=1 acpi=1 apic=1 disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] pci = [ '83:00.0' , '83:00.1' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'destroy' boot='cd' sdl=0 vnc=1 vncconsole=0 vncpasswd='' vnclisten='172.24.226.84' stdvga=0 serial='pty' usbdevice='tablet' gfx_passthru=0 pci_power_mgmt=1 xen_platform_pci=1 pci_msitranslate=1 viridian=1 hpet=1 ############################################################ And the vm produces the following qemu log in /var/log/xen/ ############################################################ domid: 4 -videoram option does not work with cirrus vga device model. Videoram set to 4M. Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio') Using file /xen-guests/img/windows7Test.img in read-write mode Watching /local/domain/0/device-model/4/logdirty/cmd Watching /local/domain/0/device-model/4/command Watching /local/domain/4/cpu char device redirected to /dev/pts/3 qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 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/4/xen_extended_power_mgmt): read error 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. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 xs_read(/local/domain/4/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/4/log-throttling' medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 83:00.0 ... register_real_device: Enable MSI translation via per device option register_real_device: Enable power management pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c) pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004) pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001) pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000) pt_msi_setup: msi mapped with pirq 67 pci_intx: intx=1 register_real_device: Real physical device 83:00.0 registered successfuly! IRQ type = MSI-INTx dm-command: hot insert pass-through pci dev register_real_device: Assigning real physical device 83:00.1 ... register_real_device: Enable MSI translation via per device option register_real_device: Enable power management pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004) pt_msi_setup: msi mapped with pirq 66 pci_intx: intx=2 register_real_device: Real physical device 83:00.1 registered successfuly! IRQ type = MSI-INTx pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1 cirrus vga map change while on lfb mode pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1 pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1 pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1 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. pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4] pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0 pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0 pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0 pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0 pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0 pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0 pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0 pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation pci_intx: intx=1 pt_msi_disable: Unmap msi with pirq 67 pt_msgctrl_reg_write: setup msi for dev 20 pt_msi_setup: msi mapped with pirq 67 pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0 pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0 ###################################################################### _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 07 21:39:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 21:39: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 1UDiVx-0004eB-7w; Thu, 07 Mar 2013 21:38:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiVu-0004e6-Uc for xen-users@lists.xen.org; Thu, 07 Mar 2013 21:38:11 +0000 Received: from [85.158.138.51:19262] by server-11.bemta-3.messagelabs.com id 0F/E8-01263-DB809315; Thu, 07 Mar 2013 21:38:05 +0000 X-Env-Sender: falck.andreas.lists@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1362692283!27623693!1 X-Originating-IP: [209.85.217.178] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_10_20,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3943 invoked from network); 7 Mar 2013 21:38:04 -0000 Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com) (209.85.217.178) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 21:38:04 -0000 Received: by mail-lb0-f178.google.com with SMTP id n1so837730lba.9 for ; Thu, 07 Mar 2013 13:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JH2e3jPIsgIr+0RnKunPHZbhw4A+XGQ4dH50/7aYGfU=; b=Gwg2KU+2tXaEJFaEvfEZVG8b7XDyvcwZHXz4fEaxA7IkWmqgyt1R4/k+eOEjOBST2c RKAJHAECUX0Qmxh4k+FlLgIC+D4ePuCLp8nfrsediCIPTGujivxDk8ZkCyeDw24meBHB pTURapdeTQOPhj6qW5qFN9lYWWkKuGtzy/3nIkLZtMIMUZ6quXhRqPPIirkZF7p+qlHB kB7uteoKi0OFcwRapo7aBPQ8m3n7cFt2/skGvcu8d4hf6mnc9vVQxofTPdDCtY+ntIdT CSHgrr1dPDkOPbXtUtb8CpkQzTBaXD0U1ixYWcUMtSJwq5ylQEL6KbgD2SuhGgD5d+Y5 Z3Vw== MIME-Version: 1.0 X-Received: by 10.112.83.67 with SMTP id o3mr163096lby.7.1362692283366; Thu, 07 Mar 2013 13:38:03 -0800 (PST) Received: by 10.114.21.230 with HTTP; Thu, 7 Mar 2013 13:38:03 -0800 (PST) In-Reply-To: <5138E4E6.9080001@cam.ac.uk> References: <5138E4E6.9080001@cam.ac.uk> Date: Thu, 7 Mar 2013 22:38:03 +0100 Message-ID: From: Andreas Falck To: Matthew Dean Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============5429896856164073015==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5429896856164073015== Content-Type: multipart/alternative; boundary=14dae9d2f2b67d08ef04d75c856b --14dae9d2f2b67d08ef04d75c856b Content-Type: text/plain; charset=ISO-8859-1 Hi, I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course. Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something). Regards, Andreas 2013/3/7 Matthew Dean > Hi all, > > I've managed to get a windows 7 x64 hvm to boot and install and I'm now > looking to pass through a HD 7970 as a secondary GPU. in order to prepare > the devices for passthrough I've used > > xl pci-assignable-add 83:00.0 > xl pci-assignable-add 83:00.1 > > Where I've identified the device pci ids using lspci. This works fine and > the devices appear when I call 'xl pci-assignable-list'. After adding them > to the vm config (see below) I was able to get the vm to boot and the > devices appeared in device manager. Installing the ATI drivers however has > meant that on further boots the machine never gets past the windows logo > in the VNC window and no output is generated from the ATI card. It simply > freezes there and the only way I can get back into windows is via safe > mode, even after uninstalling the ATI software. > > Has anybody else experienced similar issues or have any advice as to how > to get this to work? I'm a bit stumped and the wiki implies that this > should 'just work'. > > Thank you in advance for any help. > > Matt > > Here is my machine config > > ##############################**############################# > > builder='hvm' > memory = 2048 > name = 'Windows7Test' > > vcpus=4 > pae=1 > acpi=1 > apic=1 > > disk = [ 'file:/xen-guests/img/**windows7Test.img,hda,w' ] > pci = [ '83:00.0' , '83:00.1' ] > > on_poweroff = 'destroy' > on_reboot = 'restart' > on_crash = 'destroy' > > boot='cd' > > sdl=0 > vnc=1 > vncconsole=0 > vncpasswd='' > vnclisten='172.24.226.84' > > stdvga=0 > > serial='pty' > usbdevice='tablet' > > gfx_passthru=0 > pci_power_mgmt=1 > xen_platform_pci=1 > pci_msitranslate=1 > viridian=1 > hpet=1 > > ##############################**############################## > > And the vm produces the following qemu log in /var/log/xen/ > > ##############################**############################## > > domid: 4 > -videoram option does not work with cirrus vga device model. Videoram set > to 4M. > Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.**img > (drv 'aio') > Using file /xen-guests/img/windows7Test.**img in read-write mode > Watching /local/domain/0/device-model/**4/logdirty/cmd > Watching /local/domain/0/device-model/**4/command > Watching /local/domain/4/cpu > char device redirected to /dev/pts/3 > qemu_map_cache_init nr_buckets = 10000 size 4194304 > shared page at pfn feffd > buffered io page at pfn feffb > Guest uuid = e09f5a51-7de1-4d92-9cec-**826b9d66aeb6 > 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/4/xen_extended_**power_mgmt): read > error > 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. > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 > xs_read(/local/domain/4/log-**throttling): read error > qemu: ignoring not-understood drive `/local/domain/4/log-**throttling' > medium change watch on `/local/domain/4/log-**throttling' - unknown > device, ignored > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device 83:00.0 ... > register_real_device: Enable MSI translation via per device option > register_real_device: Enable power management > pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No > such file or directory: 0x83:0x0.0x0 > pt_register_regions: IO region registered (size=0x10000000 > base_addr=0xe000000c) > pt_register_regions: IO region registered (size=0x00040000 > base_addr=0xf0000004) > pt_register_regions: IO region registered (size=0x00000100 > base_addr=0x0000f001) > pt_register_regions: Expansion ROM registered (size=0x00020000 > base_addr=0xf0040000) > pt_msi_setup: msi mapped with pirq 67 > pci_intx: intx=1 > register_real_device: Real physical device 83:00.0 registered successfuly! > IRQ type = MSI-INTx > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device 83:00.1 ... > register_real_device: Enable MSI translation via per device option > register_real_device: Enable power management > pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No > such file or directory: 0x83:0x0.0x1 > pt_register_regions: IO region registered (size=0x00004000 > base_addr=0xf0060004) > pt_msi_setup: msi mapped with pirq 66 > pci_intx: intx=2 > register_real_device: Real physical device 83:00.1 registered successfuly! > IRQ type = MSI-INTx > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 > first_map=1 > cirrus vga map change while on lfb mode > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 > first_map=1 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 > first_map=1 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1 > 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. > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 > first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 > first_map=0 > pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 > first_map=0 > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 > first_map=0 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 > first_map=0 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 > first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 > first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 > first_map=0 > pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 > first_map=0 > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 > first_map=0 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 > pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation > pci_intx: intx=1 > pt_msi_disable: Unmap msi with pirq 67 > pt_msgctrl_reg_write: setup msi for dev 20 > pt_msi_setup: msi mapped with pirq 67 > pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f > pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 > first_map=0 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 > first_map=0 > > ##############################**##############################**########## > > ______________________________**_________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --14dae9d2f2b67d08ef04d75c856b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I believe that the Windows logo freezing in the vnc window is no= rmal behaviour when secondary GPU passthrough is working as it should, sinc= e the display should be handed over to the GPU. At least that was the case = before when I was passing through a HD6850 card as secondary to win7 using = xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that = some users have reported problems with the latest one (13-something).
Regards,
Andreas

2013/3/7 Matthew De= an <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm= now looking to pass through a HD 7970 as a secondary GPU. =A0in order to p= repare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci. =A0This works fin= e and the devices appear when I call 'xl pci-assignable-list'. Afte= r adding them to the vm config (see below) I was able to get the vm to boot= and the devices appeared in device manager. =A0Installing the ATI drivers = however has meant that on further boots the =A0machine never gets past the = windows logo in the VNC window and no output is generated from the ATI card= . =A0It simply freezes there and the only way I can get back into windows i= s via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to= get this to work? =A0I'm a bit stumped and the wiki implies that this = should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder=3D'hvm'
memory =3D 2048
name =3D 'Windows7Test'

vcpus=3D4
pae=3D1
acpi=3D1
apic=3D1

disk =3D [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] pci =3D [ '83:00.0' , '83:00.1' ]

on_poweroff =3D 'destroy'
on_reboot =A0 =3D 'restart'
on_crash =A0 =A0=3D 'destroy'

boot=3D'cd'

sdl=3D0
vnc=3D1
vncconsole=3D0
vncpasswd=3D''
vnclisten=3D'172.24.226.84'

stdvga=3D0

serial=3D'pty'
usbdevice=3D'tablet'

gfx_passthru=3D0
pci_power_mgmt=3D1
xen_platform_pci=3D1
pci_msitranslate=3D1
viridian=3D1
hpet=3D1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set t= o 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img= (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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 st= ate.
xs_read(/local/domain/0/device-model/4/xen_extended_power_mgm= t): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling&= #39;
medium change watch on `/local/domain/4/log-throttling' - unknow= n device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=3D0x10000000 base_addr=3D0x= e000000c)
pt_register_regions: IO region registered (size=3D0x00040000 base_addr=3D0x= f0000004)
pt_register_regions: IO region registered (size=3D0x00000100 base_addr=3D0x= 0000f001)
pt_register_regions: Expansion ROM registered (size=3D0x00020000 base_addr= =3D0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=3D1
register_real_device: Real physical device 83:00.0 registered successfuly!<= br> IRQ type =3D MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=3D0x00004000 base_addr=3D0x= f0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=3D2
register_real_device: Real physical device 83:00.1 registered successfuly!<= br> IRQ type =3D MSI-INTx
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D1
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D1
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st= ate.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro st= ate.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=3D1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0

#############################################################= #########

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

--14dae9d2f2b67d08ef04d75c856b-- --===============5429896856164073015== 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 --===============5429896856164073015==-- From xen-users-bounces@lists.xen.org Thu Mar 07 21:39:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 21:39: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 1UDiVx-0004eB-7w; Thu, 07 Mar 2013 21:38:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiVu-0004e6-Uc for xen-users@lists.xen.org; Thu, 07 Mar 2013 21:38:11 +0000 Received: from [85.158.138.51:19262] by server-11.bemta-3.messagelabs.com id 0F/E8-01263-DB809315; Thu, 07 Mar 2013 21:38:05 +0000 X-Env-Sender: falck.andreas.lists@gmail.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1362692283!27623693!1 X-Originating-IP: [209.85.217.178] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_10_20,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3943 invoked from network); 7 Mar 2013 21:38:04 -0000 Received: from mail-lb0-f178.google.com (HELO mail-lb0-f178.google.com) (209.85.217.178) by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 21:38:04 -0000 Received: by mail-lb0-f178.google.com with SMTP id n1so837730lba.9 for ; Thu, 07 Mar 2013 13:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JH2e3jPIsgIr+0RnKunPHZbhw4A+XGQ4dH50/7aYGfU=; b=Gwg2KU+2tXaEJFaEvfEZVG8b7XDyvcwZHXz4fEaxA7IkWmqgyt1R4/k+eOEjOBST2c RKAJHAECUX0Qmxh4k+FlLgIC+D4ePuCLp8nfrsediCIPTGujivxDk8ZkCyeDw24meBHB pTURapdeTQOPhj6qW5qFN9lYWWkKuGtzy/3nIkLZtMIMUZ6quXhRqPPIirkZF7p+qlHB kB7uteoKi0OFcwRapo7aBPQ8m3n7cFt2/skGvcu8d4hf6mnc9vVQxofTPdDCtY+ntIdT CSHgrr1dPDkOPbXtUtb8CpkQzTBaXD0U1ixYWcUMtSJwq5ylQEL6KbgD2SuhGgD5d+Y5 Z3Vw== MIME-Version: 1.0 X-Received: by 10.112.83.67 with SMTP id o3mr163096lby.7.1362692283366; Thu, 07 Mar 2013 13:38:03 -0800 (PST) Received: by 10.114.21.230 with HTTP; Thu, 7 Mar 2013 13:38:03 -0800 (PST) In-Reply-To: <5138E4E6.9080001@cam.ac.uk> References: <5138E4E6.9080001@cam.ac.uk> Date: Thu, 7 Mar 2013 22:38:03 +0100 Message-ID: From: Andreas Falck To: Matthew Dean Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============5429896856164073015==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5429896856164073015== Content-Type: multipart/alternative; boundary=14dae9d2f2b67d08ef04d75c856b --14dae9d2f2b67d08ef04d75c856b Content-Type: text/plain; charset=ISO-8859-1 Hi, I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course. Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something). Regards, Andreas 2013/3/7 Matthew Dean > Hi all, > > I've managed to get a windows 7 x64 hvm to boot and install and I'm now > looking to pass through a HD 7970 as a secondary GPU. in order to prepare > the devices for passthrough I've used > > xl pci-assignable-add 83:00.0 > xl pci-assignable-add 83:00.1 > > Where I've identified the device pci ids using lspci. This works fine and > the devices appear when I call 'xl pci-assignable-list'. After adding them > to the vm config (see below) I was able to get the vm to boot and the > devices appeared in device manager. Installing the ATI drivers however has > meant that on further boots the machine never gets past the windows logo > in the VNC window and no output is generated from the ATI card. It simply > freezes there and the only way I can get back into windows is via safe > mode, even after uninstalling the ATI software. > > Has anybody else experienced similar issues or have any advice as to how > to get this to work? I'm a bit stumped and the wiki implies that this > should 'just work'. > > Thank you in advance for any help. > > Matt > > Here is my machine config > > ##############################**############################# > > builder='hvm' > memory = 2048 > name = 'Windows7Test' > > vcpus=4 > pae=1 > acpi=1 > apic=1 > > disk = [ 'file:/xen-guests/img/**windows7Test.img,hda,w' ] > pci = [ '83:00.0' , '83:00.1' ] > > on_poweroff = 'destroy' > on_reboot = 'restart' > on_crash = 'destroy' > > boot='cd' > > sdl=0 > vnc=1 > vncconsole=0 > vncpasswd='' > vnclisten='172.24.226.84' > > stdvga=0 > > serial='pty' > usbdevice='tablet' > > gfx_passthru=0 > pci_power_mgmt=1 > xen_platform_pci=1 > pci_msitranslate=1 > viridian=1 > hpet=1 > > ##############################**############################## > > And the vm produces the following qemu log in /var/log/xen/ > > ##############################**############################## > > domid: 4 > -videoram option does not work with cirrus vga device model. Videoram set > to 4M. > Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.**img > (drv 'aio') > Using file /xen-guests/img/windows7Test.**img in read-write mode > Watching /local/domain/0/device-model/**4/logdirty/cmd > Watching /local/domain/0/device-model/**4/command > Watching /local/domain/4/cpu > char device redirected to /dev/pts/3 > qemu_map_cache_init nr_buckets = 10000 size 4194304 > shared page at pfn feffd > buffered io page at pfn feffb > Guest uuid = e09f5a51-7de1-4d92-9cec-**826b9d66aeb6 > 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/4/xen_extended_**power_mgmt): read > error > 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. > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 > xs_read(/local/domain/4/log-**throttling): read error > qemu: ignoring not-understood drive `/local/domain/4/log-**throttling' > medium change watch on `/local/domain/4/log-**throttling' - unknown > device, ignored > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device 83:00.0 ... > register_real_device: Enable MSI translation via per device option > register_real_device: Enable power management > pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No > such file or directory: 0x83:0x0.0x0 > pt_register_regions: IO region registered (size=0x10000000 > base_addr=0xe000000c) > pt_register_regions: IO region registered (size=0x00040000 > base_addr=0xf0000004) > pt_register_regions: IO region registered (size=0x00000100 > base_addr=0x0000f001) > pt_register_regions: Expansion ROM registered (size=0x00020000 > base_addr=0xf0040000) > pt_msi_setup: msi mapped with pirq 67 > pci_intx: intx=1 > register_real_device: Real physical device 83:00.0 registered successfuly! > IRQ type = MSI-INTx > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device 83:00.1 ... > register_real_device: Enable MSI translation via per device option > register_real_device: Enable power management > pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No > such file or directory: 0x83:0x0.0x1 > pt_register_regions: IO region registered (size=0x00004000 > base_addr=0xf0060004) > pt_msi_setup: msi mapped with pirq 66 > pci_intx: intx=2 > register_real_device: Real physical device 83:00.1 registered successfuly! > IRQ type = MSI-INTx > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 > first_map=1 > cirrus vga map change while on lfb mode > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 > first_map=1 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 > first_map=1 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1 > 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. > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid > access size alignment. [Offset:0eh][Length:4] > pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 > first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 > first_map=0 > pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 > first_map=0 > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 > first_map=0 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 > first_map=0 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 > first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 > first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 > first_map=0 > pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 > first_map=0 > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 > first_map=0 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 > pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation > pci_intx: intx=1 > pt_msi_disable: Unmap msi with pirq 67 > pt_msgctrl_reg_write: setup msi for dev 20 > pt_msi_setup: msi mapped with pirq 67 > pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f > pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 > first_map=0 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 > first_map=0 > > ##############################**##############################**########## > > ______________________________**_________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --14dae9d2f2b67d08ef04d75c856b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I believe that the Windows logo freezing in the vnc window is no= rmal behaviour when secondary GPU passthrough is working as it should, sinc= e the display should be handed over to the GPU. At least that was the case = before when I was passing through a HD6850 card as secondary to win7 using = xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that = some users have reported problems with the latest one (13-something).
Regards,
Andreas

2013/3/7 Matthew De= an <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm= now looking to pass through a HD 7970 as a secondary GPU. =A0in order to p= repare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci. =A0This works fin= e and the devices appear when I call 'xl pci-assignable-list'. Afte= r adding them to the vm config (see below) I was able to get the vm to boot= and the devices appeared in device manager. =A0Installing the ATI drivers = however has meant that on further boots the =A0machine never gets past the = windows logo in the VNC window and no output is generated from the ATI card= . =A0It simply freezes there and the only way I can get back into windows i= s via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to= get this to work? =A0I'm a bit stumped and the wiki implies that this = should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder=3D'hvm'
memory =3D 2048
name =3D 'Windows7Test'

vcpus=3D4
pae=3D1
acpi=3D1
apic=3D1

disk =3D [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] pci =3D [ '83:00.0' , '83:00.1' ]

on_poweroff =3D 'destroy'
on_reboot =A0 =3D 'restart'
on_crash =A0 =A0=3D 'destroy'

boot=3D'cd'

sdl=3D0
vnc=3D1
vncconsole=3D0
vncpasswd=3D''
vnclisten=3D'172.24.226.84'

stdvga=3D0

serial=3D'pty'
usbdevice=3D'tablet'

gfx_passthru=3D0
pci_power_mgmt=3D1
xen_platform_pci=3D1
pci_msitranslate=3D1
viridian=3D1
hpet=3D1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set t= o 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img= (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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 st= ate.
xs_read(/local/domain/0/device-model/4/xen_extended_power_mgm= t): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling&= #39;
medium change watch on `/local/domain/4/log-throttling' - unknow= n device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=3D0x10000000 base_addr=3D0x= e000000c)
pt_register_regions: IO region registered (size=3D0x00040000 base_addr=3D0x= f0000004)
pt_register_regions: IO region registered (size=3D0x00000100 base_addr=3D0x= 0000f001)
pt_register_regions: Expansion ROM registered (size=3D0x00020000 base_addr= =3D0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=3D1
register_real_device: Real physical device 83:00.0 registered successfuly!<= br> IRQ type =3D MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=3D0x00004000 base_addr=3D0x= f0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=3D2
register_real_device: Real physical device 83:00.1 registered successfuly!<= br> IRQ type =3D MSI-INTx
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D1
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D1
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st= ate.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro st= ate.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=3D1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0

#############################################################= #########

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

--14dae9d2f2b67d08ef04d75c856b-- --===============5429896856164073015== 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 --===============5429896856164073015==-- From xen-users-bounces@lists.xen.org Thu Mar 07 21:42:34 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 21:42: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 1UDiZ8-0004o7-6h; Thu, 07 Mar 2013 21:41:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiZ6-0004o1-Sk for xen-users@lists.xen.org; Thu, 07 Mar 2013 21:41:29 +0000 Received: from [85.158.138.51:26402] by server-16.bemta-3.messagelabs.com id 49/A0-20692-38909315; Thu, 07 Mar 2013 21:41:23 +0000 X-Env-Sender: theubaz@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1362692479!21136286!1 X-Originating-IP: [209.85.220.44] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_10_20,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2488 invoked from network); 7 Mar 2013 21:41:20 -0000 Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 21:41:20 -0000 Received: by mail-pa0-f44.google.com with SMTP id kp1so771154pab.3 for ; Thu, 07 Mar 2013 13:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nm/KBTjhzK+wDIod2vjXKWwP0yNkqEYyU/2jfHRP2eI=; b=xsuC6SzkZ8Dfb0NoCP8R/FcdSJOfkQKjBZD1y/D6EcdJqqZkNQ/23U27QKFiDKBllp 1HzMzi1E68X68Ru/2OmPRJi60AuLMdnc6uooanv3vr4x5NaPpJ4/HGtdhqoldyo/brUe 3i+O5uZNUxlTcvURggcJBZcHkVXvHQOmre2cVrSggWL6xTk4UH4Ey3zm3G0Gujcmrxb+ bb1ToBHReAIpt0HLpub1c0HiRz93R7gHvZKxhRN4QxORI0+uPmIicTDlt2KwpiTOh6k7 bxg3oVukKUOyeybK3C8Tm9+YtpSQRVL/RrBGTFvN7NKcHVoDxZI75DAUieTkaTo/jYBn aCGg== MIME-Version: 1.0 X-Received: by 10.66.5.161 with SMTP id t1mr389492pat.206.1362692478542; Thu, 07 Mar 2013 13:41:18 -0800 (PST) Received: by 10.70.34.71 with HTTP; Thu, 7 Mar 2013 13:41:18 -0800 (PST) In-Reply-To: References: <5138E4E6.9080001@cam.ac.uk> Date: Thu, 7 Mar 2013 13:41:18 -0800 X-Google-Sender-Auth: jv6TKarRqKsk1sQWyYYzUKcdgRQ Message-ID: From: John Sherwood To: Andreas Falck Cc: "xen-users@lists.xen.org" , Matthew Dean Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============2364112663480021026==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2364112663480021026== Content-Type: multipart/alternative; boundary=bcaec520e6ab1f29ef04d75c9172 --bcaec520e6ab1f29ef04d75c9172 Content-Type: text/plain; charset=ISO-8859-1 Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well. On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck wrote: > Hi, > > I believe that the Windows logo freezing in the vnc window is normal > behaviour when secondary GPU passthrough is working as it should, since the > display should be handed over to the GPU. At least that was the case before > when I was passing through a HD6850 card as secondary to win7 using xl. But > you should expect output on the GPU, of course. > > Have you tried different versions of the catalyst driver? I think that > some users have reported problems with the latest one (13-something). > > Regards, > Andreas > > 2013/3/7 Matthew Dean > >> Hi all, >> >> I've managed to get a windows 7 x64 hvm to boot and install and I'm now >> looking to pass through a HD 7970 as a secondary GPU. in order to prepare >> the devices for passthrough I've used >> >> xl pci-assignable-add 83:00.0 >> xl pci-assignable-add 83:00.1 >> >> Where I've identified the device pci ids using lspci. This works fine >> and the devices appear when I call 'xl pci-assignable-list'. After adding >> them to the vm config (see below) I was able to get the vm to boot and the >> devices appeared in device manager. Installing the ATI drivers however has >> meant that on further boots the machine never gets past the windows logo >> in the VNC window and no output is generated from the ATI card. It simply >> freezes there and the only way I can get back into windows is via safe >> mode, even after uninstalling the ATI software. >> >> Has anybody else experienced similar issues or have any advice as to how >> to get this to work? I'm a bit stumped and the wiki implies that this >> should 'just work'. >> >> Thank you in advance for any help. >> >> Matt >> >> Here is my machine config >> >> ##############################**############################# >> >> builder='hvm' >> memory = 2048 >> name = 'Windows7Test' >> >> vcpus=4 >> pae=1 >> acpi=1 >> apic=1 >> >> disk = [ 'file:/xen-guests/img/**windows7Test.img,hda,w' ] >> pci = [ '83:00.0' , '83:00.1' ] >> >> on_poweroff = 'destroy' >> on_reboot = 'restart' >> on_crash = 'destroy' >> >> boot='cd' >> >> sdl=0 >> vnc=1 >> vncconsole=0 >> vncpasswd='' >> vnclisten='172.24.226.84' >> >> stdvga=0 >> >> serial='pty' >> usbdevice='tablet' >> >> gfx_passthru=0 >> pci_power_mgmt=1 >> xen_platform_pci=1 >> pci_msitranslate=1 >> viridian=1 >> hpet=1 >> >> ##############################**############################## >> >> And the vm produces the following qemu log in /var/log/xen/ >> >> ##############################**############################## >> >> domid: 4 >> -videoram option does not work with cirrus vga device model. Videoram set >> to 4M. >> Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.**img >> (drv 'aio') >> Using file /xen-guests/img/windows7Test.**img in read-write mode >> Watching /local/domain/0/device-model/**4/logdirty/cmd >> Watching /local/domain/0/device-model/**4/command >> Watching /local/domain/4/cpu >> char device redirected to /dev/pts/3 >> qemu_map_cache_init nr_buckets = 10000 size 4194304 >> shared page at pfn feffd >> buffered io page at pfn feffb >> Guest uuid = e09f5a51-7de1-4d92-9cec-**826b9d66aeb6 >> 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/4/xen_extended_**power_mgmt): >> read error >> 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. >> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 >> xs_read(/local/domain/4/log-**throttling): read error >> qemu: ignoring not-understood drive `/local/domain/4/log-**throttling' >> medium change watch on `/local/domain/4/log-**throttling' - unknown >> device, ignored >> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 >> dm-command: hot insert pass-through pci dev >> register_real_device: Assigning real physical device 83:00.0 ... >> register_real_device: Enable MSI translation via per device option >> register_real_device: Enable power management >> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: >> No such file or directory: 0x83:0x0.0x0 >> pt_register_regions: IO region registered (size=0x10000000 >> base_addr=0xe000000c) >> pt_register_regions: IO region registered (size=0x00040000 >> base_addr=0xf0000004) >> pt_register_regions: IO region registered (size=0x00000100 >> base_addr=0x0000f001) >> pt_register_regions: Expansion ROM registered (size=0x00020000 >> base_addr=0xf0040000) >> pt_msi_setup: msi mapped with pirq 67 >> pci_intx: intx=1 >> register_real_device: Real physical device 83:00.0 registered successfuly! >> IRQ type = MSI-INTx >> dm-command: hot insert pass-through pci dev >> register_real_device: Assigning real physical device 83:00.1 ... >> register_real_device: Enable MSI translation via per device option >> register_real_device: Enable power management >> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: >> No such file or directory: 0x83:0x0.0x1 >> pt_register_regions: IO region registered (size=0x00004000 >> base_addr=0xf0060004) >> pt_msi_setup: msi mapped with pirq 66 >> pci_intx: intx=2 >> register_real_device: Real physical device 83:00.1 registered successfuly! >> IRQ type = MSI-INTx >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 >> first_map=1 >> cirrus vga map change while on lfb mode >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >> first_map=1 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >> first_map=1 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1 >> 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. >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 >> first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 >> first_map=0 >> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 >> first_map=0 >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >> first_map=0 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 >> first_map=0 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >> first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 >> first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 >> first_map=0 >> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 >> first_map=0 >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >> first_map=0 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 >> pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation >> pci_intx: intx=1 >> pt_msi_disable: Unmap msi with pirq 67 >> pt_msgctrl_reg_write: setup msi for dev 20 >> pt_msi_setup: msi mapped with pirq 67 >> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 >> first_map=0 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >> first_map=0 >> >> ##############################**##############################** >> ########## >> >> ______________________________**_________________ >> 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 > --bcaec520e6ab1f29ef04d75c9172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Having the windows logo freeze in the VNC window has been my experience wit= h GPU passthrough as well.

On Thu, Mar 7,= 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com= > wrote:
Hi,

I believe that the Windows logo f= reezing in the vnc window is normal behaviour when secondary GPU passthroug= h is working as it should, since the display should be handed over to the G= PU. At least that was the case before when I was passing through a HD6850 c= ard as secondary to win7 using xl. But you should expect output on the GPU,= of course.

Have you tried different versions of the catalyst driver? I think that = some users have reported problems with the latest one (13-something).
Regards,
Andreas

2013/3/7 Matthew De= an <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm= now looking to pass through a HD 7970 as a secondary GPU. =A0in order to p= repare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci. =A0This works fin= e and the devices appear when I call 'xl pci-assignable-list'. Afte= r adding them to the vm config (see below) I was able to get the vm to boot= and the devices appeared in device manager. =A0Installing the ATI drivers = however has meant that on further boots the =A0machine never gets past the = windows logo in the VNC window and no output is generated from the ATI card= . =A0It simply freezes there and the only way I can get back into windows i= s via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to= get this to work? =A0I'm a bit stumped and the wiki implies that this = should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder=3D'hvm'
memory =3D 2048
name =3D 'Windows7Test'

vcpus=3D4
pae=3D1
acpi=3D1
apic=3D1

disk =3D [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] pci =3D [ '83:00.0' , '83:00.1' ]

on_poweroff =3D 'destroy'
on_reboot =A0 =3D 'restart'
on_crash =A0 =A0=3D 'destroy'

boot=3D'cd'

sdl=3D0
vnc=3D1
vncconsole=3D0
vncpasswd=3D''
vnclisten=3D'172.24.226.84'

stdvga=3D0

serial=3D'pty'
usbdevice=3D'tablet'

gfx_passthru=3D0
pci_power_mgmt=3D1
xen_platform_pci=3D1
pci_msitranslate=3D1
viridian=3D1
hpet=3D1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set t= o 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img= (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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 st= ate.
xs_read(/local/domain/0/device-model/4/xen_extended_power_mgm= t): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling&= #39;
medium change watch on `/local/domain/4/log-throttling' - unknow= n device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=3D0x10000000 base_addr=3D0x= e000000c)
pt_register_regions: IO region registered (size=3D0x00040000 base_addr=3D0x= f0000004)
pt_register_regions: IO region registered (size=3D0x00000100 base_addr=3D0x= 0000f001)
pt_register_regions: Expansion ROM registered (size=3D0x00020000 base_addr= =3D0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=3D1
register_real_device: Real physical device 83:00.0 registered successfuly!<= br> IRQ type =3D MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=3D0x00004000 base_addr=3D0x= f0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=3D2
register_real_device: Real physical device 83:00.1 registered successfuly!<= br> IRQ type =3D MSI-INTx
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D1
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D1
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st= ate.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro st= ate.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=3D1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0

#############################################################= #########

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--bcaec520e6ab1f29ef04d75c9172-- --===============2364112663480021026== 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 --===============2364112663480021026==-- From xen-users-bounces@lists.xen.org Thu Mar 07 21:42:34 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 21:42: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 1UDiZ8-0004o7-6h; Thu, 07 Mar 2013 21:41:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiZ6-0004o1-Sk for xen-users@lists.xen.org; Thu, 07 Mar 2013 21:41:29 +0000 Received: from [85.158.138.51:26402] by server-16.bemta-3.messagelabs.com id 49/A0-20692-38909315; Thu, 07 Mar 2013 21:41:23 +0000 X-Env-Sender: theubaz@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1362692479!21136286!1 X-Originating-IP: [209.85.220.44] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_10_20,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2488 invoked from network); 7 Mar 2013 21:41:20 -0000 Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 21:41:20 -0000 Received: by mail-pa0-f44.google.com with SMTP id kp1so771154pab.3 for ; Thu, 07 Mar 2013 13:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nm/KBTjhzK+wDIod2vjXKWwP0yNkqEYyU/2jfHRP2eI=; b=xsuC6SzkZ8Dfb0NoCP8R/FcdSJOfkQKjBZD1y/D6EcdJqqZkNQ/23U27QKFiDKBllp 1HzMzi1E68X68Ru/2OmPRJi60AuLMdnc6uooanv3vr4x5NaPpJ4/HGtdhqoldyo/brUe 3i+O5uZNUxlTcvURggcJBZcHkVXvHQOmre2cVrSggWL6xTk4UH4Ey3zm3G0Gujcmrxb+ bb1ToBHReAIpt0HLpub1c0HiRz93R7gHvZKxhRN4QxORI0+uPmIicTDlt2KwpiTOh6k7 bxg3oVukKUOyeybK3C8Tm9+YtpSQRVL/RrBGTFvN7NKcHVoDxZI75DAUieTkaTo/jYBn aCGg== MIME-Version: 1.0 X-Received: by 10.66.5.161 with SMTP id t1mr389492pat.206.1362692478542; Thu, 07 Mar 2013 13:41:18 -0800 (PST) Received: by 10.70.34.71 with HTTP; Thu, 7 Mar 2013 13:41:18 -0800 (PST) In-Reply-To: References: <5138E4E6.9080001@cam.ac.uk> Date: Thu, 7 Mar 2013 13:41:18 -0800 X-Google-Sender-Auth: jv6TKarRqKsk1sQWyYYzUKcdgRQ Message-ID: From: John Sherwood To: Andreas Falck Cc: "xen-users@lists.xen.org" , Matthew Dean Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============2364112663480021026==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2364112663480021026== Content-Type: multipart/alternative; boundary=bcaec520e6ab1f29ef04d75c9172 --bcaec520e6ab1f29ef04d75c9172 Content-Type: text/plain; charset=ISO-8859-1 Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well. On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck wrote: > Hi, > > I believe that the Windows logo freezing in the vnc window is normal > behaviour when secondary GPU passthrough is working as it should, since the > display should be handed over to the GPU. At least that was the case before > when I was passing through a HD6850 card as secondary to win7 using xl. But > you should expect output on the GPU, of course. > > Have you tried different versions of the catalyst driver? I think that > some users have reported problems with the latest one (13-something). > > Regards, > Andreas > > 2013/3/7 Matthew Dean > >> Hi all, >> >> I've managed to get a windows 7 x64 hvm to boot and install and I'm now >> looking to pass through a HD 7970 as a secondary GPU. in order to prepare >> the devices for passthrough I've used >> >> xl pci-assignable-add 83:00.0 >> xl pci-assignable-add 83:00.1 >> >> Where I've identified the device pci ids using lspci. This works fine >> and the devices appear when I call 'xl pci-assignable-list'. After adding >> them to the vm config (see below) I was able to get the vm to boot and the >> devices appeared in device manager. Installing the ATI drivers however has >> meant that on further boots the machine never gets past the windows logo >> in the VNC window and no output is generated from the ATI card. It simply >> freezes there and the only way I can get back into windows is via safe >> mode, even after uninstalling the ATI software. >> >> Has anybody else experienced similar issues or have any advice as to how >> to get this to work? I'm a bit stumped and the wiki implies that this >> should 'just work'. >> >> Thank you in advance for any help. >> >> Matt >> >> Here is my machine config >> >> ##############################**############################# >> >> builder='hvm' >> memory = 2048 >> name = 'Windows7Test' >> >> vcpus=4 >> pae=1 >> acpi=1 >> apic=1 >> >> disk = [ 'file:/xen-guests/img/**windows7Test.img,hda,w' ] >> pci = [ '83:00.0' , '83:00.1' ] >> >> on_poweroff = 'destroy' >> on_reboot = 'restart' >> on_crash = 'destroy' >> >> boot='cd' >> >> sdl=0 >> vnc=1 >> vncconsole=0 >> vncpasswd='' >> vnclisten='172.24.226.84' >> >> stdvga=0 >> >> serial='pty' >> usbdevice='tablet' >> >> gfx_passthru=0 >> pci_power_mgmt=1 >> xen_platform_pci=1 >> pci_msitranslate=1 >> viridian=1 >> hpet=1 >> >> ##############################**############################## >> >> And the vm produces the following qemu log in /var/log/xen/ >> >> ##############################**############################## >> >> domid: 4 >> -videoram option does not work with cirrus vga device model. Videoram set >> to 4M. >> Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.**img >> (drv 'aio') >> Using file /xen-guests/img/windows7Test.**img in read-write mode >> Watching /local/domain/0/device-model/**4/logdirty/cmd >> Watching /local/domain/0/device-model/**4/command >> Watching /local/domain/4/cpu >> char device redirected to /dev/pts/3 >> qemu_map_cache_init nr_buckets = 10000 size 4194304 >> shared page at pfn feffd >> buffered io page at pfn feffb >> Guest uuid = e09f5a51-7de1-4d92-9cec-**826b9d66aeb6 >> 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/4/xen_extended_**power_mgmt): >> read error >> 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. >> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 >> xs_read(/local/domain/4/log-**throttling): read error >> qemu: ignoring not-understood drive `/local/domain/4/log-**throttling' >> medium change watch on `/local/domain/4/log-**throttling' - unknown >> device, ignored >> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 >> dm-command: hot insert pass-through pci dev >> register_real_device: Assigning real physical device 83:00.0 ... >> register_real_device: Enable MSI translation via per device option >> register_real_device: Enable power management >> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: >> No such file or directory: 0x83:0x0.0x0 >> pt_register_regions: IO region registered (size=0x10000000 >> base_addr=0xe000000c) >> pt_register_regions: IO region registered (size=0x00040000 >> base_addr=0xf0000004) >> pt_register_regions: IO region registered (size=0x00000100 >> base_addr=0x0000f001) >> pt_register_regions: Expansion ROM registered (size=0x00020000 >> base_addr=0xf0040000) >> pt_msi_setup: msi mapped with pirq 67 >> pci_intx: intx=1 >> register_real_device: Real physical device 83:00.0 registered successfuly! >> IRQ type = MSI-INTx >> dm-command: hot insert pass-through pci dev >> register_real_device: Assigning real physical device 83:00.1 ... >> register_real_device: Enable MSI translation via per device option >> register_real_device: Enable power management >> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: >> No such file or directory: 0x83:0x0.0x1 >> pt_register_regions: IO region registered (size=0x00004000 >> base_addr=0xf0060004) >> pt_msi_setup: msi mapped with pirq 66 >> pci_intx: intx=2 >> register_real_device: Real physical device 83:00.1 registered successfuly! >> IRQ type = MSI-INTx >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 >> first_map=1 >> cirrus vga map change while on lfb mode >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >> first_map=1 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >> first_map=1 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1 >> 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. >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid >> access size alignment. [Offset:0eh][Length:4] >> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 >> first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 >> first_map=0 >> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 >> first_map=0 >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >> first_map=0 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 >> first_map=0 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >> first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 >> first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 >> first_map=0 >> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 >> first_map=0 >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >> first_map=0 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 >> pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation >> pci_intx: intx=1 >> pt_msi_disable: Unmap msi with pirq 67 >> pt_msgctrl_reg_write: setup msi for dev 20 >> pt_msi_setup: msi mapped with pirq 67 >> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 >> first_map=0 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >> first_map=0 >> >> ##############################**##############################** >> ########## >> >> ______________________________**_________________ >> 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 > --bcaec520e6ab1f29ef04d75c9172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Having the windows logo freeze in the VNC window has been my experience wit= h GPU passthrough as well.

On Thu, Mar 7,= 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com= > wrote:
Hi,

I believe that the Windows logo f= reezing in the vnc window is normal behaviour when secondary GPU passthroug= h is working as it should, since the display should be handed over to the G= PU. At least that was the case before when I was passing through a HD6850 c= ard as secondary to win7 using xl. But you should expect output on the GPU,= of course.

Have you tried different versions of the catalyst driver? I think that = some users have reported problems with the latest one (13-something).
Regards,
Andreas

2013/3/7 Matthew De= an <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm= now looking to pass through a HD 7970 as a secondary GPU. =A0in order to p= repare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci. =A0This works fin= e and the devices appear when I call 'xl pci-assignable-list'. Afte= r adding them to the vm config (see below) I was able to get the vm to boot= and the devices appeared in device manager. =A0Installing the ATI drivers = however has meant that on further boots the =A0machine never gets past the = windows logo in the VNC window and no output is generated from the ATI card= . =A0It simply freezes there and the only way I can get back into windows i= s via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to= get this to work? =A0I'm a bit stumped and the wiki implies that this = should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder=3D'hvm'
memory =3D 2048
name =3D 'Windows7Test'

vcpus=3D4
pae=3D1
acpi=3D1
apic=3D1

disk =3D [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] pci =3D [ '83:00.0' , '83:00.1' ]

on_poweroff =3D 'destroy'
on_reboot =A0 =3D 'restart'
on_crash =A0 =A0=3D 'destroy'

boot=3D'cd'

sdl=3D0
vnc=3D1
vncconsole=3D0
vncpasswd=3D''
vnclisten=3D'172.24.226.84'

stdvga=3D0

serial=3D'pty'
usbdevice=3D'tablet'

gfx_passthru=3D0
pci_power_mgmt=3D1
xen_platform_pci=3D1
pci_msitranslate=3D1
viridian=3D1
hpet=3D1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set t= o 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img= (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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 st= ate.
xs_read(/local/domain/0/device-model/4/xen_extended_power_mgm= t): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling&= #39;
medium change watch on `/local/domain/4/log-throttling' - unknow= n device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=3D0x10000000 base_addr=3D0x= e000000c)
pt_register_regions: IO region registered (size=3D0x00040000 base_addr=3D0x= f0000004)
pt_register_regions: IO region registered (size=3D0x00000100 base_addr=3D0x= 0000f001)
pt_register_regions: Expansion ROM registered (size=3D0x00020000 base_addr= =3D0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=3D1
register_real_device: Real physical device 83:00.0 registered successfuly!<= br> IRQ type =3D MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=3D0x00004000 base_addr=3D0x= f0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=3D2
register_real_device: Real physical device 83:00.1 registered successfuly!<= br> IRQ type =3D MSI-INTx
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D1
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D1
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st= ate.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro st= ate.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=3D1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0

#############################################################= #########

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--bcaec520e6ab1f29ef04d75c9172-- --===============2364112663480021026== 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 --===============2364112663480021026==-- From xen-users-bounces@lists.xen.org Thu Mar 07 21:42:35 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 21:42: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 1UDiZF-0004ob-SI; Thu, 07 Mar 2013 21:41:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiZE-0004oM-2j for xen-users@lists.xen.org; Thu, 07 Mar 2013 21:41:36 +0000 Received: from [193.109.254.147:44415] by server-3.bemta-14.messagelabs.com id F1/01-17488-F8909315; Thu, 07 Mar 2013 21:41:35 +0000 X-Env-Sender: tarundua@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1362692491!9000810!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13834 invoked from network); 7 Mar 2013 21:41:32 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 21:41:32 -0000 Received: by mail-we0-f173.google.com with SMTP id x51so217259wey.18 for ; Thu, 07 Mar 2013 13:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=7OpINj+mxj2QyRMgQv2qN4d8MD+ZqanpdYW4Y824TfA=; b=0qWMGFOIlsYiQcNVrWCHw/Tm3w9rwvjZtM7jWy26Oq9IkKNowgrgYX9LVILM04yBt8 t+DE/+q/rAInunAWlO591V0+blVWtrcsqWgrs1iNwa5aUokLIOsR1ISDV0W/RVXk8anV /4FFOeigoh3VbIB6EgQotbyWSsfkqOvLJpCb71LQgAjtXQAqAOMWaspgsLogFf9f+mEB Cr/7yyPRGPm+4+ir4ZDIlAf6Viu6j8CrX9bpuaC4hXFVoJ9Bhh326wu7dKMRYjKAW++A /irstjnIFhQDacd6uUEfM2SZmy/uQ5wymPPTW59v0bTvsMvjlWe2zg41UlWlLUwk5eqx vuVQ== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr57497389wjc.35.1362692491675; Thu, 07 Mar 2013 13:41:31 -0800 (PST) Received: by 10.194.171.68 with HTTP; Thu, 7 Mar 2013 13:41:31 -0800 (PST) In-Reply-To: <20130306110805.GA13535@zion.uk.xensource.com> References: <20130305172238.GA11446@zion.uk.xensource.com> <20130306110805.GA13535@zion.uk.xensource.com> Date: Fri, 8 Mar 2013 03:11:31 +0530 Message-ID: From: Tarun Dua To: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============5362210670151349097==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5362210670151349097== Content-Type: multipart/alternative; boundary=089e013d1da8e78ee704d75c91e2 --089e013d1da8e78ee704d75c91e2 Content-Type: text/plain; charset=UTF-8 I have the same problem on CentOS 6.3 :- /proc/cpuinfo shows only 16 VCPUs. It should have 24 VCPUs based on the HW config:- Hyperthreaded 2 x Intel Xeon E5-2620 uname -a says :- 3.7.9-1.el6xen.x86_64 xen-hypervisor-4.2.1-4.el6.x86_64 xen-runtime-4.2.1-4.el6.x86_64 kernel-xen-release-6-4.noarch xen-libs-4.2.1-4.el6.x86_64 kernel-xen-firmware-3.7.9-1.el6xen.x86_64 xen-4.2.1-4.el6.x86_64 xen-licenses-4.2.1-4.el6.x86_64 kernel-xen-3.7.9-1.el6xen.x86 grub.conf looks like this :- title CentOS (3.7.9-1.el6xen.x86_64) root (hd0,0) kernel /xen.gz dom0_mem=4000M cpufreq=xen dom0_max_vcpus=24 dom0_vcpus_pin module /vmlinuz-3.7.9-1.el6xen.x86_64 ro root=UUID=eb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 quiet SYSFONT=latarcyrheb-sun16 rd_MD_UUID=79d39968:505cc18a:ee7a4c34:41b4a178 rhgb crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM module /initramfs-3.7.9-1.el6xen.x86_64.img -Tarun --089e013d1da8e78ee704d75c91e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have the same problem on CentOS 6.3 :-

/proc/cpuinfo shows only 16= VCPUs.

It should have 24 VCPUs based on the HW config:- Hyperthread= ed 2 x Intel Xeon E5-2620

uname -a says :-

3.7.9-1.el6xen.x86= _64

xen-hypervisor-4.2.1-4.el6.x86_64
xen-runtime-4.2.1-4.el6.x86_64
= kernel-xen-release-6-4.noarch
xen-libs-4.2.1-4.el6.x86_64
kernel-xen-= firmware-3.7.9-1.el6xen.x86_64
xen-4.2.1-4.el6.x86_64
xen-licenses-4.= 2.1-4.el6.x86_64
kernel-xen-3.7.9-1.el6xen.x86

grub.conf looks like this :-

ti= tle CentOS (3.7.9-1.el6xen.x86_64)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 root (hd0,0)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 kernel /x= en.gz dom0_mem=3D4000M cpufreq=3Dxen dom0_max_vcpus=3D24 dom0_vcpus_pin
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 module /vmlinuz-3.7.9-1.el6xen.x= 86_64 ro root=3DUUID=3Deb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_N= O_LVM LANG=3Den_US.UTF-8 quiet SYSFONT=3Dlatarcyrheb-sun16 rd_MD_UUID=3D79d= 39968:505cc18a:ee7a4c34:41b4a178 rhgb crashkernel=3Dauto=C2=A0 KEYBOARDTYPE= =3Dpc KEYTABLE=3Dus rd_NO_DM
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 module /initramfs-3.7.9-1.el6xen= .x86_64.img
-Tarun
--089e013d1da8e78ee704d75c91e2-- --===============5362210670151349097== 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 --===============5362210670151349097==-- From xen-users-bounces@lists.xen.org Thu Mar 07 21:42:35 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 21:42: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 1UDiZF-0004ob-SI; Thu, 07 Mar 2013 21:41:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiZE-0004oM-2j for xen-users@lists.xen.org; Thu, 07 Mar 2013 21:41:36 +0000 Received: from [193.109.254.147:44415] by server-3.bemta-14.messagelabs.com id F1/01-17488-F8909315; Thu, 07 Mar 2013 21:41:35 +0000 X-Env-Sender: tarundua@gmail.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1362692491!9000810!1 X-Originating-IP: [74.125.82.173] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13834 invoked from network); 7 Mar 2013 21:41:32 -0000 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 21:41:32 -0000 Received: by mail-we0-f173.google.com with SMTP id x51so217259wey.18 for ; Thu, 07 Mar 2013 13:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=7OpINj+mxj2QyRMgQv2qN4d8MD+ZqanpdYW4Y824TfA=; b=0qWMGFOIlsYiQcNVrWCHw/Tm3w9rwvjZtM7jWy26Oq9IkKNowgrgYX9LVILM04yBt8 t+DE/+q/rAInunAWlO591V0+blVWtrcsqWgrs1iNwa5aUokLIOsR1ISDV0W/RVXk8anV /4FFOeigoh3VbIB6EgQotbyWSsfkqOvLJpCb71LQgAjtXQAqAOMWaspgsLogFf9f+mEB Cr/7yyPRGPm+4+ir4ZDIlAf6Viu6j8CrX9bpuaC4hXFVoJ9Bhh326wu7dKMRYjKAW++A /irstjnIFhQDacd6uUEfM2SZmy/uQ5wymPPTW59v0bTvsMvjlWe2zg41UlWlLUwk5eqx vuVQ== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr57497389wjc.35.1362692491675; Thu, 07 Mar 2013 13:41:31 -0800 (PST) Received: by 10.194.171.68 with HTTP; Thu, 7 Mar 2013 13:41:31 -0800 (PST) In-Reply-To: <20130306110805.GA13535@zion.uk.xensource.com> References: <20130305172238.GA11446@zion.uk.xensource.com> <20130306110805.GA13535@zion.uk.xensource.com> Date: Fri, 8 Mar 2013 03:11:31 +0530 Message-ID: From: Tarun Dua To: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============5362210670151349097==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5362210670151349097== Content-Type: multipart/alternative; boundary=089e013d1da8e78ee704d75c91e2 --089e013d1da8e78ee704d75c91e2 Content-Type: text/plain; charset=UTF-8 I have the same problem on CentOS 6.3 :- /proc/cpuinfo shows only 16 VCPUs. It should have 24 VCPUs based on the HW config:- Hyperthreaded 2 x Intel Xeon E5-2620 uname -a says :- 3.7.9-1.el6xen.x86_64 xen-hypervisor-4.2.1-4.el6.x86_64 xen-runtime-4.2.1-4.el6.x86_64 kernel-xen-release-6-4.noarch xen-libs-4.2.1-4.el6.x86_64 kernel-xen-firmware-3.7.9-1.el6xen.x86_64 xen-4.2.1-4.el6.x86_64 xen-licenses-4.2.1-4.el6.x86_64 kernel-xen-3.7.9-1.el6xen.x86 grub.conf looks like this :- title CentOS (3.7.9-1.el6xen.x86_64) root (hd0,0) kernel /xen.gz dom0_mem=4000M cpufreq=xen dom0_max_vcpus=24 dom0_vcpus_pin module /vmlinuz-3.7.9-1.el6xen.x86_64 ro root=UUID=eb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 quiet SYSFONT=latarcyrheb-sun16 rd_MD_UUID=79d39968:505cc18a:ee7a4c34:41b4a178 rhgb crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM module /initramfs-3.7.9-1.el6xen.x86_64.img -Tarun --089e013d1da8e78ee704d75c91e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have the same problem on CentOS 6.3 :-

/proc/cpuinfo shows only 16= VCPUs.

It should have 24 VCPUs based on the HW config:- Hyperthread= ed 2 x Intel Xeon E5-2620

uname -a says :-

3.7.9-1.el6xen.x86= _64

xen-hypervisor-4.2.1-4.el6.x86_64
xen-runtime-4.2.1-4.el6.x86_64
= kernel-xen-release-6-4.noarch
xen-libs-4.2.1-4.el6.x86_64
kernel-xen-= firmware-3.7.9-1.el6xen.x86_64
xen-4.2.1-4.el6.x86_64
xen-licenses-4.= 2.1-4.el6.x86_64
kernel-xen-3.7.9-1.el6xen.x86

grub.conf looks like this :-

ti= tle CentOS (3.7.9-1.el6xen.x86_64)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 root (hd0,0)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 kernel /x= en.gz dom0_mem=3D4000M cpufreq=3Dxen dom0_max_vcpus=3D24 dom0_vcpus_pin
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 module /vmlinuz-3.7.9-1.el6xen.x= 86_64 ro root=3DUUID=3Deb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_N= O_LVM LANG=3Den_US.UTF-8 quiet SYSFONT=3Dlatarcyrheb-sun16 rd_MD_UUID=3D79d= 39968:505cc18a:ee7a4c34:41b4a178 rhgb crashkernel=3Dauto=C2=A0 KEYBOARDTYPE= =3Dpc KEYTABLE=3Dus rd_NO_DM
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 module /initramfs-3.7.9-1.el6xen= .x86_64.img
-Tarun
--089e013d1da8e78ee704d75c91e2-- --===============5362210670151349097== 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 --===============5362210670151349097==-- From xen-users-bounces@lists.xen.org Thu Mar 07 21:43:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 21:43:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiZs-0004u4-Je; Thu, 07 Mar 2013 21:42:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiZr-0004tk-6N for xen-users@lists.xen.org; Thu, 07 Mar 2013 21:42:15 +0000 Received: from [85.158.137.99:22615] by server-12.bemta-3.messagelabs.com id A5/E8-01357-6B909315; Thu, 07 Mar 2013 21:42:14 +0000 X-Env-Sender: theubaz@gmail.com X-Msg-Ref: server-12.tower-217.messagelabs.com!1362692530!14150166!1 X-Originating-IP: [209.85.220.49] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_10_20,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18754 invoked from network); 7 Mar 2013 21:42:11 -0000 Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com) (209.85.220.49) by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 21:42:11 -0000 Received: by mail-pa0-f49.google.com with SMTP id kp6so761868pab.22 for ; Thu, 07 Mar 2013 13:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U821Ut01KICkTDSRcZi0vK4ndGQbwRgLDShy5ueRmp4=; b=arMvBeAcjOoX/+DC8HwsusUDIY/fyBNLw3ys+bYFiX9EsLy6O+3mjpWpk6nhvY99k/ 77n9AdIr+6TBGnWxN9L/WsUdEP5LI3JyRgfNDILdSQp46lnzRFvkXNAtx+tNvCG3H+sl VzyEWhuP0SYAg75VIQvXqp5B93gTFj6StcdL0WH1xo0C7L/gmPQx/2xR5EMyjokHoUHA ryO/dlNyBMeauh8kDxMROMJd3FhnSxuyikNyHGu162ZmN8aiKAgYSwHiFI9CG+FrLjGw p5Xy5y9PBHI4K4g5OoeJ/9/iiO9jVSrRn69bK1XKfX8fCllvVY1tspE4MsZPuJntpfCq e1Lw== MIME-Version: 1.0 X-Received: by 10.66.117.106 with SMTP id kd10mr452324pab.148.1362692529515; Thu, 07 Mar 2013 13:42:09 -0800 (PST) Received: by 10.70.34.71 with HTTP; Thu, 7 Mar 2013 13:42:09 -0800 (PST) In-Reply-To: References: <5138E4E6.9080001@cam.ac.uk> Date: Thu, 7 Mar 2013 13:42:09 -0800 X-Google-Sender-Auth: F7znPw7uIUqCveAfaaJckNt_7D4 Message-ID: From: John Sherwood To: Andreas Falck Cc: "xen-users@lists.xen.org" , Matthew Dean Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============9169823126033773533==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9169823126033773533== Content-Type: multipart/alternative; boundary=047d7bf0e53828f39b04d75c94b1 --047d7bf0e53828f39b04d75c94b1 Content-Type: text/plain; charset=ISO-8859-1 (and I should probably mention that it has been my experience that that is the expected and correct behavior) On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood wrote: > Having the windows logo freeze in the VNC window has been my experience > with GPU passthrough as well. > > > On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck < > falck.andreas.lists@gmail.com> wrote: > >> Hi, >> >> I believe that the Windows logo freezing in the vnc window is normal >> behaviour when secondary GPU passthrough is working as it should, since the >> display should be handed over to the GPU. At least that was the case before >> when I was passing through a HD6850 card as secondary to win7 using xl. But >> you should expect output on the GPU, of course. >> >> Have you tried different versions of the catalyst driver? I think that >> some users have reported problems with the latest one (13-something). >> >> Regards, >> Andreas >> >> 2013/3/7 Matthew Dean >> >>> Hi all, >>> >>> I've managed to get a windows 7 x64 hvm to boot and install and I'm now >>> looking to pass through a HD 7970 as a secondary GPU. in order to prepare >>> the devices for passthrough I've used >>> >>> xl pci-assignable-add 83:00.0 >>> xl pci-assignable-add 83:00.1 >>> >>> Where I've identified the device pci ids using lspci. This works fine >>> and the devices appear when I call 'xl pci-assignable-list'. After adding >>> them to the vm config (see below) I was able to get the vm to boot and the >>> devices appeared in device manager. Installing the ATI drivers however has >>> meant that on further boots the machine never gets past the windows logo >>> in the VNC window and no output is generated from the ATI card. It simply >>> freezes there and the only way I can get back into windows is via safe >>> mode, even after uninstalling the ATI software. >>> >>> Has anybody else experienced similar issues or have any advice as to how >>> to get this to work? I'm a bit stumped and the wiki implies that this >>> should 'just work'. >>> >>> Thank you in advance for any help. >>> >>> Matt >>> >>> Here is my machine config >>> >>> ##############################**############################# >>> >>> builder='hvm' >>> memory = 2048 >>> name = 'Windows7Test' >>> >>> vcpus=4 >>> pae=1 >>> acpi=1 >>> apic=1 >>> >>> disk = [ 'file:/xen-guests/img/**windows7Test.img,hda,w' ] >>> pci = [ '83:00.0' , '83:00.1' ] >>> >>> on_poweroff = 'destroy' >>> on_reboot = 'restart' >>> on_crash = 'destroy' >>> >>> boot='cd' >>> >>> sdl=0 >>> vnc=1 >>> vncconsole=0 >>> vncpasswd='' >>> vnclisten='172.24.226.84' >>> >>> stdvga=0 >>> >>> serial='pty' >>> usbdevice='tablet' >>> >>> gfx_passthru=0 >>> pci_power_mgmt=1 >>> xen_platform_pci=1 >>> pci_msitranslate=1 >>> viridian=1 >>> hpet=1 >>> >>> ##############################**############################## >>> >>> And the vm produces the following qemu log in /var/log/xen/ >>> >>> ##############################**############################## >>> >>> domid: 4 >>> -videoram option does not work with cirrus vga device model. Videoram >>> set to 4M. >>> Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.**img >>> (drv 'aio') >>> Using file /xen-guests/img/windows7Test.**img in read-write mode >>> Watching /local/domain/0/device-model/**4/logdirty/cmd >>> Watching /local/domain/0/device-model/**4/command >>> Watching /local/domain/4/cpu >>> char device redirected to /dev/pts/3 >>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>> shared page at pfn feffd >>> buffered io page at pfn feffb >>> Guest uuid = e09f5a51-7de1-4d92-9cec-**826b9d66aeb6 >>> 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/4/xen_extended_**power_mgmt): >>> read error >>> 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. >>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 >>> xs_read(/local/domain/4/log-**throttling): read error >>> qemu: ignoring not-understood drive `/local/domain/4/log-**throttling' >>> medium change watch on `/local/domain/4/log-**throttling' - unknown >>> device, ignored >>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 >>> dm-command: hot insert pass-through pci dev >>> register_real_device: Assigning real physical device 83:00.0 ... >>> register_real_device: Enable MSI translation via per device option >>> register_real_device: Enable power management >>> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: >>> No such file or directory: 0x83:0x0.0x0 >>> pt_register_regions: IO region registered (size=0x10000000 >>> base_addr=0xe000000c) >>> pt_register_regions: IO region registered (size=0x00040000 >>> base_addr=0xf0000004) >>> pt_register_regions: IO region registered (size=0x00000100 >>> base_addr=0x0000f001) >>> pt_register_regions: Expansion ROM registered (size=0x00020000 >>> base_addr=0xf0040000) >>> pt_msi_setup: msi mapped with pirq 67 >>> pci_intx: intx=1 >>> register_real_device: Real physical device 83:00.0 registered >>> successfuly! >>> IRQ type = MSI-INTx >>> dm-command: hot insert pass-through pci dev >>> register_real_device: Assigning real physical device 83:00.1 ... >>> register_real_device: Enable MSI translation via per device option >>> register_real_device: Enable power management >>> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: >>> No such file or directory: 0x83:0x0.0x1 >>> pt_register_regions: IO region registered (size=0x00004000 >>> base_addr=0xf0060004) >>> pt_msi_setup: msi mapped with pirq 66 >>> pci_intx: intx=2 >>> register_real_device: Real physical device 83:00.1 registered >>> successfuly! >>> IRQ type = MSI-INTx >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=1 >>> cirrus vga map change while on lfb mode >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >>> first_map=1 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >>> first_map=1 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1 >>> 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. >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 >>> first_map=0 >>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=0 >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >>> first_map=0 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 >>> first_map=0 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >>> first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 >>> first_map=0 >>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=0 >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >>> first_map=0 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 >>> pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation >>> pci_intx: intx=1 >>> pt_msi_disable: Unmap msi with pirq 67 >>> pt_msgctrl_reg_write: setup msi for dev 20 >>> pt_msi_setup: msi mapped with pirq 67 >>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 >>> first_map=0 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >>> first_map=0 >>> >>> ##############################**##############################** >>> ########## >>> >>> ______________________________**_________________ >>> 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 >> > > --047d7bf0e53828f39b04d75c94b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (and I should probably mention that it has been my experience that that is = the expected and correct behavior)

On Thu= , Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC wi= ndow has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at= 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com>= wrote:
Hi,

I believe that the Windows logo f= reezing in the vnc window is normal behaviour when secondary GPU passthroug= h is working as it should, since the display should be handed over to the G= PU. At least that was the case before when I was passing through a HD6850 c= ard as secondary to win7 using xl. But you should expect output on the GPU,= of course.

Have you tried different versions of the catalyst driver? I think that = some users have reported problems with the latest one (13-something).
Regards,
Andreas

2013/3/7 Matthew De= an <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm= now looking to pass through a HD 7970 as a secondary GPU. =A0in order to p= repare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci. =A0This works fin= e and the devices appear when I call 'xl pci-assignable-list'. Afte= r adding them to the vm config (see below) I was able to get the vm to boot= and the devices appeared in device manager. =A0Installing the ATI drivers = however has meant that on further boots the =A0machine never gets past the = windows logo in the VNC window and no output is generated from the ATI card= . =A0It simply freezes there and the only way I can get back into windows i= s via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to= get this to work? =A0I'm a bit stumped and the wiki implies that this = should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder=3D'hvm'
memory =3D 2048
name =3D 'Windows7Test'

vcpus=3D4
pae=3D1
acpi=3D1
apic=3D1

disk =3D [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] pci =3D [ '83:00.0' , '83:00.1' ]

on_poweroff =3D 'destroy'
on_reboot =A0 =3D 'restart'
on_crash =A0 =A0=3D 'destroy'

boot=3D'cd'

sdl=3D0
vnc=3D1
vncconsole=3D0
vncpasswd=3D''
vnclisten=3D'172.24.226.84'

stdvga=3D0

serial=3D'pty'
usbdevice=3D'tablet'

gfx_passthru=3D0
pci_power_mgmt=3D1
xen_platform_pci=3D1
pci_msitranslate=3D1
viridian=3D1
hpet=3D1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set t= o 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img= (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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 st= ate.
xs_read(/local/domain/0/device-model/4/xen_extended_power_mgm= t): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling&= #39;
medium change watch on `/local/domain/4/log-throttling' - unknow= n device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=3D0x10000000 base_addr=3D0x= e000000c)
pt_register_regions: IO region registered (size=3D0x00040000 base_addr=3D0x= f0000004)
pt_register_regions: IO region registered (size=3D0x00000100 base_addr=3D0x= 0000f001)
pt_register_regions: Expansion ROM registered (size=3D0x00020000 base_addr= =3D0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=3D1
register_real_device: Real physical device 83:00.0 registered successfuly!<= br> IRQ type =3D MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=3D0x00004000 base_addr=3D0x= f0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=3D2
register_real_device: Real physical device 83:00.1 registered successfuly!<= br> IRQ type =3D MSI-INTx
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D1
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D1
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st= ate.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro st= ate.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=3D1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0

#############################################################= #########

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


--047d7bf0e53828f39b04d75c94b1-- --===============9169823126033773533== 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 --===============9169823126033773533==-- From xen-users-bounces@lists.xen.org Thu Mar 07 21:43:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 07 Mar 2013 21:43:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiZs-0004u4-Je; Thu, 07 Mar 2013 21:42:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDiZr-0004tk-6N for xen-users@lists.xen.org; Thu, 07 Mar 2013 21:42:15 +0000 Received: from [85.158.137.99:22615] by server-12.bemta-3.messagelabs.com id A5/E8-01357-6B909315; Thu, 07 Mar 2013 21:42:14 +0000 X-Env-Sender: theubaz@gmail.com X-Msg-Ref: server-12.tower-217.messagelabs.com!1362692530!14150166!1 X-Originating-IP: [209.85.220.49] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_10_20,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18754 invoked from network); 7 Mar 2013 21:42:11 -0000 Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com) (209.85.220.49) by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 7 Mar 2013 21:42:11 -0000 Received: by mail-pa0-f49.google.com with SMTP id kp6so761868pab.22 for ; Thu, 07 Mar 2013 13:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U821Ut01KICkTDSRcZi0vK4ndGQbwRgLDShy5ueRmp4=; b=arMvBeAcjOoX/+DC8HwsusUDIY/fyBNLw3ys+bYFiX9EsLy6O+3mjpWpk6nhvY99k/ 77n9AdIr+6TBGnWxN9L/WsUdEP5LI3JyRgfNDILdSQp46lnzRFvkXNAtx+tNvCG3H+sl VzyEWhuP0SYAg75VIQvXqp5B93gTFj6StcdL0WH1xo0C7L/gmPQx/2xR5EMyjokHoUHA ryO/dlNyBMeauh8kDxMROMJd3FhnSxuyikNyHGu162ZmN8aiKAgYSwHiFI9CG+FrLjGw p5Xy5y9PBHI4K4g5OoeJ/9/iiO9jVSrRn69bK1XKfX8fCllvVY1tspE4MsZPuJntpfCq e1Lw== MIME-Version: 1.0 X-Received: by 10.66.117.106 with SMTP id kd10mr452324pab.148.1362692529515; Thu, 07 Mar 2013 13:42:09 -0800 (PST) Received: by 10.70.34.71 with HTTP; Thu, 7 Mar 2013 13:42:09 -0800 (PST) In-Reply-To: References: <5138E4E6.9080001@cam.ac.uk> Date: Thu, 7 Mar 2013 13:42:09 -0800 X-Google-Sender-Auth: F7znPw7uIUqCveAfaaJckNt_7D4 Message-ID: From: John Sherwood To: Andreas Falck Cc: "xen-users@lists.xen.org" , Matthew Dean Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============9169823126033773533==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9169823126033773533== Content-Type: multipart/alternative; boundary=047d7bf0e53828f39b04d75c94b1 --047d7bf0e53828f39b04d75c94b1 Content-Type: text/plain; charset=ISO-8859-1 (and I should probably mention that it has been my experience that that is the expected and correct behavior) On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood wrote: > Having the windows logo freeze in the VNC window has been my experience > with GPU passthrough as well. > > > On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck < > falck.andreas.lists@gmail.com> wrote: > >> Hi, >> >> I believe that the Windows logo freezing in the vnc window is normal >> behaviour when secondary GPU passthrough is working as it should, since the >> display should be handed over to the GPU. At least that was the case before >> when I was passing through a HD6850 card as secondary to win7 using xl. But >> you should expect output on the GPU, of course. >> >> Have you tried different versions of the catalyst driver? I think that >> some users have reported problems with the latest one (13-something). >> >> Regards, >> Andreas >> >> 2013/3/7 Matthew Dean >> >>> Hi all, >>> >>> I've managed to get a windows 7 x64 hvm to boot and install and I'm now >>> looking to pass through a HD 7970 as a secondary GPU. in order to prepare >>> the devices for passthrough I've used >>> >>> xl pci-assignable-add 83:00.0 >>> xl pci-assignable-add 83:00.1 >>> >>> Where I've identified the device pci ids using lspci. This works fine >>> and the devices appear when I call 'xl pci-assignable-list'. After adding >>> them to the vm config (see below) I was able to get the vm to boot and the >>> devices appeared in device manager. Installing the ATI drivers however has >>> meant that on further boots the machine never gets past the windows logo >>> in the VNC window and no output is generated from the ATI card. It simply >>> freezes there and the only way I can get back into windows is via safe >>> mode, even after uninstalling the ATI software. >>> >>> Has anybody else experienced similar issues or have any advice as to how >>> to get this to work? I'm a bit stumped and the wiki implies that this >>> should 'just work'. >>> >>> Thank you in advance for any help. >>> >>> Matt >>> >>> Here is my machine config >>> >>> ##############################**############################# >>> >>> builder='hvm' >>> memory = 2048 >>> name = 'Windows7Test' >>> >>> vcpus=4 >>> pae=1 >>> acpi=1 >>> apic=1 >>> >>> disk = [ 'file:/xen-guests/img/**windows7Test.img,hda,w' ] >>> pci = [ '83:00.0' , '83:00.1' ] >>> >>> on_poweroff = 'destroy' >>> on_reboot = 'restart' >>> on_crash = 'destroy' >>> >>> boot='cd' >>> >>> sdl=0 >>> vnc=1 >>> vncconsole=0 >>> vncpasswd='' >>> vnclisten='172.24.226.84' >>> >>> stdvga=0 >>> >>> serial='pty' >>> usbdevice='tablet' >>> >>> gfx_passthru=0 >>> pci_power_mgmt=1 >>> xen_platform_pci=1 >>> pci_msitranslate=1 >>> viridian=1 >>> hpet=1 >>> >>> ##############################**############################## >>> >>> And the vm produces the following qemu log in /var/log/xen/ >>> >>> ##############################**############################## >>> >>> domid: 4 >>> -videoram option does not work with cirrus vga device model. Videoram >>> set to 4M. >>> Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.**img >>> (drv 'aio') >>> Using file /xen-guests/img/windows7Test.**img in read-write mode >>> Watching /local/domain/0/device-model/**4/logdirty/cmd >>> Watching /local/domain/0/device-model/**4/command >>> Watching /local/domain/4/cpu >>> char device redirected to /dev/pts/3 >>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>> shared page at pfn feffd >>> buffered io page at pfn feffb >>> Guest uuid = e09f5a51-7de1-4d92-9cec-**826b9d66aeb6 >>> 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/4/xen_extended_**power_mgmt): >>> read error >>> 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. >>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 >>> xs_read(/local/domain/4/log-**throttling): read error >>> qemu: ignoring not-understood drive `/local/domain/4/log-**throttling' >>> medium change watch on `/local/domain/4/log-**throttling' - unknown >>> device, ignored >>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 >>> dm-command: hot insert pass-through pci dev >>> register_real_device: Assigning real physical device 83:00.0 ... >>> register_real_device: Enable MSI translation via per device option >>> register_real_device: Enable power management >>> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: >>> No such file or directory: 0x83:0x0.0x0 >>> pt_register_regions: IO region registered (size=0x10000000 >>> base_addr=0xe000000c) >>> pt_register_regions: IO region registered (size=0x00040000 >>> base_addr=0xf0000004) >>> pt_register_regions: IO region registered (size=0x00000100 >>> base_addr=0x0000f001) >>> pt_register_regions: Expansion ROM registered (size=0x00020000 >>> base_addr=0xf0040000) >>> pt_msi_setup: msi mapped with pirq 67 >>> pci_intx: intx=1 >>> register_real_device: Real physical device 83:00.0 registered >>> successfuly! >>> IRQ type = MSI-INTx >>> dm-command: hot insert pass-through pci dev >>> register_real_device: Assigning real physical device 83:00.1 ... >>> register_real_device: Enable MSI translation via per device option >>> register_real_device: Enable power management >>> pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: >>> No such file or directory: 0x83:0x0.0x1 >>> pt_register_regions: IO region registered (size=0x00004000 >>> base_addr=0xf0060004) >>> pt_msi_setup: msi mapped with pirq 66 >>> pci_intx: intx=2 >>> register_real_device: Real physical device 83:00.1 registered >>> successfuly! >>> IRQ type = MSI-INTx >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=1 >>> cirrus vga map change while on lfb mode >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >>> first_map=1 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >>> first_map=1 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1 >>> 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. >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read register with >>> invalid access size alignment. [Offset:0eh][Length:4] >>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 >>> first_map=0 >>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=0 >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >>> first_map=0 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 >>> first_map=0 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >>> first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 >>> first_map=0 >>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0 >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 >>> index=0 first_map=0 >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 >>> first_map=0 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0 >>> pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation >>> pci_intx: intx=1 >>> pt_msi_disable: Unmap msi with pirq 67 >>> pt_msgctrl_reg_write: setup msi for dev 20 >>> pt_msi_setup: msi mapped with pirq 67 >>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 >>> first_map=0 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 >>> first_map=0 >>> >>> ##############################**##############################** >>> ########## >>> >>> ______________________________**_________________ >>> 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 >> > > --047d7bf0e53828f39b04d75c94b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (and I should probably mention that it has been my experience that that is = the expected and correct behavior)

On Thu= , Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC wi= ndow has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at= 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com>= wrote:
Hi,

I believe that the Windows logo f= reezing in the vnc window is normal behaviour when secondary GPU passthroug= h is working as it should, since the display should be handed over to the G= PU. At least that was the case before when I was passing through a HD6850 c= ard as secondary to win7 using xl. But you should expect output on the GPU,= of course.

Have you tried different versions of the catalyst driver? I think that = some users have reported problems with the latest one (13-something).
Regards,
Andreas

2013/3/7 Matthew De= an <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm= now looking to pass through a HD 7970 as a secondary GPU. =A0in order to p= repare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci. =A0This works fin= e and the devices appear when I call 'xl pci-assignable-list'. Afte= r adding them to the vm config (see below) I was able to get the vm to boot= and the devices appeared in device manager. =A0Installing the ATI drivers = however has meant that on further boots the =A0machine never gets past the = windows logo in the VNC window and no output is generated from the ATI card= . =A0It simply freezes there and the only way I can get back into windows i= s via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to= get this to work? =A0I'm a bit stumped and the wiki implies that this = should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder=3D'hvm'
memory =3D 2048
name =3D 'Windows7Test'

vcpus=3D4
pae=3D1
acpi=3D1
apic=3D1

disk =3D [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] pci =3D [ '83:00.0' , '83:00.1' ]

on_poweroff =3D 'destroy'
on_reboot =A0 =3D 'restart'
on_crash =A0 =A0=3D 'destroy'

boot=3D'cd'

sdl=3D0
vnc=3D1
vncconsole=3D0
vncpasswd=3D''
vnclisten=3D'172.24.226.84'

stdvga=3D0

serial=3D'pty'
usbdevice=3D'tablet'

gfx_passthru=3D0
pci_power_mgmt=3D1
xen_platform_pci=3D1
pci_msitranslate=3D1
viridian=3D1
hpet=3D1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set t= o 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img= (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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 st= ate.
xs_read(/local/domain/0/device-model/4/xen_extended_power_mgm= t): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling&= #39;
medium change watch on `/local/domain/4/log-throttling' - unknow= n device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=3D0x10000000 base_addr=3D0x= e000000c)
pt_register_regions: IO region registered (size=3D0x00040000 base_addr=3D0x= f0000004)
pt_register_regions: IO region registered (size=3D0x00000100 base_addr=3D0x= 0000f001)
pt_register_regions: Expansion ROM registered (size=3D0x00020000 base_addr= =3D0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=3D1
register_real_device: Real physical device 83:00.0 registered successfuly!<= br> IRQ type =3D MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul:= No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=3D0x00004000 base_addr=3D0x= f0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=3D2
register_real_device: Real physical device 83:00.1 registered successfuly!<= br> IRQ type =3D MSI-INTx
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D1
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D1
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D1
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw st= ate.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro st= ate.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid a= ccess size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dffff pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_iomem_map: e_phys=3De0000000 maddr=3De0000000 type=3D8 len=3D268435456 i= ndex=3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3000000 maddr=3Df0000000 type=3D0 len=3D262144 inde= x=3D2 first_map=3D0
pt_ioport_map: e_phys=3Dc100 pio_base=3Df000 len=3D256 index=3D4 first_map= =3D0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=3D1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=3Dffffffff maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0
pt_iomem_map: e_phys=3Df3060000 maddr=3Df0060000 type=3D0 len=3D16384 index= =3D0 first_map=3D0

#############################################################= #########

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


--047d7bf0e53828f39b04d75c94b1-- --===============9169823126033773533== 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 --===============9169823126033773533==-- From xen-users-bounces@lists.xen.org Fri Mar 08 02:33:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 02:33: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 1UDn6W-0004Fj-OB; Fri, 08 Mar 2013 02:32:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDn6V-0004Fd-Jk for xen-users@lists.xen.org; Fri, 08 Mar 2013 02:32:15 +0000 Received: from [85.158.138.51:31132] by server-14.bemta-3.messagelabs.com id 6C/F1-27076-EAD49315; Fri, 08 Mar 2013 02:32:14 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1362709932!12228852!1 X-Originating-IP: [209.85.210.182] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24446 invoked from network); 8 Mar 2013 02:32:14 -0000 Received: from mail-ia0-f182.google.com (HELO mail-ia0-f182.google.com) (209.85.210.182) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 02:32:14 -0000 Received: by mail-ia0-f182.google.com with SMTP id w21so1065091iac.27 for ; Thu, 07 Mar 2013 18:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=kuwKJnPqSXI1gbSnwYxCDLuYOZEGMgdWdBprP5S48lw=; b=vxugnw/N818vJPqtkUtxhVXGyxqC4x034MeqB/cFzEWDXE5GwdP6kMkmhc3F34+mIx 87buWiLDZ3AYRzun7q0qDcK13NTTxxew76nYPB//M2c1gd8L4rlxoi2xVulnVqkzVPmV /FGFjl2G+FWsj3Y3vedti8Xz2aH0u4Ct00Nml8m3PqmBm6b7BYhkW5E3iZzDwUa/1rvd fMw5SP9Q1agzeejmcI94A7q0ovPCJelFZrIRBvARSHBGMUC0ZhHHz/0qBobveo1ED6U7 ZOZZ2+xLxBu8AWbp/VvOhzwsQzAi1cnrM6yhEnn5lRg92cddZrCv12zAj+XBJ7qtvGEi oEIw== MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr338693igb.90.1362709932390; Thu, 07 Mar 2013 18:32:12 -0800 (PST) Received: by 10.42.41.5 with HTTP; Thu, 7 Mar 2013 18:32:12 -0800 (PST) Date: Thu, 7 Mar 2013 19:32:12 -0700 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] what is causing this bug X-BeenThere: xen-users@lists.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="===============2736363064692470883==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2736363064692470883== Content-Type: multipart/alternative; boundary=089e011847f673c1a304d760a153 --089e011847f673c1a304d760a153 Content-Type: text/plain; charset=ISO-8859-1 Can someone tell me what could be causing this eror ? xc: error: panic: xc_dom_boot.c:388: xc_dom_gnttab_hvm_seed: failed to add gnttab to physmap [errno=22] : Internal error libxl: error: libxl_dm.c:1237:device_model_spawn_outcome: domain 40 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1073:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1268:libxl__destroy_device_model: Device Model already exited --089e011847f673c1a304d760a153 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can someone tell me what could be causing this eror ?
xc: error: panic:= xc_dom_boot.c:388: xc_dom_gnttab_hvm_seed: failed to add gnttab to physmap= [errno=3D22]
: Internal error
libxl: error: libxl_dm.c:1237:device_m= odel_spawn_outcome: domain 40 device model: spawn failed (rc=3D-3)
libxl: error: libxl_create.c:1073:domcreate_devmodel_started: device model = did not start: -3
libxl: error: libxl_dm.c:1268:libxl__destroy_device_mo= del: Device Model already exited

--089e011847f673c1a304d760a153-- --===============2736363064692470883== 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 --===============2736363064692470883==-- From xen-users-bounces@lists.xen.org Fri Mar 08 02:33:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 02:33: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 1UDn6W-0004Fj-OB; Fri, 08 Mar 2013 02:32:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDn6V-0004Fd-Jk for xen-users@lists.xen.org; Fri, 08 Mar 2013 02:32:15 +0000 Received: from [85.158.138.51:31132] by server-14.bemta-3.messagelabs.com id 6C/F1-27076-EAD49315; Fri, 08 Mar 2013 02:32:14 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1362709932!12228852!1 X-Originating-IP: [209.85.210.182] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24446 invoked from network); 8 Mar 2013 02:32:14 -0000 Received: from mail-ia0-f182.google.com (HELO mail-ia0-f182.google.com) (209.85.210.182) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 02:32:14 -0000 Received: by mail-ia0-f182.google.com with SMTP id w21so1065091iac.27 for ; Thu, 07 Mar 2013 18:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=kuwKJnPqSXI1gbSnwYxCDLuYOZEGMgdWdBprP5S48lw=; b=vxugnw/N818vJPqtkUtxhVXGyxqC4x034MeqB/cFzEWDXE5GwdP6kMkmhc3F34+mIx 87buWiLDZ3AYRzun7q0qDcK13NTTxxew76nYPB//M2c1gd8L4rlxoi2xVulnVqkzVPmV /FGFjl2G+FWsj3Y3vedti8Xz2aH0u4Ct00Nml8m3PqmBm6b7BYhkW5E3iZzDwUa/1rvd fMw5SP9Q1agzeejmcI94A7q0ovPCJelFZrIRBvARSHBGMUC0ZhHHz/0qBobveo1ED6U7 ZOZZ2+xLxBu8AWbp/VvOhzwsQzAi1cnrM6yhEnn5lRg92cddZrCv12zAj+XBJ7qtvGEi oEIw== MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr338693igb.90.1362709932390; Thu, 07 Mar 2013 18:32:12 -0800 (PST) Received: by 10.42.41.5 with HTTP; Thu, 7 Mar 2013 18:32:12 -0800 (PST) Date: Thu, 7 Mar 2013 19:32:12 -0700 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] what is causing this bug X-BeenThere: xen-users@lists.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="===============2736363064692470883==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2736363064692470883== Content-Type: multipart/alternative; boundary=089e011847f673c1a304d760a153 --089e011847f673c1a304d760a153 Content-Type: text/plain; charset=ISO-8859-1 Can someone tell me what could be causing this eror ? xc: error: panic: xc_dom_boot.c:388: xc_dom_gnttab_hvm_seed: failed to add gnttab to physmap [errno=22] : Internal error libxl: error: libxl_dm.c:1237:device_model_spawn_outcome: domain 40 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1073:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1268:libxl__destroy_device_model: Device Model already exited --089e011847f673c1a304d760a153 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can someone tell me what could be causing this eror ?
xc: error: panic:= xc_dom_boot.c:388: xc_dom_gnttab_hvm_seed: failed to add gnttab to physmap= [errno=3D22]
: Internal error
libxl: error: libxl_dm.c:1237:device_m= odel_spawn_outcome: domain 40 device model: spawn failed (rc=3D-3)
libxl: error: libxl_create.c:1073:domcreate_devmodel_started: device model = did not start: -3
libxl: error: libxl_dm.c:1268:libxl__destroy_device_mo= del: Device Model already exited

--089e011847f673c1a304d760a153-- --===============2736363064692470883== 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 --===============2736363064692470883==-- From xen-users-bounces@lists.xen.org Fri Mar 08 04:33:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 04:33: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 1UDoz5-0005d0-Kc; Fri, 08 Mar 2013 04:32:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDoz4-0005cv-5v for xen-users@lists.xen.org; Fri, 08 Mar 2013 04:32:42 +0000 Received: from [85.158.143.99:2074] by server-3.bemta-4.messagelabs.com id B4/49-02186-9E969315; Fri, 08 Mar 2013 04:32:41 +0000 X-Env-Sender: ps2wayne@gmail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1362717158!27121610!1 X-Originating-IP: [209.85.223.182] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27326 invoked from network); 8 Mar 2013 04:32:39 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 04:32:39 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so1560949iea.27 for ; Thu, 07 Mar 2013 20:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YxkY33bv9Hw7ODzLzSiG+H/J6zUNK1EcyKQnR3qv0Ao=; b=tY3VWTFRc6MUd/gS0KgzhE5Kk4lbd9j3UCrSvYA79ib9L78Aqlmoe3sMEVsRQQNkZT ebnm28wUQl22S/diut+0AIdlDO9ZQ4Kf0dks/zFikVRPq2w8lOnDFWsj3a6lJuIEHfD7 fdBQm72OUrsUT8jfJ+w2yaGvnwMpcTL//0Vp1KSn8WFREPCNhrWtFCDGeUMU4nH1qNhq c7CvmS7Mj3jPU6qaMXo1kqPCHwnpFEqZAD16h82ZbLwZRacTZZJiZCqXJhXrUl3tTJyP vCV1OAVh+LH5uEr2rqjshqvYBZJoLDlprkjWQJF5bMRmxtuS2LSJ9cnIDOsRD6I6nDXL HjKQ== MIME-Version: 1.0 X-Received: by 10.42.95.146 with SMTP id f18mr301151icn.9.1362717158168; Thu, 07 Mar 2013 20:32:38 -0800 (PST) Received: by 10.64.132.101 with HTTP; Thu, 7 Mar 2013 20:32:38 -0800 (PST) In-Reply-To: References: <20130305172238.GA11446@zion.uk.xensource.com> <20130306110805.GA13535@zion.uk.xensource.com> Date: Thu, 7 Mar 2013 23:32:38 -0500 Message-ID: From: Wayne Egerer To: Tarun Dua Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============6357257664260013841==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6357257664260013841== Content-Type: multipart/alternative; boundary=20cf30334ac324acc004d7625061 --20cf30334ac324acc004d7625061 Content-Type: text/plain; charset=ISO-8859-1 What does 'xl info' show? On Thu, Mar 7, 2013 at 4:41 PM, Tarun Dua wrote: > I have the same problem on CentOS 6.3 :- > > /proc/cpuinfo shows only 16 VCPUs. > > It should have 24 VCPUs based on the HW config:- Hyperthreaded 2 x Intel > Xeon E5-2620 > > uname -a says :- > > 3.7.9-1.el6xen.x86_64 > > xen-hypervisor-4.2.1-4.el6.x86_64 > xen-runtime-4.2.1-4.el6.x86_64 > kernel-xen-release-6-4.noarch > xen-libs-4.2.1-4.el6.x86_64 > kernel-xen-firmware-3.7.9-1.el6xen.x86_64 > xen-4.2.1-4.el6.x86_64 > xen-licenses-4.2.1-4.el6.x86_64 > kernel-xen-3.7.9-1.el6xen.x86 > > grub.conf looks like this :- > > title CentOS (3.7.9-1.el6xen.x86_64) > root (hd0,0) > kernel /xen.gz dom0_mem=4000M cpufreq=xen dom0_max_vcpus=24 > dom0_vcpus_pin > module /vmlinuz-3.7.9-1.el6xen.x86_64 ro > root=UUID=eb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_NO_LVM > LANG=en_US.UTF-8 quiet SYSFONT=latarcyrheb-sun16 > rd_MD_UUID=79d39968:505cc18a:ee7a4c34:41b4a178 rhgb crashkernel=auto > KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM > module /initramfs-3.7.9-1.el6xen.x86_64.img > -Tarun > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --20cf30334ac324acc004d7625061 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What does 'xl info' show?


On Thu, Mar 7, 2013 at 4:41 PM, = Tarun Dua <tarundua@gmail.com> wrote:
I have the same problem on CentOS 6.3 :-
=
/proc/cpuinfo shows only 16 VCPUs.

It should have 24 VCPUs based= on the HW config:- Hyperthreaded 2 x Intel Xeon E5-2620

uname -a says :-

3.7.9-1.el6xen.x86_64

xen-hypervisor-4.2.1-4.el6.x86_64
xen-runtime-4.2.1-4.el6.x86_64
= kernel-xen-release-6-4.noarch
xen-libs-4.2.1-4.el6.x86_64
kernel-xen-= firmware-3.7.9-1.el6xen.x86_64
xen-4.2.1-4.el6.x86_64
xen-licenses-4.= 2.1-4.el6.x86_64
kernel-xen-3.7.9-1.el6xen.x86

grub.conf looks like this :-

ti= tle CentOS (3.7.9-1.el6xen.x86_64)
=A0=A0=A0=A0=A0=A0=A0 root (hd0,0)=A0=A0=A0=A0=A0=A0=A0 kernel /xen.gz dom0_mem=3D4000M cpufreq=3Dxen dom0_m= ax_vcpus=3D24 dom0_vcpus_pin
=A0=A0=A0=A0=A0=A0=A0 module /vmlinuz-3.7.9-1.el6xen.x86_64 ro root=3DUUID= =3Deb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_NO_LVM LANG=3Den_US.U= TF-8 quiet SYSFONT=3Dlatarcyrheb-sun16 rd_MD_UUID=3D79d39968:505cc18a:ee7a4= c34:41b4a178 rhgb crashkernel=3Dauto=A0 KEYBOARDTYPE=3Dpc KEYTABLE=3Dus rd_= NO_DM
=A0=A0=A0=A0=A0=A0=A0 module /initramfs-3.7.9-1.el6xen.x86_64.img
-Tarun

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--20cf30334ac324acc004d7625061-- --===============6357257664260013841== 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 --===============6357257664260013841==-- From xen-users-bounces@lists.xen.org Fri Mar 08 04:33:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 04:33: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 1UDoz5-0005d0-Kc; Fri, 08 Mar 2013 04:32:43 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDoz4-0005cv-5v for xen-users@lists.xen.org; Fri, 08 Mar 2013 04:32:42 +0000 Received: from [85.158.143.99:2074] by server-3.bemta-4.messagelabs.com id B4/49-02186-9E969315; Fri, 08 Mar 2013 04:32:41 +0000 X-Env-Sender: ps2wayne@gmail.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1362717158!27121610!1 X-Originating-IP: [209.85.223.182] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27326 invoked from network); 8 Mar 2013 04:32:39 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 04:32:39 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so1560949iea.27 for ; Thu, 07 Mar 2013 20:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YxkY33bv9Hw7ODzLzSiG+H/J6zUNK1EcyKQnR3qv0Ao=; b=tY3VWTFRc6MUd/gS0KgzhE5Kk4lbd9j3UCrSvYA79ib9L78Aqlmoe3sMEVsRQQNkZT ebnm28wUQl22S/diut+0AIdlDO9ZQ4Kf0dks/zFikVRPq2w8lOnDFWsj3a6lJuIEHfD7 fdBQm72OUrsUT8jfJ+w2yaGvnwMpcTL//0Vp1KSn8WFREPCNhrWtFCDGeUMU4nH1qNhq c7CvmS7Mj3jPU6qaMXo1kqPCHwnpFEqZAD16h82ZbLwZRacTZZJiZCqXJhXrUl3tTJyP vCV1OAVh+LH5uEr2rqjshqvYBZJoLDlprkjWQJF5bMRmxtuS2LSJ9cnIDOsRD6I6nDXL HjKQ== MIME-Version: 1.0 X-Received: by 10.42.95.146 with SMTP id f18mr301151icn.9.1362717158168; Thu, 07 Mar 2013 20:32:38 -0800 (PST) Received: by 10.64.132.101 with HTTP; Thu, 7 Mar 2013 20:32:38 -0800 (PST) In-Reply-To: References: <20130305172238.GA11446@zion.uk.xensource.com> <20130306110805.GA13535@zion.uk.xensource.com> Date: Thu, 7 Mar 2013 23:32:38 -0500 Message-ID: From: Wayne Egerer To: Tarun Dua Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============6357257664260013841==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6357257664260013841== Content-Type: multipart/alternative; boundary=20cf30334ac324acc004d7625061 --20cf30334ac324acc004d7625061 Content-Type: text/plain; charset=ISO-8859-1 What does 'xl info' show? On Thu, Mar 7, 2013 at 4:41 PM, Tarun Dua wrote: > I have the same problem on CentOS 6.3 :- > > /proc/cpuinfo shows only 16 VCPUs. > > It should have 24 VCPUs based on the HW config:- Hyperthreaded 2 x Intel > Xeon E5-2620 > > uname -a says :- > > 3.7.9-1.el6xen.x86_64 > > xen-hypervisor-4.2.1-4.el6.x86_64 > xen-runtime-4.2.1-4.el6.x86_64 > kernel-xen-release-6-4.noarch > xen-libs-4.2.1-4.el6.x86_64 > kernel-xen-firmware-3.7.9-1.el6xen.x86_64 > xen-4.2.1-4.el6.x86_64 > xen-licenses-4.2.1-4.el6.x86_64 > kernel-xen-3.7.9-1.el6xen.x86 > > grub.conf looks like this :- > > title CentOS (3.7.9-1.el6xen.x86_64) > root (hd0,0) > kernel /xen.gz dom0_mem=4000M cpufreq=xen dom0_max_vcpus=24 > dom0_vcpus_pin > module /vmlinuz-3.7.9-1.el6xen.x86_64 ro > root=UUID=eb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_NO_LVM > LANG=en_US.UTF-8 quiet SYSFONT=latarcyrheb-sun16 > rd_MD_UUID=79d39968:505cc18a:ee7a4c34:41b4a178 rhgb crashkernel=auto > KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM > module /initramfs-3.7.9-1.el6xen.x86_64.img > -Tarun > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --20cf30334ac324acc004d7625061 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What does 'xl info' show?


On Thu, Mar 7, 2013 at 4:41 PM, = Tarun Dua <tarundua@gmail.com> wrote:
I have the same problem on CentOS 6.3 :-
=
/proc/cpuinfo shows only 16 VCPUs.

It should have 24 VCPUs based= on the HW config:- Hyperthreaded 2 x Intel Xeon E5-2620

uname -a says :-

3.7.9-1.el6xen.x86_64

xen-hypervisor-4.2.1-4.el6.x86_64
xen-runtime-4.2.1-4.el6.x86_64
= kernel-xen-release-6-4.noarch
xen-libs-4.2.1-4.el6.x86_64
kernel-xen-= firmware-3.7.9-1.el6xen.x86_64
xen-4.2.1-4.el6.x86_64
xen-licenses-4.= 2.1-4.el6.x86_64
kernel-xen-3.7.9-1.el6xen.x86

grub.conf looks like this :-

ti= tle CentOS (3.7.9-1.el6xen.x86_64)
=A0=A0=A0=A0=A0=A0=A0 root (hd0,0)=A0=A0=A0=A0=A0=A0=A0 kernel /xen.gz dom0_mem=3D4000M cpufreq=3Dxen dom0_m= ax_vcpus=3D24 dom0_vcpus_pin
=A0=A0=A0=A0=A0=A0=A0 module /vmlinuz-3.7.9-1.el6xen.x86_64 ro root=3DUUID= =3Deb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_NO_LVM LANG=3Den_US.U= TF-8 quiet SYSFONT=3Dlatarcyrheb-sun16 rd_MD_UUID=3D79d39968:505cc18a:ee7a4= c34:41b4a178 rhgb crashkernel=3Dauto=A0 KEYBOARDTYPE=3Dpc KEYTABLE=3Dus rd_= NO_DM
=A0=A0=A0=A0=A0=A0=A0 module /initramfs-3.7.9-1.el6xen.x86_64.img
-Tarun

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--20cf30334ac324acc004d7625061-- --===============6357257664260013841== 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 --===============6357257664260013841==-- From xen-users-bounces@lists.xen.org Fri Mar 08 08:57:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 08:57:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDt5i-0001A7-0a; Fri, 08 Mar 2013 08:55:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDt5g-00019m-Qp for xen-users@lists.xen.org; Fri, 08 Mar 2013 08:55:49 +0000 Received: from [85.158.139.211:18409] by server-13.bemta-5.messagelabs.com id 93/66-16871-497A9315; Fri, 08 Mar 2013 08:55:48 +0000 X-Env-Sender: tarundua@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1362732935!18621475!1 X-Originating-IP: [209.85.128.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP, spamassassin: , async_handler: YXN5bmNfZGVsYXk6IDcwNDIwMDggKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30064 invoked from network); 8 Mar 2013 08:55:36 -0000 Received: from mail-ve0-f169.google.com (HELO mail-ve0-f169.google.com) (209.85.128.169) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 08:55:36 -0000 Received: by mail-ve0-f169.google.com with SMTP id 15so1088300vea.28 for ; Fri, 08 Mar 2013 00:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=+PCphP8h2LxKBAMiarDlD5lvSM8cO3n+I4R+SRhpcok=; b=aDre4L2JPoelkK1YtJfyv6iCUGD1qLeoMzEx/4y87NBpv+0hzgXuG5zwfvS3/p53kz iOsvGkWJXQY69pRRoX4F0BbQBTyobDqzrG6DPInIddscjVMKiIsdYrvwmnND4FU6Espf fsmVh+YxKPdT4IPjAXMdeKf0BHVvYL8E0mUxC16WGBs+HFbREi8w9DvFYMAnWgxMPMfT FNMTLc+9YCEgYaN1fyCQatZ9o38lgnL82qNUM9vJ1ejKN/2WIsSJ1l1CWXDjnqcGQama L5TYxLXS+ZQnxXKd2FPQleN2t68/zzX3iv7IDcrm77SPhvjFtH3BU4LX3kZ3ZGRmxvcE hwzw== MIME-Version: 1.0 X-Received: by 10.52.176.38 with SMTP id cf6mr494883vdc.132.1362732935336; Fri, 08 Mar 2013 00:55:35 -0800 (PST) Received: by 10.52.103.73 with HTTP; Fri, 8 Mar 2013 00:55:35 -0800 (PST) In-Reply-To: References: <20130305172238.GA11446@zion.uk.xensource.com> <20130306110805.GA13535@zion.uk.xensource.com> Date: Fri, 8 Mar 2013 14:25:35 +0530 Message-ID: From: Tarun Dua To: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============4061927342764924063==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4061927342764924063== Content-Type: multipart/alternative; boundary=bcaec5015cfb8907db04d765fcbd --bcaec5015cfb8907db04d765fcbd Content-Type: text/plain; charset=UTF-8 release : 3.7.9-1.el6xen.x86_64 version : #1 SMP Mon Feb 18 14:46:35 EST 2013 machine : x86_64 nr_cpus : 24 max_cpu_id : 127 nr_nodes : 1 cores_per_socket : 6 threads_per_core : 2 cpu_mhz : 1995 hw_caps : bfebfbff:2c100800:00000000:00003f40:17bee3ff:00000000:00000001:00000000 virt_caps : hvm total_memory : 65459 free_memory : 7246 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .1 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 : unavailable xen_commandline : dom0_mem=4000M cpufreq=xen dom0_max_vcpus=24 dom0_vcpus_pin cc_compiler : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) cc_compile_by : mockbuild cc_compile_domain : crc.id.au cc_compile_date : Sat Feb 16 19:16:38 EST 2013 xend_config_format : 4 On Fri, Mar 8, 2013 at 10:02 AM, Wayne Egerer wrote: > What does 'xl info' show? > > > On Thu, Mar 7, 2013 at 4:41 PM, Tarun Dua wrote: > >> I have the same problem on CentOS 6.3 :- >> >> /proc/cpuinfo shows only 16 VCPUs. >> >> It should have 24 VCPUs based on the HW config:- Hyperthreaded 2 x Intel >> Xeon E5-2620 >> >> uname -a says :- >> >> 3.7.9-1.el6xen.x86_64 >> >> xen-hypervisor-4.2.1-4.el6.x86_64 >> xen-runtime-4.2.1-4.el6.x86_64 >> kernel-xen-release-6-4.noarch >> xen-libs-4.2.1-4.el6.x86_64 >> kernel-xen-firmware-3.7.9-1.el6xen.x86_64 >> xen-4.2.1-4.el6.x86_64 >> xen-licenses-4.2.1-4.el6.x86_64 >> kernel-xen-3.7.9-1.el6xen.x86 >> >> grub.conf looks like this :- >> >> title CentOS (3.7.9-1.el6xen.x86_64) >> root (hd0,0) >> kernel /xen.gz dom0_mem=4000M cpufreq=xen dom0_max_vcpus=24 >> dom0_vcpus_pin >> module /vmlinuz-3.7.9-1.el6xen.x86_64 ro >> root=UUID=eb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_NO_LVM >> LANG=en_US.UTF-8 quiet SYSFONT=latarcyrheb-sun16 >> rd_MD_UUID=79d39968:505cc18a:ee7a4c34:41b4a178 rhgb crashkernel=auto >> KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM >> module /initramfs-3.7.9-1.el6xen.x86_64.img >> -Tarun >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users >> > > --bcaec5015cfb8907db04d765fcbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 cmVsZWFzZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDMuNy45LTEuZWw2eGVuLng4 Nl82NDxicj52ZXJzaW9uwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogIzEgU01QIE1v biBGZWIgMTggMTQ6NDY6MzUgRVNUIDIwMTM8YnI+bWFjaGluZcKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA6IHg4Nl82NDxicj5ucl9jcHVzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDogMjQ8YnI+bWF4X2NwdV9pZMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDEyNzxicj5u cl9ub2Rlc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiAxPGJyPg0KY29yZXNfcGVyX3Nv Y2tldMKgwqDCoMKgwqDCoCA6IDY8YnI+dGhyZWFkc19wZXJfY29yZcKgwqDCoMKgwqDCoCA6IDI8 YnI+Y3B1X21oesKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDE5OTU8YnI+aHdfY2Fw c8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IGJmZWJmYmZmOjJjMTAwODAwOjAwMDAw MDAwOjAwMDAzZjQwOjE3YmVlM2ZmOjAwMDAwMDAwOjAwMDAwMDAxOjAwMDAwMDAwPGJyPnZpcnRf Y2Fwc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogaHZtPGJyPg0KdG90YWxfbWVtb3J5wqDC oMKgwqDCoMKgwqDCoMKgwqAgOiA2NTQ1OTxicj5mcmVlX21lbW9yecKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgOiA3MjQ2PGJyPnNoYXJpbmdfZnJlZWRfbWVtb3J5wqDCoCA6IDA8YnI+c2hhcmluZ191 c2VkX21lbW9yecKgwqDCoCA6IDA8YnI+ZnJlZV9jcHVzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgOiAwPGJyPnhlbl9tYWpvcsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogNDxicj54ZW5f bWlub3LCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDI8YnI+eGVuX2V4dHJhwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgOiAuMTxicj4NCnhlbl9jYXBzwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCA6IHhlbi0zLjAteDg2XzY0IHhlbi0zLjAteDg2XzMycCBodm0tMy4wLXg4Nl8zMiBo dm0tMy4wLXg4Nl8zMnAgaHZtLTMuMC14ODZfNjQ8YnI+eGVuX3NjaGVkdWxlcsKgwqDCoMKgwqDC oMKgwqDCoCA6IGNyZWRpdDxicj54ZW5fcGFnZXNpemXCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDQw OTY8YnI+cGxhdGZvcm1fcGFyYW1zwqDCoMKgwqDCoMKgwqAgOiB2aXJ0X3N0YXJ0PTB4ZmZmZjgw MDAwMDAwMDAwMDxicj4NCnhlbl9jaGFuZ2VzZXTCoMKgwqDCoMKgwqDCoMKgwqAgOiB1bmF2YWls YWJsZTxicj54ZW5fY29tbWFuZGxpbmXCoMKgwqDCoMKgwqDCoCA6IGRvbTBfbWVtPTQwMDBNIGNw dWZyZXE9eGVuIGRvbTBfbWF4X3ZjcHVzPTI0IGRvbTBfdmNwdXNfcGluPGJyPmNjX2NvbXBpbGVy wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IGdjYyAoR0NDKSA0LjQuNiAyMDEyMDMwNSAoUmVkIEhh dCA0LjQuNi00KTxicj5jY19jb21waWxlX2J5wqDCoMKgwqDCoMKgwqDCoMKgIDogbW9ja2J1aWxk PGJyPg0KY2NfY29tcGlsZV9kb21haW7CoMKgwqDCoMKgIDogPGEgaHJlZj0iaHR0cDovL2NyYy5p ZC5hdSI+Y3JjLmlkLmF1PC9hPjxicj5jY19jb21waWxlX2RhdGXCoMKgwqDCoMKgwqDCoCA6IFNh dCBGZWIgMTYgMTk6MTY6MzggRVNUIDIwMTM8YnI+eGVuZF9jb25maWdfZm9ybWF0wqDCoMKgwqAg OiA0PGJyPjxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgTWFyIDgsIDIw MTMgYXQgMTA6MDIgQU0sIFdheW5lIEVnZXJlciA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9 Im1haWx0bzpwczJ3YXluZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wczJ3YXluZUBnbWFp bC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBkaXI9Imx0ciI+V2hhdCBkb2VzICYjMzk7eGwgaW5m byYjMzk7IHNob3c/PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48YnI+PGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPjxkaXY+PGRpdiBjbGFzcz0iaDUiPg0KT24gVGh1LCBNYXIgNywg MjAxMyBhdCA0OjQxIFBNLCBUYXJ1biBEdWEgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJt YWlsdG86dGFydW5kdWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFydW5kdWFAZ21haWwu Y29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjwvZGl2PjwvZGl2PjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXY+PGRpdiBjbGFzcz0iaDUiPkkgaGF2 ZSB0aGUgc2FtZSBwcm9ibGVtIG9uIENlbnRPUyA2LjMgOi08YnI+PGJyPi9wcm9jL2NwdWluZm8g c2hvd3Mgb25seSAxNiBWQ1BVcy48YnI+DQo8YnI+SXQgc2hvdWxkIGhhdmUgMjQgVkNQVXMgYmFz ZWQgb24gdGhlIEhXIGNvbmZpZzotIEh5cGVydGhyZWFkZWQgMiB4IEludGVsIFhlb24gRTUtMjYy MDxicj4NCjxicj51bmFtZSAtYSBzYXlzIDotPGJyPjxicj4zLjcuOS0xLmVsNnhlbi54ODZfNjQg PGJyPg0KPGJyPnhlbi1oeXBlcnZpc29yLTQuMi4xLTQuZWw2Lng4Nl82NDxicj54ZW4tcnVudGlt ZS00LjIuMS00LmVsNi54ODZfNjQ8YnI+a2VybmVsLXhlbi1yZWxlYXNlLTYtNC5ub2FyY2g8YnI+ eGVuLWxpYnMtNC4yLjEtNC5lbDYueDg2XzY0PGJyPmtlcm5lbC14ZW4tZmlybXdhcmUtMy43Ljkt MS5lbDZ4ZW4ueDg2XzY0PGJyPnhlbi00LjIuMS00LmVsNi54ODZfNjQ8YnI+eGVuLWxpY2Vuc2Vz LTQuMi4xLTQuZWw2Lng4Nl82NDxicj4NCg0KDQprZXJuZWwteGVuLTMuNy45LTEuZWw2eGVuLng4 Njxicj48YnI+Z3J1Yi5jb25mIGxvb2tzIGxpa2UgdGhpcyA6LTxicj48YnI+dGl0bGUgQ2VudE9T ICgzLjcuOS0xLmVsNnhlbi54ODZfNjQpPGJyPsKgwqDCoMKgwqDCoMKgIHJvb3QgKGhkMCwwKTxi cj7CoMKgwqDCoMKgwqDCoCBrZXJuZWwgL3hlbi5neiBkb20wX21lbT00MDAwTSBjcHVmcmVxPXhl biBkb20wX21heF92Y3B1cz0yNCBkb20wX3ZjcHVzX3Bpbjxicj4NCg0KDQrCoMKgwqDCoMKgwqDC oCBtb2R1bGUgL3ZtbGludXotMy43LjktMS5lbDZ4ZW4ueDg2XzY0IHJvIHJvb3Q9VVVJRD1lYjRk YjU4Yi02NTBhLTQ3ZGMtYThlMi05ZTdjYzY2ODA5MDMgcmRfTk9fTFVLUyByZF9OT19MVk0gTEFO Rz1lbl9VUy5VVEYtOCBxdWlldCBTWVNGT05UPWxhdGFyY3lyaGViLXN1bjE2IHJkX01EX1VVSUQ9 NzlkMzk5Njg6NTA1Y2MxOGE6ZWU3YTRjMzQ6NDFiNGExNzggcmhnYiBjcmFzaGtlcm5lbD1hdXRv wqAgS0VZQk9BUkRUWVBFPXBjIEtFWVRBQkxFPXVzIHJkX05PX0RNPGJyPg0KDQoNCsKgwqDCoMKg wqDCoMKgIG1vZHVsZSAvaW5pdHJhbWZzLTMuNy45LTEuZWw2eGVuLng4Nl82NC5pbWc8c3Bhbj48 Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPi1UYXJ1bjxicj4NCjwvZm9udD48L3NwYW4+PGJyPjwv ZGl2PjwvZGl2PjxkaXYgY2xhc3M9ImltIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NClhlbi11c2VycyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86WGVuLXVzZXJzQGxpc3RzLnhlbi5vcmciIHRhcmdldD0iX2JsYW5rIj5YZW4tdXNl cnNAbGlzdHMueGVuLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwOi8vbGlzdHMueGVuLm9yZy94 ZW4tdXNlcnMiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tdXNlcnM8 L2E+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+ PC9kaXY+PGJyPg0K --bcaec5015cfb8907db04d765fcbd-- --===============4061927342764924063== 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 --===============4061927342764924063==-- From xen-users-bounces@lists.xen.org Fri Mar 08 08:57:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 08:57:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDt5i-0001A7-0a; Fri, 08 Mar 2013 08:55:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDt5g-00019m-Qp for xen-users@lists.xen.org; Fri, 08 Mar 2013 08:55:49 +0000 Received: from [85.158.139.211:18409] by server-13.bemta-5.messagelabs.com id 93/66-16871-497A9315; Fri, 08 Mar 2013 08:55:48 +0000 X-Env-Sender: tarundua@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1362732935!18621475!1 X-Originating-IP: [209.85.128.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP, spamassassin: , async_handler: YXN5bmNfZGVsYXk6IDcwNDIwMDggKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30064 invoked from network); 8 Mar 2013 08:55:36 -0000 Received: from mail-ve0-f169.google.com (HELO mail-ve0-f169.google.com) (209.85.128.169) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 08:55:36 -0000 Received: by mail-ve0-f169.google.com with SMTP id 15so1088300vea.28 for ; Fri, 08 Mar 2013 00:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=+PCphP8h2LxKBAMiarDlD5lvSM8cO3n+I4R+SRhpcok=; b=aDre4L2JPoelkK1YtJfyv6iCUGD1qLeoMzEx/4y87NBpv+0hzgXuG5zwfvS3/p53kz iOsvGkWJXQY69pRRoX4F0BbQBTyobDqzrG6DPInIddscjVMKiIsdYrvwmnND4FU6Espf fsmVh+YxKPdT4IPjAXMdeKf0BHVvYL8E0mUxC16WGBs+HFbREi8w9DvFYMAnWgxMPMfT FNMTLc+9YCEgYaN1fyCQatZ9o38lgnL82qNUM9vJ1ejKN/2WIsSJ1l1CWXDjnqcGQama L5TYxLXS+ZQnxXKd2FPQleN2t68/zzX3iv7IDcrm77SPhvjFtH3BU4LX3kZ3ZGRmxvcE hwzw== MIME-Version: 1.0 X-Received: by 10.52.176.38 with SMTP id cf6mr494883vdc.132.1362732935336; Fri, 08 Mar 2013 00:55:35 -0800 (PST) Received: by 10.52.103.73 with HTTP; Fri, 8 Mar 2013 00:55:35 -0800 (PST) In-Reply-To: References: <20130305172238.GA11446@zion.uk.xensource.com> <20130306110805.GA13535@zion.uk.xensource.com> Date: Fri, 8 Mar 2013 14:25:35 +0530 Message-ID: From: Tarun Dua To: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============4061927342764924063==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4061927342764924063== Content-Type: multipart/alternative; boundary=bcaec5015cfb8907db04d765fcbd --bcaec5015cfb8907db04d765fcbd Content-Type: text/plain; charset=UTF-8 release : 3.7.9-1.el6xen.x86_64 version : #1 SMP Mon Feb 18 14:46:35 EST 2013 machine : x86_64 nr_cpus : 24 max_cpu_id : 127 nr_nodes : 1 cores_per_socket : 6 threads_per_core : 2 cpu_mhz : 1995 hw_caps : bfebfbff:2c100800:00000000:00003f40:17bee3ff:00000000:00000001:00000000 virt_caps : hvm total_memory : 65459 free_memory : 7246 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .1 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 : unavailable xen_commandline : dom0_mem=4000M cpufreq=xen dom0_max_vcpus=24 dom0_vcpus_pin cc_compiler : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) cc_compile_by : mockbuild cc_compile_domain : crc.id.au cc_compile_date : Sat Feb 16 19:16:38 EST 2013 xend_config_format : 4 On Fri, Mar 8, 2013 at 10:02 AM, Wayne Egerer wrote: > What does 'xl info' show? > > > On Thu, Mar 7, 2013 at 4:41 PM, Tarun Dua wrote: > >> I have the same problem on CentOS 6.3 :- >> >> /proc/cpuinfo shows only 16 VCPUs. >> >> It should have 24 VCPUs based on the HW config:- Hyperthreaded 2 x Intel >> Xeon E5-2620 >> >> uname -a says :- >> >> 3.7.9-1.el6xen.x86_64 >> >> xen-hypervisor-4.2.1-4.el6.x86_64 >> xen-runtime-4.2.1-4.el6.x86_64 >> kernel-xen-release-6-4.noarch >> xen-libs-4.2.1-4.el6.x86_64 >> kernel-xen-firmware-3.7.9-1.el6xen.x86_64 >> xen-4.2.1-4.el6.x86_64 >> xen-licenses-4.2.1-4.el6.x86_64 >> kernel-xen-3.7.9-1.el6xen.x86 >> >> grub.conf looks like this :- >> >> title CentOS (3.7.9-1.el6xen.x86_64) >> root (hd0,0) >> kernel /xen.gz dom0_mem=4000M cpufreq=xen dom0_max_vcpus=24 >> dom0_vcpus_pin >> module /vmlinuz-3.7.9-1.el6xen.x86_64 ro >> root=UUID=eb4db58b-650a-47dc-a8e2-9e7cc6680903 rd_NO_LUKS rd_NO_LVM >> LANG=en_US.UTF-8 quiet SYSFONT=latarcyrheb-sun16 >> rd_MD_UUID=79d39968:505cc18a:ee7a4c34:41b4a178 rhgb crashkernel=auto >> KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM >> module /initramfs-3.7.9-1.el6xen.x86_64.img >> -Tarun >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users >> > > --bcaec5015cfb8907db04d765fcbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 cmVsZWFzZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDMuNy45LTEuZWw2eGVuLng4 Nl82NDxicj52ZXJzaW9uwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogIzEgU01QIE1v biBGZWIgMTggMTQ6NDY6MzUgRVNUIDIwMTM8YnI+bWFjaGluZcKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA6IHg4Nl82NDxicj5ucl9jcHVzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDogMjQ8YnI+bWF4X2NwdV9pZMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDEyNzxicj5u cl9ub2Rlc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiAxPGJyPg0KY29yZXNfcGVyX3Nv Y2tldMKgwqDCoMKgwqDCoCA6IDY8YnI+dGhyZWFkc19wZXJfY29yZcKgwqDCoMKgwqDCoCA6IDI8 YnI+Y3B1X21oesKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDE5OTU8YnI+aHdfY2Fw c8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IGJmZWJmYmZmOjJjMTAwODAwOjAwMDAw MDAwOjAwMDAzZjQwOjE3YmVlM2ZmOjAwMDAwMDAwOjAwMDAwMDAxOjAwMDAwMDAwPGJyPnZpcnRf Y2Fwc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogaHZtPGJyPg0KdG90YWxfbWVtb3J5wqDC oMKgwqDCoMKgwqDCoMKgwqAgOiA2NTQ1OTxicj5mcmVlX21lbW9yecKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgOiA3MjQ2PGJyPnNoYXJpbmdfZnJlZWRfbWVtb3J5wqDCoCA6IDA8YnI+c2hhcmluZ191 c2VkX21lbW9yecKgwqDCoCA6IDA8YnI+ZnJlZV9jcHVzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgOiAwPGJyPnhlbl9tYWpvcsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogNDxicj54ZW5f bWlub3LCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDI8YnI+eGVuX2V4dHJhwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgOiAuMTxicj4NCnhlbl9jYXBzwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCA6IHhlbi0zLjAteDg2XzY0IHhlbi0zLjAteDg2XzMycCBodm0tMy4wLXg4Nl8zMiBo dm0tMy4wLXg4Nl8zMnAgaHZtLTMuMC14ODZfNjQ8YnI+eGVuX3NjaGVkdWxlcsKgwqDCoMKgwqDC oMKgwqDCoCA6IGNyZWRpdDxicj54ZW5fcGFnZXNpemXCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IDQw OTY8YnI+cGxhdGZvcm1fcGFyYW1zwqDCoMKgwqDCoMKgwqAgOiB2aXJ0X3N0YXJ0PTB4ZmZmZjgw MDAwMDAwMDAwMDxicj4NCnhlbl9jaGFuZ2VzZXTCoMKgwqDCoMKgwqDCoMKgwqAgOiB1bmF2YWls YWJsZTxicj54ZW5fY29tbWFuZGxpbmXCoMKgwqDCoMKgwqDCoCA6IGRvbTBfbWVtPTQwMDBNIGNw dWZyZXE9eGVuIGRvbTBfbWF4X3ZjcHVzPTI0IGRvbTBfdmNwdXNfcGluPGJyPmNjX2NvbXBpbGVy wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IGdjYyAoR0NDKSA0LjQuNiAyMDEyMDMwNSAoUmVkIEhh dCA0LjQuNi00KTxicj5jY19jb21waWxlX2J5wqDCoMKgwqDCoMKgwqDCoMKgIDogbW9ja2J1aWxk PGJyPg0KY2NfY29tcGlsZV9kb21haW7CoMKgwqDCoMKgIDogPGEgaHJlZj0iaHR0cDovL2NyYy5p ZC5hdSI+Y3JjLmlkLmF1PC9hPjxicj5jY19jb21waWxlX2RhdGXCoMKgwqDCoMKgwqDCoCA6IFNh dCBGZWIgMTYgMTk6MTY6MzggRVNUIDIwMTM8YnI+eGVuZF9jb25maWdfZm9ybWF0wqDCoMKgwqAg OiA0PGJyPjxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgTWFyIDgsIDIw MTMgYXQgMTA6MDIgQU0sIFdheW5lIEVnZXJlciA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9 Im1haWx0bzpwczJ3YXluZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wczJ3YXluZUBnbWFp bC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBkaXI9Imx0ciI+V2hhdCBkb2VzICYjMzk7eGwgaW5m byYjMzk7IHNob3c/PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48YnI+PGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPjxkaXY+PGRpdiBjbGFzcz0iaDUiPg0KT24gVGh1LCBNYXIgNywg MjAxMyBhdCA0OjQxIFBNLCBUYXJ1biBEdWEgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJt YWlsdG86dGFydW5kdWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFydW5kdWFAZ21haWwu Y29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjwvZGl2PjwvZGl2PjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXY+PGRpdiBjbGFzcz0iaDUiPkkgaGF2 ZSB0aGUgc2FtZSBwcm9ibGVtIG9uIENlbnRPUyA2LjMgOi08YnI+PGJyPi9wcm9jL2NwdWluZm8g c2hvd3Mgb25seSAxNiBWQ1BVcy48YnI+DQo8YnI+SXQgc2hvdWxkIGhhdmUgMjQgVkNQVXMgYmFz ZWQgb24gdGhlIEhXIGNvbmZpZzotIEh5cGVydGhyZWFkZWQgMiB4IEludGVsIFhlb24gRTUtMjYy MDxicj4NCjxicj51bmFtZSAtYSBzYXlzIDotPGJyPjxicj4zLjcuOS0xLmVsNnhlbi54ODZfNjQg PGJyPg0KPGJyPnhlbi1oeXBlcnZpc29yLTQuMi4xLTQuZWw2Lng4Nl82NDxicj54ZW4tcnVudGlt ZS00LjIuMS00LmVsNi54ODZfNjQ8YnI+a2VybmVsLXhlbi1yZWxlYXNlLTYtNC5ub2FyY2g8YnI+ eGVuLWxpYnMtNC4yLjEtNC5lbDYueDg2XzY0PGJyPmtlcm5lbC14ZW4tZmlybXdhcmUtMy43Ljkt MS5lbDZ4ZW4ueDg2XzY0PGJyPnhlbi00LjIuMS00LmVsNi54ODZfNjQ8YnI+eGVuLWxpY2Vuc2Vz LTQuMi4xLTQuZWw2Lng4Nl82NDxicj4NCg0KDQprZXJuZWwteGVuLTMuNy45LTEuZWw2eGVuLng4 Njxicj48YnI+Z3J1Yi5jb25mIGxvb2tzIGxpa2UgdGhpcyA6LTxicj48YnI+dGl0bGUgQ2VudE9T ICgzLjcuOS0xLmVsNnhlbi54ODZfNjQpPGJyPsKgwqDCoMKgwqDCoMKgIHJvb3QgKGhkMCwwKTxi cj7CoMKgwqDCoMKgwqDCoCBrZXJuZWwgL3hlbi5neiBkb20wX21lbT00MDAwTSBjcHVmcmVxPXhl biBkb20wX21heF92Y3B1cz0yNCBkb20wX3ZjcHVzX3Bpbjxicj4NCg0KDQrCoMKgwqDCoMKgwqDC oCBtb2R1bGUgL3ZtbGludXotMy43LjktMS5lbDZ4ZW4ueDg2XzY0IHJvIHJvb3Q9VVVJRD1lYjRk YjU4Yi02NTBhLTQ3ZGMtYThlMi05ZTdjYzY2ODA5MDMgcmRfTk9fTFVLUyByZF9OT19MVk0gTEFO Rz1lbl9VUy5VVEYtOCBxdWlldCBTWVNGT05UPWxhdGFyY3lyaGViLXN1bjE2IHJkX01EX1VVSUQ9 NzlkMzk5Njg6NTA1Y2MxOGE6ZWU3YTRjMzQ6NDFiNGExNzggcmhnYiBjcmFzaGtlcm5lbD1hdXRv wqAgS0VZQk9BUkRUWVBFPXBjIEtFWVRBQkxFPXVzIHJkX05PX0RNPGJyPg0KDQoNCsKgwqDCoMKg wqDCoMKgIG1vZHVsZSAvaW5pdHJhbWZzLTMuNy45LTEuZWw2eGVuLng4Nl82NC5pbWc8c3Bhbj48 Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPi1UYXJ1bjxicj4NCjwvZm9udD48L3NwYW4+PGJyPjwv ZGl2PjwvZGl2PjxkaXYgY2xhc3M9ImltIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NClhlbi11c2VycyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86WGVuLXVzZXJzQGxpc3RzLnhlbi5vcmciIHRhcmdldD0iX2JsYW5rIj5YZW4tdXNl cnNAbGlzdHMueGVuLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwOi8vbGlzdHMueGVuLm9yZy94 ZW4tdXNlcnMiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tdXNlcnM8 L2E+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+ PC9kaXY+PGJyPg0K --bcaec5015cfb8907db04d765fcbd-- --===============4061927342764924063== 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 --===============4061927342764924063==-- From xen-users-bounces@lists.xen.org Fri Mar 08 08:57:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 08:57: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 1UDt68-0001DD-P1; Fri, 08 Mar 2013 08:56:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDt67-0001Cs-9K for xen-users@lists.xen.org; Fri, 08 Mar 2013 08:56:15 +0000 Received: from [193.109.254.147:49050] by server-16.bemta-14.messagelabs.com id 3E/14-20064-EA7A9315; Fri, 08 Mar 2013 08:56:14 +0000 X-Env-Sender: tarundua@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1362732970!9188886!1 X-Originating-IP: [209.85.220.182] X-SpamReason: No, hits=2.5 required=7.0 tests=HTML_40_50,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21253 invoked from network); 8 Mar 2013 08:56:12 -0000 Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com) (209.85.220.182) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 08:56:12 -0000 Received: by mail-vc0-f182.google.com with SMTP id fl17so788200vcb.13 for ; Fri, 08 Mar 2013 00:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=axn0tlOlMcgf+0mCStI1oN9jKpp0bigpBXUL2RAedmU=; b=B9FbuftQyQYMgOX8KCop9Z1Fct7ZF5ihI/qd7GuIWkFxqZiCqqPIuZ7qoS0TQnOu8W mSdicm4dLK4NvZB5zfmq1PPN7ki4COxwCA3IPHh2eRmlmBEjWp98+wDkfFMVKSSLkmpi vkKCpN6Osus/7kETl1B99OLJjvdsonW9Fuf1zrwdgJ0Wmq6gMos/Ahyi9k84Wmhpf8TV I2zo+Hj3Lx7JvWAUDM3jMRafvCvPIhpl/x2UiOqC2ZTU6EDe+tqdeMmAhA1EWzGDCcEz 1mFF6G83CHs/WVkUZ2jSxjckrDiUE4zYhemvZprz89xUrEUzpfuhEyjJEcD743vNT2JQ m5lA== MIME-Version: 1.0 X-Received: by 10.52.98.5 with SMTP id ee5mr515619vdb.102.1362732970771; Fri, 08 Mar 2013 00:56:10 -0800 (PST) Received: by 10.52.103.73 with HTTP; Fri, 8 Mar 2013 00:56:10 -0800 (PST) In-Reply-To: References: <20130305172238.GA11446@zion.uk.xensource.com> <20130306110805.GA13535@zion.uk.xensource.com> Date: Fri, 8 Mar 2013 14:26:10 +0530 Message-ID: From: Tarun Dua To: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============3055587220500290262==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3055587220500290262== Content-Type: multipart/alternative; boundary=20cf307f34a6a5be0a04d765fe43 --20cf307f34a6a5be0a04d765fe43 Content-Type: text/plain; charset=UTF-8 My apologies for top-posting. Regards -Tarun --20cf307f34a6a5be0a04d765fe43 Content-Type: text/html; charset=UTF-8 My apologies for top-posting.
<SNIP>
Regards
-Tarun

--20cf307f34a6a5be0a04d765fe43-- --===============3055587220500290262== 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 --===============3055587220500290262==-- From xen-users-bounces@lists.xen.org Fri Mar 08 08:57:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 08:57: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 1UDt68-0001DD-P1; Fri, 08 Mar 2013 08:56:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDt67-0001Cs-9K for xen-users@lists.xen.org; Fri, 08 Mar 2013 08:56:15 +0000 Received: from [193.109.254.147:49050] by server-16.bemta-14.messagelabs.com id 3E/14-20064-EA7A9315; Fri, 08 Mar 2013 08:56:14 +0000 X-Env-Sender: tarundua@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1362732970!9188886!1 X-Originating-IP: [209.85.220.182] X-SpamReason: No, hits=2.5 required=7.0 tests=HTML_40_50,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21253 invoked from network); 8 Mar 2013 08:56:12 -0000 Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com) (209.85.220.182) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 08:56:12 -0000 Received: by mail-vc0-f182.google.com with SMTP id fl17so788200vcb.13 for ; Fri, 08 Mar 2013 00:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=axn0tlOlMcgf+0mCStI1oN9jKpp0bigpBXUL2RAedmU=; b=B9FbuftQyQYMgOX8KCop9Z1Fct7ZF5ihI/qd7GuIWkFxqZiCqqPIuZ7qoS0TQnOu8W mSdicm4dLK4NvZB5zfmq1PPN7ki4COxwCA3IPHh2eRmlmBEjWp98+wDkfFMVKSSLkmpi vkKCpN6Osus/7kETl1B99OLJjvdsonW9Fuf1zrwdgJ0Wmq6gMos/Ahyi9k84Wmhpf8TV I2zo+Hj3Lx7JvWAUDM3jMRafvCvPIhpl/x2UiOqC2ZTU6EDe+tqdeMmAhA1EWzGDCcEz 1mFF6G83CHs/WVkUZ2jSxjckrDiUE4zYhemvZprz89xUrEUzpfuhEyjJEcD743vNT2JQ m5lA== MIME-Version: 1.0 X-Received: by 10.52.98.5 with SMTP id ee5mr515619vdb.102.1362732970771; Fri, 08 Mar 2013 00:56:10 -0800 (PST) Received: by 10.52.103.73 with HTTP; Fri, 8 Mar 2013 00:56:10 -0800 (PST) In-Reply-To: References: <20130305172238.GA11446@zion.uk.xensource.com> <20130306110805.GA13535@zion.uk.xensource.com> Date: Fri, 8 Mar 2013 14:26:10 +0530 Message-ID: From: Tarun Dua To: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============3055587220500290262==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3055587220500290262== Content-Type: multipart/alternative; boundary=20cf307f34a6a5be0a04d765fe43 --20cf307f34a6a5be0a04d765fe43 Content-Type: text/plain; charset=UTF-8 My apologies for top-posting. Regards -Tarun --20cf307f34a6a5be0a04d765fe43 Content-Type: text/html; charset=UTF-8 My apologies for top-posting.
<SNIP>
Regards
-Tarun

--20cf307f34a6a5be0a04d765fe43-- --===============3055587220500290262== 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 --===============3055587220500290262==-- From xen-users-bounces@lists.xen.org Fri Mar 08 10:56:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 10:56: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 1UDuxN-00051K-36; Fri, 08 Mar 2013 10:55:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDuxL-000518-2u for xen-users@lists.xensource.com; Fri, 08 Mar 2013 10:55:19 +0000 Received: from [85.158.143.99:11104] by server-2.bemta-4.messagelabs.com id F8/C8-12656-693C9315; Fri, 08 Mar 2013 10:55:18 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-16.tower-216.messagelabs.com!1362740111!16325910!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29512 invoked from network); 8 Mar 2013 10:55:12 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 8 Mar 2013 10:55:12 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UDuxC-00024B-3H for xen-users@lists.xensource.com; Fri, 08 Mar 2013 02:55:10 -0800 Date: Fri, 8 Mar 2013 02:55:10 -0800 (PST) From: Fantu To: xen-users@lists.xensource.com Message-ID: <1362740110070-5714696.post@n5.nabble.com> In-Reply-To: <001f01ce1b5a$0f711980$2e534c80$@gmail.com> References: <001f01ce1b5a$0f711980$2e534c80$@gmail.com> MIME-Version: 1.0 Subject: Re: [Xen-users] qdisk and blktap X-BeenThere: xen-users@lists.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 You must install blktap package (blktap-dkms) if not already done and insert it on /etc/mudules. You must also change from file to tap2 or use new disk configuration instead of deprecated: http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt -- View this message in context: http://xen.1045712.n5.nabble.com/qdisk-and-blktap-tp5714679p5714696.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 Fri Mar 08 10:56:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 10:56: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 1UDuxN-00051K-36; Fri, 08 Mar 2013 10:55:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UDuxL-000518-2u for xen-users@lists.xensource.com; Fri, 08 Mar 2013 10:55:19 +0000 Received: from [85.158.143.99:11104] by server-2.bemta-4.messagelabs.com id F8/C8-12656-693C9315; Fri, 08 Mar 2013 10:55:18 +0000 X-Env-Sender: fantonifabio@tiscali.it X-Msg-Ref: server-16.tower-216.messagelabs.com!1362740111!16325910!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29512 invoked from network); 8 Mar 2013 10:55:12 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-16.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 8 Mar 2013 10:55:12 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UDuxC-00024B-3H for xen-users@lists.xensource.com; Fri, 08 Mar 2013 02:55:10 -0800 Date: Fri, 8 Mar 2013 02:55:10 -0800 (PST) From: Fantu To: xen-users@lists.xensource.com Message-ID: <1362740110070-5714696.post@n5.nabble.com> In-Reply-To: <001f01ce1b5a$0f711980$2e534c80$@gmail.com> References: <001f01ce1b5a$0f711980$2e534c80$@gmail.com> MIME-Version: 1.0 Subject: Re: [Xen-users] qdisk and blktap X-BeenThere: xen-users@lists.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 You must install blktap package (blktap-dkms) if not already done and insert it on /etc/mudules. You must also change from file to tap2 or use new disk configuration instead of deprecated: http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt -- View this message in context: http://xen.1045712.n5.nabble.com/qdisk-and-blktap-tp5714679p5714696.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 Fri Mar 08 18:35:54 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 18:35: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 1UE27t-0008J6-1g; Fri, 08 Mar 2013 18:34:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE27r-0008J1-8e for xen-users@lists.xen.org; Fri, 08 Mar 2013 18:34:39 +0000 Received: from [85.158.143.99:53083] by server-3.bemta-4.messagelabs.com id 54/A9-02186-E3F2A315; Fri, 08 Mar 2013 18:34:38 +0000 X-Env-Sender: paul@stimpsonfamily.co.uk X-Msg-Ref: server-6.tower-216.messagelabs.com!1362767678!20561065!1 X-Originating-IP: [94.136.40.61] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNjE1NjY=\n,sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNjE1NjY=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31527 invoked from network); 8 Mar 2013 18:34:38 -0000 Received: from mailex.mailcore.me (HELO mailex.mailcore.me) (94.136.40.61) by server-6.tower-216.messagelabs.com with SMTP; 8 Mar 2013 18:34:38 -0000 Received: from [192.165.210.4] (helo=[192.168.225.223]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UE27p-0000Ev-PW for xen-users@lists.xen.org; Fri, 08 Mar 2013 18:34:38 +0000 Message-ID: <513A2F3D.9050100@stimpsonfamily.co.uk> Date: Fri, 08 Mar 2013 18:34:37 +0000 From: Paul Stimpson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Mailcore-Auth: 8324857 X-Mailcore-Domain: 844183 Subject: [Xen-users] Imaging complete Xen installs X-BeenThere: xen-users@lists.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, I'm helping to create an appliance which consists of an Ubuntu host, a number of Ubuntu guests and a Windows server guest. We've been using Clonezilla to image the machine but it is performing badly in terms of image size and restore times. The filesystem on the boot drive is an LVM 2 container containing multiple ext3/4 and an NTFS FS. We want to do a full disk image including the boot sector and partition table. When we do a "savedisk", Clonezilla is complaining that it can't intelligently backup any of the ext or NTFS volumes because they're within an LVM container so it's just doing a dd and then gzipping it. We've tried zerofree and this does make things better but it's nowhere near as good as a real intelligent backup. Clonezilla makes it sound like LVM isn't supported but the first thing it says when you start the backup is that it's unmounting the LVM volumes. Can anyone please recommend a better backup program that is preferably free software or a better way of using Clonezilla so I can get the backup down to a more manageable size? Thanks, Paul. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 08 18:35:54 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 18:35: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 1UE27t-0008J6-1g; Fri, 08 Mar 2013 18:34:41 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE27r-0008J1-8e for xen-users@lists.xen.org; Fri, 08 Mar 2013 18:34:39 +0000 Received: from [85.158.143.99:53083] by server-3.bemta-4.messagelabs.com id 54/A9-02186-E3F2A315; Fri, 08 Mar 2013 18:34:38 +0000 X-Env-Sender: paul@stimpsonfamily.co.uk X-Msg-Ref: server-6.tower-216.messagelabs.com!1362767678!20561065!1 X-Originating-IP: [94.136.40.61] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNjE1NjY=\n,sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNjE1NjY=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31527 invoked from network); 8 Mar 2013 18:34:38 -0000 Received: from mailex.mailcore.me (HELO mailex.mailcore.me) (94.136.40.61) by server-6.tower-216.messagelabs.com with SMTP; 8 Mar 2013 18:34:38 -0000 Received: from [192.165.210.4] (helo=[192.168.225.223]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UE27p-0000Ev-PW for xen-users@lists.xen.org; Fri, 08 Mar 2013 18:34:38 +0000 Message-ID: <513A2F3D.9050100@stimpsonfamily.co.uk> Date: Fri, 08 Mar 2013 18:34:37 +0000 From: Paul Stimpson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Mailcore-Auth: 8324857 X-Mailcore-Domain: 844183 Subject: [Xen-users] Imaging complete Xen installs X-BeenThere: xen-users@lists.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, I'm helping to create an appliance which consists of an Ubuntu host, a number of Ubuntu guests and a Windows server guest. We've been using Clonezilla to image the machine but it is performing badly in terms of image size and restore times. The filesystem on the boot drive is an LVM 2 container containing multiple ext3/4 and an NTFS FS. We want to do a full disk image including the boot sector and partition table. When we do a "savedisk", Clonezilla is complaining that it can't intelligently backup any of the ext or NTFS volumes because they're within an LVM container so it's just doing a dd and then gzipping it. We've tried zerofree and this does make things better but it's nowhere near as good as a real intelligent backup. Clonezilla makes it sound like LVM isn't supported but the first thing it says when you start the backup is that it's unmounting the LVM volumes. Can anyone please recommend a better backup program that is preferably free software or a better way of using Clonezilla so I can get the backup down to a more manageable size? Thanks, Paul. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 08 20:24:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 20:24: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 1UE3pH-0001YF-G2; Fri, 08 Mar 2013 20:23:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE3pF-0001YA-9m for xen-users@lists.xen.org; Fri, 08 Mar 2013 20:23:33 +0000 Received: from [85.158.137.99:55758] by server-8.bemta-3.messagelabs.com id B6/5A-20604-4C84A315; Fri, 08 Mar 2013 20:23:32 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1362774210!14313767!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23067 invoked from network); 8 Mar 2013 20:23:31 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Mar 2013 20:23:31 -0000 Received: from [201.122.115.101] (port=37668 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UE3pB-0006lA-FH for xen-users@lists.xen.org; Fri, 08 Mar 2013 14:23:29 -0600 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id D9F7AA209 for ; Fri, 8 Mar 2013 14:18:40 -0600 (CST) Message-ID: <513A48BF.5050809@ondore.com> Date: Fri, 08 Mar 2013 14:23:27 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <513A2F3D.9050100@stimpsonfamily.co.uk> In-Reply-To: <513A2F3D.9050100@stimpsonfamily.co.uk> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Imaging complete Xen installs X-BeenThere: xen-users@lists.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 Hello. El 08/03/13 12:34, Paul Stimpson escribi=F3: > I'm helping to create an appliance which consists of an Ubuntu host, a > number of Ubuntu guests and a Windows server guest. We've been using > Clonezilla to image the machine but it is performing badly in terms of > image size and restore times. Consider using partimage, at least for NTFS formatted devices. Since = your storage volumes are heterogeneous, I would suggest making a = separate image of each volume, this would allow the backup utility to = figure out the FS type and make the corresponding optimizations. Your restore script would need to partition the physical device, create = the LVM structure, and then restore each image on it's place. > Can anyone please recommend a better backup program that is preferably > free software or a better way of using Clonezilla so I can get the > backup down to a more manageable size? Can't think of any, that could handle well the mix of different type of = FS, specially if they lay over LVM. A home-made wrapper that could = handle each image separately does not seems to be too complex, unless = you are looking for something "really abstract and flexible". Don't forget to consider the cost of the storage media, needed to handle = simple dd+gz dumps, against the cost of time and dedication to create = the wrapper. I can't say which will come out a better option, but it's = definitely something worth to evaluate. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 08 20:24:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 20:24: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 1UE3pH-0001YF-G2; Fri, 08 Mar 2013 20:23:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE3pF-0001YA-9m for xen-users@lists.xen.org; Fri, 08 Mar 2013 20:23:33 +0000 Received: from [85.158.137.99:55758] by server-8.bemta-3.messagelabs.com id B6/5A-20604-4C84A315; Fri, 08 Mar 2013 20:23:32 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1362774210!14313767!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23067 invoked from network); 8 Mar 2013 20:23:31 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Mar 2013 20:23:31 -0000 Received: from [201.122.115.101] (port=37668 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UE3pB-0006lA-FH for xen-users@lists.xen.org; Fri, 08 Mar 2013 14:23:29 -0600 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id D9F7AA209 for ; Fri, 8 Mar 2013 14:18:40 -0600 (CST) Message-ID: <513A48BF.5050809@ondore.com> Date: Fri, 08 Mar 2013 14:23:27 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <513A2F3D.9050100@stimpsonfamily.co.uk> In-Reply-To: <513A2F3D.9050100@stimpsonfamily.co.uk> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Imaging complete Xen installs X-BeenThere: xen-users@lists.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 Hello. El 08/03/13 12:34, Paul Stimpson escribi=F3: > I'm helping to create an appliance which consists of an Ubuntu host, a > number of Ubuntu guests and a Windows server guest. We've been using > Clonezilla to image the machine but it is performing badly in terms of > image size and restore times. Consider using partimage, at least for NTFS formatted devices. Since = your storage volumes are heterogeneous, I would suggest making a = separate image of each volume, this would allow the backup utility to = figure out the FS type and make the corresponding optimizations. Your restore script would need to partition the physical device, create = the LVM structure, and then restore each image on it's place. > Can anyone please recommend a better backup program that is preferably > free software or a better way of using Clonezilla so I can get the > backup down to a more manageable size? Can't think of any, that could handle well the mix of different type of = FS, specially if they lay over LVM. A home-made wrapper that could = handle each image separately does not seems to be too complex, unless = you are looking for something "really abstract and flexible". Don't forget to consider the cost of the storage media, needed to handle = simple dd+gz dumps, against the cost of time and dedication to create = the wrapper. I can't say which will come out a better option, but it's = definitely something worth to evaluate. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 08 23:40:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 23:40: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 1UE6t6-0005UM-6q; Fri, 08 Mar 2013 23:39:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE5wv-0003dy-MM for xen-users@lists.xen.org; Fri, 08 Mar 2013 22:39:37 +0000 Received: from [85.158.139.211:10705] by server-14.bemta-5.messagelabs.com id DA/9B-13158-8A86A315; Fri, 08 Mar 2013 22:39:36 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1362782375!14695684!1 X-Originating-IP: [209.85.215.65] 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.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22082 invoked from network); 8 Mar 2013 22:39:36 -0000 Received: from mail-la0-f65.google.com (HELO mail-la0-f65.google.com) (209.85.215.65) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 22:39:36 -0000 Received: by mail-la0-f65.google.com with SMTP id fq12so468711lab.4 for ; Fri, 08 Mar 2013 14:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=oTeZCy7khP4ALFBJs6M3zimw7CO3w4zsPpMwgfDZ35o=; b=f/753sdllexYAg/ybYdf0IBwow4sY9Ge7ZPC/NT0w29HMTKMFS/2T7XbDzQ+Uu4H4V Jgnb8GX+YMBN16UDUQdXohvCjX7qEHnEaYZYGO8LZMEJab0YiUXm6Vbo6/YFgH32Fd3Z zVN9CDGuspuFVMqD6b57uiYMxyNoTJ+3xFZCdtM9S6kRI7csHhKIMv6K3CMDFzlZzRz0 cNQqm7c7Ajh1GoHAxKbdvbU9WdKQ+mDW0JgDRlvK9UW2WJd9uBYkgh2v+95FlfV4EpWj yGWtW295fiOq0LXVIORel/mzN8FNS4odpe/qbrim0F9R1vLry24Qu3ykSf3DaA7edXed ytMA== MIME-Version: 1.0 X-Received: by 10.152.146.199 with SMTP id te7mr3447231lab.23.1362782375644; Fri, 08 Mar 2013 14:39:35 -0800 (PST) Received: by 10.112.13.3 with HTTP; Fri, 8 Mar 2013 14:39:35 -0800 (PST) Date: Fri, 8 Mar 2013 17:39:35 -0500 X-Google-Sender-Auth: 7nguTQoJWqkarVVEZClprt4Q5VA Message-ID: From: Russ Pavlicek To: xen-users@lists.xen.org X-Mailman-Approved-At: Fri, 08 Mar 2013 23:39:41 +0000 Subject: [Xen-users] Xen Hackathon hosted by Google, May 16-17 in Dublin X-BeenThere: xen-users@lists.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="===============5274997709239928634==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5274997709239928634== Content-Type: multipart/alternative; boundary=e89a8f22c55568124704d7717fcd --e89a8f22c55568124704d7717fcd Content-Type: text/plain; charset=ISO-8859-1 It's time for another Xen Hackathon! This year's event will be held May 16-17 in Dublin, Ireland. Details can be found here: http://blog.xen.org/index.php/2013/03/07/google-hosted-xen-hackathon-may-16-17-dublin/ Thanks, Russell Pavlicek Xen Evangelist --e89a8f22c55568124704d7717fcd Content-Type: text/html; charset=ISO-8859-1
It's time for another Xen Hackathon!

This year's event will be held May 16-17 in Dublin, Ireland.

Details can be found here:

Thanks,

Russell Pavlicek
Xen Evangelist

--e89a8f22c55568124704d7717fcd-- --===============5274997709239928634== 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 --===============5274997709239928634==-- From xen-users-bounces@lists.xen.org Fri Mar 08 23:40:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 23:40: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 1UE6t6-0005UM-6q; Fri, 08 Mar 2013 23:39:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE5wv-0003dy-MM for xen-users@lists.xen.org; Fri, 08 Mar 2013 22:39:37 +0000 Received: from [85.158.139.211:10705] by server-14.bemta-5.messagelabs.com id DA/9B-13158-8A86A315; Fri, 08 Mar 2013 22:39:36 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1362782375!14695684!1 X-Originating-IP: [209.85.215.65] 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.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22082 invoked from network); 8 Mar 2013 22:39:36 -0000 Received: from mail-la0-f65.google.com (HELO mail-la0-f65.google.com) (209.85.215.65) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 8 Mar 2013 22:39:36 -0000 Received: by mail-la0-f65.google.com with SMTP id fq12so468711lab.4 for ; Fri, 08 Mar 2013 14:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=oTeZCy7khP4ALFBJs6M3zimw7CO3w4zsPpMwgfDZ35o=; b=f/753sdllexYAg/ybYdf0IBwow4sY9Ge7ZPC/NT0w29HMTKMFS/2T7XbDzQ+Uu4H4V Jgnb8GX+YMBN16UDUQdXohvCjX7qEHnEaYZYGO8LZMEJab0YiUXm6Vbo6/YFgH32Fd3Z zVN9CDGuspuFVMqD6b57uiYMxyNoTJ+3xFZCdtM9S6kRI7csHhKIMv6K3CMDFzlZzRz0 cNQqm7c7Ajh1GoHAxKbdvbU9WdKQ+mDW0JgDRlvK9UW2WJd9uBYkgh2v+95FlfV4EpWj yGWtW295fiOq0LXVIORel/mzN8FNS4odpe/qbrim0F9R1vLry24Qu3ykSf3DaA7edXed ytMA== MIME-Version: 1.0 X-Received: by 10.152.146.199 with SMTP id te7mr3447231lab.23.1362782375644; Fri, 08 Mar 2013 14:39:35 -0800 (PST) Received: by 10.112.13.3 with HTTP; Fri, 8 Mar 2013 14:39:35 -0800 (PST) Date: Fri, 8 Mar 2013 17:39:35 -0500 X-Google-Sender-Auth: 7nguTQoJWqkarVVEZClprt4Q5VA Message-ID: From: Russ Pavlicek To: xen-users@lists.xen.org X-Mailman-Approved-At: Fri, 08 Mar 2013 23:39:41 +0000 Subject: [Xen-users] Xen Hackathon hosted by Google, May 16-17 in Dublin X-BeenThere: xen-users@lists.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="===============5274997709239928634==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5274997709239928634== Content-Type: multipart/alternative; boundary=e89a8f22c55568124704d7717fcd --e89a8f22c55568124704d7717fcd Content-Type: text/plain; charset=ISO-8859-1 It's time for another Xen Hackathon! This year's event will be held May 16-17 in Dublin, Ireland. Details can be found here: http://blog.xen.org/index.php/2013/03/07/google-hosted-xen-hackathon-may-16-17-dublin/ Thanks, Russell Pavlicek Xen Evangelist --e89a8f22c55568124704d7717fcd Content-Type: text/html; charset=ISO-8859-1
It's time for another Xen Hackathon!

This year's event will be held May 16-17 in Dublin, Ireland.

Details can be found here:

Thanks,

Russell Pavlicek
Xen Evangelist

--e89a8f22c55568124704d7717fcd-- --===============5274997709239928634== 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 --===============5274997709239928634==-- From xen-users-bounces@lists.xen.org Fri Mar 08 23:40:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 23:40: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 1UE6t4-0005Tz-UP; Fri, 08 Mar 2013 23:39:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD3HY-00050i-Pp for xen-users@lists.xen.org; Wed, 06 Mar 2013 01:36:37 +0000 Received: from [85.158.138.51:21247] by server-9.bemta-3.messagelabs.com id FC/A5-32531-F9D96315; Wed, 06 Mar 2013 01:36:31 +0000 X-Env-Sender: yuanpu@139.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1362533788!28176959!1 X-Originating-IP: [221.176.9.70] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjIxLjE3Ni45LjcwID0+IDIwMjU1\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15718 invoked from network); 6 Mar 2013 01:36:30 -0000 Received: from n9-70.mail.139.com (HELO n9-70.mail.139.com) (221.176.9.70) by server-11.tower-174.messagelabs.com with SMTP; 6 Mar 2013 01:36:30 -0000 X-Richmail-Antispam: sCL2rVi0borhSzeOjpYxWEmrxqxSIjpgsIL2jVqxeZIR0RM= Received: from yuanLaptop (unknown[58.243.250.110]) by rmsmtp-app3-rm-app-04-12004 (RichMail) with SMTP id 2ee451369d98c9a-7ba08; Wed, 06 Mar 2013 09:36:27 +0800 (CST) X-RM-TRANSID: 2ee451369d98c9a-7ba08 Date: Wed, 6 Mar 2013 09:36:26 +0800 From: yuanpu To: xen-users X-Priority: 3 X-GUID: 3D4F3036-7FBB-4D20-A74B-AE47C9E81525 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[en] Mime-Version: 1.0 Message-ID: <201303060936252179245@139.com> X-Mailman-Approved-At: Fri, 08 Mar 2013 23:39:41 +0000 Subject: [Xen-users] Can i modify vm ip address from without login to it X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: 18611408221 <18611408221@139.com> List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4228687049453833781==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============4228687049453833781== Content-Type: multipart/alternative; boundary="----=_001_NextPart850121234364_=----" This is a multi-part message in MIME format. ------=_001_NextPart850121234364_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 YW55IG9uZSBjYW4gaGVscCBtZSB0aGFuayB5b3UgdmVyeSBtdWNoLg0KDQoNCg0KDQp5dWFucHVA MTM5LmNvbQ== ------=_001_NextPart850121234364_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
any one can help me thank you very much.
 
= yuanpu@139.com
------=_001_NextPart850121234364_=------ --===============4228687049453833781== 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 --===============4228687049453833781==-- From xen-users-bounces@lists.xen.org Fri Mar 08 23:40:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 23:40: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 1UE6t4-0005Tz-UP; Fri, 08 Mar 2013 23:39:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD3HY-00050i-Pp for xen-users@lists.xen.org; Wed, 06 Mar 2013 01:36:37 +0000 Received: from [85.158.138.51:21247] by server-9.bemta-3.messagelabs.com id FC/A5-32531-F9D96315; Wed, 06 Mar 2013 01:36:31 +0000 X-Env-Sender: yuanpu@139.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1362533788!28176959!1 X-Originating-IP: [221.176.9.70] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjIxLjE3Ni45LjcwID0+IDIwMjU1\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15718 invoked from network); 6 Mar 2013 01:36:30 -0000 Received: from n9-70.mail.139.com (HELO n9-70.mail.139.com) (221.176.9.70) by server-11.tower-174.messagelabs.com with SMTP; 6 Mar 2013 01:36:30 -0000 X-Richmail-Antispam: sCL2rVi0borhSzeOjpYxWEmrxqxSIjpgsIL2jVqxeZIR0RM= Received: from yuanLaptop (unknown[58.243.250.110]) by rmsmtp-app3-rm-app-04-12004 (RichMail) with SMTP id 2ee451369d98c9a-7ba08; Wed, 06 Mar 2013 09:36:27 +0800 (CST) X-RM-TRANSID: 2ee451369d98c9a-7ba08 Date: Wed, 6 Mar 2013 09:36:26 +0800 From: yuanpu To: xen-users X-Priority: 3 X-GUID: 3D4F3036-7FBB-4D20-A74B-AE47C9E81525 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[en] Mime-Version: 1.0 Message-ID: <201303060936252179245@139.com> X-Mailman-Approved-At: Fri, 08 Mar 2013 23:39:41 +0000 Subject: [Xen-users] Can i modify vm ip address from without login to it X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: 18611408221 <18611408221@139.com> List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4228687049453833781==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============4228687049453833781== Content-Type: multipart/alternative; boundary="----=_001_NextPart850121234364_=----" This is a multi-part message in MIME format. ------=_001_NextPart850121234364_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 YW55IG9uZSBjYW4gaGVscCBtZSB0aGFuayB5b3UgdmVyeSBtdWNoLg0KDQoNCg0KDQp5dWFucHVA MTM5LmNvbQ== ------=_001_NextPart850121234364_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
any one can help me thank you very much.
 
= yuanpu@139.com
------=_001_NextPart850121234364_=------ --===============4228687049453833781== 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 --===============4228687049453833781==-- From xen-users-bounces@lists.xen.org Fri Mar 08 23:40:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 23:40: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 1UE6t5-0005UB-IG; Fri, 08 Mar 2013 23:39:43 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD7Jd-0008Cv-82 for xen-users@lists.xen.org; Wed, 06 Mar 2013 05:55:01 +0000 Received: from [85.158.137.99:5075] by server-6.bemta-3.messagelabs.com id 5D/4F-11048-43AD6315; Wed, 06 Mar 2013 05:55:00 +0000 X-Env-Sender: mr.gerami@gmail.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1362549298!14692212!1 X-Originating-IP: [209.85.217.175] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22729 invoked from network); 6 Mar 2013 05:54:59 -0000 Received: from mail-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 05:54:59 -0000 Received: by mail-lb0-f175.google.com with SMTP id n3so5345682lbo.6 for ; Tue, 05 Mar 2013 21:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=wC/d75RSLeNPqf+HNskdHwbp8M/nXP56LNWFj12T/kc=; b=PTsB4rYeJgcGmUG679MSrHlwW9cLOnpxiT1JkwhsfN6dohg0rf8CYEEzq2l0ls4vu/ YG9x1Mq9OK8utN/zxne63e44U0f7FkagbG9nhhX4JaT2vho5ykF9wxud+prLzogh1idu b+osiQ+PMoz+YWbBO6kiylX1cYnHZgrknBGPEwc1U2pg/lnLhN4hRNjWUtxroPszu0eT pZNSP2/wbNOrgTRAc4UhIWLL/xI/729Xu2jkKQ0KpDrk/wuf0UHKU2wc/HfGSOchgZs3 eeGGOJH9ldz7kdwNC5WSjpUyvOdc1zT4qhg6HL4cT2XglXHPg9kqky/B7ib2vXz7EBTn g/Dg== X-Received: by 10.112.36.2 with SMTP id m2mr6919860lbj.100.1362549298099; Tue, 05 Mar 2013 21:54:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.29.70 with HTTP; Tue, 5 Mar 2013 21:54:37 -0800 (PST) In-Reply-To: <20130305172238.GA11446@zion.uk.xensource.com> References: <20130305172238.GA11446@zion.uk.xensource.com> From: Mohammad Reza Gerami Date: Wed, 6 Mar 2013 09:24:37 +0330 Message-ID: To: Wei Liu X-Mailman-Approved-At: Fri, 08 Mar 2013 23:39:41 +0000 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============7153013120217927833==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7153013120217927833== Content-Type: multipart/alternative; boundary=f46d04244532e7099c04d73b3a9f --f46d04244532e7099c04d73b3a9f Content-Type: text/plain; charset=UTF-8 Dear Wei Liu *Thanks for your response* *I have 4 cpu with 8 core, and with hyper threat I have 64, but my application run with root or other only use maximum 16 core* *my OS is centos 6.3 64bit , where can I check for limitation of cpus? * *tnx a lot * On Tue, Mar 5, 2013 at 8:52 PM, Wei Liu wrote: > On Sat, Mar 02, 2013 at 09:23:46AM +0000, Mohammad Reza Gerami wrote: > > Dear Friends > > > > I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I > have 64 > > I installed CentOS 6.3 64 bit and install my software > > but when I run job and check, Maximum 16 core use in my system > > > > What do you mean by "run job and check"? How many CPUs are there in your > /proc/cpuinfo? If you're seeing 64 CPUs, you're probably hitting limits > in your guests. > > > Wei. > > > what is your idea? > > > > thank you > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > -- *Best Regards Mohammad Reza Gerami --f46d04244532e7099c04d73b3a9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear=C2=A0Wei Liu
Thanks for your response
I have 4 cpu with 8 core, and with=C2=A0hyper threat I h= ave 64, but my application run with root or other only use maximum 16 core<= /span>
my OS is centos 6.3 64bit =C2=A0, where can I check for = limitation of cpus?=C2=A0
tnx a l= ot

On Tue, Mar 5, 2013 at 8:5= 2 PM, Wei Liu <wei.liu2@citrix.com> wrote:
On Sat, Mar 02, 2013 at 09:23:46AM +0000, Mohammad Reza G= erami wrote:
> Dear Friends
>
> I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I= have 64
> I installed CentOS 6.3 64 bit and install my software
> but when I run =C2=A0job and check, Maximum =C2=A016 core use in my sy= stem
>

What do you mean by "run job and check"? How many CPUs are = there in your
/proc/cpuinfo? If you're seeing 64 CPUs, you're probably hitting li= mits
in your guests.


Wei.

> what is your idea?
>
> thank you

> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org=
> http://li= sts.xen.org/xen-users




--
*Best Regard= s
Mohammad Reza Gerami




--f46d04244532e7099c04d73b3a9f-- --===============7153013120217927833== 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 --===============7153013120217927833==-- From xen-users-bounces@lists.xen.org Fri Mar 08 23:40:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 23:40: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 1UE6t5-0005UB-IG; Fri, 08 Mar 2013 23:39:43 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UD7Jd-0008Cv-82 for xen-users@lists.xen.org; Wed, 06 Mar 2013 05:55:01 +0000 Received: from [85.158.137.99:5075] by server-6.bemta-3.messagelabs.com id 5D/4F-11048-43AD6315; Wed, 06 Mar 2013 05:55:00 +0000 X-Env-Sender: mr.gerami@gmail.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1362549298!14692212!1 X-Originating-IP: [209.85.217.175] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22729 invoked from network); 6 Mar 2013 05:54:59 -0000 Received: from mail-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 6 Mar 2013 05:54:59 -0000 Received: by mail-lb0-f175.google.com with SMTP id n3so5345682lbo.6 for ; Tue, 05 Mar 2013 21:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=wC/d75RSLeNPqf+HNskdHwbp8M/nXP56LNWFj12T/kc=; b=PTsB4rYeJgcGmUG679MSrHlwW9cLOnpxiT1JkwhsfN6dohg0rf8CYEEzq2l0ls4vu/ YG9x1Mq9OK8utN/zxne63e44U0f7FkagbG9nhhX4JaT2vho5ykF9wxud+prLzogh1idu b+osiQ+PMoz+YWbBO6kiylX1cYnHZgrknBGPEwc1U2pg/lnLhN4hRNjWUtxroPszu0eT pZNSP2/wbNOrgTRAc4UhIWLL/xI/729Xu2jkKQ0KpDrk/wuf0UHKU2wc/HfGSOchgZs3 eeGGOJH9ldz7kdwNC5WSjpUyvOdc1zT4qhg6HL4cT2XglXHPg9kqky/B7ib2vXz7EBTn g/Dg== X-Received: by 10.112.36.2 with SMTP id m2mr6919860lbj.100.1362549298099; Tue, 05 Mar 2013 21:54:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.29.70 with HTTP; Tue, 5 Mar 2013 21:54:37 -0800 (PST) In-Reply-To: <20130305172238.GA11446@zion.uk.xensource.com> References: <20130305172238.GA11446@zion.uk.xensource.com> From: Mohammad Reza Gerami Date: Wed, 6 Mar 2013 09:24:37 +0330 Message-ID: To: Wei Liu X-Mailman-Approved-At: Fri, 08 Mar 2013 23:39:41 +0000 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] use all of my cpu cores X-BeenThere: xen-users@lists.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="===============7153013120217927833==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7153013120217927833== Content-Type: multipart/alternative; boundary=f46d04244532e7099c04d73b3a9f --f46d04244532e7099c04d73b3a9f Content-Type: text/plain; charset=UTF-8 Dear Wei Liu *Thanks for your response* *I have 4 cpu with 8 core, and with hyper threat I have 64, but my application run with root or other only use maximum 16 core* *my OS is centos 6.3 64bit , where can I check for limitation of cpus? * *tnx a lot * On Tue, Mar 5, 2013 at 8:52 PM, Wei Liu wrote: > On Sat, Mar 02, 2013 at 09:23:46AM +0000, Mohammad Reza Gerami wrote: > > Dear Friends > > > > I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I > have 64 > > I installed CentOS 6.3 64 bit and install my software > > but when I run job and check, Maximum 16 core use in my system > > > > What do you mean by "run job and check"? How many CPUs are there in your > /proc/cpuinfo? If you're seeing 64 CPUs, you're probably hitting limits > in your guests. > > > Wei. > > > what is your idea? > > > > thank you > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > -- *Best Regards Mohammad Reza Gerami --f46d04244532e7099c04d73b3a9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear=C2=A0Wei Liu
Thanks for your response
I have 4 cpu with 8 core, and with=C2=A0hyper threat I h= ave 64, but my application run with root or other only use maximum 16 core<= /span>
my OS is centos 6.3 64bit =C2=A0, where can I check for = limitation of cpus?=C2=A0
tnx a l= ot

On Tue, Mar 5, 2013 at 8:5= 2 PM, Wei Liu <wei.liu2@citrix.com> wrote:
On Sat, Mar 02, 2013 at 09:23:46AM +0000, Mohammad Reza G= erami wrote:
> Dear Friends
>
> I have a server with 4 * 8 (core) CPU, all 32 core with hyper threat I= have 64
> I installed CentOS 6.3 64 bit and install my software
> but when I run =C2=A0job and check, Maximum =C2=A016 core use in my sy= stem
>

What do you mean by "run job and check"? How many CPUs are = there in your
/proc/cpuinfo? If you're seeing 64 CPUs, you're probably hitting li= mits
in your guests.


Wei.

> what is your idea?
>
> thank you

> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org=
> http://li= sts.xen.org/xen-users




--
*Best Regard= s
Mohammad Reza Gerami




--f46d04244532e7099c04d73b3a9f-- --===============7153013120217927833== 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 --===============7153013120217927833==-- From xen-users-bounces@lists.xen.org Fri Mar 08 23:53:03 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 23:53: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 1UE75A-0006Oe-OR; Fri, 08 Mar 2013 23:52:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE759-0006OU-NH for xen-users@lists.xen.org; Fri, 08 Mar 2013 23:52:11 +0000 Received: from [85.158.143.99:29246] by server-1.bemta-4.messagelabs.com id 53/EE-06203-BA97A315; Fri, 08 Mar 2013 23:52:11 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1362786729!22378867!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7420 invoked from network); 8 Mar 2013 23:52:10 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Mar 2013 23:52:10 -0000 Received: from [201.122.115.101] (port=49628 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UE756-0005dC-Fy for xen-users@lists.xen.org; Fri, 08 Mar 2013 17:52:08 -0600 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id C5D37A209 for ; Fri, 8 Mar 2013 17:47:19 -0600 (CST) Message-ID: <513A79A7.2070402@ondore.com> Date: Fri, 08 Mar 2013 17:52:07 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <201303060936252179245@139.com> In-Reply-To: <201303060936252179245@139.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Can i modify vm ip address from without login to it X-BeenThere: xen-users@lists.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 Hello. El 05/03/13 19:36, yuanpu escribi=F3: >Can i modify vm ip address from without login to it? > any one can help me thank you very much. If you wish to modify DomU's IP address without shutting it down, it's = hardly possible. What you may do, is to shut down the machine, mount it's root filesystem = under Dom0, change the configuration of the network interface, unmount = the filesystem, then start the DomU back. If your problem is that you don't have DomU's root password, and don't = want to overwrite it in a dirty way, this method should work. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 08 23:53:03 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 08 Mar 2013 23:53: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 1UE75A-0006Oe-OR; Fri, 08 Mar 2013 23:52:12 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE759-0006OU-NH for xen-users@lists.xen.org; Fri, 08 Mar 2013 23:52:11 +0000 Received: from [85.158.143.99:29246] by server-1.bemta-4.messagelabs.com id 53/EE-06203-BA97A315; Fri, 08 Mar 2013 23:52:11 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1362786729!22378867!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7420 invoked from network); 8 Mar 2013 23:52:10 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Mar 2013 23:52:10 -0000 Received: from [201.122.115.101] (port=49628 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UE756-0005dC-Fy for xen-users@lists.xen.org; Fri, 08 Mar 2013 17:52:08 -0600 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id C5D37A209 for ; Fri, 8 Mar 2013 17:47:19 -0600 (CST) Message-ID: <513A79A7.2070402@ondore.com> Date: Fri, 08 Mar 2013 17:52:07 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <201303060936252179245@139.com> In-Reply-To: <201303060936252179245@139.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Can i modify vm ip address from without login to it X-BeenThere: xen-users@lists.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 Hello. El 05/03/13 19:36, yuanpu escribi=F3: >Can i modify vm ip address from without login to it? > any one can help me thank you very much. If you wish to modify DomU's IP address without shutting it down, it's = hardly possible. What you may do, is to shut down the machine, mount it's root filesystem = under Dom0, change the configuration of the network interface, unmount = the filesystem, then start the DomU back. If your problem is that you don't have DomU's root password, and don't = want to overwrite it in a dirty way, this method should work. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 09 00:45:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2013 00: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 1UE7tz-0007f1-C9; Sat, 09 Mar 2013 00:44:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE7ty-0007ew-AF for xen-users@lists.xen.org; Sat, 09 Mar 2013 00:44:42 +0000 Received: from [85.158.139.83:25655] by server-13.bemta-5.messagelabs.com id 44/9A-16871-9F58A315; Sat, 09 Mar 2013 00:44:41 +0000 X-Env-Sender: wangbj@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1362789879!28102070!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9320 invoked from network); 9 Mar 2013 00:44:40 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 Mar 2013 00:44:40 -0000 Received: by mail-ob0-f171.google.com with SMTP id x4so1807437obh.2 for ; Fri, 08 Mar 2013 16:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=qe/Nx5BkMytyjiUwVblbvH5cgqWQqupIJEF5q2MiFPY=; b=bRBK7s7GJAB496DclF6az8TUk7lyIiECNCazmJFFtjhQm92RnBztUvFsUzXBC/qYbN t/jFgNxfwdF0tkTqoKtIeMIkyvKA0HihJrlJYESWYW+H4rFJAPGsZP/9/n61qyMi6ImD p+EUPeUJGuNWefHyvF3DOUFSWhSk3wBRgG51lAmC+sksDN7i9yvj1v6sDk+uiTXRZ6QQ hpoE08O0YZ+8xlQYht5DEpTETiXnaCY/EMxRFyhkxaQnhrn3QfdQQmF2Rdd0ynXrQYJY 9ZmxpD1XuwzeqczVEgdOl/9a6bbjGB/UmZa1z0hnFFdHB6rERYh6lhJMsXMUOyTD062S I7mg== MIME-Version: 1.0 X-Received: by 10.182.245.33 with SMTP id xl1mr3476006obc.91.1362789878813; Fri, 08 Mar 2013 16:44:38 -0800 (PST) Received: by 10.60.35.9 with HTTP; Fri, 8 Mar 2013 16:44:38 -0800 (PST) Date: Fri, 8 Mar 2013 16:44:38 -0800 Message-ID: From: Baojun Wang To: xen-users@lists.xen.org Cc: Baojun Wang Subject: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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 run pvlinux (via pvgrub) using pci passthrough (and vga pass through), xen version is 4.2.1, dom0 & domU kernel are both 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) supports vt-d, processor is i7-2600 and it supports vt-d too. When pci passthrough is not enabled, everything is fine; but after I enabled pci pass through, domU can only see 512MB RAM (USB passed from pci-passthrough works, but video/intel didn't work, likely due to i915 load error from dmesg, everything else is also good). I googled and found a similar issue is reported at: http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html But seems there is no follow up how the problem is fixed, how can I fix the issue? Below are some links from pastebin.com: 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2 I tried xen version 4.2.0 too but still no luck. My kernel have all xen feature enabled; and I can provide more info if necessary. Thanks baojun _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 09 00:45:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 09 Mar 2013 00: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 1UE7tz-0007f1-C9; Sat, 09 Mar 2013 00:44:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UE7ty-0007ew-AF for xen-users@lists.xen.org; Sat, 09 Mar 2013 00:44:42 +0000 Received: from [85.158.139.83:25655] by server-13.bemta-5.messagelabs.com id 44/9A-16871-9F58A315; Sat, 09 Mar 2013 00:44:41 +0000 X-Env-Sender: wangbj@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1362789879!28102070!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9320 invoked from network); 9 Mar 2013 00:44:40 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 9 Mar 2013 00:44:40 -0000 Received: by mail-ob0-f171.google.com with SMTP id x4so1807437obh.2 for ; Fri, 08 Mar 2013 16:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=qe/Nx5BkMytyjiUwVblbvH5cgqWQqupIJEF5q2MiFPY=; b=bRBK7s7GJAB496DclF6az8TUk7lyIiECNCazmJFFtjhQm92RnBztUvFsUzXBC/qYbN t/jFgNxfwdF0tkTqoKtIeMIkyvKA0HihJrlJYESWYW+H4rFJAPGsZP/9/n61qyMi6ImD p+EUPeUJGuNWefHyvF3DOUFSWhSk3wBRgG51lAmC+sksDN7i9yvj1v6sDk+uiTXRZ6QQ hpoE08O0YZ+8xlQYht5DEpTETiXnaCY/EMxRFyhkxaQnhrn3QfdQQmF2Rdd0ynXrQYJY 9ZmxpD1XuwzeqczVEgdOl/9a6bbjGB/UmZa1z0hnFFdHB6rERYh6lhJMsXMUOyTD062S I7mg== MIME-Version: 1.0 X-Received: by 10.182.245.33 with SMTP id xl1mr3476006obc.91.1362789878813; Fri, 08 Mar 2013 16:44:38 -0800 (PST) Received: by 10.60.35.9 with HTTP; Fri, 8 Mar 2013 16:44:38 -0800 (PST) Date: Fri, 8 Mar 2013 16:44:38 -0800 Message-ID: From: Baojun Wang To: xen-users@lists.xen.org Cc: Baojun Wang Subject: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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 run pvlinux (via pvgrub) using pci passthrough (and vga pass through), xen version is 4.2.1, dom0 & domU kernel are both 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) supports vt-d, processor is i7-2600 and it supports vt-d too. When pci passthrough is not enabled, everything is fine; but after I enabled pci pass through, domU can only see 512MB RAM (USB passed from pci-passthrough works, but video/intel didn't work, likely due to i915 load error from dmesg, everything else is also good). I googled and found a similar issue is reported at: http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html But seems there is no follow up how the problem is fixed, how can I fix the issue? Below are some links from pastebin.com: 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2 I tried xen version 4.2.0 too but still no luck. My kernel have all xen feature enabled; and I can provide more info if necessary. Thanks baojun _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 10 02:24:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2013 02:24: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 1UEVuX-0004D0-2k; Sun, 10 Mar 2013 02:22:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UEVuV-0004Cv-AE for xen-users@lists.xen.org; Sun, 10 Mar 2013 02:22:51 +0000 Received: from [85.158.138.51:52552] by server-11.bemta-3.messagelabs.com id 51/D7-01263-A7EEB315; Sun, 10 Mar 2013 02:22:50 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1362882168!23524051!1 X-Originating-IP: [209.85.210.172] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23616 invoked from network); 10 Mar 2013 02:22:49 -0000 Received: from mail-ia0-f172.google.com (HELO mail-ia0-f172.google.com) (209.85.210.172) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2013 02:22:49 -0000 Received: by mail-ia0-f172.google.com with SMTP id l29so2591347iag.17 for ; Sat, 09 Mar 2013 18:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=QFJli9ZI+sfFaP3tln2qz/wnKXa2GHoFgC9v0AFzmR8=; b=YpUjb6CGtl6dflZWaVXGxayyC5U1qQJXeAtYg5MOXhTk2Jvnpjc42q6tNc0dGLNPQv YwVNPUIiBKlR1e7l+4LRUcBx6p4ZO5JFyNKizOrBM/zKJZ3sG6gl43bruApJDJ5L+rHc 0SZuZ1slxE7Joe9V7Oc4ihcqw2wOwDFVrzonr+eY1SUHplq89zmyEJ0TPaGWMLTEikar XFhLZKzT6HN7JYANw4ATRGjAk6l4FXP6xYtGP5XE7pgQTpoLl8NYt+Ftg/42goTOzrNl iGReV0RVXxUcyyYKqbzYZtsFZD+T8OSNOHGBZUbIH9mb66QpUK9HW3/C7PQR35X5oIiO 5RFQ== MIME-Version: 1.0 X-Received: by 10.50.196.130 with SMTP id im2mr3575702igc.90.1362882167892; Sat, 09 Mar 2013 18:22:47 -0800 (PST) Received: by 10.42.41.5 with HTTP; Sat, 9 Mar 2013 18:22:47 -0800 (PST) Date: Sat, 9 Mar 2013 19:22:47 -0700 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] xen 4.3 unstable bug on arch linux X-BeenThere: xen-users@lists.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="===============6475155901797255974==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6475155901797255974== Content-Type: multipart/alternative; boundary=14dae93410717cfa8d04d788bb1e --14dae93410717cfa8d04d788bb1e Content-Type: text/plain; charset=ISO-8859-1 Well the hg change 26563 creates issue were hvm can't be started. By reversing the change any revision can be compiled and it functions perfectly. --14dae93410717cfa8d04d788bb1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well the hg change 26563 creates issue were hvm can't be started. By re= versing the change any revision=A0 can be compiled and it functions perfect= ly.
--14dae93410717cfa8d04d788bb1e-- --===============6475155901797255974== 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 --===============6475155901797255974==-- From xen-users-bounces@lists.xen.org Sun Mar 10 02:24:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2013 02:24: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 1UEVuX-0004D0-2k; Sun, 10 Mar 2013 02:22:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UEVuV-0004Cv-AE for xen-users@lists.xen.org; Sun, 10 Mar 2013 02:22:51 +0000 Received: from [85.158.138.51:52552] by server-11.bemta-3.messagelabs.com id 51/D7-01263-A7EEB315; Sun, 10 Mar 2013 02:22:50 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1362882168!23524051!1 X-Originating-IP: [209.85.210.172] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23616 invoked from network); 10 Mar 2013 02:22:49 -0000 Received: from mail-ia0-f172.google.com (HELO mail-ia0-f172.google.com) (209.85.210.172) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2013 02:22:49 -0000 Received: by mail-ia0-f172.google.com with SMTP id l29so2591347iag.17 for ; Sat, 09 Mar 2013 18:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=QFJli9ZI+sfFaP3tln2qz/wnKXa2GHoFgC9v0AFzmR8=; b=YpUjb6CGtl6dflZWaVXGxayyC5U1qQJXeAtYg5MOXhTk2Jvnpjc42q6tNc0dGLNPQv YwVNPUIiBKlR1e7l+4LRUcBx6p4ZO5JFyNKizOrBM/zKJZ3sG6gl43bruApJDJ5L+rHc 0SZuZ1slxE7Joe9V7Oc4ihcqw2wOwDFVrzonr+eY1SUHplq89zmyEJ0TPaGWMLTEikar XFhLZKzT6HN7JYANw4ATRGjAk6l4FXP6xYtGP5XE7pgQTpoLl8NYt+Ftg/42goTOzrNl iGReV0RVXxUcyyYKqbzYZtsFZD+T8OSNOHGBZUbIH9mb66QpUK9HW3/C7PQR35X5oIiO 5RFQ== MIME-Version: 1.0 X-Received: by 10.50.196.130 with SMTP id im2mr3575702igc.90.1362882167892; Sat, 09 Mar 2013 18:22:47 -0800 (PST) Received: by 10.42.41.5 with HTTP; Sat, 9 Mar 2013 18:22:47 -0800 (PST) Date: Sat, 9 Mar 2013 19:22:47 -0700 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] xen 4.3 unstable bug on arch linux X-BeenThere: xen-users@lists.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="===============6475155901797255974==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6475155901797255974== Content-Type: multipart/alternative; boundary=14dae93410717cfa8d04d788bb1e --14dae93410717cfa8d04d788bb1e Content-Type: text/plain; charset=ISO-8859-1 Well the hg change 26563 creates issue were hvm can't be started. By reversing the change any revision can be compiled and it functions perfectly. --14dae93410717cfa8d04d788bb1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well the hg change 26563 creates issue were hvm can't be started. By re= versing the change any revision=A0 can be compiled and it functions perfect= ly.
--14dae93410717cfa8d04d788bb1e-- --===============6475155901797255974== 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 --===============6475155901797255974==-- From xen-users-bounces@lists.xen.org Sun Mar 10 22:17:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2013 22:17:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UEoWZ-0005lU-HU; Sun, 10 Mar 2013 22:15:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UEoWX-0005lP-BU for xen-users@lists.xen.org; Sun, 10 Mar 2013 22:15:21 +0000 Received: from [85.158.139.211:60764] by server-15.bemta-5.messagelabs.com id ED/30-22815-8F50D315; Sun, 10 Mar 2013 22:15:20 +0000 X-Env-Sender: tglcode@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1362953719!18839074!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MIME_BASE64_TEXT,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26566 invoked from network); 10 Mar 2013 22:15:19 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2013 22:15:19 -0000 Received: by mail-ee0-f45.google.com with SMTP id b57so1847891eek.4 for ; Sun, 10 Mar 2013 15:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=H/M81SyfQvzzwTxT2HFgxPjZ48wcQlazt9FvgIZrkz0=; b=VUf+V+GQ6GRhS/f8KtzeipGge5oW0hP5uYd2pKNW6QP+AXz24hambYMEWit51tlnCm 4vR1fc6VdsSLNKDM9SUfip0mqcsaAeUHzZGBGajvTSRvF0RsYmdFeC3W7eyynkGwXpWh gZn8hTuDdlkOeXkQ1wtIyTX8pE3dUHLfLDNBr6bsO8bTX+GU1O8qWdbI+B98PQQM+gzL Kyn45trr+vPGcedFxmojEGIso/tMDFfZlRRVyLefMXUUaeuh8zp2LBIUIsah7gkg9jYd T6f/hSk7UlAyBU4Rm4cmsQJRAdLK13caKWZpCyrMxiK67fmbfrB2QV/NFnHjSnZsLaaE i5Vg== MIME-Version: 1.0 X-Received: by 10.14.179.5 with SMTP id g5mr29859676eem.41.1362953719303; Sun, 10 Mar 2013 15:15:19 -0700 (PDT) Received: by 10.223.64.207 with HTTP; Sun, 10 Mar 2013 15:15:19 -0700 (PDT) Date: Sun, 10 Mar 2013 17:15:19 -0500 Message-ID: From: Tod Liverseed To: xen-users@lists.xen.org Subject: [Xen-users] Windows 2008R2 HVMs and clock drift X-BeenThere: xen-users@lists.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="===============3336504177830855372==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3336504177830855372== Content-Type: multipart/alternative; boundary=047d7b603fe648fd3e04d79964fb --047d7b603fe648fd3e04d79964fb Content-Type: text/plain; charset=ISO-8859-1 I am running Xen 4.0.1 on debian squeeze. I have 2 Win2008R2 HVMs running on it. Dom0 is using NTPDate and has a solid time. Zero problem with Dom0. Now, the strange part. One vm's clock drifts, while the other vm's clock does not drift. Of course I do use NTP as both are part of a windows domain, so ultimately W32TM does correct the issue (or keeps it within the domain tolerance). The .CFGs are identical except for the ram/disks and... VCPUs OK, HVM configs. These settings are common in both the VM that drifts and the one that does not. acpi = 1 apic = 1 device_model = '/usr/lib/xen-4.0/bin/qemu-dm' boot="c" localtime=1 sdl=0 serial='pty' timer_mode=2 viridian=1 Now for the Differences.... ********** Does not Drift ********** builder='hvm' memory = 16384 shadow_memory = 96 vcpus=6 cpus="8-15" ************************************** ********** Drifts ********** builder='hvm' memory = 8096 shadow_memory = 30 cpus="4-5" vcpus=2 **************************** Below is a /stripchart from W32TM in the one that drifts. 16:39:02 d:+00.0625636s o:+03.8884581s [ | * ] 16:39:33 d:+00.0625636s o:+03.9052416s [ | * ] 16:40:03 d:+00.0624592s o:+03.9651983s [ | * ] 16:40:33 d:+00.0624592s o:+04.1260910s [ | * ] 16:41:03 d:+00.0624592s o:+04.3182343s [ | * ] 16:41:33 d:+00.0780740s o:+04.7369497s [ | * ] 16:42:03 d:+00.0624592s o:+04.9525362s [ | * ] 16:42:33 d:+00.0624592s o:+05.3478084s [ | * ] 16:43:04 d:+00.0624592s o:+05.7430806s [ | * ] 16:43:34 d:+00.0624592s o:+06.1071022s [ | * ] 16:44:04 d:+00.0624592s o:+06.7836298s [ | * ] 16:44:34 d:+00.0624592s o:+07.0382848s [ | * ] 16:45:04 d:+00.0624216s o:+07.2666513s [ | * ] 16:45:34 d:+00.0624216s o:+07.6019390s [ | * ] 16:46:04 d:+00.0624216s o:+08.1559809s [ | * ] 16:46:34 d:+00.0624216s o:+08.5850204s [ | * ] 16:47:05 d:+00.0637092s o:+08.6929941s [ | * ] I have two identical servers, running these same HVMs, and both do the same exact thing. Both servers are Supermicro's with dual Xeon L5630 CPUs and 64gig of ram. I can't help but think that the VCPUs has something to do with this... I really can't try upping the VCPUs as these are running in production/dr environments. Any ideas? Thanks :-) Tod --047d7b603fe648fd3e04d79964fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SSBhbSBydW5uaW5nIFhlbiA0LjAuMSBvbiBkZWJpYW4gc3F1ZWV6ZS4gSSBoYXZlIDIgV2luMjAw OFIyIEhWTXMgcnVubmluZyBvbiBpdC6gIERvbTAgaXMgdXNpbmcgTlRQRGF0ZSBhbmQgaGFzIGEg c29saWQgdGltZS4gWmVybyBwcm9ibGVtIHdpdGggRG9tMC4gTm93LKAgdGhlIHN0cmFuZ2UgcGFy dC6gIE9uZSB2bSYjMzk7cyBjbG9jayBkcmlmdHMsoCB3aGlsZSB0aGUgb3RoZXIgdm0mIzM5O3Mg Y2xvY2sgZG9lcyBub3QgZHJpZnQuoCBPZiBjb3Vyc2UgSSBkbyB1c2UgTlRQIGFzIGJvdGggYXJl IHBhcnQgb2YgYSB3aW5kb3dzIGRvbWFpbiygIHNvIHVsdGltYXRlbHkgVzMyVE0gZG9lcyBjb3Jy ZWN0IHRoZSBpc3N1ZSAob3Iga2VlcHMgaXQgd2l0aGluIHRoZSBkb21haW4gdG9sZXJhbmNlKS4g VGhlIC5DRkdzIGFyZSBpZGVudGljYWwgZXhjZXB0IGZvciB0aGUgcmFtL2Rpc2tzIGFuZC4uLiBW Q1BVczxicj4NCg0KPGJyPk9LLKAgSFZNIGNvbmZpZ3MuIFRoZXNlIHNldHRpbmdzIGFyZSBjb21t b24gaW4gYm90aCB0aGUgVk0gdGhhdCBkcmlmdHMgYW5kIHRoZSBvbmUgdGhhdCBkb2VzIG5vdC4g PGJyPjxicj5hY3BpID0gMTxicj5hcGljID0gMTxicj5kZXZpY2VfbW9kZWwgPSAmIzM5Oy91c3Iv bGliL3hlbi00LjAvYmluL3FlbXUtZG0mIzM5Ozxicj5ib290PSZxdW90O2MmcXVvdDs8YnI+bG9j YWx0aW1lPTE8YnI+DQpzZGw9MDxicj5zZXJpYWw9JiMzOTtwdHkmIzM5Ozxicj50aW1lcl9tb2Rl PTI8YnI+dmlyaWRpYW49MTxicj48YnI+Tm93IGZvciB0aGUgRGlmZmVyZW5jZXMuLi4uPGJyPjxi cj4qKioqKioqKioqIERvZXMgbm90IERyaWZ0ICoqKioqKioqKio8YnI+YnVpbGRlcj0mIzM5O2h2 bSYjMzk7PGJyPm1lbW9yeSA9IDE2Mzg0PGJyPnNoYWRvd19tZW1vcnkgPSA5Njxicj52Y3B1cz02 PGJyPmNwdXM9JnF1b3Q7OC0xNSZxdW90Ozxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPGJyPjxicj4qKioqKioqKioqIERyaWZ0cyAqKioqKioqKioqPGJyPmJ1aWxk ZXI9JiMzOTtodm0mIzM5Ozxicj5tZW1vcnkgPSA4MDk2PGJyPnNoYWRvd19tZW1vcnkgPSAzMDxi cj5jcHVzPSZxdW90OzQtNSZxdW90Ozxicj52Y3B1cz0yPGJyPioqKioqKioqKioqKioqKioqKioq KioqKioqKio8YnI+QmVsb3cgaXMgYSAvc3RyaXBjaGFydCBmcm9tIFczMlRNIGluIHRoZSBvbmUg dGhhdCBkcmlmdHMuIDxicj4NCjxicj4xNjozOTowMiBkOiswMC4wNjI1NjM2cyBvOiswMy44ODg0 NTgxc6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKAgKqCgoKCgoKCgoKCg oKCgoCBdPGJyPjE2OjM5OjMzIGQ6KzAwLjA2MjU2MzZzIG86KzAzLjkwNTI0MTZzoCBboKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKAgfKCgoKCgoKCgoCAqoKCgoKCgoKCgoKCgoKCgIF08YnI+MTY6 NDA6MDMgZDorMDAuMDYyNDU5MnMgbzorMDMuOTY1MTk4M3OgIFugoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoCB8oKCgoKCgoKCgICqgoKCgoKCgoKCgoKCgoKAgXTxicj4NCjE2OjQwOjMzIGQ6KzAw LjA2MjQ1OTJzIG86KzA0LjEyNjA5MTBzoCBboKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgfKCg oKCgoKCgoCAqoKCgoKCgoKCgoKCgoKCgIF08YnI+MTY6NDE6MDMgZDorMDAuMDYyNDU5MnMgbzor MDQuMzE4MjM0M3OgIFugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCB8oKCgoKCgoKCgoCAqoKCg oKCgoKCgoKCgoKAgXTxicj4xNjo0MTozMyBkOiswMC4wNzgwNzQwcyBvOiswNC43MzY5NDk3c6Ag W6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKCgoCAqoKCgoKCgoKCgoKCgoCBd PGJyPg0KMTY6NDI6MDMgZDorMDAuMDYyNDU5MnMgbzorMDQuOTUyNTM2MnOgIFugoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCgICqgoKCgoKCgoKCgoKAgXTxicj4xNjo0Mjoz MyBkOiswMC4wNjI0NTkycyBvOiswNS4zNDc4MDg0c6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgIHygoKCgoKCgoKCgoKCgICqgoKCgoKCgoKCgoCBdPGJyPjE2OjQzOjA0IGQ6KzAwLjA2MjQ1 OTJzIG86KzA1Ljc0MzA4MDZzoCBboKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgfKCgoKCgoKCg oKCgoKCgICqgoKCgoKCgoKCgIF08YnI+DQoxNjo0MzozNCBkOiswMC4wNjI0NTkycyBvOiswNi4x MDcxMDIyc6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKCgoKCgoKAgKqCg oKCgoKCgoCBdPGJyPjE2OjQ0OjA0IGQ6KzAwLjA2MjQ1OTJzIG86KzA2Ljc4MzYyOThzoCBboKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgfKCgoKCgoKCgoKCgoKCgoKCgICqgoKCgoKCgIF08YnI+ MTY6NDQ6MzQgZDorMDAuMDYyNDU5MnMgbzorMDcuMDM4Mjg0OHOgIFugoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCgoKCgoKAgKqCgoKCgoKAgXTxicj4NCjE2OjQ1OjA0IGQ6 KzAwLjA2MjQyMTZzIG86KzA3LjI2NjY1MTNzoCBboKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAg fKCgoKCgoKCgoKCgoKCgoKCgoCAqoKCgoKCgIF08YnI+MTY6NDU6MzQgZDorMDAuMDYyNDIxNnMg bzorMDcuNjAxOTM5MHOgIFugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCg oKCgoKCgoCAqoKCgoKAgXTxicj4xNjo0NjowNCBkOiswMC4wNjI0MjE2cyBvOiswOC4xNTU5ODA5 c6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKCgoKCgoKCgoKCgoCAqoKCg oCBdPGJyPg0KMTY6NDY6MzQgZDorMDAuMDYyNDIxNnMgbzorMDguNTg1MDIwNHOgIFugoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCgoKCgoKCgoKCgoCAqoKAgXTxicj4xNjo0 NzowNSBkOiswMC4wNjM3MDkycyBvOiswOC42OTI5OTQxc6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgIHygoKCgoKCgoKCgoKCgoKCgoKCgoKCgICqgoCBdPGJyPjxicj48YnI+SSBoYXZlIHR3 byBpZGVudGljYWwgc2VydmVycyygIHJ1bm5pbmcgdGhlc2Ugc2FtZSBIVk1zLKAgYW5kIGJvdGgg ZG8gdGhlIHNhbWUgZXhhY3QgdGhpbmcuIEJvdGggc2VydmVycyBhcmUgU3VwZXJtaWNybyYjMzk7 cyB3aXRoIGR1YWwgWGVvbiBMNTYzMCBDUFVzIGFuZCA2NGdpZyBvZiByYW0uIEkgY2FuJiMzOTt0 IGhlbHAgYnV0IHRoaW5rIHRoYXQgdGhlIFZDUFVzIGhhcyBzb21ldGhpbmcgdG8gZG8gd2l0aCB0 aGlzLi4uIEkgcmVhbGx5IGNhbiYjMzk7dCB0cnkgdXBwaW5nIHRoZSBWQ1BVcyBhcyB0aGVzZSBh cmUgcnVubmluZyBpbiBwcm9kdWN0aW9uL2RyIGVudmlyb25tZW50cy4gPGJyPg0KPGJyPkFueSBp ZGVhcz88YnI+PGJyPlRoYW5rcyA6LSk8YnI+PGJyPlRvZDxicj48YnI+PGJyPjxicj48YnI+PGJy Pg0K --047d7b603fe648fd3e04d79964fb-- --===============3336504177830855372== 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 --===============3336504177830855372==-- From xen-users-bounces@lists.xen.org Sun Mar 10 22:17:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 10 Mar 2013 22:17:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UEoWZ-0005lU-HU; Sun, 10 Mar 2013 22:15:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UEoWX-0005lP-BU for xen-users@lists.xen.org; Sun, 10 Mar 2013 22:15:21 +0000 Received: from [85.158.139.211:60764] by server-15.bemta-5.messagelabs.com id ED/30-22815-8F50D315; Sun, 10 Mar 2013 22:15:20 +0000 X-Env-Sender: tglcode@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1362953719!18839074!1 X-Originating-IP: [74.125.83.45] X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE, MIME_BASE64_TEXT,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26566 invoked from network); 10 Mar 2013 22:15:19 -0000 Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com) (74.125.83.45) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 10 Mar 2013 22:15:19 -0000 Received: by mail-ee0-f45.google.com with SMTP id b57so1847891eek.4 for ; Sun, 10 Mar 2013 15:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=H/M81SyfQvzzwTxT2HFgxPjZ48wcQlazt9FvgIZrkz0=; b=VUf+V+GQ6GRhS/f8KtzeipGge5oW0hP5uYd2pKNW6QP+AXz24hambYMEWit51tlnCm 4vR1fc6VdsSLNKDM9SUfip0mqcsaAeUHzZGBGajvTSRvF0RsYmdFeC3W7eyynkGwXpWh gZn8hTuDdlkOeXkQ1wtIyTX8pE3dUHLfLDNBr6bsO8bTX+GU1O8qWdbI+B98PQQM+gzL Kyn45trr+vPGcedFxmojEGIso/tMDFfZlRRVyLefMXUUaeuh8zp2LBIUIsah7gkg9jYd T6f/hSk7UlAyBU4Rm4cmsQJRAdLK13caKWZpCyrMxiK67fmbfrB2QV/NFnHjSnZsLaaE i5Vg== MIME-Version: 1.0 X-Received: by 10.14.179.5 with SMTP id g5mr29859676eem.41.1362953719303; Sun, 10 Mar 2013 15:15:19 -0700 (PDT) Received: by 10.223.64.207 with HTTP; Sun, 10 Mar 2013 15:15:19 -0700 (PDT) Date: Sun, 10 Mar 2013 17:15:19 -0500 Message-ID: From: Tod Liverseed To: xen-users@lists.xen.org Subject: [Xen-users] Windows 2008R2 HVMs and clock drift X-BeenThere: xen-users@lists.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="===============3336504177830855372==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3336504177830855372== Content-Type: multipart/alternative; boundary=047d7b603fe648fd3e04d79964fb --047d7b603fe648fd3e04d79964fb Content-Type: text/plain; charset=ISO-8859-1 I am running Xen 4.0.1 on debian squeeze. I have 2 Win2008R2 HVMs running on it. Dom0 is using NTPDate and has a solid time. Zero problem with Dom0. Now, the strange part. One vm's clock drifts, while the other vm's clock does not drift. Of course I do use NTP as both are part of a windows domain, so ultimately W32TM does correct the issue (or keeps it within the domain tolerance). The .CFGs are identical except for the ram/disks and... VCPUs OK, HVM configs. These settings are common in both the VM that drifts and the one that does not. acpi = 1 apic = 1 device_model = '/usr/lib/xen-4.0/bin/qemu-dm' boot="c" localtime=1 sdl=0 serial='pty' timer_mode=2 viridian=1 Now for the Differences.... ********** Does not Drift ********** builder='hvm' memory = 16384 shadow_memory = 96 vcpus=6 cpus="8-15" ************************************** ********** Drifts ********** builder='hvm' memory = 8096 shadow_memory = 30 cpus="4-5" vcpus=2 **************************** Below is a /stripchart from W32TM in the one that drifts. 16:39:02 d:+00.0625636s o:+03.8884581s [ | * ] 16:39:33 d:+00.0625636s o:+03.9052416s [ | * ] 16:40:03 d:+00.0624592s o:+03.9651983s [ | * ] 16:40:33 d:+00.0624592s o:+04.1260910s [ | * ] 16:41:03 d:+00.0624592s o:+04.3182343s [ | * ] 16:41:33 d:+00.0780740s o:+04.7369497s [ | * ] 16:42:03 d:+00.0624592s o:+04.9525362s [ | * ] 16:42:33 d:+00.0624592s o:+05.3478084s [ | * ] 16:43:04 d:+00.0624592s o:+05.7430806s [ | * ] 16:43:34 d:+00.0624592s o:+06.1071022s [ | * ] 16:44:04 d:+00.0624592s o:+06.7836298s [ | * ] 16:44:34 d:+00.0624592s o:+07.0382848s [ | * ] 16:45:04 d:+00.0624216s o:+07.2666513s [ | * ] 16:45:34 d:+00.0624216s o:+07.6019390s [ | * ] 16:46:04 d:+00.0624216s o:+08.1559809s [ | * ] 16:46:34 d:+00.0624216s o:+08.5850204s [ | * ] 16:47:05 d:+00.0637092s o:+08.6929941s [ | * ] I have two identical servers, running these same HVMs, and both do the same exact thing. Both servers are Supermicro's with dual Xeon L5630 CPUs and 64gig of ram. I can't help but think that the VCPUs has something to do with this... I really can't try upping the VCPUs as these are running in production/dr environments. Any ideas? Thanks :-) Tod --047d7b603fe648fd3e04d79964fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SSBhbSBydW5uaW5nIFhlbiA0LjAuMSBvbiBkZWJpYW4gc3F1ZWV6ZS4gSSBoYXZlIDIgV2luMjAw OFIyIEhWTXMgcnVubmluZyBvbiBpdC6gIERvbTAgaXMgdXNpbmcgTlRQRGF0ZSBhbmQgaGFzIGEg c29saWQgdGltZS4gWmVybyBwcm9ibGVtIHdpdGggRG9tMC4gTm93LKAgdGhlIHN0cmFuZ2UgcGFy dC6gIE9uZSB2bSYjMzk7cyBjbG9jayBkcmlmdHMsoCB3aGlsZSB0aGUgb3RoZXIgdm0mIzM5O3Mg Y2xvY2sgZG9lcyBub3QgZHJpZnQuoCBPZiBjb3Vyc2UgSSBkbyB1c2UgTlRQIGFzIGJvdGggYXJl IHBhcnQgb2YgYSB3aW5kb3dzIGRvbWFpbiygIHNvIHVsdGltYXRlbHkgVzMyVE0gZG9lcyBjb3Jy ZWN0IHRoZSBpc3N1ZSAob3Iga2VlcHMgaXQgd2l0aGluIHRoZSBkb21haW4gdG9sZXJhbmNlKS4g VGhlIC5DRkdzIGFyZSBpZGVudGljYWwgZXhjZXB0IGZvciB0aGUgcmFtL2Rpc2tzIGFuZC4uLiBW Q1BVczxicj4NCg0KPGJyPk9LLKAgSFZNIGNvbmZpZ3MuIFRoZXNlIHNldHRpbmdzIGFyZSBjb21t b24gaW4gYm90aCB0aGUgVk0gdGhhdCBkcmlmdHMgYW5kIHRoZSBvbmUgdGhhdCBkb2VzIG5vdC4g PGJyPjxicj5hY3BpID0gMTxicj5hcGljID0gMTxicj5kZXZpY2VfbW9kZWwgPSAmIzM5Oy91c3Iv bGliL3hlbi00LjAvYmluL3FlbXUtZG0mIzM5Ozxicj5ib290PSZxdW90O2MmcXVvdDs8YnI+bG9j YWx0aW1lPTE8YnI+DQpzZGw9MDxicj5zZXJpYWw9JiMzOTtwdHkmIzM5Ozxicj50aW1lcl9tb2Rl PTI8YnI+dmlyaWRpYW49MTxicj48YnI+Tm93IGZvciB0aGUgRGlmZmVyZW5jZXMuLi4uPGJyPjxi cj4qKioqKioqKioqIERvZXMgbm90IERyaWZ0ICoqKioqKioqKio8YnI+YnVpbGRlcj0mIzM5O2h2 bSYjMzk7PGJyPm1lbW9yeSA9IDE2Mzg0PGJyPnNoYWRvd19tZW1vcnkgPSA5Njxicj52Y3B1cz02 PGJyPmNwdXM9JnF1b3Q7OC0xNSZxdW90Ozxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPGJyPjxicj4qKioqKioqKioqIERyaWZ0cyAqKioqKioqKioqPGJyPmJ1aWxk ZXI9JiMzOTtodm0mIzM5Ozxicj5tZW1vcnkgPSA4MDk2PGJyPnNoYWRvd19tZW1vcnkgPSAzMDxi cj5jcHVzPSZxdW90OzQtNSZxdW90Ozxicj52Y3B1cz0yPGJyPioqKioqKioqKioqKioqKioqKioq KioqKioqKio8YnI+QmVsb3cgaXMgYSAvc3RyaXBjaGFydCBmcm9tIFczMlRNIGluIHRoZSBvbmUg dGhhdCBkcmlmdHMuIDxicj4NCjxicj4xNjozOTowMiBkOiswMC4wNjI1NjM2cyBvOiswMy44ODg0 NTgxc6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKAgKqCgoKCgoKCgoKCg oKCgoCBdPGJyPjE2OjM5OjMzIGQ6KzAwLjA2MjU2MzZzIG86KzAzLjkwNTI0MTZzoCBboKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKAgfKCgoKCgoKCgoCAqoKCgoKCgoKCgoKCgoKCgIF08YnI+MTY6 NDA6MDMgZDorMDAuMDYyNDU5MnMgbzorMDMuOTY1MTk4M3OgIFugoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoCB8oKCgoKCgoKCgICqgoKCgoKCgoKCgoKCgoKAgXTxicj4NCjE2OjQwOjMzIGQ6KzAw LjA2MjQ1OTJzIG86KzA0LjEyNjA5MTBzoCBboKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgfKCg oKCgoKCgoCAqoKCgoKCgoKCgoKCgoKCgIF08YnI+MTY6NDE6MDMgZDorMDAuMDYyNDU5MnMgbzor MDQuMzE4MjM0M3OgIFugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCB8oKCgoKCgoKCgoCAqoKCg oKCgoKCgoKCgoKAgXTxicj4xNjo0MTozMyBkOiswMC4wNzgwNzQwcyBvOiswNC43MzY5NDk3c6Ag W6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKCgoCAqoKCgoKCgoKCgoKCgoCBd PGJyPg0KMTY6NDI6MDMgZDorMDAuMDYyNDU5MnMgbzorMDQuOTUyNTM2MnOgIFugoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCgICqgoKCgoKCgoKCgoKAgXTxicj4xNjo0Mjoz MyBkOiswMC4wNjI0NTkycyBvOiswNS4zNDc4MDg0c6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgIHygoKCgoKCgoKCgoKCgICqgoKCgoKCgoKCgoCBdPGJyPjE2OjQzOjA0IGQ6KzAwLjA2MjQ1 OTJzIG86KzA1Ljc0MzA4MDZzoCBboKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgfKCgoKCgoKCg oKCgoKCgICqgoKCgoKCgoKCgIF08YnI+DQoxNjo0MzozNCBkOiswMC4wNjI0NTkycyBvOiswNi4x MDcxMDIyc6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKCgoKCgoKAgKqCg oKCgoKCgoCBdPGJyPjE2OjQ0OjA0IGQ6KzAwLjA2MjQ1OTJzIG86KzA2Ljc4MzYyOThzoCBboKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgfKCgoKCgoKCgoKCgoKCgoKCgICqgoKCgoKCgIF08YnI+ MTY6NDQ6MzQgZDorMDAuMDYyNDU5MnMgbzorMDcuMDM4Mjg0OHOgIFugoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCgoKCgoKAgKqCgoKCgoKAgXTxicj4NCjE2OjQ1OjA0IGQ6 KzAwLjA2MjQyMTZzIG86KzA3LjI2NjY1MTNzoCBboKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAg fKCgoKCgoKCgoKCgoKCgoKCgoCAqoKCgoKCgIF08YnI+MTY6NDU6MzQgZDorMDAuMDYyNDIxNnMg bzorMDcuNjAxOTM5MHOgIFugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCg oKCgoKCgoCAqoKCgoKAgXTxicj4xNjo0NjowNCBkOiswMC4wNjI0MjE2cyBvOiswOC4xNTU5ODA5 c6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgIHygoKCgoKCgoKCgoKCgoKCgoKCgoCAqoKCg oCBdPGJyPg0KMTY6NDY6MzQgZDorMDAuMDYyNDIxNnMgbzorMDguNTg1MDIwNHOgIFugoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoCB8oKCgoKCgoKCgoKCgoKCgoKCgoKCgoCAqoKAgXTxicj4xNjo0 NzowNSBkOiswMC4wNjM3MDkycyBvOiswOC42OTI5OTQxc6AgW6CgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgIHygoKCgoKCgoKCgoKCgoKCgoKCgoKCgICqgoCBdPGJyPjxicj48YnI+SSBoYXZlIHR3 byBpZGVudGljYWwgc2VydmVycyygIHJ1bm5pbmcgdGhlc2Ugc2FtZSBIVk1zLKAgYW5kIGJvdGgg ZG8gdGhlIHNhbWUgZXhhY3QgdGhpbmcuIEJvdGggc2VydmVycyBhcmUgU3VwZXJtaWNybyYjMzk7 cyB3aXRoIGR1YWwgWGVvbiBMNTYzMCBDUFVzIGFuZCA2NGdpZyBvZiByYW0uIEkgY2FuJiMzOTt0 IGhlbHAgYnV0IHRoaW5rIHRoYXQgdGhlIFZDUFVzIGhhcyBzb21ldGhpbmcgdG8gZG8gd2l0aCB0 aGlzLi4uIEkgcmVhbGx5IGNhbiYjMzk7dCB0cnkgdXBwaW5nIHRoZSBWQ1BVcyBhcyB0aGVzZSBh cmUgcnVubmluZyBpbiBwcm9kdWN0aW9uL2RyIGVudmlyb25tZW50cy4gPGJyPg0KPGJyPkFueSBp ZGVhcz88YnI+PGJyPlRoYW5rcyA6LSk8YnI+PGJyPlRvZDxicj48YnI+PGJyPjxicj48YnI+PGJy Pg0K --047d7b603fe648fd3e04d79964fb-- --===============3336504177830855372== 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 --===============3336504177830855372==-- From xen-users-bounces@lists.xen.org Mon Mar 11 11:26:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 11:26: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 1UF0qf-00015s-Bd; Mon, 11 Mar 2013 11:24:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF0qc-00015k-SH for xen-users@lists.xensource.com; Mon, 11 Mar 2013 11:24:55 +0000 Received: from [85.158.138.51:56395] by server-15.bemta-3.messagelabs.com id 32/18-23142-10FBD315; Mon, 11 Mar 2013 11:24:49 +0000 X-Env-Sender: cristi@elvsoft.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1363001079!30195315!1 X-Originating-IP: [65.55.88.15] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8, spamassassin: , async_handler: YXN5bmNfZGVsYXk6IDcwNDgyMTYgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3279 invoked from network); 11 Mar 2013 11:24:40 -0000 Received: from tx2ehsobe005.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.15) by server-2.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 11 Mar 2013 11:24:40 -0000 Received: from mail99-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 11:24:39 +0000 Received: from mail99-tx2 (localhost [127.0.0.1]) by mail99-tx2-R.bigfish.com (Postfix) with ESMTP id EBADE4A011C for ; Mon, 11 Mar 2013 11:24:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.197; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0511HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: S0(zzc85fhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz17326ahz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah34h1155h) Received-SPF: pass (mail99-tx2: domain of elvsoft.com designates 157.56.250.197 as permitted sender) client-ip=157.56.250.197; envelope-from=cristi@elvsoft.com; helo=AMSPRD0511HT004.eurprd05.prod.outlook.com ; .outlook.com ; Received: from mail99-tx2 (localhost.localdomain [127.0.0.1]) by mail99-tx2 (MessageSwitch) id 136300107535517_10931; Mon, 11 Mar 2013 11:24:35 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.246]) by mail99-tx2.bigfish.com (Postfix) with ESMTP id E164D4400C1 for ; Mon, 11 Mar 2013 11:24:34 +0000 (UTC) Received: from AMSPRD0511HT004.eurprd05.prod.outlook.com (157.56.250.197) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 11:24:34 +0000 Received: from AMSPRD0511MB545.eurprd05.prod.outlook.com ([169.254.1.90]) by AMSPRD0511HT004.eurprd05.prod.outlook.com ([10.242.15.165]) with mapi id 14.16.0263.000; Mon, 11 Mar 2013 11:24:30 +0000 From: Tomoiaga Cristian To: "xen-users@lists.xensource.com" Thread-Topic: Possible bug in Xen 4.2.1 when rebooting domU after save/restore Thread-Index: Ac4eStQGJHLI8f9LQY6CniMRvpUpCw== Date: Mon, 11 Mar 2013 11:24:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [78.96.54.61] MIME-Version: 1.0 X-OriginatorOrg: elvsoft.com Subject: [Xen-users] Possible bug in Xen 4.2.1 when rebooting domU after save/restore X-BeenThere: xen-users@lists.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="===============5471527933842163648==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5471527933842163648== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D4_01CE1E5B.B393FB00" ------=_NextPart_000_00D4_01CE1E5B.B393FB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, After saving and restoring a DomU (teste on the same server), doing a reboot to the newly restored domU will cause it to crash. This happens on PV and PVHVM domUs. I am using qemu upstream for the HVM guests, but I don't really think it matters as long as PV guests behave the same. I want to confirm this if possible, before submitting a bug report and more details. I am using CentOS 6 with this mirrorlist: http://www.crc.id.au/repo/mirrorlist-el6.txt To reproduce: xl save [domid] ./somefile xl restore -d path_to_domU.cfg ./somefile xl reboot [newdomid] xl info: host : xenrotest release : 3.8.2-3.el6xen.x86_64 version : #1 SMP Sat Mar 9 20:43:07 EST 2013 machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 3192 hw_caps : bfebfbff:28100800:00000000:00003f40:17bae3ff:00000000:00000001:00000000 virt_caps : hvm hvm_directio total_memory : 16361 free_memory : 15121 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .1 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 : unavailable xen_commandline : dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin log_lvl=all guest_loglvl=all cc_compiler : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) cc_compile_by : mockbuild cc_compile_domain : crc.id.au cc_compile_date : Sat Feb 16 19:16:38 EST 2013 xend_config_format : 4 Xen xl log, after issuing the reboot command: Domain 8 needs to be cleaned up: destroying the domain Done. Rebooting now xc: error: 0-length read: Internal error xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error xc: error: read: p2m_size (0 = Success): Internal error libxl: error: libxl_create.c:820:libxl__xc_domain_restore_done: restoring domain: Success libxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1394:libxl__destroy_domid: non-existant domain 9 libxl: error: libxl.c:1358:domain_destroy_callback: unable to destroy guest with domid 9 libxl: error: libxl_create.c:1153:domcreate_destruction_cb: unable to destroy domain 9 following failed creation xl save/restore and other details can be attached if needed. Regards, Cristian Tomoiaga ------=_NextPart_000_00D4_01CE1E5B.B393FB00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUSDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBbqbMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwMTE3MTUwMTMwWhcNMTQwMTE3MjEyNDIwWjBbMRkwFwYDVQQNExBKcHMwbEs4VjM0S00yNWpI MRswGQYDVQQDDBJjcmlzdGlAZWx2c29mdC5jb20xITAfBgkqhkiG9w0BCQEWEmNyaXN0aUBlbHZz b2Z0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtoWGa/XxDqv35clMugCYaw V7MCVtdgmuhihqVwP2rbRh16hd3VlbDM6wE9niCJYkuBGDS2wxgYYJEsKxbh/3aKQlI5Ld60LboQ 5AAb4Rxtjn62Qhzo+gIr5KNHENtdFM1TjMsBipoWq0nbgw07g56d2Im9OApPa5uftOa4f06/lN6x oeOH0INVJkfKwjEpJVDNodxwXxX3e+L0A2Z9xmT+aoUPKFGbY2ZH+tsTHjbhQZ+t2tP5ai7RTHRn gN8CFr2SR4kUaUoCNNNqjB9rNv5k+oh2P23e4c/3adBMje0EJAD8OENBDu961ALpPZ/oZXwA5cRF ZpKMD1827xn19YkCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU62pBfoHSU6BQnoomgUHBOlFaAo0wHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESY3Jpc3RpQGVsdnNvZnQu Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJPq+gx5D/9vlGKScJstceRTO0FCP1N9zI0zRK6D/ dXRMj1rolLp2Eawx7bXUQYUCUEPsIeOXWrcsM9jB8+oHtRx7omcRdaNetPA6VMR8pVyAKHByEc70 Q3/6Hq/1ubjVNeQJKt8SH+lXj+nmTaoAZiKxiuqhmm7EzRBXV2WdSJiwzU6kKMzMdOVY2jD1MNHS S/VMUc7NnvPbyeUphQWEm2UjxLCYUPR8ofwAjSQ0CJaybUlhCYXbEqO32dwBewL/Q6NTEoX56sIT EkluYALq2WVmYzpzrQYUdB8UmImVk/rXJMF0Mp5HcK+htl6xKORg2js3Oqge3JHltCYeJHfi6TCC B8kwggWxoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYz NloXDTM2MDkxNzE5NDYzNlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEAwYjbCbxsRnx4n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOF HKHTPbQzK9Mvr/7qsEFZZ7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P 7u000BHHls1SPboz1t1N3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjK LR8HlzABLXJ5+kbWEyqouaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2 ROFzYh87xL6gU1YlbFEJ96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevo bE1wWyllnN2qXcyvATHsDOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJ ixamuyx+F14FTVhuEh0B7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7 afhwx/p6N9jYDdJ2T1f/kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8 ibYZKnMBCg8DsxJg8novgdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7 jHQTUksCAwEAAaOCAlIwggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBRO C+8apEBbpRdphzDKNGhD0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvc2ZzY2EtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDCCAV0GA1UdIASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIB FiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDov L2NlcnQuc3RhcnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0 YXJ0IENvbW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwg cmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3Rh cnRDb20gRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIB ABZsmfRmDDT10IVefQrs2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02 hytLu2jTOWY9oCbH8jmRHVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwe tfKe9Kkpg/iyFONuKIdEw5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2P gVGaO42J9E2TZns8A+3Tmh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37D a2q5w8tES6x4kIvnxyweSxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKG pR5nZK0GLi+pcIXHlg98iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6 glKg769LVZPrwbXwIousNE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4 xZlDY+NN4Hct4WWZcmkEGkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cC xQkbCNxVN+KB+zeEQ2IgyudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INe MYIEHTCCBBkCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbqbMAkGBSsOAwIa BQCgggJdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMxMTEx MjQwNFowIwYJKoZIhvcNAQkEMRYEFMSO+4EvF5DSiBcgoxvywk+1R2chMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFz cyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbqbMIGnBgsqhkiG9w0BCRACCzGB l6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFupswgasGCSqGSIb3DQEJDzGBnTCB mjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggq hkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4D AhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAHoevOKCo3WMczMJIwtxcOgVDgs32kWICGmbBiLNccLFl8KowCS1dMFsSwmeaiKXy7RUnn16T vCyeq8UHRMAdBHy1ALZpdDBDaOXeVsN4L+x78CxVeVfOK+HiJq9Xpq/PvFSrQMIKjR6xBIdmK21/ qwudRFFpZdGXBMqrdYUaTIEUi6azvYIKNR7Zq87IVWKmIMBaWlNzZvkRZgkBSLc749PACE2CKLrd cFTM/gmIemOPlak77zQbfNYXT27ai9dXj5gABzs8APSBiVcn38L7H+Hrg5pLJA0pKyuXMYzPiNzm jYwixqdjlnD69LSmjL8W2HyvXN4Yop2XKZk6astD3gAAAAAAAA== ------=_NextPart_000_00D4_01CE1E5B.B393FB00-- --===============5471527933842163648== 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 --===============5471527933842163648==-- From xen-users-bounces@lists.xen.org Mon Mar 11 11:26:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 11:26: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 1UF0qf-00015s-Bd; Mon, 11 Mar 2013 11:24:57 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF0qc-00015k-SH for xen-users@lists.xensource.com; Mon, 11 Mar 2013 11:24:55 +0000 Received: from [85.158.138.51:56395] by server-15.bemta-3.messagelabs.com id 32/18-23142-10FBD315; Mon, 11 Mar 2013 11:24:49 +0000 X-Env-Sender: cristi@elvsoft.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1363001079!30195315!1 X-Originating-IP: [65.55.88.15] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8, spamassassin: , async_handler: YXN5bmNfZGVsYXk6IDcwNDgyMTYgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3279 invoked from network); 11 Mar 2013 11:24:40 -0000 Received: from tx2ehsobe005.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.15) by server-2.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 11 Mar 2013 11:24:40 -0000 Received: from mail99-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 11:24:39 +0000 Received: from mail99-tx2 (localhost [127.0.0.1]) by mail99-tx2-R.bigfish.com (Postfix) with ESMTP id EBADE4A011C for ; Mon, 11 Mar 2013 11:24:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.197; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0511HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: S0(zzc85fhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz17326ahz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah34h1155h) Received-SPF: pass (mail99-tx2: domain of elvsoft.com designates 157.56.250.197 as permitted sender) client-ip=157.56.250.197; envelope-from=cristi@elvsoft.com; helo=AMSPRD0511HT004.eurprd05.prod.outlook.com ; .outlook.com ; Received: from mail99-tx2 (localhost.localdomain [127.0.0.1]) by mail99-tx2 (MessageSwitch) id 136300107535517_10931; Mon, 11 Mar 2013 11:24:35 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.246]) by mail99-tx2.bigfish.com (Postfix) with ESMTP id E164D4400C1 for ; Mon, 11 Mar 2013 11:24:34 +0000 (UTC) Received: from AMSPRD0511HT004.eurprd05.prod.outlook.com (157.56.250.197) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 11:24:34 +0000 Received: from AMSPRD0511MB545.eurprd05.prod.outlook.com ([169.254.1.90]) by AMSPRD0511HT004.eurprd05.prod.outlook.com ([10.242.15.165]) with mapi id 14.16.0263.000; Mon, 11 Mar 2013 11:24:30 +0000 From: Tomoiaga Cristian To: "xen-users@lists.xensource.com" Thread-Topic: Possible bug in Xen 4.2.1 when rebooting domU after save/restore Thread-Index: Ac4eStQGJHLI8f9LQY6CniMRvpUpCw== Date: Mon, 11 Mar 2013 11:24:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [78.96.54.61] MIME-Version: 1.0 X-OriginatorOrg: elvsoft.com Subject: [Xen-users] Possible bug in Xen 4.2.1 when rebooting domU after save/restore X-BeenThere: xen-users@lists.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="===============5471527933842163648==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5471527933842163648== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D4_01CE1E5B.B393FB00" ------=_NextPart_000_00D4_01CE1E5B.B393FB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, After saving and restoring a DomU (teste on the same server), doing a reboot to the newly restored domU will cause it to crash. This happens on PV and PVHVM domUs. I am using qemu upstream for the HVM guests, but I don't really think it matters as long as PV guests behave the same. I want to confirm this if possible, before submitting a bug report and more details. I am using CentOS 6 with this mirrorlist: http://www.crc.id.au/repo/mirrorlist-el6.txt To reproduce: xl save [domid] ./somefile xl restore -d path_to_domU.cfg ./somefile xl reboot [newdomid] xl info: host : xenrotest release : 3.8.2-3.el6xen.x86_64 version : #1 SMP Sat Mar 9 20:43:07 EST 2013 machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 3192 hw_caps : bfebfbff:28100800:00000000:00003f40:17bae3ff:00000000:00000001:00000000 virt_caps : hvm hvm_directio total_memory : 16361 free_memory : 15121 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .1 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 : unavailable xen_commandline : dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin log_lvl=all guest_loglvl=all cc_compiler : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) cc_compile_by : mockbuild cc_compile_domain : crc.id.au cc_compile_date : Sat Feb 16 19:16:38 EST 2013 xend_config_format : 4 Xen xl log, after issuing the reboot command: Domain 8 needs to be cleaned up: destroying the domain Done. Rebooting now xc: error: 0-length read: Internal error xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error xc: error: read: p2m_size (0 = Success): Internal error libxl: error: libxl_create.c:820:libxl__xc_domain_restore_done: restoring domain: Success libxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1394:libxl__destroy_domid: non-existant domain 9 libxl: error: libxl.c:1358:domain_destroy_callback: unable to destroy guest with domid 9 libxl: error: libxl_create.c:1153:domcreate_destruction_cb: unable to destroy domain 9 following failed creation xl save/restore and other details can be attached if needed. Regards, Cristian Tomoiaga ------=_NextPart_000_00D4_01CE1E5B.B393FB00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUSDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBbqbMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwMTE3MTUwMTMwWhcNMTQwMTE3MjEyNDIwWjBbMRkwFwYDVQQNExBKcHMwbEs4VjM0S00yNWpI MRswGQYDVQQDDBJjcmlzdGlAZWx2c29mdC5jb20xITAfBgkqhkiG9w0BCQEWEmNyaXN0aUBlbHZz b2Z0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtoWGa/XxDqv35clMugCYaw V7MCVtdgmuhihqVwP2rbRh16hd3VlbDM6wE9niCJYkuBGDS2wxgYYJEsKxbh/3aKQlI5Ld60LboQ 5AAb4Rxtjn62Qhzo+gIr5KNHENtdFM1TjMsBipoWq0nbgw07g56d2Im9OApPa5uftOa4f06/lN6x oeOH0INVJkfKwjEpJVDNodxwXxX3e+L0A2Z9xmT+aoUPKFGbY2ZH+tsTHjbhQZ+t2tP5ai7RTHRn gN8CFr2SR4kUaUoCNNNqjB9rNv5k+oh2P23e4c/3adBMje0EJAD8OENBDu961ALpPZ/oZXwA5cRF ZpKMD1827xn19YkCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU62pBfoHSU6BQnoomgUHBOlFaAo0wHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESY3Jpc3RpQGVsdnNvZnQu Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJPq+gx5D/9vlGKScJstceRTO0FCP1N9zI0zRK6D/ dXRMj1rolLp2Eawx7bXUQYUCUEPsIeOXWrcsM9jB8+oHtRx7omcRdaNetPA6VMR8pVyAKHByEc70 Q3/6Hq/1ubjVNeQJKt8SH+lXj+nmTaoAZiKxiuqhmm7EzRBXV2WdSJiwzU6kKMzMdOVY2jD1MNHS S/VMUc7NnvPbyeUphQWEm2UjxLCYUPR8ofwAjSQ0CJaybUlhCYXbEqO32dwBewL/Q6NTEoX56sIT EkluYALq2WVmYzpzrQYUdB8UmImVk/rXJMF0Mp5HcK+htl6xKORg2js3Oqge3JHltCYeJHfi6TCC B8kwggWxoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYz NloXDTM2MDkxNzE5NDYzNlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEAwYjbCbxsRnx4n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOF HKHTPbQzK9Mvr/7qsEFZZ7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P 7u000BHHls1SPboz1t1N3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjK LR8HlzABLXJ5+kbWEyqouaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2 ROFzYh87xL6gU1YlbFEJ96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevo bE1wWyllnN2qXcyvATHsDOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJ ixamuyx+F14FTVhuEh0B7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7 afhwx/p6N9jYDdJ2T1f/kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8 ibYZKnMBCg8DsxJg8novgdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7 jHQTUksCAwEAAaOCAlIwggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBRO C+8apEBbpRdphzDKNGhD0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvc2ZzY2EtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDCCAV0GA1UdIASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIB FiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDov L2NlcnQuc3RhcnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0 YXJ0IENvbW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwg cmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3Rh cnRDb20gRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIB ABZsmfRmDDT10IVefQrs2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02 hytLu2jTOWY9oCbH8jmRHVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwe tfKe9Kkpg/iyFONuKIdEw5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2P gVGaO42J9E2TZns8A+3Tmh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37D a2q5w8tES6x4kIvnxyweSxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKG pR5nZK0GLi+pcIXHlg98iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6 glKg769LVZPrwbXwIousNE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4 xZlDY+NN4Hct4WWZcmkEGkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cC xQkbCNxVN+KB+zeEQ2IgyudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INe MYIEHTCCBBkCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbqbMAkGBSsOAwIa BQCgggJdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMxMTEx MjQwNFowIwYJKoZIhvcNAQkEMRYEFMSO+4EvF5DSiBcgoxvywk+1R2chMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFz cyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbqbMIGnBgsqhkiG9w0BCRACCzGB l6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFupswgasGCSqGSIb3DQEJDzGBnTCB mjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggq hkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4D AhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAHoevOKCo3WMczMJIwtxcOgVDgs32kWICGmbBiLNccLFl8KowCS1dMFsSwmeaiKXy7RUnn16T vCyeq8UHRMAdBHy1ALZpdDBDaOXeVsN4L+x78CxVeVfOK+HiJq9Xpq/PvFSrQMIKjR6xBIdmK21/ qwudRFFpZdGXBMqrdYUaTIEUi6azvYIKNR7Zq87IVWKmIMBaWlNzZvkRZgkBSLc749PACE2CKLrd cFTM/gmIemOPlak77zQbfNYXT27ai9dXj5gABzs8APSBiVcn38L7H+Hrg5pLJA0pKyuXMYzPiNzm jYwixqdjlnD69LSmjL8W2HyvXN4Yop2XKZk6astD3gAAAAAAAA== ------=_NextPart_000_00D4_01CE1E5B.B393FB00-- --===============5471527933842163648== 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 --===============5471527933842163648==-- From xen-users-bounces@lists.xen.org Mon Mar 11 11:27:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 11:27: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 1UF0sY-0001Br-6s; Mon, 11 Mar 2013 11:26:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF0sW-0001Bg-9n for xen-users@lists.xen.org; Mon, 11 Mar 2013 11:26:52 +0000 Received: from [85.158.137.99:5171] by server-12.bemta-3.messagelabs.com id 09/9C-01357-B7FBD315; Mon, 11 Mar 2013 11:26:51 +0000 X-Env-Sender: cristi@elvsoft.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1363001201!16908044!1 X-Originating-IP: [65.55.88.14] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8, spamassassin: , async_handler: YXN5bmNfZGVsYXk6IDcwNDUyMDMgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4516 invoked from network); 11 Mar 2013 11:26:42 -0000 Received: from tx2ehsobe004.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.14) by server-11.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 11 Mar 2013 11:26:42 -0000 Received: from mail158-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 11:26:40 +0000 Received: from mail158-tx2 (localhost [127.0.0.1]) by mail158-tx2-R.bigfish.com (Postfix) with ESMTP id D593D801CC for ; Mon, 11 Mar 2013 11:26:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.197; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0511HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: S0(zzc85fhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz17326ahz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah34h1155h) Received-SPF: pass (mail158-tx2: domain of elvsoft.com designates 157.56.250.197 as permitted sender) client-ip=157.56.250.197; envelope-from=cristi@elvsoft.com; helo=AMSPRD0511HT004.eurprd05.prod.outlook.com ; .outlook.com ; Received: from mail158-tx2 (localhost.localdomain [127.0.0.1]) by mail158-tx2 (MessageSwitch) id 1363001199170595_6751; Mon, 11 Mar 2013 11:26:39 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.242]) by mail158-tx2.bigfish.com (Postfix) with ESMTP id 1C3C01A01E9 for ; Mon, 11 Mar 2013 11:26:39 +0000 (UTC) Received: from AMSPRD0511HT004.eurprd05.prod.outlook.com (157.56.250.197) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 11:26:38 +0000 Received: from AMSPRD0511MB545.eurprd05.prod.outlook.com ([169.254.1.90]) by AMSPRD0511HT004.eurprd05.prod.outlook.com ([10.242.15.165]) with mapi id 14.16.0263.000; Mon, 11 Mar 2013 11:26:36 +0000 From: Tomoiaga Cristian To: "xen-users@lists.xen.org" Thread-Topic: Possible bug in Xen 4.2.1 when rebooting domU after save/restore Thread-Index: Ac4eSzkqg2eHvKR4SkmvFCpqj3oUsw== Date: Mon, 11 Mar 2013 11:26:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [78.96.54.61] MIME-Version: 1.0 X-OriginatorOrg: elvsoft.com Subject: [Xen-users] Possible bug in Xen 4.2.1 when rebooting domU after save/restore X-BeenThere: xen-users@lists.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="===============5230007040409729646==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5230007040409729646== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F2_01CE1E5B.FEB3DA60" ------=_NextPart_000_00F2_01CE1E5B.FEB3DA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, After saving and restoring a DomU (teste on the same server), doing a reboot to the newly restored domU will cause it to crash. This happens on PV and PVHVM domUs. I am using qemu upstream for the HVM guests, but I don't really think it matters as long as PV guests behave the same. I want to confirm this if possible, before submitting a bug report and more details. I am using CentOS 6 with this mirrorlist: http://www.crc.id.au/repo/mirrorlist-el6.txt To reproduce: xl save [domid] ./somefile xl restore -d path_to_domU.cfg ./somefile xl reboot [newdomid] xl info: host : xenrotest release : 3.8.2-3.el6xen.x86_64 version : #1 SMP Sat Mar 9 20:43:07 EST 2013 machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 3192 hw_caps : bfebfbff:28100800:00000000:00003f40:17bae3ff:00000000:00000001:00000000 virt_caps : hvm hvm_directio total_memory : 16361 free_memory : 15121 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .1 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 : unavailable xen_commandline : dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin log_lvl=all guest_loglvl=all cc_compiler : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) cc_compile_by : mockbuild cc_compile_domain : crc.id.au cc_compile_date : Sat Feb 16 19:16:38 EST 2013 xend_config_format : 4 Xen xl log, after issuing the reboot command: Domain 8 needs to be cleaned up: destroying the domain Done. Rebooting now xc: error: 0-length read: Internal error xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error xc: error: read: p2m_size (0 = Success): Internal error libxl: error: libxl_create.c:820:libxl__xc_domain_restore_done: restoring domain: Success libxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1394:libxl__destroy_domid: non-existant domain 9 libxl: error: libxl.c:1358:domain_destroy_callback: unable to destroy guest with domid 9 libxl: error: libxl_create.c:1153:domcreate_destruction_cb: unable to destroy domain 9 following failed creation xl save/restore and other details can be attached if needed. Regards, Cristian Tomoiaga ------=_NextPart_000_00F2_01CE1E5B.FEB3DA60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUSDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBbqbMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwMTE3MTUwMTMwWhcNMTQwMTE3MjEyNDIwWjBbMRkwFwYDVQQNExBKcHMwbEs4VjM0S00yNWpI MRswGQYDVQQDDBJjcmlzdGlAZWx2c29mdC5jb20xITAfBgkqhkiG9w0BCQEWEmNyaXN0aUBlbHZz b2Z0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtoWGa/XxDqv35clMugCYaw V7MCVtdgmuhihqVwP2rbRh16hd3VlbDM6wE9niCJYkuBGDS2wxgYYJEsKxbh/3aKQlI5Ld60LboQ 5AAb4Rxtjn62Qhzo+gIr5KNHENtdFM1TjMsBipoWq0nbgw07g56d2Im9OApPa5uftOa4f06/lN6x oeOH0INVJkfKwjEpJVDNodxwXxX3e+L0A2Z9xmT+aoUPKFGbY2ZH+tsTHjbhQZ+t2tP5ai7RTHRn gN8CFr2SR4kUaUoCNNNqjB9rNv5k+oh2P23e4c/3adBMje0EJAD8OENBDu961ALpPZ/oZXwA5cRF ZpKMD1827xn19YkCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU62pBfoHSU6BQnoomgUHBOlFaAo0wHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESY3Jpc3RpQGVsdnNvZnQu Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJPq+gx5D/9vlGKScJstceRTO0FCP1N9zI0zRK6D/ dXRMj1rolLp2Eawx7bXUQYUCUEPsIeOXWrcsM9jB8+oHtRx7omcRdaNetPA6VMR8pVyAKHByEc70 Q3/6Hq/1ubjVNeQJKt8SH+lXj+nmTaoAZiKxiuqhmm7EzRBXV2WdSJiwzU6kKMzMdOVY2jD1MNHS S/VMUc7NnvPbyeUphQWEm2UjxLCYUPR8ofwAjSQ0CJaybUlhCYXbEqO32dwBewL/Q6NTEoX56sIT EkluYALq2WVmYzpzrQYUdB8UmImVk/rXJMF0Mp5HcK+htl6xKORg2js3Oqge3JHltCYeJHfi6TCC B8kwggWxoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYz NloXDTM2MDkxNzE5NDYzNlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEAwYjbCbxsRnx4n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOF HKHTPbQzK9Mvr/7qsEFZZ7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P 7u000BHHls1SPboz1t1N3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjK LR8HlzABLXJ5+kbWEyqouaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2 ROFzYh87xL6gU1YlbFEJ96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevo bE1wWyllnN2qXcyvATHsDOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJ ixamuyx+F14FTVhuEh0B7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7 afhwx/p6N9jYDdJ2T1f/kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8 ibYZKnMBCg8DsxJg8novgdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7 jHQTUksCAwEAAaOCAlIwggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBRO C+8apEBbpRdphzDKNGhD0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvc2ZzY2EtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDCCAV0GA1UdIASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIB FiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDov L2NlcnQuc3RhcnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0 YXJ0IENvbW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwg cmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3Rh cnRDb20gRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIB ABZsmfRmDDT10IVefQrs2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02 hytLu2jTOWY9oCbH8jmRHVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwe tfKe9Kkpg/iyFONuKIdEw5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2P gVGaO42J9E2TZns8A+3Tmh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37D a2q5w8tES6x4kIvnxyweSxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKG pR5nZK0GLi+pcIXHlg98iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6 glKg769LVZPrwbXwIousNE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4 xZlDY+NN4Hct4WWZcmkEGkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cC xQkbCNxVN+KB+zeEQ2IgyudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INe MYIEHTCCBBkCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbqbMAkGBSsOAwIa BQCgggJdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMxMTEx MjYxMFowIwYJKoZIhvcNAQkEMRYEFKeT//LukswJpLElVoFR4LvxW+LXMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFz cyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbqbMIGnBgsqhkiG9w0BCRACCzGB l6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFupswgasGCSqGSIb3DQEJDzGBnTCB mjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggq hkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4D AhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAG2jh03iUgD99+4R73TWzb4WZy7ZWFOsZLOL7ZcwikAa5ogsWebGOkFkezPh073gIaQBYxwuz aoO38N4mboQhZAoB+Dx/3PwMiYaRn4FET1yn2a1yEHkbmjhHXiW/HRpp5oEVfUyKq6GVUvOIiust pZZnkfbtf5AF/ikm9aRpCJqD1IsATVnR8Sa32A5DlATqQPwjIQzOMqmSBThLlaXtpU4Y8eHYz45m tgIsesijPD+girRtX0kkLEwJSKc7uBeVgj6opQsWz5UWIDDuR3rFxWEKYaHg9Id5HnHZXpaOUB1F 6yUtZKU0LJI46fsOT95NbSsox45IzxT50gJCx6QaeAAAAAAAAA== ------=_NextPart_000_00F2_01CE1E5B.FEB3DA60-- --===============5230007040409729646== 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 --===============5230007040409729646==-- From xen-users-bounces@lists.xen.org Mon Mar 11 11:27:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 11:27: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 1UF0sY-0001Br-6s; Mon, 11 Mar 2013 11:26:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF0sW-0001Bg-9n for xen-users@lists.xen.org; Mon, 11 Mar 2013 11:26:52 +0000 Received: from [85.158.137.99:5171] by server-12.bemta-3.messagelabs.com id 09/9C-01357-B7FBD315; Mon, 11 Mar 2013 11:26:51 +0000 X-Env-Sender: cristi@elvsoft.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1363001201!16908044!1 X-Originating-IP: [65.55.88.14] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8, spamassassin: , async_handler: YXN5bmNfZGVsYXk6IDcwNDUyMDMgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4516 invoked from network); 11 Mar 2013 11:26:42 -0000 Received: from tx2ehsobe004.messaging.microsoft.com (HELO tx2outboundpool.messaging.microsoft.com) (65.55.88.14) by server-11.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 11 Mar 2013 11:26:42 -0000 Received: from mail158-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 11:26:40 +0000 Received: from mail158-tx2 (localhost [127.0.0.1]) by mail158-tx2-R.bigfish.com (Postfix) with ESMTP id D593D801CC for ; Mon, 11 Mar 2013 11:26:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.197; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0511HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: S0(zzc85fhzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz17326ahz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah34h1155h) Received-SPF: pass (mail158-tx2: domain of elvsoft.com designates 157.56.250.197 as permitted sender) client-ip=157.56.250.197; envelope-from=cristi@elvsoft.com; helo=AMSPRD0511HT004.eurprd05.prod.outlook.com ; .outlook.com ; Received: from mail158-tx2 (localhost.localdomain [127.0.0.1]) by mail158-tx2 (MessageSwitch) id 1363001199170595_6751; Mon, 11 Mar 2013 11:26:39 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.242]) by mail158-tx2.bigfish.com (Postfix) with ESMTP id 1C3C01A01E9 for ; Mon, 11 Mar 2013 11:26:39 +0000 (UTC) Received: from AMSPRD0511HT004.eurprd05.prod.outlook.com (157.56.250.197) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 11:26:38 +0000 Received: from AMSPRD0511MB545.eurprd05.prod.outlook.com ([169.254.1.90]) by AMSPRD0511HT004.eurprd05.prod.outlook.com ([10.242.15.165]) with mapi id 14.16.0263.000; Mon, 11 Mar 2013 11:26:36 +0000 From: Tomoiaga Cristian To: "xen-users@lists.xen.org" Thread-Topic: Possible bug in Xen 4.2.1 when rebooting domU after save/restore Thread-Index: Ac4eSzkqg2eHvKR4SkmvFCpqj3oUsw== Date: Mon, 11 Mar 2013 11:26:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [78.96.54.61] MIME-Version: 1.0 X-OriginatorOrg: elvsoft.com Subject: [Xen-users] Possible bug in Xen 4.2.1 when rebooting domU after save/restore X-BeenThere: xen-users@lists.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="===============5230007040409729646==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5230007040409729646== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F2_01CE1E5B.FEB3DA60" ------=_NextPart_000_00F2_01CE1E5B.FEB3DA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, After saving and restoring a DomU (teste on the same server), doing a reboot to the newly restored domU will cause it to crash. This happens on PV and PVHVM domUs. I am using qemu upstream for the HVM guests, but I don't really think it matters as long as PV guests behave the same. I want to confirm this if possible, before submitting a bug report and more details. I am using CentOS 6 with this mirrorlist: http://www.crc.id.au/repo/mirrorlist-el6.txt To reproduce: xl save [domid] ./somefile xl restore -d path_to_domU.cfg ./somefile xl reboot [newdomid] xl info: host : xenrotest release : 3.8.2-3.el6xen.x86_64 version : #1 SMP Sat Mar 9 20:43:07 EST 2013 machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 3192 hw_caps : bfebfbff:28100800:00000000:00003f40:17bae3ff:00000000:00000001:00000000 virt_caps : hvm hvm_directio total_memory : 16361 free_memory : 15121 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .1 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 : unavailable xen_commandline : dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin log_lvl=all guest_loglvl=all cc_compiler : gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) cc_compile_by : mockbuild cc_compile_domain : crc.id.au cc_compile_date : Sat Feb 16 19:16:38 EST 2013 xend_config_format : 4 Xen xl log, after issuing the reboot command: Domain 8 needs to be cleaned up: destroying the domain Done. Rebooting now xc: error: 0-length read: Internal error xc: error: read_exact_timed failed (read rc: 0, errno: 0): Internal error xc: error: read: p2m_size (0 = Success): Internal error libxl: error: libxl_create.c:820:libxl__xc_domain_restore_done: restoring domain: Success libxl: error: libxl_create.c:902:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1394:libxl__destroy_domid: non-existant domain 9 libxl: error: libxl.c:1358:domain_destroy_callback: unable to destroy guest with domid 9 libxl: error: libxl_create.c:1153:domcreate_destruction_cb: unable to destroy domain 9 following failed creation xl save/restore and other details can be attached if needed. Regards, Cristian Tomoiaga ------=_NextPart_000_00F2_01CE1E5B.FEB3DA60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUSDCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBbqbMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwMTE3MTUwMTMwWhcNMTQwMTE3MjEyNDIwWjBbMRkwFwYDVQQNExBKcHMwbEs4VjM0S00yNWpI MRswGQYDVQQDDBJjcmlzdGlAZWx2c29mdC5jb20xITAfBgkqhkiG9w0BCQEWEmNyaXN0aUBlbHZz b2Z0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtoWGa/XxDqv35clMugCYaw V7MCVtdgmuhihqVwP2rbRh16hd3VlbDM6wE9niCJYkuBGDS2wxgYYJEsKxbh/3aKQlI5Ld60LboQ 5AAb4Rxtjn62Qhzo+gIr5KNHENtdFM1TjMsBipoWq0nbgw07g56d2Im9OApPa5uftOa4f06/lN6x oeOH0INVJkfKwjEpJVDNodxwXxX3e+L0A2Z9xmT+aoUPKFGbY2ZH+tsTHjbhQZ+t2tP5ai7RTHRn gN8CFr2SR4kUaUoCNNNqjB9rNv5k+oh2P23e4c/3adBMje0EJAD8OENBDu961ALpPZ/oZXwA5cRF ZpKMD1827xn19YkCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU62pBfoHSU6BQnoomgUHBOlFaAo0wHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESY3Jpc3RpQGVsdnNvZnQu Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJPq+gx5D/9vlGKScJstceRTO0FCP1N9zI0zRK6D/ dXRMj1rolLp2Eawx7bXUQYUCUEPsIeOXWrcsM9jB8+oHtRx7omcRdaNetPA6VMR8pVyAKHByEc70 Q3/6Hq/1ubjVNeQJKt8SH+lXj+nmTaoAZiKxiuqhmm7EzRBXV2WdSJiwzU6kKMzMdOVY2jD1MNHS S/VMUc7NnvPbyeUphQWEm2UjxLCYUPR8ofwAjSQ0CJaybUlhCYXbEqO32dwBewL/Q6NTEoX56sIT EkluYALq2WVmYzpzrQYUdB8UmImVk/rXJMF0Mp5HcK+htl6xKORg2js3Oqge3JHltCYeJHfi6TCC B8kwggWxoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYz NloXDTM2MDkxNzE5NDYzNlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0 YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEAwYjbCbxsRnx4n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOF HKHTPbQzK9Mvr/7qsEFZZ7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P 7u000BHHls1SPboz1t1N3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjK LR8HlzABLXJ5+kbWEyqouaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2 ROFzYh87xL6gU1YlbFEJ96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevo bE1wWyllnN2qXcyvATHsDOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJ ixamuyx+F14FTVhuEh0B7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7 afhwx/p6N9jYDdJ2T1f/kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8 ibYZKnMBCg8DsxJg8novgdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7 jHQTUksCAwEAAaOCAlIwggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBRO C+8apEBbpRdphzDKNGhD0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvc2ZzY2EtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDCCAV0GA1UdIASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIB FiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDov L2NlcnQuc3RhcnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0 YXJ0IENvbW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwg cmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3Rh cnRDb20gRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIB ABZsmfRmDDT10IVefQrs2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02 hytLu2jTOWY9oCbH8jmRHVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwe tfKe9Kkpg/iyFONuKIdEw5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2P gVGaO42J9E2TZns8A+3Tmh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37D a2q5w8tES6x4kIvnxyweSxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKG pR5nZK0GLi+pcIXHlg98iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6 glKg769LVZPrwbXwIousNE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4 xZlDY+NN4Hct4WWZcmkEGkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cC xQkbCNxVN+KB+zeEQ2IgyudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INe MYIEHTCCBBkCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbqbMAkGBSsOAwIa BQCgggJdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMxMTEx MjYxMFowIwYJKoZIhvcNAQkEMRYEFKeT//LukswJpLElVoFR4LvxW+LXMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFz cyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbqbMIGnBgsqhkiG9w0BCRACCzGB l6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFupswgasGCSqGSIb3DQEJDzGBnTCB mjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggq hkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4D AhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAG2jh03iUgD99+4R73TWzb4WZy7ZWFOsZLOL7ZcwikAa5ogsWebGOkFkezPh073gIaQBYxwuz aoO38N4mboQhZAoB+Dx/3PwMiYaRn4FET1yn2a1yEHkbmjhHXiW/HRpp5oEVfUyKq6GVUvOIiust pZZnkfbtf5AF/ikm9aRpCJqD1IsATVnR8Sa32A5DlATqQPwjIQzOMqmSBThLlaXtpU4Y8eHYz45m tgIsesijPD+girRtX0kkLEwJSKc7uBeVgj6opQsWz5UWIDDuR3rFxWEKYaHg9Id5HnHZXpaOUB1F 6yUtZKU0LJI46fsOT95NbSsox45IzxT50gJCx6QaeAAAAAAAAA== ------=_NextPart_000_00F2_01CE1E5B.FEB3DA60-- --===============5230007040409729646== 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 --===============5230007040409729646==-- From xen-users-bounces@lists.xen.org Mon Mar 11 13:50:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 13:50: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 1UF35y-0004yB-II; Mon, 11 Mar 2013 13:48:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF35v-0004y2-LZ for xen-users@lists.xen.org; Mon, 11 Mar 2013 13:48:53 +0000 Received: from [193.109.254.147:33050] by server-14.bemta-14.messagelabs.com id 9F/DC-05867-2C0ED315; Mon, 11 Mar 2013 13:48:50 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-8.tower-27.messagelabs.com!1363009729!9485142!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15108 invoked from network); 11 Mar 2013 13:48:49 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-8.tower-27.messagelabs.com with SMTP; 11 Mar 2013 13:48:49 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:58055) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UF35t-0004YL-7k (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Mon, 11 Mar 2013 13:48:49 +0000 Message-ID: <513DE0B9.5020005@cam.ac.uk> Date: Mon, 11 Mar 2013 13:48:41 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <5138E4E6.9080001@cam.ac.uk> In-Reply-To: Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============1826829167526069351==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============1826829167526069351== Content-Type: multipart/alternative; boundary="------------050705000505090107040109" This is a multi-part message in MIME format. --------------050705000505090107040109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit First of all, thank you for the suggestions. I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems. For 13.1 I never get anywhere close as per my previous messages. For 12.3 and 12.8 I at least get a BSOD, ####################################################################### A problem has been detected ... Attempt to reset the display driver and recover from timeout failed. If this is ... Techinal information: *** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) *** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca ####################################################################### Does anybody have any further ideas? Matt On 07/03/2013 21:42, John Sherwood wrote: > (and I should probably mention that it has been my experience that > that is the expected and correct behavior) > > On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood > wrote: > > Having the windows logo freeze in the VNC window has been my > experience with GPU passthrough as well. > > > On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck > > wrote: > > Hi, > > I believe that the Windows logo freezing in the vnc window is > normal behaviour when secondary GPU passthrough is working as > it should, since the display should be handed over to the GPU. > At least that was the case before when I was passing through a > HD6850 card as secondary to win7 using xl. But you should > expect output on the GPU, of course. > > Have you tried different versions of the catalyst driver? I > think that some users have reported problems with the latest > one (13-something). > > Regards, > Andreas > > 2013/3/7 Matthew Dean > > > Hi all, > > I've managed to get a windows 7 x64 hvm to boot and > install and I'm now looking to pass through a HD 7970 as a > secondary GPU. in order to prepare the devices for > passthrough I've used > > xl pci-assignable-add 83:00.0 > xl pci-assignable-add 83:00.1 > > Where I've identified the device pci ids using lspci. > This works fine and the devices appear when I call 'xl > pci-assignable-list'. After adding them to the vm config > (see below) I was able to get the vm to boot and the > devices appeared in device manager. Installing the ATI > drivers however has meant that on further boots the > machine never gets past the windows logo in the VNC > window and no output is generated from the ATI card. It > simply freezes there and the only way I can get back into > windows is via safe mode, even after uninstalling the ATI > software. > > Has anybody else experienced similar issues or have any > advice as to how to get this to work? I'm a bit stumped > and the wiki implies that this should 'just work'. > > Thank you in advance for any help. > > Matt > > Here is my machine config > > ########################################################### > > builder='hvm' > memory = 2048 > name = 'Windows7Test' > > vcpus=4 > pae=1 > acpi=1 > apic=1 > > disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] > pci = [ '83:00.0' , '83:00.1' ] > > on_poweroff = 'destroy' > on_reboot = 'restart' > on_crash = 'destroy' > > boot='cd' > > sdl=0 > vnc=1 > vncconsole=0 > vncpasswd='' > vnclisten='172.24.226.84' > > stdvga=0 > > serial='pty' > usbdevice='tablet' > > gfx_passthru=0 > pci_power_mgmt=1 > xen_platform_pci=1 > pci_msitranslate=1 > viridian=1 > hpet=1 > > ############################################################ > > And the vm produces the following qemu log in /var/log/xen/ > > ############################################################ > > domid: 4 > -videoram option does not work with cirrus vga device > model. Videoram set to 4M. > Strip off blktap sub-type prefix to > /xen-guests/img/windows7Test.img (drv 'aio') > Using file /xen-guests/img/windows7Test.img in read-write mode > Watching /local/domain/0/device-model/4/logdirty/cmd > Watching /local/domain/0/device-model/4/command > Watching /local/domain/4/cpu > char device redirected to /dev/pts/3 > qemu_map_cache_init nr_buckets = 10000 size 4194304 > shared page at pfn feffd > buffered io page at pfn feffb > Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 > 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/4/xen_extended_power_mgmt): > read error > 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. > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: > 0, size: 0 > xs_read(/local/domain/4/log-throttling): read error > qemu: ignoring not-understood drive > `/local/domain/4/log-throttling' > medium change watch on `/local/domain/4/log-throttling' - > unknown device, ignored > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: > 0, size: 0 > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device > 83:00.0 ... > register_real_device: Enable MSI translation via per > device option > register_real_device: Enable power management > pt_iomul_init: Error: pt_iomul_init can't open file > /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 > pt_register_regions: IO region registered (size=0x10000000 > base_addr=0xe000000c) > pt_register_regions: IO region registered (size=0x00040000 > base_addr=0xf0000004) > pt_register_regions: IO region registered (size=0x00000100 > base_addr=0x0000f001) > pt_register_regions: Expansion ROM registered > (size=0x00020000 base_addr=0xf0040000) > pt_msi_setup: msi mapped with pirq 67 > pci_intx: intx=1 > register_real_device: Real physical device 83:00.0 > registered successfuly! > IRQ type = MSI-INTx > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device > 83:00.1 ... > register_real_device: Enable MSI translation via per > device option > register_real_device: Enable power management > pt_iomul_init: Error: pt_iomul_init can't open file > /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 > pt_register_regions: IO region registered (size=0x00004000 > base_addr=0xf0060004) > pt_msi_setup: msi mapped with pirq 66 > pci_intx: intx=2 > register_real_device: Real physical device 83:00.1 > registered successfuly! > IRQ type = MSI-INTx > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 > len=268435456 index=0 first_map=1 > cirrus vga map change while on lfb mode > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 > len=262144 index=2 first_map=1 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 > len=16384 index=0 first_map=1 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 > first_map=1 > 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. > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 > len=268435456 index=0 first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 > len=262144 index=2 first_map=0 > pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 > first_map=0 > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 > len=268435456 index=0 first_map=0 > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 > len=262144 index=2 first_map=0 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 > first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 > len=16384 index=0 first_map=0 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 > len=16384 index=0 first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 > len=268435456 index=0 first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 > len=262144 index=2 first_map=0 > pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 > first_map=0 > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 > len=268435456 index=0 first_map=0 > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 > len=262144 index=2 first_map=0 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 > first_map=0 > pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx > translation > pci_intx: intx=1 > pt_msi_disable: Unmap msi with pirq 67 > pt_msgctrl_reg_write: setup msi for dev 20 > pt_msi_setup: msi mapped with pirq 67 > pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f > pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 > len=16384 index=0 first_map=0 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 > len=16384 index=0 first_map=0 > > ###################################################################### > > _______________________________________________ > 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 > > > --------------050705000505090107040109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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



--------------050705000505090107040109-- --===============1826829167526069351== 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 --===============1826829167526069351==-- From xen-users-bounces@lists.xen.org Mon Mar 11 13:50:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 13:50: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 1UF35y-0004yB-II; Mon, 11 Mar 2013 13:48:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF35v-0004y2-LZ for xen-users@lists.xen.org; Mon, 11 Mar 2013 13:48:53 +0000 Received: from [193.109.254.147:33050] by server-14.bemta-14.messagelabs.com id 9F/DC-05867-2C0ED315; Mon, 11 Mar 2013 13:48:50 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-8.tower-27.messagelabs.com!1363009729!9485142!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15108 invoked from network); 11 Mar 2013 13:48:49 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-8.tower-27.messagelabs.com with SMTP; 11 Mar 2013 13:48:49 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:58055) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UF35t-0004YL-7k (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Mon, 11 Mar 2013 13:48:49 +0000 Message-ID: <513DE0B9.5020005@cam.ac.uk> Date: Mon, 11 Mar 2013 13:48:41 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <5138E4E6.9080001@cam.ac.uk> In-Reply-To: Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============1826829167526069351==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============1826829167526069351== Content-Type: multipart/alternative; boundary="------------050705000505090107040109" This is a multi-part message in MIME format. --------------050705000505090107040109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit First of all, thank you for the suggestions. I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems. For 13.1 I never get anywhere close as per my previous messages. For 12.3 and 12.8 I at least get a BSOD, ####################################################################### A problem has been detected ... Attempt to reset the display driver and recover from timeout failed. If this is ... Techinal information: *** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) *** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca ####################################################################### Does anybody have any further ideas? Matt On 07/03/2013 21:42, John Sherwood wrote: > (and I should probably mention that it has been my experience that > that is the expected and correct behavior) > > On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood > wrote: > > Having the windows logo freeze in the VNC window has been my > experience with GPU passthrough as well. > > > On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck > > wrote: > > Hi, > > I believe that the Windows logo freezing in the vnc window is > normal behaviour when secondary GPU passthrough is working as > it should, since the display should be handed over to the GPU. > At least that was the case before when I was passing through a > HD6850 card as secondary to win7 using xl. But you should > expect output on the GPU, of course. > > Have you tried different versions of the catalyst driver? I > think that some users have reported problems with the latest > one (13-something). > > Regards, > Andreas > > 2013/3/7 Matthew Dean > > > Hi all, > > I've managed to get a windows 7 x64 hvm to boot and > install and I'm now looking to pass through a HD 7970 as a > secondary GPU. in order to prepare the devices for > passthrough I've used > > xl pci-assignable-add 83:00.0 > xl pci-assignable-add 83:00.1 > > Where I've identified the device pci ids using lspci. > This works fine and the devices appear when I call 'xl > pci-assignable-list'. After adding them to the vm config > (see below) I was able to get the vm to boot and the > devices appeared in device manager. Installing the ATI > drivers however has meant that on further boots the > machine never gets past the windows logo in the VNC > window and no output is generated from the ATI card. It > simply freezes there and the only way I can get back into > windows is via safe mode, even after uninstalling the ATI > software. > > Has anybody else experienced similar issues or have any > advice as to how to get this to work? I'm a bit stumped > and the wiki implies that this should 'just work'. > > Thank you in advance for any help. > > Matt > > Here is my machine config > > ########################################################### > > builder='hvm' > memory = 2048 > name = 'Windows7Test' > > vcpus=4 > pae=1 > acpi=1 > apic=1 > > disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] > pci = [ '83:00.0' , '83:00.1' ] > > on_poweroff = 'destroy' > on_reboot = 'restart' > on_crash = 'destroy' > > boot='cd' > > sdl=0 > vnc=1 > vncconsole=0 > vncpasswd='' > vnclisten='172.24.226.84' > > stdvga=0 > > serial='pty' > usbdevice='tablet' > > gfx_passthru=0 > pci_power_mgmt=1 > xen_platform_pci=1 > pci_msitranslate=1 > viridian=1 > hpet=1 > > ############################################################ > > And the vm produces the following qemu log in /var/log/xen/ > > ############################################################ > > domid: 4 > -videoram option does not work with cirrus vga device > model. Videoram set to 4M. > Strip off blktap sub-type prefix to > /xen-guests/img/windows7Test.img (drv 'aio') > Using file /xen-guests/img/windows7Test.img in read-write mode > Watching /local/domain/0/device-model/4/logdirty/cmd > Watching /local/domain/0/device-model/4/command > Watching /local/domain/4/cpu > char device redirected to /dev/pts/3 > qemu_map_cache_init nr_buckets = 10000 size 4194304 > shared page at pfn feffd > buffered io page at pfn feffb > Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 > 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/4/xen_extended_power_mgmt): > read error > 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. > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: > 0, size: 0 > xs_read(/local/domain/4/log-throttling): read error > qemu: ignoring not-understood drive > `/local/domain/4/log-throttling' > medium change watch on `/local/domain/4/log-throttling' - > unknown device, ignored > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: > 0, size: 0 > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device > 83:00.0 ... > register_real_device: Enable MSI translation via per > device option > register_real_device: Enable power management > pt_iomul_init: Error: pt_iomul_init can't open file > /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 > pt_register_regions: IO region registered (size=0x10000000 > base_addr=0xe000000c) > pt_register_regions: IO region registered (size=0x00040000 > base_addr=0xf0000004) > pt_register_regions: IO region registered (size=0x00000100 > base_addr=0x0000f001) > pt_register_regions: Expansion ROM registered > (size=0x00020000 base_addr=0xf0040000) > pt_msi_setup: msi mapped with pirq 67 > pci_intx: intx=1 > register_real_device: Real physical device 83:00.0 > registered successfuly! > IRQ type = MSI-INTx > dm-command: hot insert pass-through pci dev > register_real_device: Assigning real physical device > 83:00.1 ... > register_real_device: Enable MSI translation via per > device option > register_real_device: Enable power management > pt_iomul_init: Error: pt_iomul_init can't open file > /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 > pt_register_regions: IO region registered (size=0x00004000 > base_addr=0xf0060004) > pt_msi_setup: msi mapped with pirq 66 > pci_intx: intx=2 > register_real_device: Real physical device 83:00.1 > registered successfuly! > IRQ type = MSI-INTx > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 > len=268435456 index=0 first_map=1 > cirrus vga map change while on lfb mode > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 > len=262144 index=2 first_map=1 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 > len=16384 index=0 first_map=1 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 > first_map=1 > 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. > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:04:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_pci_read_config: [00:05:0] Error: Failed to read > register with invalid access size alignment. > [Offset:0eh][Length:4] > pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 > len=268435456 index=0 first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 > len=262144 index=2 first_map=0 > pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 > first_map=0 > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 > len=268435456 index=0 first_map=0 > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 > len=262144 index=2 first_map=0 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 > first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 > len=16384 index=0 first_map=0 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 > len=16384 index=0 first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 > len=268435456 index=0 first_map=0 > pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 > len=262144 index=2 first_map=0 > pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 > first_map=0 > pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 > len=268435456 index=0 first_map=0 > pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 > len=262144 index=2 first_map=0 > pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 > first_map=0 > pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx > translation > pci_intx: intx=1 > pt_msi_disable: Unmap msi with pirq 67 > pt_msgctrl_reg_write: setup msi for dev 20 > pt_msi_setup: msi mapped with pirq 67 > pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f > pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 > len=16384 index=0 first_map=0 > pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 > len=16384 index=0 first_map=0 > > ###################################################################### > > _______________________________________________ > 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 > > > --------------050705000505090107040109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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



--------------050705000505090107040109-- --===============1826829167526069351== 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 --===============1826829167526069351==-- From xen-users-bounces@lists.xen.org Mon Mar 11 14:58:28 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 14:58: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 1UF4AH-0000UV-Oo; Mon, 11 Mar 2013 14:57:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF4AG-0000UN-6H for xen-users@lists.xen.org; Mon, 11 Mar 2013 14:57:24 +0000 Received: from [85.158.137.99:24139] by server-10.bemta-3.messagelabs.com id 59/70-19664-3D0FD315; Mon, 11 Mar 2013 14:57:23 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-3.tower-217.messagelabs.com!1363013841!12746991!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=2.7 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,HTML_40_50,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32405 invoked from network); 11 Mar 2013 14:57:21 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 14:57:21 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LjwWD-1Ulf1l2g3t-00bweS; Mon, 11 Mar 2013 15:57:20 +0100 Message-ID: <513DF0D0.1050907@brockmann-consult.de> Date: Mon, 11 Mar 2013 15:57:20 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Matthew Dean References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> In-Reply-To: <513DE0B9.5020005@cam.ac.uk> X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:LUQv9U/XVs+c7GPypYqE+cSQjbMCvQp67eKoBy+MKrZ OO1FXactBGxsDSrRXY88VJmy5qNIKviJC92yYCy8Wj51xoL4/0 hGC2RSIQzToRRqQ7hdIFagit91pwLfpdhzZ9j5Lj1D7hnkcMAp LMBUrrU2u/M8sVQgorq/A3+03TkHRkS6/OIEpaIHTylYpYSxmK 9Lpm+TuEUjWysKJ3e/rolQUe/uu0p+iJt2q3FKC86t9CZTtlc0 VCD4MMe4NQmowZIUjisYt6t489yZ79WHLMnJwBLEPv0O4qcWvj hj+Rvsem8cEY0E5lmXCmcPNWu0tXyY7edIYHOqK4T2udjBYIKn yamE7iT8WRY2umiTxnjE9z7mNXIDNHLR1mLF+lCKr Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============8921525429385634044==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============8921525429385634044== Content-Type: multipart/alternative; boundary="------------030905080701090607050404" This is a multi-part message in MIME format. --------------030905080701090607050404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly. Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen. On 2013-03-11 14:48, Matthew Dean wrote: > First of all, thank you for the suggestions. I've now re-installed > windows and I've tried driver versions 12.3, 12.8 and 13.1 all with > and without the CCC as I read in various places that it can cause > problems. For 13.1 I never get anywhere close as per my previous > messages. For 12.3 and 12.8 I at least get a BSOD, > > ####################################################################### > > A problem has been detected ... > > Attempt to reset the display driver and recover from timeout failed. > > If this is ... > > Techinal information: > > *** STOP: 0x00000116 > (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) > > *** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, > Datestamp 4f597fca > > ####################################################################### > > Does anybody have any further ideas? > > Matt > > On 07/03/2013 21:42, John Sherwood wrote: >> (and I should probably mention that it has been my experience that >> that is the expected and correct behavior) >> >> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood > > wrote: >> >> Having the windows logo freeze in the VNC window has been my >> experience with GPU passthrough as well. >> >> >> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >> > > wrote: >> >> Hi, >> >> I believe that the Windows logo freezing in the vnc window is >> normal behaviour when secondary GPU passthrough is working as >> it should, since the display should be handed over to the >> GPU. At least that was the case before when I was passing >> through a HD6850 card as secondary to win7 using xl. But you >> should expect output on the GPU, of course. >> >> Have you tried different versions of the catalyst driver? I >> think that some users have reported problems with the latest >> one (13-something). >> >> Regards, >> Andreas >> >> 2013/3/7 Matthew Dean > >> >> Hi all, >> >> I've managed to get a windows 7 x64 hvm to boot and >> install and I'm now looking to pass through a HD 7970 as >> a secondary GPU. in order to prepare the devices for >> passthrough I've used >> >> xl pci-assignable-add 83:00.0 >> xl pci-assignable-add 83:00.1 >> >> Where I've identified the device pci ids using lspci. >> This works fine and the devices appear when I call 'xl >> pci-assignable-list'. After adding them to the vm config >> (see below) I was able to get the vm to boot and the >> devices appeared in device manager. Installing the ATI >> drivers however has meant that on further boots the >> machine never gets past the windows logo in the VNC >> window and no output is generated from the ATI card. It >> simply freezes there and the only way I can get back into >> windows is via safe mode, even after uninstalling the ATI >> software. >> >> Has anybody else experienced similar issues or have any >> advice as to how to get this to work? I'm a bit stumped >> and the wiki implies that this should 'just work'. >> >> Thank you in advance for any help. >> >> Matt >> >> Here is my machine config >> >> ########################################################### >> >> builder='hvm' >> memory = 2048 >> name = 'Windows7Test' >> >> vcpus=4 >> pae=1 >> acpi=1 >> apic=1 >> >> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >> pci = [ '83:00.0' , '83:00.1' ] >> >> on_poweroff = 'destroy' >> on_reboot = 'restart' >> on_crash = 'destroy' >> >> boot='cd' >> >> sdl=0 >> vnc=1 >> vncconsole=0 >> vncpasswd='' >> vnclisten='172.24.226.84' >> >> stdvga=0 >> >> serial='pty' >> usbdevice='tablet' >> >> gfx_passthru=0 >> pci_power_mgmt=1 >> xen_platform_pci=1 >> pci_msitranslate=1 >> viridian=1 >> hpet=1 >> >> ############################################################ >> >> And the vm produces the following qemu log in /var/log/xen/ >> >> ############################################################ >> >> domid: 4 >> -videoram option does not work with cirrus vga device >> model. Videoram set to 4M. >> Strip off blktap sub-type prefix to >> /xen-guests/img/windows7Test.img (drv 'aio') >> Using file /xen-guests/img/windows7Test.img in read-write >> mode >> Watching /local/domain/0/device-model/4/logdirty/cmd >> Watching /local/domain/0/device-model/4/command >> Watching /local/domain/4/cpu >> char device redirected to /dev/pts/3 >> qemu_map_cache_init nr_buckets = 10000 size 4194304 >> shared page at pfn feffd >> buffered io page at pfn feffb >> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >> 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/4/xen_extended_power_mgmt): >> read error >> 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. >> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >> count: 0, size: 0 >> xs_read(/local/domain/4/log-throttling): read error >> qemu: ignoring not-understood drive >> `/local/domain/4/log-throttling' >> medium change watch on `/local/domain/4/log-throttling' - >> unknown device, ignored >> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >> count: 0, size: 0 >> dm-command: hot insert pass-through pci dev >> register_real_device: Assigning real physical device >> 83:00.0 ... >> register_real_device: Enable MSI translation via per >> device option >> register_real_device: Enable power management >> pt_iomul_init: Error: pt_iomul_init can't open file >> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 >> pt_register_regions: IO region registered >> (size=0x10000000 base_addr=0xe000000c) >> pt_register_regions: IO region registered >> (size=0x00040000 base_addr=0xf0000004) >> pt_register_regions: IO region registered >> (size=0x00000100 base_addr=0x0000f001) >> pt_register_regions: Expansion ROM registered >> (size=0x00020000 base_addr=0xf0040000) >> pt_msi_setup: msi mapped with pirq 67 >> pci_intx: intx=1 >> register_real_device: Real physical device 83:00.0 >> registered successfuly! >> IRQ type = MSI-INTx >> dm-command: hot insert pass-through pci dev >> register_real_device: Assigning real physical device >> 83:00.1 ... >> register_real_device: Enable MSI translation via per >> device option >> register_real_device: Enable power management >> pt_iomul_init: Error: pt_iomul_init can't open file >> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 >> pt_register_regions: IO region registered >> (size=0x00004000 base_addr=0xf0060004) >> pt_msi_setup: msi mapped with pirq 66 >> pci_intx: intx=2 >> register_real_device: Real physical device 83:00.1 >> registered successfuly! >> IRQ type = MSI-INTx >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >> len=268435456 index=0 first_map=1 >> cirrus vga map change while on lfb mode >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >> len=262144 index=2 first_map=1 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >> len=16384 index=0 first_map=1 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >> first_map=1 >> 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. >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >> len=268435456 index=0 first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >> len=262144 index=2 first_map=0 >> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 >> first_map=0 >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >> len=268435456 index=0 first_map=0 >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >> len=262144 index=2 first_map=0 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >> first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >> len=16384 index=0 first_map=0 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >> len=16384 index=0 first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >> len=268435456 index=0 first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >> len=262144 index=2 first_map=0 >> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 >> first_map=0 >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >> len=268435456 index=0 first_map=0 >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >> len=262144 index=2 first_map=0 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >> first_map=0 >> pt_msgctrl_reg_write: guest enabling MSI, disable >> MSI-INTx translation >> pci_intx: intx=1 >> pt_msi_disable: Unmap msi with pirq 67 >> pt_msgctrl_reg_write: setup msi for dev 20 >> pt_msi_setup: msi mapped with pirq 67 >> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >> len=16384 index=0 first_map=0 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >> len=16384 index=0 first_map=0 >> >> ###################################################################### >> >> _______________________________________________ >> 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 >> >> >> > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --------------030905080701090607050404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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





_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------
--------------030905080701090607050404-- --===============8921525429385634044== 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 --===============8921525429385634044==-- From xen-users-bounces@lists.xen.org Mon Mar 11 14:58:28 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 14:58: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 1UF4AH-0000UV-Oo; Mon, 11 Mar 2013 14:57:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF4AG-0000UN-6H for xen-users@lists.xen.org; Mon, 11 Mar 2013 14:57:24 +0000 Received: from [85.158.137.99:24139] by server-10.bemta-3.messagelabs.com id 59/70-19664-3D0FD315; Mon, 11 Mar 2013 14:57:23 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-3.tower-217.messagelabs.com!1363013841!12746991!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=2.7 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,HTML_40_50,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32405 invoked from network); 11 Mar 2013 14:57:21 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 14:57:21 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LjwWD-1Ulf1l2g3t-00bweS; Mon, 11 Mar 2013 15:57:20 +0100 Message-ID: <513DF0D0.1050907@brockmann-consult.de> Date: Mon, 11 Mar 2013 15:57:20 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Matthew Dean References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> In-Reply-To: <513DE0B9.5020005@cam.ac.uk> X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:LUQv9U/XVs+c7GPypYqE+cSQjbMCvQp67eKoBy+MKrZ OO1FXactBGxsDSrRXY88VJmy5qNIKviJC92yYCy8Wj51xoL4/0 hGC2RSIQzToRRqQ7hdIFagit91pwLfpdhzZ9j5Lj1D7hnkcMAp LMBUrrU2u/M8sVQgorq/A3+03TkHRkS6/OIEpaIHTylYpYSxmK 9Lpm+TuEUjWysKJ3e/rolQUe/uu0p+iJt2q3FKC86t9CZTtlc0 VCD4MMe4NQmowZIUjisYt6t489yZ79WHLMnJwBLEPv0O4qcWvj hj+Rvsem8cEY0E5lmXCmcPNWu0tXyY7edIYHOqK4T2udjBYIKn yamE7iT8WRY2umiTxnjE9z7mNXIDNHLR1mLF+lCKr Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============8921525429385634044==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============8921525429385634044== Content-Type: multipart/alternative; boundary="------------030905080701090607050404" This is a multi-part message in MIME format. --------------030905080701090607050404 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly. Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen. On 2013-03-11 14:48, Matthew Dean wrote: > First of all, thank you for the suggestions. I've now re-installed > windows and I've tried driver versions 12.3, 12.8 and 13.1 all with > and without the CCC as I read in various places that it can cause > problems. For 13.1 I never get anywhere close as per my previous > messages. For 12.3 and 12.8 I at least get a BSOD, > > ####################################################################### > > A problem has been detected ... > > Attempt to reset the display driver and recover from timeout failed. > > If this is ... > > Techinal information: > > *** STOP: 0x00000116 > (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) > > *** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, > Datestamp 4f597fca > > ####################################################################### > > Does anybody have any further ideas? > > Matt > > On 07/03/2013 21:42, John Sherwood wrote: >> (and I should probably mention that it has been my experience that >> that is the expected and correct behavior) >> >> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood > > wrote: >> >> Having the windows logo freeze in the VNC window has been my >> experience with GPU passthrough as well. >> >> >> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >> > > wrote: >> >> Hi, >> >> I believe that the Windows logo freezing in the vnc window is >> normal behaviour when secondary GPU passthrough is working as >> it should, since the display should be handed over to the >> GPU. At least that was the case before when I was passing >> through a HD6850 card as secondary to win7 using xl. But you >> should expect output on the GPU, of course. >> >> Have you tried different versions of the catalyst driver? I >> think that some users have reported problems with the latest >> one (13-something). >> >> Regards, >> Andreas >> >> 2013/3/7 Matthew Dean > >> >> Hi all, >> >> I've managed to get a windows 7 x64 hvm to boot and >> install and I'm now looking to pass through a HD 7970 as >> a secondary GPU. in order to prepare the devices for >> passthrough I've used >> >> xl pci-assignable-add 83:00.0 >> xl pci-assignable-add 83:00.1 >> >> Where I've identified the device pci ids using lspci. >> This works fine and the devices appear when I call 'xl >> pci-assignable-list'. After adding them to the vm config >> (see below) I was able to get the vm to boot and the >> devices appeared in device manager. Installing the ATI >> drivers however has meant that on further boots the >> machine never gets past the windows logo in the VNC >> window and no output is generated from the ATI card. It >> simply freezes there and the only way I can get back into >> windows is via safe mode, even after uninstalling the ATI >> software. >> >> Has anybody else experienced similar issues or have any >> advice as to how to get this to work? I'm a bit stumped >> and the wiki implies that this should 'just work'. >> >> Thank you in advance for any help. >> >> Matt >> >> Here is my machine config >> >> ########################################################### >> >> builder='hvm' >> memory = 2048 >> name = 'Windows7Test' >> >> vcpus=4 >> pae=1 >> acpi=1 >> apic=1 >> >> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >> pci = [ '83:00.0' , '83:00.1' ] >> >> on_poweroff = 'destroy' >> on_reboot = 'restart' >> on_crash = 'destroy' >> >> boot='cd' >> >> sdl=0 >> vnc=1 >> vncconsole=0 >> vncpasswd='' >> vnclisten='172.24.226.84' >> >> stdvga=0 >> >> serial='pty' >> usbdevice='tablet' >> >> gfx_passthru=0 >> pci_power_mgmt=1 >> xen_platform_pci=1 >> pci_msitranslate=1 >> viridian=1 >> hpet=1 >> >> ############################################################ >> >> And the vm produces the following qemu log in /var/log/xen/ >> >> ############################################################ >> >> domid: 4 >> -videoram option does not work with cirrus vga device >> model. Videoram set to 4M. >> Strip off blktap sub-type prefix to >> /xen-guests/img/windows7Test.img (drv 'aio') >> Using file /xen-guests/img/windows7Test.img in read-write >> mode >> Watching /local/domain/0/device-model/4/logdirty/cmd >> Watching /local/domain/0/device-model/4/command >> Watching /local/domain/4/cpu >> char device redirected to /dev/pts/3 >> qemu_map_cache_init nr_buckets = 10000 size 4194304 >> shared page at pfn feffd >> buffered io page at pfn feffb >> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >> 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/4/xen_extended_power_mgmt): >> read error >> 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. >> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >> count: 0, size: 0 >> xs_read(/local/domain/4/log-throttling): read error >> qemu: ignoring not-understood drive >> `/local/domain/4/log-throttling' >> medium change watch on `/local/domain/4/log-throttling' - >> unknown device, ignored >> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >> count: 0, size: 0 >> dm-command: hot insert pass-through pci dev >> register_real_device: Assigning real physical device >> 83:00.0 ... >> register_real_device: Enable MSI translation via per >> device option >> register_real_device: Enable power management >> pt_iomul_init: Error: pt_iomul_init can't open file >> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 >> pt_register_regions: IO region registered >> (size=0x10000000 base_addr=0xe000000c) >> pt_register_regions: IO region registered >> (size=0x00040000 base_addr=0xf0000004) >> pt_register_regions: IO region registered >> (size=0x00000100 base_addr=0x0000f001) >> pt_register_regions: Expansion ROM registered >> (size=0x00020000 base_addr=0xf0040000) >> pt_msi_setup: msi mapped with pirq 67 >> pci_intx: intx=1 >> register_real_device: Real physical device 83:00.0 >> registered successfuly! >> IRQ type = MSI-INTx >> dm-command: hot insert pass-through pci dev >> register_real_device: Assigning real physical device >> 83:00.1 ... >> register_real_device: Enable MSI translation via per >> device option >> register_real_device: Enable power management >> pt_iomul_init: Error: pt_iomul_init can't open file >> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 >> pt_register_regions: IO region registered >> (size=0x00004000 base_addr=0xf0060004) >> pt_msi_setup: msi mapped with pirq 66 >> pci_intx: intx=2 >> register_real_device: Real physical device 83:00.1 >> registered successfuly! >> IRQ type = MSI-INTx >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >> len=268435456 index=0 first_map=1 >> cirrus vga map change while on lfb mode >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >> len=262144 index=2 first_map=1 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >> len=16384 index=0 first_map=1 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >> first_map=1 >> 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. >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:04:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_pci_read_config: [00:05:0] Error: Failed to read >> register with invalid access size alignment. >> [Offset:0eh][Length:4] >> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >> len=268435456 index=0 first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >> len=262144 index=2 first_map=0 >> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 >> first_map=0 >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >> len=268435456 index=0 first_map=0 >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >> len=262144 index=2 first_map=0 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >> first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >> len=16384 index=0 first_map=0 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >> len=16384 index=0 first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >> len=268435456 index=0 first_map=0 >> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >> len=262144 index=2 first_map=0 >> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 >> first_map=0 >> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >> len=268435456 index=0 first_map=0 >> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >> len=262144 index=2 first_map=0 >> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >> first_map=0 >> pt_msgctrl_reg_write: guest enabling MSI, disable >> MSI-INTx translation >> pci_intx: intx=1 >> pt_msi_disable: Unmap msi with pirq 67 >> pt_msgctrl_reg_write: setup msi for dev 20 >> pt_msi_setup: msi mapped with pirq 67 >> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >> len=16384 index=0 first_map=0 >> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >> len=16384 index=0 first_map=0 >> >> ###################################################################### >> >> _______________________________________________ >> 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 >> >> >> > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --------------030905080701090607050404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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





_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------
--------------030905080701090607050404-- --===============8921525429385634044== 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 --===============8921525429385634044==-- From xen-users-bounces@lists.xen.org Mon Mar 11 15:23:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 15:23: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 1UF4Yp-0001We-Tm; Mon, 11 Mar 2013 15:22:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF4Yo-0001WX-BB for xen-users@lists.xen.org; Mon, 11 Mar 2013 15:22:46 +0000 Received: from [85.158.138.51:42671] by server-10.bemta-3.messagelabs.com id CA/1B-19664-5C6FD315; Mon, 11 Mar 2013 15:22:45 +0000 X-Env-Sender: skippyvondrake@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1363015356!23729124!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31660 invoked from network); 11 Mar 2013 15:22:37 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 15:22:37 -0000 Received: by mail-la0-f46.google.com with SMTP id fq12so4064785lab.19 for ; Mon, 11 Mar 2013 08:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=24ZLZudDz1lDTdt2IB8zPxdsbe4n038zbiymXWCTmr0=; b=FsD3xX/owxccgec3K//GkbPXTrFxH9RXHcCRDfqWEY2OLUkvl/VjnjOwIPM8PFJ4DS j7W7CsE4SLSsQLZU80NKoO6o8tBE7mdeRTyfQVNrZdqfIg9EQmkPKrYqMcckwjQtRmGa pgP3A70dDDIcWbg7T6Uk0J7SXYmVNosXX9JUy6rQBOM0uNDIhXhCuUO+/29cZ2+g39Nr 1apr1rqmeGGj8dyg/no0v8Y9JpZxUw3qqJhKqnz/uw5UluwPfxjnziLeWPomSHhrLrgf xAgLpRlFrKUzJl4UW7cuPXyw9BUFE3Woz6EIm58LMx5/FqEwBx+sEWYQ35f1fc1aeXcL /BcQ== MIME-Version: 1.0 X-Received: by 10.112.101.230 with SMTP id fj6mr218989lbb.115.1363015356618; Mon, 11 Mar 2013 08:22:36 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Mon, 11 Mar 2013 08:22:36 -0700 (PDT) Date: Mon, 11 Mar 2013 11:22:36 -0400 Message-ID: From: Skippy VonDrake To: xen-users@lists.xen.org Subject: [Xen-users] can't boot dom0 on Dell XPS 9100 X-BeenThere: xen-users@lists.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 Using Ubuntu-12.10 and tried Xen 4.2.1 and Ubuntu's Xen with same errors. Since Xen never boots successfully - there is no log message. So I captured the output with video and posted screenshots at http://skippyvondrake.com. Maybe it's a hardware issue. The motherboard has Intel chipset x58 (if that helps). The first message of interest: hda_intel: azx_get_response timeout Followed by stuff like "failed command: READ FPDMA QUEUED" And near the end: ni_cp: Failed to load firmware "radeon/TURKS_pfp.bin" disabling GPU acceleration -Skippy _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 11 15:23:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 15:23: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 1UF4Yp-0001We-Tm; Mon, 11 Mar 2013 15:22:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF4Yo-0001WX-BB for xen-users@lists.xen.org; Mon, 11 Mar 2013 15:22:46 +0000 Received: from [85.158.138.51:42671] by server-10.bemta-3.messagelabs.com id CA/1B-19664-5C6FD315; Mon, 11 Mar 2013 15:22:45 +0000 X-Env-Sender: skippyvondrake@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1363015356!23729124!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31660 invoked from network); 11 Mar 2013 15:22:37 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 15:22:37 -0000 Received: by mail-la0-f46.google.com with SMTP id fq12so4064785lab.19 for ; Mon, 11 Mar 2013 08:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=24ZLZudDz1lDTdt2IB8zPxdsbe4n038zbiymXWCTmr0=; b=FsD3xX/owxccgec3K//GkbPXTrFxH9RXHcCRDfqWEY2OLUkvl/VjnjOwIPM8PFJ4DS j7W7CsE4SLSsQLZU80NKoO6o8tBE7mdeRTyfQVNrZdqfIg9EQmkPKrYqMcckwjQtRmGa pgP3A70dDDIcWbg7T6Uk0J7SXYmVNosXX9JUy6rQBOM0uNDIhXhCuUO+/29cZ2+g39Nr 1apr1rqmeGGj8dyg/no0v8Y9JpZxUw3qqJhKqnz/uw5UluwPfxjnziLeWPomSHhrLrgf xAgLpRlFrKUzJl4UW7cuPXyw9BUFE3Woz6EIm58LMx5/FqEwBx+sEWYQ35f1fc1aeXcL /BcQ== MIME-Version: 1.0 X-Received: by 10.112.101.230 with SMTP id fj6mr218989lbb.115.1363015356618; Mon, 11 Mar 2013 08:22:36 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Mon, 11 Mar 2013 08:22:36 -0700 (PDT) Date: Mon, 11 Mar 2013 11:22:36 -0400 Message-ID: From: Skippy VonDrake To: xen-users@lists.xen.org Subject: [Xen-users] can't boot dom0 on Dell XPS 9100 X-BeenThere: xen-users@lists.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 Using Ubuntu-12.10 and tried Xen 4.2.1 and Ubuntu's Xen with same errors. Since Xen never boots successfully - there is no log message. So I captured the output with video and posted screenshots at http://skippyvondrake.com. Maybe it's a hardware issue. The motherboard has Intel chipset x58 (if that helps). The first message of interest: hda_intel: azx_get_response timeout Followed by stuff like "failed command: READ FPDMA QUEUED" And near the end: ni_cp: Failed to load firmware "radeon/TURKS_pfp.bin" disabling GPU acceleration -Skippy _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 11 15:26:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 15:26: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 1UF4bc-0001fQ-NS; Mon, 11 Mar 2013 15:25:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF4ba-0001fH-On for xen-users@lists.xen.org; Mon, 11 Mar 2013 15:25:38 +0000 Received: from [85.158.138.51:38945] by server-11.bemta-3.messagelabs.com id 1F/26-01263-D67FD315; Mon, 11 Mar 2013 15:25:33 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1363015515!23593856!1 X-Originating-IP: [209.85.210.179] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9545 invoked from network); 11 Mar 2013 15:25:16 -0000 Received: from mail-ia0-f179.google.com (HELO mail-ia0-f179.google.com) (209.85.210.179) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 15:25:16 -0000 Received: by mail-ia0-f179.google.com with SMTP id x24so3724328iak.24 for ; Mon, 11 Mar 2013 08:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=Jb3zQjuFdK7lYsDCJ3WuXT/NKT9UPBmKlmItWh7i5y0=; b=TufL52UqcWGWNVK6mfvTHt7pyXqqfNvzACGJFpPzVAr+xICczwBOcPeNmFhj/c/jCK viqqJ2IBWi/52lpTzcYzQyn5h8GsncTmSKaNQ9mz3YixK5ZepO23bXYy+qfRt6jXbhfj B4fY6nYUY5z/YPvuBmwUyCM5Jz/oUKjdKqYBlz37gZhxBwI2KRIJhPmF8i8Q6nM5p4Ni RW9lguS8cqmPb7ymy2L40GNxIRDqnOaJ1Wxv81lBU3wQj5T3tzQAtfnKWq1n4uIN4b0q 9oafdrI2GTu3+7BGWI4K0I/wVikExl0e+A6AmAbRuyxuzaV75aDUmYZyYcAE0Rw/a/Pz TASQ== MIME-Version: 1.0 X-Received: by 10.42.91.209 with SMTP id q17mr8970711icm.50.1363015514872; Mon, 11 Mar 2013 08:25:14 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 11 Mar 2013 08:25:14 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 11 Mar 2013 08:25:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Mar 2013 09:25:14 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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="===============2800260644699300878==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2800260644699300878== Content-Type: multipart/alternative; boundary=90e6ba5bbe1396634404d7a7c720 --90e6ba5bbe1396634404d7a7c720 Content-Type: text/plain; charset=ISO-8859-1 What is the best open sourced free tool that will synchronize local lvms to iscsi and allow fail over to iscsi targets. --90e6ba5bbe1396634404d7a7c720 Content-Type: text/html; charset=ISO-8859-1

What is the best open sourced free tool that will synchronize local lvms to iscsi and allow fail over to iscsi targets.

--90e6ba5bbe1396634404d7a7c720-- --===============2800260644699300878== 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 --===============2800260644699300878==-- From xen-users-bounces@lists.xen.org Mon Mar 11 15:26:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 15:26: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 1UF4bc-0001fQ-NS; Mon, 11 Mar 2013 15:25:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF4ba-0001fH-On for xen-users@lists.xen.org; Mon, 11 Mar 2013 15:25:38 +0000 Received: from [85.158.138.51:38945] by server-11.bemta-3.messagelabs.com id 1F/26-01263-D67FD315; Mon, 11 Mar 2013 15:25:33 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-14.tower-174.messagelabs.com!1363015515!23593856!1 X-Originating-IP: [209.85.210.179] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9545 invoked from network); 11 Mar 2013 15:25:16 -0000 Received: from mail-ia0-f179.google.com (HELO mail-ia0-f179.google.com) (209.85.210.179) by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 15:25:16 -0000 Received: by mail-ia0-f179.google.com with SMTP id x24so3724328iak.24 for ; Mon, 11 Mar 2013 08:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=Jb3zQjuFdK7lYsDCJ3WuXT/NKT9UPBmKlmItWh7i5y0=; b=TufL52UqcWGWNVK6mfvTHt7pyXqqfNvzACGJFpPzVAr+xICczwBOcPeNmFhj/c/jCK viqqJ2IBWi/52lpTzcYzQyn5h8GsncTmSKaNQ9mz3YixK5ZepO23bXYy+qfRt6jXbhfj B4fY6nYUY5z/YPvuBmwUyCM5Jz/oUKjdKqYBlz37gZhxBwI2KRIJhPmF8i8Q6nM5p4Ni RW9lguS8cqmPb7ymy2L40GNxIRDqnOaJ1Wxv81lBU3wQj5T3tzQAtfnKWq1n4uIN4b0q 9oafdrI2GTu3+7BGWI4K0I/wVikExl0e+A6AmAbRuyxuzaV75aDUmYZyYcAE0Rw/a/Pz TASQ== MIME-Version: 1.0 X-Received: by 10.42.91.209 with SMTP id q17mr8970711icm.50.1363015514872; Mon, 11 Mar 2013 08:25:14 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 11 Mar 2013 08:25:14 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 11 Mar 2013 08:25:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Mar 2013 09:25:14 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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="===============2800260644699300878==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2800260644699300878== Content-Type: multipart/alternative; boundary=90e6ba5bbe1396634404d7a7c720 --90e6ba5bbe1396634404d7a7c720 Content-Type: text/plain; charset=ISO-8859-1 What is the best open sourced free tool that will synchronize local lvms to iscsi and allow fail over to iscsi targets. --90e6ba5bbe1396634404d7a7c720 Content-Type: text/html; charset=ISO-8859-1

What is the best open sourced free tool that will synchronize local lvms to iscsi and allow fail over to iscsi targets.

--90e6ba5bbe1396634404d7a7c720-- --===============2800260644699300878== 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 --===============2800260644699300878==-- From xen-users-bounces@lists.xen.org Mon Mar 11 17:47:29 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 17:47: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 1UF6nT-0004qz-AD; Mon, 11 Mar 2013 17:46:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF6nQ-0004qu-0Z for xen-users@lists.xen.org; Mon, 11 Mar 2013 17:46:00 +0000 Received: from [193.109.254.147:29872] by server-15.bemta-14.messagelabs.com id AB/E8-14305-7581E315; Mon, 11 Mar 2013 17:45:59 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-12.tower-27.messagelabs.com!1363023958!8830340!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9978 invoked from network); 11 Mar 2013 17:45:58 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-12.tower-27.messagelabs.com with SMTP; 11 Mar 2013 17:45:58 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:61035) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UF6nN-000898-7o (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Mon, 11 Mar 2013 17:45:57 +0000 Message-ID: <513E184C.4000007@cam.ac.uk> Date: Mon, 11 Mar 2013 17:45:48 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> In-Reply-To: <513DF0D0.1050907@brockmann-consult.de> Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============5427921877716911395==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5427921877716911395== Content-Type: multipart/alternative; boundary="------------070007070200040102070906" This is a multi-part message in MIME format. --------------070007070200040102070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit That was a good suggestion, I've just tried passing through a USB controller and that worked fine. The driver installed correctly and I can use devices attached to the relevant ports. The problem therefore seems to be to do with gpu passthrough specifically. I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem. The system is Asus Z9PE-D8 WS motherboard (chipset is intel C602) Dual Xeon 2620 64 GB non-ecc memory Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through) In the bios I have vt-d enabled. I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default. I've tried all combinations of these enabled and disabled. If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread . If the problem is to no with these options then I think I have a problem. Has anybody got any thoughts? Matt On 11/03/2013 14:57, Peter Maloney wrote: > Did you try other devices, such as your onboard sound card, your > onboard USB controllers, etc.? Maybe your board doesn't do passthrough > properly. > > Or did you try another PCIe port for the card? Maybe there are bugs > where the addresses overlap with some other device, but in another > slot it wouldn't happen. > > > On 2013-03-11 14:48, Matthew Dean wrote: >> First of all, thank you for the suggestions. I've now re-installed >> windows and I've tried driver versions 12.3, 12.8 and 13.1 all with >> and without the CCC as I read in various places that it can cause >> problems. For 13.1 I never get anywhere close as per my previous >> messages. For 12.3 and 12.8 I at least get a BSOD, >> >> ####################################################################### >> >> A problem has been detected ... >> >> Attempt to reset the display driver and recover from timeout failed. >> >> If this is ... >> >> Techinal information: >> >> *** STOP: 0x00000116 >> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >> >> *** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, >> Datestamp 4f597fca >> >> ####################################################################### >> >> Does anybody have any further ideas? >> >> Matt >> >> On 07/03/2013 21:42, John Sherwood wrote: >>> (and I should probably mention that it has been my experience that >>> that is the expected and correct behavior) >>> >>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >> > wrote: >>> >>> Having the windows logo freeze in the VNC window has been my >>> experience with GPU passthrough as well. >>> >>> >>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>> >> > wrote: >>> >>> Hi, >>> >>> I believe that the Windows logo freezing in the vnc window >>> is normal behaviour when secondary GPU passthrough is >>> working as it should, since the display should be handed >>> over to the GPU. At least that was the case before when I >>> was passing through a HD6850 card as secondary to win7 using >>> xl. But you should expect output on the GPU, of course. >>> >>> Have you tried different versions of the catalyst driver? I >>> think that some users have reported problems with the latest >>> one (13-something). >>> >>> Regards, >>> Andreas >>> >>> 2013/3/7 Matthew Dean > >>> >>> Hi all, >>> >>> I've managed to get a windows 7 x64 hvm to boot and >>> install and I'm now looking to pass through a HD 7970 as >>> a secondary GPU. in order to prepare the devices for >>> passthrough I've used >>> >>> xl pci-assignable-add 83:00.0 >>> xl pci-assignable-add 83:00.1 >>> >>> Where I've identified the device pci ids using lspci. >>> This works fine and the devices appear when I call 'xl >>> pci-assignable-list'. After adding them to the vm config >>> (see below) I was able to get the vm to boot and the >>> devices appeared in device manager. Installing the ATI >>> drivers however has meant that on further boots the >>> machine never gets past the windows logo in the VNC >>> window and no output is generated from the ATI card. It >>> simply freezes there and the only way I can get back >>> into windows is via safe mode, even after uninstalling >>> the ATI software. >>> >>> Has anybody else experienced similar issues or have any >>> advice as to how to get this to work? I'm a bit stumped >>> and the wiki implies that this should 'just work'. >>> >>> Thank you in advance for any help. >>> >>> Matt >>> >>> Here is my machine config >>> >>> ########################################################### >>> >>> builder='hvm' >>> memory = 2048 >>> name = 'Windows7Test' >>> >>> vcpus=4 >>> pae=1 >>> acpi=1 >>> apic=1 >>> >>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>> pci = [ '83:00.0' , '83:00.1' ] >>> >>> on_poweroff = 'destroy' >>> on_reboot = 'restart' >>> on_crash = 'destroy' >>> >>> boot='cd' >>> >>> sdl=0 >>> vnc=1 >>> vncconsole=0 >>> vncpasswd='' >>> vnclisten='172.24.226.84' >>> >>> stdvga=0 >>> >>> serial='pty' >>> usbdevice='tablet' >>> >>> gfx_passthru=0 >>> pci_power_mgmt=1 >>> xen_platform_pci=1 >>> pci_msitranslate=1 >>> viridian=1 >>> hpet=1 >>> >>> ############################################################ >>> >>> And the vm produces the following qemu log in /var/log/xen/ >>> >>> ############################################################ >>> >>> domid: 4 >>> -videoram option does not work with cirrus vga device >>> model. Videoram set to 4M. >>> Strip off blktap sub-type prefix to >>> /xen-guests/img/windows7Test.img (drv 'aio') >>> Using file /xen-guests/img/windows7Test.img in >>> read-write mode >>> Watching /local/domain/0/device-model/4/logdirty/cmd >>> Watching /local/domain/0/device-model/4/command >>> Watching /local/domain/4/cpu >>> char device redirected to /dev/pts/3 >>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>> shared page at pfn feffd >>> buffered io page at pfn feffb >>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>> 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/4/xen_extended_power_mgmt): >>> read error >>> 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. >>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>> count: 0, size: 0 >>> xs_read(/local/domain/4/log-throttling): read error >>> qemu: ignoring not-understood drive >>> `/local/domain/4/log-throttling' >>> medium change watch on `/local/domain/4/log-throttling' >>> - unknown device, ignored >>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>> count: 0, size: 0 >>> dm-command: hot insert pass-through pci dev >>> register_real_device: Assigning real physical device >>> 83:00.0 ... >>> register_real_device: Enable MSI translation via per >>> device option >>> register_real_device: Enable power management >>> pt_iomul_init: Error: pt_iomul_init can't open file >>> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 >>> pt_register_regions: IO region registered >>> (size=0x10000000 base_addr=0xe000000c) >>> pt_register_regions: IO region registered >>> (size=0x00040000 base_addr=0xf0000004) >>> pt_register_regions: IO region registered >>> (size=0x00000100 base_addr=0x0000f001) >>> pt_register_regions: Expansion ROM registered >>> (size=0x00020000 base_addr=0xf0040000) >>> pt_msi_setup: msi mapped with pirq 67 >>> pci_intx: intx=1 >>> register_real_device: Real physical device 83:00.0 >>> registered successfuly! >>> IRQ type = MSI-INTx >>> dm-command: hot insert pass-through pci dev >>> register_real_device: Assigning real physical device >>> 83:00.1 ... >>> register_real_device: Enable MSI translation via per >>> device option >>> register_real_device: Enable power management >>> pt_iomul_init: Error: pt_iomul_init can't open file >>> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 >>> pt_register_regions: IO region registered >>> (size=0x00004000 base_addr=0xf0060004) >>> pt_msi_setup: msi mapped with pirq 66 >>> pci_intx: intx=2 >>> register_real_device: Real physical device 83:00.1 >>> registered successfuly! >>> IRQ type = MSI-INTx >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=1 >>> cirrus vga map change while on lfb mode >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>> len=262144 index=2 first_map=1 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>> len=16384 index=0 first_map=1 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >>> first_map=1 >>> 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. >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>> len=262144 index=2 first_map=0 >>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 >>> first_map=0 >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=0 >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>> len=262144 index=2 first_map=0 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >>> first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>> len=16384 index=0 first_map=0 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>> len=16384 index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>> len=262144 index=2 first_map=0 >>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 >>> first_map=0 >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=0 >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>> len=262144 index=2 first_map=0 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >>> first_map=0 >>> pt_msgctrl_reg_write: guest enabling MSI, disable >>> MSI-INTx translation >>> pci_intx: intx=1 >>> pt_msi_disable: Unmap msi with pirq 67 >>> pt_msgctrl_reg_write: setup msi for dev 20 >>> pt_msi_setup: msi mapped with pirq 67 >>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>> len=16384 index=0 first_map=0 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>> len=16384 index=0 first_map=0 >>> >>> ###################################################################### >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >> >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str. 2 > 21502 Geesthacht > Germany > Tel: +49 4152 889 300 > Fax: +49 4152 889 333 > E-mail:peter.maloney@brockmann-consult.de > Internet:http://www.brockmann-consult.de > -------------------------------------------- --------------070007070200040102070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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





_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------

--------------070007070200040102070906-- --===============5427921877716911395== 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 --===============5427921877716911395==-- From xen-users-bounces@lists.xen.org Mon Mar 11 17:47:29 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 17:47: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 1UF6nT-0004qz-AD; Mon, 11 Mar 2013 17:46:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF6nQ-0004qu-0Z for xen-users@lists.xen.org; Mon, 11 Mar 2013 17:46:00 +0000 Received: from [193.109.254.147:29872] by server-15.bemta-14.messagelabs.com id AB/E8-14305-7581E315; Mon, 11 Mar 2013 17:45:59 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-12.tower-27.messagelabs.com!1363023958!8830340!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9978 invoked from network); 11 Mar 2013 17:45:58 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-12.tower-27.messagelabs.com with SMTP; 11 Mar 2013 17:45:58 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:61035) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UF6nN-000898-7o (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Mon, 11 Mar 2013 17:45:57 +0000 Message-ID: <513E184C.4000007@cam.ac.uk> Date: Mon, 11 Mar 2013 17:45:48 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> In-Reply-To: <513DF0D0.1050907@brockmann-consult.de> Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============5427921877716911395==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5427921877716911395== Content-Type: multipart/alternative; boundary="------------070007070200040102070906" This is a multi-part message in MIME format. --------------070007070200040102070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit That was a good suggestion, I've just tried passing through a USB controller and that worked fine. The driver installed correctly and I can use devices attached to the relevant ports. The problem therefore seems to be to do with gpu passthrough specifically. I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem. The system is Asus Z9PE-D8 WS motherboard (chipset is intel C602) Dual Xeon 2620 64 GB non-ecc memory Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through) In the bios I have vt-d enabled. I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default. I've tried all combinations of these enabled and disabled. If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread . If the problem is to no with these options then I think I have a problem. Has anybody got any thoughts? Matt On 11/03/2013 14:57, Peter Maloney wrote: > Did you try other devices, such as your onboard sound card, your > onboard USB controllers, etc.? Maybe your board doesn't do passthrough > properly. > > Or did you try another PCIe port for the card? Maybe there are bugs > where the addresses overlap with some other device, but in another > slot it wouldn't happen. > > > On 2013-03-11 14:48, Matthew Dean wrote: >> First of all, thank you for the suggestions. I've now re-installed >> windows and I've tried driver versions 12.3, 12.8 and 13.1 all with >> and without the CCC as I read in various places that it can cause >> problems. For 13.1 I never get anywhere close as per my previous >> messages. For 12.3 and 12.8 I at least get a BSOD, >> >> ####################################################################### >> >> A problem has been detected ... >> >> Attempt to reset the display driver and recover from timeout failed. >> >> If this is ... >> >> Techinal information: >> >> *** STOP: 0x00000116 >> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >> >> *** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, >> Datestamp 4f597fca >> >> ####################################################################### >> >> Does anybody have any further ideas? >> >> Matt >> >> On 07/03/2013 21:42, John Sherwood wrote: >>> (and I should probably mention that it has been my experience that >>> that is the expected and correct behavior) >>> >>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >> > wrote: >>> >>> Having the windows logo freeze in the VNC window has been my >>> experience with GPU passthrough as well. >>> >>> >>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>> >> > wrote: >>> >>> Hi, >>> >>> I believe that the Windows logo freezing in the vnc window >>> is normal behaviour when secondary GPU passthrough is >>> working as it should, since the display should be handed >>> over to the GPU. At least that was the case before when I >>> was passing through a HD6850 card as secondary to win7 using >>> xl. But you should expect output on the GPU, of course. >>> >>> Have you tried different versions of the catalyst driver? I >>> think that some users have reported problems with the latest >>> one (13-something). >>> >>> Regards, >>> Andreas >>> >>> 2013/3/7 Matthew Dean > >>> >>> Hi all, >>> >>> I've managed to get a windows 7 x64 hvm to boot and >>> install and I'm now looking to pass through a HD 7970 as >>> a secondary GPU. in order to prepare the devices for >>> passthrough I've used >>> >>> xl pci-assignable-add 83:00.0 >>> xl pci-assignable-add 83:00.1 >>> >>> Where I've identified the device pci ids using lspci. >>> This works fine and the devices appear when I call 'xl >>> pci-assignable-list'. After adding them to the vm config >>> (see below) I was able to get the vm to boot and the >>> devices appeared in device manager. Installing the ATI >>> drivers however has meant that on further boots the >>> machine never gets past the windows logo in the VNC >>> window and no output is generated from the ATI card. It >>> simply freezes there and the only way I can get back >>> into windows is via safe mode, even after uninstalling >>> the ATI software. >>> >>> Has anybody else experienced similar issues or have any >>> advice as to how to get this to work? I'm a bit stumped >>> and the wiki implies that this should 'just work'. >>> >>> Thank you in advance for any help. >>> >>> Matt >>> >>> Here is my machine config >>> >>> ########################################################### >>> >>> builder='hvm' >>> memory = 2048 >>> name = 'Windows7Test' >>> >>> vcpus=4 >>> pae=1 >>> acpi=1 >>> apic=1 >>> >>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>> pci = [ '83:00.0' , '83:00.1' ] >>> >>> on_poweroff = 'destroy' >>> on_reboot = 'restart' >>> on_crash = 'destroy' >>> >>> boot='cd' >>> >>> sdl=0 >>> vnc=1 >>> vncconsole=0 >>> vncpasswd='' >>> vnclisten='172.24.226.84' >>> >>> stdvga=0 >>> >>> serial='pty' >>> usbdevice='tablet' >>> >>> gfx_passthru=0 >>> pci_power_mgmt=1 >>> xen_platform_pci=1 >>> pci_msitranslate=1 >>> viridian=1 >>> hpet=1 >>> >>> ############################################################ >>> >>> And the vm produces the following qemu log in /var/log/xen/ >>> >>> ############################################################ >>> >>> domid: 4 >>> -videoram option does not work with cirrus vga device >>> model. Videoram set to 4M. >>> Strip off blktap sub-type prefix to >>> /xen-guests/img/windows7Test.img (drv 'aio') >>> Using file /xen-guests/img/windows7Test.img in >>> read-write mode >>> Watching /local/domain/0/device-model/4/logdirty/cmd >>> Watching /local/domain/0/device-model/4/command >>> Watching /local/domain/4/cpu >>> char device redirected to /dev/pts/3 >>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>> shared page at pfn feffd >>> buffered io page at pfn feffb >>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>> 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/4/xen_extended_power_mgmt): >>> read error >>> 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. >>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>> count: 0, size: 0 >>> xs_read(/local/domain/4/log-throttling): read error >>> qemu: ignoring not-understood drive >>> `/local/domain/4/log-throttling' >>> medium change watch on `/local/domain/4/log-throttling' >>> - unknown device, ignored >>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>> count: 0, size: 0 >>> dm-command: hot insert pass-through pci dev >>> register_real_device: Assigning real physical device >>> 83:00.0 ... >>> register_real_device: Enable MSI translation via per >>> device option >>> register_real_device: Enable power management >>> pt_iomul_init: Error: pt_iomul_init can't open file >>> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 >>> pt_register_regions: IO region registered >>> (size=0x10000000 base_addr=0xe000000c) >>> pt_register_regions: IO region registered >>> (size=0x00040000 base_addr=0xf0000004) >>> pt_register_regions: IO region registered >>> (size=0x00000100 base_addr=0x0000f001) >>> pt_register_regions: Expansion ROM registered >>> (size=0x00020000 base_addr=0xf0040000) >>> pt_msi_setup: msi mapped with pirq 67 >>> pci_intx: intx=1 >>> register_real_device: Real physical device 83:00.0 >>> registered successfuly! >>> IRQ type = MSI-INTx >>> dm-command: hot insert pass-through pci dev >>> register_real_device: Assigning real physical device >>> 83:00.1 ... >>> register_real_device: Enable MSI translation via per >>> device option >>> register_real_device: Enable power management >>> pt_iomul_init: Error: pt_iomul_init can't open file >>> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 >>> pt_register_regions: IO region registered >>> (size=0x00004000 base_addr=0xf0060004) >>> pt_msi_setup: msi mapped with pirq 66 >>> pci_intx: intx=2 >>> register_real_device: Real physical device 83:00.1 >>> registered successfuly! >>> IRQ type = MSI-INTx >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=1 >>> cirrus vga map change while on lfb mode >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>> len=262144 index=2 first_map=1 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>> len=16384 index=0 first_map=1 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >>> first_map=1 >>> 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. >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:04:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_pci_read_config: [00:05:0] Error: Failed to read >>> register with invalid access size alignment. >>> [Offset:0eh][Length:4] >>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>> len=262144 index=2 first_map=0 >>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 >>> first_map=0 >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=0 >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>> len=262144 index=2 first_map=0 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >>> first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>> len=16384 index=0 first_map=0 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>> len=16384 index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=0 >>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>> len=262144 index=2 first_map=0 >>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 >>> first_map=0 >>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>> len=268435456 index=0 first_map=0 >>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>> len=262144 index=2 first_map=0 >>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 >>> first_map=0 >>> pt_msgctrl_reg_write: guest enabling MSI, disable >>> MSI-INTx translation >>> pci_intx: intx=1 >>> pt_msi_disable: Unmap msi with pirq 67 >>> pt_msgctrl_reg_write: setup msi for dev 20 >>> pt_msi_setup: msi mapped with pirq 67 >>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>> len=16384 index=0 first_map=0 >>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>> len=16384 index=0 first_map=0 >>> >>> ###################################################################### >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >> >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str. 2 > 21502 Geesthacht > Germany > Tel: +49 4152 889 300 > Fax: +49 4152 889 333 > E-mail:peter.maloney@brockmann-consult.de > Internet:http://www.brockmann-consult.de > -------------------------------------------- --------------070007070200040102070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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





_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------

--------------070007070200040102070906-- --===============5427921877716911395== 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 --===============5427921877716911395==-- From xen-users-bounces@lists.xen.org Mon Mar 11 18:18:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 18:18: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 1UF7HF-00062p-59; Mon, 11 Mar 2013 18:16:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF7HC-00062k-Ol for xen-users@lists.xen.org; Mon, 11 Mar 2013 18:16:47 +0000 Received: from [85.158.137.99:26877] by server-9.bemta-3.messagelabs.com id DB/84-32531-98F1E315; Mon, 11 Mar 2013 18:16:41 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-12.tower-217.messagelabs.com!1363025799!14686424!1 X-Originating-IP: [212.227.126.171] X-SpamReason: No, hits=0.4 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNTQ2MDU=\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNTQ2MDU=\n, HTML_50_60, HTML_MESSAGE, MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16445 invoked from network); 11 Mar 2013 18:16:39 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.126.171) by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 18:16:39 -0000 Received: from [192.168.179.201] (hmbg-4d06ba89.pool.mediaWays.net [77.6.186.137]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M3M80-1V67Qz3BqK-00qvft; Mon, 11 Mar 2013 19:16:38 +0100 Message-ID: <513E1F89.8040506@brockmann-consult.de> Date: Mon, 11 Mar 2013 19:16:41 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 MIME-Version: 1.0 To: Matthew Dean References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> In-Reply-To: <513E184C.4000007@cam.ac.uk> X-Provags-ID: V02:K0:eJrBmbIKT2OwKy7JzWr8q7LlHSwVBJ002SzgVtCxiPe 1thnZkxRVLkCzyCpAvU5pjOgfaZiAZ6f0qLYCsnKRImKjtRLdW /bQySDvy/bN+WTnsX+Jf1vRGECNUjzJwyPqjazW0eraT+SLN2s MF9XMODJp5xhVWpVmrPxT7h0bhku51kRIf41lfo9khfWzIotDG exSlO9kaB5LPvWJX1k32GZmflJCYb2+GhP7YVOSv3YIIB6Zdz9 27DGABrTi1/KHRlB6Y4UxDnIZgzRGevPCzIFHztiFYt4q767+X sUJpKMQsP+V1G9+3JFfZxJrlomnL2NQ/W9nH1Hkx1O7QqSovr6 LiBTcKZn+IHqI5W8cUBRluDgPLYp6M9euPfKIh/SEFegj3e6aX XGh9LW7LR1lpg== Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============2624911106646618367==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============2624911106646618367== Content-Type: multipart/alternative; boundary="------------090701040309050003030601" This is a multi-part message in MIME format. --------------090701040309050003030601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread) So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem. -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B) +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU) +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)] | \-00.1 Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE] +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB 3.0 Host Controller +-0a.0-[03]----00.0 Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series] | \-00.1 Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series] *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B) 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H) 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A) *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 On 03/11/2013 06:45 PM, Matthew Dean wrote: > That was a good suggestion, I've just tried passing through a USB > controller and that worked fine. The driver installed correctly and I > can use devices attached to the relevant ports. The problem therefore > seems to be to do with gpu passthrough specifically. I'm just going > to describe my system and some settings I have in the bios as this is > starting to feel like a system specific problem. The system is > > Asus Z9PE-D8 WS motherboard (chipset is intel C602) > Dual Xeon 2620 > 64 GB non-ecc memory > Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm > trying to pass through) > > In the bios I have vt-d enabled. I also have sub-feature settings for > "Coherency Support" and "ATS Support" which are disabled by default. > I've tried all combinations of these enabled and disabled. If I > enable "ATS Support" I do however have to add the option > "iommu=no-qinval,no-intremap" to the xen boot otherwise the system > hangs as per this thread > . > If the problem is to no with these options then I think I have a problem. > > Has anybody got any thoughts? > > Matt > > On 11/03/2013 14:57, Peter Maloney wrote: >> Did you try other devices, such as your onboard sound card, your >> onboard USB controllers, etc.? Maybe your board doesn't do >> passthrough properly. >> >> Or did you try another PCIe port for the card? Maybe there are bugs >> where the addresses overlap with some other device, but in another >> slot it wouldn't happen. >> >> >> On 2013-03-11 14:48, Matthew Dean wrote: >>> First of all, thank you for the suggestions. I've now re-installed >>> windows and I've tried driver versions 12.3, 12.8 and 13.1 all with >>> and without the CCC as I read in various places that it can cause >>> problems. For 13.1 I never get anywhere close as per my previous >>> messages. For 12.3 and 12.8 I at least get a BSOD, >>> >>> ####################################################################### >>> >>> A problem has been detected ... >>> >>> Attempt to reset the display driver and recover from timeout failed. >>> >>> If this is ... >>> >>> Techinal information: >>> >>> *** STOP: 0x00000116 >>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>> >>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>> FFFFF88003D8E000, Datestamp 4f597fca >>> >>> ####################################################################### >>> >>> Does anybody have any further ideas? >>> >>> Matt >>> >>> On 07/03/2013 21:42, John Sherwood wrote: >>>> (and I should probably mention that it has been my experience that >>>> that is the expected and correct behavior) >>>> >>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>> > wrote: >>>> >>>> Having the windows logo freeze in the VNC window has been my >>>> experience with GPU passthrough as well. >>>> >>>> >>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> I believe that the Windows logo freezing in the vnc window >>>> is normal behaviour when secondary GPU passthrough is >>>> working as it should, since the display should be handed >>>> over to the GPU. At least that was the case before when I >>>> was passing through a HD6850 card as secondary to win7 >>>> using xl. But you should expect output on the GPU, of course. >>>> >>>> Have you tried different versions of the catalyst driver? I >>>> think that some users have reported problems with the >>>> latest one (13-something). >>>> >>>> Regards, >>>> Andreas >>>> >>>> 2013/3/7 Matthew Dean >>> > >>>> >>>> Hi all, >>>> >>>> I've managed to get a windows 7 x64 hvm to boot and >>>> install and I'm now looking to pass through a HD 7970 >>>> as a secondary GPU. in order to prepare the devices >>>> for passthrough I've used >>>> >>>> xl pci-assignable-add 83:00.0 >>>> xl pci-assignable-add 83:00.1 >>>> >>>> Where I've identified the device pci ids using lspci. >>>> This works fine and the devices appear when I call 'xl >>>> pci-assignable-list'. After adding them to the vm >>>> config (see below) I was able to get the vm to boot and >>>> the devices appeared in device manager. Installing the >>>> ATI drivers however has meant that on further boots the >>>> machine never gets past the windows logo in the VNC >>>> window and no output is generated from the ATI card. >>>> It simply freezes there and the only way I can get >>>> back into windows is via safe mode, even after >>>> uninstalling the ATI software. >>>> >>>> Has anybody else experienced similar issues or have any >>>> advice as to how to get this to work? I'm a bit >>>> stumped and the wiki implies that this should 'just work'. >>>> >>>> Thank you in advance for any help. >>>> >>>> Matt >>>> >>>> Here is my machine config >>>> >>>> ########################################################### >>>> >>>> builder='hvm' >>>> memory = 2048 >>>> name = 'Windows7Test' >>>> >>>> vcpus=4 >>>> pae=1 >>>> acpi=1 >>>> apic=1 >>>> >>>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>> pci = [ '83:00.0' , '83:00.1' ] >>>> >>>> on_poweroff = 'destroy' >>>> on_reboot = 'restart' >>>> on_crash = 'destroy' >>>> >>>> boot='cd' >>>> >>>> sdl=0 >>>> vnc=1 >>>> vncconsole=0 >>>> vncpasswd='' >>>> vnclisten='172.24.226.84' >>>> >>>> stdvga=0 >>>> >>>> serial='pty' >>>> usbdevice='tablet' >>>> >>>> gfx_passthru=0 >>>> pci_power_mgmt=1 >>>> xen_platform_pci=1 >>>> pci_msitranslate=1 >>>> viridian=1 >>>> hpet=1 >>>> >>>> ############################################################ >>>> >>>> And the vm produces the following qemu log in /var/log/xen/ >>>> >>>> ############################################################ >>>> >>>> domid: 4 >>>> -videoram option does not work with cirrus vga device >>>> model. Videoram set to 4M. >>>> Strip off blktap sub-type prefix to >>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>> Using file /xen-guests/img/windows7Test.img in >>>> read-write mode >>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>> Watching /local/domain/0/device-model/4/command >>>> Watching /local/domain/4/cpu >>>> char device redirected to /dev/pts/3 >>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>> shared page at pfn feffd >>>> buffered io page at pfn feffb >>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>> 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/4/xen_extended_power_mgmt): >>>> read error >>>> 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. >>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>> count: 0, size: 0 >>>> xs_read(/local/domain/4/log-throttling): read error >>>> qemu: ignoring not-understood drive >>>> `/local/domain/4/log-throttling' >>>> medium change watch on `/local/domain/4/log-throttling' >>>> - unknown device, ignored >>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>> count: 0, size: 0 >>>> dm-command: hot insert pass-through pci dev >>>> register_real_device: Assigning real physical device >>>> 83:00.0 ... >>>> register_real_device: Enable MSI translation via per >>>> device option >>>> register_real_device: Enable power management >>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 >>>> pt_register_regions: IO region registered >>>> (size=0x10000000 base_addr=0xe000000c) >>>> pt_register_regions: IO region registered >>>> (size=0x00040000 base_addr=0xf0000004) >>>> pt_register_regions: IO region registered >>>> (size=0x00000100 base_addr=0x0000f001) >>>> pt_register_regions: Expansion ROM registered >>>> (size=0x00020000 base_addr=0xf0040000) >>>> pt_msi_setup: msi mapped with pirq 67 >>>> pci_intx: intx=1 >>>> register_real_device: Real physical device 83:00.0 >>>> registered successfuly! >>>> IRQ type = MSI-INTx >>>> dm-command: hot insert pass-through pci dev >>>> register_real_device: Assigning real physical device >>>> 83:00.1 ... >>>> register_real_device: Enable MSI translation via per >>>> device option >>>> register_real_device: Enable power management >>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 >>>> pt_register_regions: IO region registered >>>> (size=0x00004000 base_addr=0xf0060004) >>>> pt_msi_setup: msi mapped with pirq 66 >>>> pci_intx: intx=2 >>>> register_real_device: Real physical device 83:00.1 >>>> registered successfuly! >>>> IRQ type = MSI-INTx >>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=1 >>>> cirrus vga map change while on lfb mode >>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=1 >>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=1 >>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>> index=4 first_map=1 >>>> 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. >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=0 >>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=0 >>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>> index=4 first_map=0 >>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=0 >>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=0 >>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>> index=4 first_map=0 >>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=0 >>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=0 >>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=0 >>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=0 >>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>> index=4 first_map=0 >>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=0 >>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=0 >>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>> index=4 first_map=0 >>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>> MSI-INTx translation >>>> pci_intx: intx=1 >>>> pt_msi_disable: Unmap msi with pirq 67 >>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>> pt_msi_setup: msi mapped with pirq 67 >>>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=0 >>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=0 >>>> >>>> ###################################################################### >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xen.org >>> http://lists.xen.org/xen-users >> >> >> -- >> >> -------------------------------------------- >> Peter Maloney >> Brockmann Consult >> Max-Planck-Str. 2 >> 21502 Geesthacht >> Germany >> Tel: +49 4152 889 300 >> Fax: +49 4152 889 333 >> E-mail: peter.maloney@brockmann-consult.de >> Internet: http://www.brockmann-consult.de >> -------------------------------------------- > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --------------090701040309050003030601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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





_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------



_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

--------------090701040309050003030601-- --===============2624911106646618367== 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 --===============2624911106646618367==-- From xen-users-bounces@lists.xen.org Mon Mar 11 18:18:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 18:18: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 1UF7HF-00062p-59; Mon, 11 Mar 2013 18:16:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF7HC-00062k-Ol for xen-users@lists.xen.org; Mon, 11 Mar 2013 18:16:47 +0000 Received: from [85.158.137.99:26877] by server-9.bemta-3.messagelabs.com id DB/84-32531-98F1E315; Mon, 11 Mar 2013 18:16:41 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-12.tower-217.messagelabs.com!1363025799!14686424!1 X-Originating-IP: [212.227.126.171] X-SpamReason: No, hits=0.4 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNTQ2MDU=\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNTQ2MDU=\n, HTML_50_60, HTML_MESSAGE, MAILTO_TO_SPAM_ADDR X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16445 invoked from network); 11 Mar 2013 18:16:39 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.126.171) by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 18:16:39 -0000 Received: from [192.168.179.201] (hmbg-4d06ba89.pool.mediaWays.net [77.6.186.137]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M3M80-1V67Qz3BqK-00qvft; Mon, 11 Mar 2013 19:16:38 +0100 Message-ID: <513E1F89.8040506@brockmann-consult.de> Date: Mon, 11 Mar 2013 19:16:41 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 MIME-Version: 1.0 To: Matthew Dean References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> In-Reply-To: <513E184C.4000007@cam.ac.uk> X-Provags-ID: V02:K0:eJrBmbIKT2OwKy7JzWr8q7LlHSwVBJ002SzgVtCxiPe 1thnZkxRVLkCzyCpAvU5pjOgfaZiAZ6f0qLYCsnKRImKjtRLdW /bQySDvy/bN+WTnsX+Jf1vRGECNUjzJwyPqjazW0eraT+SLN2s MF9XMODJp5xhVWpVmrPxT7h0bhku51kRIf41lfo9khfWzIotDG exSlO9kaB5LPvWJX1k32GZmflJCYb2+GhP7YVOSv3YIIB6Zdz9 27DGABrTi1/KHRlB6Y4UxDnIZgzRGevPCzIFHztiFYt4q767+X sUJpKMQsP+V1G9+3JFfZxJrlomnL2NQ/W9nH1Hkx1O7QqSovr6 LiBTcKZn+IHqI5W8cUBRluDgPLYp6M9euPfKIh/SEFegj3e6aX XGh9LW7LR1lpg== Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============2624911106646618367==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============2624911106646618367== Content-Type: multipart/alternative; boundary="------------090701040309050003030601" This is a multi-part message in MIME format. --------------090701040309050003030601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread) So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem. -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B) +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU) +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)] | \-00.1 Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE] +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB 3.0 Host Controller +-0a.0-[03]----00.0 Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series] | \-00.1 Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series] *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B) 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H) 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A) *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 On 03/11/2013 06:45 PM, Matthew Dean wrote: > That was a good suggestion, I've just tried passing through a USB > controller and that worked fine. The driver installed correctly and I > can use devices attached to the relevant ports. The problem therefore > seems to be to do with gpu passthrough specifically. I'm just going > to describe my system and some settings I have in the bios as this is > starting to feel like a system specific problem. The system is > > Asus Z9PE-D8 WS motherboard (chipset is intel C602) > Dual Xeon 2620 > 64 GB non-ecc memory > Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm > trying to pass through) > > In the bios I have vt-d enabled. I also have sub-feature settings for > "Coherency Support" and "ATS Support" which are disabled by default. > I've tried all combinations of these enabled and disabled. If I > enable "ATS Support" I do however have to add the option > "iommu=no-qinval,no-intremap" to the xen boot otherwise the system > hangs as per this thread > . > If the problem is to no with these options then I think I have a problem. > > Has anybody got any thoughts? > > Matt > > On 11/03/2013 14:57, Peter Maloney wrote: >> Did you try other devices, such as your onboard sound card, your >> onboard USB controllers, etc.? Maybe your board doesn't do >> passthrough properly. >> >> Or did you try another PCIe port for the card? Maybe there are bugs >> where the addresses overlap with some other device, but in another >> slot it wouldn't happen. >> >> >> On 2013-03-11 14:48, Matthew Dean wrote: >>> First of all, thank you for the suggestions. I've now re-installed >>> windows and I've tried driver versions 12.3, 12.8 and 13.1 all with >>> and without the CCC as I read in various places that it can cause >>> problems. For 13.1 I never get anywhere close as per my previous >>> messages. For 12.3 and 12.8 I at least get a BSOD, >>> >>> ####################################################################### >>> >>> A problem has been detected ... >>> >>> Attempt to reset the display driver and recover from timeout failed. >>> >>> If this is ... >>> >>> Techinal information: >>> >>> *** STOP: 0x00000116 >>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>> >>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>> FFFFF88003D8E000, Datestamp 4f597fca >>> >>> ####################################################################### >>> >>> Does anybody have any further ideas? >>> >>> Matt >>> >>> On 07/03/2013 21:42, John Sherwood wrote: >>>> (and I should probably mention that it has been my experience that >>>> that is the expected and correct behavior) >>>> >>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>> > wrote: >>>> >>>> Having the windows logo freeze in the VNC window has been my >>>> experience with GPU passthrough as well. >>>> >>>> >>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> I believe that the Windows logo freezing in the vnc window >>>> is normal behaviour when secondary GPU passthrough is >>>> working as it should, since the display should be handed >>>> over to the GPU. At least that was the case before when I >>>> was passing through a HD6850 card as secondary to win7 >>>> using xl. But you should expect output on the GPU, of course. >>>> >>>> Have you tried different versions of the catalyst driver? I >>>> think that some users have reported problems with the >>>> latest one (13-something). >>>> >>>> Regards, >>>> Andreas >>>> >>>> 2013/3/7 Matthew Dean >>> > >>>> >>>> Hi all, >>>> >>>> I've managed to get a windows 7 x64 hvm to boot and >>>> install and I'm now looking to pass through a HD 7970 >>>> as a secondary GPU. in order to prepare the devices >>>> for passthrough I've used >>>> >>>> xl pci-assignable-add 83:00.0 >>>> xl pci-assignable-add 83:00.1 >>>> >>>> Where I've identified the device pci ids using lspci. >>>> This works fine and the devices appear when I call 'xl >>>> pci-assignable-list'. After adding them to the vm >>>> config (see below) I was able to get the vm to boot and >>>> the devices appeared in device manager. Installing the >>>> ATI drivers however has meant that on further boots the >>>> machine never gets past the windows logo in the VNC >>>> window and no output is generated from the ATI card. >>>> It simply freezes there and the only way I can get >>>> back into windows is via safe mode, even after >>>> uninstalling the ATI software. >>>> >>>> Has anybody else experienced similar issues or have any >>>> advice as to how to get this to work? I'm a bit >>>> stumped and the wiki implies that this should 'just work'. >>>> >>>> Thank you in advance for any help. >>>> >>>> Matt >>>> >>>> Here is my machine config >>>> >>>> ########################################################### >>>> >>>> builder='hvm' >>>> memory = 2048 >>>> name = 'Windows7Test' >>>> >>>> vcpus=4 >>>> pae=1 >>>> acpi=1 >>>> apic=1 >>>> >>>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>> pci = [ '83:00.0' , '83:00.1' ] >>>> >>>> on_poweroff = 'destroy' >>>> on_reboot = 'restart' >>>> on_crash = 'destroy' >>>> >>>> boot='cd' >>>> >>>> sdl=0 >>>> vnc=1 >>>> vncconsole=0 >>>> vncpasswd='' >>>> vnclisten='172.24.226.84' >>>> >>>> stdvga=0 >>>> >>>> serial='pty' >>>> usbdevice='tablet' >>>> >>>> gfx_passthru=0 >>>> pci_power_mgmt=1 >>>> xen_platform_pci=1 >>>> pci_msitranslate=1 >>>> viridian=1 >>>> hpet=1 >>>> >>>> ############################################################ >>>> >>>> And the vm produces the following qemu log in /var/log/xen/ >>>> >>>> ############################################################ >>>> >>>> domid: 4 >>>> -videoram option does not work with cirrus vga device >>>> model. Videoram set to 4M. >>>> Strip off blktap sub-type prefix to >>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>> Using file /xen-guests/img/windows7Test.img in >>>> read-write mode >>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>> Watching /local/domain/0/device-model/4/command >>>> Watching /local/domain/4/cpu >>>> char device redirected to /dev/pts/3 >>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>> shared page at pfn feffd >>>> buffered io page at pfn feffb >>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>> 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/4/xen_extended_power_mgmt): >>>> read error >>>> 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. >>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>> count: 0, size: 0 >>>> xs_read(/local/domain/4/log-throttling): read error >>>> qemu: ignoring not-understood drive >>>> `/local/domain/4/log-throttling' >>>> medium change watch on `/local/domain/4/log-throttling' >>>> - unknown device, ignored >>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>> count: 0, size: 0 >>>> dm-command: hot insert pass-through pci dev >>>> register_real_device: Assigning real physical device >>>> 83:00.0 ... >>>> register_real_device: Enable MSI translation via per >>>> device option >>>> register_real_device: Enable power management >>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0 >>>> pt_register_regions: IO region registered >>>> (size=0x10000000 base_addr=0xe000000c) >>>> pt_register_regions: IO region registered >>>> (size=0x00040000 base_addr=0xf0000004) >>>> pt_register_regions: IO region registered >>>> (size=0x00000100 base_addr=0x0000f001) >>>> pt_register_regions: Expansion ROM registered >>>> (size=0x00020000 base_addr=0xf0040000) >>>> pt_msi_setup: msi mapped with pirq 67 >>>> pci_intx: intx=1 >>>> register_real_device: Real physical device 83:00.0 >>>> registered successfuly! >>>> IRQ type = MSI-INTx >>>> dm-command: hot insert pass-through pci dev >>>> register_real_device: Assigning real physical device >>>> 83:00.1 ... >>>> register_real_device: Enable MSI translation via per >>>> device option >>>> register_real_device: Enable power management >>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>> /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1 >>>> pt_register_regions: IO region registered >>>> (size=0x00004000 base_addr=0xf0060004) >>>> pt_msi_setup: msi mapped with pirq 66 >>>> pci_intx: intx=2 >>>> register_real_device: Real physical device 83:00.1 >>>> registered successfuly! >>>> IRQ type = MSI-INTx >>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=1 >>>> cirrus vga map change while on lfb mode >>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=1 >>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=1 >>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>> index=4 first_map=1 >>>> 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. >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>> register with invalid access size alignment. >>>> [Offset:0eh][Length:4] >>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=0 >>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=0 >>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>> index=4 first_map=0 >>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=0 >>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=0 >>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>> index=4 first_map=0 >>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=0 >>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=0 >>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=0 >>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=0 >>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>> index=4 first_map=0 >>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>> len=268435456 index=0 first_map=0 >>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>> len=262144 index=2 first_map=0 >>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>> index=4 first_map=0 >>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>> MSI-INTx translation >>>> pci_intx: intx=1 >>>> pt_msi_disable: Unmap msi with pirq 67 >>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>> pt_msi_setup: msi mapped with pirq 67 >>>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=0 >>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>> len=16384 index=0 first_map=0 >>>> >>>> ###################################################################### >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xen.org >>> http://lists.xen.org/xen-users >> >> >> -- >> >> -------------------------------------------- >> Peter Maloney >> Brockmann Consult >> Max-Planck-Str. 2 >> 21502 Geesthacht >> Germany >> Tel: +49 4152 889 300 >> Fax: +49 4152 889 333 >> E-mail: peter.maloney@brockmann-consult.de >> Internet: http://www.brockmann-consult.de >> -------------------------------------------- > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --------------090701040309050003030601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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





_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------



_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

--------------090701040309050003030601-- --===============2624911106646618367== 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 --===============2624911106646618367==-- From xen-users-bounces@lists.xen.org Mon Mar 11 19:08:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 19:08: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 1UF83m-0006kE-7r; Mon, 11 Mar 2013 19:06:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF83k-0006k9-JD for xen-users@lists.xen.org; Mon, 11 Mar 2013 19:06:56 +0000 Received: from [85.158.137.99:17607] by server-10.bemta-3.messagelabs.com id 54/A4-19664-F4B2E315; Mon, 11 Mar 2013 19:06:55 +0000 X-Env-Sender: paul@stimpsonfamily.co.uk X-Msg-Ref: server-10.tower-217.messagelabs.com!1363028815!17844596!1 X-Originating-IP: [94.136.40.61] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n,sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7919 invoked from network); 11 Mar 2013 19:06:55 -0000 Received: from mailex.mailcore.me (HELO mailex.mailcore.me) (94.136.40.61) by server-10.tower-217.messagelabs.com with SMTP; 11 Mar 2013 19:06:55 -0000 Received: from [192.165.210.4] (helo=[192.168.225.223]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UF83i-0003b9-SY for xen-users@lists.xen.org; Mon, 11 Mar 2013 19:06:55 +0000 Message-ID: <513E2B4F.7030600@stimpsonfamily.co.uk> Date: Mon, 11 Mar 2013 19:06:55 +0000 From: Paul Stimpson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Mailcore-Auth: 8324857 X-Mailcore-Domain: 844183 Subject: [Xen-users] Windows QEMU resolution X-BeenThere: xen-users@lists.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, I have a Windows guest under XL with Xen 4.2.0 and I'm trying to increase the resolution of the VNC console. I added: extra = "xen-fbfront.video=32,1920,1200" to the config file and Windows now offers me a choice of 800x600 or 1024x768 as available screen resolutions rather than just 800x600 so something has happened. My initial thought was that I wasn't seeing the higher resolutions because I hadn't allocated enough memory to the video so I tried 64,1920,1200 and 256,1920,1200 but I still don't see anything better than 1024x768 available in Windows. What am I doing wrong please? Thanks, Paul. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 11 19:08:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 19:08: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 1UF83m-0006kE-7r; Mon, 11 Mar 2013 19:06:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF83k-0006k9-JD for xen-users@lists.xen.org; Mon, 11 Mar 2013 19:06:56 +0000 Received: from [85.158.137.99:17607] by server-10.bemta-3.messagelabs.com id 54/A4-19664-F4B2E315; Mon, 11 Mar 2013 19:06:55 +0000 X-Env-Sender: paul@stimpsonfamily.co.uk X-Msg-Ref: server-10.tower-217.messagelabs.com!1363028815!17844596!1 X-Originating-IP: [94.136.40.61] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n,sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7919 invoked from network); 11 Mar 2013 19:06:55 -0000 Received: from mailex.mailcore.me (HELO mailex.mailcore.me) (94.136.40.61) by server-10.tower-217.messagelabs.com with SMTP; 11 Mar 2013 19:06:55 -0000 Received: from [192.165.210.4] (helo=[192.168.225.223]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UF83i-0003b9-SY for xen-users@lists.xen.org; Mon, 11 Mar 2013 19:06:55 +0000 Message-ID: <513E2B4F.7030600@stimpsonfamily.co.uk> Date: Mon, 11 Mar 2013 19:06:55 +0000 From: Paul Stimpson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Mailcore-Auth: 8324857 X-Mailcore-Domain: 844183 Subject: [Xen-users] Windows QEMU resolution X-BeenThere: xen-users@lists.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, I have a Windows guest under XL with Xen 4.2.0 and I'm trying to increase the resolution of the VNC console. I added: extra = "xen-fbfront.video=32,1920,1200" to the config file and Windows now offers me a choice of 800x600 or 1024x768 as available screen resolutions rather than just 800x600 so something has happened. My initial thought was that I wasn't seeing the higher resolutions because I hadn't allocated enough memory to the video so I tried 64,1920,1200 and 256,1920,1200 but I still don't see anything better than 1024x768 available in Windows. What am I doing wrong please? Thanks, Paul. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 11 19:25:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 19: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 1UF8Kc-0007Et-Gv; Mon, 11 Mar 2013 19:24:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF8Kb-0007Eo-7F for xen-users@lists.xen.org; Mon, 11 Mar 2013 19:24:21 +0000 Received: from [85.158.143.99:2091] by server-3.bemta-4.messagelabs.com id A3/FA-02186-46F2E315; Mon, 11 Mar 2013 19:24:20 +0000 X-Env-Sender: ghudiczius@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1363029859!28003956!1 X-Originating-IP: [74.125.83.48] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7142 invoked from network); 11 Mar 2013 19:24:20 -0000 Received: from mail-ee0-f48.google.com (HELO mail-ee0-f48.google.com) (74.125.83.48) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 19:24:20 -0000 Received: by mail-ee0-f48.google.com with SMTP id t10so2436189eei.21 for ; Mon, 11 Mar 2013 12:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PUn1OvKalMER15nNI2w23zBYlSlyEZcvS7Fy4IJ5X5w=; b=cpdvOKbFmP257/r0ZFe8XPyoTELMpBdE7Tst81Ug5G5Cv1Y5jbKQmjLkDvAl3V7V7e BHdNV4SrFDnRMgOUOyEzaqOb+bXx2UlvBux/sPrFLKc346scXDarZvwKjVDk9t3Kp/I7 E+J3NNN3wNp8U4YRP/WqI1cgUhQR6XL3gwZRjdZYJ3pT71KN6Dsb4OoaDy1QN3CJMowg 7FFQVnFtCb6VanstciKlqLF4yL/fR+athY2+MoJOAVdRIxJTVRsbUx/1F4eoM/c2vbtN r41QyN5Ue970aHw3Q5vm+W3vOdogdKKPZj+pTnMSXSjCLWeK6qvqe/vR/K2J8ijwWTaq QTOw== X-Received: by 10.14.175.129 with SMTP id z1mr39826665eel.7.1363029859740; Mon, 11 Mar 2013 12:24:19 -0700 (PDT) Received: from ?IPv6:2a01:368:e10d::10? ([2a01:368:e10d::10]) by mx.google.com with ESMTPS id 3sm25351763eej.6.2013.03.11.12.24.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 12:24:18 -0700 (PDT) Message-ID: <513E2F5F.70502@gmail.com> Date: Mon, 11 Mar 2013 20:24:15 +0100 From: Gabor Hudiczius User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <513E2B4F.7030600@stimpsonfamily.co.uk> In-Reply-To: <513E2B4F.7030600@stimpsonfamily.co.uk> Subject: Re: [Xen-users] Windows QEMU resolution X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: ghudiczius@gmail.com 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, you need the following 2 lines in your xen config: stdvga = 1 videoram = 16 (or more, if you like) With these settings i can set the resolution even to 2560*1600. Regards, Gabor Hudiczius On 13.03.11. 20:06, Paul Stimpson wrote: > Hi, > > I have a Windows guest under XL with Xen 4.2.0 and I'm trying to > increase the resolution of the VNC console. > > I added: > > extra = "xen-fbfront.video=32,1920,1200" > > to the config file and Windows now offers me a choice of 800x600 or > 1024x768 as available screen resolutions rather than just 800x600 so > something has happened. My initial thought was that I wasn't seeing the > higher resolutions because I hadn't allocated enough memory to the video > so I tried 64,1920,1200 and 256,1920,1200 but I still don't see anything > better than 1024x768 available in Windows. > > What am I doing wrong please? > > Thanks, > Paul. > > > _______________________________________________ > 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 Mar 11 19:25:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 19: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 1UF8Kc-0007Et-Gv; Mon, 11 Mar 2013 19:24:22 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF8Kb-0007Eo-7F for xen-users@lists.xen.org; Mon, 11 Mar 2013 19:24:21 +0000 Received: from [85.158.143.99:2091] by server-3.bemta-4.messagelabs.com id A3/FA-02186-46F2E315; Mon, 11 Mar 2013 19:24:20 +0000 X-Env-Sender: ghudiczius@gmail.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1363029859!28003956!1 X-Originating-IP: [74.125.83.48] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7142 invoked from network); 11 Mar 2013 19:24:20 -0000 Received: from mail-ee0-f48.google.com (HELO mail-ee0-f48.google.com) (74.125.83.48) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 19:24:20 -0000 Received: by mail-ee0-f48.google.com with SMTP id t10so2436189eei.21 for ; Mon, 11 Mar 2013 12:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PUn1OvKalMER15nNI2w23zBYlSlyEZcvS7Fy4IJ5X5w=; b=cpdvOKbFmP257/r0ZFe8XPyoTELMpBdE7Tst81Ug5G5Cv1Y5jbKQmjLkDvAl3V7V7e BHdNV4SrFDnRMgOUOyEzaqOb+bXx2UlvBux/sPrFLKc346scXDarZvwKjVDk9t3Kp/I7 E+J3NNN3wNp8U4YRP/WqI1cgUhQR6XL3gwZRjdZYJ3pT71KN6Dsb4OoaDy1QN3CJMowg 7FFQVnFtCb6VanstciKlqLF4yL/fR+athY2+MoJOAVdRIxJTVRsbUx/1F4eoM/c2vbtN r41QyN5Ue970aHw3Q5vm+W3vOdogdKKPZj+pTnMSXSjCLWeK6qvqe/vR/K2J8ijwWTaq QTOw== X-Received: by 10.14.175.129 with SMTP id z1mr39826665eel.7.1363029859740; Mon, 11 Mar 2013 12:24:19 -0700 (PDT) Received: from ?IPv6:2a01:368:e10d::10? ([2a01:368:e10d::10]) by mx.google.com with ESMTPS id 3sm25351763eej.6.2013.03.11.12.24.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 12:24:18 -0700 (PDT) Message-ID: <513E2F5F.70502@gmail.com> Date: Mon, 11 Mar 2013 20:24:15 +0100 From: Gabor Hudiczius User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <513E2B4F.7030600@stimpsonfamily.co.uk> In-Reply-To: <513E2B4F.7030600@stimpsonfamily.co.uk> Subject: Re: [Xen-users] Windows QEMU resolution X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: ghudiczius@gmail.com 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, you need the following 2 lines in your xen config: stdvga = 1 videoram = 16 (or more, if you like) With these settings i can set the resolution even to 2560*1600. Regards, Gabor Hudiczius On 13.03.11. 20:06, Paul Stimpson wrote: > Hi, > > I have a Windows guest under XL with Xen 4.2.0 and I'm trying to > increase the resolution of the VNC console. > > I added: > > extra = "xen-fbfront.video=32,1920,1200" > > to the config file and Windows now offers me a choice of 800x600 or > 1024x768 as available screen resolutions rather than just 800x600 so > something has happened. My initial thought was that I wasn't seeing the > higher resolutions because I hadn't allocated enough memory to the video > so I tried 64,1920,1200 and 256,1920,1200 but I still don't see anything > better than 1024x768 available in Windows. > > What am I doing wrong please? > > Thanks, > Paul. > > > _______________________________________________ > 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 Mar 11 20:10:31 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 20:10: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 1UF92Q-0007o5-Ez; Mon, 11 Mar 2013 20:09:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF92O-0007o0-LJ for xen-users@lists.xen.org; Mon, 11 Mar 2013 20:09:36 +0000 Received: from [85.158.143.99:61201] by server-3.bemta-4.messagelabs.com id C4/BB-02186-FF93E315; Mon, 11 Mar 2013 20:09:35 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1363032574!22729501!1 X-Originating-IP: [209.85.223.182] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22231 invoked from network); 11 Mar 2013 20:09:35 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 20:09:35 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so5345654iea.27 for ; Mon, 11 Mar 2013 13:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=36D3w2y8Z3ZlPBodv4ptFNMO/oNmgdCeNk1p0UGPZHU=; b=V5P7uL/dztocXmukOJh5t9Qs+3izHLilDG+Ksas4mvAx9D5VDrMYlgRtxy3V/I6kP6 M6PHdGfC4dTh4YOLD6agZQF+GqInLheufLe/AeqgyZa05ROuZXW/BCasYckIL6sJZ74H iBW96GDn8RXxICcXWcqcBDZ8OF23F2Z3F1h2EMRgOV1PzByHKlwhqT6gJu+7ToB1NNcw xIRo5f4tWB4t0WrvC2ShVV/NAhfXfZ3xbZBOKCO3pNC4ndVsyJijsH9DIzxRMxm/aw/p 8iqQYulegoQaPHFA2pqGYai4zAUNohS4419A90BL3F7YkWcxP7szKSgV1jtcVZr7XHhN BmmA== MIME-Version: 1.0 X-Received: by 10.50.77.230 with SMTP id v6mr8934402igw.29.1363032514494; Mon, 11 Mar 2013 13:08:34 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 11 Mar 2013 13:08:34 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 11 Mar 2013 13:08:34 -0700 (PDT) Date: Mon, 11 Mar 2013 14:08:34 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] Seabios patch X-BeenThere: xen-users@lists.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="===============0466755595002421650==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0466755595002421650== Content-Type: multipart/alternative; boundary=e89a8f3ba87fd808e404d7abbcad --e89a8f3ba87fd808e404d7abbcad Content-Type: text/plain; charset=ISO-8859-1 I want to patch seabios . I hope someone can point me to Roth file to edit --e89a8f3ba87fd808e404d7abbcad Content-Type: text/html; charset=ISO-8859-1

I want to patch seabios . I hope someone can point me to Roth file to edit

--e89a8f3ba87fd808e404d7abbcad-- --===============0466755595002421650== 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 --===============0466755595002421650==-- From xen-users-bounces@lists.xen.org Mon Mar 11 20:10:31 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 20:10: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 1UF92Q-0007o5-Ez; Mon, 11 Mar 2013 20:09:38 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UF92O-0007o0-LJ for xen-users@lists.xen.org; Mon, 11 Mar 2013 20:09:36 +0000 Received: from [85.158.143.99:61201] by server-3.bemta-4.messagelabs.com id C4/BB-02186-FF93E315; Mon, 11 Mar 2013 20:09:35 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1363032574!22729501!1 X-Originating-IP: [209.85.223.182] X-SpamReason: No, hits=3.1 required=7.0 tests=HTML_00_10,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22231 invoked from network); 11 Mar 2013 20:09:35 -0000 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 20:09:35 -0000 Received: by mail-ie0-f182.google.com with SMTP id k14so5345654iea.27 for ; Mon, 11 Mar 2013 13:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=36D3w2y8Z3ZlPBodv4ptFNMO/oNmgdCeNk1p0UGPZHU=; b=V5P7uL/dztocXmukOJh5t9Qs+3izHLilDG+Ksas4mvAx9D5VDrMYlgRtxy3V/I6kP6 M6PHdGfC4dTh4YOLD6agZQF+GqInLheufLe/AeqgyZa05ROuZXW/BCasYckIL6sJZ74H iBW96GDn8RXxICcXWcqcBDZ8OF23F2Z3F1h2EMRgOV1PzByHKlwhqT6gJu+7ToB1NNcw xIRo5f4tWB4t0WrvC2ShVV/NAhfXfZ3xbZBOKCO3pNC4ndVsyJijsH9DIzxRMxm/aw/p 8iqQYulegoQaPHFA2pqGYai4zAUNohS4419A90BL3F7YkWcxP7szKSgV1jtcVZr7XHhN BmmA== MIME-Version: 1.0 X-Received: by 10.50.77.230 with SMTP id v6mr8934402igw.29.1363032514494; Mon, 11 Mar 2013 13:08:34 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 11 Mar 2013 13:08:34 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 11 Mar 2013 13:08:34 -0700 (PDT) Date: Mon, 11 Mar 2013 14:08:34 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] Seabios patch X-BeenThere: xen-users@lists.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="===============0466755595002421650==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0466755595002421650== Content-Type: multipart/alternative; boundary=e89a8f3ba87fd808e404d7abbcad --e89a8f3ba87fd808e404d7abbcad Content-Type: text/plain; charset=ISO-8859-1 I want to patch seabios . I hope someone can point me to Roth file to edit --e89a8f3ba87fd808e404d7abbcad Content-Type: text/html; charset=ISO-8859-1

I want to patch seabios . I hope someone can point me to Roth file to edit

--e89a8f3ba87fd808e404d7abbcad-- --===============0466755595002421650== 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 --===============0466755595002421650==-- From xen-users-bounces@lists.xen.org Mon Mar 11 22:43:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 22:43: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 1UFBQP-0000s3-J7; Mon, 11 Mar 2013 22:42:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFBQO-0000ry-On for xen-users@lists.xen.org; Mon, 11 Mar 2013 22:42:33 +0000 Received: from [85.158.139.83:65310] by server-2.bemta-5.messagelabs.com id 30/25-23989-8DD5E315; Mon, 11 Mar 2013 22:42:32 +0000 X-Env-Sender: shades_of_grey@earthlink.net X-Msg-Ref: server-2.tower-182.messagelabs.com!1363041749!28287418!1 X-Originating-IP: [209.86.89.68] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29593 invoked from network); 11 Mar 2013 22:42:30 -0000 Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68) by server-2.tower-182.messagelabs.com with SMTP; 11 Mar 2013 22:42:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RwQmD9cncRxp7qudh0jvOjr3zptDACvku/6HV+10d4iRyidkuFJwNN0hqyIcXR9T; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.250.223] (helo=[192.168.1.13]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1UFBQL-0006E7-5S for xen-users@lists.xen.org; Mon, 11 Mar 2013 18:42:29 -0400 Message-ID: <513E5DCF.3070101@earthlink.net> Date: Mon, 11 Mar 2013 18:42:23 -0400 From: ShadesOfGrey User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: X-ELNK-Trace: 0fe7bc40aa99bc8fc963772e86942a7b94f5150ab1c16ac044d224e428e16b4590a109d2224677538c1e3e7743d2c296350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.250.223 Subject: Re: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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="===============4286319510820514952==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============4286319510820514952== Content-Type: multipart/alternative; boundary="------------030107020504080909000902" This is a multi-part message in MIME format. --------------030107020504080909000902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough Tutorial", this may be the potential cause of your issue. > *EFI Source Modification* > > Given that I encountered no make errors, I was shocked to find that > they still hadn't addressed the grub efi compatibility bug where it > fails to recognize available system memory. > > The fix for this is a source modification, though they have supposedly > added a build process for xen.efi, which would replace the debian.efi > generated by grub. I have yet to find adequate instructions to make > that work, and even if I did may break adding |xen-pciback.hide| to > the grub configuration, which we need if we are planning to do the > easy method of PCI Passthrough. > > So, let's open up |xen/arch/x86/setup.c| with our favorite text > editor, and find the line containing |( e820_raw_nr != 0 )|, and make > that area look like this: > > |#if 0 > else if ( e820_raw_nr != 0 ) > { > memmap_type = "Xen-e820"; > } > else if ( bootsym(lowmem_kb) ) > { > memmap_type = "Xen-e801"; > e820_raw[0].addr = 0; > e820_raw[0].size = bootsym(lowmem_kb) << 10; > e820_raw[0].type = E820_RAM; > e820_raw[1].addr = 0x100000; > e820_raw[1].size = bootsym(highmem_kb) << 10; > e820_raw[1].type = E820_RAM; > e820_raw_nr = 2; > } > #endif > else if ( mbi->flags & MBI_MEMMAP ) > | > > Notice we are commenting out a section of code using "if 0", which > always evaluates to false, to eliminate the section of e801 mapping > which breaks our ram recognition. > > I have no idea what kind of adverse affects this has on other systems, > but it has worked for me since Xen 4.1.2. > > *End EFI Source Modification* > On 03/08/2013 07:44 PM, Baojun Wang wrote: > Hi list, > > I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga > pass through), xen version is 4.2.1, dom0 & domU kernel are both > 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) > supports vt-d, processor is i7-2600 and it supports vt-d too. > > When pci passthrough is not enabled, everything is fine; > but after I enabled pci pass through, domU can only see 512MB RAM (USB > passed from pci-passthrough works, but video/intel didn't work, likely > due to i915 load error from dmesg, everything else is also good). > > I googled and found a similar issue is reported at: > http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html > > But seems there is no follow up how the problem is fixed, how can I > fix the issue? > > > Below are some links from pastebin.com: > > 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D > 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG > 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv > 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP > 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2 > > I tried xen version 4.2.0 too but still no luck. > My kernel have all xen feature enabled; and I can provide more info if > necessary. > > Thanks > baojun > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --------------030107020504080909000902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough Tutorial", this may be the potential cause of your issue.

EFI Source Modification

Given that I encountered no make errors, I was shocked to find that they still hadn't addressed the grub efi compatibility bug where it fails to recognize available system memory.

The fix for this is a source modification, though they have supposedly added a build process for xen.efi, which would replace the debian.efi generated by grub. I have yet to find adequate instructions to make that work, and even if I did may break adding xen-pciback.hide to the grub configuration, which we need if we are planning to do the easy method of PCI Passthrough.

So, let's open up xen/arch/x86/setup.c with our favorite text editor, and find the line containing ( e820_raw_nr != 0 ), and make that area look like this: 

#if 0
 else if ( e820_raw_nr != 0 )
 {
 memmap_type = "Xen-e820";
 }
 else if ( bootsym(lowmem_kb) )
 {
 memmap_type = "Xen-e801";
 e820_raw[0].addr = 0;
 e820_raw[0].size = bootsym(lowmem_kb) << 10;
 e820_raw[0].type = E820_RAM;
 e820_raw[1].addr = 0x100000;
 e820_raw[1].size = bootsym(highmem_kb) << 10;
 e820_raw[1].type = E820_RAM;
 e820_raw_nr = 2;
 }
 #endif
 else if ( mbi->flags & MBI_MEMMAP )

Notice we are commenting out a section of code using "if 0", which always evaluates to false, to eliminate the section of e801 mapping which breaks our ram recognition.

I have no idea what kind of adverse affects this has on other systems, but it has worked for me since Xen 4.1.2.

End EFI Source Modification



On 03/08/2013 07:44 PM, Baojun Wang wrote:
Hi list,

I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga
pass through), xen version is 4.2.1, dom0 & domU kernel are both
3.8.2, I checked the kernel log (DMAR) and the motherboard (H67)
supports vt-d, processor is i7-2600 and it supports vt-d too.

When pci passthrough is not enabled, everything is fine;
but after I enabled pci pass through, domU can only see 512MB RAM (USB
passed from pci-passthrough works, but video/intel didn't work, likely
due to i915 load error from dmesg, everything else is also good).

I googled and found a similar issue is reported at:
http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html

But seems there is no follow up how the problem is fixed, how can I
fix the issue?


Below are some links from pastebin.com:

1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D
2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG
3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv
4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP
5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2

I tried xen version 4.2.0 too but still no luck.
My kernel have all xen feature enabled; and I can provide more info if
necessary.

Thanks
baojun

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

--------------030107020504080909000902-- --===============4286319510820514952== 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 --===============4286319510820514952==-- From xen-users-bounces@lists.xen.org Mon Mar 11 22:43:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 11 Mar 2013 22:43: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 1UFBQP-0000s3-J7; Mon, 11 Mar 2013 22:42:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFBQO-0000ry-On for xen-users@lists.xen.org; Mon, 11 Mar 2013 22:42:33 +0000 Received: from [85.158.139.83:65310] by server-2.bemta-5.messagelabs.com id 30/25-23989-8DD5E315; Mon, 11 Mar 2013 22:42:32 +0000 X-Env-Sender: shades_of_grey@earthlink.net X-Msg-Ref: server-2.tower-182.messagelabs.com!1363041749!28287418!1 X-Originating-IP: [209.86.89.68] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29593 invoked from network); 11 Mar 2013 22:42:30 -0000 Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68) by server-2.tower-182.messagelabs.com with SMTP; 11 Mar 2013 22:42:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RwQmD9cncRxp7qudh0jvOjr3zptDACvku/6HV+10d4iRyidkuFJwNN0hqyIcXR9T; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.250.223] (helo=[192.168.1.13]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1UFBQL-0006E7-5S for xen-users@lists.xen.org; Mon, 11 Mar 2013 18:42:29 -0400 Message-ID: <513E5DCF.3070101@earthlink.net> Date: Mon, 11 Mar 2013 18:42:23 -0400 From: ShadesOfGrey User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: X-ELNK-Trace: 0fe7bc40aa99bc8fc963772e86942a7b94f5150ab1c16ac044d224e428e16b4590a109d2224677538c1e3e7743d2c296350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.250.223 Subject: Re: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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="===============4286319510820514952==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============4286319510820514952== Content-Type: multipart/alternative; boundary="------------030107020504080909000902" This is a multi-part message in MIME format. --------------030107020504080909000902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough Tutorial", this may be the potential cause of your issue. > *EFI Source Modification* > > Given that I encountered no make errors, I was shocked to find that > they still hadn't addressed the grub efi compatibility bug where it > fails to recognize available system memory. > > The fix for this is a source modification, though they have supposedly > added a build process for xen.efi, which would replace the debian.efi > generated by grub. I have yet to find adequate instructions to make > that work, and even if I did may break adding |xen-pciback.hide| to > the grub configuration, which we need if we are planning to do the > easy method of PCI Passthrough. > > So, let's open up |xen/arch/x86/setup.c| with our favorite text > editor, and find the line containing |( e820_raw_nr != 0 )|, and make > that area look like this: > > |#if 0 > else if ( e820_raw_nr != 0 ) > { > memmap_type = "Xen-e820"; > } > else if ( bootsym(lowmem_kb) ) > { > memmap_type = "Xen-e801"; > e820_raw[0].addr = 0; > e820_raw[0].size = bootsym(lowmem_kb) << 10; > e820_raw[0].type = E820_RAM; > e820_raw[1].addr = 0x100000; > e820_raw[1].size = bootsym(highmem_kb) << 10; > e820_raw[1].type = E820_RAM; > e820_raw_nr = 2; > } > #endif > else if ( mbi->flags & MBI_MEMMAP ) > | > > Notice we are commenting out a section of code using "if 0", which > always evaluates to false, to eliminate the section of e801 mapping > which breaks our ram recognition. > > I have no idea what kind of adverse affects this has on other systems, > but it has worked for me since Xen 4.1.2. > > *End EFI Source Modification* > On 03/08/2013 07:44 PM, Baojun Wang wrote: > Hi list, > > I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga > pass through), xen version is 4.2.1, dom0 & domU kernel are both > 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) > supports vt-d, processor is i7-2600 and it supports vt-d too. > > When pci passthrough is not enabled, everything is fine; > but after I enabled pci pass through, domU can only see 512MB RAM (USB > passed from pci-passthrough works, but video/intel didn't work, likely > due to i915 load error from dmesg, everything else is also good). > > I googled and found a similar issue is reported at: > http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html > > But seems there is no follow up how the problem is fixed, how can I > fix the issue? > > > Below are some links from pastebin.com: > > 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D > 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG > 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv > 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP > 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2 > > I tried xen version 4.2.0 too but still no luck. > My kernel have all xen feature enabled; and I can provide more info if > necessary. > > Thanks > baojun > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --------------030107020504080909000902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough Tutorial", this may be the potential cause of your issue.

EFI Source Modification

Given that I encountered no make errors, I was shocked to find that they still hadn't addressed the grub efi compatibility bug where it fails to recognize available system memory.

The fix for this is a source modification, though they have supposedly added a build process for xen.efi, which would replace the debian.efi generated by grub. I have yet to find adequate instructions to make that work, and even if I did may break adding xen-pciback.hide to the grub configuration, which we need if we are planning to do the easy method of PCI Passthrough.

So, let's open up xen/arch/x86/setup.c with our favorite text editor, and find the line containing ( e820_raw_nr != 0 ), and make that area look like this: 

#if 0
 else if ( e820_raw_nr != 0 )
 {
 memmap_type = "Xen-e820";
 }
 else if ( bootsym(lowmem_kb) )
 {
 memmap_type = "Xen-e801";
 e820_raw[0].addr = 0;
 e820_raw[0].size = bootsym(lowmem_kb) << 10;
 e820_raw[0].type = E820_RAM;
 e820_raw[1].addr = 0x100000;
 e820_raw[1].size = bootsym(highmem_kb) << 10;
 e820_raw[1].type = E820_RAM;
 e820_raw_nr = 2;
 }
 #endif
 else if ( mbi->flags & MBI_MEMMAP )

Notice we are commenting out a section of code using "if 0", which always evaluates to false, to eliminate the section of e801 mapping which breaks our ram recognition.

I have no idea what kind of adverse affects this has on other systems, but it has worked for me since Xen 4.1.2.

End EFI Source Modification



On 03/08/2013 07:44 PM, Baojun Wang wrote:
Hi list,

I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga
pass through), xen version is 4.2.1, dom0 & domU kernel are both
3.8.2, I checked the kernel log (DMAR) and the motherboard (H67)
supports vt-d, processor is i7-2600 and it supports vt-d too.

When pci passthrough is not enabled, everything is fine;
but after I enabled pci pass through, domU can only see 512MB RAM (USB
passed from pci-passthrough works, but video/intel didn't work, likely
due to i915 load error from dmesg, everything else is also good).

I googled and found a similar issue is reported at:
http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html

But seems there is no follow up how the problem is fixed, how can I
fix the issue?


Below are some links from pastebin.com:

1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D
2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG
3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv
4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP
5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2

I tried xen version 4.2.0 too but still no luck.
My kernel have all xen feature enabled; and I can provide more info if
necessary.

Thanks
baojun

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

--------------030107020504080909000902-- --===============4286319510820514952== 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 --===============4286319510820514952==-- From xen-users-bounces@lists.xen.org Tue Mar 12 00:16:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 00:16: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 1UFCsO-000241-CW; Tue, 12 Mar 2013 00:15:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFCsM-00023w-TU for xen-users@lists.xen.org; Tue, 12 Mar 2013 00:15:31 +0000 Received: from [85.158.138.51:26288] by server-13.bemta-3.messagelabs.com id 3A/2F-25744-1A37E315; Tue, 12 Mar 2013 00:15:29 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1363047326!31469478!1 X-Originating-IP: [209.85.220.177] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19472 invoked from network); 12 Mar 2013 00:15:28 -0000 Received: from mail-vc0-f177.google.com (HELO mail-vc0-f177.google.com) (209.85.220.177) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 00:15:28 -0000 Received: by mail-vc0-f177.google.com with SMTP id m18so2398024vcm.36 for ; Mon, 11 Mar 2013 17:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uk9ykESZHGG8V+cQyLeTYca0sh2hvEd0p5MUMSI00xo=; b=WxaYyCA8uRw7pajOA7yvn6GOifcjph/wlvRlHYQFPFDX31fgYqJstfd4I/9MOn2YfM 2NGzMzgF3Rx1rzLXCjNs+YJI5kW9/bOB2Nm8DdpY7AQgW6ULqyJKq1h5D89Ag4tvFl5R F6LO3Vzoqd/Ir/Kr7v8/DjKc8awHesZSLxeiJkrRRZ2qUGpF1prSzomX57mNsIjZcj75 PUBhYnc7drlEAr6IyU0YaQntHlVgKvq3NyMiD1HqlFOVQhG7ODeCBhkmJpJM2P2uBRu5 AfnD/XsJIB1YrQEC+LMfqE5ausrQGcX2l0R17niUTkAcB6ewQ6GChBm52iWnptn3RHQJ RBng== MIME-Version: 1.0 X-Received: by 10.58.23.169 with SMTP id n9mr5733407vef.58.1363047326537; Mon, 11 Mar 2013 17:15:26 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Mon, 11 Mar 2013 17:15:26 -0700 (PDT) In-Reply-To: <513E5DCF.3070101@earthlink.net> References: <513E5DCF.3070101@earthlink.net> Date: Mon, 11 Mar 2013 20:15:26 -0400 Message-ID: From: Casey DeLorme To: ShadesOfGrey Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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="===============9087210211491576318==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9087210211491576318== Content-Type: multipart/alternative; boundary=047d7b339887b60ca004d7af2f09 --047d7b339887b60ca004d7af2f09 Content-Type: text/plain; charset=UTF-8 That patch was for the EFI Dom0 memory recognition, and was patched sometime before 4.2 released (by reversing the if statement). Your xl dmesg shows e820 (and approx. 16G) so I am quite certain that is not the cause of your DomU memory bug. Can you provide your PV DomU configuration? I know I've heard about the bug before, usually in the context of over 3GB to a PV domain, but from what I recall it was fixed: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1673 On Mon, Mar 11, 2013 at 6:42 PM, ShadesOfGrey wrote: > From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough > Tutorial", this may be the potential cause of your issue. > > *EFI Source Modification* > > Given that I encountered no make errors, I was shocked to find that they > still hadn't addressed the grub efi compatibility bug where it fails to > recognize available system memory. > > The fix for this is a source modification, though they have supposedly > added a build process for xen.efi, which would replace the debian.efi > generated by grub. I have yet to find adequate instructions to make that > work, and even if I did may break adding xen-pciback.hide to the grub > configuration, which we need if we are planning to do the easy method of > PCI Passthrough. > > So, let's open up xen/arch/x86/setup.c with our favorite text editor, and > find the line containing ( e820_raw_nr != 0 ), and make that area look > like this: > > #if 0 > else if ( e820_raw_nr != 0 ) > { > memmap_type = "Xen-e820"; > } > else if ( bootsym(lowmem_kb) ) > { > memmap_type = "Xen-e801"; > e820_raw[0].addr = 0; > e820_raw[0].size = bootsym(lowmem_kb) << 10; > e820_raw[0].type = E820_RAM; > e820_raw[1].addr = 0x100000; > e820_raw[1].size = bootsym(highmem_kb) << 10; > e820_raw[1].type = E820_RAM; > e820_raw_nr = 2; > } > #endif > else if ( mbi->flags & MBI_MEMMAP ) > > > Notice we are commenting out a section of code using "if 0", which always > evaluates to false, to eliminate the section of e801 mapping which breaks > our ram recognition. > > I have no idea what kind of adverse affects this has on other systems, but > it has worked for me since Xen 4.1.2. > > *End EFI Source Modification* > > > > On 03/08/2013 07:44 PM, Baojun Wang wrote: > > Hi list, > > I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga > pass through), xen version is 4.2.1, dom0 & domU kernel are both > 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) > supports vt-d, processor is i7-2600 and it supports vt-d too. > > When pci passthrough is not enabled, everything is fine; > but after I enabled pci pass through, domU can only see 512MB RAM (USB > passed from pci-passthrough works, but video/intel didn't work, likely > due to i915 load error from dmesg, everything else is also good). > > I googled and found a similar issue is reported at:http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html > > But seems there is no follow up how the problem is fixed, how can I > fix the issue? > > > Below are some links from pastebin.com: > > 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D > 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG > 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv > 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP > 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2 > > I tried xen version 4.2.0 too but still no luck. > My kernel have all xen feature enabled; and I can provide more info if > necessary. > > Thanks > baojun > > _______________________________________________ > Xen-users mailing listXen-users@lists.xen.orghttp://lists.xen.org/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --047d7b339887b60ca004d7af2f09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That patch was for the EFI Dom0 memory rec= ognition, and was patched sometime before 4.2 released (by reversing the if= statement). =C2=A0Your xl dmesg shows e820 (and approx. 16G) so I am quite= certain that is not the cause of your DomU memory bug.

Can you provide your PV DomU configuration?
<= br>

I know I've heard about the bug before, us= ually in the context of over 3GB to a PV domain, but from what I recall it = was fixed:
=



On Mon, Mar 11, 2013 at 6:42 PM, ShadesOfGrey <shades_of_grey@e= arthlink.net> wrote:
=20 =20 =20
From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough Tutorial", this may be the potenti= al cause of your issue.

EFI Source Modification

Given that I encountered no make errors, I was shocked to find that they still hadn't addressed the grub efi compatibility bug where it fails to recognize available system memory.

The fix for this is a source modification, though they have supposedly added a build process for xen.efi, which would replace the debian.efi generated by grub. I have yet to find adequate instructions to make that work, and even if I did may break adding xen-pciback.hide to the grub configuration, which we need if we are planning to do the easy method of PCI Passthrough.

So, let's open up xen/arch/x86/setup.c with our favorite text editor, and find the line containing ( e820_raw_nr=C2=A0!=3D 0 ), and make that area look like this: 

#if 0
 else if ( e820_raw_nr !=3D 0 )
 {
 memmap_type =3D "Xen-e820";
 }
 else if ( bootsym(lowmem_kb) )
 {
 memmap_type =3D "Xen-e801";
 e820_raw[0].addr =3D 0;
 e820_raw[0].size =3D bootsym(lowmem_kb) << 10;
 e820_raw[0].type =3D E820_RAM;
 e820_raw[1].addr =3D 0x100000;
 e820_raw[1].size =3D bootsym(highmem_kb) << 10;
 e820_raw[1].type =3D E820_RAM;
 e820_raw_nr =3D 2;
 }
 #endif
 else if ( mbi->flags & MBI_MEMMAP )

Notice we are commenting out a section of code using "if 0&= quot;, which always evaluates to false, to eliminate the section of e801 mapping which breaks our ram recognition.

I have no idea what kind of adverse affects this has on other systems, but it has worked for me since Xen 4.1.2.

End EFI Source Modification



On 03/08/2013 07:44 PM, Baojun Wang wrote:
Hi list,

I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga
pass through), xen version is 4.2.1, dom0 & domU kernel are both
3.8.2, I checked the kernel log (DMAR) and the motherboard (H67)
supports vt-d, processor is i7-2600 and it supports vt-d too.

When pci passthrough is not enabled, everything is fine;
but after I enabled pci pass through, domU can only see 512MB RAM (USB
passed from pci-passthrough works, but video/intel didn't work, likely
due to i915 load error from dmesg, everything else is also good).

I googled and found a similar issue is reported at:
http://lists.xen.org/archives/html/xen-users/2012-12/=
msg00179.html

But seems there is no follow up how the problem is fixed, how can I
fix the issue?


Below are some links from pastebin.com:

1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D
2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG
3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv
4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP
5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2

I tried xen version 4.2.0 too but still no luck.
My kernel have all xen feature enabled; and I can provide more info if
necessary.

Thanks
baojun

_______________________________________________
Xen-users mailing list
Xen-users@list=
s.xen.org
http://lists.x=
en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--047d7b339887b60ca004d7af2f09-- --===============9087210211491576318== 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 --===============9087210211491576318==-- From xen-users-bounces@lists.xen.org Tue Mar 12 00:16:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 00:16: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 1UFCsO-000241-CW; Tue, 12 Mar 2013 00:15:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFCsM-00023w-TU for xen-users@lists.xen.org; Tue, 12 Mar 2013 00:15:31 +0000 Received: from [85.158.138.51:26288] by server-13.bemta-3.messagelabs.com id 3A/2F-25744-1A37E315; Tue, 12 Mar 2013 00:15:29 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1363047326!31469478!1 X-Originating-IP: [209.85.220.177] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19472 invoked from network); 12 Mar 2013 00:15:28 -0000 Received: from mail-vc0-f177.google.com (HELO mail-vc0-f177.google.com) (209.85.220.177) by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 00:15:28 -0000 Received: by mail-vc0-f177.google.com with SMTP id m18so2398024vcm.36 for ; Mon, 11 Mar 2013 17:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uk9ykESZHGG8V+cQyLeTYca0sh2hvEd0p5MUMSI00xo=; b=WxaYyCA8uRw7pajOA7yvn6GOifcjph/wlvRlHYQFPFDX31fgYqJstfd4I/9MOn2YfM 2NGzMzgF3Rx1rzLXCjNs+YJI5kW9/bOB2Nm8DdpY7AQgW6ULqyJKq1h5D89Ag4tvFl5R F6LO3Vzoqd/Ir/Kr7v8/DjKc8awHesZSLxeiJkrRRZ2qUGpF1prSzomX57mNsIjZcj75 PUBhYnc7drlEAr6IyU0YaQntHlVgKvq3NyMiD1HqlFOVQhG7ODeCBhkmJpJM2P2uBRu5 AfnD/XsJIB1YrQEC+LMfqE5ausrQGcX2l0R17niUTkAcB6ewQ6GChBm52iWnptn3RHQJ RBng== MIME-Version: 1.0 X-Received: by 10.58.23.169 with SMTP id n9mr5733407vef.58.1363047326537; Mon, 11 Mar 2013 17:15:26 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Mon, 11 Mar 2013 17:15:26 -0700 (PDT) In-Reply-To: <513E5DCF.3070101@earthlink.net> References: <513E5DCF.3070101@earthlink.net> Date: Mon, 11 Mar 2013 20:15:26 -0400 Message-ID: From: Casey DeLorme To: ShadesOfGrey Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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="===============9087210211491576318==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9087210211491576318== Content-Type: multipart/alternative; boundary=047d7b339887b60ca004d7af2f09 --047d7b339887b60ca004d7af2f09 Content-Type: text/plain; charset=UTF-8 That patch was for the EFI Dom0 memory recognition, and was patched sometime before 4.2 released (by reversing the if statement). Your xl dmesg shows e820 (and approx. 16G) so I am quite certain that is not the cause of your DomU memory bug. Can you provide your PV DomU configuration? I know I've heard about the bug before, usually in the context of over 3GB to a PV domain, but from what I recall it was fixed: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1673 On Mon, Mar 11, 2013 at 6:42 PM, ShadesOfGrey wrote: > From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough > Tutorial", this may be the potential cause of your issue. > > *EFI Source Modification* > > Given that I encountered no make errors, I was shocked to find that they > still hadn't addressed the grub efi compatibility bug where it fails to > recognize available system memory. > > The fix for this is a source modification, though they have supposedly > added a build process for xen.efi, which would replace the debian.efi > generated by grub. I have yet to find adequate instructions to make that > work, and even if I did may break adding xen-pciback.hide to the grub > configuration, which we need if we are planning to do the easy method of > PCI Passthrough. > > So, let's open up xen/arch/x86/setup.c with our favorite text editor, and > find the line containing ( e820_raw_nr != 0 ), and make that area look > like this: > > #if 0 > else if ( e820_raw_nr != 0 ) > { > memmap_type = "Xen-e820"; > } > else if ( bootsym(lowmem_kb) ) > { > memmap_type = "Xen-e801"; > e820_raw[0].addr = 0; > e820_raw[0].size = bootsym(lowmem_kb) << 10; > e820_raw[0].type = E820_RAM; > e820_raw[1].addr = 0x100000; > e820_raw[1].size = bootsym(highmem_kb) << 10; > e820_raw[1].type = E820_RAM; > e820_raw_nr = 2; > } > #endif > else if ( mbi->flags & MBI_MEMMAP ) > > > Notice we are commenting out a section of code using "if 0", which always > evaluates to false, to eliminate the section of e801 mapping which breaks > our ram recognition. > > I have no idea what kind of adverse affects this has on other systems, but > it has worked for me since Xen 4.1.2. > > *End EFI Source Modification* > > > > On 03/08/2013 07:44 PM, Baojun Wang wrote: > > Hi list, > > I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga > pass through), xen version is 4.2.1, dom0 & domU kernel are both > 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) > supports vt-d, processor is i7-2600 and it supports vt-d too. > > When pci passthrough is not enabled, everything is fine; > but after I enabled pci pass through, domU can only see 512MB RAM (USB > passed from pci-passthrough works, but video/intel didn't work, likely > due to i915 load error from dmesg, everything else is also good). > > I googled and found a similar issue is reported at:http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html > > But seems there is no follow up how the problem is fixed, how can I > fix the issue? > > > Below are some links from pastebin.com: > > 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D > 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG > 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv > 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP > 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2 > > I tried xen version 4.2.0 too but still no luck. > My kernel have all xen feature enabled; and I can provide more info if > necessary. > > Thanks > baojun > > _______________________________________________ > Xen-users mailing listXen-users@lists.xen.orghttp://lists.xen.org/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --047d7b339887b60ca004d7af2f09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That patch was for the EFI Dom0 memory rec= ognition, and was patched sometime before 4.2 released (by reversing the if= statement). =C2=A0Your xl dmesg shows e820 (and approx. 16G) so I am quite= certain that is not the cause of your DomU memory bug.

Can you provide your PV DomU configuration?
<= br>

I know I've heard about the bug before, us= ually in the context of over 3GB to a PV domain, but from what I recall it = was fixed:
=



On Mon, Mar 11, 2013 at 6:42 PM, ShadesOfGrey <shades_of_grey@e= arthlink.net> wrote:
=20 =20 =20
From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough Tutorial", this may be the potenti= al cause of your issue.

EFI Source Modification

Given that I encountered no make errors, I was shocked to find that they still hadn't addressed the grub efi compatibility bug where it fails to recognize available system memory.

The fix for this is a source modification, though they have supposedly added a build process for xen.efi, which would replace the debian.efi generated by grub. I have yet to find adequate instructions to make that work, and even if I did may break adding xen-pciback.hide to the grub configuration, which we need if we are planning to do the easy method of PCI Passthrough.

So, let's open up xen/arch/x86/setup.c with our favorite text editor, and find the line containing ( e820_raw_nr=C2=A0!=3D 0 ), and make that area look like this: 

#if 0
 else if ( e820_raw_nr !=3D 0 )
 {
 memmap_type =3D "Xen-e820";
 }
 else if ( bootsym(lowmem_kb) )
 {
 memmap_type =3D "Xen-e801";
 e820_raw[0].addr =3D 0;
 e820_raw[0].size =3D bootsym(lowmem_kb) << 10;
 e820_raw[0].type =3D E820_RAM;
 e820_raw[1].addr =3D 0x100000;
 e820_raw[1].size =3D bootsym(highmem_kb) << 10;
 e820_raw[1].type =3D E820_RAM;
 e820_raw_nr =3D 2;
 }
 #endif
 else if ( mbi->flags & MBI_MEMMAP )

Notice we are commenting out a section of code using "if 0&= quot;, which always evaluates to false, to eliminate the section of e801 mapping which breaks our ram recognition.

I have no idea what kind of adverse affects this has on other systems, but it has worked for me since Xen 4.1.2.

End EFI Source Modification



On 03/08/2013 07:44 PM, Baojun Wang wrote:
Hi list,

I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga
pass through), xen version is 4.2.1, dom0 & domU kernel are both
3.8.2, I checked the kernel log (DMAR) and the motherboard (H67)
supports vt-d, processor is i7-2600 and it supports vt-d too.

When pci passthrough is not enabled, everything is fine;
but after I enabled pci pass through, domU can only see 512MB RAM (USB
passed from pci-passthrough works, but video/intel didn't work, likely
due to i915 load error from dmesg, everything else is also good).

I googled and found a similar issue is reported at:
http://lists.xen.org/archives/html/xen-users/2012-12/=
msg00179.html

But seems there is no follow up how the problem is fixed, how can I
fix the issue?


Below are some links from pastebin.com:

1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D
2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG
3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv
4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP
5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2

I tried xen version 4.2.0 too but still no luck.
My kernel have all xen feature enabled; and I can provide more info if
necessary.

Thanks
baojun

_______________________________________________
Xen-users mailing list
Xen-users@list=
s.xen.org
http://lists.x=
en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--047d7b339887b60ca004d7af2f09-- --===============9087210211491576318== 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 --===============9087210211491576318==-- From xen-users-bounces@lists.xen.org Tue Mar 12 04:44:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 04:44: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 1UFH3F-00083Y-Cy; Tue, 12 Mar 2013 04:43:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFH3C-00083O-Sg for xen-users@lists.xen.org; Tue, 12 Mar 2013 04:42:59 +0000 Received: from [85.158.137.99:58045] by server-2.bemta-3.messagelabs.com id A0/C8-05208-152BE315; Tue, 12 Mar 2013 04:42:57 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-13.tower-217.messagelabs.com!1363063374!984308!1 X-Originating-IP: [209.85.220.177] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32386 invoked from network); 12 Mar 2013 04:42:55 -0000 Received: from mail-vc0-f177.google.com (HELO mail-vc0-f177.google.com) (209.85.220.177) by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 04:42:55 -0000 Received: by mail-vc0-f177.google.com with SMTP id m18so2475233vcm.36 for ; Mon, 11 Mar 2013 21:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=TCylxkZWGFBdt2yQk7Gfaa/hCrXddykh2x07Mrc7ieI=; b=ZaX0MIbpxDhJYeslLE1Yuf+3VS+ybFSeuNx0aj5wUwRPBKbV+NdHIPVlLeqe8bsZCr 3OJFHbqD/YkGlOz0kIpQBgnznve90oviKvyD/fyL8jw1Aw8HLVsp7QZRqweq1o5nqy0E buMBSjjY5etyq8YWqUGHyaUG3rodpc8NK4QByxWDS0OVtwhKIdu9mN9j5YpI4Yf55sm7 ML31xrqrJf9cw7CyLoTdsh0UtnKm5UVJnUyoORkVMbFogclEPtqRgsCI2hhTU+SanCXO eS4P6YQVwXGuFuLEukHbRMU22/2XaR5sCTxErcd/T/wlVgAo9HCJsVzg5SfCjV6MC3W0 q6Nw== MIME-Version: 1.0 X-Received: by 10.220.222.72 with SMTP id if8mr5682212vcb.61.1363063374025; Mon, 11 Mar 2013 21:42:54 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Mon, 11 Mar 2013 21:42:53 -0700 (PDT) In-Reply-To: References: <513E5DCF.3070101@earthlink.net> Date: Tue, 12 Mar 2013 00:42:53 -0400 Message-ID: From: Casey DeLorme To: Baojun Wang , "xen-users@lists.xen.org" Subject: Re: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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="===============5598258058930760331==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5598258058930760331== Content-Type: multipart/alternative; boundary=14dae9ccd5943748c404d7b2eca8 --14dae9ccd5943748c404d7b2eca8 Content-Type: text/plain; charset=UTF-8 As mentioned, that patch is only for Dom0 with EFI and has nothing to do with DomU's. I have very little PV experience myself, but I can suggest a couple of ideas. You might try dropping the RAM to maybe 3G (3072) and seeing if anything changes. Perhaps try increments of 1G and see where it breaks. If reducing the supplied RAM suddenly provides more memory then maybe the bug I referenced earlier wasn't fixed after all. It would give you something more to work with anyways. Another possibility is manually setting `e820_host`, which according to the man pages is specifically for supporting PCI Passthrough to PV, however the same description claims that it should automatically be on when devices are passed. Can't hurt to give it a try. Also, just a reminder to use "Reply All" to keep the list in the loop. Out of curiosity, is there any reason why you would choose PV over PVHVM? My understanding is that PVHVM performs nearly the same while remaining mostly encapsulated without all the confusion I see regarding PV configuration and bugs. If you don't have a specific reason it might be worth investigating. In any event, I hope these help with troubleshooting. Sincerely, ~Casey PS - Sorry for top posting, just wanted the original message to remain in context when I included xen-users again. Also, another reference link: http://wiki.xen.org/wiki/Virtualization_Spectrum On Mon, Mar 11, 2013 at 10:47 PM, Baojun Wang wrote: > Yep, I tried comment the code by shadowofgray, but it still yields the > same result. > > Below is domU configuration: > > kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" > extra = "(hd0)/boot/grub/pvgrub.lst" > > memory = '8192' > > vcpus = 4 > > disk = [ '/dev/sda1,raw,xvda1,w', '/dev/vg00/gentoo,raw,xvda2,w', > '/dev/vg00/exports,raw,xvda3,w', '/dev/vg01/home,raw,xvda4,w', > '/dev/vg01/swap,raw,xvda5,w' ] > > name = 'gentoo' > > serial = 'pty' > # > gfx_passthru=1 > > pci = [ '00:02.0', '00:1a.0', '00:1b.0', '00:1d.0', '03:00.0', '04:00.0' ] > > vif = [ 'mac=fe:00:36:79:00:01, bridge=br0, virtio' ] > > > boot option for xen.gz already includes pci devices above. and pci > devices passed through are video/audio/usb: > Below is lspci output: > > 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor > Family DRAM Controller (rev 09) > 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core > Processor Family PCI Express Root Port (rev 09) > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation > Core Processor Family Integrated Graphics Controller (rev 09) > 00:16.0 Communication controller: Intel Corporation 6 Series/C200 > Series Chipset Family MEI Controller #1 (rev 04) > 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset > Family USB Enhanced Host Controller #2 (rev 05) > 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset > Family High Definition Audio Controller (rev 05) > 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 1 (rev b5) > 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 2 (rev b5) > 00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 3 (rev b5) > 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 4 (rev b5) > 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 5 (rev b5) > 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset > Family USB Enhanced Host Controller #1 (rev 05) > 00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset Family LPC > Controller (rev 05) > 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series > Chipset Family SATA AHCI Controller (rev 05) > 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family > SMBus Controller (rev 05) > 03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB > Host Controller > 04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB > Host Controller > 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06) > > > > Thanks > baojun > > On Mon, Mar 11, 2013 at 5:15 PM, Casey DeLorme wrote: > > That patch was for the EFI Dom0 memory recognition, and was patched > sometime > > before 4.2 released (by reversing the if statement). Your xl dmesg shows > > e820 (and approx. 16G) so I am quite certain that is not the cause of > your > > DomU memory bug. > > > > Can you provide your PV DomU configuration? > > > > > > I know I've heard about the bug before, usually in the context of over > 3GB > > to a PV domain, but from what I recall it was fixed: > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1673 > > > > > > > > On Mon, Mar 11, 2013 at 6:42 PM, ShadesOfGrey < > shades_of_grey@earthlink.net> > > wrote: > >> > >> From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough > >> Tutorial", this may be the potential cause of your issue. > >> > >> EFI Source Modification > >> > >> Given that I encountered no make errors, I was shocked to find that they > >> still hadn't addressed the grub efi compatibility bug where it fails to > >> recognize available system memory. > >> > >> The fix for this is a source modification, though they have supposedly > >> added a build process for xen.efi, which would replace the debian.efi > >> generated by grub. I have yet to find adequate instructions to make that > >> work, and even if I did may break adding xen-pciback.hide to the grub > >> configuration, which we need if we are planning to do the easy method > of PCI > >> Passthrough. > >> > >> So, let's open up xen/arch/x86/setup.c with our favorite text editor, > and > >> find the line containing ( e820_raw_nr != 0 ), and make that area look > like > >> this: > >> > >> #if 0 > >> else if ( e820_raw_nr != 0 ) > >> { > >> memmap_type = "Xen-e820"; > >> } > >> else if ( bootsym(lowmem_kb) ) > >> { > >> memmap_type = "Xen-e801"; > >> e820_raw[0].addr = 0; > >> e820_raw[0].size = bootsym(lowmem_kb) << 10; > >> e820_raw[0].type = E820_RAM; > >> e820_raw[1].addr = 0x100000; > >> e820_raw[1].size = bootsym(highmem_kb) << 10; > >> e820_raw[1].type = E820_RAM; > >> e820_raw_nr = 2; > >> } > >> #endif > >> else if ( mbi->flags & MBI_MEMMAP ) > >> > >> > >> Notice we are commenting out a section of code using "if 0", which > always > >> evaluates to false, to eliminate the section of e801 mapping which > breaks > >> our ram recognition. > >> > >> I have no idea what kind of adverse affects this has on other systems, > but > >> it has worked for me since Xen 4.1.2. > >> > >> End EFI Source Modification > >> > >> > >> > >> On 03/08/2013 07:44 PM, Baojun Wang wrote: > >> > >> Hi list, > >> > >> I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga > >> pass through), xen version is 4.2.1, dom0 & domU kernel are both > >> 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) > >> supports vt-d, processor is i7-2600 and it supports vt-d too. > >> > >> When pci passthrough is not enabled, everything is fine; > >> but after I enabled pci pass through, domU can only see 512MB RAM (USB > >> passed from pci-passthrough works, but video/intel didn't work, likely > >> due to i915 load error from dmesg, everything else is also good). > >> > >> I googled and found a similar issue is reported at: > >> http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html > >> > >> But seems there is no follow up how the problem is fixed, how can I > >> fix the issue? > >> > >> > >> Below are some links from pastebin.com: > >> > >> 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D > >> 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG > >> 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv > >> 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP > >> 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2 > >> > >> I tried xen version 4.2.0 too but still no luck. > >> My kernel have all xen feature enabled; and I can provide more info if > >> necessary. > >> > >> Thanks > >> baojun > >> > >> _______________________________________________ > >> 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 > > > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > --14dae9ccd5943748c404d7b2eca8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As mentioned, that patch is only for Dom0 with E= FI and has nothing to do with DomU's.

I ha= ve very little PV experience myself, but I can suggest a couple of ideas.


You might try dropping the RAM to maybe = 3G (3072) and seeing if anything changes. =C2=A0Perhaps try increments of 1= G and see where it breaks. =C2=A0If reducing the supplied RAM suddenly prov= ides more memory then maybe the bug I referenced earlier wasn't fixed a= fter all. =C2=A0It would give you something more to work with anyways.


Another possibility is manually setting = `e820_host`, which according to the man pages is specifically for supportin= g PCI Passthrough to PV, however the same description claims that it should= automatically be on when devices are passed. =C2=A0Can't hurt to give = it a try.


Also, just a reminder to use "Reply= All" to keep the list in the loop.


Out of curiosity, is there any reason why you would choose PV over PV= HVM? =C2=A0My understanding is that PVHVM performs nearly the same while re= maining mostly encapsulated without all the confusion I see regarding PV co= nfiguration and bugs. =C2=A0If you don't have a specific reason it migh= t be worth investigating.


In any event, I hope these help with tro= ubleshooting.

Sincerely,

= ~Casey

PS - Sorry for top posting, jus= t wanted the original message to remain in context when I included xen-user= s again.

Also, another reference link:


On Mon, Mar 11, 2013 at 10:47 PM, Baojun Wang <wangbj@gmail.com> wrote:
Yep, I tried comment the code by shadowofgray, but it still yields the
same result.

Below is domU configuration:

kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"
extra =3D "(hd0)/boot/grub/pvgrub.lst"

memory =3D '8192'

vcpus =3D 4

disk =3D [ '/dev/sda1,raw,xvda1,w', '/dev/vg00/gentoo,raw,xvda2= ,w',
'/dev/vg00/exports,raw,xvda3,w', =C2=A0'/dev/vg01/home,raw,xvda= 4,w',
'/dev/vg01/swap,raw,xvda5,w' ]

name =3D 'gentoo'

serial =3D 'pty'
#
gfx_passthru=3D1

pci =3D [ '00:02.0', '00:1a.0', '00:1b.0', '00:= 1d.0', '03:00.0', '04:00.0' ]

vif =3D [ 'mac=3Dfe:00:36:79:00:01, bridge=3Dbr0, virtio' ]


boot option for xen.gz already includes pci devices above. and pci
devices passed through are video/audio/usb:
Below is lspci output:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor
Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200
Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset
Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 1 (rev b5)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 2 (rev b5)
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 3 (rev b5)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 4 (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 5 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset Family LPC
Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series
Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family
SMBus Controller (rev 05)
03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB
Host Controller
04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB
Host Controller
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06)



Thanks
baojun

On Mon, Mar 11, 2013 at 5:15 PM, Casey DeLorme <cdelorme@gmail.com> wrote:
> That patch was for the EFI Dom0 memory recognition, and was patched so= metime
> before 4.2 released (by reversing the if statement). =C2=A0Your xl dme= sg shows
> e820 (and approx. 16G) so I am quite certain that is not the cause of = your
> DomU memory bug.
>
> Can you provide your PV DomU configuration?
>
>
> I know I've heard about the bug before, usually in the context of = over 3GB
> to a PV domain, but from what I recall it was fixed:
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?i= d=3D1673
>
>
>
> On Mon, Mar 11, 2013 at 6:42 PM, ShadesOfGrey <shades_of_grey@earthlink.net>
> wrote:
>>
>> From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI= Passthrough
>> Tutorial", this may be the potential cause of your issue.
>>
>> EFI Source Modification
>>
>> Given that I encountered no make errors, I was shocked to find tha= t they
>> still hadn't addressed the grub efi compatibility bug where it= fails to
>> recognize available system memory.
>>
>> The fix for this is a source modification, though they have suppos= edly
>> added a build process for xen.efi, which would replace the debian.= efi
>> generated by grub. I have yet to find adequate instructions to mak= e that
>> work, and even if I did may break adding xen-pciback.hide to the g= rub
>> configuration, which we need if we are planning to do the easy met= hod of PCI
>> Passthrough.
>>
>> So, let's open up xen/arch/x86/setup.c with our favorite text = editor, and
>> find the line containing ( e820_raw_nr !=3D 0 ), and make that are= a look like
>> this:
>>
>> #if 0
>> =C2=A0else if ( e820_raw_nr !=3D 0 )
>> =C2=A0{
>> =C2=A0memmap_type =3D "Xen-e820";
>> =C2=A0}
>> =C2=A0else if ( bootsym(lowmem_kb) )
>> =C2=A0{
>> =C2=A0memmap_type =3D "Xen-e801";
>> =C2=A0e820_raw[0].addr =3D 0;
>> =C2=A0e820_raw[0].size =3D bootsym(lowmem_kb) << 10;
>> =C2=A0e820_raw[0].type =3D E820_RAM;
>> =C2=A0e820_raw[1].addr =3D 0x100000;
>> =C2=A0e820_raw[1].size =3D bootsym(highmem_kb) << 10;
>> =C2=A0e820_raw[1].type =3D E820_RAM;
>> =C2=A0e820_raw_nr =3D 2;
>> =C2=A0}
>> =C2=A0#endif
>> =C2=A0else if ( mbi->flags & MBI_MEMMAP )
>>
>>
>> Notice we are commenting out a section of code using "if 0&qu= ot;, which always
>> evaluates to false, to eliminate the section of e801 mapping which= breaks
>> our ram recognition.
>>
>> I have no idea what kind of adverse affects this has on other syst= ems, but
>> it has worked for me since Xen 4.1.2.
>>
>> End EFI Source Modification
>>
>>
>>
>> On 03/08/2013 07:44 PM, Baojun Wang wrote:
>>
>> Hi list,
>>
>> I'm trying to run pvlinux (via pvgrub) using pci passthrough (= and vga
>> pass through), xen version is 4.2.1, dom0 & domU kernel are bo= th
>> 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) >> supports vt-d, processor is i7-2600 and it supports vt-d too.
>>
>> When pci passthrough is not enabled, everything is fine;
>> but after I enabled pci pass through, domU can only see 512MB RAM = (USB
>> passed from pci-passthrough works, but video/intel didn't work= , likely
>> due to i915 load error from dmesg, everything else is also good).<= br> >>
>> I googled and found a similar issue is reported at:
>> http://lists.xen.org/archives/html/xen-users= /2012-12/msg00179.html
>>
>> But seems there is no follow up how the problem is fixed, how can = I
>> fix the issue?
>>
>>
>> Below are some links from pastebin.com:
>>
>> 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D
>> 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG
>> 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv
>> 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP
>> 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2
>>
>> I tried xen version 4.2.0 too but still no luck.
>> My kernel have all xen feature enabled; and I can provide more inf= o if
>> necessary.
>>
>> Thanks
>> baojun
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org=
> http://li= sts.xen.org/xen-users

--14dae9ccd5943748c404d7b2eca8-- --===============5598258058930760331== 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 --===============5598258058930760331==-- From xen-users-bounces@lists.xen.org Tue Mar 12 04:44:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 04:44: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 1UFH3F-00083Y-Cy; Tue, 12 Mar 2013 04:43:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFH3C-00083O-Sg for xen-users@lists.xen.org; Tue, 12 Mar 2013 04:42:59 +0000 Received: from [85.158.137.99:58045] by server-2.bemta-3.messagelabs.com id A0/C8-05208-152BE315; Tue, 12 Mar 2013 04:42:57 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-13.tower-217.messagelabs.com!1363063374!984308!1 X-Originating-IP: [209.85.220.177] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32386 invoked from network); 12 Mar 2013 04:42:55 -0000 Received: from mail-vc0-f177.google.com (HELO mail-vc0-f177.google.com) (209.85.220.177) by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 04:42:55 -0000 Received: by mail-vc0-f177.google.com with SMTP id m18so2475233vcm.36 for ; Mon, 11 Mar 2013 21:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=TCylxkZWGFBdt2yQk7Gfaa/hCrXddykh2x07Mrc7ieI=; b=ZaX0MIbpxDhJYeslLE1Yuf+3VS+ybFSeuNx0aj5wUwRPBKbV+NdHIPVlLeqe8bsZCr 3OJFHbqD/YkGlOz0kIpQBgnznve90oviKvyD/fyL8jw1Aw8HLVsp7QZRqweq1o5nqy0E buMBSjjY5etyq8YWqUGHyaUG3rodpc8NK4QByxWDS0OVtwhKIdu9mN9j5YpI4Yf55sm7 ML31xrqrJf9cw7CyLoTdsh0UtnKm5UVJnUyoORkVMbFogclEPtqRgsCI2hhTU+SanCXO eS4P6YQVwXGuFuLEukHbRMU22/2XaR5sCTxErcd/T/wlVgAo9HCJsVzg5SfCjV6MC3W0 q6Nw== MIME-Version: 1.0 X-Received: by 10.220.222.72 with SMTP id if8mr5682212vcb.61.1363063374025; Mon, 11 Mar 2013 21:42:54 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Mon, 11 Mar 2013 21:42:53 -0700 (PDT) In-Reply-To: References: <513E5DCF.3070101@earthlink.net> Date: Tue, 12 Mar 2013 00:42:53 -0400 Message-ID: From: Casey DeLorme To: Baojun Wang , "xen-users@lists.xen.org" Subject: Re: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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="===============5598258058930760331==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5598258058930760331== Content-Type: multipart/alternative; boundary=14dae9ccd5943748c404d7b2eca8 --14dae9ccd5943748c404d7b2eca8 Content-Type: text/plain; charset=UTF-8 As mentioned, that patch is only for Dom0 with EFI and has nothing to do with DomU's. I have very little PV experience myself, but I can suggest a couple of ideas. You might try dropping the RAM to maybe 3G (3072) and seeing if anything changes. Perhaps try increments of 1G and see where it breaks. If reducing the supplied RAM suddenly provides more memory then maybe the bug I referenced earlier wasn't fixed after all. It would give you something more to work with anyways. Another possibility is manually setting `e820_host`, which according to the man pages is specifically for supporting PCI Passthrough to PV, however the same description claims that it should automatically be on when devices are passed. Can't hurt to give it a try. Also, just a reminder to use "Reply All" to keep the list in the loop. Out of curiosity, is there any reason why you would choose PV over PVHVM? My understanding is that PVHVM performs nearly the same while remaining mostly encapsulated without all the confusion I see regarding PV configuration and bugs. If you don't have a specific reason it might be worth investigating. In any event, I hope these help with troubleshooting. Sincerely, ~Casey PS - Sorry for top posting, just wanted the original message to remain in context when I included xen-users again. Also, another reference link: http://wiki.xen.org/wiki/Virtualization_Spectrum On Mon, Mar 11, 2013 at 10:47 PM, Baojun Wang wrote: > Yep, I tried comment the code by shadowofgray, but it still yields the > same result. > > Below is domU configuration: > > kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" > extra = "(hd0)/boot/grub/pvgrub.lst" > > memory = '8192' > > vcpus = 4 > > disk = [ '/dev/sda1,raw,xvda1,w', '/dev/vg00/gentoo,raw,xvda2,w', > '/dev/vg00/exports,raw,xvda3,w', '/dev/vg01/home,raw,xvda4,w', > '/dev/vg01/swap,raw,xvda5,w' ] > > name = 'gentoo' > > serial = 'pty' > # > gfx_passthru=1 > > pci = [ '00:02.0', '00:1a.0', '00:1b.0', '00:1d.0', '03:00.0', '04:00.0' ] > > vif = [ 'mac=fe:00:36:79:00:01, bridge=br0, virtio' ] > > > boot option for xen.gz already includes pci devices above. and pci > devices passed through are video/audio/usb: > Below is lspci output: > > 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor > Family DRAM Controller (rev 09) > 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core > Processor Family PCI Express Root Port (rev 09) > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation > Core Processor Family Integrated Graphics Controller (rev 09) > 00:16.0 Communication controller: Intel Corporation 6 Series/C200 > Series Chipset Family MEI Controller #1 (rev 04) > 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset > Family USB Enhanced Host Controller #2 (rev 05) > 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset > Family High Definition Audio Controller (rev 05) > 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 1 (rev b5) > 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 2 (rev b5) > 00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 3 (rev b5) > 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 4 (rev b5) > 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset > Family PCI Express Root Port 5 (rev b5) > 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset > Family USB Enhanced Host Controller #1 (rev 05) > 00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset Family LPC > Controller (rev 05) > 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series > Chipset Family SATA AHCI Controller (rev 05) > 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family > SMBus Controller (rev 05) > 03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB > Host Controller > 04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB > Host Controller > 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06) > > > > Thanks > baojun > > On Mon, Mar 11, 2013 at 5:15 PM, Casey DeLorme wrote: > > That patch was for the EFI Dom0 memory recognition, and was patched > sometime > > before 4.2 released (by reversing the if statement). Your xl dmesg shows > > e820 (and approx. 16G) so I am quite certain that is not the cause of > your > > DomU memory bug. > > > > Can you provide your PV DomU configuration? > > > > > > I know I've heard about the bug before, usually in the context of over > 3GB > > to a PV domain, but from what I recall it was fixed: > > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1673 > > > > > > > > On Mon, Mar 11, 2013 at 6:42 PM, ShadesOfGrey < > shades_of_grey@earthlink.net> > > wrote: > >> > >> From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI Passthrough > >> Tutorial", this may be the potential cause of your issue. > >> > >> EFI Source Modification > >> > >> Given that I encountered no make errors, I was shocked to find that they > >> still hadn't addressed the grub efi compatibility bug where it fails to > >> recognize available system memory. > >> > >> The fix for this is a source modification, though they have supposedly > >> added a build process for xen.efi, which would replace the debian.efi > >> generated by grub. I have yet to find adequate instructions to make that > >> work, and even if I did may break adding xen-pciback.hide to the grub > >> configuration, which we need if we are planning to do the easy method > of PCI > >> Passthrough. > >> > >> So, let's open up xen/arch/x86/setup.c with our favorite text editor, > and > >> find the line containing ( e820_raw_nr != 0 ), and make that area look > like > >> this: > >> > >> #if 0 > >> else if ( e820_raw_nr != 0 ) > >> { > >> memmap_type = "Xen-e820"; > >> } > >> else if ( bootsym(lowmem_kb) ) > >> { > >> memmap_type = "Xen-e801"; > >> e820_raw[0].addr = 0; > >> e820_raw[0].size = bootsym(lowmem_kb) << 10; > >> e820_raw[0].type = E820_RAM; > >> e820_raw[1].addr = 0x100000; > >> e820_raw[1].size = bootsym(highmem_kb) << 10; > >> e820_raw[1].type = E820_RAM; > >> e820_raw_nr = 2; > >> } > >> #endif > >> else if ( mbi->flags & MBI_MEMMAP ) > >> > >> > >> Notice we are commenting out a section of code using "if 0", which > always > >> evaluates to false, to eliminate the section of e801 mapping which > breaks > >> our ram recognition. > >> > >> I have no idea what kind of adverse affects this has on other systems, > but > >> it has worked for me since Xen 4.1.2. > >> > >> End EFI Source Modification > >> > >> > >> > >> On 03/08/2013 07:44 PM, Baojun Wang wrote: > >> > >> Hi list, > >> > >> I'm trying to run pvlinux (via pvgrub) using pci passthrough (and vga > >> pass through), xen version is 4.2.1, dom0 & domU kernel are both > >> 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) > >> supports vt-d, processor is i7-2600 and it supports vt-d too. > >> > >> When pci passthrough is not enabled, everything is fine; > >> but after I enabled pci pass through, domU can only see 512MB RAM (USB > >> passed from pci-passthrough works, but video/intel didn't work, likely > >> due to i915 load error from dmesg, everything else is also good). > >> > >> I googled and found a similar issue is reported at: > >> http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html > >> > >> But seems there is no follow up how the problem is fixed, how can I > >> fix the issue? > >> > >> > >> Below are some links from pastebin.com: > >> > >> 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D > >> 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG > >> 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv > >> 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP > >> 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2 > >> > >> I tried xen version 4.2.0 too but still no luck. > >> My kernel have all xen feature enabled; and I can provide more info if > >> necessary. > >> > >> Thanks > >> baojun > >> > >> _______________________________________________ > >> 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 > > > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > --14dae9ccd5943748c404d7b2eca8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As mentioned, that patch is only for Dom0 with E= FI and has nothing to do with DomU's.

I ha= ve very little PV experience myself, but I can suggest a couple of ideas.


You might try dropping the RAM to maybe = 3G (3072) and seeing if anything changes. =C2=A0Perhaps try increments of 1= G and see where it breaks. =C2=A0If reducing the supplied RAM suddenly prov= ides more memory then maybe the bug I referenced earlier wasn't fixed a= fter all. =C2=A0It would give you something more to work with anyways.


Another possibility is manually setting = `e820_host`, which according to the man pages is specifically for supportin= g PCI Passthrough to PV, however the same description claims that it should= automatically be on when devices are passed. =C2=A0Can't hurt to give = it a try.


Also, just a reminder to use "Reply= All" to keep the list in the loop.


Out of curiosity, is there any reason why you would choose PV over PV= HVM? =C2=A0My understanding is that PVHVM performs nearly the same while re= maining mostly encapsulated without all the confusion I see regarding PV co= nfiguration and bugs. =C2=A0If you don't have a specific reason it migh= t be worth investigating.


In any event, I hope these help with tro= ubleshooting.

Sincerely,

= ~Casey

PS - Sorry for top posting, jus= t wanted the original message to remain in context when I included xen-user= s again.

Also, another reference link:


On Mon, Mar 11, 2013 at 10:47 PM, Baojun Wang <wangbj@gmail.com> wrote:
Yep, I tried comment the code by shadowofgray, but it still yields the
same result.

Below is domU configuration:

kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz"
extra =3D "(hd0)/boot/grub/pvgrub.lst"

memory =3D '8192'

vcpus =3D 4

disk =3D [ '/dev/sda1,raw,xvda1,w', '/dev/vg00/gentoo,raw,xvda2= ,w',
'/dev/vg00/exports,raw,xvda3,w', =C2=A0'/dev/vg01/home,raw,xvda= 4,w',
'/dev/vg01/swap,raw,xvda5,w' ]

name =3D 'gentoo'

serial =3D 'pty'
#
gfx_passthru=3D1

pci =3D [ '00:02.0', '00:1a.0', '00:1b.0', '00:= 1d.0', '03:00.0', '04:00.0' ]

vif =3D [ 'mac=3Dfe:00:36:79:00:01, bridge=3Dbr0, virtio' ]


boot option for xen.gz already includes pci devices above. and pci
devices passed through are video/audio/usb:
Below is lspci output:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor
Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200
Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset
Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 1 (rev b5)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 2 (rev b5)
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 3 (rev b5)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 4 (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset
Family PCI Express Root Port 5 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset Family LPC
Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series
Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family
SMBus Controller (rev 05)
03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB
Host Controller
04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB
Host Controller
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06)



Thanks
baojun

On Mon, Mar 11, 2013 at 5:15 PM, Casey DeLorme <cdelorme@gmail.com> wrote:
> That patch was for the EFI Dom0 memory recognition, and was patched so= metime
> before 4.2 released (by reversing the if statement). =C2=A0Your xl dme= sg shows
> e820 (and approx. 16G) so I am quite certain that is not the cause of = your
> DomU memory bug.
>
> Can you provide your PV DomU configuration?
>
>
> I know I've heard about the bug before, usually in the context of = over 3GB
> to a PV domain, but from what I recall it was fixed:
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?i= d=3D1673
>
>
>
> On Mon, Mar 11, 2013 at 6:42 PM, ShadesOfGrey <shades_of_grey@earthlink.net>
> wrote:
>>
>> From Casey Delorme's "Comprehensive Xen Debian Wheezy PCI= Passthrough
>> Tutorial", this may be the potential cause of your issue.
>>
>> EFI Source Modification
>>
>> Given that I encountered no make errors, I was shocked to find tha= t they
>> still hadn't addressed the grub efi compatibility bug where it= fails to
>> recognize available system memory.
>>
>> The fix for this is a source modification, though they have suppos= edly
>> added a build process for xen.efi, which would replace the debian.= efi
>> generated by grub. I have yet to find adequate instructions to mak= e that
>> work, and even if I did may break adding xen-pciback.hide to the g= rub
>> configuration, which we need if we are planning to do the easy met= hod of PCI
>> Passthrough.
>>
>> So, let's open up xen/arch/x86/setup.c with our favorite text = editor, and
>> find the line containing ( e820_raw_nr !=3D 0 ), and make that are= a look like
>> this:
>>
>> #if 0
>> =C2=A0else if ( e820_raw_nr !=3D 0 )
>> =C2=A0{
>> =C2=A0memmap_type =3D "Xen-e820";
>> =C2=A0}
>> =C2=A0else if ( bootsym(lowmem_kb) )
>> =C2=A0{
>> =C2=A0memmap_type =3D "Xen-e801";
>> =C2=A0e820_raw[0].addr =3D 0;
>> =C2=A0e820_raw[0].size =3D bootsym(lowmem_kb) << 10;
>> =C2=A0e820_raw[0].type =3D E820_RAM;
>> =C2=A0e820_raw[1].addr =3D 0x100000;
>> =C2=A0e820_raw[1].size =3D bootsym(highmem_kb) << 10;
>> =C2=A0e820_raw[1].type =3D E820_RAM;
>> =C2=A0e820_raw_nr =3D 2;
>> =C2=A0}
>> =C2=A0#endif
>> =C2=A0else if ( mbi->flags & MBI_MEMMAP )
>>
>>
>> Notice we are commenting out a section of code using "if 0&qu= ot;, which always
>> evaluates to false, to eliminate the section of e801 mapping which= breaks
>> our ram recognition.
>>
>> I have no idea what kind of adverse affects this has on other syst= ems, but
>> it has worked for me since Xen 4.1.2.
>>
>> End EFI Source Modification
>>
>>
>>
>> On 03/08/2013 07:44 PM, Baojun Wang wrote:
>>
>> Hi list,
>>
>> I'm trying to run pvlinux (via pvgrub) using pci passthrough (= and vga
>> pass through), xen version is 4.2.1, dom0 & domU kernel are bo= th
>> 3.8.2, I checked the kernel log (DMAR) and the motherboard (H67) >> supports vt-d, processor is i7-2600 and it supports vt-d too.
>>
>> When pci passthrough is not enabled, everything is fine;
>> but after I enabled pci pass through, domU can only see 512MB RAM = (USB
>> passed from pci-passthrough works, but video/intel didn't work= , likely
>> due to i915 load error from dmesg, everything else is also good).<= br> >>
>> I googled and found a similar issue is reported at:
>> http://lists.xen.org/archives/html/xen-users= /2012-12/msg00179.html
>>
>> But seems there is no follow up how the problem is fixed, how can = I
>> fix the issue?
>>
>>
>> Below are some links from pastebin.com:
>>
>> 1) native dmesg without loading xen.gz: http://pastebin.com/BTVNTi8D
>> 2) (kernel) dmesg of dom0: http://pastebin.com/DEZ7gfmG
>> 3) (xl) dmesg of dom0: http://pastebin.com/46bR2ngv
>> 4) domU dmesg without pci passthrough: http://pastebin.com/DGZR4NLP
>> 5) domU dmesg with pci passthrough: http://pastebin.com/aujxwys2
>>
>> I tried xen version 4.2.0 too but still no luck.
>> My kernel have all xen feature enabled; and I can provide more inf= o if
>> necessary.
>>
>> Thanks
>> baojun
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org=
> http://li= sts.xen.org/xen-users

--14dae9ccd5943748c404d7b2eca8-- --===============5598258058930760331== 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 --===============5598258058930760331==-- From xen-users-bounces@lists.xen.org Tue Mar 12 07:35:13 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 07:35: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 1UFJii-0001kl-UD; Tue, 12 Mar 2013 07:34:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFJig-0001kg-Qq for xen-users@lists.xen.org; Tue, 12 Mar 2013 07:33:59 +0000 Received: from [85.158.138.51:60045] by server-3.bemta-3.messagelabs.com id 5F/39-26934-16ADE315; Tue, 12 Mar 2013 07:33:53 +0000 X-Env-Sender: christian@holpert.de X-Msg-Ref: server-4.tower-174.messagelabs.com!1363073632!31380655!1 X-Originating-IP: [80.67.31.31] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogODAuNjcuMzEuMzEgPT4gNjI2OTI=\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14764 invoked from network); 12 Mar 2013 07:33:52 -0000 Received: from smtprelay04.ispgateway.de (HELO smtprelay04.ispgateway.de) (80.67.31.31) by server-4.tower-174.messagelabs.com with SMTP; 12 Mar 2013 07:33:52 -0000 Received: from [217.83.55.143] (helo=colin.holpert.de) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1UFJia-0000B4-Iy; Tue, 12 Mar 2013 08:33:52 +0100 Received: from PRO43287A006.holpert.de (unknown [10.75.157.20]) by colin.holpert.de (Postfix) with ESMTP id 25EED7FF3; Tue, 12 Mar 2013 08:33:52 +0100 (CET) X-PGP-Fingerprint: D092 371C 931D 8F21 D71B 7A11 DC07 0F36 [RSA] X-PGP-Fingerprint: 8E3B 2F47 6673 B936 9EAE 52F3 4C8B C713 58C5 FFD6 [DH/DSS] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Mar 2013 08:33:51 +0100 To: xen-users@lists.xen.org From: Christian Holpert In-Reply-To: References: Mime-Version: 1.0 Message-Id: X-Df-Sender: Y2hyaXN0aWFuQGhvbHBlcnQuZGU= Cc: Baojun Wang Subject: Re: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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 At 01:44 09.03.2013, you wrote: >I googled and found a similar issue is reported at: >http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html > >But seems there is no follow up how the problem is fixed, how can I >fix the issue? in my case from December: no fix found till now. Upgraded my Gentoo to app-emulation/xen-tools-4.2.1-r1, = app-emulation/xen-4.2.1-r2. A workaround is to boot the domU without the PCI-Device in config and = pass it later on. This way you can work with all the RAM you need = _and_ the PCI-Device. Still hoping for a solution in one of the next updates. When I shutdown this domU for reboot I keep a 'ghost' in xl list xen xen # xl list Name ID Mem VCPUs State Tim= e(s) Domain-0 0 7529 4 r----- = 85.2 colin 1 2048 3 -b---- 1= 02.3 (null) 2 6 2 --ps-d 1= 44.6 which can be removed by killing the corresponding qemu-system-i386 process. Regards, Christian -- = Markt-Apotheke Christian Holpert e.K., M=F6mbris http://www.marktapotheke.org - info@marktapotheke.org http://www.blue-essentials-shop.de - info@blue-essentials-shop.de Apotheker Christian Holpert Im Markthof 5 63776 M=F6mbris Tel.: 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, Registernummer 2165 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 07:35:13 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 07:35: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 1UFJii-0001kl-UD; Tue, 12 Mar 2013 07:34:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFJig-0001kg-Qq for xen-users@lists.xen.org; Tue, 12 Mar 2013 07:33:59 +0000 Received: from [85.158.138.51:60045] by server-3.bemta-3.messagelabs.com id 5F/39-26934-16ADE315; Tue, 12 Mar 2013 07:33:53 +0000 X-Env-Sender: christian@holpert.de X-Msg-Ref: server-4.tower-174.messagelabs.com!1363073632!31380655!1 X-Originating-IP: [80.67.31.31] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogODAuNjcuMzEuMzEgPT4gNjI2OTI=\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14764 invoked from network); 12 Mar 2013 07:33:52 -0000 Received: from smtprelay04.ispgateway.de (HELO smtprelay04.ispgateway.de) (80.67.31.31) by server-4.tower-174.messagelabs.com with SMTP; 12 Mar 2013 07:33:52 -0000 Received: from [217.83.55.143] (helo=colin.holpert.de) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1UFJia-0000B4-Iy; Tue, 12 Mar 2013 08:33:52 +0100 Received: from PRO43287A006.holpert.de (unknown [10.75.157.20]) by colin.holpert.de (Postfix) with ESMTP id 25EED7FF3; Tue, 12 Mar 2013 08:33:52 +0100 (CET) X-PGP-Fingerprint: D092 371C 931D 8F21 D71B 7A11 DC07 0F36 [RSA] X-PGP-Fingerprint: 8E3B 2F47 6673 B936 9EAE 52F3 4C8B C713 58C5 FFD6 [DH/DSS] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Mar 2013 08:33:51 +0100 To: xen-users@lists.xen.org From: Christian Holpert In-Reply-To: References: Mime-Version: 1.0 Message-Id: X-Df-Sender: Y2hyaXN0aWFuQGhvbHBlcnQuZGU= Cc: Baojun Wang Subject: Re: [Xen-users] domU only see 512MB RAM when enabling PCI passthrough X-BeenThere: xen-users@lists.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 At 01:44 09.03.2013, you wrote: >I googled and found a similar issue is reported at: >http://lists.xen.org/archives/html/xen-users/2012-12/msg00179.html > >But seems there is no follow up how the problem is fixed, how can I >fix the issue? in my case from December: no fix found till now. Upgraded my Gentoo to app-emulation/xen-tools-4.2.1-r1, = app-emulation/xen-4.2.1-r2. A workaround is to boot the domU without the PCI-Device in config and = pass it later on. This way you can work with all the RAM you need = _and_ the PCI-Device. Still hoping for a solution in one of the next updates. When I shutdown this domU for reboot I keep a 'ghost' in xl list xen xen # xl list Name ID Mem VCPUs State Tim= e(s) Domain-0 0 7529 4 r----- = 85.2 colin 1 2048 3 -b---- 1= 02.3 (null) 2 6 2 --ps-d 1= 44.6 which can be removed by killing the corresponding qemu-system-i386 process. Regards, Christian -- = Markt-Apotheke Christian Holpert e.K., M=F6mbris http://www.marktapotheke.org - info@marktapotheke.org http://www.blue-essentials-shop.de - info@blue-essentials-shop.de Apotheker Christian Holpert Im Markthof 5 63776 M=F6mbris Tel.: 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, Registernummer 2165 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 10:33:23 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 10:33: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 1UFMVM-0005Pu-0F; Tue, 12 Mar 2013 10:32:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFMVK-0005Pp-BN for xen-users@lists.xen.org; Tue, 12 Mar 2013 10:32:23 +0000 Received: from [85.158.139.83:22140] by server-5.bemta-5.messagelabs.com id 7E/1F-02762-5340F315; Tue, 12 Mar 2013 10:32:21 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-6.tower-182.messagelabs.com!1363084339!24016084!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4472 invoked from network); 12 Mar 2013 10:32:19 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-6.tower-182.messagelabs.com with SMTP; 12 Mar 2013 10:32:19 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:61475) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UFMVG-0007sY-8b (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Tue, 12 Mar 2013 10:32:18 +0000 Message-ID: <513F0426.1080808@cam.ac.uk> Date: Tue, 12 Mar 2013 10:32:06 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> In-Reply-To: <513E1F89.8040506@brockmann-consult.de> Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============8869961835013415013==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============8869961835013415013== Content-Type: multipart/alternative; boundary="------------060701070204050308000901" This is a multi-part message in MIME format. --------------060701070204050308000901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As requested, lspci ############################################################################################################## 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07) 00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07) 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07) 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07) 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07) 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06) 00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05) 00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05) 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06) 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06) 00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6) 00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6) 00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6) 00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6) 00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6) 00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6) 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06) 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06) 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06) 03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] 03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06) 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller 09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller 0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10) 0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01) 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07) 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07) 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07) 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07) 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07) 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07) 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07) 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07) 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07) 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07) 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07) 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07) 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07) 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07) 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07) 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07) 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07) 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07) 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07) 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07) 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07) 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07) 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07) 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07) 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07) 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07) 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07) 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07) 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07) 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07) 7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07) 7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07) 7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07) 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07) 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07) 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07) 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07) 80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07) 80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07) 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) 83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] 83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07) ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07) ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07) ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07) ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07) ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07) ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07) ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07) ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07) ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07) ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07) ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07) ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07) ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07) ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07) ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07) ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07) ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07) ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07) ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07) ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07) ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07) ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07) ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07) ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07) ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07) ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07) ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07) ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07) ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07) ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07) ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07) ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07) ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07) ############################################################################################################## lspci -tv ############################################################################################################## -+-[0000:ff]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control Unit 0 | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control Unit 1 | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control Unit 2 | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control Unit 3 | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt Control Registers | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address Decoder | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home Agent | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor +-[0000:80]-+-00.0-[81]-- | +-01.0-[82]-- | +-02.0-[83]--+-00.0 Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] | | \-00.1 Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] | +-03.0-[84]-- | +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management | +-05.2 Intel Corporation Xeon E5/Core i7 Control Status and Global Errors | \-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC +-[0000:7f]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control Unit 0 | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control Unit 1 | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control Unit 2 | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control Unit 3 | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt Control Registers | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address Decoder | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home Agent | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor \-[0000:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 +-01.0-[01]-- +-01.1-[02]-- +-02.0-[03]--+-00.0 Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] | \-00.1 Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] +-03.0-[04]-- +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management +-05.2 Intel Corporation Xeon E5/Core i7 Control Status and Global Errors +-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC +-11.0-[05]----00.0 Intel Corporation C602 chipset 4-Port SATA Storage Control Unit +-16.0 Intel Corporation C600/X79 series chipset MEI Controller #1 +-16.1 Intel Corporation C600/X79 series chipset MEI Controller #2 +-1a.0 Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 +-1b.0 Intel Corporation C600/X79 series chipset High Definition Audio Controller +-1c.0-[06]----00.0 Intel Corporation 82574L Gigabit Network Connection +-1c.1-[07]----00.0 Intel Corporation 82574L Gigabit Network Connection +-1c.2-[08]----00.0 ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller +-1c.3-[09]----00.0 ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller +-1c.4-[0a]----00.0 Marvell Technology Group Ltd. Device 9230 +-1c.6-[0b]----00.0 VIA Technologies, Inc. VT6315 Series Firewire Controller +-1d.0 Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 +-1e.0-[0c]-- +-1f.0 Intel Corporation C600/X79 series chipset LPC Controller +-1f.2 Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller \-1f.3 Intel Corporation C600/X79 series chipset SMBus Host Controller ############################################################################################################## I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present. I've had a dig for the thread your talking about but I cannot find it. If anybody else knows if it still exists somewhere I'd be grateful if you could let me know. Thanks again for your help. Matt On 11/03/2013 18:16, Peter Maloney wrote: > Ah, because you have 2 cpus and 2 cards, can you post output of "lspci > -tv" and "lspci"? There was one guy who could pass through one card, > but when he physically added the 2nd card in the machine, the same > config with the first card wouldn't work any more because the 2 cards > were on the same PCI bridge. And he could pass through both and have > them work, but not just one of them at a time. (I have since cleaned > out my email box, and so I can't find the old thread) > > So you see on my system, the "02.0" bridge is separate from "0c.0", so > I don't have a problem. > > -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI to > PCI bridge (external gfx0 port B) > +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O > Memory Management Unit (IOMMU) > +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee ATI > RV370 5B60 [Radeon X300 (PCIE)] > | \-00.1 Advanced Micro Devices [AMD] nee ATI > RV370 [Radeon X300SE] > +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB 3.0 > Host Controller > +-0a.0-[03]----00.0 Marvell Technology Group Ltd. 88SE9172 > SATA 6Gb/s Controller > +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee ATI > Juniper XT [AMD Radeon HD 6000 Series] > | \-00.1 Advanced Micro Devices [AMD] nee ATI > Juniper HDMI Audio [Radeon HD 5700 Series] > > > *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 PCI > to PCI bridge (PCI express gpp port B) > 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to > PCI bridge (PCI express gpp port H) > 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to > PCI bridge (external gfx1 port A) > *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 > > > > On 03/11/2013 06:45 PM, Matthew Dean wrote: >> That was a good suggestion, I've just tried passing through a USB >> controller and that worked fine. The driver installed correctly and >> I can use devices attached to the relevant ports. The problem >> therefore seems to be to do with gpu passthrough specifically. I'm >> just going to describe my system and some settings I have in the bios >> as this is starting to feel like a system specific problem. The >> system is >> >> Asus Z9PE-D8 WS motherboard (chipset is intel C602) >> Dual Xeon 2620 >> 64 GB non-ecc memory >> Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm >> trying to pass through) >> >> In the bios I have vt-d enabled. I also have sub-feature settings >> for "Coherency Support" and "ATS Support" which are disabled by >> default. I've tried all combinations of these enabled and disabled. >> If I enable "ATS Support" I do however have to add the option >> "iommu=no-qinval,no-intremap" to the xen boot otherwise the system >> hangs as per this thread >> . >> If the problem is to no with these options then I think I have a problem. >> >> Has anybody got any thoughts? >> >> Matt >> >> On 11/03/2013 14:57, Peter Maloney wrote: >>> Did you try other devices, such as your onboard sound card, your >>> onboard USB controllers, etc.? Maybe your board doesn't do >>> passthrough properly. >>> >>> Or did you try another PCIe port for the card? Maybe there are bugs >>> where the addresses overlap with some other device, but in another >>> slot it wouldn't happen. >>> >>> >>> On 2013-03-11 14:48, Matthew Dean wrote: >>>> First of all, thank you for the suggestions. I've now re-installed >>>> windows and I've tried driver versions 12.3, 12.8 and 13.1 all with >>>> and without the CCC as I read in various places that it can cause >>>> problems. For 13.1 I never get anywhere close as per my previous >>>> messages. For 12.3 and 12.8 I at least get a BSOD, >>>> >>>> ####################################################################### >>>> >>>> A problem has been detected ... >>>> >>>> Attempt to reset the display driver and recover from timeout failed. >>>> >>>> If this is ... >>>> >>>> Techinal information: >>>> >>>> *** STOP: 0x00000116 >>>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>>> >>>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>>> FFFFF88003D8E000, Datestamp 4f597fca >>>> >>>> ####################################################################### >>>> >>>> Does anybody have any further ideas? >>>> >>>> Matt >>>> >>>> On 07/03/2013 21:42, John Sherwood wrote: >>>>> (and I should probably mention that it has been my experience that >>>>> that is the expected and correct behavior) >>>>> >>>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>>> > wrote: >>>>> >>>>> Having the windows logo freeze in the VNC window has been my >>>>> experience with GPU passthrough as well. >>>>> >>>>> >>>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>>> >>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> I believe that the Windows logo freezing in the vnc window >>>>> is normal behaviour when secondary GPU passthrough is >>>>> working as it should, since the display should be handed >>>>> over to the GPU. At least that was the case before when I >>>>> was passing through a HD6850 card as secondary to win7 >>>>> using xl. But you should expect output on the GPU, of course. >>>>> >>>>> Have you tried different versions of the catalyst driver? >>>>> I think that some users have reported problems with the >>>>> latest one (13-something). >>>>> >>>>> Regards, >>>>> Andreas >>>>> >>>>> 2013/3/7 Matthew Dean >>>> > >>>>> >>>>> Hi all, >>>>> >>>>> I've managed to get a windows 7 x64 hvm to boot and >>>>> install and I'm now looking to pass through a HD 7970 >>>>> as a secondary GPU. in order to prepare the devices >>>>> for passthrough I've used >>>>> >>>>> xl pci-assignable-add 83:00.0 >>>>> xl pci-assignable-add 83:00.1 >>>>> >>>>> Where I've identified the device pci ids using lspci. >>>>> This works fine and the devices appear when I call >>>>> 'xl pci-assignable-list'. After adding them to the vm >>>>> config (see below) I was able to get the vm to boot >>>>> and the devices appeared in device manager. >>>>> Installing the ATI drivers however has meant that on >>>>> further boots the machine never gets past the windows >>>>> logo in the VNC window and no output is generated from >>>>> the ATI card. It simply freezes there and the only >>>>> way I can get back into windows is via safe mode, even >>>>> after uninstalling the ATI software. >>>>> >>>>> Has anybody else experienced similar issues or have >>>>> any advice as to how to get this to work? I'm a bit >>>>> stumped and the wiki implies that this should 'just work'. >>>>> >>>>> Thank you in advance for any help. >>>>> >>>>> Matt >>>>> >>>>> Here is my machine config >>>>> >>>>> ########################################################### >>>>> >>>>> builder='hvm' >>>>> memory = 2048 >>>>> name = 'Windows7Test' >>>>> >>>>> vcpus=4 >>>>> pae=1 >>>>> acpi=1 >>>>> apic=1 >>>>> >>>>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>>> pci = [ '83:00.0' , '83:00.1' ] >>>>> >>>>> on_poweroff = 'destroy' >>>>> on_reboot = 'restart' >>>>> on_crash = 'destroy' >>>>> >>>>> boot='cd' >>>>> >>>>> sdl=0 >>>>> vnc=1 >>>>> vncconsole=0 >>>>> vncpasswd='' >>>>> vnclisten='172.24.226.84' >>>>> >>>>> stdvga=0 >>>>> >>>>> serial='pty' >>>>> usbdevice='tablet' >>>>> >>>>> gfx_passthru=0 >>>>> pci_power_mgmt=1 >>>>> xen_platform_pci=1 >>>>> pci_msitranslate=1 >>>>> viridian=1 >>>>> hpet=1 >>>>> >>>>> ############################################################ >>>>> >>>>> And the vm produces the following qemu log in >>>>> /var/log/xen/ >>>>> >>>>> ############################################################ >>>>> >>>>> domid: 4 >>>>> -videoram option does not work with cirrus vga device >>>>> model. Videoram set to 4M. >>>>> Strip off blktap sub-type prefix to >>>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>>> Using file /xen-guests/img/windows7Test.img in >>>>> read-write mode >>>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>>> Watching /local/domain/0/device-model/4/command >>>>> Watching /local/domain/4/cpu >>>>> char device redirected to /dev/pts/3 >>>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>>> shared page at pfn feffd >>>>> buffered io page at pfn feffb >>>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>>> 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/4/xen_extended_power_mgmt): >>>>> read error >>>>> 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. >>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>> count: 0, size: 0 >>>>> xs_read(/local/domain/4/log-throttling): read error >>>>> qemu: ignoring not-understood drive >>>>> `/local/domain/4/log-throttling' >>>>> medium change watch on >>>>> `/local/domain/4/log-throttling' - unknown device, ignored >>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>> count: 0, size: 0 >>>>> dm-command: hot insert pass-through pci dev >>>>> register_real_device: Assigning real physical device >>>>> 83:00.0 ... >>>>> register_real_device: Enable MSI translation via per >>>>> device option >>>>> register_real_device: Enable power management >>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>> /dev/xen/pci_iomul: No such file or directory: >>>>> 0x83:0x0.0x0 >>>>> pt_register_regions: IO region registered >>>>> (size=0x10000000 base_addr=0xe000000c) >>>>> pt_register_regions: IO region registered >>>>> (size=0x00040000 base_addr=0xf0000004) >>>>> pt_register_regions: IO region registered >>>>> (size=0x00000100 base_addr=0x0000f001) >>>>> pt_register_regions: Expansion ROM registered >>>>> (size=0x00020000 base_addr=0xf0040000) >>>>> pt_msi_setup: msi mapped with pirq 67 >>>>> pci_intx: intx=1 >>>>> register_real_device: Real physical device 83:00.0 >>>>> registered successfuly! >>>>> IRQ type = MSI-INTx >>>>> dm-command: hot insert pass-through pci dev >>>>> register_real_device: Assigning real physical device >>>>> 83:00.1 ... >>>>> register_real_device: Enable MSI translation via per >>>>> device option >>>>> register_real_device: Enable power management >>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>> /dev/xen/pci_iomul: No such file or directory: >>>>> 0x83:0x0.0x1 >>>>> pt_register_regions: IO region registered >>>>> (size=0x00004000 base_addr=0xf0060004) >>>>> pt_msi_setup: msi mapped with pirq 66 >>>>> pci_intx: intx=2 >>>>> register_real_device: Real physical device 83:00.1 >>>>> registered successfuly! >>>>> IRQ type = MSI-INTx >>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=1 >>>>> cirrus vga map change while on lfb mode >>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=1 >>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=1 >>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>> index=4 first_map=1 >>>>> 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. >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=0 >>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>> index=4 first_map=0 >>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=0 >>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>> index=4 first_map=0 >>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=0 >>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>> index=4 first_map=0 >>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=0 >>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>> index=4 first_map=0 >>>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>>> MSI-INTx translation >>>>> pci_intx: intx=1 >>>>> pt_msi_disable: Unmap msi with pirq 67 >>>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>>> pt_msi_setup: msi mapped with pirq 67 >>>>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=0 >>>>> >>>>> ###################################################################### >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-users mailing list >>>> Xen-users@lists.xen.org >>>> http://lists.xen.org/xen-users >>> >>> >>> -- >>> >>> -------------------------------------------- >>> Peter Maloney >>> Brockmann Consult >>> Max-Planck-Str. 2 >>> 21502 Geesthacht >>> Germany >>> Tel: +49 4152 889 300 >>> Fax: +49 4152 889 333 >>> E-mail:peter.maloney@brockmann-consult.de >>> Internet:http://www.brockmann-consult.de >>> -------------------------------------------- >> >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > --------------060701070204050308000901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
As requested,

lspci

##############################################################################################################

00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07)
00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06)
00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05)
00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05)
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06)
00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06)
00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6)
00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6)
00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6)
00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6)
00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6)
00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06)
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06)
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10)
0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01)
7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07)
80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)

##############################################################################################################

lspci -tv

##############################################################################################################

-+-[0000:ff]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-00.0-[81]--
 |           +-01.0-[82]--
 |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
 |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
 |           +-03.0-[84]--
 |           +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
 |           \-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
             +-01.0-[01]--
             +-01.1-[02]--
             +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
             |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
             +-03.0-[04]--
             +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
             +-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
             +-11.0-[05]----00.0  Intel Corporation C602 chipset 4-Port SATA Storage Control Unit
             +-16.0  Intel Corporation C600/X79 series chipset MEI Controller #1
             +-16.1  Intel Corporation C600/X79 series chipset MEI Controller #2
             +-1a.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2
             +-1b.0  Intel Corporation C600/X79 series chipset High Definition Audio Controller
             +-1c.0-[06]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.1-[07]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.2-[08]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.3-[09]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.4-[0a]----00.0  Marvell Technology Group Ltd. Device 9230
             +-1c.6-[0b]----00.0  VIA Technologies, Inc. VT6315 Series Firewire Controller
             +-1d.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1
             +-1e.0-[0c]--
             +-1f.0  Intel Corporation C600/X79 series chipset LPC Controller
             +-1f.2  Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation C600/X79 series chipset SMBus Host Controller

##############################################################################################################

I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present.  I've had a dig for the thread your talking about but I cannot find it.  If anybody else knows if it still exists somewhere I'd be grateful if you could let me know.

Thanks again for your help.

Matt

On 11/03/2013 18:16, Peter Maloney wrote:
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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





_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------



_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


--------------060701070204050308000901-- --===============8869961835013415013== 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 --===============8869961835013415013==-- From xen-users-bounces@lists.xen.org Tue Mar 12 10:33:23 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 10:33: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 1UFMVM-0005Pu-0F; Tue, 12 Mar 2013 10:32:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFMVK-0005Pp-BN for xen-users@lists.xen.org; Tue, 12 Mar 2013 10:32:23 +0000 Received: from [85.158.139.83:22140] by server-5.bemta-5.messagelabs.com id 7E/1F-02762-5340F315; Tue, 12 Mar 2013 10:32:21 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-6.tower-182.messagelabs.com!1363084339!24016084!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4472 invoked from network); 12 Mar 2013 10:32:19 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-6.tower-182.messagelabs.com with SMTP; 12 Mar 2013 10:32:19 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:61475) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UFMVG-0007sY-8b (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Tue, 12 Mar 2013 10:32:18 +0000 Message-ID: <513F0426.1080808@cam.ac.uk> Date: Tue, 12 Mar 2013 10:32:06 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> In-Reply-To: <513E1F89.8040506@brockmann-consult.de> Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============8869961835013415013==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============8869961835013415013== Content-Type: multipart/alternative; boundary="------------060701070204050308000901" This is a multi-part message in MIME format. --------------060701070204050308000901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As requested, lspci ############################################################################################################## 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07) 00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07) 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07) 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07) 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07) 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06) 00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05) 00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05) 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06) 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06) 00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6) 00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6) 00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6) 00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6) 00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6) 00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6) 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06) 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06) 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06) 03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] 03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06) 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller 09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller 0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10) 0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01) 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07) 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07) 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07) 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07) 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07) 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07) 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07) 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07) 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07) 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07) 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07) 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07) 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07) 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07) 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07) 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07) 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07) 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07) 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07) 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07) 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07) 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07) 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07) 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07) 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07) 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07) 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07) 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07) 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07) 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07) 7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07) 7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07) 7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07) 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07) 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07) 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07) 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07) 80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07) 80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07) 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) 83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] 83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07) ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07) ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07) ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07) ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07) ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07) ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07) ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07) ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07) ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07) ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07) ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07) ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07) ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07) ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07) ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07) ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07) ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07) ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07) ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07) ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07) ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07) ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07) ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07) ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07) ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07) ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07) ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07) ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07) ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07) ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07) ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07) ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07) ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07) ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07) ############################################################################################################## lspci -tv ############################################################################################################## -+-[0000:ff]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control Unit 0 | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control Unit 1 | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control Unit 2 | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control Unit 3 | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt Control Registers | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address Decoder | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home Agent | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor +-[0000:80]-+-00.0-[81]-- | +-01.0-[82]-- | +-02.0-[83]--+-00.0 Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] | | \-00.1 Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] | +-03.0-[84]-- | +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management | +-05.2 Intel Corporation Xeon E5/Core i7 Control Status and Global Errors | \-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC +-[0000:7f]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control Unit 0 | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control Unit 1 | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control Unit 2 | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control Unit 3 | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt Control Registers | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address Decoder | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home Agent | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor \-[0000:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 +-01.0-[01]-- +-01.1-[02]-- +-02.0-[03]--+-00.0 Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] | \-00.1 Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] +-03.0-[04]-- +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management +-05.2 Intel Corporation Xeon E5/Core i7 Control Status and Global Errors +-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC +-11.0-[05]----00.0 Intel Corporation C602 chipset 4-Port SATA Storage Control Unit +-16.0 Intel Corporation C600/X79 series chipset MEI Controller #1 +-16.1 Intel Corporation C600/X79 series chipset MEI Controller #2 +-1a.0 Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 +-1b.0 Intel Corporation C600/X79 series chipset High Definition Audio Controller +-1c.0-[06]----00.0 Intel Corporation 82574L Gigabit Network Connection +-1c.1-[07]----00.0 Intel Corporation 82574L Gigabit Network Connection +-1c.2-[08]----00.0 ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller +-1c.3-[09]----00.0 ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller +-1c.4-[0a]----00.0 Marvell Technology Group Ltd. Device 9230 +-1c.6-[0b]----00.0 VIA Technologies, Inc. VT6315 Series Firewire Controller +-1d.0 Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 +-1e.0-[0c]-- +-1f.0 Intel Corporation C600/X79 series chipset LPC Controller +-1f.2 Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller \-1f.3 Intel Corporation C600/X79 series chipset SMBus Host Controller ############################################################################################################## I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present. I've had a dig for the thread your talking about but I cannot find it. If anybody else knows if it still exists somewhere I'd be grateful if you could let me know. Thanks again for your help. Matt On 11/03/2013 18:16, Peter Maloney wrote: > Ah, because you have 2 cpus and 2 cards, can you post output of "lspci > -tv" and "lspci"? There was one guy who could pass through one card, > but when he physically added the 2nd card in the machine, the same > config with the first card wouldn't work any more because the 2 cards > were on the same PCI bridge. And he could pass through both and have > them work, but not just one of them at a time. (I have since cleaned > out my email box, and so I can't find the old thread) > > So you see on my system, the "02.0" bridge is separate from "0c.0", so > I don't have a problem. > > -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI to > PCI bridge (external gfx0 port B) > +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O > Memory Management Unit (IOMMU) > +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee ATI > RV370 5B60 [Radeon X300 (PCIE)] > | \-00.1 Advanced Micro Devices [AMD] nee ATI > RV370 [Radeon X300SE] > +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB 3.0 > Host Controller > +-0a.0-[03]----00.0 Marvell Technology Group Ltd. 88SE9172 > SATA 6Gb/s Controller > +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee ATI > Juniper XT [AMD Radeon HD 6000 Series] > | \-00.1 Advanced Micro Devices [AMD] nee ATI > Juniper HDMI Audio [Radeon HD 5700 Series] > > > *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 PCI > to PCI bridge (PCI express gpp port B) > 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to > PCI bridge (PCI express gpp port H) > 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to > PCI bridge (external gfx1 port A) > *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 > > > > On 03/11/2013 06:45 PM, Matthew Dean wrote: >> That was a good suggestion, I've just tried passing through a USB >> controller and that worked fine. The driver installed correctly and >> I can use devices attached to the relevant ports. The problem >> therefore seems to be to do with gpu passthrough specifically. I'm >> just going to describe my system and some settings I have in the bios >> as this is starting to feel like a system specific problem. The >> system is >> >> Asus Z9PE-D8 WS motherboard (chipset is intel C602) >> Dual Xeon 2620 >> 64 GB non-ecc memory >> Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm >> trying to pass through) >> >> In the bios I have vt-d enabled. I also have sub-feature settings >> for "Coherency Support" and "ATS Support" which are disabled by >> default. I've tried all combinations of these enabled and disabled. >> If I enable "ATS Support" I do however have to add the option >> "iommu=no-qinval,no-intremap" to the xen boot otherwise the system >> hangs as per this thread >> . >> If the problem is to no with these options then I think I have a problem. >> >> Has anybody got any thoughts? >> >> Matt >> >> On 11/03/2013 14:57, Peter Maloney wrote: >>> Did you try other devices, such as your onboard sound card, your >>> onboard USB controllers, etc.? Maybe your board doesn't do >>> passthrough properly. >>> >>> Or did you try another PCIe port for the card? Maybe there are bugs >>> where the addresses overlap with some other device, but in another >>> slot it wouldn't happen. >>> >>> >>> On 2013-03-11 14:48, Matthew Dean wrote: >>>> First of all, thank you for the suggestions. I've now re-installed >>>> windows and I've tried driver versions 12.3, 12.8 and 13.1 all with >>>> and without the CCC as I read in various places that it can cause >>>> problems. For 13.1 I never get anywhere close as per my previous >>>> messages. For 12.3 and 12.8 I at least get a BSOD, >>>> >>>> ####################################################################### >>>> >>>> A problem has been detected ... >>>> >>>> Attempt to reset the display driver and recover from timeout failed. >>>> >>>> If this is ... >>>> >>>> Techinal information: >>>> >>>> *** STOP: 0x00000116 >>>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>>> >>>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>>> FFFFF88003D8E000, Datestamp 4f597fca >>>> >>>> ####################################################################### >>>> >>>> Does anybody have any further ideas? >>>> >>>> Matt >>>> >>>> On 07/03/2013 21:42, John Sherwood wrote: >>>>> (and I should probably mention that it has been my experience that >>>>> that is the expected and correct behavior) >>>>> >>>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>>> > wrote: >>>>> >>>>> Having the windows logo freeze in the VNC window has been my >>>>> experience with GPU passthrough as well. >>>>> >>>>> >>>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>>> >>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> I believe that the Windows logo freezing in the vnc window >>>>> is normal behaviour when secondary GPU passthrough is >>>>> working as it should, since the display should be handed >>>>> over to the GPU. At least that was the case before when I >>>>> was passing through a HD6850 card as secondary to win7 >>>>> using xl. But you should expect output on the GPU, of course. >>>>> >>>>> Have you tried different versions of the catalyst driver? >>>>> I think that some users have reported problems with the >>>>> latest one (13-something). >>>>> >>>>> Regards, >>>>> Andreas >>>>> >>>>> 2013/3/7 Matthew Dean >>>> > >>>>> >>>>> Hi all, >>>>> >>>>> I've managed to get a windows 7 x64 hvm to boot and >>>>> install and I'm now looking to pass through a HD 7970 >>>>> as a secondary GPU. in order to prepare the devices >>>>> for passthrough I've used >>>>> >>>>> xl pci-assignable-add 83:00.0 >>>>> xl pci-assignable-add 83:00.1 >>>>> >>>>> Where I've identified the device pci ids using lspci. >>>>> This works fine and the devices appear when I call >>>>> 'xl pci-assignable-list'. After adding them to the vm >>>>> config (see below) I was able to get the vm to boot >>>>> and the devices appeared in device manager. >>>>> Installing the ATI drivers however has meant that on >>>>> further boots the machine never gets past the windows >>>>> logo in the VNC window and no output is generated from >>>>> the ATI card. It simply freezes there and the only >>>>> way I can get back into windows is via safe mode, even >>>>> after uninstalling the ATI software. >>>>> >>>>> Has anybody else experienced similar issues or have >>>>> any advice as to how to get this to work? I'm a bit >>>>> stumped and the wiki implies that this should 'just work'. >>>>> >>>>> Thank you in advance for any help. >>>>> >>>>> Matt >>>>> >>>>> Here is my machine config >>>>> >>>>> ########################################################### >>>>> >>>>> builder='hvm' >>>>> memory = 2048 >>>>> name = 'Windows7Test' >>>>> >>>>> vcpus=4 >>>>> pae=1 >>>>> acpi=1 >>>>> apic=1 >>>>> >>>>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>>> pci = [ '83:00.0' , '83:00.1' ] >>>>> >>>>> on_poweroff = 'destroy' >>>>> on_reboot = 'restart' >>>>> on_crash = 'destroy' >>>>> >>>>> boot='cd' >>>>> >>>>> sdl=0 >>>>> vnc=1 >>>>> vncconsole=0 >>>>> vncpasswd='' >>>>> vnclisten='172.24.226.84' >>>>> >>>>> stdvga=0 >>>>> >>>>> serial='pty' >>>>> usbdevice='tablet' >>>>> >>>>> gfx_passthru=0 >>>>> pci_power_mgmt=1 >>>>> xen_platform_pci=1 >>>>> pci_msitranslate=1 >>>>> viridian=1 >>>>> hpet=1 >>>>> >>>>> ############################################################ >>>>> >>>>> And the vm produces the following qemu log in >>>>> /var/log/xen/ >>>>> >>>>> ############################################################ >>>>> >>>>> domid: 4 >>>>> -videoram option does not work with cirrus vga device >>>>> model. Videoram set to 4M. >>>>> Strip off blktap sub-type prefix to >>>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>>> Using file /xen-guests/img/windows7Test.img in >>>>> read-write mode >>>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>>> Watching /local/domain/0/device-model/4/command >>>>> Watching /local/domain/4/cpu >>>>> char device redirected to /dev/pts/3 >>>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>>> shared page at pfn feffd >>>>> buffered io page at pfn feffb >>>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>>> 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/4/xen_extended_power_mgmt): >>>>> read error >>>>> 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. >>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>> count: 0, size: 0 >>>>> xs_read(/local/domain/4/log-throttling): read error >>>>> qemu: ignoring not-understood drive >>>>> `/local/domain/4/log-throttling' >>>>> medium change watch on >>>>> `/local/domain/4/log-throttling' - unknown device, ignored >>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>> count: 0, size: 0 >>>>> dm-command: hot insert pass-through pci dev >>>>> register_real_device: Assigning real physical device >>>>> 83:00.0 ... >>>>> register_real_device: Enable MSI translation via per >>>>> device option >>>>> register_real_device: Enable power management >>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>> /dev/xen/pci_iomul: No such file or directory: >>>>> 0x83:0x0.0x0 >>>>> pt_register_regions: IO region registered >>>>> (size=0x10000000 base_addr=0xe000000c) >>>>> pt_register_regions: IO region registered >>>>> (size=0x00040000 base_addr=0xf0000004) >>>>> pt_register_regions: IO region registered >>>>> (size=0x00000100 base_addr=0x0000f001) >>>>> pt_register_regions: Expansion ROM registered >>>>> (size=0x00020000 base_addr=0xf0040000) >>>>> pt_msi_setup: msi mapped with pirq 67 >>>>> pci_intx: intx=1 >>>>> register_real_device: Real physical device 83:00.0 >>>>> registered successfuly! >>>>> IRQ type = MSI-INTx >>>>> dm-command: hot insert pass-through pci dev >>>>> register_real_device: Assigning real physical device >>>>> 83:00.1 ... >>>>> register_real_device: Enable MSI translation via per >>>>> device option >>>>> register_real_device: Enable power management >>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>> /dev/xen/pci_iomul: No such file or directory: >>>>> 0x83:0x0.0x1 >>>>> pt_register_regions: IO region registered >>>>> (size=0x00004000 base_addr=0xf0060004) >>>>> pt_msi_setup: msi mapped with pirq 66 >>>>> pci_intx: intx=2 >>>>> register_real_device: Real physical device 83:00.1 >>>>> registered successfuly! >>>>> IRQ type = MSI-INTx >>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=1 >>>>> cirrus vga map change while on lfb mode >>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=1 >>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=1 >>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>> index=4 first_map=1 >>>>> 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. >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>> register with invalid access size alignment. >>>>> [Offset:0eh][Length:4] >>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=0 >>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>> index=4 first_map=0 >>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=0 >>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>> index=4 first_map=0 >>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=0 >>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>> index=4 first_map=0 >>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>> len=268435456 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>> len=262144 index=2 first_map=0 >>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>> index=4 first_map=0 >>>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>>> MSI-INTx translation >>>>> pci_intx: intx=1 >>>>> pt_msi_disable: Unmap msi with pirq 67 >>>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>>> pt_msi_setup: msi mapped with pirq 67 >>>>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f >>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=0 >>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>> len=16384 index=0 first_map=0 >>>>> >>>>> ###################################################################### >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-users mailing list >>>> Xen-users@lists.xen.org >>>> http://lists.xen.org/xen-users >>> >>> >>> -- >>> >>> -------------------------------------------- >>> Peter Maloney >>> Brockmann Consult >>> Max-Planck-Str. 2 >>> 21502 Geesthacht >>> Germany >>> Tel: +49 4152 889 300 >>> Fax: +49 4152 889 333 >>> E-mail:peter.maloney@brockmann-consult.de >>> Internet:http://www.brockmann-consult.de >>> -------------------------------------------- >> >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > --------------060701070204050308000901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
As requested,

lspci

##############################################################################################################

00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07)
00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06)
00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05)
00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05)
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06)
00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06)
00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6)
00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6)
00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6)
00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6)
00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6)
00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06)
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06)
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10)
0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01)
7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07)
80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)

##############################################################################################################

lspci -tv

##############################################################################################################

-+-[0000:ff]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-00.0-[81]--
 |           +-01.0-[82]--
 |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
 |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
 |           +-03.0-[84]--
 |           +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
 |           \-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
             +-01.0-[01]--
             +-01.1-[02]--
             +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
             |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
             +-03.0-[04]--
             +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
             +-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
             +-11.0-[05]----00.0  Intel Corporation C602 chipset 4-Port SATA Storage Control Unit
             +-16.0  Intel Corporation C600/X79 series chipset MEI Controller #1
             +-16.1  Intel Corporation C600/X79 series chipset MEI Controller #2
             +-1a.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2
             +-1b.0  Intel Corporation C600/X79 series chipset High Definition Audio Controller
             +-1c.0-[06]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.1-[07]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.2-[08]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.3-[09]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.4-[0a]----00.0  Marvell Technology Group Ltd. Device 9230
             +-1c.6-[0b]----00.0  VIA Technologies, Inc. VT6315 Series Firewire Controller
             +-1d.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1
             +-1e.0-[0c]--
             +-1f.0  Intel Corporation C600/X79 series chipset LPC Controller
             +-1f.2  Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation C600/X79 series chipset SMBus Host Controller

##############################################################################################################

I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present.  I've had a dig for the thread your talking about but I cannot find it.  If anybody else knows if it still exists somewhere I'd be grateful if you could let me know.

Thanks again for your help.

Matt

On 11/03/2013 18:16, Peter Maloney wrote:
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_______________________________________________
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





_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------



_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


--------------060701070204050308000901-- --===============8869961835013415013== 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 --===============8869961835013415013==-- From xen-users-bounces@lists.xen.org Tue Mar 12 11:42:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 11:42: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 1UFNaS-0000HI-Io; Tue, 12 Mar 2013 11:41:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFNaP-0000H0-Pr for xen-users@lists.xen.org; Tue, 12 Mar 2013 11:41:42 +0000 Received: from [85.158.139.211:63787] by server-14.bemta-5.messagelabs.com id B4/41-13158-5741F315; Tue, 12 Mar 2013 11:41:41 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-14.tower-206.messagelabs.com!1363088493!19020033!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=3.2 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n, BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4376 invoked from network); 12 Mar 2013 11:41:33 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 11:41:33 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lbh4l-1Ucw9T3KMV-00l2rs; Tue, 12 Mar 2013 12:41:28 +0100 Message-ID: <513F1467.2010202@brockmann-consult.de> Date: Tue, 12 Mar 2013 12:41:27 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Matthew Dean References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> <513F0426.1080808@cam.ac.uk> In-Reply-To: <513F0426.1080808@cam.ac.uk> X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:VuK6USacJfARH1mj+rNa7u2Rq8BjBhQ5C3IFvI+41md UmjAJXwVtc/JLkUvohwYCphXS8fHVPlkQIf2UxSn+iIvyeFbJj 2oYLku+mYidrSqVIi+UeN5p88cq33+JMvU3FA+6JfPkbKvmA9J xSGqhXzxpW590GML2PnymwgPpzOC9X9z0PTgUas/dpxgrdQo5e ghpSbJ2D90Li0nCJMo2+4Iktffdu+baqGCJueAioaYgIrcM/0U hJAvAwh8nPPVNx0VQ1EKDCf3jPfmKAVNGVLI9tYRnUSw0C0D+a 6OTy0aOAZvIlc8wmBvIsUSGl/Y5+Xkfq5CqbyN0784DUWugw4a 6F5DuE1U3G3m0HRraXqBAGIh6g+3svVPa+qdpZUfk Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============6399286018734657788==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============6399286018734657788== Content-Type: multipart/alternative; boundary="------------000406000300080301090806" This is a multi-part message in MIME format. --------------000406000300080301090806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Okay that is enormous output :D And I'm not sure what to say about it... hopefully someone else reading it can read it better than I can. Your bridges: *00:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) *80:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) Your GPUs: ... +-[0000:*80*]-+-00.0-[81]-- | +-*02.0*-[83]--+-00.0 Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] | | \-00.1 Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] \-[0000:*00*]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 +-*02.0*-[03]--+-00.0 Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] | \-00.1 Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] So you would be fine with PCI bridges if that 80 vs 00 is really different bridges and not just same ones seen by different CPUSs. I can look at many older Xeons and they all show just one set of bridges, and one very new one (newer socket) has the same thing as yours. But I don't use IOMMU on those, so I don't know what effect it has. I kinda think they are the same bridge, which would be bad. I don't know how to test it... pull out a CPU? ;) find some other detail that has IDs? disable one in the bios (unlikely)? or you could test this by passing through both cards to the same domu... This would be a good test (and matches what the other thread was about... his worked with passing both through) On 2013-03-12 11:32, Matthew Dean wrote: > As requested, > > lspci > > ############################################################################################################## > > 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) > 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 1a (rev 07) > 00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 1b (rev 07) > 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 2a (rev 07) > 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 3a in PCI Express Mode (rev 07) > 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address > Map, VTd_Misc, System Management (rev 07) > 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control > Status and Global Errors (rev 07) > 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) > 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Virtual Root Port (rev 06) > 00:16.0 Communication controller: Intel Corporation C600/X79 series > chipset MEI Controller #1 (rev 05) > 00:16.1 Communication controller: Intel Corporation C600/X79 series > chipset MEI Controller #2 (rev 05) > 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #2 (rev 06) > 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High > Definition Audio Controller (rev 06) > 00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 1 (rev b6) > 00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 2 (rev b6) > 00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 3 (rev b6) > 00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 4 (rev b6) > 00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 5 (rev b6) > 00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 7 (rev b6) > 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #1 (rev 06) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) > 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC > Controller (rev 06) > 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset > 6-Port SATA AHCI Controller (rev 06) > 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host > Controller (rev 06) > 03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee > ATI Tahiti XT [Radeon HD 7970] > 03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT > HDMI Audio [Radeon HD 7970 Series] > 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 > chipset 4-Port SATA Storage Control Unit (rev 06) > 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB > Host Controller > 09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB > Host Controller > 0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 > (rev 10) > 0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series > Firewire Controller (rev 01) > 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > 0 (rev 07) > 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 0 (rev 07) > 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 0 (rev 07) > 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > 1 (rev 07) > 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 1 (rev 07) > 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 1 (rev 07) > 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 0 (rev 07) > 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 1 (rev 07) > 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 2 (rev 07) > 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 3 (rev 07) > 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt > Control Registers (rev 07) > 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore > and Scratchpad Configuration Registers (rev 07) > 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller System Address Decoder 0 (rev 07) > 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System > Address Decoder (rev 07) > 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller System Address Decoder 1 (rev 07) > 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor > Home Agent (rev 07) > 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 > Processor Home Agent Performance Monitoring (rev 07) > 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Registers (rev 07) > 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller RAS Registers (rev 07) > 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 0 (rev 07) > 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 1 (rev 07) > 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 2 (rev 07) > 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 3 (rev 07) > 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 4 (rev 07) > 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) > 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) > 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 0 (rev 07) > 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 1 (rev 07) > 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) > 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) > 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 2 (rev 07) > 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 3 (rev 07) > 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO > (rev 07) > 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe > (rev 07) > 7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring > to PCI Express Performance Monitor (rev 07) > 7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 > QuickPath Interconnect Agent Ring Registers (rev 07) > 7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring > to QuickPath Interconnect Link 0 Performance Monitor (rev 07) > 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 1 Performance Monitor (rev 07) > 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI > Express Mode (rev 07) > 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 1a (rev 07) > 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 2a (rev 07) > 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 3a in PCI Express Mode (rev 07) > 80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address > Map, VTd_Misc, System Management (rev 07) > 80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control > Status and Global Errors (rev 07) > 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) > 83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee > ATI Tahiti XT [Radeon HD 7970] > 83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT > HDMI Audio [Radeon HD 7970 Series] > ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > 0 (rev 07) > ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 0 (rev 07) > ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 0 (rev 07) > ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > 1 (rev 07) > ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 1 (rev 07) > ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 1 (rev 07) > ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 0 (rev 07) > ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 1 (rev 07) > ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 2 (rev 07) > ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 3 (rev 07) > ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt > Control Registers (rev 07) > ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore > and Scratchpad Configuration Registers (rev 07) > ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller System Address Decoder 0 (rev 07) > ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System > Address Decoder (rev 07) > ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller System Address Decoder 1 (rev 07) > ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor > Home Agent (rev 07) > ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 > Processor Home Agent Performance Monitoring (rev 07) > ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Registers (rev 07) > ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller RAS Registers (rev 07) > ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 0 (rev 07) > ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 1 (rev 07) > ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 2 (rev 07) > ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 3 (rev 07) > ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 4 (rev 07) > ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) > ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) > ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 0 (rev 07) > ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 1 (rev 07) > ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) > ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) > ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 2 (rev 07) > ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 3 (rev 07) > ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO > (rev 07) > ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe > (rev 07) > ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring > to PCI Express Performance Monitor (rev 07) > ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 > QuickPath Interconnect Agent Ring Registers (rev 07) > ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring > to QuickPath Interconnect Link 0 Performance Monitor (rev 07) > ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 1 Performance Monitor (rev 07) > > ############################################################################################################## > > lspci -tv > > ############################################################################################################## > > -+-[0000:ff]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 > | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 > | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 > | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 > | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 > | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 > | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control > Unit 0 > | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control > Unit 1 > | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control > Unit 2 > | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control > Unit 3 > | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt > Control Registers > | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and > Scratchpad Configuration Registers > | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller System Address Decoder 0 > | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address > Decoder > | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller System Address Decoder 1 > | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home > Agent > | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home > Agent Performance Monitoring > | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Registers > | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller RAS Registers > | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 0 > | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 1 > | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 2 > | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 3 > | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 4 > | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 0 > | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 1 > | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 0 > | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 1 > | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 2 > | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 3 > | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 2 > | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 3 > | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO > | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe > | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI > Express Performance Monitor > | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath > Interconnect Agent Ring Registers > | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 0 Performance Monitor > | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 1 Performance Monitor > +-[0000:80]-+-00.0-[81]-- > | +-01.0-[82]-- > | +-02.0-[83]--+-00.0 Advanced Micro Devices [AMD] nee ATI > Tahiti XT [Radeon HD 7970] > | | \-00.1 Advanced Micro Devices [AMD] nee ATI > Tahiti XT HDMI Audio [Radeon HD 7970 Series] > | +-03.0-[84]-- > | +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, > VTd_Misc, System Management > | +-05.2 Intel Corporation Xeon E5/Core i7 Control Status > and Global Errors > | \-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC > +-[0000:7f]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 > | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 > | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 > | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 > | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 > | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 > | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control > Unit 0 > | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control > Unit 1 > | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control > Unit 2 > | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control > Unit 3 > | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt > Control Registers > | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and > Scratchpad Configuration Registers > | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller System Address Decoder 0 > | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address > Decoder > | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller System Address Decoder 1 > | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home > Agent > | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home > Agent Performance Monitoring > | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Registers > | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller RAS Registers > | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 0 > | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 1 > | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 2 > | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 3 > | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 4 > | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 0 > | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 1 > | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 0 > | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 1 > | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 2 > | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 3 > | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 2 > | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 3 > | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO > | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe > | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI > Express Performance Monitor > | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath > Interconnect Agent Ring Registers > | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 0 Performance Monitor > | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 1 Performance Monitor > \-[0000:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 > +-01.0-[01]-- > +-01.1-[02]-- > +-02.0-[03]--+-00.0 Advanced Micro Devices [AMD] nee ATI > Tahiti XT [Radeon HD 7970] > | \-00.1 Advanced Micro Devices [AMD] nee ATI > Tahiti XT HDMI Audio [Radeon HD 7970 Series] > +-03.0-[04]-- > +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, > VTd_Misc, System Management > +-05.2 Intel Corporation Xeon E5/Core i7 Control Status > and Global Errors > +-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC > +-11.0-[05]----00.0 Intel Corporation C602 chipset > 4-Port SATA Storage Control Unit > +-16.0 Intel Corporation C600/X79 series chipset MEI > Controller #1 > +-16.1 Intel Corporation C600/X79 series chipset MEI > Controller #2 > +-1a.0 Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #2 > +-1b.0 Intel Corporation C600/X79 series chipset High > Definition Audio Controller > +-1c.0-[06]----00.0 Intel Corporation 82574L Gigabit > Network Connection > +-1c.1-[07]----00.0 Intel Corporation 82574L Gigabit > Network Connection > +-1c.2-[08]----00.0 ASMedia Technology Inc. ASM1042 > SuperSpeed USB Host Controller > +-1c.3-[09]----00.0 ASMedia Technology Inc. ASM1042 > SuperSpeed USB Host Controller > +-1c.4-[0a]----00.0 Marvell Technology Group Ltd. Device > 9230 > +-1c.6-[0b]----00.0 VIA Technologies, Inc. VT6315 Series > Firewire Controller > +-1d.0 Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #1 > +-1e.0-[0c]-- > +-1f.0 Intel Corporation C600/X79 series chipset LPC > Controller > +-1f.2 Intel Corporation C600/X79 series chipset 6-Port > SATA AHCI Controller > \-1f.3 Intel Corporation C600/X79 series chipset SMBus > Host Controller > > ############################################################################################################## > > I'm going to try passing through both cards and see if that works as > well as passing through just the one but with only one card present. > I've had a dig for the thread your talking about but I cannot find > it. If anybody else knows if it still exists somewhere I'd be > grateful if you could let me know. > > Thanks again for your help. > > Matt > > On 11/03/2013 18:16, Peter Maloney wrote: >> Ah, because you have 2 cpus and 2 cards, can you post output of >> "lspci -tv" and "lspci"? There was one guy who could pass through one >> card, but when he physically added the 2nd card in the machine, the >> same config with the first card wouldn't work any more because the 2 >> cards were on the same PCI bridge. And he could pass through both and >> have them work, but not just one of them at a time. (I have since >> cleaned out my email box, and so I can't find the old thread) >> >> So you see on my system, the "02.0" bridge is separate from "0c.0", >> so I don't have a problem. >> >> -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI to >> PCI bridge (external gfx0 port B) >> +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O >> Memory Management Unit (IOMMU) >> +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI RV370 5B60 [Radeon X300 (PCIE)] >> | \-00.1 Advanced Micro Devices [AMD] nee ATI >> RV370 [Radeon X300SE] >> +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB 3.0 >> Host Controller >> +-0a.0-[03]----00.0 Marvell Technology Group Ltd. >> 88SE9172 SATA 6Gb/s Controller >> +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Juniper XT [AMD Radeon HD 6000 Series] >> | \-00.1 Advanced Micro Devices [AMD] nee ATI >> Juniper HDMI Audio [Radeon HD 5700 Series] >> >> >> *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 PCI >> to PCI bridge (PCI express gpp port B) >> 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to >> PCI bridge (PCI express gpp port H) >> 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to >> PCI bridge (external gfx1 port A) >> *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 >> >> >> >> On 03/11/2013 06:45 PM, Matthew Dean wrote: >>> That was a good suggestion, I've just tried passing through a USB >>> controller and that worked fine. The driver installed correctly and >>> I can use devices attached to the relevant ports. The problem >>> therefore seems to be to do with gpu passthrough specifically. I'm >>> just going to describe my system and some settings I have in the >>> bios as this is starting to feel like a system specific problem. >>> The system is >>> >>> Asus Z9PE-D8 WS motherboard (chipset is intel C602) >>> Dual Xeon 2620 >>> 64 GB non-ecc memory >>> Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm >>> trying to pass through) >>> >>> In the bios I have vt-d enabled. I also have sub-feature settings >>> for "Coherency Support" and "ATS Support" which are disabled by >>> default. I've tried all combinations of these enabled and >>> disabled. If I enable "ATS Support" I do however have to add the >>> option "iommu=no-qinval,no-intremap" to the xen boot otherwise the >>> system hangs as per this thread >>> . >>> If the problem is to no with these options then I think I have a >>> problem. >>> >>> Has anybody got any thoughts? >>> >>> Matt >>> >>> On 11/03/2013 14:57, Peter Maloney wrote: >>>> Did you try other devices, such as your onboard sound card, your >>>> onboard USB controllers, etc.? Maybe your board doesn't do >>>> passthrough properly. >>>> >>>> Or did you try another PCIe port for the card? Maybe there are bugs >>>> where the addresses overlap with some other device, but in another >>>> slot it wouldn't happen. >>>> >>>> >>>> On 2013-03-11 14:48, Matthew Dean wrote: >>>>> First of all, thank you for the suggestions. I've now >>>>> re-installed windows and I've tried driver versions 12.3, 12.8 and >>>>> 13.1 all with and without the CCC as I read in various places that >>>>> it can cause problems. For 13.1 I never get anywhere close as per >>>>> my previous messages. For 12.3 and 12.8 I at least get a BSOD, >>>>> >>>>> ####################################################################### >>>>> >>>>> A problem has been detected ... >>>>> >>>>> Attempt to reset the display driver and recover from timeout failed. >>>>> >>>>> If this is ... >>>>> >>>>> Techinal information: >>>>> >>>>> *** STOP: 0x00000116 >>>>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>>>> >>>>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>>>> FFFFF88003D8E000, Datestamp 4f597fca >>>>> >>>>> ####################################################################### >>>>> >>>>> Does anybody have any further ideas? >>>>> >>>>> Matt >>>>> >>>>> On 07/03/2013 21:42, John Sherwood wrote: >>>>>> (and I should probably mention that it has been my experience >>>>>> that that is the expected and correct behavior) >>>>>> >>>>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>>>> > wrote: >>>>>> >>>>>> Having the windows logo freeze in the VNC window has been my >>>>>> experience with GPU passthrough as well. >>>>>> >>>>>> >>>>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I believe that the Windows logo freezing in the vnc >>>>>> window is normal behaviour when secondary GPU passthrough >>>>>> is working as it should, since the display should be >>>>>> handed over to the GPU. At least that was the case before >>>>>> when I was passing through a HD6850 card as secondary to >>>>>> win7 using xl. But you should expect output on the GPU, >>>>>> of course. >>>>>> >>>>>> Have you tried different versions of the catalyst driver? >>>>>> I think that some users have reported problems with the >>>>>> latest one (13-something). >>>>>> >>>>>> Regards, >>>>>> Andreas >>>>>> >>>>>> 2013/3/7 Matthew Dean >>>>> > >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I've managed to get a windows 7 x64 hvm to boot and >>>>>> install and I'm now looking to pass through a HD 7970 >>>>>> as a secondary GPU. in order to prepare the devices >>>>>> for passthrough I've used >>>>>> >>>>>> xl pci-assignable-add 83:00.0 >>>>>> xl pci-assignable-add 83:00.1 >>>>>> >>>>>> Where I've identified the device pci ids using lspci. >>>>>> This works fine and the devices appear when I call >>>>>> 'xl pci-assignable-list'. After adding them to the vm >>>>>> config (see below) I was able to get the vm to boot >>>>>> and the devices appeared in device manager. >>>>>> Installing the ATI drivers however has meant that on >>>>>> further boots the machine never gets past the >>>>>> windows logo in the VNC window and no output is >>>>>> generated from the ATI card. It simply freezes there >>>>>> and the only way I can get back into windows is via >>>>>> safe mode, even after uninstalling the ATI software. >>>>>> >>>>>> Has anybody else experienced similar issues or have >>>>>> any advice as to how to get this to work? I'm a bit >>>>>> stumped and the wiki implies that this should 'just >>>>>> work'. >>>>>> >>>>>> Thank you in advance for any help. >>>>>> >>>>>> Matt >>>>>> >>>>>> Here is my machine config >>>>>> >>>>>> ########################################################### >>>>>> >>>>>> builder='hvm' >>>>>> memory = 2048 >>>>>> name = 'Windows7Test' >>>>>> >>>>>> vcpus=4 >>>>>> pae=1 >>>>>> acpi=1 >>>>>> apic=1 >>>>>> >>>>>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>>>> pci = [ '83:00.0' , '83:00.1' ] >>>>>> >>>>>> on_poweroff = 'destroy' >>>>>> on_reboot = 'restart' >>>>>> on_crash = 'destroy' >>>>>> >>>>>> boot='cd' >>>>>> >>>>>> sdl=0 >>>>>> vnc=1 >>>>>> vncconsole=0 >>>>>> vncpasswd='' >>>>>> vnclisten='172.24.226.84' >>>>>> >>>>>> stdvga=0 >>>>>> >>>>>> serial='pty' >>>>>> usbdevice='tablet' >>>>>> >>>>>> gfx_passthru=0 >>>>>> pci_power_mgmt=1 >>>>>> xen_platform_pci=1 >>>>>> pci_msitranslate=1 >>>>>> viridian=1 >>>>>> hpet=1 >>>>>> >>>>>> ############################################################ >>>>>> >>>>>> And the vm produces the following qemu log in >>>>>> /var/log/xen/ >>>>>> >>>>>> ############################################################ >>>>>> >>>>>> domid: 4 >>>>>> -videoram option does not work with cirrus vga device >>>>>> model. Videoram set to 4M. >>>>>> Strip off blktap sub-type prefix to >>>>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>>>> Using file /xen-guests/img/windows7Test.img in >>>>>> read-write mode >>>>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>>>> Watching /local/domain/0/device-model/4/command >>>>>> Watching /local/domain/4/cpu >>>>>> char device redirected to /dev/pts/3 >>>>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>>>> shared page at pfn feffd >>>>>> buffered io page at pfn feffb >>>>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>>>> 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/4/xen_extended_power_mgmt): >>>>>> read error >>>>>> 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. >>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>> count: 0, size: 0 >>>>>> xs_read(/local/domain/4/log-throttling): read error >>>>>> qemu: ignoring not-understood drive >>>>>> `/local/domain/4/log-throttling' >>>>>> medium change watch on >>>>>> `/local/domain/4/log-throttling' - unknown device, >>>>>> ignored >>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>> count: 0, size: 0 >>>>>> dm-command: hot insert pass-through pci dev >>>>>> register_real_device: Assigning real physical device >>>>>> 83:00.0 ... >>>>>> register_real_device: Enable MSI translation via per >>>>>> device option >>>>>> register_real_device: Enable power management >>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>> 0x83:0x0.0x0 >>>>>> pt_register_regions: IO region registered >>>>>> (size=0x10000000 base_addr=0xe000000c) >>>>>> pt_register_regions: IO region registered >>>>>> (size=0x00040000 base_addr=0xf0000004) >>>>>> pt_register_regions: IO region registered >>>>>> (size=0x00000100 base_addr=0x0000f001) >>>>>> pt_register_regions: Expansion ROM registered >>>>>> (size=0x00020000 base_addr=0xf0040000) >>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>> pci_intx: intx=1 >>>>>> register_real_device: Real physical device 83:00.0 >>>>>> registered successfuly! >>>>>> IRQ type = MSI-INTx >>>>>> dm-command: hot insert pass-through pci dev >>>>>> register_real_device: Assigning real physical device >>>>>> 83:00.1 ... >>>>>> register_real_device: Enable MSI translation via per >>>>>> device option >>>>>> register_real_device: Enable power management >>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>> 0x83:0x0.0x1 >>>>>> pt_register_regions: IO region registered >>>>>> (size=0x00004000 base_addr=0xf0060004) >>>>>> pt_msi_setup: msi mapped with pirq 66 >>>>>> pci_intx: intx=2 >>>>>> register_real_device: Real physical device 83:00.1 >>>>>> registered successfuly! >>>>>> IRQ type = MSI-INTx >>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=1 >>>>>> cirrus vga map change while on lfb mode >>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=1 >>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=1 >>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>> index=4 first_map=1 >>>>>> 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. >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=0 >>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>> index=4 first_map=0 >>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=0 >>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>> index=4 first_map=0 >>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=0 >>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>> index=4 first_map=0 >>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=0 >>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>> index=4 first_map=0 >>>>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>>>> MSI-INTx translation >>>>>> pci_intx: intx=1 >>>>>> pt_msi_disable: Unmap msi with pirq 67 >>>>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags >>>>>> 130f >>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=0 >>>>>> >>>>>> ###################################################################### >>>>>> >>>>>> _____________________ >>>>>> --------------000406000300080301090806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Okay that is enormous output :D

And I'm not sure what to say about it... hopefully someone else reading it can read it better than I can.

Your bridges:

00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)

Your GPUs:
...
  +-[0000:80]-+-00.0-[81]--
  |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
   |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
  \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
              +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
              |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]

So you would be fine with PCI bridges if that 80 vs 00 is really different bridges and not just same ones seen by different CPUSs.

I can look at many older Xeons and they all show just one set of bridges, and one very new one (newer socket) has the same thing as yours. But I don't use IOMMU on those, so I don't know what effect it has.

I kinda think they are the same bridge, which would be bad. I don't know how to test it... pull out a CPU? ;) find some other detail that has IDs? disable one in the bios (unlikely)? or you could test this by passing through both cards to the same domu... This would be a good test (and matches what the other thread was about... his worked with passing both through)




On 2013-03-12 11:32, Matthew Dean wrote:
As requested,

lspci

##############################################################################################################

00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07)
00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06)
00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05)
00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05)
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06)
00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06)
00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6)
00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6)
00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6)
00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6)
00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6)
00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06)
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06)
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10)
0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01)
7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07)
80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)

##############################################################################################################

lspci -tv

##############################################################################################################

-+-[0000:ff]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-00.0-[81]--
 |           +-01.0-[82]--
 |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
 |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
 |           +-03.0-[84]--
 |           +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
 |           \-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
             +-01.0-[01]--
             +-01.1-[02]--
             +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
             |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
             +-03.0-[04]--
             +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
             +-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
             +-11.0-[05]----00.0  Intel Corporation C602 chipset 4-Port SATA Storage Control Unit
             +-16.0  Intel Corporation C600/X79 series chipset MEI Controller #1
             +-16.1  Intel Corporation C600/X79 series chipset MEI Controller #2
             +-1a.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2
             +-1b.0  Intel Corporation C600/X79 series chipset High Definition Audio Controller
             +-1c.0-[06]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.1-[07]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.2-[08]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.3-[09]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.4-[0a]----00.0  Marvell Technology Group Ltd. Device 9230
             +-1c.6-[0b]----00.0  VIA Technologies, Inc. VT6315 Series Firewire Controller
             +-1d.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1
             +-1e.0-[0c]--
             +-1f.0  Intel Corporation C600/X79 series chipset LPC Controller
             +-1f.2  Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation C600/X79 series chipset SMBus Host Controller

##############################################################################################################

I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present.  I've had a dig for the thread your talking about but I cannot find it.  If anybody else knows if it still exists somewhere I'd be grateful if you could let me know.

Thanks again for your help.

Matt

On 11/03/2013 18:16, Peter Maloney wrote:
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_____________________

--------------000406000300080301090806-- --===============6399286018734657788== 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 --===============6399286018734657788==-- From xen-users-bounces@lists.xen.org Tue Mar 12 11:42:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 11:42: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 1UFNaS-0000HI-Io; Tue, 12 Mar 2013 11:41:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFNaP-0000H0-Pr for xen-users@lists.xen.org; Tue, 12 Mar 2013 11:41:42 +0000 Received: from [85.158.139.211:63787] by server-14.bemta-5.messagelabs.com id B4/41-13158-5741F315; Tue, 12 Mar 2013 11:41:41 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-14.tower-206.messagelabs.com!1363088493!19020033!1 X-Originating-IP: [212.227.17.10] X-SpamReason: No, hits=3.2 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjE3LjEwID0+IDY3OTMx\n, BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4376 invoked from network); 12 Mar 2013 11:41:33 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.17.10) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 11:41:33 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lbh4l-1Ucw9T3KMV-00l2rs; Tue, 12 Mar 2013 12:41:28 +0100 Message-ID: <513F1467.2010202@brockmann-consult.de> Date: Tue, 12 Mar 2013 12:41:27 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Matthew Dean References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> <513F0426.1080808@cam.ac.uk> In-Reply-To: <513F0426.1080808@cam.ac.uk> X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:VuK6USacJfARH1mj+rNa7u2Rq8BjBhQ5C3IFvI+41md UmjAJXwVtc/JLkUvohwYCphXS8fHVPlkQIf2UxSn+iIvyeFbJj 2oYLku+mYidrSqVIi+UeN5p88cq33+JMvU3FA+6JfPkbKvmA9J xSGqhXzxpW590GML2PnymwgPpzOC9X9z0PTgUas/dpxgrdQo5e ghpSbJ2D90Li0nCJMo2+4Iktffdu+baqGCJueAioaYgIrcM/0U hJAvAwh8nPPVNx0VQ1EKDCf3jPfmKAVNGVLI9tYRnUSw0C0D+a 6OTy0aOAZvIlc8wmBvIsUSGl/Y5+Xkfq5CqbyN0784DUWugw4a 6F5DuE1U3G3m0HRraXqBAGIh6g+3svVPa+qdpZUfk Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============6399286018734657788==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============6399286018734657788== Content-Type: multipart/alternative; boundary="------------000406000300080301090806" This is a multi-part message in MIME format. --------------000406000300080301090806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Okay that is enormous output :D And I'm not sure what to say about it... hopefully someone else reading it can read it better than I can. Your bridges: *00:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) *80:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) Your GPUs: ... +-[0000:*80*]-+-00.0-[81]-- | +-*02.0*-[83]--+-00.0 Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] | | \-00.1 Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] \-[0000:*00*]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 +-*02.0*-[03]--+-00.0 Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970] | \-00.1 Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] So you would be fine with PCI bridges if that 80 vs 00 is really different bridges and not just same ones seen by different CPUSs. I can look at many older Xeons and they all show just one set of bridges, and one very new one (newer socket) has the same thing as yours. But I don't use IOMMU on those, so I don't know what effect it has. I kinda think they are the same bridge, which would be bad. I don't know how to test it... pull out a CPU? ;) find some other detail that has IDs? disable one in the bios (unlikely)? or you could test this by passing through both cards to the same domu... This would be a good test (and matches what the other thread was about... his worked with passing both through) On 2013-03-12 11:32, Matthew Dean wrote: > As requested, > > lspci > > ############################################################################################################## > > 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) > 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 1a (rev 07) > 00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 1b (rev 07) > 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 2a (rev 07) > 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 3a in PCI Express Mode (rev 07) > 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address > Map, VTd_Misc, System Management (rev 07) > 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control > Status and Global Errors (rev 07) > 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) > 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Virtual Root Port (rev 06) > 00:16.0 Communication controller: Intel Corporation C600/X79 series > chipset MEI Controller #1 (rev 05) > 00:16.1 Communication controller: Intel Corporation C600/X79 series > chipset MEI Controller #2 (rev 05) > 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #2 (rev 06) > 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High > Definition Audio Controller (rev 06) > 00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 1 (rev b6) > 00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 2 (rev b6) > 00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 3 (rev b6) > 00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 4 (rev b6) > 00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 5 (rev b6) > 00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI > Express Root Port 7 (rev b6) > 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #1 (rev 06) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) > 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC > Controller (rev 06) > 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset > 6-Port SATA AHCI Controller (rev 06) > 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host > Controller (rev 06) > 03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee > ATI Tahiti XT [Radeon HD 7970] > 03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT > HDMI Audio [Radeon HD 7970 Series] > 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 > chipset 4-Port SATA Storage Control Unit (rev 06) > 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB > Host Controller > 09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB > Host Controller > 0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 > (rev 10) > 0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series > Firewire Controller (rev 01) > 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > 0 (rev 07) > 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 0 (rev 07) > 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 0 (rev 07) > 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > 1 (rev 07) > 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 1 (rev 07) > 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 1 (rev 07) > 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 0 (rev 07) > 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 1 (rev 07) > 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 2 (rev 07) > 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 3 (rev 07) > 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt > Control Registers (rev 07) > 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore > and Scratchpad Configuration Registers (rev 07) > 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller System Address Decoder 0 (rev 07) > 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System > Address Decoder (rev 07) > 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller System Address Decoder 1 (rev 07) > 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor > Home Agent (rev 07) > 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 > Processor Home Agent Performance Monitoring (rev 07) > 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Registers (rev 07) > 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller RAS Registers (rev 07) > 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 0 (rev 07) > 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 1 (rev 07) > 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 2 (rev 07) > 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 3 (rev 07) > 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 4 (rev 07) > 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) > 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) > 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 0 (rev 07) > 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 1 (rev 07) > 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) > 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) > 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 2 (rev 07) > 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 3 (rev 07) > 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO > (rev 07) > 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe > (rev 07) > 7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring > to PCI Express Performance Monitor (rev 07) > 7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 > QuickPath Interconnect Agent Ring Registers (rev 07) > 7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring > to QuickPath Interconnect Link 0 Performance Monitor (rev 07) > 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 1 Performance Monitor (rev 07) > 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI > Express Mode (rev 07) > 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 1a (rev 07) > 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 2a (rev 07) > 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express > Root Port 3a in PCI Express Mode (rev 07) > 80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address > Map, VTd_Misc, System Management (rev 07) > 80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control > Status and Global Errors (rev 07) > 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) > 83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee > ATI Tahiti XT [Radeon HD 7970] > 83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT > HDMI Audio [Radeon HD 7970 Series] > ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > 0 (rev 07) > ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 0 (rev 07) > ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 0 (rev 07) > ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > 1 (rev 07) > ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 1 (rev 07) > ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link > Reut 1 (rev 07) > ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 0 (rev 07) > ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 1 (rev 07) > ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 2 (rev 07) > ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power > Control Unit 3 (rev 07) > ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt > Control Registers (rev 07) > ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore > and Scratchpad Configuration Registers (rev 07) > ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller System Address Decoder 0 (rev 07) > ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System > Address Decoder (rev 07) > ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast > Register 0 (rev 07) > ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller System Address Decoder 1 (rev 07) > ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor > Home Agent (rev 07) > ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 > Processor Home Agent Performance Monitoring (rev 07) > ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Registers (rev 07) > ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller RAS Registers (rev 07) > ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 0 (rev 07) > ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 1 (rev 07) > ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 2 (rev 07) > ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 3 (rev 07) > ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Target Address Decoder 4 (rev 07) > ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) > ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) > ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 0 (rev 07) > ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 1 (rev 07) > ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) > ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) > ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 2 (rev 07) > ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 > Integrated Memory Controller ERROR Registers 3 (rev 07) > ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO > (rev 07) > ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe > (rev 07) > ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring > to PCI Express Performance Monitor (rev 07) > ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 > QuickPath Interconnect Agent Ring Registers (rev 07) > ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring > to QuickPath Interconnect Link 0 Performance Monitor (rev 07) > ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 1 Performance Monitor (rev 07) > > ############################################################################################################## > > lspci -tv > > ############################################################################################################## > > -+-[0000:ff]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 > | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 > | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 > | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 > | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 > | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 > | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control > Unit 0 > | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control > Unit 1 > | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control > Unit 2 > | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control > Unit 3 > | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt > Control Registers > | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and > Scratchpad Configuration Registers > | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller System Address Decoder 0 > | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address > Decoder > | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller System Address Decoder 1 > | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home > Agent > | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home > Agent Performance Monitoring > | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Registers > | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller RAS Registers > | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 0 > | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 1 > | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 2 > | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 3 > | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 4 > | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 0 > | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 1 > | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 0 > | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 1 > | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 2 > | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 3 > | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 2 > | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 3 > | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO > | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe > | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI > Express Performance Monitor > | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath > Interconnect Agent Ring Registers > | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 0 Performance Monitor > | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 1 Performance Monitor > +-[0000:80]-+-00.0-[81]-- > | +-01.0-[82]-- > | +-02.0-[83]--+-00.0 Advanced Micro Devices [AMD] nee ATI > Tahiti XT [Radeon HD 7970] > | | \-00.1 Advanced Micro Devices [AMD] nee ATI > Tahiti XT HDMI Audio [Radeon HD 7970 Series] > | +-03.0-[84]-- > | +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, > VTd_Misc, System Management > | +-05.2 Intel Corporation Xeon E5/Core i7 Control Status > and Global Errors > | \-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC > +-[0000:7f]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 > | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 > | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 > | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 > | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 > | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 > | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control > Unit 0 > | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control > Unit 1 > | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control > Unit 2 > | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control > Unit 3 > | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt > Control Registers > | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and > Scratchpad Configuration Registers > | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller System Address Decoder 0 > | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address > Decoder > | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 > | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller System Address Decoder 1 > | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home > Agent > | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home > Agent Performance Monitoring > | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Registers > | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller RAS Registers > | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 0 > | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 1 > | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 2 > | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 3 > | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Target Address Decoder 4 > | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 0 > | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 1 > | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 0 > | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 1 > | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 2 > | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller Channel 0-3 Thermal Control 3 > | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 2 > | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated > Memory Controller ERROR Registers 3 > | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO > | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe > | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI > Express Performance Monitor > | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath > Interconnect Agent Ring Registers > | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 0 Performance Monitor > | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to > QuickPath Interconnect Link 1 Performance Monitor > \-[0000:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 > +-01.0-[01]-- > +-01.1-[02]-- > +-02.0-[03]--+-00.0 Advanced Micro Devices [AMD] nee ATI > Tahiti XT [Radeon HD 7970] > | \-00.1 Advanced Micro Devices [AMD] nee ATI > Tahiti XT HDMI Audio [Radeon HD 7970 Series] > +-03.0-[04]-- > +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, > VTd_Misc, System Management > +-05.2 Intel Corporation Xeon E5/Core i7 Control Status > and Global Errors > +-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC > +-11.0-[05]----00.0 Intel Corporation C602 chipset > 4-Port SATA Storage Control Unit > +-16.0 Intel Corporation C600/X79 series chipset MEI > Controller #1 > +-16.1 Intel Corporation C600/X79 series chipset MEI > Controller #2 > +-1a.0 Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #2 > +-1b.0 Intel Corporation C600/X79 series chipset High > Definition Audio Controller > +-1c.0-[06]----00.0 Intel Corporation 82574L Gigabit > Network Connection > +-1c.1-[07]----00.0 Intel Corporation 82574L Gigabit > Network Connection > +-1c.2-[08]----00.0 ASMedia Technology Inc. ASM1042 > SuperSpeed USB Host Controller > +-1c.3-[09]----00.0 ASMedia Technology Inc. ASM1042 > SuperSpeed USB Host Controller > +-1c.4-[0a]----00.0 Marvell Technology Group Ltd. Device > 9230 > +-1c.6-[0b]----00.0 VIA Technologies, Inc. VT6315 Series > Firewire Controller > +-1d.0 Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #1 > +-1e.0-[0c]-- > +-1f.0 Intel Corporation C600/X79 series chipset LPC > Controller > +-1f.2 Intel Corporation C600/X79 series chipset 6-Port > SATA AHCI Controller > \-1f.3 Intel Corporation C600/X79 series chipset SMBus > Host Controller > > ############################################################################################################## > > I'm going to try passing through both cards and see if that works as > well as passing through just the one but with only one card present. > I've had a dig for the thread your talking about but I cannot find > it. If anybody else knows if it still exists somewhere I'd be > grateful if you could let me know. > > Thanks again for your help. > > Matt > > On 11/03/2013 18:16, Peter Maloney wrote: >> Ah, because you have 2 cpus and 2 cards, can you post output of >> "lspci -tv" and "lspci"? There was one guy who could pass through one >> card, but when he physically added the 2nd card in the machine, the >> same config with the first card wouldn't work any more because the 2 >> cards were on the same PCI bridge. And he could pass through both and >> have them work, but not just one of them at a time. (I have since >> cleaned out my email box, and so I can't find the old thread) >> >> So you see on my system, the "02.0" bridge is separate from "0c.0", >> so I don't have a problem. >> >> -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI to >> PCI bridge (external gfx0 port B) >> +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O >> Memory Management Unit (IOMMU) >> +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI RV370 5B60 [Radeon X300 (PCIE)] >> | \-00.1 Advanced Micro Devices [AMD] nee ATI >> RV370 [Radeon X300SE] >> +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB 3.0 >> Host Controller >> +-0a.0-[03]----00.0 Marvell Technology Group Ltd. >> 88SE9172 SATA 6Gb/s Controller >> +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Juniper XT [AMD Radeon HD 6000 Series] >> | \-00.1 Advanced Micro Devices [AMD] nee ATI >> Juniper HDMI Audio [Radeon HD 5700 Series] >> >> >> *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 PCI >> to PCI bridge (PCI express gpp port B) >> 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to >> PCI bridge (PCI express gpp port H) >> 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to >> PCI bridge (external gfx1 port A) >> *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 >> >> >> >> On 03/11/2013 06:45 PM, Matthew Dean wrote: >>> That was a good suggestion, I've just tried passing through a USB >>> controller and that worked fine. The driver installed correctly and >>> I can use devices attached to the relevant ports. The problem >>> therefore seems to be to do with gpu passthrough specifically. I'm >>> just going to describe my system and some settings I have in the >>> bios as this is starting to feel like a system specific problem. >>> The system is >>> >>> Asus Z9PE-D8 WS motherboard (chipset is intel C602) >>> Dual Xeon 2620 >>> 64 GB non-ecc memory >>> Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm >>> trying to pass through) >>> >>> In the bios I have vt-d enabled. I also have sub-feature settings >>> for "Coherency Support" and "ATS Support" which are disabled by >>> default. I've tried all combinations of these enabled and >>> disabled. If I enable "ATS Support" I do however have to add the >>> option "iommu=no-qinval,no-intremap" to the xen boot otherwise the >>> system hangs as per this thread >>> . >>> If the problem is to no with these options then I think I have a >>> problem. >>> >>> Has anybody got any thoughts? >>> >>> Matt >>> >>> On 11/03/2013 14:57, Peter Maloney wrote: >>>> Did you try other devices, such as your onboard sound card, your >>>> onboard USB controllers, etc.? Maybe your board doesn't do >>>> passthrough properly. >>>> >>>> Or did you try another PCIe port for the card? Maybe there are bugs >>>> where the addresses overlap with some other device, but in another >>>> slot it wouldn't happen. >>>> >>>> >>>> On 2013-03-11 14:48, Matthew Dean wrote: >>>>> First of all, thank you for the suggestions. I've now >>>>> re-installed windows and I've tried driver versions 12.3, 12.8 and >>>>> 13.1 all with and without the CCC as I read in various places that >>>>> it can cause problems. For 13.1 I never get anywhere close as per >>>>> my previous messages. For 12.3 and 12.8 I at least get a BSOD, >>>>> >>>>> ####################################################################### >>>>> >>>>> A problem has been detected ... >>>>> >>>>> Attempt to reset the display driver and recover from timeout failed. >>>>> >>>>> If this is ... >>>>> >>>>> Techinal information: >>>>> >>>>> *** STOP: 0x00000116 >>>>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>>>> >>>>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>>>> FFFFF88003D8E000, Datestamp 4f597fca >>>>> >>>>> ####################################################################### >>>>> >>>>> Does anybody have any further ideas? >>>>> >>>>> Matt >>>>> >>>>> On 07/03/2013 21:42, John Sherwood wrote: >>>>>> (and I should probably mention that it has been my experience >>>>>> that that is the expected and correct behavior) >>>>>> >>>>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>>>> > wrote: >>>>>> >>>>>> Having the windows logo freeze in the VNC window has been my >>>>>> experience with GPU passthrough as well. >>>>>> >>>>>> >>>>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I believe that the Windows logo freezing in the vnc >>>>>> window is normal behaviour when secondary GPU passthrough >>>>>> is working as it should, since the display should be >>>>>> handed over to the GPU. At least that was the case before >>>>>> when I was passing through a HD6850 card as secondary to >>>>>> win7 using xl. But you should expect output on the GPU, >>>>>> of course. >>>>>> >>>>>> Have you tried different versions of the catalyst driver? >>>>>> I think that some users have reported problems with the >>>>>> latest one (13-something). >>>>>> >>>>>> Regards, >>>>>> Andreas >>>>>> >>>>>> 2013/3/7 Matthew Dean >>>>> > >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I've managed to get a windows 7 x64 hvm to boot and >>>>>> install and I'm now looking to pass through a HD 7970 >>>>>> as a secondary GPU. in order to prepare the devices >>>>>> for passthrough I've used >>>>>> >>>>>> xl pci-assignable-add 83:00.0 >>>>>> xl pci-assignable-add 83:00.1 >>>>>> >>>>>> Where I've identified the device pci ids using lspci. >>>>>> This works fine and the devices appear when I call >>>>>> 'xl pci-assignable-list'. After adding them to the vm >>>>>> config (see below) I was able to get the vm to boot >>>>>> and the devices appeared in device manager. >>>>>> Installing the ATI drivers however has meant that on >>>>>> further boots the machine never gets past the >>>>>> windows logo in the VNC window and no output is >>>>>> generated from the ATI card. It simply freezes there >>>>>> and the only way I can get back into windows is via >>>>>> safe mode, even after uninstalling the ATI software. >>>>>> >>>>>> Has anybody else experienced similar issues or have >>>>>> any advice as to how to get this to work? I'm a bit >>>>>> stumped and the wiki implies that this should 'just >>>>>> work'. >>>>>> >>>>>> Thank you in advance for any help. >>>>>> >>>>>> Matt >>>>>> >>>>>> Here is my machine config >>>>>> >>>>>> ########################################################### >>>>>> >>>>>> builder='hvm' >>>>>> memory = 2048 >>>>>> name = 'Windows7Test' >>>>>> >>>>>> vcpus=4 >>>>>> pae=1 >>>>>> acpi=1 >>>>>> apic=1 >>>>>> >>>>>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>>>> pci = [ '83:00.0' , '83:00.1' ] >>>>>> >>>>>> on_poweroff = 'destroy' >>>>>> on_reboot = 'restart' >>>>>> on_crash = 'destroy' >>>>>> >>>>>> boot='cd' >>>>>> >>>>>> sdl=0 >>>>>> vnc=1 >>>>>> vncconsole=0 >>>>>> vncpasswd='' >>>>>> vnclisten='172.24.226.84' >>>>>> >>>>>> stdvga=0 >>>>>> >>>>>> serial='pty' >>>>>> usbdevice='tablet' >>>>>> >>>>>> gfx_passthru=0 >>>>>> pci_power_mgmt=1 >>>>>> xen_platform_pci=1 >>>>>> pci_msitranslate=1 >>>>>> viridian=1 >>>>>> hpet=1 >>>>>> >>>>>> ############################################################ >>>>>> >>>>>> And the vm produces the following qemu log in >>>>>> /var/log/xen/ >>>>>> >>>>>> ############################################################ >>>>>> >>>>>> domid: 4 >>>>>> -videoram option does not work with cirrus vga device >>>>>> model. Videoram set to 4M. >>>>>> Strip off blktap sub-type prefix to >>>>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>>>> Using file /xen-guests/img/windows7Test.img in >>>>>> read-write mode >>>>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>>>> Watching /local/domain/0/device-model/4/command >>>>>> Watching /local/domain/4/cpu >>>>>> char device redirected to /dev/pts/3 >>>>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>>>> shared page at pfn feffd >>>>>> buffered io page at pfn feffb >>>>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>>>> 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/4/xen_extended_power_mgmt): >>>>>> read error >>>>>> 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. >>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>> count: 0, size: 0 >>>>>> xs_read(/local/domain/4/log-throttling): read error >>>>>> qemu: ignoring not-understood drive >>>>>> `/local/domain/4/log-throttling' >>>>>> medium change watch on >>>>>> `/local/domain/4/log-throttling' - unknown device, >>>>>> ignored >>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>> count: 0, size: 0 >>>>>> dm-command: hot insert pass-through pci dev >>>>>> register_real_device: Assigning real physical device >>>>>> 83:00.0 ... >>>>>> register_real_device: Enable MSI translation via per >>>>>> device option >>>>>> register_real_device: Enable power management >>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>> 0x83:0x0.0x0 >>>>>> pt_register_regions: IO region registered >>>>>> (size=0x10000000 base_addr=0xe000000c) >>>>>> pt_register_regions: IO region registered >>>>>> (size=0x00040000 base_addr=0xf0000004) >>>>>> pt_register_regions: IO region registered >>>>>> (size=0x00000100 base_addr=0x0000f001) >>>>>> pt_register_regions: Expansion ROM registered >>>>>> (size=0x00020000 base_addr=0xf0040000) >>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>> pci_intx: intx=1 >>>>>> register_real_device: Real physical device 83:00.0 >>>>>> registered successfuly! >>>>>> IRQ type = MSI-INTx >>>>>> dm-command: hot insert pass-through pci dev >>>>>> register_real_device: Assigning real physical device >>>>>> 83:00.1 ... >>>>>> register_real_device: Enable MSI translation via per >>>>>> device option >>>>>> register_real_device: Enable power management >>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>> 0x83:0x0.0x1 >>>>>> pt_register_regions: IO region registered >>>>>> (size=0x00004000 base_addr=0xf0060004) >>>>>> pt_msi_setup: msi mapped with pirq 66 >>>>>> pci_intx: intx=2 >>>>>> register_real_device: Real physical device 83:00.1 >>>>>> registered successfuly! >>>>>> IRQ type = MSI-INTx >>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=1 >>>>>> cirrus vga map change while on lfb mode >>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=1 >>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=1 >>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>> index=4 first_map=1 >>>>>> 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. >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>> register with invalid access size alignment. >>>>>> [Offset:0eh][Length:4] >>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=0 >>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>> index=4 first_map=0 >>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=0 >>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>> index=4 first_map=0 >>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=0 >>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>> index=4 first_map=0 >>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>> len=268435456 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>> len=262144 index=2 first_map=0 >>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>> index=4 first_map=0 >>>>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>>>> MSI-INTx translation >>>>>> pci_intx: intx=1 >>>>>> pt_msi_disable: Unmap msi with pirq 67 >>>>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>> pt_msi_update: Update msi with pirq 67 gvec b0 gflags >>>>>> 130f >>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=0 >>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>> len=16384 index=0 first_map=0 >>>>>> >>>>>> ###################################################################### >>>>>> >>>>>> _____________________ >>>>>> --------------000406000300080301090806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Okay that is enormous output :D

And I'm not sure what to say about it... hopefully someone else reading it can read it better than I can.

Your bridges:

00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)

Your GPUs:
...
  +-[0000:80]-+-00.0-[81]--
  |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
   |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
  \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
              +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
              |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]

So you would be fine with PCI bridges if that 80 vs 00 is really different bridges and not just same ones seen by different CPUSs.

I can look at many older Xeons and they all show just one set of bridges, and one very new one (newer socket) has the same thing as yours. But I don't use IOMMU on those, so I don't know what effect it has.

I kinda think they are the same bridge, which would be bad. I don't know how to test it... pull out a CPU? ;) find some other detail that has IDs? disable one in the bios (unlikely)? or you could test this by passing through both cards to the same domu... This would be a good test (and matches what the other thread was about... his worked with passing both through)




On 2013-03-12 11:32, Matthew Dean wrote:
As requested,

lspci

##############################################################################################################

00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07)
00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06)
00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05)
00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05)
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06)
00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06)
00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6)
00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6)
00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6)
00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6)
00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6)
00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06)
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06)
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10)
0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01)
7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07)
80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)

##############################################################################################################

lspci -tv

##############################################################################################################

-+-[0000:ff]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-00.0-[81]--
 |           +-01.0-[82]--
 |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
 |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
 |           +-03.0-[84]--
 |           +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
 |           \-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
             +-01.0-[01]--
             +-01.1-[02]--
             +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
             |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
             +-03.0-[04]--
             +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
             +-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
             +-11.0-[05]----00.0  Intel Corporation C602 chipset 4-Port SATA Storage Control Unit
             +-16.0  Intel Corporation C600/X79 series chipset MEI Controller #1
             +-16.1  Intel Corporation C600/X79 series chipset MEI Controller #2
             +-1a.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2
             +-1b.0  Intel Corporation C600/X79 series chipset High Definition Audio Controller
             +-1c.0-[06]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.1-[07]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.2-[08]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.3-[09]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.4-[0a]----00.0  Marvell Technology Group Ltd. Device 9230
             +-1c.6-[0b]----00.0  VIA Technologies, Inc. VT6315 Series Firewire Controller
             +-1d.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1
             +-1e.0-[0c]--
             +-1f.0  Intel Corporation C600/X79 series chipset LPC Controller
             +-1f.2  Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation C600/X79 series chipset SMBus Host Controller

##############################################################################################################

I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present.  I've had a dig for the thread your talking about but I cannot find it.  If anybody else knows if it still exists somewhere I'd be grateful if you could let me know.

Thanks again for your help.

Matt

On 11/03/2013 18:16, Peter Maloney wrote:
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_____________________

--------------000406000300080301090806-- --===============6399286018734657788== 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 --===============6399286018734657788==-- From xen-users-bounces@lists.xen.org Tue Mar 12 11:58:09 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 11:58: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 1UFNpS-0001XE-Oo; Tue, 12 Mar 2013 11:57:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFNpQ-0001X2-1M for xen-users@lists.xen.org; Tue, 12 Mar 2013 11:57:12 +0000 Received: from [193.109.254.147:8926] by server-11.bemta-14.messagelabs.com id 6C/33-24840-7181F315; Tue, 12 Mar 2013 11:57:11 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-15.tower-27.messagelabs.com!1363089349!1712046!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19052 invoked from network); 12 Mar 2013 11:55:49 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-15.tower-27.messagelabs.com with SMTP; 12 Mar 2013 11:55:49 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:61727) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UFNnq-0006it-8d (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Tue, 12 Mar 2013 11:55:35 +0000 Message-ID: <513F17AA.6050406@cam.ac.uk> Date: Tue, 12 Mar 2013 11:55:22 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> <513F0426.1080808@cam.ac.uk> <513F1467.2010202@brockmann-consult.de> In-Reply-To: <513F1467.2010202@brockmann-consult.de> Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============9108367519053242777==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============9108367519053242777== Content-Type: multipart/alternative; boundary="------------080301000809030306000709" This is a multi-part message in MIME format. --------------080301000809030306000709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My guess is that they are on different bridges. I've read that for this board if you use only the first CPU socket then you'll only get access to pcie slots 1 through 4. Slots 5, 6 and 7 simply won't work at all. Passing through both cards still does not work but this time I don't get a BSOD, the display simply never turns on. I can hear the fan speed of the card change however at the precise point where the VNC window stops showing any change so there is something going on here. I've just pulled out the card in slot 5 and tried to pass through the one remaining card and that has the same result, with the display never turning on. Matt On 12/03/2013 11:41, Peter Maloney wrote: > Okay that is enormous output :D > > And I'm not sure what to say about it... hopefully someone else > reading it can read it better than I can. > > Your bridges: > > *00:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI > Express Root Port 2a (rev 07) > *80:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI > Express Root Port 2a (rev 07) > > Your GPUs: > ... > +-[0000:*80*]-+-00.0-[81]-- > | +-*02.0*-[83]--+-00.0 Advanced Micro Devices [AMD] nee > ATI Tahiti XT [Radeon HD 7970] > | | \-00.1 Advanced Micro Devices [AMD] nee > ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] > \-[0000:*00*]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 > +-*02.0*-[03]--+-00.0 Advanced Micro Devices [AMD] nee > ATI Tahiti XT [Radeon HD 7970] > | \-00.1 Advanced Micro Devices [AMD] nee > ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] > > So you would be fine with PCI bridges if that 80 vs 00 is really > different bridges and not just same ones seen by different CPUSs. > > I can look at many older Xeons and they all show just one set of > bridges, and one very new one (newer socket) has the same thing as > yours. But I don't use IOMMU on those, so I don't know what effect it has. > > I kinda think they are the same bridge, which would be bad. I don't > know how to test it... pull out a CPU? ;) find some other detail that > has IDs? disable one in the bios (unlikely)? or you could test this by > passing through both cards to the same domu... This would be a good > test (and matches what the other thread was about... his worked with > passing both through) > > > > > On 2013-03-12 11:32, Matthew Dean wrote: >> As requested, >> >> lspci >> >> ############################################################################################################## >> >> 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) >> 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 1a (rev 07) >> 00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 1b (rev 07) >> 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 2a (rev 07) >> 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 3a in PCI Express Mode (rev 07) >> 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address >> Map, VTd_Misc, System Management (rev 07) >> 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control >> Status and Global Errors (rev 07) >> 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) >> 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Virtual Root Port (rev 06) >> 00:16.0 Communication controller: Intel Corporation C600/X79 series >> chipset MEI Controller #1 (rev 05) >> 00:16.1 Communication controller: Intel Corporation C600/X79 series >> chipset MEI Controller #2 (rev 05) >> 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset >> USB2 Enhanced Host Controller #2 (rev 06) >> 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High >> Definition Audio Controller (rev 06) >> 00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 1 (rev b6) >> 00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 2 (rev b6) >> 00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 3 (rev b6) >> 00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 4 (rev b6) >> 00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 5 (rev b6) >> 00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 7 (rev b6) >> 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset >> USB2 Enhanced Host Controller #1 (rev 06) >> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) >> 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC >> Controller (rev 06) >> 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset >> 6-Port SATA AHCI Controller (rev 06) >> 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host >> Controller (rev 06) >> 03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> 03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT >> HDMI Audio [Radeon HD 7970 Series] >> 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 >> chipset 4-Port SATA Storage Control Unit (rev 06) >> 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >> Connection >> 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >> Connection >> 08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed >> USB Host Controller >> 09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed >> USB Host Controller >> 0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 >> (rev 10) >> 0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series >> Firewire Controller (rev 01) >> 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> 0 (rev 07) >> 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 0 (rev 07) >> 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 0 (rev 07) >> 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> 1 (rev 07) >> 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 1 (rev 07) >> 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 1 (rev 07) >> 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 0 (rev 07) >> 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 1 (rev 07) >> 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 2 (rev 07) >> 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 3 (rev 07) >> 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Interrupt Control Registers (rev 07) >> 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Semaphore and Scratchpad Configuration Registers (rev 07) >> 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller System Address Decoder 0 (rev 07) >> 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System >> Address Decoder (rev 07) >> 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller System Address Decoder 1 (rev 07) >> 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Processor Home Agent (rev 07) >> 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 >> Processor Home Agent Performance Monitoring (rev 07) >> 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Registers (rev 07) >> 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller RAS Registers (rev 07) >> 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 0 (rev 07) >> 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 1 (rev 07) >> 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 2 (rev 07) >> 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 3 (rev 07) >> 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 4 (rev 07) >> 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) >> 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) >> 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 0 (rev 07) >> 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 1 (rev 07) >> 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) >> 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) >> 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 2 (rev 07) >> 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 3 (rev 07) >> 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO >> (rev 07) >> 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe >> (rev 07) >> 7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >> to PCI Express Performance Monitor (rev 07) >> 7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 >> QuickPath Interconnect Agent Ring Registers (rev 07) >> 7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >> to QuickPath Interconnect Link 0 Performance Monitor (rev 07) >> 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 1 Performance Monitor (rev 07) >> 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI >> Express Mode (rev 07) >> 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 1a (rev 07) >> 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 2a (rev 07) >> 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 3a in PCI Express Mode (rev 07) >> 80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address >> Map, VTd_Misc, System Management (rev 07) >> 80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control >> Status and Global Errors (rev 07) >> 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) >> 83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> 83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT >> HDMI Audio [Radeon HD 7970 Series] >> ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> 0 (rev 07) >> ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 0 (rev 07) >> ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 0 (rev 07) >> ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> 1 (rev 07) >> ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 1 (rev 07) >> ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 1 (rev 07) >> ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 0 (rev 07) >> ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 1 (rev 07) >> ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 2 (rev 07) >> ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 3 (rev 07) >> ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Interrupt Control Registers (rev 07) >> ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Semaphore and Scratchpad Configuration Registers (rev 07) >> ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller System Address Decoder 0 (rev 07) >> ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System >> Address Decoder (rev 07) >> ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller System Address Decoder 1 (rev 07) >> ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Processor Home Agent (rev 07) >> ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 >> Processor Home Agent Performance Monitoring (rev 07) >> ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Registers (rev 07) >> ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller RAS Registers (rev 07) >> ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 0 (rev 07) >> ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 1 (rev 07) >> ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 2 (rev 07) >> ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 3 (rev 07) >> ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 4 (rev 07) >> ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) >> ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) >> ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 0 (rev 07) >> ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 1 (rev 07) >> ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) >> ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) >> ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 2 (rev 07) >> ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 3 (rev 07) >> ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO >> (rev 07) >> ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe >> (rev 07) >> ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >> to PCI Express Performance Monitor (rev 07) >> ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 >> QuickPath Interconnect Agent Ring Registers (rev 07) >> ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >> to QuickPath Interconnect Link 0 Performance Monitor (rev 07) >> ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 1 Performance Monitor (rev 07) >> >> ############################################################################################################## >> >> lspci -tv >> >> ############################################################################################################## >> >> -+-[0000:ff]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 >> | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >> | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >> | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 >> | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >> | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >> | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 0 >> | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 1 >> | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 2 >> | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 3 >> | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt >> Control Registers >> | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and >> Scratchpad Configuration Registers >> | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller System Address Decoder 0 >> | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address >> Decoder >> | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller System Address Decoder 1 >> | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home >> Agent >> | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home >> Agent Performance Monitoring >> | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Registers >> | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller RAS Registers >> | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 0 >> | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 1 >> | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 2 >> | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 3 >> | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 4 >> | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 0 >> | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 1 >> | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 0 >> | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 1 >> | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 2 >> | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 3 >> | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 2 >> | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 3 >> | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO >> | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe >> | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI >> Express Performance Monitor >> | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath >> Interconnect Agent Ring Registers >> | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 0 Performance Monitor >> | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 1 Performance Monitor >> +-[0000:80]-+-00.0-[81]-- >> | +-01.0-[82]-- >> | +-02.0-[83]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> | | \-00.1 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >> | +-03.0-[84]-- >> | +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, >> VTd_Misc, System Management >> | +-05.2 Intel Corporation Xeon E5/Core i7 Control Status >> and Global Errors >> | \-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC >> +-[0000:7f]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 >> | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >> | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >> | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 >> | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >> | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >> | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 0 >> | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 1 >> | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 2 >> | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 3 >> | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt >> Control Registers >> | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and >> Scratchpad Configuration Registers >> | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller System Address Decoder 0 >> | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address >> Decoder >> | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller System Address Decoder 1 >> | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home >> Agent >> | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home >> Agent Performance Monitoring >> | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Registers >> | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller RAS Registers >> | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 0 >> | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 1 >> | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 2 >> | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 3 >> | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 4 >> | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 0 >> | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 1 >> | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 0 >> | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 1 >> | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 2 >> | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 3 >> | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 2 >> | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 3 >> | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO >> | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe >> | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI >> Express Performance Monitor >> | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath >> Interconnect Agent Ring Registers >> | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 0 Performance Monitor >> | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 1 Performance Monitor >> \-[0000:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 >> +-01.0-[01]-- >> +-01.1-[02]-- >> +-02.0-[03]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> | \-00.1 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >> +-03.0-[04]-- >> +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, >> VTd_Misc, System Management >> +-05.2 Intel Corporation Xeon E5/Core i7 Control Status >> and Global Errors >> +-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC >> +-11.0-[05]----00.0 Intel Corporation C602 chipset >> 4-Port SATA Storage Control Unit >> +-16.0 Intel Corporation C600/X79 series chipset MEI >> Controller #1 >> +-16.1 Intel Corporation C600/X79 series chipset MEI >> Controller #2 >> +-1a.0 Intel Corporation C600/X79 series chipset USB2 >> Enhanced Host Controller #2 >> +-1b.0 Intel Corporation C600/X79 series chipset High >> Definition Audio Controller >> +-1c.0-[06]----00.0 Intel Corporation 82574L Gigabit >> Network Connection >> +-1c.1-[07]----00.0 Intel Corporation 82574L Gigabit >> Network Connection >> +-1c.2-[08]----00.0 ASMedia Technology Inc. ASM1042 >> SuperSpeed USB Host Controller >> +-1c.3-[09]----00.0 ASMedia Technology Inc. ASM1042 >> SuperSpeed USB Host Controller >> +-1c.4-[0a]----00.0 Marvell Technology Group Ltd. >> Device 9230 >> +-1c.6-[0b]----00.0 VIA Technologies, Inc. VT6315 >> Series Firewire Controller >> +-1d.0 Intel Corporation C600/X79 series chipset USB2 >> Enhanced Host Controller #1 >> +-1e.0-[0c]-- >> +-1f.0 Intel Corporation C600/X79 series chipset LPC >> Controller >> +-1f.2 Intel Corporation C600/X79 series chipset 6-Port >> SATA AHCI Controller >> \-1f.3 Intel Corporation C600/X79 series chipset SMBus >> Host Controller >> >> ############################################################################################################## >> >> I'm going to try passing through both cards and see if that works as >> well as passing through just the one but with only one card present. >> I've had a dig for the thread your talking about but I cannot find >> it. If anybody else knows if it still exists somewhere I'd be >> grateful if you could let me know. >> >> Thanks again for your help. >> >> Matt >> >> On 11/03/2013 18:16, Peter Maloney wrote: >>> Ah, because you have 2 cpus and 2 cards, can you post output of >>> "lspci -tv" and "lspci"? There was one guy who could pass through >>> one card, but when he physically added the 2nd card in the machine, >>> the same config with the first card wouldn't work any more because >>> the 2 cards were on the same PCI bridge. And he could pass through >>> both and have them work, but not just one of them at a time. (I have >>> since cleaned out my email box, and so I can't find the old thread) >>> >>> So you see on my system, the "02.0" bridge is separate from "0c.0", >>> so I don't have a problem. >>> >>> -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI to >>> PCI bridge (external gfx0 port B) >>> +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O >>> Memory Management Unit (IOMMU) >>> +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee >>> ATI RV370 5B60 [Radeon X300 (PCIE)] >>> | \-00.1 Advanced Micro Devices [AMD] nee ATI >>> RV370 [Radeon X300SE] >>> +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB 3.0 >>> Host Controller >>> +-0a.0-[03]----00.0 Marvell Technology Group Ltd. >>> 88SE9172 SATA 6Gb/s Controller >>> +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee >>> ATI Juniper XT [AMD Radeon HD 6000 Series] >>> | \-00.1 Advanced Micro Devices [AMD] nee ATI >>> Juniper HDMI Audio [Radeon HD 5700 Series] >>> >>> >>> *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>> to PCI bridge (PCI express gpp port B) >>> 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>> to PCI bridge (PCI express gpp port H) >>> 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>> to PCI bridge (external gfx1 port A) >>> *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 >>> >>> >>> >>> On 03/11/2013 06:45 PM, Matthew Dean wrote: >>>> That was a good suggestion, I've just tried passing through a USB >>>> controller and that worked fine. The driver installed correctly >>>> and I can use devices attached to the relevant ports. The problem >>>> therefore seems to be to do with gpu passthrough specifically. I'm >>>> just going to describe my system and some settings I have in the >>>> bios as this is starting to feel like a system specific problem. >>>> The system is >>>> >>>> Asus Z9PE-D8 WS motherboard (chipset is intel C602) >>>> Dual Xeon 2620 >>>> 64 GB non-ecc memory >>>> Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm >>>> trying to pass through) >>>> >>>> In the bios I have vt-d enabled. I also have sub-feature settings >>>> for "Coherency Support" and "ATS Support" which are disabled by >>>> default. I've tried all combinations of these enabled and >>>> disabled. If I enable "ATS Support" I do however have to add the >>>> option "iommu=no-qinval,no-intremap" to the xen boot otherwise the >>>> system hangs as per this thread >>>> . >>>> If the problem is to no with these options then I think I have a >>>> problem. >>>> >>>> Has anybody got any thoughts? >>>> >>>> Matt >>>> >>>> On 11/03/2013 14:57, Peter Maloney wrote: >>>>> Did you try other devices, such as your onboard sound card, your >>>>> onboard USB controllers, etc.? Maybe your board doesn't do >>>>> passthrough properly. >>>>> >>>>> Or did you try another PCIe port for the card? Maybe there are >>>>> bugs where the addresses overlap with some other device, but in >>>>> another slot it wouldn't happen. >>>>> >>>>> >>>>> On 2013-03-11 14:48, Matthew Dean wrote: >>>>>> First of all, thank you for the suggestions. I've now >>>>>> re-installed windows and I've tried driver versions 12.3, 12.8 >>>>>> and 13.1 all with and without the CCC as I read in various places >>>>>> that it can cause problems. For 13.1 I never get anywhere close >>>>>> as per my previous messages. For 12.3 and 12.8 I at least get a >>>>>> BSOD, >>>>>> >>>>>> ####################################################################### >>>>>> >>>>>> A problem has been detected ... >>>>>> >>>>>> Attempt to reset the display driver and recover from timeout failed. >>>>>> >>>>>> If this is ... >>>>>> >>>>>> Techinal information: >>>>>> >>>>>> *** STOP: 0x00000116 >>>>>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>>>>> >>>>>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>>>>> FFFFF88003D8E000, Datestamp 4f597fca >>>>>> >>>>>> ####################################################################### >>>>>> >>>>>> Does anybody have any further ideas? >>>>>> >>>>>> Matt >>>>>> >>>>>> On 07/03/2013 21:42, John Sherwood wrote: >>>>>>> (and I should probably mention that it has been my experience >>>>>>> that that is the expected and correct behavior) >>>>>>> >>>>>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>>>>> > wrote: >>>>>>> >>>>>>> Having the windows logo freeze in the VNC window has been my >>>>>>> experience with GPU passthrough as well. >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I believe that the Windows logo freezing in the vnc >>>>>>> window is normal behaviour when secondary GPU >>>>>>> passthrough is working as it should, since the display >>>>>>> should be handed over to the GPU. At least that was the >>>>>>> case before when I was passing through a HD6850 card as >>>>>>> secondary to win7 using xl. But you should expect output >>>>>>> on the GPU, of course. >>>>>>> >>>>>>> Have you tried different versions of the catalyst >>>>>>> driver? I think that some users have reported problems >>>>>>> with the latest one (13-something). >>>>>>> >>>>>>> Regards, >>>>>>> Andreas >>>>>>> >>>>>>> 2013/3/7 Matthew Dean >>>>>> > >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I've managed to get a windows 7 x64 hvm to boot and >>>>>>> install and I'm now looking to pass through a HD >>>>>>> 7970 as a secondary GPU. in order to prepare the >>>>>>> devices for passthrough I've used >>>>>>> >>>>>>> xl pci-assignable-add 83:00.0 >>>>>>> xl pci-assignable-add 83:00.1 >>>>>>> >>>>>>> Where I've identified the device pci ids using >>>>>>> lspci. This works fine and the devices appear when >>>>>>> I call 'xl pci-assignable-list'. After adding them >>>>>>> to the vm config (see below) I was able to get the >>>>>>> vm to boot and the devices appeared in device >>>>>>> manager. Installing the ATI drivers however has >>>>>>> meant that on further boots the machine never gets >>>>>>> past the windows logo in the VNC window and no >>>>>>> output is generated from the ATI card. It simply >>>>>>> freezes there and the only way I can get back into >>>>>>> windows is via safe mode, even after uninstalling >>>>>>> the ATI software. >>>>>>> >>>>>>> Has anybody else experienced similar issues or have >>>>>>> any advice as to how to get this to work? I'm a bit >>>>>>> stumped and the wiki implies that this should 'just >>>>>>> work'. >>>>>>> >>>>>>> Thank you in advance for any help. >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> Here is my machine config >>>>>>> >>>>>>> ########################################################### >>>>>>> >>>>>>> builder='hvm' >>>>>>> memory = 2048 >>>>>>> name = 'Windows7Test' >>>>>>> >>>>>>> vcpus=4 >>>>>>> pae=1 >>>>>>> acpi=1 >>>>>>> apic=1 >>>>>>> >>>>>>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>>>>> pci = [ '83:00.0' , '83:00.1' ] >>>>>>> >>>>>>> on_poweroff = 'destroy' >>>>>>> on_reboot = 'restart' >>>>>>> on_crash = 'destroy' >>>>>>> >>>>>>> boot='cd' >>>>>>> >>>>>>> sdl=0 >>>>>>> vnc=1 >>>>>>> vncconsole=0 >>>>>>> vncpasswd='' >>>>>>> vnclisten='172.24.226.84' >>>>>>> >>>>>>> stdvga=0 >>>>>>> >>>>>>> serial='pty' >>>>>>> usbdevice='tablet' >>>>>>> >>>>>>> gfx_passthru=0 >>>>>>> pci_power_mgmt=1 >>>>>>> xen_platform_pci=1 >>>>>>> pci_msitranslate=1 >>>>>>> viridian=1 >>>>>>> hpet=1 >>>>>>> >>>>>>> ############################################################ >>>>>>> >>>>>>> And the vm produces the following qemu log in >>>>>>> /var/log/xen/ >>>>>>> >>>>>>> ############################################################ >>>>>>> >>>>>>> domid: 4 >>>>>>> -videoram option does not work with cirrus vga >>>>>>> device model. Videoram set to 4M. >>>>>>> Strip off blktap sub-type prefix to >>>>>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>>>>> Using file /xen-guests/img/windows7Test.img in >>>>>>> read-write mode >>>>>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>>>>> Watching /local/domain/0/device-model/4/command >>>>>>> Watching /local/domain/4/cpu >>>>>>> char device redirected to /dev/pts/3 >>>>>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>>>>> shared page at pfn feffd >>>>>>> buffered io page at pfn feffb >>>>>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>>>>> 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/4/xen_extended_power_mgmt): >>>>>>> read error >>>>>>> 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. >>>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>>> count: 0, size: 0 >>>>>>> xs_read(/local/domain/4/log-throttling): read error >>>>>>> qemu: ignoring not-understood drive >>>>>>> `/local/domain/4/log-throttling' >>>>>>> medium change watch on >>>>>>> `/local/domain/4/log-throttling' - unknown device, >>>>>>> ignored >>>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>>> count: 0, size: 0 >>>>>>> dm-command: hot insert pass-through pci dev >>>>>>> register_real_device: Assigning real physical device >>>>>>> 83:00.0 ... >>>>>>> register_real_device: Enable MSI translation via per >>>>>>> device option >>>>>>> register_real_device: Enable power management >>>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>>> 0x83:0x0.0x0 >>>>>>> pt_register_regions: IO region registered >>>>>>> (size=0x10000000 base_addr=0xe000000c) >>>>>>> pt_register_regions: IO region registered >>>>>>> (size=0x00040000 base_addr=0xf0000004) >>>>>>> pt_register_regions: IO region registered >>>>>>> (size=0x00000100 base_addr=0x0000f001) >>>>>>> pt_register_regions: Expansion ROM registered >>>>>>> (size=0x00020000 base_addr=0xf0040000) >>>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>>> pci_intx: intx=1 >>>>>>> register_real_device: Real physical device 83:00.0 >>>>>>> registered successfuly! >>>>>>> IRQ type = MSI-INTx >>>>>>> dm-command: hot insert pass-through pci dev >>>>>>> register_real_device: Assigning real physical device >>>>>>> 83:00.1 ... >>>>>>> register_real_device: Enable MSI translation via per >>>>>>> device option >>>>>>> register_real_device: Enable power management >>>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>>> 0x83:0x0.0x1 >>>>>>> pt_register_regions: IO region registered >>>>>>> (size=0x00004000 base_addr=0xf0060004) >>>>>>> pt_msi_setup: msi mapped with pirq 66 >>>>>>> pci_intx: intx=2 >>>>>>> register_real_device: Real physical device 83:00.1 >>>>>>> registered successfuly! >>>>>>> IRQ type = MSI-INTx >>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=1 >>>>>>> cirrus vga map change while on lfb mode >>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=1 >>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=1 >>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>> index=4 first_map=1 >>>>>>> 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. >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=0 >>>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>>> index=4 first_map=0 >>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=0 >>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>> index=4 first_map=0 >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=0 >>>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>>> index=4 first_map=0 >>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=0 >>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>> index=4 first_map=0 >>>>>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>>>>> MSI-INTx translation >>>>>>> pci_intx: intx=1 >>>>>>> pt_msi_disable: Unmap msi with pirq 67 >>>>>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>>> pt_msi_update: Update msi with pirq 67 gvec b0 >>>>>>> gflags 130f >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=0 >>>>>>> >>>>>>> ###################################################################### >>>>>>> >>>>>>> _____________________ >>>>>>> > --------------080301000809030306000709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
My guess is that they are on different bridges.  I've read that for this board if you use only the first CPU socket then you'll only get access to pcie slots 1 through 4.  Slots 5, 6 and 7 simply won't work at all.  Passing through both cards still does not work but this time I don't get a BSOD, the display simply never turns on.  I can hear the fan speed of the card change however at the precise point where the VNC window stops showing any change so there is something going on here.  I've just pulled out the card in slot 5 and tried to pass through the one remaining card and that has the same result, with the display never turning on.

Matt

On 12/03/2013 11:41, Peter Maloney wrote:
Okay that is enormous output :D

And I'm not sure what to say about it... hopefully someone else reading it can read it better than I can.

Your bridges:

00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)

Your GPUs:
...
  +-[0000:80]-+-00.0-[81]--
  |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
   |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
  \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
              +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
              |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]

So you would be fine with PCI bridges if that 80 vs 00 is really different bridges and not just same ones seen by different CPUSs.

I can look at many older Xeons and they all show just one set of bridges, and one very new one (newer socket) has the same thing as yours. But I don't use IOMMU on those, so I don't know what effect it has.

I kinda think they are the same bridge, which would be bad. I don't know how to test it... pull out a CPU? ;) find some other detail that has IDs? disable one in the bios (unlikely)? or you could test this by passing through both cards to the same domu... This would be a good test (and matches what the other thread was about... his worked with passing both through)




On 2013-03-12 11:32, Matthew Dean wrote:
As requested,

lspci

##############################################################################################################

00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07)
00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06)
00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05)
00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05)
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06)
00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06)
00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6)
00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6)
00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6)
00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6)
00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6)
00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06)
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06)
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10)
0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01)
7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07)
80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)

##############################################################################################################

lspci -tv

##############################################################################################################

-+-[0000:ff]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-00.0-[81]--
 |           +-01.0-[82]--
 |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
 |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
 |           +-03.0-[84]--
 |           +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
 |           \-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
             +-01.0-[01]--
             +-01.1-[02]--
             +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
             |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
             +-03.0-[04]--
             +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
             +-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
             +-11.0-[05]----00.0  Intel Corporation C602 chipset 4-Port SATA Storage Control Unit
             +-16.0  Intel Corporation C600/X79 series chipset MEI Controller #1
             +-16.1  Intel Corporation C600/X79 series chipset MEI Controller #2
             +-1a.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2
             +-1b.0  Intel Corporation C600/X79 series chipset High Definition Audio Controller
             +-1c.0-[06]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.1-[07]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.2-[08]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.3-[09]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.4-[0a]----00.0  Marvell Technology Group Ltd. Device 9230
             +-1c.6-[0b]----00.0  VIA Technologies, Inc. VT6315 Series Firewire Controller
             +-1d.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1
             +-1e.0-[0c]--
             +-1f.0  Intel Corporation C600/X79 series chipset LPC Controller
             +-1f.2  Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation C600/X79 series chipset SMBus Host Controller

##############################################################################################################

I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present.  I've had a dig for the thread your talking about but I cannot find it.  If anybody else knows if it still exists somewhere I'd be grateful if you could let me know.

Thanks again for your help.

Matt

On 11/03/2013 18:16, Peter Maloney wrote:
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_____________________


--------------080301000809030306000709-- --===============9108367519053242777== 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 --===============9108367519053242777==-- From xen-users-bounces@lists.xen.org Tue Mar 12 11:58:09 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 11:58: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 1UFNpS-0001XE-Oo; Tue, 12 Mar 2013 11:57:14 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFNpQ-0001X2-1M for xen-users@lists.xen.org; Tue, 12 Mar 2013 11:57:12 +0000 Received: from [193.109.254.147:8926] by server-11.bemta-14.messagelabs.com id 6C/33-24840-7181F315; Tue, 12 Mar 2013 11:57:11 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-15.tower-27.messagelabs.com!1363089349!1712046!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19052 invoked from network); 12 Mar 2013 11:55:49 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-15.tower-27.messagelabs.com with SMTP; 12 Mar 2013 11:55:49 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:61727) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UFNnq-0006it-8d (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Tue, 12 Mar 2013 11:55:35 +0000 Message-ID: <513F17AA.6050406@cam.ac.uk> Date: Tue, 12 Mar 2013 11:55:22 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> <513F0426.1080808@cam.ac.uk> <513F1467.2010202@brockmann-consult.de> In-Reply-To: <513F1467.2010202@brockmann-consult.de> Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============9108367519053242777==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============9108367519053242777== Content-Type: multipart/alternative; boundary="------------080301000809030306000709" This is a multi-part message in MIME format. --------------080301000809030306000709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My guess is that they are on different bridges. I've read that for this board if you use only the first CPU socket then you'll only get access to pcie slots 1 through 4. Slots 5, 6 and 7 simply won't work at all. Passing through both cards still does not work but this time I don't get a BSOD, the display simply never turns on. I can hear the fan speed of the card change however at the precise point where the VNC window stops showing any change so there is something going on here. I've just pulled out the card in slot 5 and tried to pass through the one remaining card and that has the same result, with the display never turning on. Matt On 12/03/2013 11:41, Peter Maloney wrote: > Okay that is enormous output :D > > And I'm not sure what to say about it... hopefully someone else > reading it can read it better than I can. > > Your bridges: > > *00:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI > Express Root Port 2a (rev 07) > *80:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI > Express Root Port 2a (rev 07) > > Your GPUs: > ... > +-[0000:*80*]-+-00.0-[81]-- > | +-*02.0*-[83]--+-00.0 Advanced Micro Devices [AMD] nee > ATI Tahiti XT [Radeon HD 7970] > | | \-00.1 Advanced Micro Devices [AMD] nee > ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] > \-[0000:*00*]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 > +-*02.0*-[03]--+-00.0 Advanced Micro Devices [AMD] nee > ATI Tahiti XT [Radeon HD 7970] > | \-00.1 Advanced Micro Devices [AMD] nee > ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] > > So you would be fine with PCI bridges if that 80 vs 00 is really > different bridges and not just same ones seen by different CPUSs. > > I can look at many older Xeons and they all show just one set of > bridges, and one very new one (newer socket) has the same thing as > yours. But I don't use IOMMU on those, so I don't know what effect it has. > > I kinda think they are the same bridge, which would be bad. I don't > know how to test it... pull out a CPU? ;) find some other detail that > has IDs? disable one in the bios (unlikely)? or you could test this by > passing through both cards to the same domu... This would be a good > test (and matches what the other thread was about... his worked with > passing both through) > > > > > On 2013-03-12 11:32, Matthew Dean wrote: >> As requested, >> >> lspci >> >> ############################################################################################################## >> >> 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) >> 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 1a (rev 07) >> 00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 1b (rev 07) >> 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 2a (rev 07) >> 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 3a in PCI Express Mode (rev 07) >> 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address >> Map, VTd_Misc, System Management (rev 07) >> 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control >> Status and Global Errors (rev 07) >> 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) >> 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Virtual Root Port (rev 06) >> 00:16.0 Communication controller: Intel Corporation C600/X79 series >> chipset MEI Controller #1 (rev 05) >> 00:16.1 Communication controller: Intel Corporation C600/X79 series >> chipset MEI Controller #2 (rev 05) >> 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset >> USB2 Enhanced Host Controller #2 (rev 06) >> 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High >> Definition Audio Controller (rev 06) >> 00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 1 (rev b6) >> 00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 2 (rev b6) >> 00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 3 (rev b6) >> 00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 4 (rev b6) >> 00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 5 (rev b6) >> 00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI >> Express Root Port 7 (rev b6) >> 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset >> USB2 Enhanced Host Controller #1 (rev 06) >> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) >> 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC >> Controller (rev 06) >> 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset >> 6-Port SATA AHCI Controller (rev 06) >> 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host >> Controller (rev 06) >> 03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> 03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT >> HDMI Audio [Radeon HD 7970 Series] >> 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 >> chipset 4-Port SATA Storage Control Unit (rev 06) >> 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >> Connection >> 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >> Connection >> 08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed >> USB Host Controller >> 09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed >> USB Host Controller >> 0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 >> (rev 10) >> 0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series >> Firewire Controller (rev 01) >> 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> 0 (rev 07) >> 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 0 (rev 07) >> 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 0 (rev 07) >> 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> 1 (rev 07) >> 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 1 (rev 07) >> 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 1 (rev 07) >> 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 0 (rev 07) >> 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 1 (rev 07) >> 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 2 (rev 07) >> 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 3 (rev 07) >> 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Interrupt Control Registers (rev 07) >> 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Semaphore and Scratchpad Configuration Registers (rev 07) >> 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller System Address Decoder 0 (rev 07) >> 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System >> Address Decoder (rev 07) >> 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller System Address Decoder 1 (rev 07) >> 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Processor Home Agent (rev 07) >> 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 >> Processor Home Agent Performance Monitoring (rev 07) >> 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Registers (rev 07) >> 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller RAS Registers (rev 07) >> 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 0 (rev 07) >> 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 1 (rev 07) >> 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 2 (rev 07) >> 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 3 (rev 07) >> 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 4 (rev 07) >> 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) >> 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) >> 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 0 (rev 07) >> 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 1 (rev 07) >> 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) >> 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) >> 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 2 (rev 07) >> 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 3 (rev 07) >> 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO >> (rev 07) >> 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe >> (rev 07) >> 7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >> to PCI Express Performance Monitor (rev 07) >> 7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 >> QuickPath Interconnect Agent Ring Registers (rev 07) >> 7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >> to QuickPath Interconnect Link 0 Performance Monitor (rev 07) >> 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 1 Performance Monitor (rev 07) >> 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI >> Express Mode (rev 07) >> 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 1a (rev 07) >> 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 2a (rev 07) >> 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express >> Root Port 3a in PCI Express Mode (rev 07) >> 80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address >> Map, VTd_Misc, System Management (rev 07) >> 80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control >> Status and Global Errors (rev 07) >> 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) >> 83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> 83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT >> HDMI Audio [Radeon HD 7970 Series] >> ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> 0 (rev 07) >> ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 0 (rev 07) >> ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 0 (rev 07) >> ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> 1 (rev 07) >> ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 1 (rev 07) >> ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link >> Reut 1 (rev 07) >> ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 0 (rev 07) >> ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 1 (rev 07) >> ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 2 (rev 07) >> ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power >> Control Unit 3 (rev 07) >> ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Interrupt Control Registers (rev 07) >> ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Semaphore and Scratchpad Configuration Registers (rev 07) >> ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller System Address Decoder 0 (rev 07) >> ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System >> Address Decoder (rev 07) >> ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >> Register 0 (rev 07) >> ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller System Address Decoder 1 (rev 07) >> ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Processor Home Agent (rev 07) >> ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 >> Processor Home Agent Performance Monitoring (rev 07) >> ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Registers (rev 07) >> ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller RAS Registers (rev 07) >> ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 0 (rev 07) >> ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 1 (rev 07) >> ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 2 (rev 07) >> ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 3 (rev 07) >> ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Target Address Decoder 4 (rev 07) >> ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) >> ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) >> ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 0 (rev 07) >> ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 1 (rev 07) >> ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) >> ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) >> ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 2 (rev 07) >> ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 >> Integrated Memory Controller ERROR Registers 3 (rev 07) >> ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO >> (rev 07) >> ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe >> (rev 07) >> ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >> to PCI Express Performance Monitor (rev 07) >> ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 >> QuickPath Interconnect Agent Ring Registers (rev 07) >> ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >> to QuickPath Interconnect Link 0 Performance Monitor (rev 07) >> ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 1 Performance Monitor (rev 07) >> >> ############################################################################################################## >> >> lspci -tv >> >> ############################################################################################################## >> >> -+-[0000:ff]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 >> | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >> | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >> | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 >> | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >> | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >> | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 0 >> | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 1 >> | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 2 >> | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 3 >> | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt >> Control Registers >> | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and >> Scratchpad Configuration Registers >> | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller System Address Decoder 0 >> | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address >> Decoder >> | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller System Address Decoder 1 >> | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home >> Agent >> | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home >> Agent Performance Monitoring >> | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Registers >> | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller RAS Registers >> | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 0 >> | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 1 >> | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 2 >> | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 3 >> | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 4 >> | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 0 >> | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 1 >> | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 0 >> | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 1 >> | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 2 >> | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 3 >> | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 2 >> | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 3 >> | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO >> | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe >> | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI >> Express Performance Monitor >> | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath >> Interconnect Agent Ring Registers >> | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 0 Performance Monitor >> | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 1 Performance Monitor >> +-[0000:80]-+-00.0-[81]-- >> | +-01.0-[82]-- >> | +-02.0-[83]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> | | \-00.1 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >> | +-03.0-[84]-- >> | +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, >> VTd_Misc, System Management >> | +-05.2 Intel Corporation Xeon E5/Core i7 Control Status >> and Global Errors >> | \-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC >> +-[0000:7f]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 >> | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >> | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >> | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 >> | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >> | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >> | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 0 >> | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 1 >> | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 2 >> | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control >> Unit 3 >> | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt >> Control Registers >> | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and >> Scratchpad Configuration Registers >> | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller System Address Decoder 0 >> | +-0c.7 Intel Corporation Xeon E5/Core i7 System Address >> Decoder >> | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast Register 0 >> | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller System Address Decoder 1 >> | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor Home >> Agent >> | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor Home >> Agent Performance Monitoring >> | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Registers >> | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller RAS Registers >> | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 0 >> | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 1 >> | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 2 >> | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 3 >> | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Target Address Decoder 4 >> | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 0 >> | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 1 >> | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 0 >> | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 1 >> | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 2 >> | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller Channel 0-3 Thermal Control 3 >> | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 2 >> | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated >> Memory Controller ERROR Registers 3 >> | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO >> | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe >> | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI >> Express Performance Monitor >> | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath >> Interconnect Agent Ring Registers >> | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 0 Performance Monitor >> | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to >> QuickPath Interconnect Link 1 Performance Monitor >> \-[0000:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 >> +-01.0-[01]-- >> +-01.1-[02]-- >> +-02.0-[03]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> | \-00.1 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >> +-03.0-[04]-- >> +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, >> VTd_Misc, System Management >> +-05.2 Intel Corporation Xeon E5/Core i7 Control Status >> and Global Errors >> +-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC >> +-11.0-[05]----00.0 Intel Corporation C602 chipset >> 4-Port SATA Storage Control Unit >> +-16.0 Intel Corporation C600/X79 series chipset MEI >> Controller #1 >> +-16.1 Intel Corporation C600/X79 series chipset MEI >> Controller #2 >> +-1a.0 Intel Corporation C600/X79 series chipset USB2 >> Enhanced Host Controller #2 >> +-1b.0 Intel Corporation C600/X79 series chipset High >> Definition Audio Controller >> +-1c.0-[06]----00.0 Intel Corporation 82574L Gigabit >> Network Connection >> +-1c.1-[07]----00.0 Intel Corporation 82574L Gigabit >> Network Connection >> +-1c.2-[08]----00.0 ASMedia Technology Inc. ASM1042 >> SuperSpeed USB Host Controller >> +-1c.3-[09]----00.0 ASMedia Technology Inc. ASM1042 >> SuperSpeed USB Host Controller >> +-1c.4-[0a]----00.0 Marvell Technology Group Ltd. >> Device 9230 >> +-1c.6-[0b]----00.0 VIA Technologies, Inc. VT6315 >> Series Firewire Controller >> +-1d.0 Intel Corporation C600/X79 series chipset USB2 >> Enhanced Host Controller #1 >> +-1e.0-[0c]-- >> +-1f.0 Intel Corporation C600/X79 series chipset LPC >> Controller >> +-1f.2 Intel Corporation C600/X79 series chipset 6-Port >> SATA AHCI Controller >> \-1f.3 Intel Corporation C600/X79 series chipset SMBus >> Host Controller >> >> ############################################################################################################## >> >> I'm going to try passing through both cards and see if that works as >> well as passing through just the one but with only one card present. >> I've had a dig for the thread your talking about but I cannot find >> it. If anybody else knows if it still exists somewhere I'd be >> grateful if you could let me know. >> >> Thanks again for your help. >> >> Matt >> >> On 11/03/2013 18:16, Peter Maloney wrote: >>> Ah, because you have 2 cpus and 2 cards, can you post output of >>> "lspci -tv" and "lspci"? There was one guy who could pass through >>> one card, but when he physically added the 2nd card in the machine, >>> the same config with the first card wouldn't work any more because >>> the 2 cards were on the same PCI bridge. And he could pass through >>> both and have them work, but not just one of them at a time. (I have >>> since cleaned out my email box, and so I can't find the old thread) >>> >>> So you see on my system, the "02.0" bridge is separate from "0c.0", >>> so I don't have a problem. >>> >>> -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI to >>> PCI bridge (external gfx0 port B) >>> +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O >>> Memory Management Unit (IOMMU) >>> +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee >>> ATI RV370 5B60 [Radeon X300 (PCIE)] >>> | \-00.1 Advanced Micro Devices [AMD] nee ATI >>> RV370 [Radeon X300SE] >>> +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB 3.0 >>> Host Controller >>> +-0a.0-[03]----00.0 Marvell Technology Group Ltd. >>> 88SE9172 SATA 6Gb/s Controller >>> +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee >>> ATI Juniper XT [AMD Radeon HD 6000 Series] >>> | \-00.1 Advanced Micro Devices [AMD] nee ATI >>> Juniper HDMI Audio [Radeon HD 5700 Series] >>> >>> >>> *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>> to PCI bridge (PCI express gpp port B) >>> 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>> to PCI bridge (PCI express gpp port H) >>> 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>> to PCI bridge (external gfx1 port A) >>> *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 >>> >>> >>> >>> On 03/11/2013 06:45 PM, Matthew Dean wrote: >>>> That was a good suggestion, I've just tried passing through a USB >>>> controller and that worked fine. The driver installed correctly >>>> and I can use devices attached to the relevant ports. The problem >>>> therefore seems to be to do with gpu passthrough specifically. I'm >>>> just going to describe my system and some settings I have in the >>>> bios as this is starting to feel like a system specific problem. >>>> The system is >>>> >>>> Asus Z9PE-D8 WS motherboard (chipset is intel C602) >>>> Dual Xeon 2620 >>>> 64 GB non-ecc memory >>>> Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm >>>> trying to pass through) >>>> >>>> In the bios I have vt-d enabled. I also have sub-feature settings >>>> for "Coherency Support" and "ATS Support" which are disabled by >>>> default. I've tried all combinations of these enabled and >>>> disabled. If I enable "ATS Support" I do however have to add the >>>> option "iommu=no-qinval,no-intremap" to the xen boot otherwise the >>>> system hangs as per this thread >>>> . >>>> If the problem is to no with these options then I think I have a >>>> problem. >>>> >>>> Has anybody got any thoughts? >>>> >>>> Matt >>>> >>>> On 11/03/2013 14:57, Peter Maloney wrote: >>>>> Did you try other devices, such as your onboard sound card, your >>>>> onboard USB controllers, etc.? Maybe your board doesn't do >>>>> passthrough properly. >>>>> >>>>> Or did you try another PCIe port for the card? Maybe there are >>>>> bugs where the addresses overlap with some other device, but in >>>>> another slot it wouldn't happen. >>>>> >>>>> >>>>> On 2013-03-11 14:48, Matthew Dean wrote: >>>>>> First of all, thank you for the suggestions. I've now >>>>>> re-installed windows and I've tried driver versions 12.3, 12.8 >>>>>> and 13.1 all with and without the CCC as I read in various places >>>>>> that it can cause problems. For 13.1 I never get anywhere close >>>>>> as per my previous messages. For 12.3 and 12.8 I at least get a >>>>>> BSOD, >>>>>> >>>>>> ####################################################################### >>>>>> >>>>>> A problem has been detected ... >>>>>> >>>>>> Attempt to reset the display driver and recover from timeout failed. >>>>>> >>>>>> If this is ... >>>>>> >>>>>> Techinal information: >>>>>> >>>>>> *** STOP: 0x00000116 >>>>>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>>>>> >>>>>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>>>>> FFFFF88003D8E000, Datestamp 4f597fca >>>>>> >>>>>> ####################################################################### >>>>>> >>>>>> Does anybody have any further ideas? >>>>>> >>>>>> Matt >>>>>> >>>>>> On 07/03/2013 21:42, John Sherwood wrote: >>>>>>> (and I should probably mention that it has been my experience >>>>>>> that that is the expected and correct behavior) >>>>>>> >>>>>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>>>>> > wrote: >>>>>>> >>>>>>> Having the windows logo freeze in the VNC window has been my >>>>>>> experience with GPU passthrough as well. >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I believe that the Windows logo freezing in the vnc >>>>>>> window is normal behaviour when secondary GPU >>>>>>> passthrough is working as it should, since the display >>>>>>> should be handed over to the GPU. At least that was the >>>>>>> case before when I was passing through a HD6850 card as >>>>>>> secondary to win7 using xl. But you should expect output >>>>>>> on the GPU, of course. >>>>>>> >>>>>>> Have you tried different versions of the catalyst >>>>>>> driver? I think that some users have reported problems >>>>>>> with the latest one (13-something). >>>>>>> >>>>>>> Regards, >>>>>>> Andreas >>>>>>> >>>>>>> 2013/3/7 Matthew Dean >>>>>> > >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I've managed to get a windows 7 x64 hvm to boot and >>>>>>> install and I'm now looking to pass through a HD >>>>>>> 7970 as a secondary GPU. in order to prepare the >>>>>>> devices for passthrough I've used >>>>>>> >>>>>>> xl pci-assignable-add 83:00.0 >>>>>>> xl pci-assignable-add 83:00.1 >>>>>>> >>>>>>> Where I've identified the device pci ids using >>>>>>> lspci. This works fine and the devices appear when >>>>>>> I call 'xl pci-assignable-list'. After adding them >>>>>>> to the vm config (see below) I was able to get the >>>>>>> vm to boot and the devices appeared in device >>>>>>> manager. Installing the ATI drivers however has >>>>>>> meant that on further boots the machine never gets >>>>>>> past the windows logo in the VNC window and no >>>>>>> output is generated from the ATI card. It simply >>>>>>> freezes there and the only way I can get back into >>>>>>> windows is via safe mode, even after uninstalling >>>>>>> the ATI software. >>>>>>> >>>>>>> Has anybody else experienced similar issues or have >>>>>>> any advice as to how to get this to work? I'm a bit >>>>>>> stumped and the wiki implies that this should 'just >>>>>>> work'. >>>>>>> >>>>>>> Thank you in advance for any help. >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> Here is my machine config >>>>>>> >>>>>>> ########################################################### >>>>>>> >>>>>>> builder='hvm' >>>>>>> memory = 2048 >>>>>>> name = 'Windows7Test' >>>>>>> >>>>>>> vcpus=4 >>>>>>> pae=1 >>>>>>> acpi=1 >>>>>>> apic=1 >>>>>>> >>>>>>> disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>>>>> pci = [ '83:00.0' , '83:00.1' ] >>>>>>> >>>>>>> on_poweroff = 'destroy' >>>>>>> on_reboot = 'restart' >>>>>>> on_crash = 'destroy' >>>>>>> >>>>>>> boot='cd' >>>>>>> >>>>>>> sdl=0 >>>>>>> vnc=1 >>>>>>> vncconsole=0 >>>>>>> vncpasswd='' >>>>>>> vnclisten='172.24.226.84' >>>>>>> >>>>>>> stdvga=0 >>>>>>> >>>>>>> serial='pty' >>>>>>> usbdevice='tablet' >>>>>>> >>>>>>> gfx_passthru=0 >>>>>>> pci_power_mgmt=1 >>>>>>> xen_platform_pci=1 >>>>>>> pci_msitranslate=1 >>>>>>> viridian=1 >>>>>>> hpet=1 >>>>>>> >>>>>>> ############################################################ >>>>>>> >>>>>>> And the vm produces the following qemu log in >>>>>>> /var/log/xen/ >>>>>>> >>>>>>> ############################################################ >>>>>>> >>>>>>> domid: 4 >>>>>>> -videoram option does not work with cirrus vga >>>>>>> device model. Videoram set to 4M. >>>>>>> Strip off blktap sub-type prefix to >>>>>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>>>>> Using file /xen-guests/img/windows7Test.img in >>>>>>> read-write mode >>>>>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>>>>> Watching /local/domain/0/device-model/4/command >>>>>>> Watching /local/domain/4/cpu >>>>>>> char device redirected to /dev/pts/3 >>>>>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>>>>> shared page at pfn feffd >>>>>>> buffered io page at pfn feffb >>>>>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>>>>> 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/4/xen_extended_power_mgmt): >>>>>>> read error >>>>>>> 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. >>>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>>> count: 0, size: 0 >>>>>>> xs_read(/local/domain/4/log-throttling): read error >>>>>>> qemu: ignoring not-understood drive >>>>>>> `/local/domain/4/log-throttling' >>>>>>> medium change watch on >>>>>>> `/local/domain/4/log-throttling' - unknown device, >>>>>>> ignored >>>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>>> count: 0, size: 0 >>>>>>> dm-command: hot insert pass-through pci dev >>>>>>> register_real_device: Assigning real physical device >>>>>>> 83:00.0 ... >>>>>>> register_real_device: Enable MSI translation via per >>>>>>> device option >>>>>>> register_real_device: Enable power management >>>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>>> 0x83:0x0.0x0 >>>>>>> pt_register_regions: IO region registered >>>>>>> (size=0x10000000 base_addr=0xe000000c) >>>>>>> pt_register_regions: IO region registered >>>>>>> (size=0x00040000 base_addr=0xf0000004) >>>>>>> pt_register_regions: IO region registered >>>>>>> (size=0x00000100 base_addr=0x0000f001) >>>>>>> pt_register_regions: Expansion ROM registered >>>>>>> (size=0x00020000 base_addr=0xf0040000) >>>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>>> pci_intx: intx=1 >>>>>>> register_real_device: Real physical device 83:00.0 >>>>>>> registered successfuly! >>>>>>> IRQ type = MSI-INTx >>>>>>> dm-command: hot insert pass-through pci dev >>>>>>> register_real_device: Assigning real physical device >>>>>>> 83:00.1 ... >>>>>>> register_real_device: Enable MSI translation via per >>>>>>> device option >>>>>>> register_real_device: Enable power management >>>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>>> 0x83:0x0.0x1 >>>>>>> pt_register_regions: IO region registered >>>>>>> (size=0x00004000 base_addr=0xf0060004) >>>>>>> pt_msi_setup: msi mapped with pirq 66 >>>>>>> pci_intx: intx=2 >>>>>>> register_real_device: Real physical device 83:00.1 >>>>>>> registered successfuly! >>>>>>> IRQ type = MSI-INTx >>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=1 >>>>>>> cirrus vga map change while on lfb mode >>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=1 >>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=1 >>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>> index=4 first_map=1 >>>>>>> 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. >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>> register with invalid access size alignment. >>>>>>> [Offset:0eh][Length:4] >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=0 >>>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>>> index=4 first_map=0 >>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=0 >>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>> index=4 first_map=0 >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=0 >>>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>>> index=4 first_map=0 >>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>> len=268435456 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>> len=262144 index=2 first_map=0 >>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>> index=4 first_map=0 >>>>>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>>>>> MSI-INTx translation >>>>>>> pci_intx: intx=1 >>>>>>> pt_msi_disable: Unmap msi with pirq 67 >>>>>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>>> pt_msi_update: Update msi with pirq 67 gvec b0 >>>>>>> gflags 130f >>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=0 >>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>> len=16384 index=0 first_map=0 >>>>>>> >>>>>>> ###################################################################### >>>>>>> >>>>>>> _____________________ >>>>>>> > --------------080301000809030306000709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
My guess is that they are on different bridges.  I've read that for this board if you use only the first CPU socket then you'll only get access to pcie slots 1 through 4.  Slots 5, 6 and 7 simply won't work at all.  Passing through both cards still does not work but this time I don't get a BSOD, the display simply never turns on.  I can hear the fan speed of the card change however at the precise point where the VNC window stops showing any change so there is something going on here.  I've just pulled out the card in slot 5 and tried to pass through the one remaining card and that has the same result, with the display never turning on.

Matt

On 12/03/2013 11:41, Peter Maloney wrote:
Okay that is enormous output :D

And I'm not sure what to say about it... hopefully someone else reading it can read it better than I can.

Your bridges:

00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)

Your GPUs:
...
  +-[0000:80]-+-00.0-[81]--
  |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
   |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
  \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
              +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
              |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]

So you would be fine with PCI bridges if that 80 vs 00 is really different bridges and not just same ones seen by different CPUSs.

I can look at many older Xeons and they all show just one set of bridges, and one very new one (newer socket) has the same thing as yours. But I don't use IOMMU on those, so I don't know what effect it has.

I kinda think they are the same bridge, which would be bad. I don't know how to test it... pull out a CPU? ;) find some other detail that has IDs? disable one in the bios (unlikely)? or you could test this by passing through both cards to the same domu... This would be a good test (and matches what the other thread was about... his worked with passing both through)




On 2013-03-12 11:32, Matthew Dean wrote:
As requested,

lspci

##############################################################################################################

00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07)
00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06)
00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05)
00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05)
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06)
00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06)
00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6)
00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6)
00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6)
00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6)
00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6)
00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06)
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06)
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10)
0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01)
7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07)
80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)

##############################################################################################################

lspci -tv

##############################################################################################################

-+-[0000:ff]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-00.0-[81]--
 |           +-01.0-[82]--
 |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
 |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
 |           +-03.0-[84]--
 |           +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
 |           \-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
             +-01.0-[01]--
             +-01.1-[02]--
             +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
             |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
             +-03.0-[04]--
             +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
             +-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
             +-11.0-[05]----00.0  Intel Corporation C602 chipset 4-Port SATA Storage Control Unit
             +-16.0  Intel Corporation C600/X79 series chipset MEI Controller #1
             +-16.1  Intel Corporation C600/X79 series chipset MEI Controller #2
             +-1a.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2
             +-1b.0  Intel Corporation C600/X79 series chipset High Definition Audio Controller
             +-1c.0-[06]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.1-[07]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.2-[08]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.3-[09]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.4-[0a]----00.0  Marvell Technology Group Ltd. Device 9230
             +-1c.6-[0b]----00.0  VIA Technologies, Inc. VT6315 Series Firewire Controller
             +-1d.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1
             +-1e.0-[0c]--
             +-1f.0  Intel Corporation C600/X79 series chipset LPC Controller
             +-1f.2  Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation C600/X79 series chipset SMBus Host Controller

##############################################################################################################

I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present.  I've had a dig for the thread your talking about but I cannot find it.  If anybody else knows if it still exists somewhere I'd be grateful if you could let me know.

Thanks again for your help.

Matt

On 11/03/2013 18:16, Peter Maloney wrote:
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_____________________


--------------080301000809030306000709-- --===============9108367519053242777== 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 --===============9108367519053242777==-- From xen-users-bounces@lists.xen.org Tue Mar 12 12:13:56 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 12:13: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 1UFO4v-0002R0-BQ; Tue, 12 Mar 2013 12:13:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFO4t-0002Qt-Ey for xen-users@lists.xen.org; Tue, 12 Mar 2013 12:13:11 +0000 Received: from [85.158.143.99:49421] by server-3.bemta-4.messagelabs.com id 96/2B-02186-6DB1F315; Tue, 12 Mar 2013 12:13:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1363090306!16901588!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6888 invoked from network); 12 Mar 2013 12:11:46 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 12:11:46 -0000 X-IronPort-AV: E=Sophos;i="4.84,830,1355097600"; d="scan'208";a="2411797" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Mar 2013 12:11:47 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 12 Mar 2013 12:11:47 +0000 Message-ID: <1363090305.29599.14.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Paul Stimpson Date: Tue, 12 Mar 2013 12:11:45 +0000 In-Reply-To: <513E2B4F.7030600@stimpsonfamily.co.uk> References: <513E2B4F.7030600@stimpsonfamily.co.uk> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Windows QEMU resolution X-BeenThere: xen-users@lists.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, 2013-03-11 at 19:06 +0000, Paul Stimpson wrote: > Hi, > > I have a Windows guest under XL with Xen 4.2.0 and I'm trying to > increase the resolution of the VNC console. > > I added: > > extra = "xen-fbfront.video=32,1920,1200" Does Windows really have a xen-fbfront driver? I've not heard of such a thing. In any case "extra" adds something to the PV guest kernel command line, which isn't going to go anywhere an HVM Windows guest kernel I'm afraid. > to the config file and Windows now offers me a choice of 800x600 or > 1024x768 as available screen resolutions rather than just 800x600 so > something has happened. My initial thought was that I wasn't seeing the > higher resolutions because I hadn't allocated enough memory to the video > so I tried 64,1920,1200 and 256,1920,1200 but I still don't see anything > better than 1024x768 available in Windows. > > What am I doing wrong please? You need to be looking at the options relating to the emulated VGA device and video ram etc in xl.cfg(5). Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 12:13:56 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 12:13: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 1UFO4v-0002R0-BQ; Tue, 12 Mar 2013 12:13:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFO4t-0002Qt-Ey for xen-users@lists.xen.org; Tue, 12 Mar 2013 12:13:11 +0000 Received: from [85.158.143.99:49421] by server-3.bemta-4.messagelabs.com id 96/2B-02186-6DB1F315; Tue, 12 Mar 2013 12:13:10 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1363090306!16901588!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6888 invoked from network); 12 Mar 2013 12:11:46 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 12:11:46 -0000 X-IronPort-AV: E=Sophos;i="4.84,830,1355097600"; d="scan'208";a="2411797" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Mar 2013 12:11:47 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 12 Mar 2013 12:11:47 +0000 Message-ID: <1363090305.29599.14.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Paul Stimpson Date: Tue, 12 Mar 2013 12:11:45 +0000 In-Reply-To: <513E2B4F.7030600@stimpsonfamily.co.uk> References: <513E2B4F.7030600@stimpsonfamily.co.uk> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Windows QEMU resolution X-BeenThere: xen-users@lists.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, 2013-03-11 at 19:06 +0000, Paul Stimpson wrote: > Hi, > > I have a Windows guest under XL with Xen 4.2.0 and I'm trying to > increase the resolution of the VNC console. > > I added: > > extra = "xen-fbfront.video=32,1920,1200" Does Windows really have a xen-fbfront driver? I've not heard of such a thing. In any case "extra" adds something to the PV guest kernel command line, which isn't going to go anywhere an HVM Windows guest kernel I'm afraid. > to the config file and Windows now offers me a choice of 800x600 or > 1024x768 as available screen resolutions rather than just 800x600 so > something has happened. My initial thought was that I wasn't seeing the > higher resolutions because I hadn't allocated enough memory to the video > so I tried 64,1920,1200 and 256,1920,1200 but I still don't see anything > better than 1024x768 available in Windows. > > What am I doing wrong please? You need to be looking at the options relating to the emulated VGA device and video ram etc in xl.cfg(5). Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 13:06:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 13:06: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 1UFOtv-0004XI-Vz; Tue, 12 Mar 2013 13:05:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFOtt-0004X9-MA for xen-users@lists.xen.org; Tue, 12 Mar 2013 13:05:53 +0000 Received: from [193.109.254.147:38226] by server-6.bemta-14.messagelabs.com id 36/3B-31180-0382F315; Tue, 12 Mar 2013 13:05:52 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1363093547!3399387!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20625 invoked from network); 12 Mar 2013 13:05:48 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 13:05:48 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so6271833wgb.24 for ; Tue, 12 Mar 2013 06:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ilrgo4uAQIrQpg6l7v9vIPo3vOV8aoTabrF1xbH7MuU=; b=M3IN7xd76byHoOUI6EmXlQuluUhg58muyFTWMhhy6CaKGjkOKweL8RXUgPdbAIHhAu xJRim+8sUciZkP119SsCzKNVVcUDJK5LPNjyr+I/KoYT6NWZRGReJRmbdCscca/x77kC ts8N4EhAO7f2zT3upD71SH9d8EDr01uisvAvlMA6EJk3iR+K1sIR/3bP4IwdjY43W1gN mPcXG+9K/t7LZhBlEAzo9hZKyygZKiqD6gvnUVA5H3pTygYU4kPmpv7mi+7N25FIzF9w i4HUTzqWP4AyzXct5uwIGQxp0RGDZ+xBtzd52pwUUWY3VKxNB2jnVR9q1oN6IdhNfSyI 4MHA== X-Received: by 10.180.78.168 with SMTP id c8mr19460096wix.27.1363093547431; Tue, 12 Mar 2013 06:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Tue, 12 Mar 2013 06:05:27 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Tue, 12 Mar 2013 09:05:27 -0400 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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, Mar 11, 2013 at 11:25 AM, jacek burghardt wrote: > What is the best open sourced free tool that will synchronize local lvms to > iscsi and allow fail over to iscsi targets. I (personally) have never seen such a tool, free or commercial. I don't know if it's even possible to have a failover block device (devs, feel free to shed some more educated light on this). In most cases, having block devices fail is rather rare, and is not an event that most systems can recover from gracefully. Failover systems usually involve hot-spare servers, where the file systems are either common or synced in some manner. I suppose you _could_ set up a mirrored LVM volume with your local disk and your iSCSI target as PVs, but I don't think I would recommend that. Instead, I would take a second look at your architecture. If you have an iSCSI system in place, it would be better to build RAID / LVM mirroring into the iSCSI unit. Let your storage system deal with storage availability. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 13:06:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 13:06: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 1UFOtv-0004XI-Vz; Tue, 12 Mar 2013 13:05:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFOtt-0004X9-MA for xen-users@lists.xen.org; Tue, 12 Mar 2013 13:05:53 +0000 Received: from [193.109.254.147:38226] by server-6.bemta-14.messagelabs.com id 36/3B-31180-0382F315; Tue, 12 Mar 2013 13:05:52 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1363093547!3399387!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20625 invoked from network); 12 Mar 2013 13:05:48 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 13:05:48 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so6271833wgb.24 for ; Tue, 12 Mar 2013 06:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ilrgo4uAQIrQpg6l7v9vIPo3vOV8aoTabrF1xbH7MuU=; b=M3IN7xd76byHoOUI6EmXlQuluUhg58muyFTWMhhy6CaKGjkOKweL8RXUgPdbAIHhAu xJRim+8sUciZkP119SsCzKNVVcUDJK5LPNjyr+I/KoYT6NWZRGReJRmbdCscca/x77kC ts8N4EhAO7f2zT3upD71SH9d8EDr01uisvAvlMA6EJk3iR+K1sIR/3bP4IwdjY43W1gN mPcXG+9K/t7LZhBlEAzo9hZKyygZKiqD6gvnUVA5H3pTygYU4kPmpv7mi+7N25FIzF9w i4HUTzqWP4AyzXct5uwIGQxp0RGDZ+xBtzd52pwUUWY3VKxNB2jnVR9q1oN6IdhNfSyI 4MHA== X-Received: by 10.180.78.168 with SMTP id c8mr19460096wix.27.1363093547431; Tue, 12 Mar 2013 06:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Tue, 12 Mar 2013 06:05:27 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Tue, 12 Mar 2013 09:05:27 -0400 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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, Mar 11, 2013 at 11:25 AM, jacek burghardt wrote: > What is the best open sourced free tool that will synchronize local lvms to > iscsi and allow fail over to iscsi targets. I (personally) have never seen such a tool, free or commercial. I don't know if it's even possible to have a failover block device (devs, feel free to shed some more educated light on this). In most cases, having block devices fail is rather rare, and is not an event that most systems can recover from gracefully. Failover systems usually involve hot-spare servers, where the file systems are either common or synced in some manner. I suppose you _could_ set up a mirrored LVM volume with your local disk and your iSCSI target as PVs, but I don't think I would recommend that. Instead, I would take a second look at your architecture. If you have an iSCSI system in place, it would be better to build RAID / LVM mirroring into the iSCSI unit. Let your storage system deal with storage availability. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 13:26:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 13:26: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 1UFPDS-0005Ke-W6; Tue, 12 Mar 2013 13:26:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFPDQ-0005KW-1L for xen-users@lists.xen.org; Tue, 12 Mar 2013 13:26:04 +0000 Received: from [85.158.138.51:23652] by server-12.bemta-3.messagelabs.com id AB/EC-01357-1EC2F315; Tue, 12 Mar 2013 13:25:53 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-3.tower-174.messagelabs.com!1363094738!23438614!1 X-Originating-IP: [212.227.126.186] X-SpamReason: No, hits=3.2 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNTgyMzY=\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNTgyMzY=\n,BODY_RANDOM_LONG, HTML_40_50,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13061 invoked from network); 12 Mar 2013 13:25:38 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.126.186) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 13:25:38 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LdyJ6-1UYDAX2vSW-00prlF; Tue, 12 Mar 2013 14:25:33 +0100 Message-ID: <513F2CCD.8040705@brockmann-consult.de> Date: Tue, 12 Mar 2013 14:25:33 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Matthew Dean References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> <513F0426.1080808@cam.ac.uk> <513F1467.2010202@brockmann-consult.de> <513F17AA.6050406@cam.ac.uk> In-Reply-To: <513F17AA.6050406@cam.ac.uk> X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:N7ch/aTx6LmD6v29kcgbQKNQepP7kugk/Kw/0KP8cH9 ZNR3ND8FMm9/9gBNdFboEy2OhY5ongdDHLUwqsNiqQUhe6Nu9O qLu2Wdl/8RiSBKKdYiOX7vnxHPNrt8f4t8kAmVJbhozgTLXJlT k2afjbZXXMa3joS10zElPlQBgYEfXrHenHS2t0fghFVp5ztz+i tAICCNnnqhnJ01F2p7Cl3Mp3Z7nGuIQQtnqjJNexc5SAUXTmcT Y0EW1Wmg/75QujsuXqv579fUrg75Q0wyQfDr5pGvFu+QiUDrz7 ykjBr3p5of6mErI4zcbgv7mVqVSI74GbJlNWyXu9m5KxPwQeWD ovzXR2u9XK+svNriTTW4P4zSQY5VsKcURf9DcEWCf Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============8793504173819426069==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============8793504173819426069== Content-Type: multipart/alternative; boundary="------------070001060502070002070100" This is a multi-part message in MIME format. --------------070001060502070002070100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There was one point with windows XP, where if I didn't have the cable attached to the video card, it would do something strange... maybe not initialize, or maybe I couldn't switch to the other port later (I planned on using vga for domu, and dvi for dom0 so my monitor's switch button would work). So maybe try things like that. And I would do any future tests with only one card physically plugged in until you find something new and can test with both. You could also try putting both cards in slots 1-4, instead of one in 5,6,7. But when trying other drivers, domu settings, etc. I'd use just one card. And FYI, in winxp, I could only get my domu to show graphics if I set "stdvga=1" in the config. Maybe you can try that. But it is just a guess (as it was when I first found it worked in XP). My windows 7 and 8 worked fine without that setting. I also can hear my fan change when I start my domu... it lets you know it is working :) Did the fan speed change before, when you had both cards in, and one passed through? But either way, it sounds like you got some new information, even if vague... that one vs 2 GPUs has a different effect. I hope it leads to the answer. On 2013-03-12 12:55, Matthew Dean wrote: > My guess is that they are on different bridges. I've read that for > this board if you use only the first CPU socket then you'll only get > access to pcie slots 1 through 4. Slots 5, 6 and 7 simply won't work > at all. Passing through both cards still does not work but this time > I don't get a BSOD, the display simply never turns on. I can hear the > fan speed of the card change however at the precise point where the > VNC window stops showing any change so there is something going on > here. I've just pulled out the card in slot 5 and tried to pass > through the one remaining card and that has the same result, with the > display never turning on. > > Matt > > On 12/03/2013 11:41, Peter Maloney wrote: >> Okay that is enormous output :D >> >> And I'm not sure what to say about it... hopefully someone else >> reading it can read it better than I can. >> >> Your bridges: >> >> *00:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >> Express Root Port 2a (rev 07) >> *80:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >> Express Root Port 2a (rev 07) >> >> Your GPUs: >> ... >> +-[0000:*80*]-+-00.0-[81]-- >> | +-*02.0*-[83]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> | | \-00.1 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >> \-[0000:*00*]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 >> +-*02.0*-[03]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> | \-00.1 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >> >> So you would be fine with PCI bridges if that 80 vs 00 is really >> different bridges and not just same ones seen by different CPUSs. >> >> I can look at many older Xeons and they all show just one set of >> bridges, and one very new one (newer socket) has the same thing as >> yours. But I don't use IOMMU on those, so I don't know what effect it >> has. >> >> I kinda think they are the same bridge, which would be bad. I don't >> know how to test it... pull out a CPU? ;) find some other detail that >> has IDs? disable one in the bios (unlikely)? or you could test this >> by passing through both cards to the same domu... This would be a >> good test (and matches what the other thread was about... his worked >> with passing both through) >> >> >> >> >> On 2013-03-12 11:32, Matthew Dean wrote: >>> As requested, >>> >>> lspci >>> >>> ############################################################################################################## >>> >>> 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) >>> 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 1a (rev 07) >>> 00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 1b (rev 07) >>> 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 2a (rev 07) >>> 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 3a in PCI Express Mode (rev 07) >>> 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address >>> Map, VTd_Misc, System Management (rev 07) >>> 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control >>> Status and Global Errors (rev 07) >>> 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) >>> 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Virtual Root Port (rev 06) >>> 00:16.0 Communication controller: Intel Corporation C600/X79 series >>> chipset MEI Controller #1 (rev 05) >>> 00:16.1 Communication controller: Intel Corporation C600/X79 series >>> chipset MEI Controller #2 (rev 05) >>> 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset >>> USB2 Enhanced Host Controller #2 (rev 06) >>> 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High >>> Definition Audio Controller (rev 06) >>> 00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 1 (rev b6) >>> 00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 2 (rev b6) >>> 00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 3 (rev b6) >>> 00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 4 (rev b6) >>> 00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 5 (rev b6) >>> 00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 7 (rev b6) >>> 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset >>> USB2 Enhanced Host Controller #1 (rev 06) >>> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) >>> 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC >>> Controller (rev 06) >>> 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset >>> 6-Port SATA AHCI Controller (rev 06) >>> 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host >>> Controller (rev 06) >>> 03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT [Radeon HD 7970] >>> 03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT >>> HDMI Audio [Radeon HD 7970 Series] >>> 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 >>> chipset 4-Port SATA Storage Control Unit (rev 06) >>> 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit >>> Network Connection >>> 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit >>> Network Connection >>> 08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed >>> USB Host Controller >>> 09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed >>> USB Host Controller >>> 0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 >>> (rev 10) >>> 0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series >>> Firewire Controller (rev 01) >>> 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link 0 (rev 07) >>> 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 0 (rev 07) >>> 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 0 (rev 07) >>> 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link 1 (rev 07) >>> 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 1 (rev 07) >>> 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 1 (rev 07) >>> 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 0 (rev 07) >>> 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 1 (rev 07) >>> 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 2 (rev 07) >>> 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 3 (rev 07) >>> 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Interrupt Control Registers (rev 07) >>> 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Semaphore and Scratchpad Configuration Registers (rev 07) >>> 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller System Address Decoder 0 (rev 07) >>> 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System >>> Address Decoder (rev 07) >>> 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller System Address Decoder 1 (rev 07) >>> 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Processor Home Agent (rev 07) >>> 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 >>> Processor Home Agent Performance Monitoring (rev 07) >>> 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Registers (rev 07) >>> 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller RAS Registers (rev 07) >>> 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 0 (rev 07) >>> 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 1 (rev 07) >>> 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 2 (rev 07) >>> 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 3 (rev 07) >>> 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 4 (rev 07) >>> 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) >>> 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) >>> 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 0 (rev 07) >>> 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 1 (rev 07) >>> 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) >>> 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) >>> 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 2 (rev 07) >>> 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 3 (rev 07) >>> 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO >>> (rev 07) >>> 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe >>> (rev 07) >>> 7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >>> to PCI Express Performance Monitor (rev 07) >>> 7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 >>> QuickPath Interconnect Agent Ring Registers (rev 07) >>> 7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >>> to QuickPath Interconnect Link 0 Performance Monitor (rev 07) >>> 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 1 Performance Monitor (rev 07) >>> 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI >>> Express Mode (rev 07) >>> 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 1a (rev 07) >>> 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 2a (rev 07) >>> 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 3a in PCI Express Mode (rev 07) >>> 80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address >>> Map, VTd_Misc, System Management (rev 07) >>> 80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control >>> Status and Global Errors (rev 07) >>> 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) >>> 83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT [Radeon HD 7970] >>> 83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT >>> HDMI Audio [Radeon HD 7970 Series] >>> ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link 0 (rev 07) >>> ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 0 (rev 07) >>> ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 0 (rev 07) >>> ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link 1 (rev 07) >>> ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 1 (rev 07) >>> ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 1 (rev 07) >>> ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 0 (rev 07) >>> ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 1 (rev 07) >>> ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 2 (rev 07) >>> ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 3 (rev 07) >>> ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Interrupt Control Registers (rev 07) >>> ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Semaphore and Scratchpad Configuration Registers (rev 07) >>> ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller System Address Decoder 0 (rev 07) >>> ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System >>> Address Decoder (rev 07) >>> ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller System Address Decoder 1 (rev 07) >>> ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Processor Home Agent (rev 07) >>> ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 >>> Processor Home Agent Performance Monitoring (rev 07) >>> ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Registers (rev 07) >>> ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller RAS Registers (rev 07) >>> ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 0 (rev 07) >>> ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 1 (rev 07) >>> ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 2 (rev 07) >>> ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 3 (rev 07) >>> ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 4 (rev 07) >>> ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) >>> ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) >>> ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 0 (rev 07) >>> ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 1 (rev 07) >>> ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) >>> ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) >>> ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 2 (rev 07) >>> ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 3 (rev 07) >>> ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO >>> (rev 07) >>> ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe >>> (rev 07) >>> ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >>> to PCI Express Performance Monitor (rev 07) >>> ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 >>> QuickPath Interconnect Agent Ring Registers (rev 07) >>> ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >>> to QuickPath Interconnect Link 0 Performance Monitor (rev 07) >>> ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 1 Performance Monitor (rev 07) >>> >>> ############################################################################################################## >>> >>> lspci -tv >>> >>> ############################################################################################################## >>> >>> -+-[0000:ff]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 >>> | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >>> | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >>> | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 >>> | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >>> | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >>> | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 0 >>> | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 1 >>> | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 2 >>> | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 3 >>> | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt >>> Control Registers >>> | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and >>> Scratchpad Configuration Registers >>> | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller System Address Decoder 0 >>> | +-0c.7 Intel Corporation Xeon E5/Core i7 System >>> Address Decoder >>> | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller System Address Decoder 1 >>> | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor >>> Home Agent >>> | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor >>> Home Agent Performance Monitoring >>> | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Registers >>> | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller RAS Registers >>> | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 0 >>> | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 1 >>> | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 2 >>> | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 3 >>> | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 4 >>> | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 0 >>> | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 1 >>> | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 0 >>> | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 1 >>> | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 2 >>> | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 3 >>> | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 2 >>> | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 3 >>> | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO >>> | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe >>> | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI >>> Express Performance Monitor >>> | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath >>> Interconnect Agent Ring Registers >>> | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 0 Performance Monitor >>> | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 1 Performance Monitor >>> +-[0000:80]-+-00.0-[81]-- >>> | +-01.0-[82]-- >>> | +-02.0-[83]--+-00.0 Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT [Radeon HD 7970] >>> | | \-00.1 Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >>> | +-03.0-[84]-- >>> | +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, >>> VTd_Misc, System Management >>> | +-05.2 Intel Corporation Xeon E5/Core i7 Control >>> Status and Global Errors >>> | \-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC >>> +-[0000:7f]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 >>> | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >>> | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >>> | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 >>> | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >>> | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >>> | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 0 >>> | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 1 >>> | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 2 >>> | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 3 >>> | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt >>> Control Registers >>> | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and >>> Scratchpad Configuration Registers >>> | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller System Address Decoder 0 >>> | +-0c.7 Intel Corporation Xeon E5/Core i7 System >>> Address Decoder >>> | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller System Address Decoder 1 >>> | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor >>> Home Agent >>> | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor >>> Home Agent Performance Monitoring >>> | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Registers >>> | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller RAS Registers >>> | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 0 >>> | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 1 >>> | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 2 >>> | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 3 >>> | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 4 >>> | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 0 >>> | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 1 >>> | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 0 >>> | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 1 >>> | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 2 >>> | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 3 >>> | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 2 >>> | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 3 >>> | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO >>> | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe >>> | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI >>> Express Performance Monitor >>> | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath >>> Interconnect Agent Ring Registers >>> | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 0 Performance Monitor >>> | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 1 Performance Monitor >>> \-[0000:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 >>> +-01.0-[01]-- >>> +-01.1-[02]-- >>> +-02.0-[03]--+-00.0 Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT [Radeon HD 7970] >>> | \-00.1 Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >>> +-03.0-[04]-- >>> +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, >>> VTd_Misc, System Management >>> +-05.2 Intel Corporation Xeon E5/Core i7 Control >>> Status and Global Errors >>> +-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC >>> +-11.0-[05]----00.0 Intel Corporation C602 chipset >>> 4-Port SATA Storage Control Unit >>> +-16.0 Intel Corporation C600/X79 series chipset MEI >>> Controller #1 >>> +-16.1 Intel Corporation C600/X79 series chipset MEI >>> Controller #2 >>> +-1a.0 Intel Corporation C600/X79 series chipset USB2 >>> Enhanced Host Controller #2 >>> +-1b.0 Intel Corporation C600/X79 series chipset High >>> Definition Audio Controller >>> +-1c.0-[06]----00.0 Intel Corporation 82574L Gigabit >>> Network Connection >>> +-1c.1-[07]----00.0 Intel Corporation 82574L Gigabit >>> Network Connection >>> +-1c.2-[08]----00.0 ASMedia Technology Inc. ASM1042 >>> SuperSpeed USB Host Controller >>> +-1c.3-[09]----00.0 ASMedia Technology Inc. ASM1042 >>> SuperSpeed USB Host Controller >>> +-1c.4-[0a]----00.0 Marvell Technology Group Ltd. >>> Device 9230 >>> +-1c.6-[0b]----00.0 VIA Technologies, Inc. VT6315 >>> Series Firewire Controller >>> +-1d.0 Intel Corporation C600/X79 series chipset USB2 >>> Enhanced Host Controller #1 >>> +-1e.0-[0c]-- >>> +-1f.0 Intel Corporation C600/X79 series chipset LPC >>> Controller >>> +-1f.2 Intel Corporation C600/X79 series chipset >>> 6-Port SATA AHCI Controller >>> \-1f.3 Intel Corporation C600/X79 series chipset SMBus >>> Host Controller >>> >>> ############################################################################################################## >>> >>> I'm going to try passing through both cards and see if that works as >>> well as passing through just the one but with only one card >>> present. I've had a dig for the thread your talking about but I >>> cannot find it. If anybody else knows if it still exists somewhere >>> I'd be grateful if you could let me know. >>> >>> Thanks again for your help. >>> >>> Matt >>> >>> On 11/03/2013 18:16, Peter Maloney wrote: >>>> Ah, because you have 2 cpus and 2 cards, can you post output of >>>> "lspci -tv" and "lspci"? There was one guy who could pass through >>>> one card, but when he physically added the 2nd card in the machine, >>>> the same config with the first card wouldn't work any more because >>>> the 2 cards were on the same PCI bridge. And he could pass through >>>> both and have them work, but not just one of them at a time. (I >>>> have since cleaned out my email box, and so I can't find the old >>>> thread) >>>> >>>> So you see on my system, the "02.0" bridge is separate from "0c.0", >>>> so I don't have a problem. >>>> >>>> -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI >>>> to PCI bridge (external gfx0 port B) >>>> +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O >>>> Memory Management Unit (IOMMU) >>>> +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee >>>> ATI RV370 5B60 [Radeon X300 (PCIE)] >>>> | \-00.1 Advanced Micro Devices [AMD] nee >>>> ATI RV370 [Radeon X300SE] >>>> +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB >>>> 3.0 Host Controller >>>> +-0a.0-[03]----00.0 Marvell Technology Group Ltd. >>>> 88SE9172 SATA 6Gb/s Controller >>>> +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee >>>> ATI Juniper XT [AMD Radeon HD 6000 Series] >>>> | \-00.1 Advanced Micro Devices [AMD] nee >>>> ATI Juniper HDMI Audio [Radeon HD 5700 Series] >>>> >>>> >>>> *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 >>>> PCI to PCI bridge (PCI express gpp port B) >>>> 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>>> to PCI bridge (PCI express gpp port H) >>>> 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>>> to PCI bridge (external gfx1 port A) >>>> *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 >>>> >>>> >>>> >>>> On 03/11/2013 06:45 PM, Matthew Dean wrote: >>>>> That was a good suggestion, I've just tried passing through a USB >>>>> controller and that worked fine. The driver installed correctly >>>>> and I can use devices attached to the relevant ports. The problem >>>>> therefore seems to be to do with gpu passthrough specifically. >>>>> I'm just going to describe my system and some settings I have in >>>>> the bios as this is starting to feel like a system specific >>>>> problem. The system is >>>>> >>>>> Asus Z9PE-D8 WS motherboard (chipset is intel C602) >>>>> Dual Xeon 2620 >>>>> 64 GB non-ecc memory >>>>> Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm >>>>> trying to pass through) >>>>> >>>>> In the bios I have vt-d enabled. I also have sub-feature settings >>>>> for "Coherency Support" and "ATS Support" which are disabled by >>>>> default. I've tried all combinations of these enabled and >>>>> disabled. If I enable "ATS Support" I do however have to add the >>>>> option "iommu=no-qinval,no-intremap" to the xen boot otherwise the >>>>> system hangs as per this thread >>>>> . >>>>> If the problem is to no with these options then I think I have a >>>>> problem. >>>>> >>>>> Has anybody got any thoughts? >>>>> >>>>> Matt >>>>> >>>>> On 11/03/2013 14:57, Peter Maloney wrote: >>>>>> Did you try other devices, such as your onboard sound card, your >>>>>> onboard USB controllers, etc.? Maybe your board doesn't do >>>>>> passthrough properly. >>>>>> >>>>>> Or did you try another PCIe port for the card? Maybe there are >>>>>> bugs where the addresses overlap with some other device, but in >>>>>> another slot it wouldn't happen. >>>>>> >>>>>> >>>>>> On 2013-03-11 14:48, Matthew Dean wrote: >>>>>>> First of all, thank you for the suggestions. I've now >>>>>>> re-installed windows and I've tried driver versions 12.3, 12.8 >>>>>>> and 13.1 all with and without the CCC as I read in various >>>>>>> places that it can cause problems. For 13.1 I never get >>>>>>> anywhere close as per my previous messages. For 12.3 and 12.8 I >>>>>>> at least get a BSOD, >>>>>>> >>>>>>> ####################################################################### >>>>>>> >>>>>>> A problem has been detected ... >>>>>>> >>>>>>> Attempt to reset the display driver and recover from timeout failed. >>>>>>> >>>>>>> If this is ... >>>>>>> >>>>>>> Techinal information: >>>>>>> >>>>>>> *** STOP: 0x00000116 >>>>>>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>>>>>> >>>>>>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>>>>>> FFFFF88003D8E000, Datestamp 4f597fca >>>>>>> >>>>>>> ####################################################################### >>>>>>> >>>>>>> Does anybody have any further ideas? >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> On 07/03/2013 21:42, John Sherwood wrote: >>>>>>>> (and I should probably mention that it has been my experience >>>>>>>> that that is the expected and correct behavior) >>>>>>>> >>>>>>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>>>>>> > wrote: >>>>>>>> >>>>>>>> Having the windows logo freeze in the VNC window has been >>>>>>>> my experience with GPU passthrough as well. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I believe that the Windows logo freezing in the vnc >>>>>>>> window is normal behaviour when secondary GPU >>>>>>>> passthrough is working as it should, since the display >>>>>>>> should be handed over to the GPU. At least that was the >>>>>>>> case before when I was passing through a HD6850 card as >>>>>>>> secondary to win7 using xl. But you should expect >>>>>>>> output on the GPU, of course. >>>>>>>> >>>>>>>> Have you tried different versions of the catalyst >>>>>>>> driver? I think that some users have reported problems >>>>>>>> with the latest one (13-something). >>>>>>>> >>>>>>>> Regards, >>>>>>>> Andreas >>>>>>>> >>>>>>>> 2013/3/7 Matthew Dean >>>>>>> > >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've managed to get a windows 7 x64 hvm to boot and >>>>>>>> install and I'm now looking to pass through a HD >>>>>>>> 7970 as a secondary GPU. in order to prepare the >>>>>>>> devices for passthrough I've used >>>>>>>> >>>>>>>> xl pci-assignable-add 83:00.0 >>>>>>>> xl pci-assignable-add 83:00.1 >>>>>>>> >>>>>>>> Where I've identified the device pci ids using >>>>>>>> lspci. This works fine and the devices appear when >>>>>>>> I call 'xl pci-assignable-list'. After adding them >>>>>>>> to the vm config (see below) I was able to get the >>>>>>>> vm to boot and the devices appeared in device >>>>>>>> manager. Installing the ATI drivers however has >>>>>>>> meant that on further boots the machine never gets >>>>>>>> past the windows logo in the VNC window and no >>>>>>>> output is generated from the ATI card. It simply >>>>>>>> freezes there and the only way I can get back into >>>>>>>> windows is via safe mode, even after uninstalling >>>>>>>> the ATI software. >>>>>>>> >>>>>>>> Has anybody else experienced similar issues or have >>>>>>>> any advice as to how to get this to work? I'm a >>>>>>>> bit stumped and the wiki implies that this should >>>>>>>> 'just work'. >>>>>>>> >>>>>>>> Thank you in advance for any help. >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> Here is my machine config >>>>>>>> >>>>>>>> ########################################################### >>>>>>>> >>>>>>>> builder='hvm' >>>>>>>> memory = 2048 >>>>>>>> name = 'Windows7Test' >>>>>>>> >>>>>>>> vcpus=4 >>>>>>>> pae=1 >>>>>>>> acpi=1 >>>>>>>> apic=1 >>>>>>>> >>>>>>>> disk = [ >>>>>>>> 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>>>>>> pci = [ '83:00.0' , '83:00.1' ] >>>>>>>> >>>>>>>> on_poweroff = 'destroy' >>>>>>>> on_reboot = 'restart' >>>>>>>> on_crash = 'destroy' >>>>>>>> >>>>>>>> boot='cd' >>>>>>>> >>>>>>>> sdl=0 >>>>>>>> vnc=1 >>>>>>>> vncconsole=0 >>>>>>>> vncpasswd='' >>>>>>>> vnclisten='172.24.226.84' >>>>>>>> >>>>>>>> stdvga=0 >>>>>>>> >>>>>>>> serial='pty' >>>>>>>> usbdevice='tablet' >>>>>>>> >>>>>>>> gfx_passthru=0 >>>>>>>> pci_power_mgmt=1 >>>>>>>> xen_platform_pci=1 >>>>>>>> pci_msitranslate=1 >>>>>>>> viridian=1 >>>>>>>> hpet=1 >>>>>>>> >>>>>>>> ############################################################ >>>>>>>> >>>>>>>> And the vm produces the following qemu log in >>>>>>>> /var/log/xen/ >>>>>>>> >>>>>>>> ############################################################ >>>>>>>> >>>>>>>> domid: 4 >>>>>>>> -videoram option does not work with cirrus vga >>>>>>>> device model. Videoram set to 4M. >>>>>>>> Strip off blktap sub-type prefix to >>>>>>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>>>>>> Using file /xen-guests/img/windows7Test.img in >>>>>>>> read-write mode >>>>>>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>>>>>> Watching /local/domain/0/device-model/4/command >>>>>>>> Watching /local/domain/4/cpu >>>>>>>> char device redirected to /dev/pts/3 >>>>>>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>>>>>> shared page at pfn feffd >>>>>>>> buffered io page at pfn feffb >>>>>>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>>>>>> 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/4/xen_extended_power_mgmt): >>>>>>>> read error >>>>>>>> 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. >>>>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>>>> count: 0, size: 0 >>>>>>>> xs_read(/local/domain/4/log-throttling): read error >>>>>>>> qemu: ignoring not-understood drive >>>>>>>> `/local/domain/4/log-throttling' >>>>>>>> medium change watch on >>>>>>>> `/local/domain/4/log-throttling' - unknown device, >>>>>>>> ignored >>>>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>>>> count: 0, size: 0 >>>>>>>> dm-command: hot insert pass-through pci dev >>>>>>>> register_real_device: Assigning real physical >>>>>>>> device 83:00.0 ... >>>>>>>> register_real_device: Enable MSI translation via >>>>>>>> per device option >>>>>>>> register_real_device: Enable power management >>>>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>>>> 0x83:0x0.0x0 >>>>>>>> pt_register_regions: IO region registered >>>>>>>> (size=0x10000000 base_addr=0xe000000c) >>>>>>>> pt_register_regions: IO region registered >>>>>>>> (size=0x00040000 base_addr=0xf0000004) >>>>>>>> pt_register_regions: IO region registered >>>>>>>> (size=0x00000100 base_addr=0x0000f001) >>>>>>>> pt_register_regions: Expansion ROM registered >>>>>>>> (size=0x00020000 base_addr=0xf0040000) >>>>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>>>> pci_intx: intx=1 >>>>>>>> register_real_device: Real physical device 83:00.0 >>>>>>>> registered successfuly! >>>>>>>> IRQ type = MSI-INTx >>>>>>>> dm-command: hot insert pass-through pci dev >>>>>>>> register_real_device: Assigning real physical >>>>>>>> device 83:00.1 ... >>>>>>>> register_real_device: Enable MSI translation via >>>>>>>> per device option >>>>>>>> register_real_device: Enable power management >>>>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>>>> 0x83:0x0.0x1 >>>>>>>> pt_register_regions: IO region registered >>>>>>>> (size=0x00004000 base_addr=0xf0060004) >>>>>>>> pt_msi_setup: msi mapped with pirq 66 >>>>>>>> pci_intx: intx=2 >>>>>>>> register_real_device: Real physical device 83:00.1 >>>>>>>> registered successfuly! >>>>>>>> IRQ type = MSI-INTx >>>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=1 >>>>>>>> cirrus vga map change while on lfb mode >>>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=1 >>>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=1 >>>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>>> index=4 first_map=1 >>>>>>>> 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. >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=0 >>>>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>>>> index=4 first_map=0 >>>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=0 >>>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>>> index=4 first_map=0 >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=0 >>>>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>>>> index=4 first_map=0 >>>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=0 >>>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>>> index=4 first_map=0 >>>>>>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>>>>>> MSI-INTx translation >>>>>>>> pci_intx: intx=1 >>>>>>>> pt_msi_disable: Unmap msi with pirq 67 >>>>>>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>>>> pt_msi_update: Update msi with pirq 67 gvec b0 >>>>>>>> gflags 130f >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=0 >>>>>>>> >>>>>>>> ###################################################################### >>>>>>>> >>>>>>>> _____________________ >>>>>>>> >> > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --------------070001060502070002070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
There was one point with windows XP, where if I didn't have the cable attached to the video card, it would do something strange... maybe not initialize, or maybe I couldn't switch to the other port later (I planned on using vga for domu, and dvi for dom0 so my monitor's switch button would work). So maybe try things like that.

And I would do any future tests with only one card physically plugged in until you find something new and can test with both. You could also try putting both cards in slots 1-4, instead of one in 5,6,7. But when trying other drivers, domu settings, etc. I'd use just one card.

And FYI, in winxp, I could only get my domu to show graphics if I set "stdvga=1" in the config. Maybe you can try that. But it is just a guess (as it was when I first found it worked in XP). My windows 7 and 8 worked fine without that setting.

I also can hear my fan change when I start my domu... it lets you know it is working :)
Did the fan speed change before, when you had both cards in, and one passed through?

But either way, it sounds like you got some new information, even if vague... that one vs 2 GPUs has a different effect. I hope it leads to the answer.

On 2013-03-12 12:55, Matthew Dean wrote:
My guess is that they are on different bridges.  I've read that for this board if you use only the first CPU socket then you'll only get access to pcie slots 1 through 4.  Slots 5, 6 and 7 simply won't work at all.  Passing through both cards still does not work but this time I don't get a BSOD, the display simply never turns on.  I can hear the fan speed of the card change however at the precise point where the VNC window stops showing any change so there is something going on here.  I've just pulled out the card in slot 5 and tried to pass through the one remaining card and that has the same result, with the display never turning on.

Matt

On 12/03/2013 11:41, Peter Maloney wrote:
Okay that is enormous output :D

And I'm not sure what to say about it... hopefully someone else reading it can read it better than I can.

Your bridges:

00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)

Your GPUs:
...
  +-[0000:80]-+-00.0-[81]--
  |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
   |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
  \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
              +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
              |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]

So you would be fine with PCI bridges if that 80 vs 00 is really different bridges and not just same ones seen by different CPUSs.

I can look at many older Xeons and they all show just one set of bridges, and one very new one (newer socket) has the same thing as yours. But I don't use IOMMU on those, so I don't know what effect it has.

I kinda think they are the same bridge, which would be bad. I don't know how to test it... pull out a CPU? ;) find some other detail that has IDs? disable one in the bios (unlikely)? or you could test this by passing through both cards to the same domu... This would be a good test (and matches what the other thread was about... his worked with passing both through)




On 2013-03-12 11:32, Matthew Dean wrote:
As requested,

lspci

##############################################################################################################

00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07)
00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06)
00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05)
00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05)
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06)
00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06)
00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6)
00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6)
00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6)
00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6)
00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6)
00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06)
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06)
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10)
0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01)
7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07)
80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)

##############################################################################################################

lspci -tv

##############################################################################################################

-+-[0000:ff]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-00.0-[81]--
 |           +-01.0-[82]--
 |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
 |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
 |           +-03.0-[84]--
 |           +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
 |           \-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
             +-01.0-[01]--
             +-01.1-[02]--
             +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
             |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
             +-03.0-[04]--
             +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
             +-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
             +-11.0-[05]----00.0  Intel Corporation C602 chipset 4-Port SATA Storage Control Unit
             +-16.0  Intel Corporation C600/X79 series chipset MEI Controller #1
             +-16.1  Intel Corporation C600/X79 series chipset MEI Controller #2
             +-1a.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2
             +-1b.0  Intel Corporation C600/X79 series chipset High Definition Audio Controller
             +-1c.0-[06]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.1-[07]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.2-[08]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.3-[09]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.4-[0a]----00.0  Marvell Technology Group Ltd. Device 9230
             +-1c.6-[0b]----00.0  VIA Technologies, Inc. VT6315 Series Firewire Controller
             +-1d.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1
             +-1e.0-[0c]--
             +-1f.0  Intel Corporation C600/X79 series chipset LPC Controller
             +-1f.2  Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation C600/X79 series chipset SMBus Host Controller

##############################################################################################################

I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present.  I've had a dig for the thread your talking about but I cannot find it.  If anybody else knows if it still exists somewhere I'd be grateful if you could let me know.

Thanks again for your help.

Matt

On 11/03/2013 18:16, Peter Maloney wrote:
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_____________________




_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------
--------------070001060502070002070100-- --===============8793504173819426069== 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 --===============8793504173819426069==-- From xen-users-bounces@lists.xen.org Tue Mar 12 13:26:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 13:26: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 1UFPDS-0005Ke-W6; Tue, 12 Mar 2013 13:26:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFPDQ-0005KW-1L for xen-users@lists.xen.org; Tue, 12 Mar 2013 13:26:04 +0000 Received: from [85.158.138.51:23652] by server-12.bemta-3.messagelabs.com id AB/EC-01357-1EC2F315; Tue, 12 Mar 2013 13:25:53 +0000 X-Env-Sender: peter.maloney@brockmann-consult.de X-Msg-Ref: server-3.tower-174.messagelabs.com!1363094738!23438614!1 X-Originating-IP: [212.227.126.186] X-SpamReason: No, hits=3.2 required=7.0 tests=sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNTgyMzY=\n,sa_preprocessor: QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNTgyMzY=\n,BODY_RANDOM_LONG, HTML_40_50,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RATWARE_GECKO_BUILD X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13061 invoked from network); 12 Mar 2013 13:25:38 -0000 Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.126.186) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 13:25:38 -0000 Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LdyJ6-1UYDAX2vSW-00prlF; Tue, 12 Mar 2013 14:25:33 +0100 Message-ID: <513F2CCD.8040705@brockmann-consult.de> Date: Tue, 12 Mar 2013 14:25:33 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Matthew Dean References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> <513F0426.1080808@cam.ac.uk> <513F1467.2010202@brockmann-consult.de> <513F17AA.6050406@cam.ac.uk> In-Reply-To: <513F17AA.6050406@cam.ac.uk> X-Enigmail-Version: 1.5 X-Provags-ID: V02:K0:N7ch/aTx6LmD6v29kcgbQKNQepP7kugk/Kw/0KP8cH9 ZNR3ND8FMm9/9gBNdFboEy2OhY5ongdDHLUwqsNiqQUhe6Nu9O qLu2Wdl/8RiSBKKdYiOX7vnxHPNrt8f4t8kAmVJbhozgTLXJlT k2afjbZXXMa3joS10zElPlQBgYEfXrHenHS2t0fghFVp5ztz+i tAICCNnnqhnJ01F2p7Cl3Mp3Z7nGuIQQtnqjJNexc5SAUXTmcT Y0EW1Wmg/75QujsuXqv579fUrg75Q0wyQfDr5pGvFu+QiUDrz7 ykjBr3p5of6mErI4zcbgv7mVqVSI74GbJlNWyXu9m5KxPwQeWD ovzXR2u9XK+svNriTTW4P4zSQY5VsKcURf9DcEWCf Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============8793504173819426069==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============8793504173819426069== Content-Type: multipart/alternative; boundary="------------070001060502070002070100" This is a multi-part message in MIME format. --------------070001060502070002070100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There was one point with windows XP, where if I didn't have the cable attached to the video card, it would do something strange... maybe not initialize, or maybe I couldn't switch to the other port later (I planned on using vga for domu, and dvi for dom0 so my monitor's switch button would work). So maybe try things like that. And I would do any future tests with only one card physically plugged in until you find something new and can test with both. You could also try putting both cards in slots 1-4, instead of one in 5,6,7. But when trying other drivers, domu settings, etc. I'd use just one card. And FYI, in winxp, I could only get my domu to show graphics if I set "stdvga=1" in the config. Maybe you can try that. But it is just a guess (as it was when I first found it worked in XP). My windows 7 and 8 worked fine without that setting. I also can hear my fan change when I start my domu... it lets you know it is working :) Did the fan speed change before, when you had both cards in, and one passed through? But either way, it sounds like you got some new information, even if vague... that one vs 2 GPUs has a different effect. I hope it leads to the answer. On 2013-03-12 12:55, Matthew Dean wrote: > My guess is that they are on different bridges. I've read that for > this board if you use only the first CPU socket then you'll only get > access to pcie slots 1 through 4. Slots 5, 6 and 7 simply won't work > at all. Passing through both cards still does not work but this time > I don't get a BSOD, the display simply never turns on. I can hear the > fan speed of the card change however at the precise point where the > VNC window stops showing any change so there is something going on > here. I've just pulled out the card in slot 5 and tried to pass > through the one remaining card and that has the same result, with the > display never turning on. > > Matt > > On 12/03/2013 11:41, Peter Maloney wrote: >> Okay that is enormous output :D >> >> And I'm not sure what to say about it... hopefully someone else >> reading it can read it better than I can. >> >> Your bridges: >> >> *00:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >> Express Root Port 2a (rev 07) >> *80:02.0* PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >> Express Root Port 2a (rev 07) >> >> Your GPUs: >> ... >> +-[0000:*80*]-+-00.0-[81]-- >> | +-*02.0*-[83]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> | | \-00.1 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >> \-[0000:*00*]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 >> +-*02.0*-[03]--+-00.0 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT [Radeon HD 7970] >> | \-00.1 Advanced Micro Devices [AMD] nee >> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >> >> So you would be fine with PCI bridges if that 80 vs 00 is really >> different bridges and not just same ones seen by different CPUSs. >> >> I can look at many older Xeons and they all show just one set of >> bridges, and one very new one (newer socket) has the same thing as >> yours. But I don't use IOMMU on those, so I don't know what effect it >> has. >> >> I kinda think they are the same bridge, which would be bad. I don't >> know how to test it... pull out a CPU? ;) find some other detail that >> has IDs? disable one in the bios (unlikely)? or you could test this >> by passing through both cards to the same domu... This would be a >> good test (and matches what the other thread was about... his worked >> with passing both through) >> >> >> >> >> On 2013-03-12 11:32, Matthew Dean wrote: >>> As requested, >>> >>> lspci >>> >>> ############################################################################################################## >>> >>> 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) >>> 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 1a (rev 07) >>> 00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 1b (rev 07) >>> 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 2a (rev 07) >>> 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 3a in PCI Express Mode (rev 07) >>> 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address >>> Map, VTd_Misc, System Management (rev 07) >>> 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control >>> Status and Global Errors (rev 07) >>> 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) >>> 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Virtual Root Port (rev 06) >>> 00:16.0 Communication controller: Intel Corporation C600/X79 series >>> chipset MEI Controller #1 (rev 05) >>> 00:16.1 Communication controller: Intel Corporation C600/X79 series >>> chipset MEI Controller #2 (rev 05) >>> 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset >>> USB2 Enhanced Host Controller #2 (rev 06) >>> 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High >>> Definition Audio Controller (rev 06) >>> 00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 1 (rev b6) >>> 00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 2 (rev b6) >>> 00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 3 (rev b6) >>> 00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 4 (rev b6) >>> 00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 5 (rev b6) >>> 00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI >>> Express Root Port 7 (rev b6) >>> 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset >>> USB2 Enhanced Host Controller #1 (rev 06) >>> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) >>> 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC >>> Controller (rev 06) >>> 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset >>> 6-Port SATA AHCI Controller (rev 06) >>> 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host >>> Controller (rev 06) >>> 03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT [Radeon HD 7970] >>> 03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT >>> HDMI Audio [Radeon HD 7970 Series] >>> 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 >>> chipset 4-Port SATA Storage Control Unit (rev 06) >>> 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit >>> Network Connection >>> 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit >>> Network Connection >>> 08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed >>> USB Host Controller >>> 09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed >>> USB Host Controller >>> 0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 >>> (rev 10) >>> 0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series >>> Firewire Controller (rev 01) >>> 7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link 0 (rev 07) >>> 7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 0 (rev 07) >>> 7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 0 (rev 07) >>> 7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link 1 (rev 07) >>> 7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 1 (rev 07) >>> 7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 1 (rev 07) >>> 7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 0 (rev 07) >>> 7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 1 (rev 07) >>> 7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 2 (rev 07) >>> 7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 3 (rev 07) >>> 7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Interrupt Control Registers (rev 07) >>> 7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Semaphore and Scratchpad Configuration Registers (rev 07) >>> 7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller System Address Decoder 0 (rev 07) >>> 7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System >>> Address Decoder (rev 07) >>> 7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> 7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller System Address Decoder 1 (rev 07) >>> 7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Processor Home Agent (rev 07) >>> 7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 >>> Processor Home Agent Performance Monitoring (rev 07) >>> 7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Registers (rev 07) >>> 7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller RAS Registers (rev 07) >>> 7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 0 (rev 07) >>> 7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 1 (rev 07) >>> 7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 2 (rev 07) >>> 7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 3 (rev 07) >>> 7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 4 (rev 07) >>> 7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) >>> 7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) >>> 7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 0 (rev 07) >>> 7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 1 (rev 07) >>> 7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) >>> 7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) >>> 7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 2 (rev 07) >>> 7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 3 (rev 07) >>> 7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO >>> (rev 07) >>> 7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe >>> (rev 07) >>> 7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >>> to PCI Express Performance Monitor (rev 07) >>> 7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 >>> QuickPath Interconnect Agent Ring Registers (rev 07) >>> 7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >>> to QuickPath Interconnect Link 0 Performance Monitor (rev 07) >>> 7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 1 Performance Monitor (rev 07) >>> 80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI >>> Express Mode (rev 07) >>> 80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 1a (rev 07) >>> 80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 2a (rev 07) >>> 80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI >>> Express Root Port 3a in PCI Express Mode (rev 07) >>> 80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address >>> Map, VTd_Misc, System Management (rev 07) >>> 80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control >>> Status and Global Errors (rev 07) >>> 80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) >>> 83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT [Radeon HD 7970] >>> 83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT >>> HDMI Audio [Radeon HD 7970 Series] >>> ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link 0 (rev 07) >>> ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 0 (rev 07) >>> ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 0 (rev 07) >>> ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link 1 (rev 07) >>> ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 1 (rev 07) >>> ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI >>> Link Reut 1 (rev 07) >>> ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 0 (rev 07) >>> ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 1 (rev 07) >>> ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 2 (rev 07) >>> ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power >>> Control Unit 3 (rev 07) >>> ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Interrupt Control Registers (rev 07) >>> ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Semaphore and Scratchpad Configuration Registers (rev 07) >>> ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller System Address Decoder 0 (rev 07) >>> ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System >>> Address Decoder (rev 07) >>> ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 (rev 07) >>> ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller System Address Decoder 1 (rev 07) >>> ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Processor Home Agent (rev 07) >>> ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 >>> Processor Home Agent Performance Monitoring (rev 07) >>> ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Registers (rev 07) >>> ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller RAS Registers (rev 07) >>> ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 0 (rev 07) >>> ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 1 (rev 07) >>> ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 2 (rev 07) >>> ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 3 (rev 07) >>> ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Target Address Decoder 4 (rev 07) >>> ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07) >>> ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07) >>> ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 0 (rev 07) >>> ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 1 (rev 07) >>> ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07) >>> ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07) >>> ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 2 (rev 07) >>> ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 >>> Integrated Memory Controller ERROR Registers 3 (rev 07) >>> ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO >>> (rev 07) >>> ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe >>> (rev 07) >>> ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >>> to PCI Express Performance Monitor (rev 07) >>> ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 >>> QuickPath Interconnect Agent Ring Registers (rev 07) >>> ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring >>> to QuickPath Interconnect Link 0 Performance Monitor (rev 07) >>> ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 1 Performance Monitor (rev 07) >>> >>> ############################################################################################################## >>> >>> lspci -tv >>> >>> ############################################################################################################## >>> >>> -+-[0000:ff]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 >>> | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >>> | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >>> | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 >>> | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >>> | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >>> | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 0 >>> | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 1 >>> | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 2 >>> | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 3 >>> | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt >>> Control Registers >>> | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and >>> Scratchpad Configuration Registers >>> | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller System Address Decoder 0 >>> | +-0c.7 Intel Corporation Xeon E5/Core i7 System >>> Address Decoder >>> | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller System Address Decoder 1 >>> | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor >>> Home Agent >>> | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor >>> Home Agent Performance Monitoring >>> | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Registers >>> | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller RAS Registers >>> | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 0 >>> | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 1 >>> | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 2 >>> | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 3 >>> | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 4 >>> | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 0 >>> | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 1 >>> | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 0 >>> | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 1 >>> | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 2 >>> | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 3 >>> | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 2 >>> | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 3 >>> | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO >>> | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe >>> | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI >>> Express Performance Monitor >>> | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath >>> Interconnect Agent Ring Registers >>> | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 0 Performance Monitor >>> | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 1 Performance Monitor >>> +-[0000:80]-+-00.0-[81]-- >>> | +-01.0-[82]-- >>> | +-02.0-[83]--+-00.0 Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT [Radeon HD 7970] >>> | | \-00.1 Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >>> | +-03.0-[84]-- >>> | +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, >>> VTd_Misc, System Management >>> | +-05.2 Intel Corporation Xeon E5/Core i7 Control >>> Status and Global Errors >>> | \-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC >>> +-[0000:7f]-+-08.0 Intel Corporation Xeon E5/Core i7 QPI Link 0 >>> | +-08.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >>> | +-08.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 >>> | +-09.0 Intel Corporation Xeon E5/Core i7 QPI Link 1 >>> | +-09.3 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >>> | +-09.4 Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 >>> | +-0a.0 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 0 >>> | +-0a.1 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 1 >>> | +-0a.2 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 2 >>> | +-0a.3 Intel Corporation Xeon E5/Core i7 Power Control >>> Unit 3 >>> | +-0b.0 Intel Corporation Xeon E5/Core i7 Interrupt >>> Control Registers >>> | +-0b.3 Intel Corporation Xeon E5/Core i7 Semaphore and >>> Scratchpad Configuration Registers >>> | +-0c.0 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.1 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.2 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0c.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller System Address Decoder 0 >>> | +-0c.7 Intel Corporation Xeon E5/Core i7 System >>> Address Decoder >>> | +-0d.0 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.1 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.2 Intel Corporation Xeon E5/Core i7 Unicast >>> Register 0 >>> | +-0d.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller System Address Decoder 1 >>> | +-0e.0 Intel Corporation Xeon E5/Core i7 Processor >>> Home Agent >>> | +-0e.1 Intel Corporation Xeon E5/Core i7 Processor >>> Home Agent Performance Monitoring >>> | +-0f.0 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Registers >>> | +-0f.1 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller RAS Registers >>> | +-0f.2 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 0 >>> | +-0f.3 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 1 >>> | +-0f.4 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 2 >>> | +-0f.5 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 3 >>> | +-0f.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Target Address Decoder 4 >>> | +-10.0 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 0 >>> | +-10.1 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 1 >>> | +-10.2 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 0 >>> | +-10.3 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 1 >>> | +-10.4 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 2 >>> | +-10.5 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller Channel 0-3 Thermal Control 3 >>> | +-10.6 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 2 >>> | +-10.7 Intel Corporation Xeon E5/Core i7 Integrated >>> Memory Controller ERROR Registers 3 >>> | +-11.0 Intel Corporation Xeon E5/Core i7 DDRIO >>> | +-13.0 Intel Corporation Xeon E5/Core i7 R2PCIe >>> | +-13.1 Intel Corporation Xeon E5/Core i7 Ring to PCI >>> Express Performance Monitor >>> | +-13.4 Intel Corporation Xeon E5/Core i7 QuickPath >>> Interconnect Agent Ring Registers >>> | +-13.5 Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 0 Performance Monitor >>> | \-13.6 Intel Corporation Xeon E5/Core i7 Ring to >>> QuickPath Interconnect Link 1 Performance Monitor >>> \-[0000:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2 >>> +-01.0-[01]-- >>> +-01.1-[02]-- >>> +-02.0-[03]--+-00.0 Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT [Radeon HD 7970] >>> | \-00.1 Advanced Micro Devices [AMD] nee >>> ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series] >>> +-03.0-[04]-- >>> +-05.0 Intel Corporation Xeon E5/Core i7 Address Map, >>> VTd_Misc, System Management >>> +-05.2 Intel Corporation Xeon E5/Core i7 Control >>> Status and Global Errors >>> +-05.4 Intel Corporation Xeon E5/Core i7 I/O APIC >>> +-11.0-[05]----00.0 Intel Corporation C602 chipset >>> 4-Port SATA Storage Control Unit >>> +-16.0 Intel Corporation C600/X79 series chipset MEI >>> Controller #1 >>> +-16.1 Intel Corporation C600/X79 series chipset MEI >>> Controller #2 >>> +-1a.0 Intel Corporation C600/X79 series chipset USB2 >>> Enhanced Host Controller #2 >>> +-1b.0 Intel Corporation C600/X79 series chipset High >>> Definition Audio Controller >>> +-1c.0-[06]----00.0 Intel Corporation 82574L Gigabit >>> Network Connection >>> +-1c.1-[07]----00.0 Intel Corporation 82574L Gigabit >>> Network Connection >>> +-1c.2-[08]----00.0 ASMedia Technology Inc. ASM1042 >>> SuperSpeed USB Host Controller >>> +-1c.3-[09]----00.0 ASMedia Technology Inc. ASM1042 >>> SuperSpeed USB Host Controller >>> +-1c.4-[0a]----00.0 Marvell Technology Group Ltd. >>> Device 9230 >>> +-1c.6-[0b]----00.0 VIA Technologies, Inc. VT6315 >>> Series Firewire Controller >>> +-1d.0 Intel Corporation C600/X79 series chipset USB2 >>> Enhanced Host Controller #1 >>> +-1e.0-[0c]-- >>> +-1f.0 Intel Corporation C600/X79 series chipset LPC >>> Controller >>> +-1f.2 Intel Corporation C600/X79 series chipset >>> 6-Port SATA AHCI Controller >>> \-1f.3 Intel Corporation C600/X79 series chipset SMBus >>> Host Controller >>> >>> ############################################################################################################## >>> >>> I'm going to try passing through both cards and see if that works as >>> well as passing through just the one but with only one card >>> present. I've had a dig for the thread your talking about but I >>> cannot find it. If anybody else knows if it still exists somewhere >>> I'd be grateful if you could let me know. >>> >>> Thanks again for your help. >>> >>> Matt >>> >>> On 11/03/2013 18:16, Peter Maloney wrote: >>>> Ah, because you have 2 cpus and 2 cards, can you post output of >>>> "lspci -tv" and "lspci"? There was one guy who could pass through >>>> one card, but when he physically added the 2nd card in the machine, >>>> the same config with the first card wouldn't work any more because >>>> the 2 cards were on the same PCI bridge. And he could pass through >>>> both and have them work, but not just one of them at a time. (I >>>> have since cleaned out my email box, and so I can't find the old >>>> thread) >>>> >>>> So you see on my system, the "02.0" bridge is separate from "0c.0", >>>> so I don't have a problem. >>>> >>>> -[0000:00]-+-00.0 Advanced Micro Devices [AMD] nee ATI RD890 PCI >>>> to PCI bridge (external gfx0 port B) >>>> +-00.2 Advanced Micro Devices [AMD] nee ATI RD990 I/O >>>> Memory Management Unit (IOMMU) >>>> +-*02.0*-[01]--+-00.0 Advanced Micro Devices [AMD] nee >>>> ATI RV370 5B60 [Radeon X300 (PCIE)] >>>> | \-00.1 Advanced Micro Devices [AMD] nee >>>> ATI RV370 [Radeon X300SE] >>>> +-09.0-[02]----00.0 Etron Technology, Inc. EJ168 USB >>>> 3.0 Host Controller >>>> +-0a.0-[03]----00.0 Marvell Technology Group Ltd. >>>> 88SE9172 SATA 6Gb/s Controller >>>> +-*0c.0*-[04]--+-00.0 Advanced Micro Devices [AMD] nee >>>> ATI Juniper XT [AMD Radeon HD 6000 Series] >>>> | \-00.1 Advanced Micro Devices [AMD] nee >>>> ATI Juniper HDMI Audio [Radeon HD 5700 Series] >>>> >>>> >>>> *00:02.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI RD890 >>>> PCI to PCI bridge (PCI express gpp port B) >>>> 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>>> to PCI bridge (PCI express gpp port H) >>>> 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI >>>> to PCI bridge (external gfx1 port A) >>>> *00:0c.0 PCI bridge*: Advanced Micro Devices [AMD] nee ATI Device 5a20 >>>> >>>> >>>> >>>> On 03/11/2013 06:45 PM, Matthew Dean wrote: >>>>> That was a good suggestion, I've just tried passing through a USB >>>>> controller and that worked fine. The driver installed correctly >>>>> and I can use devices attached to the relevant ports. The problem >>>>> therefore seems to be to do with gpu passthrough specifically. >>>>> I'm just going to describe my system and some settings I have in >>>>> the bios as this is starting to feel like a system specific >>>>> problem. The system is >>>>> >>>>> Asus Z9PE-D8 WS motherboard (chipset is intel C602) >>>>> Dual Xeon 2620 >>>>> 64 GB non-ecc memory >>>>> Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm >>>>> trying to pass through) >>>>> >>>>> In the bios I have vt-d enabled. I also have sub-feature settings >>>>> for "Coherency Support" and "ATS Support" which are disabled by >>>>> default. I've tried all combinations of these enabled and >>>>> disabled. If I enable "ATS Support" I do however have to add the >>>>> option "iommu=no-qinval,no-intremap" to the xen boot otherwise the >>>>> system hangs as per this thread >>>>> . >>>>> If the problem is to no with these options then I think I have a >>>>> problem. >>>>> >>>>> Has anybody got any thoughts? >>>>> >>>>> Matt >>>>> >>>>> On 11/03/2013 14:57, Peter Maloney wrote: >>>>>> Did you try other devices, such as your onboard sound card, your >>>>>> onboard USB controllers, etc.? Maybe your board doesn't do >>>>>> passthrough properly. >>>>>> >>>>>> Or did you try another PCIe port for the card? Maybe there are >>>>>> bugs where the addresses overlap with some other device, but in >>>>>> another slot it wouldn't happen. >>>>>> >>>>>> >>>>>> On 2013-03-11 14:48, Matthew Dean wrote: >>>>>>> First of all, thank you for the suggestions. I've now >>>>>>> re-installed windows and I've tried driver versions 12.3, 12.8 >>>>>>> and 13.1 all with and without the CCC as I read in various >>>>>>> places that it can cause problems. For 13.1 I never get >>>>>>> anywhere close as per my previous messages. For 12.3 and 12.8 I >>>>>>> at least get a BSOD, >>>>>>> >>>>>>> ####################################################################### >>>>>>> >>>>>>> A problem has been detected ... >>>>>>> >>>>>>> Attempt to reset the display driver and recover from timeout failed. >>>>>>> >>>>>>> If this is ... >>>>>>> >>>>>>> Techinal information: >>>>>>> >>>>>>> *** STOP: 0x00000116 >>>>>>> (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002) >>>>>>> >>>>>>> *** atikmpag.sys - Address FFFFF88003D95AE4 base at >>>>>>> FFFFF88003D8E000, Datestamp 4f597fca >>>>>>> >>>>>>> ####################################################################### >>>>>>> >>>>>>> Does anybody have any further ideas? >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> On 07/03/2013 21:42, John Sherwood wrote: >>>>>>>> (and I should probably mention that it has been my experience >>>>>>>> that that is the expected and correct behavior) >>>>>>>> >>>>>>>> On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood >>>>>>> > wrote: >>>>>>>> >>>>>>>> Having the windows logo freeze in the VNC window has been >>>>>>>> my experience with GPU passthrough as well. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I believe that the Windows logo freezing in the vnc >>>>>>>> window is normal behaviour when secondary GPU >>>>>>>> passthrough is working as it should, since the display >>>>>>>> should be handed over to the GPU. At least that was the >>>>>>>> case before when I was passing through a HD6850 card as >>>>>>>> secondary to win7 using xl. But you should expect >>>>>>>> output on the GPU, of course. >>>>>>>> >>>>>>>> Have you tried different versions of the catalyst >>>>>>>> driver? I think that some users have reported problems >>>>>>>> with the latest one (13-something). >>>>>>>> >>>>>>>> Regards, >>>>>>>> Andreas >>>>>>>> >>>>>>>> 2013/3/7 Matthew Dean >>>>>>> > >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've managed to get a windows 7 x64 hvm to boot and >>>>>>>> install and I'm now looking to pass through a HD >>>>>>>> 7970 as a secondary GPU. in order to prepare the >>>>>>>> devices for passthrough I've used >>>>>>>> >>>>>>>> xl pci-assignable-add 83:00.0 >>>>>>>> xl pci-assignable-add 83:00.1 >>>>>>>> >>>>>>>> Where I've identified the device pci ids using >>>>>>>> lspci. This works fine and the devices appear when >>>>>>>> I call 'xl pci-assignable-list'. After adding them >>>>>>>> to the vm config (see below) I was able to get the >>>>>>>> vm to boot and the devices appeared in device >>>>>>>> manager. Installing the ATI drivers however has >>>>>>>> meant that on further boots the machine never gets >>>>>>>> past the windows logo in the VNC window and no >>>>>>>> output is generated from the ATI card. It simply >>>>>>>> freezes there and the only way I can get back into >>>>>>>> windows is via safe mode, even after uninstalling >>>>>>>> the ATI software. >>>>>>>> >>>>>>>> Has anybody else experienced similar issues or have >>>>>>>> any advice as to how to get this to work? I'm a >>>>>>>> bit stumped and the wiki implies that this should >>>>>>>> 'just work'. >>>>>>>> >>>>>>>> Thank you in advance for any help. >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> Here is my machine config >>>>>>>> >>>>>>>> ########################################################### >>>>>>>> >>>>>>>> builder='hvm' >>>>>>>> memory = 2048 >>>>>>>> name = 'Windows7Test' >>>>>>>> >>>>>>>> vcpus=4 >>>>>>>> pae=1 >>>>>>>> acpi=1 >>>>>>>> apic=1 >>>>>>>> >>>>>>>> disk = [ >>>>>>>> 'file:/xen-guests/img/windows7Test.img,hda,w' ] >>>>>>>> pci = [ '83:00.0' , '83:00.1' ] >>>>>>>> >>>>>>>> on_poweroff = 'destroy' >>>>>>>> on_reboot = 'restart' >>>>>>>> on_crash = 'destroy' >>>>>>>> >>>>>>>> boot='cd' >>>>>>>> >>>>>>>> sdl=0 >>>>>>>> vnc=1 >>>>>>>> vncconsole=0 >>>>>>>> vncpasswd='' >>>>>>>> vnclisten='172.24.226.84' >>>>>>>> >>>>>>>> stdvga=0 >>>>>>>> >>>>>>>> serial='pty' >>>>>>>> usbdevice='tablet' >>>>>>>> >>>>>>>> gfx_passthru=0 >>>>>>>> pci_power_mgmt=1 >>>>>>>> xen_platform_pci=1 >>>>>>>> pci_msitranslate=1 >>>>>>>> viridian=1 >>>>>>>> hpet=1 >>>>>>>> >>>>>>>> ############################################################ >>>>>>>> >>>>>>>> And the vm produces the following qemu log in >>>>>>>> /var/log/xen/ >>>>>>>> >>>>>>>> ############################################################ >>>>>>>> >>>>>>>> domid: 4 >>>>>>>> -videoram option does not work with cirrus vga >>>>>>>> device model. Videoram set to 4M. >>>>>>>> Strip off blktap sub-type prefix to >>>>>>>> /xen-guests/img/windows7Test.img (drv 'aio') >>>>>>>> Using file /xen-guests/img/windows7Test.img in >>>>>>>> read-write mode >>>>>>>> Watching /local/domain/0/device-model/4/logdirty/cmd >>>>>>>> Watching /local/domain/0/device-model/4/command >>>>>>>> Watching /local/domain/4/cpu >>>>>>>> char device redirected to /dev/pts/3 >>>>>>>> qemu_map_cache_init nr_buckets = 10000 size 4194304 >>>>>>>> shared page at pfn feffd >>>>>>>> buffered io page at pfn feffb >>>>>>>> Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6 >>>>>>>> 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/4/xen_extended_power_mgmt): >>>>>>>> read error >>>>>>>> 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. >>>>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>>>> count: 0, size: 0 >>>>>>>> xs_read(/local/domain/4/log-throttling): read error >>>>>>>> qemu: ignoring not-understood drive >>>>>>>> `/local/domain/4/log-throttling' >>>>>>>> medium change watch on >>>>>>>> `/local/domain/4/log-throttling' - unknown device, >>>>>>>> ignored >>>>>>>> I/O request not ready: 0, ptr: 0, port: 0, data: 0, >>>>>>>> count: 0, size: 0 >>>>>>>> dm-command: hot insert pass-through pci dev >>>>>>>> register_real_device: Assigning real physical >>>>>>>> device 83:00.0 ... >>>>>>>> register_real_device: Enable MSI translation via >>>>>>>> per device option >>>>>>>> register_real_device: Enable power management >>>>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>>>> 0x83:0x0.0x0 >>>>>>>> pt_register_regions: IO region registered >>>>>>>> (size=0x10000000 base_addr=0xe000000c) >>>>>>>> pt_register_regions: IO region registered >>>>>>>> (size=0x00040000 base_addr=0xf0000004) >>>>>>>> pt_register_regions: IO region registered >>>>>>>> (size=0x00000100 base_addr=0x0000f001) >>>>>>>> pt_register_regions: Expansion ROM registered >>>>>>>> (size=0x00020000 base_addr=0xf0040000) >>>>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>>>> pci_intx: intx=1 >>>>>>>> register_real_device: Real physical device 83:00.0 >>>>>>>> registered successfuly! >>>>>>>> IRQ type = MSI-INTx >>>>>>>> dm-command: hot insert pass-through pci dev >>>>>>>> register_real_device: Assigning real physical >>>>>>>> device 83:00.1 ... >>>>>>>> register_real_device: Enable MSI translation via >>>>>>>> per device option >>>>>>>> register_real_device: Enable power management >>>>>>>> pt_iomul_init: Error: pt_iomul_init can't open file >>>>>>>> /dev/xen/pci_iomul: No such file or directory: >>>>>>>> 0x83:0x0.0x1 >>>>>>>> pt_register_regions: IO region registered >>>>>>>> (size=0x00004000 base_addr=0xf0060004) >>>>>>>> pt_msi_setup: msi mapped with pirq 66 >>>>>>>> pci_intx: intx=2 >>>>>>>> register_real_device: Real physical device 83:00.1 >>>>>>>> registered successfuly! >>>>>>>> IRQ type = MSI-INTx >>>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=1 >>>>>>>> cirrus vga map change while on lfb mode >>>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=1 >>>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=1 >>>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>>> index=4 first_map=1 >>>>>>>> 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. >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:04:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_pci_read_config: [00:05:0] Error: Failed to read >>>>>>>> register with invalid access size alignment. >>>>>>>> [Offset:0eh][Length:4] >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=0 >>>>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>>>> index=4 first_map=0 >>>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=0 >>>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>>> index=4 first_map=0 >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=0 >>>>>>>> pt_ioport_map: e_phys=ffff pio_base=f000 len=256 >>>>>>>> index=4 first_map=0 >>>>>>>> pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 >>>>>>>> len=268435456 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 >>>>>>>> len=262144 index=2 first_map=0 >>>>>>>> pt_ioport_map: e_phys=c100 pio_base=f000 len=256 >>>>>>>> index=4 first_map=0 >>>>>>>> pt_msgctrl_reg_write: guest enabling MSI, disable >>>>>>>> MSI-INTx translation >>>>>>>> pci_intx: intx=1 >>>>>>>> pt_msi_disable: Unmap msi with pirq 67 >>>>>>>> pt_msgctrl_reg_write: setup msi for dev 20 >>>>>>>> pt_msi_setup: msi mapped with pirq 67 >>>>>>>> pt_msi_update: Update msi with pirq 67 gvec b0 >>>>>>>> gflags 130f >>>>>>>> pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=0 >>>>>>>> pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 >>>>>>>> len=16384 index=0 first_map=0 >>>>>>>> >>>>>>>> ###################################################################### >>>>>>>> >>>>>>>> _____________________ >>>>>>>> >> > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- --------------070001060502070002070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
There was one point with windows XP, where if I didn't have the cable attached to the video card, it would do something strange... maybe not initialize, or maybe I couldn't switch to the other port later (I planned on using vga for domu, and dvi for dom0 so my monitor's switch button would work). So maybe try things like that.

And I would do any future tests with only one card physically plugged in until you find something new and can test with both. You could also try putting both cards in slots 1-4, instead of one in 5,6,7. But when trying other drivers, domu settings, etc. I'd use just one card.

And FYI, in winxp, I could only get my domu to show graphics if I set "stdvga=1" in the config. Maybe you can try that. But it is just a guess (as it was when I first found it worked in XP). My windows 7 and 8 worked fine without that setting.

I also can hear my fan change when I start my domu... it lets you know it is working :)
Did the fan speed change before, when you had both cards in, and one passed through?

But either way, it sounds like you got some new information, even if vague... that one vs 2 GPUs has a different effect. I hope it leads to the answer.

On 2013-03-12 12:55, Matthew Dean wrote:
My guess is that they are on different bridges.  I've read that for this board if you use only the first CPU socket then you'll only get access to pcie slots 1 through 4.  Slots 5, 6 and 7 simply won't work at all.  Passing through both cards still does not work but this time I don't get a BSOD, the display simply never turns on.  I can hear the fan speed of the card change however at the precise point where the VNC window stops showing any change so there is something going on here.  I've just pulled out the card in slot 5 and tried to pass through the one remaining card and that has the same result, with the display never turning on.

Matt

On 12/03/2013 11:41, Peter Maloney wrote:
Okay that is enormous output :D

And I'm not sure what to say about it... hopefully someone else reading it can read it better than I can.

Your bridges:

00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)

Your GPUs:
...
  +-[0000:80]-+-00.0-[81]--
  |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
   |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
  \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
              +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
              |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]

So you would be fine with PCI bridges if that 80 vs 00 is really different bridges and not just same ones seen by different CPUSs.

I can look at many older Xeons and they all show just one set of bridges, and one very new one (newer socket) has the same thing as yours. But I don't use IOMMU on those, so I don't know what effect it has.

I kinda think they are the same bridge, which would be bad. I don't know how to test it... pull out a CPU? ;) find some other detail that has IDs? disable one in the bios (unlikely)? or you could test this by passing through both cards to the same domu... This would be a good test (and matches what the other thread was about... his worked with passing both through)




On 2013-03-12 11:32, Matthew Dean wrote:
As requested,

lspci

##############################################################################################################

00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
00:01.1 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1b (rev 07)
00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06)
00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05)
00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05)
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06)
00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06)
00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6)
00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6)
00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6)
00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6)
00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6)
00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 7 (rev b6)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06)
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
03:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 06)
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
09:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
0a:00.0 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10)
0b:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01)
7f:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
7f:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
7f:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
7f:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
7f:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
7f:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
7f:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
7f:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
7f:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
7f:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
7f:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
7f:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
7f:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
7f:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
7f:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
7f:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
7f:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
7f:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
7f:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
7f:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
7f:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
7f:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
7f:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
7f:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
7f:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
7f:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
7f:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
7f:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
7f:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
7f:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
7f:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
7f:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
7f:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
7f:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
7f:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
7f:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
7f:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)
80:00.0 PCI bridge: Intel Corporation Xeon E5/Core i7 DMI2 in PCI Express Mode (rev 07)
80:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07)
80:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07)
80:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07)
80:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07)
80:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07)
80:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07)
83:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
83:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
ff:08.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 0 (rev 07)
ff:08.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:08.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 0 (rev 07)
ff:09.0 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link 1 (rev 07)
ff:09.3 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:09.4 System peripheral: Intel Corporation Xeon E5/Core i7 QPI Link Reut 1 (rev 07)
ff:0a.0 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 0 (rev 07)
ff:0a.1 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 1 (rev 07)
ff:0a.2 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 2 (rev 07)
ff:0a.3 System peripheral: Intel Corporation Xeon E5/Core i7 Power Control Unit 3 (rev 07)
ff:0b.0 System peripheral: Intel Corporation Xeon E5/Core i7 Interrupt Control Registers (rev 07)
ff:0b.3 System peripheral: Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers (rev 07)
ff:0c.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0c.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0 (rev 07)
ff:0c.7 System peripheral: Intel Corporation Xeon E5/Core i7 System Address Decoder (rev 07)
ff:0d.0 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.1 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.2 System peripheral: Intel Corporation Xeon E5/Core i7 Unicast Register 0 (rev 07)
ff:0d.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1 (rev 07)
ff:0e.0 System peripheral: Intel Corporation Xeon E5/Core i7 Processor Home Agent (rev 07)
ff:0e.1 Performance counters: Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring (rev 07)
ff:0f.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers (rev 07)
ff:0f.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers (rev 07)
ff:0f.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0 (rev 07)
ff:0f.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1 (rev 07)
ff:0f.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2 (rev 07)
ff:0f.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3 (rev 07)
ff:0f.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4 (rev 07)
ff:10.0 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0 (rev 07)
ff:10.1 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1 (rev 07)
ff:10.2 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0 (rev 07)
ff:10.3 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1 (rev 07)
ff:10.4 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2 (rev 07)
ff:10.5 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3 (rev 07)
ff:10.6 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2 (rev 07)
ff:10.7 System peripheral: Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3 (rev 07)
ff:11.0 System peripheral: Intel Corporation Xeon E5/Core i7 DDRIO (rev 07)
ff:13.0 System peripheral: Intel Corporation Xeon E5/Core i7 R2PCIe (rev 07)
ff:13.1 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor (rev 07)
ff:13.4 Performance counters: Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers (rev 07)
ff:13.5 Performance counters: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor (rev 07)
ff:13.6 System peripheral: Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor (rev 07)

##############################################################################################################

lspci -tv

##############################################################################################################

-+-[0000:ff]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 +-[0000:80]-+-00.0-[81]--
 |           +-01.0-[82]--
 |           +-02.0-[83]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
 |           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
 |           +-03.0-[84]--
 |           +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
 |           +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
 |           \-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
 +-[0000:7f]-+-08.0  Intel Corporation Xeon E5/Core i7 QPI Link 0
 |           +-08.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-08.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 0
 |           +-09.0  Intel Corporation Xeon E5/Core i7 QPI Link 1
 |           +-09.3  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-09.4  Intel Corporation Xeon E5/Core i7 QPI Link Reut 1
 |           +-0a.0  Intel Corporation Xeon E5/Core i7 Power Control Unit 0
 |           +-0a.1  Intel Corporation Xeon E5/Core i7 Power Control Unit 1
 |           +-0a.2  Intel Corporation Xeon E5/Core i7 Power Control Unit 2
 |           +-0a.3  Intel Corporation Xeon E5/Core i7 Power Control Unit 3
 |           +-0b.0  Intel Corporation Xeon E5/Core i7 Interrupt Control Registers
 |           +-0b.3  Intel Corporation Xeon E5/Core i7 Semaphore and Scratchpad Configuration Registers
 |           +-0c.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0c.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 0
 |           +-0c.7  Intel Corporation Xeon E5/Core i7 System Address Decoder
 |           +-0d.0  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.1  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.2  Intel Corporation Xeon E5/Core i7 Unicast Register 0
 |           +-0d.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller System Address Decoder 1
 |           +-0e.0  Intel Corporation Xeon E5/Core i7 Processor Home Agent
 |           +-0e.1  Intel Corporation Xeon E5/Core i7 Processor Home Agent Performance Monitoring
 |           +-0f.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Registers
 |           +-0f.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller RAS Registers
 |           +-0f.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 0
 |           +-0f.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 1
 |           +-0f.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 2
 |           +-0f.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 3
 |           +-0f.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Target Address Decoder 4
 |           +-10.0  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 0
 |           +-10.1  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 1
 |           +-10.2  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 0
 |           +-10.3  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 1
 |           +-10.4  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 2
 |           +-10.5  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller Channel 0-3 Thermal Control 3
 |           +-10.6  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 2
 |           +-10.7  Intel Corporation Xeon E5/Core i7 Integrated Memory Controller ERROR Registers 3
 |           +-11.0  Intel Corporation Xeon E5/Core i7 DDRIO
 |           +-13.0  Intel Corporation Xeon E5/Core i7 R2PCIe
 |           +-13.1  Intel Corporation Xeon E5/Core i7 Ring to PCI Express Performance Monitor
 |           +-13.4  Intel Corporation Xeon E5/Core i7 QuickPath Interconnect Agent Ring Registers
 |           +-13.5  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 0 Performance Monitor
 |           \-13.6  Intel Corporation Xeon E5/Core i7 Ring to QuickPath Interconnect Link 1 Performance Monitor
 \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
             +-01.0-[01]--
             +-01.1-[02]--
             +-02.0-[03]--+-00.0  Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]
             |            \-00.1  Advanced Micro Devices [AMD] nee ATI Tahiti XT HDMI Audio [Radeon HD 7970 Series]
             +-03.0-[04]--
             +-05.0  Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management
             +-05.2  Intel Corporation Xeon E5/Core i7 Control Status and Global Errors
             +-05.4  Intel Corporation Xeon E5/Core i7 I/O APIC
             +-11.0-[05]----00.0  Intel Corporation C602 chipset 4-Port SATA Storage Control Unit
             +-16.0  Intel Corporation C600/X79 series chipset MEI Controller #1
             +-16.1  Intel Corporation C600/X79 series chipset MEI Controller #2
             +-1a.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2
             +-1b.0  Intel Corporation C600/X79 series chipset High Definition Audio Controller
             +-1c.0-[06]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.1-[07]----00.0  Intel Corporation 82574L Gigabit Network Connection
             +-1c.2-[08]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.3-[09]----00.0  ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
             +-1c.4-[0a]----00.0  Marvell Technology Group Ltd. Device 9230
             +-1c.6-[0b]----00.0  VIA Technologies, Inc. VT6315 Series Firewire Controller
             +-1d.0  Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1
             +-1e.0-[0c]--
             +-1f.0  Intel Corporation C600/X79 series chipset LPC Controller
             +-1f.2  Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller
             \-1f.3  Intel Corporation C600/X79 series chipset SMBus Host Controller

##############################################################################################################

I'm going to try passing through both cards and see if that works as well as passing through just the one but with only one card present.  I've had a dig for the thread your talking about but I cannot find it.  If anybody else knows if it still exists somewhere I'd be grateful if you could let me know.

Thanks again for your help.

Matt

On 11/03/2013 18:16, Peter Maloney wrote:
Ah, because you have 2 cpus and 2 cards, can you post output of "lspci -tv" and "lspci"? There was one guy who could pass through one card, but when he physically added the 2nd card in the machine, the same config with the first card wouldn't work any more because the 2 cards were on the same PCI bridge. And he could pass through both and have them work, but not just one of them at a time. (I have since cleaned out my email box, and so I can't find the old thread)

So you see on my system, the "02.0" bridge is separate from "0c.0", so I don't have a problem.

-[0000:00]-+-00.0  Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B)
           +-00.2  Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU)
           +-02.0-[01]--+-00.0  Advanced Micro Devices [AMD] nee ATI RV370 5B60 [Radeon X300 (PCIE)]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI RV370 [Radeon X300SE]
           +-09.0-[02]----00.0  Etron Technology, Inc. EJ168 USB 3.0 Host Controller
           +-0a.0-[03]----00.0  Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller
           +-0c.0-[04]--+-00.0  Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series]
           |            \-00.1  Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series]


00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B)
00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx1 port A)
00:0c.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI Device 5a20



On 03/11/2013 06:45 PM, Matthew Dean wrote:
That was a good suggestion, I've just tried passing through a USB controller and that worked fine.  The driver installed correctly and I can use devices attached to the relevant ports.  The problem therefore seems to be to do with gpu passthrough specifically.  I'm just going to describe my system and some settings I have in the bios as this is starting to feel like a system specific problem.  The system is

Asus Z9PE-D8 WS motherboard (chipset is intel C602)
Dual Xeon 2620
64 GB non-ecc memory
Dual AMD radeon HD 7970 in slots 1 & 5 (it's the one in slot 5 I'm trying to pass through)

In the bios I have vt-d enabled.  I also have sub-feature settings for "Coherency Support" and "ATS Support" which are disabled by default.  I've tried all combinations of these enabled and disabled.  If I enable "ATS Support" I do however have to add the option "iommu=no-qinval,no-intremap" to the xen boot otherwise the system hangs as per this thread.  If the problem is to no with these options then I think I have a problem.

Has anybody got any thoughts?

Matt

On 11/03/2013 14:57, Peter Maloney wrote:
Did you try other devices, such as your onboard sound card, your onboard USB controllers, etc.? Maybe your board doesn't do passthrough properly.

Or did you try another PCIe port for the card? Maybe there are bugs where the addresses overlap with some other device, but in another slot it wouldn't happen.


On 2013-03-11 14:48, Matthew Dean wrote:
First of all, thank you for the suggestions.  I've now re-installed windows and I've tried driver versions 12.3, 12.8 and 13.1 all with and without the CCC as I read in various places that it can cause problems.  For 13.1 I never get anywhere close as per my previous messages.  For 12.3 and 12.8 I at least get a BSOD,

#######################################################################

A problem has been detected ...

Attempt to reset the display driver and recover from timeout failed.

If this is ...

Techinal information:

*** STOP: 0x00000116 (0xFFFFFA8002AAF010,0xFFFFF88003D95AE4,0x0000000000000000,0x0000000000000002)

*** atikmpag.sys - Address FFFFF88003D95AE4 base at FFFFF88003D8E000, Datestamp 4f597fca

#######################################################################

Does anybody have any further ideas?

Matt

On 07/03/2013 21:42, John Sherwood wrote:
(and I should probably mention that it has been my experience that that is the expected and correct behavior)

On Thu, Mar 7, 2013 at 1:41 PM, John Sherwood <jrs@vt.edu> wrote:
Having the windows logo freeze in the VNC window has been my experience with GPU passthrough as well.


On Thu, Mar 7, 2013 at 1:38 PM, Andreas Falck <falck.andreas.lists@gmail.com> wrote:
Hi,

I believe that the Windows logo freezing in the vnc window is normal behaviour when secondary GPU passthrough is working as it should, since the display should be handed over to the GPU. At least that was the case before when I was passing through a HD6850 card as secondary to win7 using xl. But you should expect output on the GPU, of course.

Have you tried different versions of the catalyst driver? I think that some users have reported problems with the latest one (13-something).

Regards,
Andreas

2013/3/7 Matthew Dean <mcd40@cam.ac.uk>
Hi all,

I've managed to get a windows 7 x64 hvm to boot and install and I'm now looking to pass through a HD 7970 as a secondary GPU.  in order to prepare the devices for passthrough I've used

xl pci-assignable-add 83:00.0
xl pci-assignable-add 83:00.1

Where I've identified the device pci ids using lspci.  This works fine and the devices appear when I call 'xl pci-assignable-list'. After adding them to the vm config (see below) I was able to get the vm to boot and the devices appeared in device manager.  Installing the ATI drivers however has meant that on further boots the  machine never gets past the windows logo in the VNC window and no output is generated from the ATI card.  It simply freezes there and the only way I can get back into windows is via safe mode, even after uninstalling the ATI software.

Has anybody else experienced similar issues or have any advice as to how to get this to work?  I'm a bit stumped and the wiki implies that this should 'just work'.

Thank you in advance for any help.

Matt

Here is my machine config

###########################################################

builder='hvm'
memory = 2048
name = 'Windows7Test'

vcpus=4
pae=1
acpi=1
apic=1

disk = [ 'file:/xen-guests/img/windows7Test.img,hda,w' ]
pci = [ '83:00.0' , '83:00.1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

boot='cd'

sdl=0
vnc=1
vncconsole=0
vncpasswd=''
vnclisten='172.24.226.84'

stdvga=0

serial='pty'
usbdevice='tablet'

gfx_passthru=0
pci_power_mgmt=1
xen_platform_pci=1
pci_msitranslate=1
viridian=1
hpet=1

############################################################

And the vm produces the following qemu log in /var/log/xen/

############################################################

domid: 4
-videoram option does not work with cirrus vga device model. Videoram set to 4M.
Strip off blktap sub-type prefix to /xen-guests/img/windows7Test.img (drv 'aio')
Using file /xen-guests/img/windows7Test.img in read-write mode
Watching /local/domain/0/device-model/4/logdirty/cmd
Watching /local/domain/0/device-model/4/command
Watching /local/domain/4/cpu
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e09f5a51-7de1-4d92-9cec-826b9d66aeb6
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/4/xen_extended_power_mgmt): read error
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.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/4/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/4/log-throttling'
medium change watch on `/local/domain/4/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xe000000c)
pt_register_regions: IO region registered (size=0x00040000 base_addr=0xf0000004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000f001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xf0040000)
pt_msi_setup: msi mapped with pirq 67
pci_intx: intx=1
register_real_device: Real physical device 83:00.0 registered successfuly!
IRQ type = MSI-INTx
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 83:00.1 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Enable power management
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No such file or directory: 0x83:0x0.0x1
pt_register_regions: IO region registered (size=0x00004000 base_addr=0xf0060004)
pt_msi_setup: msi mapped with pirq 66
pci_intx: intx=2
register_real_device: Real physical device 83:00.1 registered successfuly!
IRQ type = MSI-INTx
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=1
cirrus vga map change while on lfb mode
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=1
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=1
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=1
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.
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:04:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_pci_read_config: [00:05:0] Error: Failed to read register with invalid access size alignment. [Offset:0eh][Length:4]
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=ffffffff maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=ffff pio_base=f000 len=256 index=4 first_map=0
pt_iomem_map: e_phys=e0000000 maddr=e0000000 type=8 len=268435456 index=0 first_map=0
pt_iomem_map: e_phys=f3000000 maddr=f0000000 type=0 len=262144 index=2 first_map=0
pt_ioport_map: e_phys=c100 pio_base=f000 len=256 index=4 first_map=0
pt_msgctrl_reg_write: guest enabling MSI, disable MSI-INTx translation
pci_intx: intx=1
pt_msi_disable: Unmap msi with pirq 67
pt_msgctrl_reg_write: setup msi for dev 20
pt_msi_setup: msi mapped with pirq 67
pt_msi_update: Update msi with pirq 67 gvec b0 gflags 130f
pt_iomem_map: e_phys=ffffffff maddr=f0060000 type=0 len=16384 index=0 first_map=0
pt_iomem_map: e_phys=f3060000 maddr=f0060000 type=0 len=16384 index=0 first_map=0

######################################################################

_____________________




_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users


-- 

--------------------------------------------
Peter Maloney
Brockmann Consult
Max-Planck-Str. 2
21502 Geesthacht
Germany
Tel: +49 4152 889 300
Fax: +49 4152 889 333
E-mail: peter.maloney@brockmann-consult.de
Internet: http://www.brockmann-consult.de
--------------------------------------------
--------------070001060502070002070100-- --===============8793504173819426069== 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 --===============8793504173819426069==-- From xen-users-bounces@lists.xen.org Tue Mar 12 13:29:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 13:29: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 1UFPGL-0005WE-Dh; Tue, 12 Mar 2013 13:29:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFPGJ-0005W4-KY for xen-users@lists.xen.org; Tue, 12 Mar 2013 13:29:03 +0000 Received: from [85.158.138.51:54254] by server-7.bemta-3.messagelabs.com id 18/AD-06591-E9D2F315; Tue, 12 Mar 2013 13:29:02 +0000 X-Env-Sender: sgrunt91@hotmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1363094942!31458480!1 X-Originating-IP: [157.55.1.149] X-SpamReason: No, hits=0.2 required=7.0 tests=FORGED_HOTMAIL_RCVD, HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 555 invoked from network); 12 Mar 2013 13:29:02 -0000 Received: from dub0-omc2-s10.dub0.hotmail.com (HELO dub0-omc2-s10.dub0.hotmail.com) (157.55.1.149) by server-4.tower-174.messagelabs.com with SMTP; 12 Mar 2013 13:29:02 -0000 Received: from DUB002-W70 ([157.55.1.138]) by dub0-omc2-s10.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Mar 2013 06:29:01 -0700 X-EIP: [48lHtYi5jr8sZSUKvoob02KjrbH92DLN] X-Originating-Email: [sgrunt91@hotmail.com] Message-ID: From: "R. Jeremy" To: "xen-users@lists.xen.org" Date: Tue, 12 Mar 2013 13:29:01 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2013 13:29:01.0675 (UTC) FILETIME=[8F2E4BB0:01CE1F25] Subject: [Xen-users] Xen 3 High Availability ways X-BeenThere: xen-users@lists.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="===============7906052970381384383==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7906052970381384383== Content-Type: multipart/alternative; boundary="_1e27d21c-054c-4012-9006-250cf7f4bf53_" --_1e27d21c-054c-4012-9006-250cf7f4bf53_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C I'm new in Xensource World. I have to work on Xen 3.1.2 hypervisor=2C I've = done some searches on how to make Xen HA (not FT for the moment).The way th= at is come again and again is to make a cluster with Corosync=2C pacemaker= =2C DRDB. I just want to now if there are others way to do Xen HA=2C and wh= ich is the best way in your opinion?I need something very stable and sustai= nable. I've seen many others mails of this subject=2C but we never know what is th= e best way. And this is often for Xen 4. I'm french=2C so I hope you'll understand my english... Thanks! BR = --_1e27d21c-054c-4012-9006-250cf7f4bf53_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=2C

I'm new= in Xensource World. I have to work on Xen 3.1.2 hypervisor=2C I've done so= me searches on how to make Xen HA (not FT for the moment).
The wa= y that is come again and again is to make a cluster with Corosync=2C pacema= ker=2C DRDB. I just want to now if there are others way to do Xen HA=2C and= which is the best way in your opinion?
I need something very sta= ble and sustainable.

I've seen many others mails o= f this subject=2C but we never know what is the best way. And this is often= for Xen 4.

I'm french=2C so I hope you'll underst= and my english...

Thanks!

BR
= --_1e27d21c-054c-4012-9006-250cf7f4bf53_-- --===============7906052970381384383== 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 --===============7906052970381384383==-- From xen-users-bounces@lists.xen.org Tue Mar 12 13:29:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 13:29: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 1UFPGL-0005WE-Dh; Tue, 12 Mar 2013 13:29:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFPGJ-0005W4-KY for xen-users@lists.xen.org; Tue, 12 Mar 2013 13:29:03 +0000 Received: from [85.158.138.51:54254] by server-7.bemta-3.messagelabs.com id 18/AD-06591-E9D2F315; Tue, 12 Mar 2013 13:29:02 +0000 X-Env-Sender: sgrunt91@hotmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1363094942!31458480!1 X-Originating-IP: [157.55.1.149] X-SpamReason: No, hits=0.2 required=7.0 tests=FORGED_HOTMAIL_RCVD, HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 555 invoked from network); 12 Mar 2013 13:29:02 -0000 Received: from dub0-omc2-s10.dub0.hotmail.com (HELO dub0-omc2-s10.dub0.hotmail.com) (157.55.1.149) by server-4.tower-174.messagelabs.com with SMTP; 12 Mar 2013 13:29:02 -0000 Received: from DUB002-W70 ([157.55.1.138]) by dub0-omc2-s10.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Mar 2013 06:29:01 -0700 X-EIP: [48lHtYi5jr8sZSUKvoob02KjrbH92DLN] X-Originating-Email: [sgrunt91@hotmail.com] Message-ID: From: "R. Jeremy" To: "xen-users@lists.xen.org" Date: Tue, 12 Mar 2013 13:29:01 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2013 13:29:01.0675 (UTC) FILETIME=[8F2E4BB0:01CE1F25] Subject: [Xen-users] Xen 3 High Availability ways X-BeenThere: xen-users@lists.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="===============7906052970381384383==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7906052970381384383== Content-Type: multipart/alternative; boundary="_1e27d21c-054c-4012-9006-250cf7f4bf53_" --_1e27d21c-054c-4012-9006-250cf7f4bf53_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C I'm new in Xensource World. I have to work on Xen 3.1.2 hypervisor=2C I've = done some searches on how to make Xen HA (not FT for the moment).The way th= at is come again and again is to make a cluster with Corosync=2C pacemaker= =2C DRDB. I just want to now if there are others way to do Xen HA=2C and wh= ich is the best way in your opinion?I need something very stable and sustai= nable. I've seen many others mails of this subject=2C but we never know what is th= e best way. And this is often for Xen 4. I'm french=2C so I hope you'll understand my english... Thanks! BR = --_1e27d21c-054c-4012-9006-250cf7f4bf53_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=2C

I'm new= in Xensource World. I have to work on Xen 3.1.2 hypervisor=2C I've done so= me searches on how to make Xen HA (not FT for the moment).
The wa= y that is come again and again is to make a cluster with Corosync=2C pacema= ker=2C DRDB. I just want to now if there are others way to do Xen HA=2C and= which is the best way in your opinion?
I need something very sta= ble and sustainable.

I've seen many others mails o= f this subject=2C but we never know what is the best way. And this is often= for Xen 4.

I'm french=2C so I hope you'll underst= and my english...

Thanks!

BR
= --_1e27d21c-054c-4012-9006-250cf7f4bf53_-- --===============7906052970381384383== 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 --===============7906052970381384383==-- From xen-users-bounces@lists.xen.org Tue Mar 12 13:38:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 13:38: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 1UFPOj-0005ze-Lj; Tue, 12 Mar 2013 13:37:45 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFPOi-0005zS-BF for xen-users@lists.xensource.com; Tue, 12 Mar 2013 13:37:44 +0000 Received: from [85.158.139.83:41733] by server-9.bemta-5.messagelabs.com id E7/8D-08547-7AF2F315; Tue, 12 Mar 2013 13:37:43 +0000 X-Env-Sender: maillists@conactive.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1363095462!24062079!1 X-Originating-IP: [213.160.90.171] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17573 invoked from network); 12 Mar 2013 13:37:43 -0000 Received: from d01.online-netz.de (HELO d01.online-netz.de) (213.160.90.171) by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2013 13:37:43 -0000 Received: from news.conactive.com (fandango.conactive.com [212.202.99.226]) by d01.online-netz.de (Postfix) with ESMTP id 641CEF9927 for ; Tue, 12 Mar 2013 14:37:40 +0100 (CET) Date: Tue, 12 Mar 2013 14:37:38 +0100 To: xen-users@lists.xensource.com X-Mailer: Virtual Access Open Source http://www.virtual-access.org/ Message-Id: Mime-Version: 1.0 From: Kai Schaetzl In-Reply-To: <513F2CCD.8040705@brockmann-consult.de> References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> <513F0426.1080808@cam.ac.uk> <513F1467.2010202@brockmann-consult.de> <513F17AA.6050406@cam.ac.uk> <513F2CCD.8040705@brockmann-consult.de> Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: xen-users@lists.xensource.com 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 Folks, could you please stop quoting and quoting and quoting all of these lengthy logs again and again? Thanks. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 13:38:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 13:38: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 1UFPOj-0005ze-Lj; Tue, 12 Mar 2013 13:37:45 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFPOi-0005zS-BF for xen-users@lists.xensource.com; Tue, 12 Mar 2013 13:37:44 +0000 Received: from [85.158.139.83:41733] by server-9.bemta-5.messagelabs.com id E7/8D-08547-7AF2F315; Tue, 12 Mar 2013 13:37:43 +0000 X-Env-Sender: maillists@conactive.com X-Msg-Ref: server-6.tower-182.messagelabs.com!1363095462!24062079!1 X-Originating-IP: [213.160.90.171] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17573 invoked from network); 12 Mar 2013 13:37:43 -0000 Received: from d01.online-netz.de (HELO d01.online-netz.de) (213.160.90.171) by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2013 13:37:43 -0000 Received: from news.conactive.com (fandango.conactive.com [212.202.99.226]) by d01.online-netz.de (Postfix) with ESMTP id 641CEF9927 for ; Tue, 12 Mar 2013 14:37:40 +0100 (CET) Date: Tue, 12 Mar 2013 14:37:38 +0100 To: xen-users@lists.xensource.com X-Mailer: Virtual Access Open Source http://www.virtual-access.org/ Message-Id: Mime-Version: 1.0 From: Kai Schaetzl In-Reply-To: <513F2CCD.8040705@brockmann-consult.de> References: <5138E4E6.9080001@cam.ac.uk> <513DE0B9.5020005@cam.ac.uk> <513DF0D0.1050907@brockmann-consult.de> <513E184C.4000007@cam.ac.uk> <513E1F89.8040506@brockmann-consult.de> <513F0426.1080808@cam.ac.uk> <513F1467.2010202@brockmann-consult.de> <513F17AA.6050406@cam.ac.uk> <513F2CCD.8040705@brockmann-consult.de> Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: xen-users@lists.xensource.com 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 Folks, could you please stop quoting and quoting and quoting all of these lengthy logs again and again? Thanks. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 14:36:28 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 14:36: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 1UFQIj-0007Kc-3E; Tue, 12 Mar 2013 14:35:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFQIh-0007KW-4v for xen-users@lists.xen.org; Tue, 12 Mar 2013 14:35:35 +0000 Received: from [85.158.143.99:11347] by server-3.bemta-4.messagelabs.com id E6/AD-02186-63D3F315; Tue, 12 Mar 2013 14:35:34 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1363098931!20260971!1 X-Originating-IP: [209.85.223.179] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_00_10, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9206 invoked from network); 12 Mar 2013 14:35:33 -0000 Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com) (209.85.223.179) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 14:35:33 -0000 Received: by mail-ie0-f179.google.com with SMTP id k11so6390569iea.38 for ; Tue, 12 Mar 2013 07:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MH+H0IiKc48rucRlw6uTUgBN06JUxY9a3P43xiYVr0g=; b=kbc4c3hatPQjxAENjIxQQdyJAoBY4T9VgLe3XmDOCWSiCLj9FDgySvDrmR0cx4Eyqn 28mmw2sTQozCc6boPQF1HuX615KTceIL6g71Drwcp/rQixrFKSy7US1JqsDdu7nf4Urz oq85YxSeFw7hm7B04avCT/Gkgu4XLNa22HnW5xMtSN8WFsbjjeb4008ASd7/9qxy11C+ xPfmoWA/qMx9FSGRZYmFQR8xA+nc/cPoBVB36vZloRbaYT9uotLn2yaP9CP4CgJJhWcJ QYtzR4rq5faerTUX9xAfIVFlqUHdZUFv28d2RJeOXY+7Z4MItY0gL2tLo7vULyt/9uek xBrA== MIME-Version: 1.0 X-Received: by 10.42.133.133 with SMTP id h5mr12440707ict.45.1363098931007; Tue, 12 Mar 2013 07:35:31 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Tue, 12 Mar 2013 07:35:30 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Tue, 12 Mar 2013 07:35:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Mar 2013 08:35:30 -0600 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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="===============5409141148086764057==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5409141148086764057== Content-Type: multipart/alternative; boundary=90e6ba5bc09d939a8f04d7bb33ac --90e6ba5bc09d939a8f04d7bb33ac Content-Type: text/plain; charset=ISO-8859-1 I have 3 xen servers and i had used lvm for virtual drives on local storage I want to backup lvms to iscsi i had installed freenas under xen and I am thinking about exporting iscsi matching sizes of lvm virtual partitions so I can back them up rsync. I looking for ideas on proper way of backing up windows 2012s and archlinux --90e6ba5bc09d939a8f04d7bb33ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I have 3 xen servers and i had used lvm for virtual drives on local stor= age I want to backup lvms to iscsi i had installed freenas under xen and I = am thinking about exporting iscsi matching sizes of lvm virtual partitions = so I can back them up rsync. I looking for ideas on proper way of backing u= p windows 2012s and archlinux

--90e6ba5bc09d939a8f04d7bb33ac-- --===============5409141148086764057== 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 --===============5409141148086764057==-- From xen-users-bounces@lists.xen.org Tue Mar 12 14:36:28 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 14:36: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 1UFQIj-0007Kc-3E; Tue, 12 Mar 2013 14:35:37 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFQIh-0007KW-4v for xen-users@lists.xen.org; Tue, 12 Mar 2013 14:35:35 +0000 Received: from [85.158.143.99:11347] by server-3.bemta-4.messagelabs.com id E6/AD-02186-63D3F315; Tue, 12 Mar 2013 14:35:34 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1363098931!20260971!1 X-Originating-IP: [209.85.223.179] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_00_10, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9206 invoked from network); 12 Mar 2013 14:35:33 -0000 Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com) (209.85.223.179) by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 14:35:33 -0000 Received: by mail-ie0-f179.google.com with SMTP id k11so6390569iea.38 for ; Tue, 12 Mar 2013 07:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MH+H0IiKc48rucRlw6uTUgBN06JUxY9a3P43xiYVr0g=; b=kbc4c3hatPQjxAENjIxQQdyJAoBY4T9VgLe3XmDOCWSiCLj9FDgySvDrmR0cx4Eyqn 28mmw2sTQozCc6boPQF1HuX615KTceIL6g71Drwcp/rQixrFKSy7US1JqsDdu7nf4Urz oq85YxSeFw7hm7B04avCT/Gkgu4XLNa22HnW5xMtSN8WFsbjjeb4008ASd7/9qxy11C+ xPfmoWA/qMx9FSGRZYmFQR8xA+nc/cPoBVB36vZloRbaYT9uotLn2yaP9CP4CgJJhWcJ QYtzR4rq5faerTUX9xAfIVFlqUHdZUFv28d2RJeOXY+7Z4MItY0gL2tLo7vULyt/9uek xBrA== MIME-Version: 1.0 X-Received: by 10.42.133.133 with SMTP id h5mr12440707ict.45.1363098931007; Tue, 12 Mar 2013 07:35:31 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Tue, 12 Mar 2013 07:35:30 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Tue, 12 Mar 2013 07:35:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Mar 2013 08:35:30 -0600 Message-ID: From: jacek burghardt To: Sean Greenslade Cc: xen-users Subject: Re: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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="===============5409141148086764057==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5409141148086764057== Content-Type: multipart/alternative; boundary=90e6ba5bc09d939a8f04d7bb33ac --90e6ba5bc09d939a8f04d7bb33ac Content-Type: text/plain; charset=ISO-8859-1 I have 3 xen servers and i had used lvm for virtual drives on local storage I want to backup lvms to iscsi i had installed freenas under xen and I am thinking about exporting iscsi matching sizes of lvm virtual partitions so I can back them up rsync. I looking for ideas on proper way of backing up windows 2012s and archlinux --90e6ba5bc09d939a8f04d7bb33ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I have 3 xen servers and i had used lvm for virtual drives on local stor= age I want to backup lvms to iscsi i had installed freenas under xen and I = am thinking about exporting iscsi matching sizes of lvm virtual partitions = so I can back them up rsync. I looking for ideas on proper way of backing u= p windows 2012s and archlinux

--90e6ba5bc09d939a8f04d7bb33ac-- --===============5409141148086764057== 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 --===============5409141148086764057==-- From xen-users-bounces@lists.xen.org Tue Mar 12 16:42:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 16:42:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSGB-000103-PQ; Tue, 12 Mar 2013 16:41:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSG9-0000zg-GC for xen-users@lists.xen.org; Tue, 12 Mar 2013 16:41:05 +0000 Received: from [85.158.137.99:20396] by server-6.bemta-3.messagelabs.com id EB/DF-11048-0AA5F315; Tue, 12 Mar 2013 16:41:04 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1363106463!18011931!1 X-Originating-IP: [209.85.214.42] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1683 invoked from network); 12 Mar 2013 16:41:04 -0000 Received: from mail-bk0-f42.google.com (HELO mail-bk0-f42.google.com) (209.85.214.42) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 16:41:04 -0000 Received: by mail-bk0-f42.google.com with SMTP id jk7so20386bkc.15 for ; Tue, 12 Mar 2013 09:41:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=6xPvl98idUwI3MuqUeYWz/iD22IQ45PY4TRUgc0NjaY=; b=J5qXcLg6Fiow6AL46hiY5P5VMfLnEngIrOKUGK+hoOQf67ueQiOrvjoQkRzTFEsc1I urDofLFKN/GZIBqLhDQqqSlBeLyROJCPWDIRq3QJSHfDrEUX8bmIn+qZZCAGkfB65B6V fVDBDefeL1ZsyLw5SrhNyf6x0t9b1P/YWD6owr5eypA3DDrJ6vCsGHSPO9Mr4e0B511i MEzVomUam7V5C7ze3rg8A3vg7LrvCqcfuq6qIiEFLpsMN3FpK0VIncPWgM+soSWuhZrJ dJMfWIuU8lcpIbLNYhTSuoTIBuh7LOjK/ymG8nHeQgFXnezJqMhQm2BSESzIyPd5GoR2 gg2w== MIME-Version: 1.0 X-Received: by 10.204.231.6 with SMTP id jo6mr6464223bkb.30.1363106463590; Tue, 12 Mar 2013 09:41:03 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Tue, 12 Mar 2013 09:41:03 -0700 (PDT) Date: Tue, 12 Mar 2013 17:41:03 +0100 Message-ID: From: Sylvain Munaut To: xen-users@lists.xen.org X-Gm-Message-State: ALoCoQmZ3Ph7YoYpKGlNfDUa6udomA5A30SleI0/OmbWMIV3y6gF5F2dTpWyBlKbKMdS7hSEgwfk Subject: [Xen-users] Code path for Gratuitous ARP in live migration X-BeenThere: xen-users@lists.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 understand how (i.e. which event triggers what) a gratuitous ARP is supposed to be sent in case of live migration ... The only path I found that would create a NOTIFY_PEER is in the netfront driver if the state is changed to 'Connected'. Is that the path supposed to be triggered by a live migration ? Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 16:42:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 16:42:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSGB-000103-PQ; Tue, 12 Mar 2013 16:41:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSG9-0000zg-GC for xen-users@lists.xen.org; Tue, 12 Mar 2013 16:41:05 +0000 Received: from [85.158.137.99:20396] by server-6.bemta-3.messagelabs.com id EB/DF-11048-0AA5F315; Tue, 12 Mar 2013 16:41:04 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1363106463!18011931!1 X-Originating-IP: [209.85.214.42] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1683 invoked from network); 12 Mar 2013 16:41:04 -0000 Received: from mail-bk0-f42.google.com (HELO mail-bk0-f42.google.com) (209.85.214.42) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 16:41:04 -0000 Received: by mail-bk0-f42.google.com with SMTP id jk7so20386bkc.15 for ; Tue, 12 Mar 2013 09:41:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=6xPvl98idUwI3MuqUeYWz/iD22IQ45PY4TRUgc0NjaY=; b=J5qXcLg6Fiow6AL46hiY5P5VMfLnEngIrOKUGK+hoOQf67ueQiOrvjoQkRzTFEsc1I urDofLFKN/GZIBqLhDQqqSlBeLyROJCPWDIRq3QJSHfDrEUX8bmIn+qZZCAGkfB65B6V fVDBDefeL1ZsyLw5SrhNyf6x0t9b1P/YWD6owr5eypA3DDrJ6vCsGHSPO9Mr4e0B511i MEzVomUam7V5C7ze3rg8A3vg7LrvCqcfuq6qIiEFLpsMN3FpK0VIncPWgM+soSWuhZrJ dJMfWIuU8lcpIbLNYhTSuoTIBuh7LOjK/ymG8nHeQgFXnezJqMhQm2BSESzIyPd5GoR2 gg2w== MIME-Version: 1.0 X-Received: by 10.204.231.6 with SMTP id jo6mr6464223bkb.30.1363106463590; Tue, 12 Mar 2013 09:41:03 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Tue, 12 Mar 2013 09:41:03 -0700 (PDT) Date: Tue, 12 Mar 2013 17:41:03 +0100 Message-ID: From: Sylvain Munaut To: xen-users@lists.xen.org X-Gm-Message-State: ALoCoQmZ3Ph7YoYpKGlNfDUa6udomA5A30SleI0/OmbWMIV3y6gF5F2dTpWyBlKbKMdS7hSEgwfk Subject: [Xen-users] Code path for Gratuitous ARP in live migration X-BeenThere: xen-users@lists.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 understand how (i.e. which event triggers what) a gratuitous ARP is supposed to be sent in case of live migration ... The only path I found that would create a NOTIFY_PEER is in the netfront driver if the state is changed to 'Connected'. Is that the path supposed to be triggered by a live migration ? Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 16:46:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 16:46: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 1UFSKS-0001LD-O1; Tue, 12 Mar 2013 16:45:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UEyaC-0007Mi-BN for xen-users@lists.xen.org; Mon, 11 Mar 2013 08:59:48 +0000 Received: from [85.158.139.211:15970] by server-7.bemta-5.messagelabs.com id D9/A3-12441-30D9D315; Mon, 11 Mar 2013 08:59:47 +0000 X-Env-Sender: getchus1@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1362992386!18892942!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17167 invoked from network); 11 Mar 2013 08:59:46 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 08:59:46 -0000 Received: by mail-wi0-f170.google.com with SMTP id hm11so839178wib.5 for ; Mon, 11 Mar 2013 01:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=t4mquxHxkWEGgyccNs82z8hXjHxYFnoKx4H6d3pFLMs=; b=ilLX3NrJizsmnJwdbUntZc2xWljgMQ7W6EPnBexUFffW0WkyQbg+HLuJEkfVxH5V8e jgiOcsMJQRjUdIJr1Ac3V8wRtwYnpvAcgUQnfOEE2GwVVwp4FeIZpAdCxzFqgRMxTEQo OlaKitGyuXzIcpKzTgdyAJM9Yvu0+AV0HtkiVuV7FV+NVpIqgeUOur+7b7d5IcZ3Q+7o XAWfuNrhAVmpQEuHBbyQD9WvQwlZ09D/vKOehpJt9y5dFZNCds5Gnh8jrfZBGgo7LcEH h0ASzMI8LH9L4MZWMErpFjJkL8dC/y9mnonr2K3e7PGI/8c43P2V688EdmJ1yWv0T69+ UAWA== MIME-Version: 1.0 X-Received: by 10.194.58.202 with SMTP id t10mr17537322wjq.4.1362992386081; Mon, 11 Mar 2013 01:59:46 -0700 (PDT) Received: by 10.194.62.174 with HTTP; Mon, 11 Mar 2013 01:59:46 -0700 (PDT) Date: Mon, 11 Mar 2013 17:59:46 +0900 Message-ID: From: =?UTF-8?B?7J207JiB7KSA?= To: xen-users@lists.xen.org X-Mailman-Approved-At: Tue, 12 Mar 2013 16:45:32 +0000 Subject: [Xen-users] I can't migrate my DomU. X-BeenThere: xen-users@lists.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="===============7646499255512277059==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7646499255512277059== Content-Type: multipart/alternative; boundary=047d7b86de880154c304d7a2650c --047d7b86de880154c304d7a2650c Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hello everyone. I'm using xl.(Without Xend) I want to migrate my DomU to backup machine. But when I enter a command xl migrate gentoo 192.168.0.2 (192.168.0.2 is my guest IP) root@192.168.0.2's password: xend is running, which may cause unpredictable results when using this xl command. Please shut down xend before continuing. (This check can be overridden with the -f option.) libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated reading banner from migration receiver stream libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration target process [5360] exited with error status 1 This error is occur. My Dom0 is using Fedora 18. My Xen daemon's status is 1. systemctl status xend.service xend.service - Xend - interface between hypervisor and some applications Loaded: loaded (/usr/lib/systemd/system/xend.service; disabled) Active: inactive (dead) 2. systemctl status xenconsoled.service xenconsoled.service - Xenconsoled - handles logging from guest consoles and hypervisor Loaded: loaded (/usr/lib/systemd/system/xenconsoled.service; enabled) Active: active (running) since Mon 2013-03-11 08:36:35 JST; 9h ag= o Process: 601 ExecStartPre=3D/bin/grep -q control_d /proc/xen/capabilities (code=3Dexited, status=3D0/SUCCESS) Main PID: 645 (xenconsoled) CGroup: name=3Dsystemd:/system/xenconsoled.service =84=80645 /usr/sbin/xenconsoled --log=3Dnone --log-dir=3D/var/log/xen/console Mar 11 08:36:35 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Started Xenconsoled - handles logging from guest consoles and hypervisor. 3. systemctl status xen-watchdog.service xen-watchdog.service - Xen-watchdog - run xen watchdog daemon Loaded: loaded (/usr/lib/systemd/system/xen-watchdog.service; enabled) Active: active (running) since Mon 2013-03-11 08:36:34 JST; 9h ag= o Process: 534 ExecStart=3D/usr/sbin/xenwatchdogd 30 15 (code=3Dexit= ed, status=3D0/SUCCESS) Main PID: 537 (xenwatchdogd) CGroup: name=3Dsystemd:/system/xen-watchdog.service =84=80537 /usr/sbin/xenwatchdogd 30 15 Mar 11 08:36:33 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Starting Xen-watchdog - run xen watchdog daemon... Mar 11 08:36:34 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Started Xen-watchdog - run xen watchdog daemon. Thank you. --047d7b86de880154c304d7a2650c Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable
Hello everyone.
=9A
I'm using xl.(Without Xend= )
=9A
I want to migrate my DomU to backup machine. But = when I enter a command
xl migrate gentoo 192.168.0.2
(= 192.168.0.2 is my guest IP)
=9A
=9A
= root@192.168.0.2's password:
xend is running, which may cause un= predictable results when using
this xl command.=9A Please shut down xend= before continuing.
(This check can be overridden with the -f option.)
libxl: error: li= bxl_utils.c:363:libxl_read_exactly: file/stream truncated reading banner fr= om migration receiver stream
libxl: info: libxl_exec.c:118:libxl_report_= child_exitstatus: migration target process [5360] exited with error status = 1
=9A
=9A
This error is occur.
=9A
My Dom0 is using Fedora 18.
=9A
My Xen daemon's = status is
=9A
1. systemctl status xend.service
xend.service - Xend - interface between hypervisor and some applications=9A=9A=9A=9A=9A=9A=9A=9A=9A Loaded: loaded (/usr/lib/systemd/system/xend.s= ervice; disabled)
=9A=9A=9A=9A=9A=9A=9A=9A=9A Active: inactive (dead)
=9A
2. systemctl status xenconsoled.service
xenconsoled.service - Xenconsoled - handles logging from guest consoles and= hypervisor
=9A=9A=9A=9A=9A=9A=9A=9A=9A Loaded: loaded (/usr/lib/systemd= /system/xenconsoled.service; enabled)
=9A=9A=9A=9A=9A=9A=9A=9A=9A Active= : active (running) since Mon 2013-03-11 08:36:35 JST; 9h ago
=9A=9A=9A=9A=9A=9A=9A=9A Process: 601 ExecStartPre=3D/bin/grep -q control_d= /proc/xen/capabilities (code=3Dexited, status=3D0/SUCCESS)
=9A=9A=9A=9A= =9A=9A=9A Main PID: 645 (xenconsoled)
=9A=9A=9A=9A=9A=9A=9A=9A=9A CGroup= : name=3Dsystemd:/system/xenconsoled.service
=9A=9A=9A=9A=9A=9A=9A=9A=9A= =9A=9A=9A=9A=9A=9A=9A=9A =84=80645 /usr/sbin/xenconsoled --log=3Dnone --log= -dir=3D/var/log/xen/console
Mar 11 08:36:35 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Started Xenconsoled - = handles logging from guest consoles and hypervisor.
3. system= ctl status xen-watchdog.service
xen-watchdog.service - Xen-watchdog - run xen watchdog daemon
=9A=9A=9A= =9A=9A=9A=9A=9A=9A Loaded: loaded (/usr/lib/systemd/system/xen-watchdog.ser= vice; enabled)
=9A=9A=9A=9A=9A=9A=9A=9A=9A Active: active (running) sinc= e Mon 2013-03-11 08:36:34 JST; 9h ago
=9A=9A=9A=9A=9A=9A=9A=9A Process: 534 ExecStart=3D/usr/sbin/xenwatchdogd 30= 15 (code=3Dexited, status=3D0/SUCCESS)
=9A=9A=9A=9A=9A=9A=9A Main PID: = 537 (xenwatchdogd)
=9A=9A=9A=9A=9A=9A=9A=9A=9A CGroup: name=3Dsystemd:/s= ystem/xen-watchdog.service
=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A= =9A=9A =84=80537 /usr/sbin/xenwatchdogd 30 15
Mar 11 08:36:33 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Starting Xen-watchdog = - run xen watchdog daemon...
Mar 11 08:36:34 Lee-primary.k2.sslab.ics.keio.ac.jp systemd= [1]: Started Xen-watchdog - run xen watchdog daemon.
Thank you.
=9A
=9A
=9A
--047d7b86de880154c304d7a2650c-- --===============7646499255512277059== 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 --===============7646499255512277059==-- From xen-users-bounces@lists.xen.org Tue Mar 12 16:46:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 16:46: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 1UFSKS-0001LD-O1; Tue, 12 Mar 2013 16:45:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UEyaC-0007Mi-BN for xen-users@lists.xen.org; Mon, 11 Mar 2013 08:59:48 +0000 Received: from [85.158.139.211:15970] by server-7.bemta-5.messagelabs.com id D9/A3-12441-30D9D315; Mon, 11 Mar 2013 08:59:47 +0000 X-Env-Sender: getchus1@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1362992386!18892942!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17167 invoked from network); 11 Mar 2013 08:59:46 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2013 08:59:46 -0000 Received: by mail-wi0-f170.google.com with SMTP id hm11so839178wib.5 for ; Mon, 11 Mar 2013 01:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=t4mquxHxkWEGgyccNs82z8hXjHxYFnoKx4H6d3pFLMs=; b=ilLX3NrJizsmnJwdbUntZc2xWljgMQ7W6EPnBexUFffW0WkyQbg+HLuJEkfVxH5V8e jgiOcsMJQRjUdIJr1Ac3V8wRtwYnpvAcgUQnfOEE2GwVVwp4FeIZpAdCxzFqgRMxTEQo OlaKitGyuXzIcpKzTgdyAJM9Yvu0+AV0HtkiVuV7FV+NVpIqgeUOur+7b7d5IcZ3Q+7o XAWfuNrhAVmpQEuHBbyQD9WvQwlZ09D/vKOehpJt9y5dFZNCds5Gnh8jrfZBGgo7LcEH h0ASzMI8LH9L4MZWMErpFjJkL8dC/y9mnonr2K3e7PGI/8c43P2V688EdmJ1yWv0T69+ UAWA== MIME-Version: 1.0 X-Received: by 10.194.58.202 with SMTP id t10mr17537322wjq.4.1362992386081; Mon, 11 Mar 2013 01:59:46 -0700 (PDT) Received: by 10.194.62.174 with HTTP; Mon, 11 Mar 2013 01:59:46 -0700 (PDT) Date: Mon, 11 Mar 2013 17:59:46 +0900 Message-ID: From: =?UTF-8?B?7J207JiB7KSA?= To: xen-users@lists.xen.org X-Mailman-Approved-At: Tue, 12 Mar 2013 16:45:32 +0000 Subject: [Xen-users] I can't migrate my DomU. X-BeenThere: xen-users@lists.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="===============7646499255512277059==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7646499255512277059== Content-Type: multipart/alternative; boundary=047d7b86de880154c304d7a2650c --047d7b86de880154c304d7a2650c Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hello everyone. I'm using xl.(Without Xend) I want to migrate my DomU to backup machine. But when I enter a command xl migrate gentoo 192.168.0.2 (192.168.0.2 is my guest IP) root@192.168.0.2's password: xend is running, which may cause unpredictable results when using this xl command. Please shut down xend before continuing. (This check can be overridden with the -f option.) libxl: error: libxl_utils.c:363:libxl_read_exactly: file/stream truncated reading banner from migration receiver stream libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration target process [5360] exited with error status 1 This error is occur. My Dom0 is using Fedora 18. My Xen daemon's status is 1. systemctl status xend.service xend.service - Xend - interface between hypervisor and some applications Loaded: loaded (/usr/lib/systemd/system/xend.service; disabled) Active: inactive (dead) 2. systemctl status xenconsoled.service xenconsoled.service - Xenconsoled - handles logging from guest consoles and hypervisor Loaded: loaded (/usr/lib/systemd/system/xenconsoled.service; enabled) Active: active (running) since Mon 2013-03-11 08:36:35 JST; 9h ag= o Process: 601 ExecStartPre=3D/bin/grep -q control_d /proc/xen/capabilities (code=3Dexited, status=3D0/SUCCESS) Main PID: 645 (xenconsoled) CGroup: name=3Dsystemd:/system/xenconsoled.service =84=80645 /usr/sbin/xenconsoled --log=3Dnone --log-dir=3D/var/log/xen/console Mar 11 08:36:35 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Started Xenconsoled - handles logging from guest consoles and hypervisor. 3. systemctl status xen-watchdog.service xen-watchdog.service - Xen-watchdog - run xen watchdog daemon Loaded: loaded (/usr/lib/systemd/system/xen-watchdog.service; enabled) Active: active (running) since Mon 2013-03-11 08:36:34 JST; 9h ag= o Process: 534 ExecStart=3D/usr/sbin/xenwatchdogd 30 15 (code=3Dexit= ed, status=3D0/SUCCESS) Main PID: 537 (xenwatchdogd) CGroup: name=3Dsystemd:/system/xen-watchdog.service =84=80537 /usr/sbin/xenwatchdogd 30 15 Mar 11 08:36:33 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Starting Xen-watchdog - run xen watchdog daemon... Mar 11 08:36:34 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Started Xen-watchdog - run xen watchdog daemon. Thank you. --047d7b86de880154c304d7a2650c Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable
Hello everyone.
=9A
I'm using xl.(Without Xend= )
=9A
I want to migrate my DomU to backup machine. But = when I enter a command
xl migrate gentoo 192.168.0.2
(= 192.168.0.2 is my guest IP)
=9A
=9A
= root@192.168.0.2's password:
xend is running, which may cause un= predictable results when using
this xl command.=9A Please shut down xend= before continuing.
(This check can be overridden with the -f option.)
libxl: error: li= bxl_utils.c:363:libxl_read_exactly: file/stream truncated reading banner fr= om migration receiver stream
libxl: info: libxl_exec.c:118:libxl_report_= child_exitstatus: migration target process [5360] exited with error status = 1
=9A
=9A
This error is occur.
=9A
My Dom0 is using Fedora 18.
=9A
My Xen daemon's = status is
=9A
1. systemctl status xend.service
xend.service - Xend - interface between hypervisor and some applications=9A=9A=9A=9A=9A=9A=9A=9A=9A Loaded: loaded (/usr/lib/systemd/system/xend.s= ervice; disabled)
=9A=9A=9A=9A=9A=9A=9A=9A=9A Active: inactive (dead)
=9A
2. systemctl status xenconsoled.service
xenconsoled.service - Xenconsoled - handles logging from guest consoles and= hypervisor
=9A=9A=9A=9A=9A=9A=9A=9A=9A Loaded: loaded (/usr/lib/systemd= /system/xenconsoled.service; enabled)
=9A=9A=9A=9A=9A=9A=9A=9A=9A Active= : active (running) since Mon 2013-03-11 08:36:35 JST; 9h ago
=9A=9A=9A=9A=9A=9A=9A=9A Process: 601 ExecStartPre=3D/bin/grep -q control_d= /proc/xen/capabilities (code=3Dexited, status=3D0/SUCCESS)
=9A=9A=9A=9A= =9A=9A=9A Main PID: 645 (xenconsoled)
=9A=9A=9A=9A=9A=9A=9A=9A=9A CGroup= : name=3Dsystemd:/system/xenconsoled.service
=9A=9A=9A=9A=9A=9A=9A=9A=9A= =9A=9A=9A=9A=9A=9A=9A=9A =84=80645 /usr/sbin/xenconsoled --log=3Dnone --log= -dir=3D/var/log/xen/console
Mar 11 08:36:35 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Started Xenconsoled - = handles logging from guest consoles and hypervisor.
3. system= ctl status xen-watchdog.service
xen-watchdog.service - Xen-watchdog - run xen watchdog daemon
=9A=9A=9A= =9A=9A=9A=9A=9A=9A Loaded: loaded (/usr/lib/systemd/system/xen-watchdog.ser= vice; enabled)
=9A=9A=9A=9A=9A=9A=9A=9A=9A Active: active (running) sinc= e Mon 2013-03-11 08:36:34 JST; 9h ago
=9A=9A=9A=9A=9A=9A=9A=9A Process: 534 ExecStart=3D/usr/sbin/xenwatchdogd 30= 15 (code=3Dexited, status=3D0/SUCCESS)
=9A=9A=9A=9A=9A=9A=9A Main PID: = 537 (xenwatchdogd)
=9A=9A=9A=9A=9A=9A=9A=9A=9A CGroup: name=3Dsystemd:/s= ystem/xen-watchdog.service
=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A=9A= =9A=9A =84=80537 /usr/sbin/xenwatchdogd 30 15
Mar 11 08:36:33 Lee-primary.k2.sslab.ics.keio.ac.jp systemd[1]: Starting Xen-watchdog = - run xen watchdog daemon...
Mar 11 08:36:34 Lee-primary.k2.sslab.ics.keio.ac.jp systemd= [1]: Started Xen-watchdog - run xen watchdog daemon.
Thank you.
=9A
=9A
=9A
--047d7b86de880154c304d7a2650c-- --===============7646499255512277059== 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 --===============7646499255512277059==-- From xen-users-bounces@lists.xen.org Tue Mar 12 16:49:15 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 16:49: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 1UFSNM-0001dS-12; Tue, 12 Mar 2013 16:48:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSNL-0001dG-0G for xen-users@lists.xen.org; Tue, 12 Mar 2013 16:48:31 +0000 Received: from [193.109.254.147:15998] by server-13.bemta-14.messagelabs.com id 5C/52-07387-E5C5F315; Tue, 12 Mar 2013 16:48:30 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-10.tower-27.messagelabs.com!1363106859!3432370!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25588 invoked from network); 12 Mar 2013 16:47:40 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-10.tower-27.messagelabs.com with SMTP; 12 Mar 2013 16:47:40 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:64792) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UFSMV-0001og-9N (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Tue, 12 Mar 2013 16:47:39 +0000 Message-ID: <513F5C1E.7010407@cam.ac.uk> Date: Tue, 12 Mar 2013 16:47:26 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============0037278615174423585==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============0037278615174423585== Content-Type: multipart/alternative; boundary="------------090101020904050303000605" This is a multi-part message in MIME format. --------------090101020904050303000605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm going to try XCP next but before I did I thought I'd try something a little crazy. I foundthis thread and decided to apply the patch and see if I could get the gpu to be passed through as the primary adapter. Interestingly I can now see the bios output from the VM on my monitor but once that finishes the screen just goes blank again. At this point I'm just trying to boot an installer cd (either windows or ubuntu) so it cannot be a driver issue in the vm. As I said I'll try XCP next, but this is starting to feel like a problem very specific to my hardware. Matt --------------090101020904050303000605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm going to try XCP next but before I did I thought I'd try something a little crazy.  I found this thread and decided to apply the patch and see if I could get the gpu to be passed through as the primary adapter.  Interestingly I can now see the bios output from the VM on my monitor but once that finishes the screen just goes blank again.  At this point I'm just trying to boot an installer cd (either windows or ubuntu) so it cannot be a driver issue in the vm.  As I said I'll try XCP next, but this is starting to feel like a problem very specific to my hardware.

Matt
--------------090101020904050303000605-- --===============0037278615174423585== 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 --===============0037278615174423585==-- From xen-users-bounces@lists.xen.org Tue Mar 12 16:49:15 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 16:49: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 1UFSNM-0001dS-12; Tue, 12 Mar 2013 16:48:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSNL-0001dG-0G for xen-users@lists.xen.org; Tue, 12 Mar 2013 16:48:31 +0000 Received: from [193.109.254.147:15998] by server-13.bemta-14.messagelabs.com id 5C/52-07387-E5C5F315; Tue, 12 Mar 2013 16:48:30 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-10.tower-27.messagelabs.com!1363106859!3432370!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25588 invoked from network); 12 Mar 2013 16:47:40 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-10.tower-27.messagelabs.com with SMTP; 12 Mar 2013 16:47:40 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:64792) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UFSMV-0001og-9N (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Tue, 12 Mar 2013 16:47:39 +0000 Message-ID: <513F5C1E.7010407@cam.ac.uk> Date: Tue, 12 Mar 2013 16:47:26 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============0037278615174423585==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============0037278615174423585== Content-Type: multipart/alternative; boundary="------------090101020904050303000605" This is a multi-part message in MIME format. --------------090101020904050303000605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm going to try XCP next but before I did I thought I'd try something a little crazy. I foundthis thread and decided to apply the patch and see if I could get the gpu to be passed through as the primary adapter. Interestingly I can now see the bios output from the VM on my monitor but once that finishes the screen just goes blank again. At this point I'm just trying to boot an installer cd (either windows or ubuntu) so it cannot be a driver issue in the vm. As I said I'll try XCP next, but this is starting to feel like a problem very specific to my hardware. Matt --------------090101020904050303000605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm going to try XCP next but before I did I thought I'd try something a little crazy.  I found this thread and decided to apply the patch and see if I could get the gpu to be passed through as the primary adapter.  Interestingly I can now see the bios output from the VM on my monitor but once that finishes the screen just goes blank again.  At this point I'm just trying to boot an installer cd (either windows or ubuntu) so it cannot be a driver issue in the vm.  As I said I'll try XCP next, but this is starting to feel like a problem very specific to my hardware.

Matt
--------------090101020904050303000605-- --===============0037278615174423585== 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 --===============0037278615174423585==-- From xen-users-bounces@lists.xen.org Tue Mar 12 16:50:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 16:50:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSOS-0001sU-Bg; Tue, 12 Mar 2013 16:49:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSOQ-0001rk-JQ for xen-users@lists.xen.org; Tue, 12 Mar 2013 16:49:38 +0000 Received: from [85.158.138.51:33503] by server-2.bemta-3.messagelabs.com id 44/C9-05208-1AC5F315; Tue, 12 Mar 2013 16:49:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1363106977!22686246!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28855 invoked from network); 12 Mar 2013 16:49:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 16:49:37 -0000 X-IronPort-AV: E=Sophos;i="4.84,831,1355097600"; d="scan'208";a="2422738" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Mar 2013 16:49:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 12 Mar 2013 16:49:37 +0000 Message-ID: <1363106975.32410.55.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sylvain Munaut Date: Tue, 12 Mar 2013 16:49:35 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Code path for Gratuitous ARP in live migration X-BeenThere: xen-users@lists.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, 2013-03-12 at 16:41 +0000, Sylvain Munaut wrote: > Hi, > > I'm trying to understand how (i.e. which event triggers what) a > gratuitous ARP is supposed to be sent in case of live migration ... > > The only path I found that would create a NOTIFY_PEER is in the > netfront driver if the state is changed to 'Connected'. Is that the > path supposed to be triggered by a live migration ? Yes, because devices are reconnected after the migration, which triggers that path. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 16:50:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 16:50:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSOS-0001sU-Bg; Tue, 12 Mar 2013 16:49:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFSOQ-0001rk-JQ for xen-users@lists.xen.org; Tue, 12 Mar 2013 16:49:38 +0000 Received: from [85.158.138.51:33503] by server-2.bemta-3.messagelabs.com id 44/C9-05208-1AC5F315; Tue, 12 Mar 2013 16:49:37 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1363106977!22686246!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28855 invoked from network); 12 Mar 2013 16:49:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 16:49:37 -0000 X-IronPort-AV: E=Sophos;i="4.84,831,1355097600"; d="scan'208";a="2422738" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Mar 2013 16:49:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 12 Mar 2013 16:49:37 +0000 Message-ID: <1363106975.32410.55.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sylvain Munaut Date: Tue, 12 Mar 2013 16:49:35 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Code path for Gratuitous ARP in live migration X-BeenThere: xen-users@lists.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, 2013-03-12 at 16:41 +0000, Sylvain Munaut wrote: > Hi, > > I'm trying to understand how (i.e. which event triggers what) a > gratuitous ARP is supposed to be sent in case of live migration ... > > The only path I found that would create a NOTIFY_PEER is in the > netfront driver if the state is changed to 'Connected'. Is that the > path supposed to be triggered by a live migration ? Yes, because devices are reconnected after the migration, which triggers that path. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 17:34:09 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 17:34: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 1UFT4l-0006AJ-T2; Tue, 12 Mar 2013 17:33:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFT4k-0006A6-Q2 for xen-users@lists.xen.org; Tue, 12 Mar 2013 17:33:22 +0000 Received: from [85.158.143.99:42045] by server-2.bemta-4.messagelabs.com id 58/99-12656-2E66F315; Tue, 12 Mar 2013 17:33:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1363109601!28149611!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25424 invoked from network); 12 Mar 2013 17:33:21 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 17:33:21 -0000 X-IronPort-AV: E=Sophos;i="4.84,832,1355097600"; d="scan'208";a="2425510" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Mar 2013 17:33:22 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 12 Mar 2013 17:33:21 +0000 Message-ID: <1363109599.32410.87.camel@zakaz.uk.xensource.com> From: Ian Campbell To: =?UTF-8?Q?=EC=9D=B4=EC=98=81=EC=A4=80?= Date: Tue, 12 Mar 2013 17:33:19 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] I can't migrate my DomU. X-BeenThere: xen-users@lists.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 T24gTW9uLCAyMDEzLTAzLTExIGF0IDA4OjU5ICswMDAwLCDsnbTsmIHspIAgd3JvdGU6Cj4gSGVs bG8gZXZlcnlvbmUuCj4gIAo+IEknbSB1c2luZyB4bC4oV2l0aG91dCBYZW5kKQo+ICAKPiBJIHdh bnQgdG8gbWlncmF0ZSBteSBEb21VIHRvIGJhY2t1cCBtYWNoaW5lLiBCdXQgd2hlbiBJIGVudGVy IGEKPiBjb21tYW5kIAo+IHhsIG1pZ3JhdGUgZ2VudG9vIDE5Mi4xNjguMC4yCj4gKDE5Mi4xNjgu MC4yIGlzIG15IGd1ZXN0IElQKQoKVGhlIG9wdGlvbiB0byB4bCBtaWdyYXRlIGlzIHRoZSAqaG9z dCogb2YgdGhlIG1hY2hpbmUgeW91IHdhbnQgdG8KbWlncmF0ZSB0aGUgVk0gdG9vLCBub3QgdGhl IElQIG9mIHRoZSBWTS4KICAKPiByb290QDE5Mi4xNjguMC4yJ3MgcGFzc3dvcmQ6CgpZb3UgbmVl ZCB0byBzZXR1cCBzc2ggYmV0d2VlbiB0aGUgY3VycmVudCBob3N0IGFuZCB0aGUgZGVzdGluYXRp b24gaG9zdCwKSSBmaW5kIGl0IG11Y2ggZWFzaWVyIHRvIHVzZSBzc2ggcHVibGljIGtleSBhdXRo IHRoYW4gdG8gdHlwZSBwYXNzd29yZHMuCgo+IHhlbmQgaXMgcnVubmluZywgd2hpY2ggbWF5IGNh dXNlIHVucHJlZGljdGFibGUgcmVzdWx0cyB3aGVuIHVzaW5nCj4gdGhpcyB4bCBjb21tYW5kLiAg UGxlYXNlIHNodXQgZG93biB4ZW5kIGJlZm9yZSBjb250aW51aW5nLgoKRGlkIHlvdSBwZXJoYXBz IHJ1biB4ZW5kIHByZXZpb3VzbHkgYW5kIHN0b3AgaXQ/IFRoYXQgbWlnaHQgY2F1c2UgZmFsc2UK K3Zlcy4KCkl0IHdvdWxkIGJlIGJldHRlciB0byBmdWxseSBkaXNhYmxlIGl0IChJIGRvbid0IGtu b3cgaG93IHdpdGggc3lzdGVtZCkKYW5kIHJlYm9vdC4KCgoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVz ZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Tue Mar 12 17:34:09 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 17:34: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 1UFT4l-0006AJ-T2; Tue, 12 Mar 2013 17:33:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFT4k-0006A6-Q2 for xen-users@lists.xen.org; Tue, 12 Mar 2013 17:33:22 +0000 Received: from [85.158.143.99:42045] by server-2.bemta-4.messagelabs.com id 58/99-12656-2E66F315; Tue, 12 Mar 2013 17:33:22 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1363109601!28149611!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25424 invoked from network); 12 Mar 2013 17:33:21 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 17:33:21 -0000 X-IronPort-AV: E=Sophos;i="4.84,832,1355097600"; d="scan'208";a="2425510" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 12 Mar 2013 17:33:22 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 12 Mar 2013 17:33:21 +0000 Message-ID: <1363109599.32410.87.camel@zakaz.uk.xensource.com> From: Ian Campbell To: =?UTF-8?Q?=EC=9D=B4=EC=98=81=EC=A4=80?= Date: Tue, 12 Mar 2013 17:33:19 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] I can't migrate my DomU. X-BeenThere: xen-users@lists.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 T24gTW9uLCAyMDEzLTAzLTExIGF0IDA4OjU5ICswMDAwLCDsnbTsmIHspIAgd3JvdGU6Cj4gSGVs bG8gZXZlcnlvbmUuCj4gIAo+IEknbSB1c2luZyB4bC4oV2l0aG91dCBYZW5kKQo+ICAKPiBJIHdh bnQgdG8gbWlncmF0ZSBteSBEb21VIHRvIGJhY2t1cCBtYWNoaW5lLiBCdXQgd2hlbiBJIGVudGVy IGEKPiBjb21tYW5kIAo+IHhsIG1pZ3JhdGUgZ2VudG9vIDE5Mi4xNjguMC4yCj4gKDE5Mi4xNjgu MC4yIGlzIG15IGd1ZXN0IElQKQoKVGhlIG9wdGlvbiB0byB4bCBtaWdyYXRlIGlzIHRoZSAqaG9z dCogb2YgdGhlIG1hY2hpbmUgeW91IHdhbnQgdG8KbWlncmF0ZSB0aGUgVk0gdG9vLCBub3QgdGhl IElQIG9mIHRoZSBWTS4KICAKPiByb290QDE5Mi4xNjguMC4yJ3MgcGFzc3dvcmQ6CgpZb3UgbmVl ZCB0byBzZXR1cCBzc2ggYmV0d2VlbiB0aGUgY3VycmVudCBob3N0IGFuZCB0aGUgZGVzdGluYXRp b24gaG9zdCwKSSBmaW5kIGl0IG11Y2ggZWFzaWVyIHRvIHVzZSBzc2ggcHVibGljIGtleSBhdXRo IHRoYW4gdG8gdHlwZSBwYXNzd29yZHMuCgo+IHhlbmQgaXMgcnVubmluZywgd2hpY2ggbWF5IGNh dXNlIHVucHJlZGljdGFibGUgcmVzdWx0cyB3aGVuIHVzaW5nCj4gdGhpcyB4bCBjb21tYW5kLiAg UGxlYXNlIHNodXQgZG93biB4ZW5kIGJlZm9yZSBjb250aW51aW5nLgoKRGlkIHlvdSBwZXJoYXBz IHJ1biB4ZW5kIHByZXZpb3VzbHkgYW5kIHN0b3AgaXQ/IFRoYXQgbWlnaHQgY2F1c2UgZmFsc2UK K3Zlcy4KCkl0IHdvdWxkIGJlIGJldHRlciB0byBmdWxseSBkaXNhYmxlIGl0IChJIGRvbid0IGtu b3cgaG93IHdpdGggc3lzdGVtZCkKYW5kIHJlYm9vdC4KCgoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVz ZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Tue Mar 12 19:43:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 19:43: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 1UFV65-0002gj-RU; Tue, 12 Mar 2013 19:42:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFV63-0002gX-Og for xen-users@lists.xen.org; Tue, 12 Mar 2013 19:42:52 +0000 Received: from [85.158.137.99:55678] by server-3.bemta-3.messagelabs.com id 1A/0A-26934-A358F315; Tue, 12 Mar 2013 19:42:50 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1363117369!18036027!1 X-Originating-IP: [74.125.82.47] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18285 invoked from network); 12 Mar 2013 19:42:49 -0000 Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com) (74.125.82.47) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 19:42:49 -0000 Received: by mail-wg0-f47.google.com with SMTP id dr13so220673wgb.26 for ; Tue, 12 Mar 2013 12:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=7Lp3zNaSLFnb9vrXaaisL8a88XAxLEYUJyguNp4XEwo=; b=Ix3xKc7xkJHmNEjH58QsEYrcuTUW0Gey6y84Aivx30cp1xjdlDDPH8LY3ZMU3nfsDC zngPpSzIrCkFPPPieHUi8k9b5TnFJ2pwgtKb/xtCFUY5WIbO0ea1iMDa08BBaloXxzlH wmlnWs7OKPeSEs3tx+fgzfkTFkuT6Npd7Jp1FuMvpDTcVkyM6XTAfKc8tQPZFo+CvfAY 0kGGnHk0YCeJ3GI9NC0isYE0WqJreymKbS8ItZFXXj6MVAj1jLkG+Lbpq+44rnRHqHXS QmfIH+Q/Zo3F6uJQkGeyHbmy0ZZ8Dh1rCrYS35hzG/r9q3VO4I0ilybMcgOwJRXJ0lmu 6PIQ== X-Received: by 10.180.73.238 with SMTP id o14mr22207079wiv.32.1363117369413; Tue, 12 Mar 2013 12:42:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 12 Mar 2013 12:42:28 -0700 (PDT) In-Reply-To: <513F5C1E.7010407@cam.ac.uk> References: <513F5C1E.7010407@cam.ac.uk> From: Matthias Date: Tue, 12 Mar 2013 20:42:28 +0100 Message-ID: To: Matthew Dean Content-Type: multipart/mixed; boundary=f46d043c80da97848004d7bf7ed2 Cc: "xen-users@lists.xen.org" , greg@wind.enjellic.com Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@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 --f46d043c80da97848004d7bf7ed2 Content-Type: text/plain; charset=ISO-8859-1 Hi, to fix the atikmeq.sys bug, you can try two things: 1) Use upstream qemu. For this, just add: device_model_version = 'qemu-xen' device_model_override = '/usr/lib/xen/bin/qemu-system-i386' to your domU config file. Note that there is currently a bug that the domU won't start when duing vga passthrough with more then 4GB memory assigned, so better use some less.. 2) If you want to have more then 4GB memory, you can patch the traditional qemu. This is a bit more complicated cause the qemu stuff is download through the build and can't be patched right away. Also stopping in mid build, patching and continuing at least for me caused some problems, so doing a full build, patch, cleanup and build again is the safer route: git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging cd xen-unstable-staging ./configure --disable-stubdom make -j12 world git apply --check /path/to/xen-unstable-atipassthrough.patch git apply /path/to/xen-unstable-atipassthrough.patch make -j12 clean make -j12 world Now do your usual install.. some use the standard, i prefer creating a debball.. Some Notes: - I use the staging branch from xen-unstable, but this is not exactly necessary for the patch, you can use master just as fine - the j12 is for multithreading and you should use double your core number.. since i got 6 cpu cores, it's 12 for me.. - the patch i have attached is originally from Greg (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), so credit goes to him, i only cleaned it up for xen-unstable. Also, the patch itself was for providing primary passthrough with ATI cards, but i found it fixing my ati 0x116 bluescreen.. - due to an insufficiancy in the patch, stubdom would not build correctly, so you have to disable it Please report back if the patch fixes your bluescreen for more argumentation to bring this patch upstream.. :) (@Greg: that's why i cc'ed you. hope you don't mind the noise) Hope it helps! --f46d043c80da97848004d7bf7ed2 Content-Type: application/octet-stream; name="xen-unstable-atipassthrough.patch" Content-Disposition: attachment; filename="xen-unstable-atipassthrough.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_he7gshdq0 ZGlmZiAtdXJOcCBhL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91 Z2guYyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91Z2guYwot LS0gYS90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcGFzcy10aHJvdWdoLmMJVGh1 IFNlcCAgNiAxMTowNTozMCAyMDEyCisrKyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRp ci9ody9wYXNzLXRocm91Z2guYwlTYXQgTm92IDI0IDA4OjI3OjA3IDIwMTIKQEAgLTE0MzgsOSAr MTQzOCwxNyBAQCBzdGF0aWMgdm9pZCBwdF9pb3BvcnRfbWFwKFBDSURldmljZSAqZCwgCiAgICAg aWYgKGVfcGh5cyAhPSAtMSkKICAgICB7CiAgICAgICAgIC8qIENyZWF0ZSBuZXcgbWFwcGluZyAq LwotICAgICAgICByZXQgPSB4Y19kb21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21p ZCwgZV9waHlzLAotICAgICAgICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ld LmFjY2Vzcy5waW9fYmFzZSwgZV9zaXplLAotICAgICAgICAgICAgICAgICAgICBEUENJX0FERF9N QVBQSU5HKTsKKyAgICAgICAgaWYgKCB2Z2Ffc2tpcF9pb3BvcnRfbWFwKGQpICkgCisgICAgICAg IHsKKyAgICAgICAgICAgIGFzc2lnbmVkX2RldmljZS0+YmFzZXNbaV0uZV9waHlzYmFzZSA9IC0x OworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgeworICAgICAgICAgICAgcmV0ID0g eGNfZG9tYWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIGVfcGh5cywKKyAgICAg ICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmFjY2Vzcy5waW9fYmFzZSwg ZV9zaXplLAorICAgICAgICAgICAgICAgICAgIERQQ0lfQUREX01BUFBJTkcpOworICAgICAgICB9 CisKICAgICAgICAgaWYgKCByZXQgIT0gMCApCiAgICAgICAgIHsKICAgICAgICAgICAgIFBUX0xP RygiRXJyb3I6IGNyZWF0ZSBuZXcgbWFwcGluZyBmYWlsZWQhXG4iKTsKZGlmZiAtdXJOcCBhL3Rv b2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91Z2guaCBiL3Rvb2xzL3Fl bXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91Z2guaAotLS0gYi90b29scy9xZW11 LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcGFzcy10aHJvdWdoLmgJVGh1IFNlcCAgNiAxMTowNToz MCAyMDEyCisrKyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91 Z2guaAlTYXQgTm92IDI0IDA4OjI3OjA3IDIwMTIKQEAgLTQxOSw2ICs0MTksMTEgQEAgaW50IHB0 X3BjaV9ob3N0X3dyaXRlKHN0cnVjdCBwY2lfZGV2ICpwYwogdm9pZCBpbnRlbF9wY2hfaW5pdChQ Q0lCdXMgKmJ1cyk7CiBpbnQgcmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVh bF9kZXZpY2UpOwogaW50IHVucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVh bF9kZXZpY2UpOworaW50IHZnYV9za2lwX2lvcG9ydF9tYXAoUENJRGV2aWNlICpkKTsKK2ludCBp Z2RfcmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpOworaW50 IGlnZF91bnJlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2aWNlKTsK K2ludCBhdGlfcmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2Up OworaW50IGF0aV91bnJlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2 aWNlKTsKIGludCBzZXR1cF92Z2FfcHQoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpOwogUENJ QnVzICppbnRlbF9wY2lfYnJpZGdlX2luaXQoUENJQnVzICpidXMsIGludCBkZXZmbiwgdWludDE2 X3QgdmlkLAogICAgICAgICAgICB1aW50MTZfdCBkaWQsIGNvbnN0IGNoYXIgKm5hbWUsIHVpbnQx Nl90IHJldmlzaW9uKTsKZGlmZiAtdXJOcCBhL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRp ci9ody9wY2kuaCBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wY2kuaAotLS0g YS90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcGNpLmgJVGh1IFNlcCAgNiAxMTow NTozMCAyMDEyCisrKyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wY2kuaAlT YXQgTm92IDI0IDA4OjI3OjA3IDIwMTIKQEAgLTU0LDYgKzU0LDggQEAgZXh0ZXJuIHRhcmdldF9w aHlzX2FkZHJfdCBwY2lfbWVtX2Jhc2U7CiAKICNkZWZpbmUgUENJX1ZFTkRPUl9JRF9DSVJSVVMg ICAgICAgICAgICAgMHgxMDEzCiAKKyNkZWZpbmUgUENJX1ZFTkRPUl9JRF9BVEkgICAgICAgICAg ICAgICAgMHgxMDAyCisKICNkZWZpbmUgUENJX1ZFTkRPUl9JRF9JQk0gICAgICAgICAgICAgICAg MHgxMDE0CiAjZGVmaW5lIFBDSV9ERVZJQ0VfSURfSUJNX09QRU5QSUMyICAgICAgIDB4ZmZmZgog CmRpZmYgLXVyTnAgYS90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcHQtZ3JhcGhp Y3MuYyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wdC1ncmFwaGljcy5jCi0t LSBhL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wdC1ncmFwaGljcy5jCVRodSBT ZXAgIDYgMTE6MDU6MzAgMjAxMgorKysgYi90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIv aHcvcHQtZ3JhcGhpY3MuYwlTYXQgTm92IDI0IDA4OjI4OjEwIDIwMTIKQEAgLTgsMTAgKzgsMjEy IEBACiAKICNpbmNsdWRlIDx1bmlzdGQuaD4KICNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KKyNpbmNs dWRlIDxzeXMvaW8uaD4KICNpbmNsdWRlIDxhc3NlcnQuaD4KIAogZXh0ZXJuIGludCBnZnhfcGFz c3RocnU7CiBleHRlcm4gaW50IGlnZF9wYXNzdGhydTsKKy8qKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKiovCisvKiAgIENvZGUgZm9yIEFUSSBHRlggUGFzc3RocnUgICAqLworLyoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKy8qIEFUSSBWQklPUyBXb3JraW5nIE1lY2hh bmlzbSAKKyAqCisgKiBHZW5lcmFsbHkgdGhlcmUgYXJlIHRocmVlIG1lbW9yeSByZXNvdXJjZXMg KHR3byBNTUlPIGFuZCBvbmUgUElPKSAKKyAqIGFzc29jaWF0ZWQgd2l0aCBtb2Rlcm4gQVRJIGdm eC4gVkJJT1MgdXNlcyBzcGVjaWFsIHRyaWNrcyB0byBmaWd1cmUgb3V0IAorICogQkFScywgaW5z dGVhZCBvZiB1c2luZyByZWd1bGFyIFBDSSBjb25maWcgc3BhY2UgcmVhZC4KKyAqCisgKiAgKDEp IFZCSU9TIHJlbGllcyBvbiBJL08gcG9ydCAweDNDMyB0byByZXRyaWV2ZSBQSU8gQkFSIAorICog ICgyKSBWQklPUyBtYWludGFpbnMgYSBzaGFkb3cgY29weSBvZiBQQ0kgY29uZmlndXJlIHNwYWNl LiBJdCByZXRyaWVzIHRoZSAKKyAqICAgICAgTU1JTyBCQVJzIGZyb20gdGhpcyBzaGFkb3cgY29w eSB2aWEgc2VuZGluZyBJL08gcmVxdWVzdHMgdG8gZmlyc3QgdHdvIAorICogICAgICByZWdpc3Rl cnMgb2YgUElPIChNTUlOREVYIGFuZCBNTURBVEEpLiBUaGUgd29ya2Zsb3cgaXMgbGlrZSB0aGlz OiAKKyAqICAgICAgTU1JTkRFWCAocmVnaXN0ZXIgMCkgaXMgd3JpdHRlbiB3aXRoIGFuIGluZGV4 IHZhbHVlLCBzcGVjaWZ5aW5nIHRoZSAKKyAqICAgICAgcmVnaXN0ZXIgVkJJT1Mgd2FudGluZyB0 byBhY2Nlc3MuIFRoZW4gdGhlIHNoYWRvd2VkIGRhdGEgY2FuIGJlIAorICogICAgICByZWFkL3dy aXR0ZW4gZnJvbSBNTURBVEEgKHJlZ2lzdGVyIDEpLiBGb3IgdHdvIE1NSU8gQkFScywgdGhlIGlu ZGV4IAorICogICAgICB2YWx1ZXMgYXJlIDB4NDAxMCBhbmQgMHg0MDE0IHJlc3BlY3RpdmVseS4g CisgKgorICovCisKKyNkZWZpbmUgQVRJX0JBUjFfSU5ERVggICAgICAgIDAgIC8vTU1JTyBCQVIx CisjZGVmaW5lIEFUSV9CQVIyX0lOREVYICAgICAgICAxICAvL01NSU8gQkFSMgorI2RlZmluZSBB VElfQkFSNV9JTkRFWCAgICAgICAgNCAgLy9QSU8gQkFSID09IEJBUjUKKworI2RlZmluZSBBVElf QkFSMV9NTUlOREVYICAgICAgMHg0MDEwICAvL2RhdGEgd3JpdHRlbiB0byBNTUlOREVYIGZvciBN TUlPIEJBUjEKKyNkZWZpbmUgQVRJX0JBUjJfTU1JTkRFWCAgICAgIDB4NDAxNCAgLy9kYXRhIHdy aXR0ZW4gdG8gTU1JTkRFWCBGT1IgTU1JTyBCQVIyCisKK3N0cnVjdCBhdGlfZ2Z4X2luZm8gewor ICAgIGludCBpbml0aWFsaXplZDsgICAgICAgICAgICAvKiBpbml0aWFsaXplZCBhbHJlYWR5PyAq LworCisgICAgLyogUElPICovCisgICAgdWludDMyX3QgaG9zdF9waW9fYmFzZTsgICAgIC8qIGhv c3QgYmFzZSBhZGRyIG9mIFBJTyAqLworICAgIHVpbnQzMl90IGd1ZXN0X3Bpb19iYXNlOyAgICAv KiBndWVzdCBiYXNlIGFkZHIgb2YgUElPICovCisgICAgdWludDMyX3QgcGlvX3NpemU7ICAgICAg ICAgIC8qIFBJTyBzaXplICovCisKKyAgICAvKiBNTUlPICovCisgICAgdWludDMyX3QgZ3Vlc3Rf bW1pb19iYXNlMTsgIC8qIGd1ZXN0IGJhc2UgYWRkciBvZiBNTUlPIDEgKi8KKyAgICB1aW50MzJf dCBndWVzdF9tbWlvX2Jhc2UyOyAgLyogZ3Vlc3QgYmFzZSBhZGRyIG9mIE1NSU8gMiAqLworCisg ICAgLyogUElPIE1NSU5ERVggYWNjZXNzIHJlY29yZGluZyAqLworICAgIHVpbnQzMl90IHByZV9t bWluZGV4X2RhdGE7ICAgICAgIC8qIHByZXZpb3VzIGRhdGEgd3JpdHRlbiB0byBNTUlOREVYICov Cit9OworCitzdGF0aWMgc3RydWN0IGF0aV9nZnhfaW5mbyBnZnhfaW5mbzsKKworLyogQ29udmVy dCBndWVzdCBQSU8gcG9ydCB0byBob3N0IFBJTyBwb3J0ICovCitzdGF0aWMgdWludDE2X3QgZ3Bv cnRfdG9faHBvcnQodWludDE2X3QgZ3BvcnQpCit7CisgICAgcmV0dXJuIChncG9ydCAtIGdmeF9p bmZvLmd1ZXN0X3Bpb19iYXNlKSArIGdmeF9pbmZvLmhvc3RfcGlvX2Jhc2U7Cit9CisKKy8qIFJl YWQgaG9zdCBQSU8gcG9ydCAqLworc3RhdGljIHVpbnQzMl90IGF0aV9od19pbih1aW50MTZfdCBo cG9ydCkKK3sKKyAgICB1bnNpZ25lZCB2YWw7CisKKyAgICBpb3BsKDMpOworICAgIGFzbSB2b2xh dGlsZSAoImluICUxLCUwIjoiPWEiKHZhbCk6Ik5kIihocG9ydCkpOworICAgIGlvcGwoMCk7CisK KyAgICByZXR1cm4gdmFsOworfQorCisvKiBXcml0ZSBkYXRhIHRvIGhvc3QgUElPICovCitzdGF0 aWMgdm9pZCBhdGlfaHdfb3V0KHVpbnQxNl90IGhwb3J0LCB1aW50MzJfdCBkYXRhKQoreworICAg IGlvcGwoMyk7CisgICAgYXNtIHZvbGF0aWxlICgib3V0ICUxLCAlMCI6OiJOZCIoaHBvcnQpLCJh IihkYXRhKSk7CisgICAgaW9wbCgwKTsKK30KKworc3RhdGljIHVpbnQzMl90IGF0aV9pb19yZWdz X3JlYWQodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyKQoreworICAgIHVpbnQzMl90IHZhbDsK KworICAgIHZhbCA9IGF0aV9od19pbihncG9ydF90b19ocG9ydChhZGRyKSk7CisKKyAgICAvKiB0 d2VhayB0aGUgdmFsdWUgaWYgVkJJT1MgaXMgcmVhZGluZyBNTUlPIEJBUjEgYW5kIEJBUjIgKi8K KyAgICBpZiAoIGFkZHIgPT0gKGdmeF9pbmZvLmd1ZXN0X3Bpb19iYXNlICsgNCkgKQorICAgIHsK KyAgICAgICAgc3dpdGNoICggZ2Z4X2luZm8ucHJlX21taW5kZXhfZGF0YSApCisgICAgICAgIHsK KyAgICAgICAgY2FzZSBBVElfQkFSMV9NTUlOREVYOgorICAgICAgICAgICAgdmFsID0gZ2Z4X2lu Zm8uZ3Vlc3RfbW1pb19iYXNlMSB8ICh2YWwgJiAweDAwMDAwMDBmKTsKKyAgICAgICAgICAgIGJy ZWFrOworICAgICAgICBjYXNlIEFUSV9CQVIyX01NSU5ERVg6CisgICAgICAgICAgICB2YWwgPSBn ZnhfaW5mby5ndWVzdF9tbWlvX2Jhc2UyIHwgKHZhbCAmIDB4MDAwMDAwMGYpOworICAgICAgICAg ICAgYnJlYWs7CisgICAgICAgIGRlZmF1bHQ6CisgICAgICAgICAgICBicmVhazsKKyAgICAgICAg fQorICAgIH0KKworICAgIHJldHVybiB2YWw7Cit9CisKK3N0YXRpYyB2b2lkIGF0aV9pb19yZWdz X3dyaXRlKHZvaWQgKm9wYXF1ZSwgdWludDMyX3QgYWRkciwgdWludDMyX3QgdmFsKQoreworICAg IGF0aV9od19vdXQoZ3BvcnRfdG9faHBvcnQoYWRkciksIHZhbCk7CisKKyAgICAvKiBib29rIGtl ZXBpbmcgKi8KKyAgICBpZiAoIGFkZHIgPT0gZ2Z4X2luZm8uZ3Vlc3RfcGlvX2Jhc2UgKQorICAg ICAgICBnZnhfaW5mby5wcmVfbW1pbmRleF9kYXRhID0gdmFsOworfQorCitzdGF0aWMgdm9pZCBh dGlfZ2Z4X2luaXQoc3RydWN0IHB0X2RldiAqYXNzaWduZWQpCit7CisgICAgUENJRGV2aWNlICpk ZXYgPSAoUENJRGV2aWNlICopJmFzc2lnbmVkLT5kZXY7CisKKyAgICByZWdpc3Rlcl9pb3BvcnRf cmVhZChkZXYtPmlvX3JlZ2lvbnNbQVRJX0JBUjVfSU5ERVhdLmFkZHIsIAorICAgICAgZGV2LT5p b19yZWdpb25zW0FUSV9CQVI1X0lOREVYXS5zaXplLCA0LCBhdGlfaW9fcmVnc19yZWFkLCBhc3Np Z25lZCk7CisKKyAgICByZWdpc3Rlcl9pb3BvcnRfd3JpdGUoZGV2LT5pb19yZWdpb25zW0FUSV9C QVI1X0lOREVYXS5hZGRyLCAKKyAgICAgIGRldi0+aW9fcmVnaW9uc1tBVElfQkFSNV9JTkRFWF0u c2l6ZSwgNCwgYXRpX2lvX3JlZ3Nfd3JpdGUsIGFzc2lnbmVkKTsKKyAgICAgICAgICAgIAorICAg IC8qIGluaXRpYWxpemUgSU8gcmVnaXN0ZXJzICovCisgICAgZ2Z4X2luZm8uZ3Vlc3RfcGlvX2Jh c2UgPSBkZXYtPmlvX3JlZ2lvbnNbQVRJX0JBUjVfSU5ERVhdLmFkZHI7CisgICAgZ2Z4X2luZm8u cGlvX3NpemUgPSBkZXYtPmlvX3JlZ2lvbnNbQVRJX0JBUjVfSU5ERVhdLnNpemU7CisgICAgZ2Z4 X2luZm8uaG9zdF9waW9fYmFzZSA9IGFzc2lnbmVkLT5iYXNlc1tBVElfQkFSNV9JTkRFWF0uYWNj ZXNzLnBpb19iYXNlOworCisgICAgZ2Z4X2luZm8uZ3Vlc3RfbW1pb19iYXNlMSA9IGRldi0+aW9f cmVnaW9uc1tBVElfQkFSMV9JTkRFWF0uYWRkcjsKKyAgICBnZnhfaW5mby5ndWVzdF9tbWlvX2Jh c2UyID0gZGV2LT5pb19yZWdpb25zW0FUSV9CQVIyX0lOREVYXS5hZGRyOworICAgIGdmeF9pbmZv LmluaXRpYWxpemVkID0gMTsKKworICAgIFBUX0xPRygiZ3Vlc3RfcGlvX2JhciA9IDB4JXgsIGhv c3RfcGlvX2JhciA9IDB4JXgsIHBpb19zaXplPTB4JXggIgorICAgICAgICAgICAiZ3Vlc3RfbW1p b19iYXIxPTB4JXgsIGd1ZXN0X21taW9fYmFyMj0weCV4XG4iLCAKKyAgICAgICAgICAgZ2Z4X2lu Zm8uZ3Vlc3RfcGlvX2Jhc2UsIGdmeF9pbmZvLmhvc3RfcGlvX2Jhc2UsIGdmeF9pbmZvLnBpb19z aXplLCAKKyAgICAgICAgICAgZ2Z4X2luZm8uZ3Vlc3RfbW1pb19iYXNlMSwgZ2Z4X2luZm8uZ3Vl c3RfbW1pb19iYXNlMik7Cit9CisKK3N0YXRpYyB1aW50MzJfdCBhdGlfbGVnYWN5X2lvX3JlYWQo dm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyKQoreworICAgIHN0cnVjdCBwdF9kZXYgKmFzc2ln bmVkX2RldmljZSA9IG9wYXF1ZTsKKyAgICBQQ0lEZXZpY2UgKmRldiA9IChQQ0lEZXZpY2UgKikm YXNzaWduZWRfZGV2aWNlLT5kZXY7CisgICAgdWludDMyX3QgdmFsID0gMHhGRjsKKworICAgIHN3 aXRjaCggYWRkciApCisgICAgeworICAgIGNhc2UgMHgzYzM6CisgICAgICAgIHZhbCA9IGRldi0+ aW9fcmVnaW9uc1tBVElfQkFSNV9JTkRFWF0uYWRkciA+PiA4OworICAgICAgICAvKiBJbnRlcmNl cHQgR0ZYIElPIHJlZ2lzdGVycy4gVGhpcyBzdXBwb3NlcyB0byBoYXBwZW4gaW4gCisgICAgICAg ICAqIGF0aV9yZWdpc3Rlcl92Z2FfcmVnaW9ucygpLiBCdXQgd2UgY2Fubm90IGdldCBndWVzdCBw aHlzIElPIEJBUiAKKyAgICAgICAgICogb3ZlciB0aGVyZS4gKi8KKyAgICAgICAgaWYgKCAhZ2Z4 X2luZm8uaW5pdGlhbGl6ZWQgKQorICAgICAgICAgICAgYXRpX2dmeF9pbml0KGFzc2lnbmVkX2Rl dmljZSk7CisgICAgICAgIGJyZWFrOworICAgIGRlZmF1bHQ6CisgICAgICAgIFBUX0xPRygiRVJS T1I6IHBvcnQgMHgleCBJL08gcmVhZCBub3QgaGFuZGxlZFxuIiwgYWRkcik7CisgICAgICAgIGJy ZWFrOworICAgIH0KKworICAgIHJldHVybiB2YWw7Cit9CisKK3N0YXRpYyB2b2lkIGF0aV9sZWdh Y3lfaW9fd3JpdGUodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyLCB1aW50MzJfdCB2YWwpCit7 CisgICAgUFRfTE9HKCJFUlJPUjogcG9ydCAweCV4IEkvTyB3cml0ZSBub3QgaGFuZGxlZFxuIiwg YWRkcik7Cit9CisKK2ludCBhdGlfcmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAq cmVhbF9kZXZpY2UpCit7CisgICAgUENJRGV2aWNlICpkZXYgPSAoUENJRGV2aWNlICopJnJlYWxf ZGV2aWNlLT5kZXY7CisgICAgaW50IHJldCA9IDA7CisKKyAgICAvKiBXZSBuZWVkIHRvIGludGVy Y2VwdCBWQklPUyBhY2Nlc3NlcyB0byBwb3J0IDB4M0MzLCB3aGljaCByZXR1cm5zIAorICAgICAq IGRldmljZSBwb3J0IEkvTyBCQVIuIEZvciB0aGUgcmVzdCBvZiBsZWdhY3kgSS9PIHBvcnRzLCB3 ZSBhbGxvdyBkaXJlY3QKKyAgICAgKiBhY2Nlc3Nlcy4KKyAgICAgKi8KKyAgICByZXQgfD0geGNf ZG9tYWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIDB4M0MwLAorICAgICAgICAg ICAgMHgzQzAsIDB4MywgRFBDSV9BRERfTUFQUElORyk7CisgICAgCisgICAgcmV0IHw9IHhjX2Rv bWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLCAweDNDNCwKKyAgICAgICAgICAg IDB4M0M0LCAweDFDLCBEUENJX0FERF9NQVBQSU5HKTsKKworICAgIHJlZ2lzdGVyX2lvcG9ydF9y ZWFkKDB4M2MzLCAxLCAxLCBhdGlfbGVnYWN5X2lvX3JlYWQsIHJlYWxfZGV2aWNlKTsKKyAgICBy ZWdpc3Rlcl9pb3BvcnRfd3JpdGUoMHgzYzMsIDEsIDEsIGF0aV9sZWdhY3lfaW9fd3JpdGUsIHJl YWxfZGV2aWNlKTsKKworICAgIC8qIGluaXRpYWxpemVkIG9uIHRoZSBmaXJzdCBwb3J0IDB4M0Mz IGFjY2VzcyBpbiBhdGlfZ2Z4X2luaXQgKi8KKyAgICBnZnhfaW5mby5pbml0aWFsaXplZCA9IDA7 CisKKyAgICByZXR1cm4gcmV0OworfQorCitpbnQgYXRpX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMo c3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpCit7CisgICAgaW50IHJldCA9IDA7CisKKyAgICBy ZXQgfD0geGNfZG9tYWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIDB4M0MwLAor ICAgICAgICAgICAgMHgzQzAsIDB4MywgRFBDSV9SRU1PVkVfTUFQUElORyk7CisgICAgCisgICAg cmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLCAweDNDNCwK KyAgICAgICAgICAgIDB4M0M0LCAweDFDLCBEUENJX1JFTU9WRV9NQVBQSU5HKTsKKworICAgIGdm eF9pbmZvLmluaXRpYWxpemVkID0gMDsKKworICAgIHJldHVybiByZXQ7Cit9CisKKy8qKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKiovCisvKiAgQ29kZSBmb3IgSW50ZWwgSUdEIFBhc3N0 aHJ1ICAqLworLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KIAogc3RhdGljIHVp bnQzMl90IGlnZF9ndWVzdF9vcHJlZ2lvbiA9IDA7CiAKQEAgLTE3Myw2ICszNzUsNzcgQEAgcmVh ZF9kZWZhdWx0OgogICAgcmV0dXJuIHBjaV9kZWZhdWx0X3JlYWRfY29uZmlnKHBjaV9kZXYsIGNv bmZpZ19hZGRyLCBsZW4pOwogfQogCitpbnQgaWdkX3JlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVj dCBwdF9kZXYgKnJlYWxfZGV2aWNlKQoreworICAgIHUzMiB2ZW5kb3JfaWQsIGlnZF9vcHJlZ2lv bjsKKyAgICBpbnQgcmV0ID0gMDsKKyAgICAKKyAgICAvKiBsZWdhY3kgSS9PIHBvcnRzIDB4M0Mw IC0tIDB4M0UwICovCisgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5k bGUsIGRvbWlkLCAweDNDMCwKKyAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJX0FERF9NQVBQ SU5HKTsKKworICAgIC8qIDE6MSBtYXAgQVNMIFN0b3JhZ2UgcmVnaXN0ZXIgdmFsdWUgKi8KKyAg ICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNlLT5wY2lfZGV2LCBQQ0lf VkVORE9SX0lELCAyKTsKKyAgICBpZ2Rfb3ByZWdpb24gPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxf ZGV2aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJT04sIDQpOworICAgIGlmICggKHZlbmRv cl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2Rfb3ByZWdpb24gKQorICAgIHsKKyAg ICAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAor ICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NISUZULAorICAgICAgICAg ICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NISUZULAorICAgICAgICAgICAgICAgIDIs CisgICAgICAgICAgICAgICAgRFBDSV9BRERfTUFQUElORyk7CisgICAgICAgIFBUX0xPRygicmVn aXN0ZXJfdmdhOiBpZ2Rfb3ByZWdpb24gPSAleFxuIiwgaWdkX29wcmVnaW9uKTsKKyAgICB9CisK KyAgICByZXR1cm4gcmV0OworfQorCitpbnQgaWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3Ry dWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpCit7CisgICAgdTMyIHZlbmRvcl9pZCwgaWdkX29wcmVn aW9uOworICAgIGludCByZXQgPSAwOworCisgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFw cGluZyh4Y19oYW5kbGUsIGRvbWlkLCAweDNDMCwKKyAgICAgICAgICAgIDB4M0MwLCAweDIwLCBE UENJX1JFTU9WRV9NQVBQSU5HKTsKKworICAgIHZlbmRvcl9pZCA9IHB0X3BjaV9ob3N0X3JlYWQo cmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9WRU5ET1JfSUQsIDIpOworICAgIGlnZF9vcHJlZ2lv biA9IHB0X3BjaV9ob3N0X3JlYWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9JTlRFTF9PUFJF R0lPTiwgNCk7CisgICAgaWYgKCAodmVuZG9yX2lkID09IFBDSV9WRU5ET1JfSURfSU5URUwpICYm IGlnZF9vcHJlZ2lvbiApCisgICAgeworICAgICAgICByZXQgfD0geGNfZG9tYWluX21lbW9yeV9t YXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsCisgICAgICAgICAgICAgICAgaWdkX29wcmVnaW9uID4+ IFhDX1BBR0VfU0hJRlQsCisgICAgICAgICAgICAgICAgaWdkX29wcmVnaW9uID4+IFhDX1BBR0Vf U0hJRlQsCisgICAgICAgICAgICAgICAgMiwKKyAgICAgICAgICAgICAgICBEUENJX1JFTU9WRV9N QVBQSU5HKTsKKyAgICB9CisKKyAgICByZXR1cm4gcmV0OworfQorLyoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKi8KKy8qIEdlbmVyaWMgQ29kZSBmb3IgR0ZYIFBhc3N0aHJ1ICovCisv KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworLyogVGhpcyBmdW5jdGlvbiBkZWNp ZGVzIHdoZXRoZXIgSS9PIHBvcnQgbWFwIHNob3VsZCBiZSBza2lwcGVkICovCitpbnQgdmdhX3Nr aXBfaW9wb3J0X21hcChQQ0lEZXZpY2UgKmQpCit7CisgICAgc3RydWN0IHB0X2RldiAqZGV2ID0g KHN0cnVjdCBwdF9kZXYgKilkOworICAgIGludCBza2lwID0gMDsKKworICAgIGlmICggIWdmeF9w YXNzdGhydSB8fCBkZXYtPnBjaV9kZXYtPmRldmljZV9jbGFzcyAhPSAweDAzMDAgKQorICAgICAg ICByZXR1cm4gMDsKKworICAgIHN3aXRjaCggZGV2LT5wY2lfZGV2LT52ZW5kb3JfaWQgKSAKKyAg ICB7CisgICAgY2FzZSBQQ0lfVkVORE9SX0lEX0FUSToKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURf QU1EOgorICAgICAgICBza2lwID0gMTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKyAg ICAgICAgc2tpcCA9IDA7CisgICAgICAgIGJyZWFrOworICAgIH0KKyAgICAgICAgCisgICAgcmV0 dXJuIHNraXA7Cit9CiAvKgogICogcmVnaXN0ZXIgVkdBIHJlc291cmNlcyBmb3IgdGhlIGRvbWFp biB3aXRoIGFzc2lnbmVkIGdmeAogICovCkBAIC0xODQsMTggKzQ1NywzMyBAQCBpbnQgcmVnaXN0 ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqCiAgICAgaWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8 IHJlYWxfZGV2aWNlLT5wY2lfZGV2LT5kZXZpY2VfY2xhc3MgIT0gMHgwMzAwICkKICAgICAgICAg cmV0dXJuIHJldDsKIAorICAgIC8qIGxlZ2FjeSBJL08gcG9ydHMgMHgzQjAgLSAweDNCQyAqLwog ICAgIHJldCB8PSB4Y19kb21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgz QjAsCiAgICAgICAgICAgICAweDNCMCwgMHhDLCBEUENJX0FERF9NQVBQSU5HKTsKIAotICAgIHJl dCB8PSB4Y19kb21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgzQzAsCi0g ICAgICAgICAgICAweDNDMCwgMHgyMCwgRFBDSV9BRERfTUFQUElORyk7Ci0KKyAgICAvKiBsZWdh Y3kgdmlkZW8gTU1JTyByYW5nZSAweEEwMDAwIC0gMHhCRkZGRiAqLwogICAgIHJldCB8PSB4Y19k b21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKICAgICAgICAgICAgIDB4YTAw MDAgPj4gWENfUEFHRV9TSElGVCwKICAgICAgICAgICAgIDB4YTAwMDAgPj4gWENfUEFHRV9TSElG VCwKICAgICAgICAgICAgIDB4MjAsCiAgICAgICAgICAgICBEUENJX0FERF9NQVBQSU5HKTsKIAor ICAgIC8qIE90aGVyIFZHQSByZWdpb25zIGFyZSB2ZW5kb3Igc3BlY2lmaWMgKi8KKyAgICBzd2l0 Y2goIHJlYWxfZGV2aWNlLT5wY2lfZGV2LT52ZW5kb3JfaWQgKSAKKyAgICB7CisgICAgY2FzZSBQ Q0lfVkVORE9SX0lEX0lOVEVMOgorCSAgICByZXQgPSBpZ2RfcmVnaXN0ZXJfdmdhX3JlZ2lvbnMo cmVhbF9kZXZpY2UpOworCSAgICBicmVhazsKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURfQVRJOgor ICAgIGNhc2UgUENJX1ZFTkRPUl9JRF9BTUQ6CisJICAgIHJldCA9IGF0aV9yZWdpc3Rlcl92Z2Ff cmVnaW9ucyhyZWFsX2RldmljZSk7CisJICAgIGJyZWFrOworICAgIGRlZmF1bHQ6CisJICAgIFBU X0xPRygiZ2Z4IGNhcmQgd2Fzbid0IHN1cHBvcnRlZCBieSBYZW4gcGFzc3RocnUhXG4iKTsKKwkg ICAgcmV0ID0gMTsKKwkgICAgYnJlYWs7CisgICAgfQorCiAgICAgaWYgKCByZXQgIT0gMCApCiAg ICAgICAgIFBUX0xPRygiVkdBIHJlZ2lvbiBtYXBwaW5nIGZhaWxlZFxuIik7CiAKQEAgLTIxMywy NiArNTAxLDMxIEBAIGludCB1bnJlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVjdCBwdF9kZXYKICAg ICBpZiAoICFnZnhfcGFzc3RocnUgfHwgcmVhbF9kZXZpY2UtPnBjaV9kZXYtPmRldmljZV9jbGFz cyAhPSAweDAzMDAgKQogICAgICAgICByZXR1cm4gcmV0OwogCisgICAgLyogbGVnYWN5IEkvTyBw b3J0cyAweDNCMCAtIDB4M0JDICovCiAgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGlu Zyh4Y19oYW5kbGUsIGRvbWlkLCAweDNCMCwKICAgICAgICAgICAgIDB4M0IwLCAweEMsIERQQ0lf UkVNT1ZFX01BUFBJTkcpOwogCi0gICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4 Y19oYW5kbGUsIGRvbWlkLCAweDNDMCwKLSAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJX1JF TU9WRV9NQVBQSU5HKTsKLQorICAgIC8qIGxlZ2FjeSB2aWRlbyBNTUlPIHJhbmdlIDB4QTAwMDAg LSAweEJGRkZGICovCiAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19oYW5k bGUsIGRvbWlkLAogICAgICAgICAgICAgMHhhMDAwMCA+PiBYQ19QQUdFX1NISUZULAogICAgICAg ICAgICAgMHhhMDAwMCA+PiBYQ19QQUdFX1NISUZULAogICAgICAgICAgICAgMjAsCiAgICAgICAg ICAgICBEUENJX1JFTU9WRV9NQVBQSU5HKTsKIAotICAgIHZlbmRvcl9pZCA9IHB0X3BjaV9ob3N0 X3JlYWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9WRU5ET1JfSUQsIDIpOwotICAgIGlmICgg KHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2RfZ3Vlc3Rfb3ByZWdpb24g KQorICAgIC8qIE90aGVyIFZHQSByZWdpb25zIGFyZSB2ZW5kb3Igc3BlY2lmaWMgKi8KKyAgICBz d2l0Y2goIHJlYWxfZGV2aWNlLT5wY2lfZGV2LT52ZW5kb3JfaWQgKSAKICAgICB7Ci0gICAgICAg IHJldCB8PSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKLSAgICAg ICAgICAgICAgICBpZ2RfZ3Vlc3Rfb3ByZWdpb24gPj4gWENfUEFHRV9TSElGVCwKLSAgICAgICAg ICAgICAgICBpZ2RfZ3Vlc3Rfb3ByZWdpb24gPj4gWENfUEFHRV9TSElGVCwKLSAgICAgICAgICAg ICAgICAyLAotICAgICAgICAgICAgICAgIERQQ0lfUkVNT1ZFX01BUFBJTkcpOworICAgIGNhc2Ug UENJX1ZFTkRPUl9JRF9JTlRFTDoKKwkgICAgcmV0ID0gaWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lv bnMocmVhbF9kZXZpY2UpOworCSAgICBicmVhazsKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURfQVRJ OgorICAgIGNhc2UgUENJX1ZFTkRPUl9JRF9BTUQ6CisJICAgIHJldCA9IGF0aV91bnJlZ2lzdGVy X3ZnYV9yZWdpb25zKHJlYWxfZGV2aWNlKTsKKwkgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKwkg ICAgUFRfTE9HKCJnZnggY2FyZCB3YXNuJ3Qgc3VwcG9ydGVkIGJ5IFhlbiBwYXNzdGhydSFcbiIp OworCSAgICByZXQgPSAxOworCSAgICBicmVhazsKICAgICB9CiAKICAgICBpZiAoIHJldCAhPSAw ICkK --f46d043c80da97848004d7bf7ed2 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 --f46d043c80da97848004d7bf7ed2-- From xen-users-bounces@lists.xen.org Tue Mar 12 19:43:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 19:43: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 1UFV65-0002gj-RU; Tue, 12 Mar 2013 19:42:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFV63-0002gX-Og for xen-users@lists.xen.org; Tue, 12 Mar 2013 19:42:52 +0000 Received: from [85.158.137.99:55678] by server-3.bemta-3.messagelabs.com id 1A/0A-26934-A358F315; Tue, 12 Mar 2013 19:42:50 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1363117369!18036027!1 X-Originating-IP: [74.125.82.47] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18285 invoked from network); 12 Mar 2013 19:42:49 -0000 Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com) (74.125.82.47) by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 19:42:49 -0000 Received: by mail-wg0-f47.google.com with SMTP id dr13so220673wgb.26 for ; Tue, 12 Mar 2013 12:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=7Lp3zNaSLFnb9vrXaaisL8a88XAxLEYUJyguNp4XEwo=; b=Ix3xKc7xkJHmNEjH58QsEYrcuTUW0Gey6y84Aivx30cp1xjdlDDPH8LY3ZMU3nfsDC zngPpSzIrCkFPPPieHUi8k9b5TnFJ2pwgtKb/xtCFUY5WIbO0ea1iMDa08BBaloXxzlH wmlnWs7OKPeSEs3tx+fgzfkTFkuT6Npd7Jp1FuMvpDTcVkyM6XTAfKc8tQPZFo+CvfAY 0kGGnHk0YCeJ3GI9NC0isYE0WqJreymKbS8ItZFXXj6MVAj1jLkG+Lbpq+44rnRHqHXS QmfIH+Q/Zo3F6uJQkGeyHbmy0ZZ8Dh1rCrYS35hzG/r9q3VO4I0ilybMcgOwJRXJ0lmu 6PIQ== X-Received: by 10.180.73.238 with SMTP id o14mr22207079wiv.32.1363117369413; Tue, 12 Mar 2013 12:42:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 12 Mar 2013 12:42:28 -0700 (PDT) In-Reply-To: <513F5C1E.7010407@cam.ac.uk> References: <513F5C1E.7010407@cam.ac.uk> From: Matthias Date: Tue, 12 Mar 2013 20:42:28 +0100 Message-ID: To: Matthew Dean Content-Type: multipart/mixed; boundary=f46d043c80da97848004d7bf7ed2 Cc: "xen-users@lists.xen.org" , greg@wind.enjellic.com Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@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 --f46d043c80da97848004d7bf7ed2 Content-Type: text/plain; charset=ISO-8859-1 Hi, to fix the atikmeq.sys bug, you can try two things: 1) Use upstream qemu. For this, just add: device_model_version = 'qemu-xen' device_model_override = '/usr/lib/xen/bin/qemu-system-i386' to your domU config file. Note that there is currently a bug that the domU won't start when duing vga passthrough with more then 4GB memory assigned, so better use some less.. 2) If you want to have more then 4GB memory, you can patch the traditional qemu. This is a bit more complicated cause the qemu stuff is download through the build and can't be patched right away. Also stopping in mid build, patching and continuing at least for me caused some problems, so doing a full build, patch, cleanup and build again is the safer route: git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging cd xen-unstable-staging ./configure --disable-stubdom make -j12 world git apply --check /path/to/xen-unstable-atipassthrough.patch git apply /path/to/xen-unstable-atipassthrough.patch make -j12 clean make -j12 world Now do your usual install.. some use the standard, i prefer creating a debball.. Some Notes: - I use the staging branch from xen-unstable, but this is not exactly necessary for the patch, you can use master just as fine - the j12 is for multithreading and you should use double your core number.. since i got 6 cpu cores, it's 12 for me.. - the patch i have attached is originally from Greg (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), so credit goes to him, i only cleaned it up for xen-unstable. Also, the patch itself was for providing primary passthrough with ATI cards, but i found it fixing my ati 0x116 bluescreen.. - due to an insufficiancy in the patch, stubdom would not build correctly, so you have to disable it Please report back if the patch fixes your bluescreen for more argumentation to bring this patch upstream.. :) (@Greg: that's why i cc'ed you. hope you don't mind the noise) Hope it helps! --f46d043c80da97848004d7bf7ed2 Content-Type: application/octet-stream; name="xen-unstable-atipassthrough.patch" Content-Disposition: attachment; filename="xen-unstable-atipassthrough.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_he7gshdq0 ZGlmZiAtdXJOcCBhL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91 Z2guYyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91Z2guYwot LS0gYS90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcGFzcy10aHJvdWdoLmMJVGh1 IFNlcCAgNiAxMTowNTozMCAyMDEyCisrKyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRp ci9ody9wYXNzLXRocm91Z2guYwlTYXQgTm92IDI0IDA4OjI3OjA3IDIwMTIKQEAgLTE0MzgsOSAr MTQzOCwxNyBAQCBzdGF0aWMgdm9pZCBwdF9pb3BvcnRfbWFwKFBDSURldmljZSAqZCwgCiAgICAg aWYgKGVfcGh5cyAhPSAtMSkKICAgICB7CiAgICAgICAgIC8qIENyZWF0ZSBuZXcgbWFwcGluZyAq LwotICAgICAgICByZXQgPSB4Y19kb21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21p ZCwgZV9waHlzLAotICAgICAgICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ld LmFjY2Vzcy5waW9fYmFzZSwgZV9zaXplLAotICAgICAgICAgICAgICAgICAgICBEUENJX0FERF9N QVBQSU5HKTsKKyAgICAgICAgaWYgKCB2Z2Ffc2tpcF9pb3BvcnRfbWFwKGQpICkgCisgICAgICAg IHsKKyAgICAgICAgICAgIGFzc2lnbmVkX2RldmljZS0+YmFzZXNbaV0uZV9waHlzYmFzZSA9IC0x OworICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgeworICAgICAgICAgICAgcmV0ID0g eGNfZG9tYWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIGVfcGh5cywKKyAgICAg ICAgICAgICAgICAgICBhc3NpZ25lZF9kZXZpY2UtPmJhc2VzW2ldLmFjY2Vzcy5waW9fYmFzZSwg ZV9zaXplLAorICAgICAgICAgICAgICAgICAgIERQQ0lfQUREX01BUFBJTkcpOworICAgICAgICB9 CisKICAgICAgICAgaWYgKCByZXQgIT0gMCApCiAgICAgICAgIHsKICAgICAgICAgICAgIFBUX0xP RygiRXJyb3I6IGNyZWF0ZSBuZXcgbWFwcGluZyBmYWlsZWQhXG4iKTsKZGlmZiAtdXJOcCBhL3Rv b2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91Z2guaCBiL3Rvb2xzL3Fl bXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91Z2guaAotLS0gYi90b29scy9xZW11 LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcGFzcy10aHJvdWdoLmgJVGh1IFNlcCAgNiAxMTowNToz MCAyMDEyCisrKyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wYXNzLXRocm91 Z2guaAlTYXQgTm92IDI0IDA4OjI3OjA3IDIwMTIKQEAgLTQxOSw2ICs0MTksMTEgQEAgaW50IHB0 X3BjaV9ob3N0X3dyaXRlKHN0cnVjdCBwY2lfZGV2ICpwYwogdm9pZCBpbnRlbF9wY2hfaW5pdChQ Q0lCdXMgKmJ1cyk7CiBpbnQgcmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVh bF9kZXZpY2UpOwogaW50IHVucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVh bF9kZXZpY2UpOworaW50IHZnYV9za2lwX2lvcG9ydF9tYXAoUENJRGV2aWNlICpkKTsKK2ludCBp Z2RfcmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpOworaW50 IGlnZF91bnJlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2aWNlKTsK K2ludCBhdGlfcmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2Up OworaW50IGF0aV91bnJlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVjdCBwdF9kZXYgKnJlYWxfZGV2 aWNlKTsKIGludCBzZXR1cF92Z2FfcHQoc3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpOwogUENJ QnVzICppbnRlbF9wY2lfYnJpZGdlX2luaXQoUENJQnVzICpidXMsIGludCBkZXZmbiwgdWludDE2 X3QgdmlkLAogICAgICAgICAgICB1aW50MTZfdCBkaWQsIGNvbnN0IGNoYXIgKm5hbWUsIHVpbnQx Nl90IHJldmlzaW9uKTsKZGlmZiAtdXJOcCBhL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRp ci9ody9wY2kuaCBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wY2kuaAotLS0g YS90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcGNpLmgJVGh1IFNlcCAgNiAxMTow NTozMCAyMDEyCisrKyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wY2kuaAlT YXQgTm92IDI0IDA4OjI3OjA3IDIwMTIKQEAgLTU0LDYgKzU0LDggQEAgZXh0ZXJuIHRhcmdldF9w aHlzX2FkZHJfdCBwY2lfbWVtX2Jhc2U7CiAKICNkZWZpbmUgUENJX1ZFTkRPUl9JRF9DSVJSVVMg ICAgICAgICAgICAgMHgxMDEzCiAKKyNkZWZpbmUgUENJX1ZFTkRPUl9JRF9BVEkgICAgICAgICAg ICAgICAgMHgxMDAyCisKICNkZWZpbmUgUENJX1ZFTkRPUl9JRF9JQk0gICAgICAgICAgICAgICAg MHgxMDE0CiAjZGVmaW5lIFBDSV9ERVZJQ0VfSURfSUJNX09QRU5QSUMyICAgICAgIDB4ZmZmZgog CmRpZmYgLXVyTnAgYS90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIvaHcvcHQtZ3JhcGhp Y3MuYyBiL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wdC1ncmFwaGljcy5jCi0t LSBhL3Rvb2xzL3FlbXUteGVuLXRyYWRpdGlvbmFsLWRpci9ody9wdC1ncmFwaGljcy5jCVRodSBT ZXAgIDYgMTE6MDU6MzAgMjAxMgorKysgYi90b29scy9xZW11LXhlbi10cmFkaXRpb25hbC1kaXIv aHcvcHQtZ3JhcGhpY3MuYwlTYXQgTm92IDI0IDA4OjI4OjEwIDIwMTIKQEAgLTgsMTAgKzgsMjEy IEBACiAKICNpbmNsdWRlIDx1bmlzdGQuaD4KICNpbmNsdWRlIDxzeXMvaW9jdGwuaD4KKyNpbmNs dWRlIDxzeXMvaW8uaD4KICNpbmNsdWRlIDxhc3NlcnQuaD4KIAogZXh0ZXJuIGludCBnZnhfcGFz c3RocnU7CiBleHRlcm4gaW50IGlnZF9wYXNzdGhydTsKKy8qKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKiovCisvKiAgIENvZGUgZm9yIEFUSSBHRlggUGFzc3RocnUgICAqLworLyoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KKy8qIEFUSSBWQklPUyBXb3JraW5nIE1lY2hh bmlzbSAKKyAqCisgKiBHZW5lcmFsbHkgdGhlcmUgYXJlIHRocmVlIG1lbW9yeSByZXNvdXJjZXMg KHR3byBNTUlPIGFuZCBvbmUgUElPKSAKKyAqIGFzc29jaWF0ZWQgd2l0aCBtb2Rlcm4gQVRJIGdm eC4gVkJJT1MgdXNlcyBzcGVjaWFsIHRyaWNrcyB0byBmaWd1cmUgb3V0IAorICogQkFScywgaW5z dGVhZCBvZiB1c2luZyByZWd1bGFyIFBDSSBjb25maWcgc3BhY2UgcmVhZC4KKyAqCisgKiAgKDEp IFZCSU9TIHJlbGllcyBvbiBJL08gcG9ydCAweDNDMyB0byByZXRyaWV2ZSBQSU8gQkFSIAorICog ICgyKSBWQklPUyBtYWludGFpbnMgYSBzaGFkb3cgY29weSBvZiBQQ0kgY29uZmlndXJlIHNwYWNl LiBJdCByZXRyaWVzIHRoZSAKKyAqICAgICAgTU1JTyBCQVJzIGZyb20gdGhpcyBzaGFkb3cgY29w eSB2aWEgc2VuZGluZyBJL08gcmVxdWVzdHMgdG8gZmlyc3QgdHdvIAorICogICAgICByZWdpc3Rl cnMgb2YgUElPIChNTUlOREVYIGFuZCBNTURBVEEpLiBUaGUgd29ya2Zsb3cgaXMgbGlrZSB0aGlz OiAKKyAqICAgICAgTU1JTkRFWCAocmVnaXN0ZXIgMCkgaXMgd3JpdHRlbiB3aXRoIGFuIGluZGV4 IHZhbHVlLCBzcGVjaWZ5aW5nIHRoZSAKKyAqICAgICAgcmVnaXN0ZXIgVkJJT1Mgd2FudGluZyB0 byBhY2Nlc3MuIFRoZW4gdGhlIHNoYWRvd2VkIGRhdGEgY2FuIGJlIAorICogICAgICByZWFkL3dy aXR0ZW4gZnJvbSBNTURBVEEgKHJlZ2lzdGVyIDEpLiBGb3IgdHdvIE1NSU8gQkFScywgdGhlIGlu ZGV4IAorICogICAgICB2YWx1ZXMgYXJlIDB4NDAxMCBhbmQgMHg0MDE0IHJlc3BlY3RpdmVseS4g CisgKgorICovCisKKyNkZWZpbmUgQVRJX0JBUjFfSU5ERVggICAgICAgIDAgIC8vTU1JTyBCQVIx CisjZGVmaW5lIEFUSV9CQVIyX0lOREVYICAgICAgICAxICAvL01NSU8gQkFSMgorI2RlZmluZSBB VElfQkFSNV9JTkRFWCAgICAgICAgNCAgLy9QSU8gQkFSID09IEJBUjUKKworI2RlZmluZSBBVElf QkFSMV9NTUlOREVYICAgICAgMHg0MDEwICAvL2RhdGEgd3JpdHRlbiB0byBNTUlOREVYIGZvciBN TUlPIEJBUjEKKyNkZWZpbmUgQVRJX0JBUjJfTU1JTkRFWCAgICAgIDB4NDAxNCAgLy9kYXRhIHdy aXR0ZW4gdG8gTU1JTkRFWCBGT1IgTU1JTyBCQVIyCisKK3N0cnVjdCBhdGlfZ2Z4X2luZm8gewor ICAgIGludCBpbml0aWFsaXplZDsgICAgICAgICAgICAvKiBpbml0aWFsaXplZCBhbHJlYWR5PyAq LworCisgICAgLyogUElPICovCisgICAgdWludDMyX3QgaG9zdF9waW9fYmFzZTsgICAgIC8qIGhv c3QgYmFzZSBhZGRyIG9mIFBJTyAqLworICAgIHVpbnQzMl90IGd1ZXN0X3Bpb19iYXNlOyAgICAv KiBndWVzdCBiYXNlIGFkZHIgb2YgUElPICovCisgICAgdWludDMyX3QgcGlvX3NpemU7ICAgICAg ICAgIC8qIFBJTyBzaXplICovCisKKyAgICAvKiBNTUlPICovCisgICAgdWludDMyX3QgZ3Vlc3Rf bW1pb19iYXNlMTsgIC8qIGd1ZXN0IGJhc2UgYWRkciBvZiBNTUlPIDEgKi8KKyAgICB1aW50MzJf dCBndWVzdF9tbWlvX2Jhc2UyOyAgLyogZ3Vlc3QgYmFzZSBhZGRyIG9mIE1NSU8gMiAqLworCisg ICAgLyogUElPIE1NSU5ERVggYWNjZXNzIHJlY29yZGluZyAqLworICAgIHVpbnQzMl90IHByZV9t bWluZGV4X2RhdGE7ICAgICAgIC8qIHByZXZpb3VzIGRhdGEgd3JpdHRlbiB0byBNTUlOREVYICov Cit9OworCitzdGF0aWMgc3RydWN0IGF0aV9nZnhfaW5mbyBnZnhfaW5mbzsKKworLyogQ29udmVy dCBndWVzdCBQSU8gcG9ydCB0byBob3N0IFBJTyBwb3J0ICovCitzdGF0aWMgdWludDE2X3QgZ3Bv cnRfdG9faHBvcnQodWludDE2X3QgZ3BvcnQpCit7CisgICAgcmV0dXJuIChncG9ydCAtIGdmeF9p bmZvLmd1ZXN0X3Bpb19iYXNlKSArIGdmeF9pbmZvLmhvc3RfcGlvX2Jhc2U7Cit9CisKKy8qIFJl YWQgaG9zdCBQSU8gcG9ydCAqLworc3RhdGljIHVpbnQzMl90IGF0aV9od19pbih1aW50MTZfdCBo cG9ydCkKK3sKKyAgICB1bnNpZ25lZCB2YWw7CisKKyAgICBpb3BsKDMpOworICAgIGFzbSB2b2xh dGlsZSAoImluICUxLCUwIjoiPWEiKHZhbCk6Ik5kIihocG9ydCkpOworICAgIGlvcGwoMCk7CisK KyAgICByZXR1cm4gdmFsOworfQorCisvKiBXcml0ZSBkYXRhIHRvIGhvc3QgUElPICovCitzdGF0 aWMgdm9pZCBhdGlfaHdfb3V0KHVpbnQxNl90IGhwb3J0LCB1aW50MzJfdCBkYXRhKQoreworICAg IGlvcGwoMyk7CisgICAgYXNtIHZvbGF0aWxlICgib3V0ICUxLCAlMCI6OiJOZCIoaHBvcnQpLCJh IihkYXRhKSk7CisgICAgaW9wbCgwKTsKK30KKworc3RhdGljIHVpbnQzMl90IGF0aV9pb19yZWdz X3JlYWQodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyKQoreworICAgIHVpbnQzMl90IHZhbDsK KworICAgIHZhbCA9IGF0aV9od19pbihncG9ydF90b19ocG9ydChhZGRyKSk7CisKKyAgICAvKiB0 d2VhayB0aGUgdmFsdWUgaWYgVkJJT1MgaXMgcmVhZGluZyBNTUlPIEJBUjEgYW5kIEJBUjIgKi8K KyAgICBpZiAoIGFkZHIgPT0gKGdmeF9pbmZvLmd1ZXN0X3Bpb19iYXNlICsgNCkgKQorICAgIHsK KyAgICAgICAgc3dpdGNoICggZ2Z4X2luZm8ucHJlX21taW5kZXhfZGF0YSApCisgICAgICAgIHsK KyAgICAgICAgY2FzZSBBVElfQkFSMV9NTUlOREVYOgorICAgICAgICAgICAgdmFsID0gZ2Z4X2lu Zm8uZ3Vlc3RfbW1pb19iYXNlMSB8ICh2YWwgJiAweDAwMDAwMDBmKTsKKyAgICAgICAgICAgIGJy ZWFrOworICAgICAgICBjYXNlIEFUSV9CQVIyX01NSU5ERVg6CisgICAgICAgICAgICB2YWwgPSBn ZnhfaW5mby5ndWVzdF9tbWlvX2Jhc2UyIHwgKHZhbCAmIDB4MDAwMDAwMGYpOworICAgICAgICAg ICAgYnJlYWs7CisgICAgICAgIGRlZmF1bHQ6CisgICAgICAgICAgICBicmVhazsKKyAgICAgICAg fQorICAgIH0KKworICAgIHJldHVybiB2YWw7Cit9CisKK3N0YXRpYyB2b2lkIGF0aV9pb19yZWdz X3dyaXRlKHZvaWQgKm9wYXF1ZSwgdWludDMyX3QgYWRkciwgdWludDMyX3QgdmFsKQoreworICAg IGF0aV9od19vdXQoZ3BvcnRfdG9faHBvcnQoYWRkciksIHZhbCk7CisKKyAgICAvKiBib29rIGtl ZXBpbmcgKi8KKyAgICBpZiAoIGFkZHIgPT0gZ2Z4X2luZm8uZ3Vlc3RfcGlvX2Jhc2UgKQorICAg ICAgICBnZnhfaW5mby5wcmVfbW1pbmRleF9kYXRhID0gdmFsOworfQorCitzdGF0aWMgdm9pZCBh dGlfZ2Z4X2luaXQoc3RydWN0IHB0X2RldiAqYXNzaWduZWQpCit7CisgICAgUENJRGV2aWNlICpk ZXYgPSAoUENJRGV2aWNlICopJmFzc2lnbmVkLT5kZXY7CisKKyAgICByZWdpc3Rlcl9pb3BvcnRf cmVhZChkZXYtPmlvX3JlZ2lvbnNbQVRJX0JBUjVfSU5ERVhdLmFkZHIsIAorICAgICAgZGV2LT5p b19yZWdpb25zW0FUSV9CQVI1X0lOREVYXS5zaXplLCA0LCBhdGlfaW9fcmVnc19yZWFkLCBhc3Np Z25lZCk7CisKKyAgICByZWdpc3Rlcl9pb3BvcnRfd3JpdGUoZGV2LT5pb19yZWdpb25zW0FUSV9C QVI1X0lOREVYXS5hZGRyLCAKKyAgICAgIGRldi0+aW9fcmVnaW9uc1tBVElfQkFSNV9JTkRFWF0u c2l6ZSwgNCwgYXRpX2lvX3JlZ3Nfd3JpdGUsIGFzc2lnbmVkKTsKKyAgICAgICAgICAgIAorICAg IC8qIGluaXRpYWxpemUgSU8gcmVnaXN0ZXJzICovCisgICAgZ2Z4X2luZm8uZ3Vlc3RfcGlvX2Jh c2UgPSBkZXYtPmlvX3JlZ2lvbnNbQVRJX0JBUjVfSU5ERVhdLmFkZHI7CisgICAgZ2Z4X2luZm8u cGlvX3NpemUgPSBkZXYtPmlvX3JlZ2lvbnNbQVRJX0JBUjVfSU5ERVhdLnNpemU7CisgICAgZ2Z4 X2luZm8uaG9zdF9waW9fYmFzZSA9IGFzc2lnbmVkLT5iYXNlc1tBVElfQkFSNV9JTkRFWF0uYWNj ZXNzLnBpb19iYXNlOworCisgICAgZ2Z4X2luZm8uZ3Vlc3RfbW1pb19iYXNlMSA9IGRldi0+aW9f cmVnaW9uc1tBVElfQkFSMV9JTkRFWF0uYWRkcjsKKyAgICBnZnhfaW5mby5ndWVzdF9tbWlvX2Jh c2UyID0gZGV2LT5pb19yZWdpb25zW0FUSV9CQVIyX0lOREVYXS5hZGRyOworICAgIGdmeF9pbmZv LmluaXRpYWxpemVkID0gMTsKKworICAgIFBUX0xPRygiZ3Vlc3RfcGlvX2JhciA9IDB4JXgsIGhv c3RfcGlvX2JhciA9IDB4JXgsIHBpb19zaXplPTB4JXggIgorICAgICAgICAgICAiZ3Vlc3RfbW1p b19iYXIxPTB4JXgsIGd1ZXN0X21taW9fYmFyMj0weCV4XG4iLCAKKyAgICAgICAgICAgZ2Z4X2lu Zm8uZ3Vlc3RfcGlvX2Jhc2UsIGdmeF9pbmZvLmhvc3RfcGlvX2Jhc2UsIGdmeF9pbmZvLnBpb19z aXplLCAKKyAgICAgICAgICAgZ2Z4X2luZm8uZ3Vlc3RfbW1pb19iYXNlMSwgZ2Z4X2luZm8uZ3Vl c3RfbW1pb19iYXNlMik7Cit9CisKK3N0YXRpYyB1aW50MzJfdCBhdGlfbGVnYWN5X2lvX3JlYWQo dm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyKQoreworICAgIHN0cnVjdCBwdF9kZXYgKmFzc2ln bmVkX2RldmljZSA9IG9wYXF1ZTsKKyAgICBQQ0lEZXZpY2UgKmRldiA9IChQQ0lEZXZpY2UgKikm YXNzaWduZWRfZGV2aWNlLT5kZXY7CisgICAgdWludDMyX3QgdmFsID0gMHhGRjsKKworICAgIHN3 aXRjaCggYWRkciApCisgICAgeworICAgIGNhc2UgMHgzYzM6CisgICAgICAgIHZhbCA9IGRldi0+ aW9fcmVnaW9uc1tBVElfQkFSNV9JTkRFWF0uYWRkciA+PiA4OworICAgICAgICAvKiBJbnRlcmNl cHQgR0ZYIElPIHJlZ2lzdGVycy4gVGhpcyBzdXBwb3NlcyB0byBoYXBwZW4gaW4gCisgICAgICAg ICAqIGF0aV9yZWdpc3Rlcl92Z2FfcmVnaW9ucygpLiBCdXQgd2UgY2Fubm90IGdldCBndWVzdCBw aHlzIElPIEJBUiAKKyAgICAgICAgICogb3ZlciB0aGVyZS4gKi8KKyAgICAgICAgaWYgKCAhZ2Z4 X2luZm8uaW5pdGlhbGl6ZWQgKQorICAgICAgICAgICAgYXRpX2dmeF9pbml0KGFzc2lnbmVkX2Rl dmljZSk7CisgICAgICAgIGJyZWFrOworICAgIGRlZmF1bHQ6CisgICAgICAgIFBUX0xPRygiRVJS T1I6IHBvcnQgMHgleCBJL08gcmVhZCBub3QgaGFuZGxlZFxuIiwgYWRkcik7CisgICAgICAgIGJy ZWFrOworICAgIH0KKworICAgIHJldHVybiB2YWw7Cit9CisKK3N0YXRpYyB2b2lkIGF0aV9sZWdh Y3lfaW9fd3JpdGUodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyLCB1aW50MzJfdCB2YWwpCit7 CisgICAgUFRfTE9HKCJFUlJPUjogcG9ydCAweCV4IEkvTyB3cml0ZSBub3QgaGFuZGxlZFxuIiwg YWRkcik7Cit9CisKK2ludCBhdGlfcmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAq cmVhbF9kZXZpY2UpCit7CisgICAgUENJRGV2aWNlICpkZXYgPSAoUENJRGV2aWNlICopJnJlYWxf ZGV2aWNlLT5kZXY7CisgICAgaW50IHJldCA9IDA7CisKKyAgICAvKiBXZSBuZWVkIHRvIGludGVy Y2VwdCBWQklPUyBhY2Nlc3NlcyB0byBwb3J0IDB4M0MzLCB3aGljaCByZXR1cm5zIAorICAgICAq IGRldmljZSBwb3J0IEkvTyBCQVIuIEZvciB0aGUgcmVzdCBvZiBsZWdhY3kgSS9PIHBvcnRzLCB3 ZSBhbGxvdyBkaXJlY3QKKyAgICAgKiBhY2Nlc3Nlcy4KKyAgICAgKi8KKyAgICByZXQgfD0geGNf ZG9tYWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIDB4M0MwLAorICAgICAgICAg ICAgMHgzQzAsIDB4MywgRFBDSV9BRERfTUFQUElORyk7CisgICAgCisgICAgcmV0IHw9IHhjX2Rv bWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLCAweDNDNCwKKyAgICAgICAgICAg IDB4M0M0LCAweDFDLCBEUENJX0FERF9NQVBQSU5HKTsKKworICAgIHJlZ2lzdGVyX2lvcG9ydF9y ZWFkKDB4M2MzLCAxLCAxLCBhdGlfbGVnYWN5X2lvX3JlYWQsIHJlYWxfZGV2aWNlKTsKKyAgICBy ZWdpc3Rlcl9pb3BvcnRfd3JpdGUoMHgzYzMsIDEsIDEsIGF0aV9sZWdhY3lfaW9fd3JpdGUsIHJl YWxfZGV2aWNlKTsKKworICAgIC8qIGluaXRpYWxpemVkIG9uIHRoZSBmaXJzdCBwb3J0IDB4M0Mz IGFjY2VzcyBpbiBhdGlfZ2Z4X2luaXQgKi8KKyAgICBnZnhfaW5mby5pbml0aWFsaXplZCA9IDA7 CisKKyAgICByZXR1cm4gcmV0OworfQorCitpbnQgYXRpX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMo c3RydWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpCit7CisgICAgaW50IHJldCA9IDA7CisKKyAgICBy ZXQgfD0geGNfZG9tYWluX2lvcG9ydF9tYXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsIDB4M0MwLAor ICAgICAgICAgICAgMHgzQzAsIDB4MywgRFBDSV9SRU1PVkVfTUFQUElORyk7CisgICAgCisgICAg cmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLCAweDNDNCwK KyAgICAgICAgICAgIDB4M0M0LCAweDFDLCBEUENJX1JFTU9WRV9NQVBQSU5HKTsKKworICAgIGdm eF9pbmZvLmluaXRpYWxpemVkID0gMDsKKworICAgIHJldHVybiByZXQ7Cit9CisKKy8qKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKiovCisvKiAgQ29kZSBmb3IgSW50ZWwgSUdEIFBhc3N0 aHJ1ICAqLworLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KIAogc3RhdGljIHVp bnQzMl90IGlnZF9ndWVzdF9vcHJlZ2lvbiA9IDA7CiAKQEAgLTE3Myw2ICszNzUsNzcgQEAgcmVh ZF9kZWZhdWx0OgogICAgcmV0dXJuIHBjaV9kZWZhdWx0X3JlYWRfY29uZmlnKHBjaV9kZXYsIGNv bmZpZ19hZGRyLCBsZW4pOwogfQogCitpbnQgaWdkX3JlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVj dCBwdF9kZXYgKnJlYWxfZGV2aWNlKQoreworICAgIHUzMiB2ZW5kb3JfaWQsIGlnZF9vcHJlZ2lv bjsKKyAgICBpbnQgcmV0ID0gMDsKKyAgICAKKyAgICAvKiBsZWdhY3kgSS9PIHBvcnRzIDB4M0Mw IC0tIDB4M0UwICovCisgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4Y19oYW5k bGUsIGRvbWlkLCAweDNDMCwKKyAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJX0FERF9NQVBQ SU5HKTsKKworICAgIC8qIDE6MSBtYXAgQVNMIFN0b3JhZ2UgcmVnaXN0ZXIgdmFsdWUgKi8KKyAg ICB2ZW5kb3JfaWQgPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxfZGV2aWNlLT5wY2lfZGV2LCBQQ0lf VkVORE9SX0lELCAyKTsKKyAgICBpZ2Rfb3ByZWdpb24gPSBwdF9wY2lfaG9zdF9yZWFkKHJlYWxf ZGV2aWNlLT5wY2lfZGV2LCBQQ0lfSU5URUxfT1BSRUdJT04sIDQpOworICAgIGlmICggKHZlbmRv cl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2Rfb3ByZWdpb24gKQorICAgIHsKKyAg ICAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19oYW5kbGUsIGRvbWlkLAor ICAgICAgICAgICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NISUZULAorICAgICAgICAg ICAgICAgIGlnZF9vcHJlZ2lvbiA+PiBYQ19QQUdFX1NISUZULAorICAgICAgICAgICAgICAgIDIs CisgICAgICAgICAgICAgICAgRFBDSV9BRERfTUFQUElORyk7CisgICAgICAgIFBUX0xPRygicmVn aXN0ZXJfdmdhOiBpZ2Rfb3ByZWdpb24gPSAleFxuIiwgaWdkX29wcmVnaW9uKTsKKyAgICB9CisK KyAgICByZXR1cm4gcmV0OworfQorCitpbnQgaWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lvbnMoc3Ry dWN0IHB0X2RldiAqcmVhbF9kZXZpY2UpCit7CisgICAgdTMyIHZlbmRvcl9pZCwgaWdkX29wcmVn aW9uOworICAgIGludCByZXQgPSAwOworCisgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFw cGluZyh4Y19oYW5kbGUsIGRvbWlkLCAweDNDMCwKKyAgICAgICAgICAgIDB4M0MwLCAweDIwLCBE UENJX1JFTU9WRV9NQVBQSU5HKTsKKworICAgIHZlbmRvcl9pZCA9IHB0X3BjaV9ob3N0X3JlYWQo cmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9WRU5ET1JfSUQsIDIpOworICAgIGlnZF9vcHJlZ2lv biA9IHB0X3BjaV9ob3N0X3JlYWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9JTlRFTF9PUFJF R0lPTiwgNCk7CisgICAgaWYgKCAodmVuZG9yX2lkID09IFBDSV9WRU5ET1JfSURfSU5URUwpICYm IGlnZF9vcHJlZ2lvbiApCisgICAgeworICAgICAgICByZXQgfD0geGNfZG9tYWluX21lbW9yeV9t YXBwaW5nKHhjX2hhbmRsZSwgZG9taWQsCisgICAgICAgICAgICAgICAgaWdkX29wcmVnaW9uID4+ IFhDX1BBR0VfU0hJRlQsCisgICAgICAgICAgICAgICAgaWdkX29wcmVnaW9uID4+IFhDX1BBR0Vf U0hJRlQsCisgICAgICAgICAgICAgICAgMiwKKyAgICAgICAgICAgICAgICBEUENJX1JFTU9WRV9N QVBQSU5HKTsKKyAgICB9CisKKyAgICByZXR1cm4gcmV0OworfQorLyoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKi8KKy8qIEdlbmVyaWMgQ29kZSBmb3IgR0ZYIFBhc3N0aHJ1ICovCisv KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworLyogVGhpcyBmdW5jdGlvbiBkZWNp ZGVzIHdoZXRoZXIgSS9PIHBvcnQgbWFwIHNob3VsZCBiZSBza2lwcGVkICovCitpbnQgdmdhX3Nr aXBfaW9wb3J0X21hcChQQ0lEZXZpY2UgKmQpCit7CisgICAgc3RydWN0IHB0X2RldiAqZGV2ID0g KHN0cnVjdCBwdF9kZXYgKilkOworICAgIGludCBza2lwID0gMDsKKworICAgIGlmICggIWdmeF9w YXNzdGhydSB8fCBkZXYtPnBjaV9kZXYtPmRldmljZV9jbGFzcyAhPSAweDAzMDAgKQorICAgICAg ICByZXR1cm4gMDsKKworICAgIHN3aXRjaCggZGV2LT5wY2lfZGV2LT52ZW5kb3JfaWQgKSAKKyAg ICB7CisgICAgY2FzZSBQQ0lfVkVORE9SX0lEX0FUSToKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURf QU1EOgorICAgICAgICBza2lwID0gMTsKKyAgICAgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKyAg ICAgICAgc2tpcCA9IDA7CisgICAgICAgIGJyZWFrOworICAgIH0KKyAgICAgICAgCisgICAgcmV0 dXJuIHNraXA7Cit9CiAvKgogICogcmVnaXN0ZXIgVkdBIHJlc291cmNlcyBmb3IgdGhlIGRvbWFp biB3aXRoIGFzc2lnbmVkIGdmeAogICovCkBAIC0xODQsMTggKzQ1NywzMyBAQCBpbnQgcmVnaXN0 ZXJfdmdhX3JlZ2lvbnMoc3RydWN0IHB0X2RldiAqCiAgICAgaWYgKCAhZ2Z4X3Bhc3N0aHJ1IHx8 IHJlYWxfZGV2aWNlLT5wY2lfZGV2LT5kZXZpY2VfY2xhc3MgIT0gMHgwMzAwICkKICAgICAgICAg cmV0dXJuIHJldDsKIAorICAgIC8qIGxlZ2FjeSBJL08gcG9ydHMgMHgzQjAgLSAweDNCQyAqLwog ICAgIHJldCB8PSB4Y19kb21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgz QjAsCiAgICAgICAgICAgICAweDNCMCwgMHhDLCBEUENJX0FERF9NQVBQSU5HKTsKIAotICAgIHJl dCB8PSB4Y19kb21haW5faW9wb3J0X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwgMHgzQzAsCi0g ICAgICAgICAgICAweDNDMCwgMHgyMCwgRFBDSV9BRERfTUFQUElORyk7Ci0KKyAgICAvKiBsZWdh Y3kgdmlkZW8gTU1JTyByYW5nZSAweEEwMDAwIC0gMHhCRkZGRiAqLwogICAgIHJldCB8PSB4Y19k b21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKICAgICAgICAgICAgIDB4YTAw MDAgPj4gWENfUEFHRV9TSElGVCwKICAgICAgICAgICAgIDB4YTAwMDAgPj4gWENfUEFHRV9TSElG VCwKICAgICAgICAgICAgIDB4MjAsCiAgICAgICAgICAgICBEUENJX0FERF9NQVBQSU5HKTsKIAor ICAgIC8qIE90aGVyIFZHQSByZWdpb25zIGFyZSB2ZW5kb3Igc3BlY2lmaWMgKi8KKyAgICBzd2l0 Y2goIHJlYWxfZGV2aWNlLT5wY2lfZGV2LT52ZW5kb3JfaWQgKSAKKyAgICB7CisgICAgY2FzZSBQ Q0lfVkVORE9SX0lEX0lOVEVMOgorCSAgICByZXQgPSBpZ2RfcmVnaXN0ZXJfdmdhX3JlZ2lvbnMo cmVhbF9kZXZpY2UpOworCSAgICBicmVhazsKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURfQVRJOgor ICAgIGNhc2UgUENJX1ZFTkRPUl9JRF9BTUQ6CisJICAgIHJldCA9IGF0aV9yZWdpc3Rlcl92Z2Ff cmVnaW9ucyhyZWFsX2RldmljZSk7CisJICAgIGJyZWFrOworICAgIGRlZmF1bHQ6CisJICAgIFBU X0xPRygiZ2Z4IGNhcmQgd2Fzbid0IHN1cHBvcnRlZCBieSBYZW4gcGFzc3RocnUhXG4iKTsKKwkg ICAgcmV0ID0gMTsKKwkgICAgYnJlYWs7CisgICAgfQorCiAgICAgaWYgKCByZXQgIT0gMCApCiAg ICAgICAgIFBUX0xPRygiVkdBIHJlZ2lvbiBtYXBwaW5nIGZhaWxlZFxuIik7CiAKQEAgLTIxMywy NiArNTAxLDMxIEBAIGludCB1bnJlZ2lzdGVyX3ZnYV9yZWdpb25zKHN0cnVjdCBwdF9kZXYKICAg ICBpZiAoICFnZnhfcGFzc3RocnUgfHwgcmVhbF9kZXZpY2UtPnBjaV9kZXYtPmRldmljZV9jbGFz cyAhPSAweDAzMDAgKQogICAgICAgICByZXR1cm4gcmV0OwogCisgICAgLyogbGVnYWN5IEkvTyBw b3J0cyAweDNCMCAtIDB4M0JDICovCiAgICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGlu Zyh4Y19oYW5kbGUsIGRvbWlkLCAweDNCMCwKICAgICAgICAgICAgIDB4M0IwLCAweEMsIERQQ0lf UkVNT1ZFX01BUFBJTkcpOwogCi0gICAgcmV0IHw9IHhjX2RvbWFpbl9pb3BvcnRfbWFwcGluZyh4 Y19oYW5kbGUsIGRvbWlkLCAweDNDMCwKLSAgICAgICAgICAgIDB4M0MwLCAweDIwLCBEUENJX1JF TU9WRV9NQVBQSU5HKTsKLQorICAgIC8qIGxlZ2FjeSB2aWRlbyBNTUlPIHJhbmdlIDB4QTAwMDAg LSAweEJGRkZGICovCiAgICAgcmV0IHw9IHhjX2RvbWFpbl9tZW1vcnlfbWFwcGluZyh4Y19oYW5k bGUsIGRvbWlkLAogICAgICAgICAgICAgMHhhMDAwMCA+PiBYQ19QQUdFX1NISUZULAogICAgICAg ICAgICAgMHhhMDAwMCA+PiBYQ19QQUdFX1NISUZULAogICAgICAgICAgICAgMjAsCiAgICAgICAg ICAgICBEUENJX1JFTU9WRV9NQVBQSU5HKTsKIAotICAgIHZlbmRvcl9pZCA9IHB0X3BjaV9ob3N0 X3JlYWQocmVhbF9kZXZpY2UtPnBjaV9kZXYsIFBDSV9WRU5ET1JfSUQsIDIpOwotICAgIGlmICgg KHZlbmRvcl9pZCA9PSBQQ0lfVkVORE9SX0lEX0lOVEVMKSAmJiBpZ2RfZ3Vlc3Rfb3ByZWdpb24g KQorICAgIC8qIE90aGVyIFZHQSByZWdpb25zIGFyZSB2ZW5kb3Igc3BlY2lmaWMgKi8KKyAgICBz d2l0Y2goIHJlYWxfZGV2aWNlLT5wY2lfZGV2LT52ZW5kb3JfaWQgKSAKICAgICB7Ci0gICAgICAg IHJldCB8PSB4Y19kb21haW5fbWVtb3J5X21hcHBpbmcoeGNfaGFuZGxlLCBkb21pZCwKLSAgICAg ICAgICAgICAgICBpZ2RfZ3Vlc3Rfb3ByZWdpb24gPj4gWENfUEFHRV9TSElGVCwKLSAgICAgICAg ICAgICAgICBpZ2RfZ3Vlc3Rfb3ByZWdpb24gPj4gWENfUEFHRV9TSElGVCwKLSAgICAgICAgICAg ICAgICAyLAotICAgICAgICAgICAgICAgIERQQ0lfUkVNT1ZFX01BUFBJTkcpOworICAgIGNhc2Ug UENJX1ZFTkRPUl9JRF9JTlRFTDoKKwkgICAgcmV0ID0gaWdkX3VucmVnaXN0ZXJfdmdhX3JlZ2lv bnMocmVhbF9kZXZpY2UpOworCSAgICBicmVhazsKKyAgICBjYXNlIFBDSV9WRU5ET1JfSURfQVRJ OgorICAgIGNhc2UgUENJX1ZFTkRPUl9JRF9BTUQ6CisJICAgIHJldCA9IGF0aV91bnJlZ2lzdGVy X3ZnYV9yZWdpb25zKHJlYWxfZGV2aWNlKTsKKwkgICAgYnJlYWs7CisgICAgZGVmYXVsdDoKKwkg ICAgUFRfTE9HKCJnZnggY2FyZCB3YXNuJ3Qgc3VwcG9ydGVkIGJ5IFhlbiBwYXNzdGhydSFcbiIp OworCSAgICByZXQgPSAxOworCSAgICBicmVhazsKICAgICB9CiAKICAgICBpZiAoIHJldCAhPSAw ICkK --f46d043c80da97848004d7bf7ed2 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 --f46d043c80da97848004d7bf7ed2-- From xen-users-bounces@lists.xen.org Tue Mar 12 19:49:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 19:49: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 1UFVBC-0002zq-S9; Tue, 12 Mar 2013 19:48:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFVBB-0002zg-9V for xen-users@lists.xen.org; Tue, 12 Mar 2013 19:48:09 +0000 Received: from [85.158.138.51:26842] by server-11.bemta-3.messagelabs.com id 1A/EA-01263-8768F315; Tue, 12 Mar 2013 19:48:08 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1363117687!31519749!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27735 invoked from network); 12 Mar 2013 19:48:07 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 19:48:07 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so238022wgb.12 for ; Tue, 12 Mar 2013 12:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HnFshGZVMekGQrg1605XOTKtE5wfxtl7uJF71PZOhm8=; b=tJn3PwyWybG2ggvA5AKPnl++GpKSf4xFnjnV46OmCp7mLxa+vsFaZk6gpN+wUFaI4D lOXnm3aEKmJet8xiyC8wdL0xoQz8SgH4n1wPNywTQFKv/y6xwh5x6GLq78oy+xgWQe04 RmTkHWF0yd4dVp4tIdmCYhiv4nG6RTFhrKNFoPou3Y3uiJVjaM2yMjfnckRZwuuSBM4L DS5wy6Fr5GEsZPVBhAHVGqord865LEX4j7NlGv9MGhsKpHqb64aYdrB8QxEVeDw3iGzY z4OHYEjGAzHZV2JiPMEJSy1FEaitk2MgC9mK3EbzLIoxsUfqgBp1UodZtuGsiPySM8NZ LcwQ== X-Received: by 10.180.97.233 with SMTP id ed9mr22236424wib.32.1363117687511; Tue, 12 Mar 2013 12:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 12 Mar 2013 12:47:47 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> From: Matthias Date: Tue, 12 Mar 2013 20:47:47 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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, after reading the thread I don't think it will help you cause you got other issues, but since i promised the patch and wrote it for another thread a minute ago anyway, here is the reference to it: http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html :) _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 19:49:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 19:49: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 1UFVBC-0002zq-S9; Tue, 12 Mar 2013 19:48:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFVBB-0002zg-9V for xen-users@lists.xen.org; Tue, 12 Mar 2013 19:48:09 +0000 Received: from [85.158.138.51:26842] by server-11.bemta-3.messagelabs.com id 1A/EA-01263-8768F315; Tue, 12 Mar 2013 19:48:08 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1363117687!31519749!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27735 invoked from network); 12 Mar 2013 19:48:07 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 19:48:07 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so238022wgb.12 for ; Tue, 12 Mar 2013 12:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HnFshGZVMekGQrg1605XOTKtE5wfxtl7uJF71PZOhm8=; b=tJn3PwyWybG2ggvA5AKPnl++GpKSf4xFnjnV46OmCp7mLxa+vsFaZk6gpN+wUFaI4D lOXnm3aEKmJet8xiyC8wdL0xoQz8SgH4n1wPNywTQFKv/y6xwh5x6GLq78oy+xgWQe04 RmTkHWF0yd4dVp4tIdmCYhiv4nG6RTFhrKNFoPou3Y3uiJVjaM2yMjfnckRZwuuSBM4L DS5wy6Fr5GEsZPVBhAHVGqord865LEX4j7NlGv9MGhsKpHqb64aYdrB8QxEVeDw3iGzY z4OHYEjGAzHZV2JiPMEJSy1FEaitk2MgC9mK3EbzLIoxsUfqgBp1UodZtuGsiPySM8NZ LcwQ== X-Received: by 10.180.97.233 with SMTP id ed9mr22236424wib.32.1363117687511; Tue, 12 Mar 2013 12:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 12 Mar 2013 12:47:47 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> From: Matthias Date: Tue, 12 Mar 2013 20:47:47 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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, after reading the thread I don't think it will help you cause you got other issues, but since i promised the patch and wrote it for another thread a minute ago anyway, here is the reference to it: http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html :) _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 19:56:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 19:56: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 1UFVIE-0003Oi-2W; Tue, 12 Mar 2013 19:55:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFVIC-0003OW-Jp for xen-users@lists.xen.org; Tue, 12 Mar 2013 19:55:24 +0000 Received: from [85.158.143.99:26444] by server-3.bemta-4.messagelabs.com id 8E/90-02186-B288F315; Tue, 12 Mar 2013 19:55:23 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1363118122!21431777!1 X-Originating-IP: [74.125.82.42] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32562 invoked from network); 12 Mar 2013 19:55:22 -0000 Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com) (74.125.82.42) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 19:55:22 -0000 Received: by mail-wg0-f42.google.com with SMTP id 12so3677635wgh.5 for ; Tue, 12 Mar 2013 12:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=YZz7Vh7333QHh83vZk4kIKdmV+koQ0Fn6ACk+2hgCTY=; b=ShlY1HusjNaaJONIddE8lpljMrgmA+qvvaR10b/BXK6zvq2jRIsKX3CsOztc611krv SmVg54EftjZOlFCE+NFTf1JHOdrxVLnYRefnsBsEhmtRJNDeVAzvwZ6rcnkR3Nkc6UMG LZT7wHQJB2o51OCo0yZIM1u6elqKKXRWL2fdW/m75VKgNZdP8gyDgxa6GEHe3lnwhBKT nWW2k3ySbMlJKQ3xOlTGlhR8dL2uY/y+UbAEOTpK9lpiyQZcEDRjvBF+qj38bjYcH63W Gd3/QcPrXaFNy+HIUuwnyfgMuYtxHemQFtDI8mq5mDZuwGTGy48OcB77vG3U22ccAFHw tSVg== X-Received: by 10.180.81.193 with SMTP id c1mr22435197wiy.19.1363118122239; Tue, 12 Mar 2013 12:55:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 12 Mar 2013 12:55:02 -0700 (PDT) In-Reply-To: References: <513F5C1E.7010407@cam.ac.uk> From: Matthias Date: Tue, 12 Mar 2013 20:55:02 +0100 Message-ID: To: Matthew Dean Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 Haha, since the discussion moved to XCP and this is not really my area i didn't read your last message. The patch from the thread you mentioned is basically the same then the one I provided.. Did you also tried to do secondary passthrough with the patch applied? Cause primary passthrough didn't work for me either with the patch, but secondary was fixed.. 2013/3/12 Matthias : > Hi, > > to fix the atikmeq.sys bug, you can try two things: > > 1) Use upstream qemu. For this, just add: > > device_model_version = 'qemu-xen' > device_model_override = '/usr/lib/xen/bin/qemu-system-i386' > > to your domU config file. Note that there is currently a bug that the > domU won't start when duing vga passthrough with more then 4GB memory > assigned, so better use some less.. > > 2) If you want to have more then 4GB memory, you can patch the > traditional qemu. This is a bit more complicated cause the qemu stuff > is download through the build and can't be patched right away. Also > stopping in mid build, patching and continuing at least for me caused > some problems, so doing a full build, patch, cleanup and build again > is the safer route: > > git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging > cd xen-unstable-staging > ./configure --disable-stubdom > make -j12 world > git apply --check /path/to/xen-unstable-atipassthrough.patch > git apply /path/to/xen-unstable-atipassthrough.patch > make -j12 clean > make -j12 world > Now do your usual install.. some use the standard, i prefer creating a debball.. > > Some Notes: > - I use the staging branch from xen-unstable, but this is not exactly > necessary for the patch, you can use master just as fine > - the j12 is for multithreading and you should use double your core > number.. since i got 6 cpu cores, it's 12 for me.. > - the patch i have attached is originally from Greg > (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), > so credit goes to him, i only cleaned it up for xen-unstable. Also, > the patch itself was for providing primary passthrough with ATI cards, > but i found it fixing my ati 0x116 bluescreen.. > - due to an insufficiancy in the patch, stubdom would not build > correctly, so you have to disable it > > Please report back if the patch fixes your bluescreen for more > argumentation to bring this patch upstream.. :) (@Greg: that's why i > cc'ed you. hope you don't mind the noise) > > Hope it helps! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 19:56:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 19:56: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 1UFVIE-0003Oi-2W; Tue, 12 Mar 2013 19:55:26 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFVIC-0003OW-Jp for xen-users@lists.xen.org; Tue, 12 Mar 2013 19:55:24 +0000 Received: from [85.158.143.99:26444] by server-3.bemta-4.messagelabs.com id 8E/90-02186-B288F315; Tue, 12 Mar 2013 19:55:23 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1363118122!21431777!1 X-Originating-IP: [74.125.82.42] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32562 invoked from network); 12 Mar 2013 19:55:22 -0000 Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com) (74.125.82.42) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 19:55:22 -0000 Received: by mail-wg0-f42.google.com with SMTP id 12so3677635wgh.5 for ; Tue, 12 Mar 2013 12:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=YZz7Vh7333QHh83vZk4kIKdmV+koQ0Fn6ACk+2hgCTY=; b=ShlY1HusjNaaJONIddE8lpljMrgmA+qvvaR10b/BXK6zvq2jRIsKX3CsOztc611krv SmVg54EftjZOlFCE+NFTf1JHOdrxVLnYRefnsBsEhmtRJNDeVAzvwZ6rcnkR3Nkc6UMG LZT7wHQJB2o51OCo0yZIM1u6elqKKXRWL2fdW/m75VKgNZdP8gyDgxa6GEHe3lnwhBKT nWW2k3ySbMlJKQ3xOlTGlhR8dL2uY/y+UbAEOTpK9lpiyQZcEDRjvBF+qj38bjYcH63W Gd3/QcPrXaFNy+HIUuwnyfgMuYtxHemQFtDI8mq5mDZuwGTGy48OcB77vG3U22ccAFHw tSVg== X-Received: by 10.180.81.193 with SMTP id c1mr22435197wiy.19.1363118122239; Tue, 12 Mar 2013 12:55:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 12 Mar 2013 12:55:02 -0700 (PDT) In-Reply-To: References: <513F5C1E.7010407@cam.ac.uk> From: Matthias Date: Tue, 12 Mar 2013 20:55:02 +0100 Message-ID: To: Matthew Dean Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 Haha, since the discussion moved to XCP and this is not really my area i didn't read your last message. The patch from the thread you mentioned is basically the same then the one I provided.. Did you also tried to do secondary passthrough with the patch applied? Cause primary passthrough didn't work for me either with the patch, but secondary was fixed.. 2013/3/12 Matthias : > Hi, > > to fix the atikmeq.sys bug, you can try two things: > > 1) Use upstream qemu. For this, just add: > > device_model_version = 'qemu-xen' > device_model_override = '/usr/lib/xen/bin/qemu-system-i386' > > to your domU config file. Note that there is currently a bug that the > domU won't start when duing vga passthrough with more then 4GB memory > assigned, so better use some less.. > > 2) If you want to have more then 4GB memory, you can patch the > traditional qemu. This is a bit more complicated cause the qemu stuff > is download through the build and can't be patched right away. Also > stopping in mid build, patching and continuing at least for me caused > some problems, so doing a full build, patch, cleanup and build again > is the safer route: > > git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging > cd xen-unstable-staging > ./configure --disable-stubdom > make -j12 world > git apply --check /path/to/xen-unstable-atipassthrough.patch > git apply /path/to/xen-unstable-atipassthrough.patch > make -j12 clean > make -j12 world > Now do your usual install.. some use the standard, i prefer creating a debball.. > > Some Notes: > - I use the staging branch from xen-unstable, but this is not exactly > necessary for the patch, you can use master just as fine > - the j12 is for multithreading and you should use double your core > number.. since i got 6 cpu cores, it's 12 for me.. > - the patch i have attached is originally from Greg > (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), > so credit goes to him, i only cleaned it up for xen-unstable. Also, > the patch itself was for providing primary passthrough with ATI cards, > but i found it fixing my ati 0x116 bluescreen.. > - due to an insufficiancy in the patch, stubdom would not build > correctly, so you have to disable it > > Please report back if the patch fixes your bluescreen for more > argumentation to bring this patch upstream.. :) (@Greg: that's why i > cc'ed you. hope you don't mind the noise) > > Hope it helps! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 21:06:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 21:06: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 1UFWNa-0005aq-ML; Tue, 12 Mar 2013 21:05:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFWNY-0005al-0t for xen-users@lists.xen.org; Tue, 12 Mar 2013 21:05:00 +0000 Received: from [85.158.137.99:55302] by server-15.bemta-3.messagelabs.com id 6B/DB-23142-6789F315; Tue, 12 Mar 2013 21:04:54 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1363122292!18053782!1 X-Originating-IP: [209.85.223.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1341 invoked from network); 12 Mar 2013 21:04:53 -0000 Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com) (209.85.223.169) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 21:04:53 -0000 Received: by mail-ie0-f169.google.com with SMTP id 13so451068iea.14 for ; Tue, 12 Mar 2013 14:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kjkLYa9+PdCusUbL7NO7p0Aq7QP++cwBOpJI7jPZCKs=; b=GSfjMd2Ue8csQ5iyCYtu5XjRStcfbqVfauYZ9D/A3xhoGejAG16jcOT04O5uxPU2Q/ QYbzB1HIEEceVH1hKljvcYcGqpy47+cxrBqz1+zyqRLjz4v9gzMQVC1IsXit5EWfAKY2 MIlfGBCT6IHlMWsRRFHnqV1tywcRjKQEP/qBKnAfusIV/FNHjfI9bC0/vwzRCrNIsQ/k 1smLgBq2EwOEdvJbueS1hepwkGdB15ueDvzFK/Q4mu9q82VZhqayTA5WkVqqlkkTE++s ltdAC0tWU/yz05dNPUl4avoerzi5b4R1WFV2rIEN3BzNG2+VGAfUTavDOXHHSN508qlr VpIg== MIME-Version: 1.0 X-Received: by 10.50.183.233 with SMTP id ep9mr13518061igc.87.1363122292231; Tue, 12 Mar 2013 14:04:52 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Tue, 12 Mar 2013 14:04:52 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Tue, 12 Mar 2013 14:04:52 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 12 Mar 2013 18:04:52 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============7013841173835166374==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7013841173835166374== Content-Type: multipart/alternative; boundary=14dae9340959039e0c04d7c0a435 --14dae9340959039e0c04d7c0a435 Content-Type: text/plain; charset=ISO-8859-1 Matthias, I think you can help! I applied a similar patch to my xen (unstable, by the way) and all that I get is "parallel0 console" through VNC and the display seems dead (black screen). This time I'm trying to "primary VGA passthru" it. But I noticed something: my VMs have been running with 8gb ram. I'll try to decrease that... I sort of gave up using my radeon 7950 as secondary, it will only work properly if I reboot dom0 as well. On Mar 12, 2013 4:48 PM, "Matthias" wrote: Hi, after reading the thread I don't think it will help you cause you got other issues, but since i promised the patch and wrote it for another thread a minute ago anyway, here is the reference to it: http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html :) --14dae9340959039e0c04d7c0a435 Content-Type: text/html; charset=ISO-8859-1

Matthias, I think you can help!

I applied a similar patch to my xen (unstable, by the way) and all that I get is "parallel0 console" through VNC and the display seems dead (black screen). This time I'm trying to "primary VGA passthru" it.

But I noticed something: my VMs have been running with 8gb ram. I'll try to decrease that...

I sort of gave up using my radeon 7950 as secondary, it will only work properly if I reboot dom0 as well.

On Mar 12, 2013 4:48 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

after reading the thread I don't think it will help you cause you got
other issues, but since i promised the patch and wrote it for another
thread a minute ago anyway, here is the reference to it:

http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html

:)

--14dae9340959039e0c04d7c0a435-- --===============7013841173835166374== 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 --===============7013841173835166374==-- From xen-users-bounces@lists.xen.org Tue Mar 12 21:06:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 21:06: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 1UFWNa-0005aq-ML; Tue, 12 Mar 2013 21:05:02 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFWNY-0005al-0t for xen-users@lists.xen.org; Tue, 12 Mar 2013 21:05:00 +0000 Received: from [85.158.137.99:55302] by server-15.bemta-3.messagelabs.com id 6B/DB-23142-6789F315; Tue, 12 Mar 2013 21:04:54 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1363122292!18053782!1 X-Originating-IP: [209.85.223.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1341 invoked from network); 12 Mar 2013 21:04:53 -0000 Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com) (209.85.223.169) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 21:04:53 -0000 Received: by mail-ie0-f169.google.com with SMTP id 13so451068iea.14 for ; Tue, 12 Mar 2013 14:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kjkLYa9+PdCusUbL7NO7p0Aq7QP++cwBOpJI7jPZCKs=; b=GSfjMd2Ue8csQ5iyCYtu5XjRStcfbqVfauYZ9D/A3xhoGejAG16jcOT04O5uxPU2Q/ QYbzB1HIEEceVH1hKljvcYcGqpy47+cxrBqz1+zyqRLjz4v9gzMQVC1IsXit5EWfAKY2 MIlfGBCT6IHlMWsRRFHnqV1tywcRjKQEP/qBKnAfusIV/FNHjfI9bC0/vwzRCrNIsQ/k 1smLgBq2EwOEdvJbueS1hepwkGdB15ueDvzFK/Q4mu9q82VZhqayTA5WkVqqlkkTE++s ltdAC0tWU/yz05dNPUl4avoerzi5b4R1WFV2rIEN3BzNG2+VGAfUTavDOXHHSN508qlr VpIg== MIME-Version: 1.0 X-Received: by 10.50.183.233 with SMTP id ep9mr13518061igc.87.1363122292231; Tue, 12 Mar 2013 14:04:52 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Tue, 12 Mar 2013 14:04:52 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Tue, 12 Mar 2013 14:04:52 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 12 Mar 2013 18:04:52 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============7013841173835166374==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7013841173835166374== Content-Type: multipart/alternative; boundary=14dae9340959039e0c04d7c0a435 --14dae9340959039e0c04d7c0a435 Content-Type: text/plain; charset=ISO-8859-1 Matthias, I think you can help! I applied a similar patch to my xen (unstable, by the way) and all that I get is "parallel0 console" through VNC and the display seems dead (black screen). This time I'm trying to "primary VGA passthru" it. But I noticed something: my VMs have been running with 8gb ram. I'll try to decrease that... I sort of gave up using my radeon 7950 as secondary, it will only work properly if I reboot dom0 as well. On Mar 12, 2013 4:48 PM, "Matthias" wrote: Hi, after reading the thread I don't think it will help you cause you got other issues, but since i promised the patch and wrote it for another thread a minute ago anyway, here is the reference to it: http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html :) --14dae9340959039e0c04d7c0a435 Content-Type: text/html; charset=ISO-8859-1

Matthias, I think you can help!

I applied a similar patch to my xen (unstable, by the way) and all that I get is "parallel0 console" through VNC and the display seems dead (black screen). This time I'm trying to "primary VGA passthru" it.

But I noticed something: my VMs have been running with 8gb ram. I'll try to decrease that...

I sort of gave up using my radeon 7950 as secondary, it will only work properly if I reboot dom0 as well.

On Mar 12, 2013 4:48 PM, "Matthias" <matthias.kannenberg@googlemail.com> wrote:

Hi,

after reading the thread I don't think it will help you cause you got
other issues, but since i promised the patch and wrote it for another
thread a minute ago anyway, here is the reference to it:

http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html

:)

--14dae9340959039e0c04d7c0a435-- --===============7013841173835166374== 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 --===============7013841173835166374==-- From xen-users-bounces@lists.xen.org Tue Mar 12 21:22:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 21:22:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFWdO-0006Bx-0Z; Tue, 12 Mar 2013 21:21:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFWdM-0006Bp-W4 for xen-users@lists.xen.org; Tue, 12 Mar 2013 21:21:21 +0000 Received: from [85.158.137.99:33270] by server-10.bemta-3.messagelabs.com id 9B/16-19664-C4C9F315; Tue, 12 Mar 2013 21:21:16 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1363123275!17966483!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27832 invoked from network); 12 Mar 2013 21:21:15 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 21:21:15 -0000 Received: by mail-wi0-f177.google.com with SMTP id hm14so257263wib.16 for ; Tue, 12 Mar 2013 14:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=CLtGubotjeMFdIQEYu4sO5tQLR8P9CTK5RdwUO0pXOE=; b=q5/60gRJ0IM0LTESZzJfOoKwt15tpX568NHrYrFxrUVrxzQriNEhVNmc00NNH6Kw8V rqpHUVLf2Ua7aQ7ZLylcUetVJrlI+nlcVDeKhyhHClJ9ap48prxx6zGU5l2J8GWHuoM8 54eqU6J6eQG2xSjy36RT/DTU3JkdgLy9lLAdHxg+D1Z+JXHuoFjlnSO91cQor552NeVG kFHJSbpi3+Y5JKo3I8gIgRKyncuy98N48putqoSpM4yL7EV9LWxFgDmAsAcgU+uaWxjS KgarRe3WPFu9597pmdLfQIYL2iK355DJd1P/prZ3p8QQX/l3hJ0q2renTYQbe3Ln8jO0 Uyog== X-Received: by 10.194.60.195 with SMTP id j3mr29715765wjr.33.1363123274802; Tue, 12 Mar 2013 14:21:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Tue, 12 Mar 2013 14:20:54 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Tue, 12 Mar 2013 17:20:54 -0400 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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, Mar 12, 2013 at 10:35 AM, jacek burghardt wrote: > I have 3 xen servers and i had used lvm for virtual drives on local storage > I want to backup lvms to iscsi i had installed freenas under xen and I am > thinking about exporting iscsi matching sizes of lvm virtual partitions so I > can back them up rsync. I looking for ideas on proper way of backing up > windows 2012s and archlinux Ah, so you're just looking to back up? That's much easier than trying to set up failover. I would certainly recommend rsync for Linux, and it can work on Windows if you're willing to either install Cygwin on the domU or share the necessary folders via samba and do pull backups. I have some helpful rsync scripts that I'd be willing to share if you're interested. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 21:22:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 21:22:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFWdO-0006Bx-0Z; Tue, 12 Mar 2013 21:21:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFWdM-0006Bp-W4 for xen-users@lists.xen.org; Tue, 12 Mar 2013 21:21:21 +0000 Received: from [85.158.137.99:33270] by server-10.bemta-3.messagelabs.com id 9B/16-19664-C4C9F315; Tue, 12 Mar 2013 21:21:16 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1363123275!17966483!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27832 invoked from network); 12 Mar 2013 21:21:15 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 21:21:15 -0000 Received: by mail-wi0-f177.google.com with SMTP id hm14so257263wib.16 for ; Tue, 12 Mar 2013 14:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=CLtGubotjeMFdIQEYu4sO5tQLR8P9CTK5RdwUO0pXOE=; b=q5/60gRJ0IM0LTESZzJfOoKwt15tpX568NHrYrFxrUVrxzQriNEhVNmc00NNH6Kw8V rqpHUVLf2Ua7aQ7ZLylcUetVJrlI+nlcVDeKhyhHClJ9ap48prxx6zGU5l2J8GWHuoM8 54eqU6J6eQG2xSjy36RT/DTU3JkdgLy9lLAdHxg+D1Z+JXHuoFjlnSO91cQor552NeVG kFHJSbpi3+Y5JKo3I8gIgRKyncuy98N48putqoSpM4yL7EV9LWxFgDmAsAcgU+uaWxjS KgarRe3WPFu9597pmdLfQIYL2iK355DJd1P/prZ3p8QQX/l3hJ0q2renTYQbe3Ln8jO0 Uyog== X-Received: by 10.194.60.195 with SMTP id j3mr29715765wjr.33.1363123274802; Tue, 12 Mar 2013 14:21:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Tue, 12 Mar 2013 14:20:54 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Tue, 12 Mar 2013 17:20:54 -0400 Message-ID: To: jacek burghardt Cc: xen-users Subject: Re: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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, Mar 12, 2013 at 10:35 AM, jacek burghardt wrote: > I have 3 xen servers and i had used lvm for virtual drives on local storage > I want to backup lvms to iscsi i had installed freenas under xen and I am > thinking about exporting iscsi matching sizes of lvm virtual partitions so I > can back them up rsync. I looking for ideas on proper way of backing up > windows 2012s and archlinux Ah, so you're just looking to back up? That's much easier than trying to set up failover. I would certainly recommend rsync for Linux, and it can work on Windows if you're willing to either install Cygwin on the domU or share the necessary folders via samba and do pull backups. I have some helpful rsync scripts that I'd be willing to share if you're interested. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 12 22:52:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 22:52: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 1UFY29-0007gT-OI; Tue, 12 Mar 2013 22:51:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFY28-0007gI-2j for xen-users@lists.xen.org; Tue, 12 Mar 2013 22:51:00 +0000 Received: from [85.158.137.99:61578] by server-6.bemta-3.messagelabs.com id CF/AC-11048-351BF315; Tue, 12 Mar 2013 22:50:59 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1363128655!17004526!1 X-Originating-IP: [209.85.223.177] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18292 invoked from network); 12 Mar 2013 22:50:57 -0000 Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com) (209.85.223.177) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 22:50:57 -0000 Received: by mail-ie0-f177.google.com with SMTP id 16so566667iea.22 for ; Tue, 12 Mar 2013 15:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/CkfbsPqxHEa3xw4DsdNgifT6G5uyNlFCszOvBrfAZc=; b=zgur5o8mlaHmcfcWEnR+RDOrNAoKZfMl+1BUPPOs1tBFqI6BClaoMbFwnGQA66JjRw ok5nar1VvTFLrw4KF7V1RVN+xHIK+2HSfz/CuKSm0fmr1ZV4KTJD5hu1nhwCxVgyvxDR hBsrvrfPBG2LgYduO9Xal51NUsJdGloyOLVkRDeJ39/igb0uVy/xGYKaPZv6wT+v1nRq 8lXdLuNyeUjDWmj8xAvP1rEqh/2I6D3clromSYeIh69R4GkzGy3jVExB7U+DraIKken5 VQW6ZkYYIDnMHJhIQ2JahtVYhqfwtCb0J15uMnAAx8RixlkkdmQSxdeV/+7RoqQVzAmD Fhjg== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr13420117igc.91.1363128655534; Tue, 12 Mar 2013 15:50:55 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Tue, 12 Mar 2013 15:50:55 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 12 Mar 2013 19:50:55 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8802008000476296816==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8802008000476296816== Content-Type: multipart/alternative; boundary=14dae93403454bf76b04d7c21f43 --14dae93403454bf76b04d7c21f43 Content-Type: text/plain; charset=ISO-8859-1 Dude, please forget my previous message! I followed that post from *xen-devel* string, applied the patch and everything seems to be working just fine! That's really my case (newest kernel, old amd patch). I hope those problems become part of the past from now on. You're are awesome! Thx a lot. 2013/3/12 Guilherme Suzuki > Matthias, I think you can help! > > I applied a similar patch to my xen (unstable, by the way) and all that I > get is "parallel0 console" through VNC and the display seems dead (black > screen). This time I'm trying to "primary VGA passthru" it. > > But I noticed something: my VMs have been running with 8gb ram. I'll try > to decrease that... > > I sort of gave up using my radeon 7950 as secondary, it will only work > properly if I reboot dom0 as well. > > On Mar 12, 2013 4:48 PM, "Matthias" > wrote: > > Hi, > > after reading the thread I don't think it will help you cause you got > other issues, but since i promised the patch and wrote it for another > thread a minute ago anyway, here is the reference to it: > > http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html > > :) > > -- Grato, ** *Guilherme Suzuki* Consultor em TI para projetos Microsoft *http://www.guilhermesuzuki.com* 11 - 992360535 11 - 20990757 --14dae93403454bf76b04d7c21f43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dude, please forget my previous message!
I followed that post from xen-devel string, applied the p= atch and everything seems to be working just fine!

That's= really my case (newest kernel, old amd patch). I hope those problems becom= e part of the past from now on.

You're are awesome! Thx a lot.


2013/3/12 Guilherme Suzuki <su= zuki.gui@gmail.com>

Matthias, I think you can help!

I applied a similar patch to my xen (unstable, by the way) and all that = I get is "parallel0 console" through VNC and the display seems de= ad (black screen). This time I'm trying to "primary VGA passthru&q= uot; it.

But I noticed something: my VMs have been running with 8gb ram. I'll= try to decrease that...

I sort of gave up using my radeon 7950 as secondary, it will only work p= roperly if I reboot dom0 as well.

On Mar 12, 2013 4:48 PM, "Matthias&qu= ot; <matthias.kannenberg@googlemail.com> wrote:

Hi,

after reading the thread I don't think it will help you cause you got other issues, but since i promised the patch and wrote it for another
thread a minute ago anyway, here is the reference to it:

http://lists.xen.org/archives/html/xen-users/2013-03/= msg00127.html

:)




--
Grato,
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex">Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=A0
--14dae93403454bf76b04d7c21f43-- --===============8802008000476296816== 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 --===============8802008000476296816==-- From xen-users-bounces@lists.xen.org Tue Mar 12 22:52:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 12 Mar 2013 22:52: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 1UFY29-0007gT-OI; Tue, 12 Mar 2013 22:51:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFY28-0007gI-2j for xen-users@lists.xen.org; Tue, 12 Mar 2013 22:51:00 +0000 Received: from [85.158.137.99:61578] by server-6.bemta-3.messagelabs.com id CF/AC-11048-351BF315; Tue, 12 Mar 2013 22:50:59 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-4.tower-217.messagelabs.com!1363128655!17004526!1 X-Originating-IP: [209.85.223.177] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18292 invoked from network); 12 Mar 2013 22:50:57 -0000 Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com) (209.85.223.177) by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 12 Mar 2013 22:50:57 -0000 Received: by mail-ie0-f177.google.com with SMTP id 16so566667iea.22 for ; Tue, 12 Mar 2013 15:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/CkfbsPqxHEa3xw4DsdNgifT6G5uyNlFCszOvBrfAZc=; b=zgur5o8mlaHmcfcWEnR+RDOrNAoKZfMl+1BUPPOs1tBFqI6BClaoMbFwnGQA66JjRw ok5nar1VvTFLrw4KF7V1RVN+xHIK+2HSfz/CuKSm0fmr1ZV4KTJD5hu1nhwCxVgyvxDR hBsrvrfPBG2LgYduO9Xal51NUsJdGloyOLVkRDeJ39/igb0uVy/xGYKaPZv6wT+v1nRq 8lXdLuNyeUjDWmj8xAvP1rEqh/2I6D3clromSYeIh69R4GkzGy3jVExB7U+DraIKken5 VQW6ZkYYIDnMHJhIQ2JahtVYhqfwtCb0J15uMnAAx8RixlkkdmQSxdeV/+7RoqQVzAmD Fhjg== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr13420117igc.91.1363128655534; Tue, 12 Mar 2013 15:50:55 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Tue, 12 Mar 2013 15:50:55 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 12 Mar 2013 19:50:55 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8802008000476296816==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8802008000476296816== Content-Type: multipart/alternative; boundary=14dae93403454bf76b04d7c21f43 --14dae93403454bf76b04d7c21f43 Content-Type: text/plain; charset=ISO-8859-1 Dude, please forget my previous message! I followed that post from *xen-devel* string, applied the patch and everything seems to be working just fine! That's really my case (newest kernel, old amd patch). I hope those problems become part of the past from now on. You're are awesome! Thx a lot. 2013/3/12 Guilherme Suzuki > Matthias, I think you can help! > > I applied a similar patch to my xen (unstable, by the way) and all that I > get is "parallel0 console" through VNC and the display seems dead (black > screen). This time I'm trying to "primary VGA passthru" it. > > But I noticed something: my VMs have been running with 8gb ram. I'll try > to decrease that... > > I sort of gave up using my radeon 7950 as secondary, it will only work > properly if I reboot dom0 as well. > > On Mar 12, 2013 4:48 PM, "Matthias" > wrote: > > Hi, > > after reading the thread I don't think it will help you cause you got > other issues, but since i promised the patch and wrote it for another > thread a minute ago anyway, here is the reference to it: > > http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html > > :) > > -- Grato, ** *Guilherme Suzuki* Consultor em TI para projetos Microsoft *http://www.guilhermesuzuki.com* 11 - 992360535 11 - 20990757 --14dae93403454bf76b04d7c21f43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dude, please forget my previous message!
I followed that post from xen-devel string, applied the p= atch and everything seems to be working just fine!

That's= really my case (newest kernel, old amd patch). I hope those problems becom= e part of the past from now on.

You're are awesome! Thx a lot.


2013/3/12 Guilherme Suzuki <su= zuki.gui@gmail.com>

Matthias, I think you can help!

I applied a similar patch to my xen (unstable, by the way) and all that = I get is "parallel0 console" through VNC and the display seems de= ad (black screen). This time I'm trying to "primary VGA passthru&q= uot; it.

But I noticed something: my VMs have been running with 8gb ram. I'll= try to decrease that...

I sort of gave up using my radeon 7950 as secondary, it will only work p= roperly if I reboot dom0 as well.

On Mar 12, 2013 4:48 PM, "Matthias&qu= ot; <matthias.kannenberg@googlemail.com> wrote:

Hi,

after reading the thread I don't think it will help you cause you got other issues, but since i promised the patch and wrote it for another
thread a minute ago anyway, here is the reference to it:

http://lists.xen.org/archives/html/xen-users/2013-03/= msg00127.html

:)




--
Grato,
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex">Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=A0
--14dae93403454bf76b04d7c21f43-- --===============8802008000476296816== 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 --===============8802008000476296816==-- From xen-users-bounces@lists.xen.org Wed Mar 13 01:39:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 01:39: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 1UFaeI-0005Hp-Ls; Wed, 13 Mar 2013 01:38:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFaeG-0005Hg-S7 for xen-users@lists.xen.org; Wed, 13 Mar 2013 01:38:33 +0000 Received: from [85.158.139.83:63986] by server-1.bemta-5.messagelabs.com id 09/A5-14063-798DF315; Wed, 13 Mar 2013 01:38:31 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1363138710!27625338!1 X-Originating-IP: [74.125.82.181] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10027 invoked from network); 13 Mar 2013 01:38:30 -0000 Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com) (74.125.82.181) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 01:38:30 -0000 Received: by mail-we0-f181.google.com with SMTP id t44so480799wey.26 for ; Tue, 12 Mar 2013 18:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/mIKIy/ob0fBuM6TNmett111PI+6Rhee3ftERr72ilg=; b=NxfsUnLPPu8/8S2PdSOVzO36KvhvM1sQ7hiGxeXZlnvUOH11mo0TUAF87gGbYsa7A6 HKrKSuljVi+fZSh7DDk0wqYlTcobJhjkbm67RLcnIvwIVKzC/+mubiTTQTrdQmK1N2kF Oxlmm88V0Nvplk+JU3ytbtfu+eESkJ89vzabduRaLcQ67YlthH0WXbgKOLpzeCAAw89g MWBvQbsdv1mzsGNrintMuGByy49UCr75b/2jhhGelwZ8/CIPXvwqIYDjIk6ZYGNc5txF V/a9/XN7gKkx12UYs/9njvyC3Ak4uOmu34a9ZR+yjnRFmWGnh6nZEcwVZsv3dNDWU/u3 K/RA== X-Received: by 10.180.183.193 with SMTP id eo1mr23621531wic.19.1363138710118; Tue, 12 Mar 2013 18:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 12 Mar 2013 18:38:09 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> From: Matthias Date: Wed, 13 Mar 2013 02:38:09 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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, good to hear it worked for you! Can you be more specific in what you now did and what xen-devel-thread you followed? 2013/3/12 Guilherme Suzuki : > Dude, please forget my previous message! > > I followed that post from xen-devel string, applied the patch and everything > seems to be working just fine! > > That's really my case (newest kernel, old amd patch). I hope those problems > become part of the past from now on. > > You're are awesome! Thx a lot. > > > 2013/3/12 Guilherme Suzuki >> >> Matthias, I think you can help! >> >> I applied a similar patch to my xen (unstable, by the way) and all that I >> get is "parallel0 console" through VNC and the display seems dead (black >> screen). This time I'm trying to "primary VGA passthru" it. >> >> But I noticed something: my VMs have been running with 8gb ram. I'll try >> to decrease that... >> >> I sort of gave up using my radeon 7950 as secondary, it will only work >> properly if I reboot dom0 as well. >> >> On Mar 12, 2013 4:48 PM, "Matthias" >> wrote: >> >> Hi, >> >> after reading the thread I don't think it will help you cause you got >> other issues, but since i promised the patch and wrote it for another >> thread a minute ago anyway, here is the reference to it: >> >> http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html >> >> :) > > > > > -- > Grato, > > Guilherme Suzuki > Consultor em TI para projetos Microsoft > http://www.guilhermesuzuki.com > 11 - 992360535 > 11 - 20990757 > > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 01:39:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 01:39: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 1UFaeI-0005Hp-Ls; Wed, 13 Mar 2013 01:38:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFaeG-0005Hg-S7 for xen-users@lists.xen.org; Wed, 13 Mar 2013 01:38:33 +0000 Received: from [85.158.139.83:63986] by server-1.bemta-5.messagelabs.com id 09/A5-14063-798DF315; Wed, 13 Mar 2013 01:38:31 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1363138710!27625338!1 X-Originating-IP: [74.125.82.181] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10027 invoked from network); 13 Mar 2013 01:38:30 -0000 Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com) (74.125.82.181) by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 01:38:30 -0000 Received: by mail-we0-f181.google.com with SMTP id t44so480799wey.26 for ; Tue, 12 Mar 2013 18:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/mIKIy/ob0fBuM6TNmett111PI+6Rhee3ftERr72ilg=; b=NxfsUnLPPu8/8S2PdSOVzO36KvhvM1sQ7hiGxeXZlnvUOH11mo0TUAF87gGbYsa7A6 HKrKSuljVi+fZSh7DDk0wqYlTcobJhjkbm67RLcnIvwIVKzC/+mubiTTQTrdQmK1N2kF Oxlmm88V0Nvplk+JU3ytbtfu+eESkJ89vzabduRaLcQ67YlthH0WXbgKOLpzeCAAw89g MWBvQbsdv1mzsGNrintMuGByy49UCr75b/2jhhGelwZ8/CIPXvwqIYDjIk6ZYGNc5txF V/a9/XN7gKkx12UYs/9njvyC3Ak4uOmu34a9ZR+yjnRFmWGnh6nZEcwVZsv3dNDWU/u3 K/RA== X-Received: by 10.180.183.193 with SMTP id eo1mr23621531wic.19.1363138710118; Tue, 12 Mar 2013 18:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Tue, 12 Mar 2013 18:38:09 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> From: Matthias Date: Wed, 13 Mar 2013 02:38:09 +0100 Message-ID: To: Guilherme Suzuki Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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, good to hear it worked for you! Can you be more specific in what you now did and what xen-devel-thread you followed? 2013/3/12 Guilherme Suzuki : > Dude, please forget my previous message! > > I followed that post from xen-devel string, applied the patch and everything > seems to be working just fine! > > That's really my case (newest kernel, old amd patch). I hope those problems > become part of the past from now on. > > You're are awesome! Thx a lot. > > > 2013/3/12 Guilherme Suzuki >> >> Matthias, I think you can help! >> >> I applied a similar patch to my xen (unstable, by the way) and all that I >> get is "parallel0 console" through VNC and the display seems dead (black >> screen). This time I'm trying to "primary VGA passthru" it. >> >> But I noticed something: my VMs have been running with 8gb ram. I'll try >> to decrease that... >> >> I sort of gave up using my radeon 7950 as secondary, it will only work >> properly if I reboot dom0 as well. >> >> On Mar 12, 2013 4:48 PM, "Matthias" >> wrote: >> >> Hi, >> >> after reading the thread I don't think it will help you cause you got >> other issues, but since i promised the patch and wrote it for another >> thread a minute ago anyway, here is the reference to it: >> >> http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html >> >> :) > > > > > -- > Grato, > > Guilherme Suzuki > Consultor em TI para projetos Microsoft > http://www.guilhermesuzuki.com > 11 - 992360535 > 11 - 20990757 > > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 01:47:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 01:47: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 1UFalr-0005YC-Sa; Wed, 13 Mar 2013 01:46:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFalp-0005Y7-Nj for xen-users@lists.xen.org; Wed, 13 Mar 2013 01:46:22 +0000 Received: from [85.158.139.211:44308] by server-6.bemta-5.messagelabs.com id 4D/F4-21466-C6ADF315; Wed, 13 Mar 2013 01:46:20 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1363139177!17592508!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9590 invoked from network); 13 Mar 2013 01:46:18 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 01:46:18 -0000 Received: by mail-pb0-f43.google.com with SMTP id md12so468713pbc.30 for ; Tue, 12 Mar 2013 18:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1QD2cZiWAuVw426JvjaApRwyLCCnw8FN4zH2Glrg8oA=; b=JWTTbJK4M2LSwYSwt5ayBFBqNQT/aPbH0x46YE0FAE1eRP12dPChTi0LAYZDSAq+dg cRJfuzSRrWlNrmAHIf7aew89EF0fQJZy5aYCnzErJz7znsqMUJnTV0WrGjPCFoNfDu0m 6ogQ4sisQrRh+MjdT7x7UWeJyD8D2ukn3Va8+4HgxJG22J6bBqE5Z9zA5YxSDSMgZQg0 EatjDDYYeX3PyHhWDi02K0wKSsAl3pQi3Zkn1RwCzl1LV6nwvz8kUG7ZoXycG4Wq1lhY pnJ0+E2eDhy9K7OHJ7G12c41r6CXHkQLWmt9NBBodMBI5Z/hOoal/p4Hkv9xhf2JLer0 KACA== MIME-Version: 1.0 X-Received: by 10.68.198.34 with SMTP id iz2mr41325624pbc.148.1363139176538; Tue, 12 Mar 2013 18:46:16 -0700 (PDT) Received: by 10.68.57.105 with HTTP; Tue, 12 Mar 2013 18:46:16 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 12 Mar 2013 22:46:16 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8569968951166862887==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8569968951166862887== Content-Type: multipart/alternative; boundary=047d7bd76d9c665d3504d7c49265 --047d7bd76d9c665d3504d7c49265 Content-Type: text/plain; charset=ISO-8859-1 Alright, I really thought that things would work now just fine. It does, BUT I'm getting the famous *BSOD* now (after rebooting the *domU*). Now I can use my radeon as primary device or secondary as well (since dom0 is freshly booted) I followed this link straight: http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html I gitted xen-unstable-staging, applied xen-unstable-atipassthough.patch (the one attached to the link above) and then tried to passthru the VGA device. My kernel version is 3.8.1-201 (I had compiled xen modules into the kernel to use kernel parameters). 2013/3/12 Matthias > Hi, > > good to hear it worked for you! > > Can you be more specific in what you now did and what xen-devel-thread > you followed? > > 2013/3/12 Guilherme Suzuki : > > Dude, please forget my previous message! > > > > I followed that post from xen-devel string, applied the patch and > everything > > seems to be working just fine! > > > > That's really my case (newest kernel, old amd patch). I hope those > problems > > become part of the past from now on. > > > > You're are awesome! Thx a lot. > > > > > > 2013/3/12 Guilherme Suzuki > >> > >> Matthias, I think you can help! > >> > >> I applied a similar patch to my xen (unstable, by the way) and all that > I > >> get is "parallel0 console" through VNC and the display seems dead (black > >> screen). This time I'm trying to "primary VGA passthru" it. > >> > >> But I noticed something: my VMs have been running with 8gb ram. I'll try > >> to decrease that... > >> > >> I sort of gave up using my radeon 7950 as secondary, it will only work > >> properly if I reboot dom0 as well. > >> > >> On Mar 12, 2013 4:48 PM, "Matthias" > > >> wrote: > >> > >> Hi, > >> > >> after reading the thread I don't think it will help you cause you got > >> other issues, but since i promised the patch and wrote it for another > >> thread a minute ago anyway, here is the reference to it: > >> > >> http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html > >> > >> :) > > > > > > > > > > -- > > Grato, > > > > Guilherme Suzuki > > Consultor em TI para projetos Microsoft > > http://www.guilhermesuzuki.com > > 11 - 992360535 > > 11 - 20990757 > > > > > -- Grato, ** *Guilherme Suzuki* Consultor em TI para projetos Microsoft *http://www.guilhermesuzuki.com* 11 - 992360535 11 - 20990757 --047d7bd76d9c665d3504d7c49265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Alright, I really thought that things would work= now just fine. It does, BUT I'm getting the famous BSOD now (af= ter rebooting the domU). Now I can use my radeon as primary device o= r secondary as well (since dom0 is freshly booted)

I followed this link straight: http://lists.xen.org/archives/= html/xen-users/2013-03/msg00127.html

I gitted xen-unstable= -staging, applied xen-unstable-atipassthough.patch (the one attached to the= link above) and then tried to passthru the VGA device. My kernel version i= s 3.8.1-201 (I had compiled xen modules into the kernel to use kernel param= eters).



201= 3/3/12 Matthias <matthias.kannenberg@googlemail.com&g= t;
Hi,

good to hear it worked for you!

Can you be more specific in what you now did and what xen-devel-thread
you followed?

2013/3/12 Guilherme Suzuki <suzu= ki.gui@gmail.com>:
> Dude, please forget my previou= s message!
>
> I followed that post from xen-devel string, applied the patch and ever= ything
> seems to be working just fine!
>
> That's really my case (newest kernel, old amd patch). I hope those= problems
> become part of the past from now on.
>
> You're are awesome! Thx a lot.
>
>
> 2013/3/12 Guilherme Suzuki <suzuki.gui@gmail.com>
>>
>> Matthias, I think you can help!
>>
>> I applied a similar patch to my xen (unstable, by the way) and all= that I
>> get is "parallel0 console" through VNC and the display s= eems dead (black
>> screen). This time I'm trying to "primary VGA passthru&qu= ot; it.
>>
>> But I noticed something: my VMs have been running with 8gb ram. I&= #39;ll try
>> to decrease that...
>>
>> I sort of gave up using my radeon 7950 as secondary, it will only = work
>> properly if I reboot dom0 as well.
>>
>> On Mar 12, 2013 4:48 PM, "Matthias" <matthias.kannenberg@googlemail.com>
>> wrote:
>>
>> Hi,
>>
>> after reading the thread I don't think it will help you cause = you got
>> other issues, but since i promised the patch and wrote it for anot= her
>> thread a minute ago anyway, here is the reference to it:
>>
>> http://lists.xen.org/archives/html/xen-users= /2013-03/msg00127.html
>>
>> :)
>
>
>
>
> --
> Grato,
>
> Guilherme Suzuki
> Consultor em TI para projetos Microsoft
> http://ww= w.guilhermesuzuki.com
> 11 - 992360535
> 11 - 20990757
>
>



--
Grato,
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex">Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=A0
--047d7bd76d9c665d3504d7c49265-- --===============8569968951166862887== 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 --===============8569968951166862887==-- From xen-users-bounces@lists.xen.org Wed Mar 13 01:47:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 01:47: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 1UFalr-0005YC-Sa; Wed, 13 Mar 2013 01:46:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFalp-0005Y7-Nj for xen-users@lists.xen.org; Wed, 13 Mar 2013 01:46:22 +0000 Received: from [85.158.139.211:44308] by server-6.bemta-5.messagelabs.com id 4D/F4-21466-C6ADF315; Wed, 13 Mar 2013 01:46:20 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1363139177!17592508!1 X-Originating-IP: [209.85.160.43] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9590 invoked from network); 13 Mar 2013 01:46:18 -0000 Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com) (209.85.160.43) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 01:46:18 -0000 Received: by mail-pb0-f43.google.com with SMTP id md12so468713pbc.30 for ; Tue, 12 Mar 2013 18:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1QD2cZiWAuVw426JvjaApRwyLCCnw8FN4zH2Glrg8oA=; b=JWTTbJK4M2LSwYSwt5ayBFBqNQT/aPbH0x46YE0FAE1eRP12dPChTi0LAYZDSAq+dg cRJfuzSRrWlNrmAHIf7aew89EF0fQJZy5aYCnzErJz7znsqMUJnTV0WrGjPCFoNfDu0m 6ogQ4sisQrRh+MjdT7x7UWeJyD8D2ukn3Va8+4HgxJG22J6bBqE5Z9zA5YxSDSMgZQg0 EatjDDYYeX3PyHhWDi02K0wKSsAl3pQi3Zkn1RwCzl1LV6nwvz8kUG7ZoXycG4Wq1lhY pnJ0+E2eDhy9K7OHJ7G12c41r6CXHkQLWmt9NBBodMBI5Z/hOoal/p4Hkv9xhf2JLer0 KACA== MIME-Version: 1.0 X-Received: by 10.68.198.34 with SMTP id iz2mr41325624pbc.148.1363139176538; Tue, 12 Mar 2013 18:46:16 -0700 (PDT) Received: by 10.68.57.105 with HTTP; Tue, 12 Mar 2013 18:46:16 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> Date: Tue, 12 Mar 2013 22:46:16 -0300 Message-ID: From: Guilherme Suzuki To: Matthias Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============8569968951166862887==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8569968951166862887== Content-Type: multipart/alternative; boundary=047d7bd76d9c665d3504d7c49265 --047d7bd76d9c665d3504d7c49265 Content-Type: text/plain; charset=ISO-8859-1 Alright, I really thought that things would work now just fine. It does, BUT I'm getting the famous *BSOD* now (after rebooting the *domU*). Now I can use my radeon as primary device or secondary as well (since dom0 is freshly booted) I followed this link straight: http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html I gitted xen-unstable-staging, applied xen-unstable-atipassthough.patch (the one attached to the link above) and then tried to passthru the VGA device. My kernel version is 3.8.1-201 (I had compiled xen modules into the kernel to use kernel parameters). 2013/3/12 Matthias > Hi, > > good to hear it worked for you! > > Can you be more specific in what you now did and what xen-devel-thread > you followed? > > 2013/3/12 Guilherme Suzuki : > > Dude, please forget my previous message! > > > > I followed that post from xen-devel string, applied the patch and > everything > > seems to be working just fine! > > > > That's really my case (newest kernel, old amd patch). I hope those > problems > > become part of the past from now on. > > > > You're are awesome! Thx a lot. > > > > > > 2013/3/12 Guilherme Suzuki > >> > >> Matthias, I think you can help! > >> > >> I applied a similar patch to my xen (unstable, by the way) and all that > I > >> get is "parallel0 console" through VNC and the display seems dead (black > >> screen). This time I'm trying to "primary VGA passthru" it. > >> > >> But I noticed something: my VMs have been running with 8gb ram. I'll try > >> to decrease that... > >> > >> I sort of gave up using my radeon 7950 as secondary, it will only work > >> properly if I reboot dom0 as well. > >> > >> On Mar 12, 2013 4:48 PM, "Matthias" > > >> wrote: > >> > >> Hi, > >> > >> after reading the thread I don't think it will help you cause you got > >> other issues, but since i promised the patch and wrote it for another > >> thread a minute ago anyway, here is the reference to it: > >> > >> http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html > >> > >> :) > > > > > > > > > > -- > > Grato, > > > > Guilherme Suzuki > > Consultor em TI para projetos Microsoft > > http://www.guilhermesuzuki.com > > 11 - 992360535 > > 11 - 20990757 > > > > > -- Grato, ** *Guilherme Suzuki* Consultor em TI para projetos Microsoft *http://www.guilhermesuzuki.com* 11 - 992360535 11 - 20990757 --047d7bd76d9c665d3504d7c49265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Alright, I really thought that things would work= now just fine. It does, BUT I'm getting the famous BSOD now (af= ter rebooting the domU). Now I can use my radeon as primary device o= r secondary as well (since dom0 is freshly booted)

I followed this link straight: http://lists.xen.org/archives/= html/xen-users/2013-03/msg00127.html

I gitted xen-unstable= -staging, applied xen-unstable-atipassthough.patch (the one attached to the= link above) and then tried to passthru the VGA device. My kernel version i= s 3.8.1-201 (I had compiled xen modules into the kernel to use kernel param= eters).



201= 3/3/12 Matthias <matthias.kannenberg@googlemail.com&g= t;
Hi,

good to hear it worked for you!

Can you be more specific in what you now did and what xen-devel-thread
you followed?

2013/3/12 Guilherme Suzuki <suzu= ki.gui@gmail.com>:
> Dude, please forget my previou= s message!
>
> I followed that post from xen-devel string, applied the patch and ever= ything
> seems to be working just fine!
>
> That's really my case (newest kernel, old amd patch). I hope those= problems
> become part of the past from now on.
>
> You're are awesome! Thx a lot.
>
>
> 2013/3/12 Guilherme Suzuki <suzuki.gui@gmail.com>
>>
>> Matthias, I think you can help!
>>
>> I applied a similar patch to my xen (unstable, by the way) and all= that I
>> get is "parallel0 console" through VNC and the display s= eems dead (black
>> screen). This time I'm trying to "primary VGA passthru&qu= ot; it.
>>
>> But I noticed something: my VMs have been running with 8gb ram. I&= #39;ll try
>> to decrease that...
>>
>> I sort of gave up using my radeon 7950 as secondary, it will only = work
>> properly if I reboot dom0 as well.
>>
>> On Mar 12, 2013 4:48 PM, "Matthias" <matthias.kannenberg@googlemail.com>
>> wrote:
>>
>> Hi,
>>
>> after reading the thread I don't think it will help you cause = you got
>> other issues, but since i promised the patch and wrote it for anot= her
>> thread a minute ago anyway, here is the reference to it:
>>
>> http://lists.xen.org/archives/html/xen-users= /2013-03/msg00127.html
>>
>> :)
>
>
>
>
> --
> Grato,
>
> Guilherme Suzuki
> Consultor em TI para projetos Microsoft
> http://ww= w.guilhermesuzuki.com
> 11 - 992360535
> 11 - 20990757
>
>



--
Grato,
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex">Guilherme Suzuki
Consultor em TI para projetos Microsoft
http://www.guilhermesuzuki.com
1= 1 - 992360535
11 - 20990757
=A0
--047d7bd76d9c665d3504d7c49265-- --===============8569968951166862887== 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 --===============8569968951166862887==-- From xen-users-bounces@lists.xen.org Wed Mar 13 09:15:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 09:15: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 1UFhli-0005xp-Jt; Wed, 13 Mar 2013 09:14:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFhlg-0005xk-UG for xen-users@lists.xensource.com; Wed, 13 Mar 2013 09:14:41 +0000 Received: from [85.158.139.83:23373] by server-4.bemta-5.messagelabs.com id F6/AA-01980-08340415; Wed, 13 Mar 2013 09:14:40 +0000 X-Env-Sender: kristoffer@itoc.dk X-Msg-Ref: server-8.tower-182.messagelabs.com!1363166076!17318427!1 X-Originating-IP: [77.66.16.14] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2628 invoked from network); 13 Mar 2013 09:14:36 -0000 Received: from mail01.itoc.dk (HELO hosting01.itoc.dk) (77.66.16.14) by server-8.tower-182.messagelabs.com with SMTP; 13 Mar 2013 09:14:36 -0000 Received: from localhost (hosting01.ultraslice.com [127.0.0.1]) by hosting01.itoc.dk (Postfix) with ESMTP id 3CB6C3C3FECB4 for ; Wed, 13 Mar 2013 10:14:35 +0100 (CET) Received: from hosting01.itoc.dk ([127.0.0.1]) by localhost (hosting01.itoc.dk [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 23924-05 for ; Wed, 13 Mar 2013 10:14:33 +0100 (CET) Received: from [10.0.1.42] (87-63-230-226-static.dk.customer.tdc.net [87.63.230.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristoffer@itoc.dk) by hosting01.itoc.dk (Postfix) with ESMTPSA id 4A7653C3FECA9 for ; Wed, 13 Mar 2013 10:14:33 +0100 (CET) From: Kristoffer Egefelt Message-Id: <3A03BB37-1863-4C1F-BCCF-7C857EB5804A@itoc.dk> Date: Wed, 13 Mar 2013 10:14:32 +0100 To: "xen-users@lists.xensource.com" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: Maia Mailguard 1.0.2 Subject: [Xen-users] SR-IOV vs nPAR X-BeenThere: xen-users@lists.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 Hi, (Already asked this on the intel wired forum: http://communities.intel.com/= message/185413#185413 but some of those questiones are XEN specific, which = might be why theres no response ;-) I have doubts if SR-IOV will provide the required features compared to nPAR. SR-IOV seems more flexible, but I'm not sure if performance and features ar= e the same as nPAR. Servers will be Dell M620 with either Intel X520 or Broadcom 57810, running= Linux kernel 3.8, XEN 4.2 and openvswitch 1.7 Tutorials like = http://wiki.xen.org/wiki/RHEL5_CentOS5_Xen_Intel_SR-IOV_NIC_Virtual_Functio= n_VF_PCI_Passthru_Tutorial does not mention if it's possible to run VFs in the dom0 for iSCSI and vswi= tch, or if it's necessary (for whatever reason) to run those networks on ph= ysical interfaces. I want to do something like this (if understand SR-IOV correctly): eth0: PF - not used eth1: VF - management (active/passive bond) eth2: VF - iSCSI eth3: VF - openvswitch (LACP bond) ethX: VF - passthrough to domU I'm quite sure this works with nPAR, but I'm not sure about SR-IOV: - QOS: SR-IOV allow only rate-limit interfaces while nPAR guarantees a mini= mum amount of bandwidth pr interface - is this correct that SR-IOV does not= allow bandwidth guarantees? - LACP apparently have problems http://www.intel.com/content/www/us/en/netw= ork-adapters/10-gigabit-network-adapters/config-qos-with-flexible-port-part= itioning.html - anybody have experience with this? - Can I use a VF as iSCSI HBA from dom0? - Anybody using DCB (datacenter bridging) with iSCSI in a SR-IOV environmen= t? - Is there any practical difference on PFs and VFs (speed, latency etc=85) = - reason to use/not use the PF ? Hope someone is able to help with some (or even all) of the above :-) Thanks Regards Kristoffer _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 09:15:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 09:15: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 1UFhli-0005xp-Jt; Wed, 13 Mar 2013 09:14:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFhlg-0005xk-UG for xen-users@lists.xensource.com; Wed, 13 Mar 2013 09:14:41 +0000 Received: from [85.158.139.83:23373] by server-4.bemta-5.messagelabs.com id F6/AA-01980-08340415; Wed, 13 Mar 2013 09:14:40 +0000 X-Env-Sender: kristoffer@itoc.dk X-Msg-Ref: server-8.tower-182.messagelabs.com!1363166076!17318427!1 X-Originating-IP: [77.66.16.14] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2628 invoked from network); 13 Mar 2013 09:14:36 -0000 Received: from mail01.itoc.dk (HELO hosting01.itoc.dk) (77.66.16.14) by server-8.tower-182.messagelabs.com with SMTP; 13 Mar 2013 09:14:36 -0000 Received: from localhost (hosting01.ultraslice.com [127.0.0.1]) by hosting01.itoc.dk (Postfix) with ESMTP id 3CB6C3C3FECB4 for ; Wed, 13 Mar 2013 10:14:35 +0100 (CET) Received: from hosting01.itoc.dk ([127.0.0.1]) by localhost (hosting01.itoc.dk [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 23924-05 for ; Wed, 13 Mar 2013 10:14:33 +0100 (CET) Received: from [10.0.1.42] (87-63-230-226-static.dk.customer.tdc.net [87.63.230.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristoffer@itoc.dk) by hosting01.itoc.dk (Postfix) with ESMTPSA id 4A7653C3FECA9 for ; Wed, 13 Mar 2013 10:14:33 +0100 (CET) From: Kristoffer Egefelt Message-Id: <3A03BB37-1863-4C1F-BCCF-7C857EB5804A@itoc.dk> Date: Wed, 13 Mar 2013 10:14:32 +0100 To: "xen-users@lists.xensource.com" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: Maia Mailguard 1.0.2 Subject: [Xen-users] SR-IOV vs nPAR X-BeenThere: xen-users@lists.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 Hi, (Already asked this on the intel wired forum: http://communities.intel.com/= message/185413#185413 but some of those questiones are XEN specific, which = might be why theres no response ;-) I have doubts if SR-IOV will provide the required features compared to nPAR. SR-IOV seems more flexible, but I'm not sure if performance and features ar= e the same as nPAR. Servers will be Dell M620 with either Intel X520 or Broadcom 57810, running= Linux kernel 3.8, XEN 4.2 and openvswitch 1.7 Tutorials like = http://wiki.xen.org/wiki/RHEL5_CentOS5_Xen_Intel_SR-IOV_NIC_Virtual_Functio= n_VF_PCI_Passthru_Tutorial does not mention if it's possible to run VFs in the dom0 for iSCSI and vswi= tch, or if it's necessary (for whatever reason) to run those networks on ph= ysical interfaces. I want to do something like this (if understand SR-IOV correctly): eth0: PF - not used eth1: VF - management (active/passive bond) eth2: VF - iSCSI eth3: VF - openvswitch (LACP bond) ethX: VF - passthrough to domU I'm quite sure this works with nPAR, but I'm not sure about SR-IOV: - QOS: SR-IOV allow only rate-limit interfaces while nPAR guarantees a mini= mum amount of bandwidth pr interface - is this correct that SR-IOV does not= allow bandwidth guarantees? - LACP apparently have problems http://www.intel.com/content/www/us/en/netw= ork-adapters/10-gigabit-network-adapters/config-qos-with-flexible-port-part= itioning.html - anybody have experience with this? - Can I use a VF as iSCSI HBA from dom0? - Anybody using DCB (datacenter bridging) with iSCSI in a SR-IOV environmen= t? - Is there any practical difference on PFs and VFs (speed, latency etc=85) = - reason to use/not use the PF ? Hope someone is able to help with some (or even all) of the above :-) Thanks Regards Kristoffer _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 09:51:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 09:51: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 1UFiKa-0007Ci-1X; Wed, 13 Mar 2013 09:50:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFiKY-0007CZ-EX for xen-users@lists.xen.org; Wed, 13 Mar 2013 09:50:42 +0000 Received: from [85.158.139.83:46378] by server-11.bemta-5.messagelabs.com id F9/2D-27486-1FB40415; Wed, 13 Mar 2013 09:50:41 +0000 X-Env-Sender: kate_mparmpop@hotmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1363168224!25901557!1 X-Originating-IP: [65.55.111.100] X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD, ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,MSGID_FROM_MTA_HEADER, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32725 invoked from network); 13 Mar 2013 09:50:24 -0000 Received: from blu0-omc2-s25.blu0.hotmail.com (HELO blu0-omc2-s25.blu0.hotmail.com) (65.55.111.100) by server-4.tower-182.messagelabs.com with SMTP; 13 Mar 2013 09:50:24 -0000 Received: from BLU0-SMTP434 ([65.55.111.73]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Mar 2013 02:50:24 -0700 X-EIP: [LfWBfLC3C6Nn4mRM7vZNIhvRqZmbaZsm] X-Originating-Email: [kate_mparmpop@hotmail.com] Message-ID: Received: from [146.50.75.189] ([146.50.75.189]) by BLU0-SMTP434.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Mar 2013 02:50:22 -0700 Date: Wed, 13 Mar 2013 10:50:20 +0100 From: Katerina Mparmpopoulou User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Enigmail-Version: 1.5.1 X-OriginalArrivalTime: 13 Mar 2013 09:50:22.0358 (UTC) FILETIME=[2DDF2360:01CE1FD0] Subject: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I use xen 4.2.1 and i'm trying to do live migration without ssh. I read at the manual page of xl that if i place the option -s empty the command is running as run , instead of ssh . I 've used the command with the following alternatives: - - sudo xl migrate VM3 root@ip -s - - sudo xl migrate VM3 root@ip -s '' the problem is that in the same time i run tcpdump (filtering the particular interface/port 22/and the target host) and i can see the ssh packets, even the -s option is empty (no parameters). my question is: How can I disable ssh???? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQEvWAAoJEIrShLVVnSKrp94H/3dqno4IolDeyvXDLJh9JAVX jUR+/xBSpuH49N9dKxczOc89SWjPHNhZ58lvUlvZMm/NiPrRGmm+oR2nLg5YTue+ A5GzX4X23v2P6lDNHYiCREIULzjKvZEMrT8MwmUy/+AGl3NZ0tw+uwgdctWd2kqK eSiKqCErDTbjK73D74Mxrt4NWwSTOcGaBBZleqGOlQtIUIvlkBT+7OzsNqAlC8Ar j+TN9TRmiYPJBC3IHLBW2ZrDs+9sxXAVwL2braJSY4sV1sXEfI17Z4fl48ubWOX0 4fh+Xg6esKK9Jy6LsMEJCEzvbpPEWyb0ukqeYDD3pFf2cTVKFQfN5fZxEH0QP9E= =XrqQ -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 09:51:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 09:51: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 1UFiKa-0007Ci-1X; Wed, 13 Mar 2013 09:50:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFiKY-0007CZ-EX for xen-users@lists.xen.org; Wed, 13 Mar 2013 09:50:42 +0000 Received: from [85.158.139.83:46378] by server-11.bemta-5.messagelabs.com id F9/2D-27486-1FB40415; Wed, 13 Mar 2013 09:50:41 +0000 X-Env-Sender: kate_mparmpop@hotmail.com X-Msg-Ref: server-4.tower-182.messagelabs.com!1363168224!25901557!1 X-Originating-IP: [65.55.111.100] X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD, ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,MSGID_FROM_MTA_HEADER, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32725 invoked from network); 13 Mar 2013 09:50:24 -0000 Received: from blu0-omc2-s25.blu0.hotmail.com (HELO blu0-omc2-s25.blu0.hotmail.com) (65.55.111.100) by server-4.tower-182.messagelabs.com with SMTP; 13 Mar 2013 09:50:24 -0000 Received: from BLU0-SMTP434 ([65.55.111.73]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Mar 2013 02:50:24 -0700 X-EIP: [LfWBfLC3C6Nn4mRM7vZNIhvRqZmbaZsm] X-Originating-Email: [kate_mparmpop@hotmail.com] Message-ID: Received: from [146.50.75.189] ([146.50.75.189]) by BLU0-SMTP434.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Mar 2013 02:50:22 -0700 Date: Wed, 13 Mar 2013 10:50:20 +0100 From: Katerina Mparmpopoulou User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Enigmail-Version: 1.5.1 X-OriginalArrivalTime: 13 Mar 2013 09:50:22.0358 (UTC) FILETIME=[2DDF2360:01CE1FD0] Subject: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I use xen 4.2.1 and i'm trying to do live migration without ssh. I read at the manual page of xl that if i place the option -s empty the command is running as run , instead of ssh . I 've used the command with the following alternatives: - - sudo xl migrate VM3 root@ip -s - - sudo xl migrate VM3 root@ip -s '' the problem is that in the same time i run tcpdump (filtering the particular interface/port 22/and the target host) and i can see the ssh packets, even the -s option is empty (no parameters). my question is: How can I disable ssh???? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQEvWAAoJEIrShLVVnSKrp94H/3dqno4IolDeyvXDLJh9JAVX jUR+/xBSpuH49N9dKxczOc89SWjPHNhZ58lvUlvZMm/NiPrRGmm+oR2nLg5YTue+ A5GzX4X23v2P6lDNHYiCREIULzjKvZEMrT8MwmUy/+AGl3NZ0tw+uwgdctWd2kqK eSiKqCErDTbjK73D74Mxrt4NWwSTOcGaBBZleqGOlQtIUIvlkBT+7OzsNqAlC8Ar j+TN9TRmiYPJBC3IHLBW2ZrDs+9sxXAVwL2braJSY4sV1sXEfI17Z4fl48ubWOX0 4fh+Xg6esKK9Jy6LsMEJCEzvbpPEWyb0ukqeYDD3pFf2cTVKFQfN5fZxEH0QP9E= =XrqQ -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 10:38:31 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 10: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 1UFj3x-00017G-Mp; Wed, 13 Mar 2013 10:37:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFj3w-000177-Eh for xen-users@lists.xen.org; Wed, 13 Mar 2013 10:37:36 +0000 Received: from [193.109.254.147:22612] by server-9.bemta-14.messagelabs.com id 4D/83-04223-FE650415; Wed, 13 Mar 2013 10:37:35 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1363171054!1851511!1 X-Originating-IP: [209.85.214.46] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6948 invoked from network); 13 Mar 2013 10:37:35 -0000 Received: from mail-bk0-f46.google.com (HELO mail-bk0-f46.google.com) (209.85.214.46) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 10:37:35 -0000 Received: by mail-bk0-f46.google.com with SMTP id j5so365417bkw.5 for ; Wed, 13 Mar 2013 03:37:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=v/dY6L1N2yuYWRPaQppf2t1RFZMq0SHXUj0WGhSQXLM=; b=MVU9QTIWwF2zPtEVwyYOhSPd3GgT3ydtN6mOwKza/O1XrtQcNRSCWYOMnDAGdoDk8O 03nz/7L988NAhYXb3pifYdssx9Af73Mkp8NYr13nogNiRUs8btuYe84Nd/kN3mZnYTRr 3tAr6Dl0J0/vO00p4RG9Ycqn00bVDxF30wyDUjsYg54q4UuG3xsaeQ8qWZNOwFAu7f2t 75M4GPMFr5Uehv28LibUHSjuajwrogh0s9h3MYVraWur47Wparb6dCrQPVz3AsOCGAkt YiaX4mc+w31OOX53TdY4rBEDY9US1JEgX+RQegcpq+bNorqn+mRrfvmW+Ew5JwlwyZ9M 9Ecg== MIME-Version: 1.0 X-Received: by 10.205.119.19 with SMTP id fs19mr7393176bkc.105.1363171053952; Wed, 13 Mar 2013 03:37:33 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Wed, 13 Mar 2013 03:37:33 -0700 (PDT) In-Reply-To: <1363106975.32410.55.camel@zakaz.uk.xensource.com> References: <1363106975.32410.55.camel@zakaz.uk.xensource.com> Date: Wed, 13 Mar 2013 11:37:33 +0100 Message-ID: From: Sylvain Munaut To: Ian Campbell X-Gm-Message-State: ALoCoQk32/u1d+XvvjB67vgdxNMOHohgwXpLBHDjhpXGLgpC/sVB4mSsxRSGuUH5B+K1cgcFx79Q Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Code path for Gratuitous ARP in live migration X-BeenThere: xen-users@lists.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, > Yes, because devices are reconnected after the migration, which triggers > that path. Thanks. I've now confirmed the gratuitous ARP is properly sent. I can see it in a tcpdump on the VM itself, and using tcpdump -i any on the dom0. However I never see it on the network itself, nor on the dom0 on the bridge interface. So either something is blocking it somewhere (bridge code or iptables), it it's sent before the VIF is attached to the bridge. Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 10:38:31 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 10: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 1UFj3x-00017G-Mp; Wed, 13 Mar 2013 10:37:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFj3w-000177-Eh for xen-users@lists.xen.org; Wed, 13 Mar 2013 10:37:36 +0000 Received: from [193.109.254.147:22612] by server-9.bemta-14.messagelabs.com id 4D/83-04223-FE650415; Wed, 13 Mar 2013 10:37:35 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1363171054!1851511!1 X-Originating-IP: [209.85.214.46] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6948 invoked from network); 13 Mar 2013 10:37:35 -0000 Received: from mail-bk0-f46.google.com (HELO mail-bk0-f46.google.com) (209.85.214.46) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 10:37:35 -0000 Received: by mail-bk0-f46.google.com with SMTP id j5so365417bkw.5 for ; Wed, 13 Mar 2013 03:37:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=v/dY6L1N2yuYWRPaQppf2t1RFZMq0SHXUj0WGhSQXLM=; b=MVU9QTIWwF2zPtEVwyYOhSPd3GgT3ydtN6mOwKza/O1XrtQcNRSCWYOMnDAGdoDk8O 03nz/7L988NAhYXb3pifYdssx9Af73Mkp8NYr13nogNiRUs8btuYe84Nd/kN3mZnYTRr 3tAr6Dl0J0/vO00p4RG9Ycqn00bVDxF30wyDUjsYg54q4UuG3xsaeQ8qWZNOwFAu7f2t 75M4GPMFr5Uehv28LibUHSjuajwrogh0s9h3MYVraWur47Wparb6dCrQPVz3AsOCGAkt YiaX4mc+w31OOX53TdY4rBEDY9US1JEgX+RQegcpq+bNorqn+mRrfvmW+Ew5JwlwyZ9M 9Ecg== MIME-Version: 1.0 X-Received: by 10.205.119.19 with SMTP id fs19mr7393176bkc.105.1363171053952; Wed, 13 Mar 2013 03:37:33 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Wed, 13 Mar 2013 03:37:33 -0700 (PDT) In-Reply-To: <1363106975.32410.55.camel@zakaz.uk.xensource.com> References: <1363106975.32410.55.camel@zakaz.uk.xensource.com> Date: Wed, 13 Mar 2013 11:37:33 +0100 Message-ID: From: Sylvain Munaut To: Ian Campbell X-Gm-Message-State: ALoCoQk32/u1d+XvvjB67vgdxNMOHohgwXpLBHDjhpXGLgpC/sVB4mSsxRSGuUH5B+K1cgcFx79Q Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Code path for Gratuitous ARP in live migration X-BeenThere: xen-users@lists.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, > Yes, because devices are reconnected after the migration, which triggers > that path. Thanks. I've now confirmed the gratuitous ARP is properly sent. I can see it in a tcpdump on the VM itself, and using tcpdump -i any on the dom0. However I never see it on the network itself, nor on the dom0 on the bridge interface. So either something is blocking it somewhere (bridge code or iptables), it it's sent before the VIF is attached to the bridge. Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 10:43:16 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 10:43: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 1UFj8b-0001jQ-Dr; Wed, 13 Mar 2013 10:42:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFj8a-0001jB-6b for xen-users@lists.xen.org; Wed, 13 Mar 2013 10:42:24 +0000 Received: from [85.158.139.83:15180] by server-11.bemta-5.messagelabs.com id 38/3D-27486-F0850415; Wed, 13 Mar 2013 10:42:23 +0000 X-Env-Sender: mailinglists@websitemanagers.com.au X-Msg-Ref: server-11.tower-182.messagelabs.com!1363171328!21416428!1 X-Originating-IP: [203.98.89.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30511 invoked from network); 13 Mar 2013 10:42:11 -0000 Received: from hammer.websitemanagers.com.au (HELO hammer.websitemanagers.com.au) (203.98.89.10) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Mar 2013 10:42:11 -0000 Received: (qmail 31004 invoked by uid 1011); 13 Mar 2013 10:42:05 -0000 Received: from 124.246.8.196 by hammer (envelope-from , uid 1008) with qmail-scanner-1.24 (clamdscan: 0.97.6/16836. spamassassin: 3.3.1. Clear:RC:1(124.246.8.196):. Processed in 0.055856 secs); 13 Mar 2013 10:42:05 -0000 Received: from unknown (HELO ?192.168.2.90?) (124.246.8.196) by 0 with SMTP; 13 Mar 2013 10:42:05 -0000 Message-ID: <514057FD.4000004@websitemanagers.com.au> Date: Wed, 13 Mar 2013 21:42:05 +1100 From: Adam Goryachev Organization: Website Managers User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: Subject: Re: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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 13/03/13 00:05, Sean Greenslade wrote: > On Mon, Mar 11, 2013 at 11:25 AM, jacek burghardt > wrote: >> What is the best open sourced free tool that will synchronize local lvms to >> iscsi and allow fail over to iscsi targets. > I (personally) have never seen such a tool, free or commercial. I > don't know if it's even possible to have a failover block device > (devs, feel free to shed some more educated light on this). In most > cases, having block devices fail is rather rare, and is not an event > that most systems can recover from gracefully. Failover systems > usually involve hot-spare servers, where the file systems are either > common or synced in some manner. > > I suppose you _could_ set up a mirrored LVM volume with your local > disk and your iSCSI target as PVs, but I don't think I would recommend > that. Instead, I would take a second look at your architecture. If you > have an iSCSI system in place, it would be better to build RAID / LVM > mirroring into the iSCSI unit. Let your storage system deal with > storage availability. One method to do what I think you are asking is: You have two storage servers and one or more xen hosts. Each storage server will have a local block device of the same size as the other (could be hardware raid, md raid, or plain disks) Use DRBD to keep the two block devices in sync (similar to RAID1 between different boxes), use dual primary mode. Use LVM to divide up the space on the block device as required. Use ietd (iscsi) to export the LV's On one or more xen hosts, use iscsi-target to connect to the LV's, each LV will be presented as a block device /dev/sdX Now use multipath to connect to both hosts, but use failover mode such that you won't use the second target unless the primary fails. I think this should provide a pretty good solution.... Would be nice to hear if you do this and how it works out...... Regards, Adam -- 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 Wed Mar 13 10:43:16 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 10:43: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 1UFj8b-0001jQ-Dr; Wed, 13 Mar 2013 10:42:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFj8a-0001jB-6b for xen-users@lists.xen.org; Wed, 13 Mar 2013 10:42:24 +0000 Received: from [85.158.139.83:15180] by server-11.bemta-5.messagelabs.com id 38/3D-27486-F0850415; Wed, 13 Mar 2013 10:42:23 +0000 X-Env-Sender: mailinglists@websitemanagers.com.au X-Msg-Ref: server-11.tower-182.messagelabs.com!1363171328!21416428!1 X-Originating-IP: [203.98.89.10] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30511 invoked from network); 13 Mar 2013 10:42:11 -0000 Received: from hammer.websitemanagers.com.au (HELO hammer.websitemanagers.com.au) (203.98.89.10) by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Mar 2013 10:42:11 -0000 Received: (qmail 31004 invoked by uid 1011); 13 Mar 2013 10:42:05 -0000 Received: from 124.246.8.196 by hammer (envelope-from , uid 1008) with qmail-scanner-1.24 (clamdscan: 0.97.6/16836. spamassassin: 3.3.1. Clear:RC:1(124.246.8.196):. Processed in 0.055856 secs); 13 Mar 2013 10:42:05 -0000 Received: from unknown (HELO ?192.168.2.90?) (124.246.8.196) by 0 with SMTP; 13 Mar 2013 10:42:05 -0000 Message-ID: <514057FD.4000004@websitemanagers.com.au> Date: Wed, 13 Mar 2013 21:42:05 +1100 From: Adam Goryachev Organization: Website Managers User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: Subject: Re: [Xen-users] Zen backup and failover X-BeenThere: xen-users@lists.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 13/03/13 00:05, Sean Greenslade wrote: > On Mon, Mar 11, 2013 at 11:25 AM, jacek burghardt > wrote: >> What is the best open sourced free tool that will synchronize local lvms to >> iscsi and allow fail over to iscsi targets. > I (personally) have never seen such a tool, free or commercial. I > don't know if it's even possible to have a failover block device > (devs, feel free to shed some more educated light on this). In most > cases, having block devices fail is rather rare, and is not an event > that most systems can recover from gracefully. Failover systems > usually involve hot-spare servers, where the file systems are either > common or synced in some manner. > > I suppose you _could_ set up a mirrored LVM volume with your local > disk and your iSCSI target as PVs, but I don't think I would recommend > that. Instead, I would take a second look at your architecture. If you > have an iSCSI system in place, it would be better to build RAID / LVM > mirroring into the iSCSI unit. Let your storage system deal with > storage availability. One method to do what I think you are asking is: You have two storage servers and one or more xen hosts. Each storage server will have a local block device of the same size as the other (could be hardware raid, md raid, or plain disks) Use DRBD to keep the two block devices in sync (similar to RAID1 between different boxes), use dual primary mode. Use LVM to divide up the space on the block device as required. Use ietd (iscsi) to export the LV's On one or more xen hosts, use iscsi-target to connect to the LV's, each LV will be presented as a block device /dev/sdX Now use multipath to connect to both hosts, but use failover mode such that you won't use the second target unless the primary fails. I think this should provide a pretty good solution.... Would be nice to hear if you do this and how it works out...... Regards, Adam -- 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 Wed Mar 13 12:16:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 12:16: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 1UFkZY-0005nh-UZ; Wed, 13 Mar 2013 12:14:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFkZX-0005na-Qu for xen-users@lists.xen.org; Wed, 13 Mar 2013 12:14:20 +0000 Received: from [85.158.137.99:49873] by server-4.bemta-3.messagelabs.com id 90/52-21470-A9D60415; Wed, 13 Mar 2013 12:14:18 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-14.tower-217.messagelabs.com!1363176856!18125132!1 X-Originating-IP: [209.85.212.174] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27486 invoked from network); 13 Mar 2013 12:14:16 -0000 Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 12:14:16 -0000 Received: by mail-wi0-f174.google.com with SMTP id hi8so2682434wib.7 for ; Wed, 13 Mar 2013 05:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ISuGiSx5vij+A3rUbf1PnFxOKFT2xwdJohzCPoJjEZY=; b=UcMcWd7leq0fecWXc0w0SCQYGJ1nbGw3DHc2PtnSxJ9K2BiCE9IgsNslkQxo8QKKUs Ww0oYMiydK9dp++QXuUqjd4hau21gB6nHYfKhNxZqWljCf5PHChCLrYR28noehzrgrDF tu9JIikNXddx90mmr4K+reaS5wR4IGiuLMd43rNXCVUO+O0kEllLaBuRWWunHvk9x3MC wz6eLCAZDSHaE8rb6u1KKiTfJfRmvFTf0c6Oj9YHl9bqCB3RsERYy6kZ9FiLC8WXbRp8 dcvGJox2qObupmII5eeb2exKXeJrCxBQs9A70M17sv6KR6JlhWcYOzKDDPjuSVO/ZfQz zInQ== MIME-Version: 1.0 X-Received: by 10.194.63.240 with SMTP id j16mr33460788wjs.45.1363176856604; Wed, 13 Mar 2013 05:14:16 -0700 (PDT) Received: by 10.216.208.143 with HTTP; Wed, 13 Mar 2013 05:14:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 13:14:16 +0100 Message-ID: From: agya naila To: Aaron Cossey Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============5043697546429903110==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5043697546429903110== Content-Type: multipart/alternative; boundary=047d7ba97b724dd43f04d7cd5831 --047d7ba97b724dd43f04d7cd5831 Content-Type: text/plain; charset=ISO-8859-1 I am not sure its due to high load in my case since there is still no high load in server. I didn't run any program that have high load and no client that accessing this server. I am suspecting the hotplug script. In my xend.log here is the logs : server1@server1:~$ sudo tail /var/log/xen/xend.log [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status. [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status. [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices irq. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vfb. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices pci. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vusb. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vtpm. [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain DomU (4) unpaused. any hints ? regards, Agya On Wed, Mar 6, 2013 at 4:12 PM, Aaron Cossey wrote: > I've encountered this frequently due to high io load. If you have > monitoring of load and io, did you see anything happen just before these > errors started in the logs? > > Aaron Cossey > aaron.cossey@gmail.com > > > On Wed, Mar 6, 2013 at 1:35 PM, agya naila wrote: > >> Hi all, >> >> Today I got problem below and my domU become unresponsive and I should >> restart the pc to make it running properly again. >> >> [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 seconds. >> [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 >> seconds. >> [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 >> seconds. >> [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 >> seconds. >> [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 >> seconds. >> [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 >> seconds. >> [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 >> seconds. >> [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 >> seconds. >> [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 >> seconds. >> [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> >> Does any body have clue regarding this problem? >> >> Regards, >> >> Agya >> >> _______________________________________________ >> 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 > --047d7ba97b724dd43f04d7cd5831 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure its due to high load in my case since there is still no high = load in server. I didn't run any program that have high load and no cli= ent that accessing this server. I am suspecting the hotplug script. In my x= end.log here is the logs :

server1@server1:~$ sudo tail /var/log/xen/xend.log
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 5171= 2.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugSt= atusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03= -13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es irq.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wai= ting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomai= n:1225) Domain DomU (4) unpaused.

any hints ?

regards,

Agya=


On Wed, Mar 6, 201= 3 at 4:12 PM, Aaron Cossey <aaron.cossey@gmail.com> wro= te:
I've=A0encountered=A0this frequently due to high io lo= ad. If you have monitoring of load and io, did you see anything happen just= before these errors started in the logs?
<= br clear=3D"all">

On Wed, Mar 6, 2013 at 1:35 PM= , agya naila <agya.naila@gmail.com> wrote:
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

--047d7ba97b724dd43f04d7cd5831-- --===============5043697546429903110== 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 --===============5043697546429903110==-- From xen-users-bounces@lists.xen.org Wed Mar 13 12:16:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 12:16: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 1UFkZY-0005nh-UZ; Wed, 13 Mar 2013 12:14:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFkZX-0005na-Qu for xen-users@lists.xen.org; Wed, 13 Mar 2013 12:14:20 +0000 Received: from [85.158.137.99:49873] by server-4.bemta-3.messagelabs.com id 90/52-21470-A9D60415; Wed, 13 Mar 2013 12:14:18 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-14.tower-217.messagelabs.com!1363176856!18125132!1 X-Originating-IP: [209.85.212.174] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27486 invoked from network); 13 Mar 2013 12:14:16 -0000 Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 12:14:16 -0000 Received: by mail-wi0-f174.google.com with SMTP id hi8so2682434wib.7 for ; Wed, 13 Mar 2013 05:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ISuGiSx5vij+A3rUbf1PnFxOKFT2xwdJohzCPoJjEZY=; b=UcMcWd7leq0fecWXc0w0SCQYGJ1nbGw3DHc2PtnSxJ9K2BiCE9IgsNslkQxo8QKKUs Ww0oYMiydK9dp++QXuUqjd4hau21gB6nHYfKhNxZqWljCf5PHChCLrYR28noehzrgrDF tu9JIikNXddx90mmr4K+reaS5wR4IGiuLMd43rNXCVUO+O0kEllLaBuRWWunHvk9x3MC wz6eLCAZDSHaE8rb6u1KKiTfJfRmvFTf0c6Oj9YHl9bqCB3RsERYy6kZ9FiLC8WXbRp8 dcvGJox2qObupmII5eeb2exKXeJrCxBQs9A70M17sv6KR6JlhWcYOzKDDPjuSVO/ZfQz zInQ== MIME-Version: 1.0 X-Received: by 10.194.63.240 with SMTP id j16mr33460788wjs.45.1363176856604; Wed, 13 Mar 2013 05:14:16 -0700 (PDT) Received: by 10.216.208.143 with HTTP; Wed, 13 Mar 2013 05:14:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 13:14:16 +0100 Message-ID: From: agya naila To: Aaron Cossey Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============5043697546429903110==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5043697546429903110== Content-Type: multipart/alternative; boundary=047d7ba97b724dd43f04d7cd5831 --047d7ba97b724dd43f04d7cd5831 Content-Type: text/plain; charset=ISO-8859-1 I am not sure its due to high load in my case since there is still no high load in server. I didn't run any program that have high load and no client that accessing this server. I am suspecting the hotplug script. In my xend.log here is the logs : server1@server1:~$ sudo tail /var/log/xen/xend.log [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status. [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status. [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices irq. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vfb. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices pci. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vusb. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vtpm. [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain DomU (4) unpaused. any hints ? regards, Agya On Wed, Mar 6, 2013 at 4:12 PM, Aaron Cossey wrote: > I've encountered this frequently due to high io load. If you have > monitoring of load and io, did you see anything happen just before these > errors started in the logs? > > Aaron Cossey > aaron.cossey@gmail.com > > > On Wed, Mar 6, 2013 at 1:35 PM, agya naila wrote: > >> Hi all, >> >> Today I got problem below and my domU become unresponsive and I should >> restart the pc to make it running properly again. >> >> [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 seconds. >> [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 >> seconds. >> [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 >> seconds. >> [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 >> seconds. >> [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 >> seconds. >> [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 >> seconds. >> [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 >> seconds. >> [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 >> seconds. >> [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 >> seconds. >> [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >> disables this message. >> >> Does any body have clue regarding this problem? >> >> Regards, >> >> Agya >> >> _______________________________________________ >> 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 > --047d7ba97b724dd43f04d7cd5831 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure its due to high load in my case since there is still no high = load in server. I didn't run any program that have high load and no cli= ent that accessing this server. I am suspecting the hotplug script. In my x= end.log here is the logs :

server1@server1:~$ sudo tail /var/log/xen/xend.log
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 5171= 2.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugSt= atusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03= -13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es irq.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wai= ting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomai= n:1225) Domain DomU (4) unpaused.

any hints ?

regards,

Agya=


On Wed, Mar 6, 201= 3 at 4:12 PM, Aaron Cossey <aaron.cossey@gmail.com> wro= te:
I've=A0encountered=A0this frequently due to high io lo= ad. If you have monitoring of load and io, did you see anything happen just= before these errors started in the logs?
<= br clear=3D"all">

On Wed, Mar 6, 2013 at 1:35 PM= , agya naila <agya.naila@gmail.com> wrote:
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

--047d7ba97b724dd43f04d7cd5831-- --===============5043697546429903110== 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 --===============5043697546429903110==-- From xen-users-bounces@lists.xen.org Wed Mar 13 12:35:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 12:35: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 1UFktT-0006Lr-C7; Wed, 13 Mar 2013 12:34:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFktQ-0006Lm-7x for xen-users@lists.xen.org; Wed, 13 Mar 2013 12:34:53 +0000 Received: from [193.109.254.147:43728] by server-14.bemta-14.messagelabs.com id D9/4E-05867-B6270415; Wed, 13 Mar 2013 12:34:51 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1363178088!8720703!1 X-Originating-IP: [74.125.82.181] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14681 invoked from network); 13 Mar 2013 12:34:48 -0000 Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com) (74.125.82.181) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 12:34:48 -0000 Received: by mail-we0-f181.google.com with SMTP id t44so905911wey.26 for ; Wed, 13 Mar 2013 05:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OdynlXAD3t/RXzzYynUhQnLrOzUhQiiUstQtQ8ZQeqA=; b=QHUkkyBCMz3g0UKivuo2yF+maDBzE3+tIZ5J1D0Taz3qQae1f7bPLJRTlv1bKhefcV FhBISzlgdL/dCRBAtzIJaAZhBBfkOlnYjHBqQ5rDeI6mPVu8TB+Opkh3xdGyHRcfzgiL /fRRmu+vXB5QfeudvMiY7j5vIze9o0KJldL6vARichDalStk7OfTQxN3QklvJWDZZ+er xbiznjHelehiNLa1EOPf73AVnvHB28KwN+7SchOugMN0yoYT0vNOxJmpQKZ4dNMQ4Cwc jwPTSMFCf835vP1vPSs9duX1VKr3kH2MJFc6zT8U5aV3Nv3BNftT5z90HJpO1XS9i02g sxYg== MIME-Version: 1.0 X-Received: by 10.194.109.136 with SMTP id hs8mr33846214wjb.8.1363178088114; Wed, 13 Mar 2013 05:34:48 -0700 (PDT) Received: by 10.216.208.143 with HTTP; Wed, 13 Mar 2013 05:34:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 13:34:48 +0100 Message-ID: From: agya naila To: Aaron Cossey Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============8859112764883900801==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8859112764883900801== Content-Type: multipart/alternative; boundary=089e0102e172b52f8504d7cda1e1 --089e0102e172b52f8504d7cda1e1 Content-Type: text/plain; charset=ISO-8859-1 Here more details of my machine log : [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.destroy: domid=3 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.handleShutdownWatch [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.handleShutdownWatch [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.handleShutdownWatch [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2402) Destroying device model [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing console/0 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = console, device = c$ [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2407) No device model [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:2499) XendDomainInfo.constructDomain [2013-03-13 13:04:46 1983] DEBUG (balloon:187) Balloon: 2058876 KiB free; need 16384; done. [2013-03-13 13:04:47 1983] DEBUG (XendDomain:476) Adding Domain: 4 [2013-03-13 13:04:47 1983] DEBUG (XendDomainInfo:2842) XendDomainInfo.initDomain: 4 256 [2013-03-13 13:04:47 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm on /dev/xvdp. [2013-03-13 13:04:47 1983] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'virtual-device': '5195$ [2013-03-13 13:04:47 1983] DEBUG (DevController:97) DevController: writing {'domain': 'Domain-0', 'frontend': '/local/$ [2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting for 51952. [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$ [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$ [2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting for 51952. [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$ [2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:47 4725] DEBUG (XendBootloader:113) Launching bootloader as ['/usr/bin/pygrub', '--output=/var/run/x$ [2013-03-13 13:04:49 1983] INFO (XendDomainInfo:3295) Unmounting /dev/xvdp from /dev/xvdp. [2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = /dev/$ [2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:2869) _initDomain:shadow_memory=0x0, memory_static_max=0x40000000, me$ [2013-03-13 13:04:49 1983] INFO (image:182) buildDomain os=linux dom=4 vcpus=1 [2013-03-13 13:04:49 1983] DEBUG (image:721) domid = 4 [2013-03-13 13:04:49 1983] DEBUG (image:722) memsize = 1024 [2013-03-13 13:04:49 1983] DEBUG (image:723) image = /var/run/xend/boot/boot_kernel.bWctVs [2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn = 1 [2013-03-13 13:04:49 1983] DEBUG (image:723) image = /var/run/xend/boot/boot_kernel.bWctVs [2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn = 1 [2013-03-13 13:04:49 1983] DEBUG (image:725) console_evtchn = 2 [2013-03-13 13:04:49 1983] DEBUG (image:726) cmdline = root=UUID=f76e1730-ef98-43f3-ae37-caaff1dbe5c1 ro consol$ [2013-03-13 13:04:49 1983] DEBUG (image:727) ramdisk = /var/run/xend/boot/boot_ramdisk.GF_u4x [2013-03-13 13:04:49 1983] DEBUG (image:728) vcpus = 1 [2013-03-13 13:04:49 1983] DEBUG (image:729) features = [2013-03-13 13:04:49 1983] DEBUG (image:730) flags = 0 [2013-03-13 13:04:49 1983] DEBUG (image:731) superpages = 0 [2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vbd : {'uuid': '2601a8a4-f53c-e392-44b7-4d79ecb6bf$ [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {'virtual-device': '51712', 'device-type': $ [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing {'domain': 'Sb-Voip1-DomU', 'frontend': '/l$ [2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vif : {'ip': '192.168.129.55', 'mac': '00:16:3e:35$ [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {'mac': '00:16:3e:35:82:be', 'handle': '0',$ [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing {'bridge': 'xenbr0', 'domain': 'Sb-Voip1-Do$ [2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:3426) Storing VM details: {'on_xend_stop': 'ignore', 'pool_name': 'Po$ [2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:1795) Storing domain details: {'console/ring-ref': '270105', 'image/e$ [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {'protocol': 'x86_64-abi', 'state': '1', 'b$ [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing {'domain': 'Sb-Voip1-DomU', 'frontend': '/l$ [2013-03-13 13:04:51 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.handleShutdownWatch [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices tap2. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vif. [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0. [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/4/0/hotplug-sta$ [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/4/0/hotplug-sta$ [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/4/0/hotplug-sta$ [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/4/0/hotplug-sta$ [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vkbd. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices ioports. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices tap. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vif2. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices console. [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vscsi. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vbd. [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug$ [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug$ [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices irq. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vfb. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices pci. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vusb. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vtpm. [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain Sb-Voip1-DomU (4) unpaused. [2013-03-13 13:20:31 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.destroy: domid=4 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2402) Destroying device model [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing console/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = console, device = c$ [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2407) No device model [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2499) XendDomainInfo.constructDomain [2013-03-13 13:23:03 1983] DEBUG (balloon:187) Balloon: 2058700 KiB free; need 16384; done. [2013-03-13 13:23:03 1983] DEBUG (XendDomain:476) Adding Domain: 5 [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2842) XendDomainInfo.initDomain: 5 256 [2013-03-13 13:23:03 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm on /dev/xvdp. [2013-03-13 13:23:03 1983] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'virtual-device': '5195$ [2013-03-13 13:23:03 1983] DEBUG (DevController:97) DevController: writing {'domain': 'Domain-0', 'frontend': '/local/$ [2013-03-13 13:23:03 1983] DEBUG (DevController:144) Waiting for 51952. [2013-03-13 13:23:03 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$ [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be connected. Hotplug scripts not $ Traceback (most recent call last): [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be connected. Hotplug scripts not $ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3989, in create_vbd self._waitForDevice(dev_type, devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice return self.getDeviceController(deviceClass).waitForDevice(devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 155, in waitForDevice (devid, self.deviceClass)) VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not working. [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:488) VM start failed Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2844, in _initDomain self._configureBootloader() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3285, in _configureBootloader mounted_vbd_uuid = dom0.create_vbd(vbd, disk); File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3989, in create_vbd self._waitForDevice(dev_type, devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice return self.getDeviceController(deviceClass).waitForDevice(devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 155, in waitForDevice (devid, self.deviceClass)) File "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 155, in waitForDevice (devid, self.deviceClass)) VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not working. [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.destroy: domid=5 [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:2407) No device model [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:108) Domain construction failed Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 106, in create vm.start() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2844, in _initDomain self._configureBootloader() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3285, in _configureBootloader mounted_vbd_uuid = dom0.create_vbd(vbd, disk); File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3989, in create_vbd self._waitForDevice(dev_type, devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice return self.getDeviceController(deviceClass).waitForDevice(devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 155, in waitForDevice (devid, self.deviceClass)) VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not working. (devid, self.deviceClass)) VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not working. Regards, Agya On Wed, Mar 13, 2013 at 1:14 PM, agya naila wrote: > I am not sure its due to high load in my case since there is still no high > load in server. I didn't run any program that have high load and no client > that accessing this server. I am suspecting the hotplug script. In my > xend.log here is the logs : > > server1@server1:~$ sudo tail /var/log/xen/xend.log > [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/4/51712/hotplug-status. > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/4/51712/hotplug-status. > [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > irq. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vfb. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > pci. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vusb. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vtpm. > [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain DomU (4) unpaused. > > any hints ? > > regards, > > Agya > > > On Wed, Mar 6, 2013 at 4:12 PM, Aaron Cossey wrote: > >> I've encountered this frequently due to high io load. If you have >> monitoring of load and io, did you see anything happen just before these >> errors started in the logs? >> >> Aaron Cossey >> aaron.cossey@gmail.com >> >> >> On Wed, Mar 6, 2013 at 1:35 PM, agya naila wrote: >> >>> Hi all, >>> >>> Today I got problem below and my domU become unresponsive and I should >>> restart the pc to make it running properly again. >>> >>> [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 >>> seconds. >>> [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 >>> seconds. >>> [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 >>> seconds. >>> [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 >>> seconds. >>> [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 >>> seconds. >>> [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 >>> seconds. >>> [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 >>> seconds. >>> [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 >>> seconds. >>> [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 >>> seconds. >>> [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> >>> Does any body have clue regarding this problem? >>> >>> Regards, >>> >>> Agya >>> >>> _______________________________________________ >>> 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 >> > > --089e0102e172b52f8504d7cda1e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here more details of my machine log :

[2013-03-13 1= 3:03:05 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.destroy: domid=3D3=
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomai= nInfo.handleShutdownWatch
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:03:05 1983] DEBUG (XendDomainI= nfo:1882) XendDomainInfo.handleShutdownWatch
[2013-03-13 13:03:05= 1983] DEBUG (XendDomainInfo:2402) Destroying device model
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2409) Releasing devic= es
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removin= g vif/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) Xe= ndDomainInfo.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing consol= e/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDo= mainInfo.destroyDevice: deviceClass =3D console, device =3D c$
[2= 013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:03:06 1983] DEBUG (XendDomainInfo:2407) No device model
[2013= -03-13 13:03:06 1983] DEBUG (XendDomainInfo:2409) Releasing devices
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vif/0<= /div>
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomain= Info.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-0= 3-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm&#= 39;, ['name', 'Sb-Voip1-DomU'], ['memory$
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm&#= 39;, ['name', 'Sb-Voip1-DomU'], ['memory$
[2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:2499) XendDomainInfo.= constructDomain
[2013-03-13 13:04:46 1983] DEBUG (balloon:187) Ba= lloon: 2058876 KiB free; need 16384; done.
[2013-03-13 13:04:47 1= 983] DEBUG (XendDomain:476) Adding Domain: 4
[2013-03-13 13:04:47 1983] DEBUG (XendDomainInfo:2842) XendDomainInfo.= initDomain: 4 256
[2013-03-13 13:04:47 1983] INFO (XendDomainInfo= :3276) Mounting drbd-vm on /dev/xvdp.
[2013-03-13 13:04:47 1983] = DEBUG (DevController:95) DevController: writing {'backend-id': '= ;0', 'virtual-device': '5195$
[2013-03-13 13:04:47 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Domain-0', 'frontend': '/local= /$
[2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting f= or 51952.
[2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:= 04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0= /backend/vbd/0/51952/hotplug$
[2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:47 1983] DEBUG (DevController:144) Wait= ing for 51952.
[2013-03-13 13:04:47 1983] DEBUG (DevController:62= 8) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:47 4725] DEBUG (XendBootloader:113) Lau= nching bootloader as ['/usr/bin/pygrub', '--output=3D/var/run/x= $
[2013-03-13 13:04:49 1983] INFO (XendDomainInfo:3295) Unmounting /dev/= xvdp from /dev/xvdp.
[2013-03-13 13:04:49 1983] DEBUG (XendDomain= Info:1276) XendDomainInfo.destroyDevice: deviceClass =3D vbd, device =3D /d= ev/$
[2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:2869) _initDomain:sha= dow_memory=3D0x0, memory_static_max=3D0x40000000, me$
[2013-03-13= 13:04:49 1983] INFO (image:182) buildDomain os=3Dlinux dom=3D4 vcpus=3D1
[2013-03-13 13:04:49 1983] DEBUG (image:721) domid =A0 =A0 =A0 =A0 =A0=3D 4=
[2013-03-13 13:04:49 1983] DEBUG (image:722) memsize =A0 =A0 =A0= =A0=3D 1024
[2013-03-13 13:04:49 1983] DEBUG (image:723) image = =A0 =A0 =A0 =A0 =A0=3D /var/run/xend/boot/boot_kernel.bWctVs
[2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn =A0 =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:723) image =A0 =A0 =A0 =A0 = =A0=3D /var/run/xend/boot/boot_kernel.bWctVs
[2013-03-13 13:04:49= 1983] DEBUG (image:724) store_evtchn =A0 =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:725) console_evtchn =3D 2
[2013-03-13 13:04:49 1983] DEBUG (image:726) cmdline =A0 =A0 =A0 =A0= =3D root=3DUUID=3Df76e1730-ef98-43f3-ae37-caaff1dbe5c1 ro consol$
[2013-03-13 13:04:49 1983] DEBUG (image:727) ramdisk =A0 =A0 =A0 =A0=3D /v= ar/run/xend/boot/boot_ramdisk.GF_u4x
[2013-03-13 13:04:49 1983] DEBUG (image:728) vcpus =A0 =A0 =A0 =A0 =A0= =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:729) features =A0 = =A0 =A0 =3D
[2013-03-13 13:04:49 1983] DEBUG (image:730) flags = =A0 =A0 =A0 =A0 =A0=3D 0
[2013-03-13 13:04:49 1983] DEBUG (image:731) superpages =A0 =A0 =3D 0
=
[2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vb= d : {'uuid': '2601a8a4-f53c-e392-44b7-4d79ecb6bf$
[20= 13-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {&#= 39;virtual-device': '51712', 'device-type': $
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Sb-Voip1-DomU', 'frontend': '/= l$
[2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDe= vice: vif : {'ip': '192.168.129.55', 'mac': '00= :16:3e:35$
[2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: wri= ting {'mac': '00:16:3e:35:82:be', 'handle': '0&= #39;,$
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevCon= troller: writing {'bridge': 'xenbr0', 'domain': = 9;Sb-Voip1-Do$
[2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:3426) Storing VM deta= ils: {'on_xend_stop': 'ignore', 'pool_name': 'P= o$
[2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:1795) Storing= domain details: {'console/ring-ref': '270105', 'image/= e$
[2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: wri= ting {'protocol': 'x86_64-abi', 'state': '1'= ;, 'b$
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) De= vController: writing {'domain': 'Sb-Voip1-DomU', 'front= end': '/l$
[2013-03-13 13:04:51 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:04:51 1983] DEBUG (DevControll= er:139) Waiting for devices tap2.
[2013-03-13 13:04:51 1983] DEBU= G (DevController:139) Waiting for devices vif.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusC= allback /local/domain/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 = 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domai= n/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 13:= 04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0= /backend/vif/4/0/hotplug-sta$
[2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vkbd.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices ioports.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es tap.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vif2.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices console.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for de= vices vscsi.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139)= Waiting for devices vbd.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712= .
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugSta= tusCallback /local/domain/0/backend/vbd/4/51712/hotplug$
[2013-03= -13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/d= omain/0/backend/vbd/4/51712/hotplug$
[2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices irq.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain Sb-Voip1-DomU= (4) unpaused.
[2013-03-13 13:20:31 1983] DEBUG (XendDomainInfo:3= 077) XendDomainInfo.destroy: domid=3D4
[2013-03-13 13:20:32 1983]= DEBUG (XendDomainInfo:2402) Destroying device model
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devic= es
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removin= g vif/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Re= leasing devices
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0<= /div>
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomain= Info.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-0= 3-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing console/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D console, device =3D c$
[2013-03-13= 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2= 013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroy= Device: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2407) No device model=
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing= devices
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) R= emoving vif/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-03-13 = 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[20= 13-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyD= evice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.c= reate(['vm', ['name', 'Sb-Voip1-DomU'], ['memor= y$
[2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2499) XendDom= ainInfo.constructDomain
[2013-03-13 13:23:03 1983] DEBUG (balloon:187) Balloon: 2058700 KiB fr= ee; need 16384; done.

[2013-03-13 13:23:03 1983] D= EBUG (XendDomain:476) Adding Domain: 5
[2013-03-13 13:23:03 1983]= DEBUG (XendDomainInfo:2842) XendDomainInfo.initDomain: 5 256
[2013-03-13 13:23:03 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm= on /dev/xvdp.
[2013-03-13 13:23:03 1983] DEBUG (DevController:95= ) DevController: writing {'backend-id': '0', 'virtual-d= evice': '5195$
[2013-03-13 13:23:03 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Domain-0', 'frontend': '/local= /$
[2013-03-13 13:23:03 1983] DEBUG (DevController:144) Waiting f= or 51952.
[2013-03-13 13:23:03 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:= 24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be con= nected. Hotplug scripts not $
Traceback (most recent call last):
[2013-03-13 13:24:43 1983= ] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be connected. Ho= tplug scripts not $
Traceback (most recent call last):
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice= (dev_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-pa= ckages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return self.getDeviceController(deviceClass).waitForDevice(dev= id)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xen= d/server/DevController.py", line 155, in waitForDevice
=A0 = =A0 (devid, self.deviceClass))
VmError: Device 51952 (vbd) could not be connected. Hotplug scripts no= t working.
[2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:488) = VM start failed
Traceback (most recent call last):
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 474, in start
=A0 =A0 XendTask.log_progress(31,= 60, self._initDomain)
=A0 File "/usr/local/lib/python2.7/di= st-packages/xen/xend/XendTask.py", line 209, in log_progress
=A0 =A0 retval =3D func(*args, **kwds)
=A0 File "/usr/l= ocal/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 284= 4, in _initDomain
=A0 =A0 self._configureBootloader()
= =A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3285, in _configureBootloader
=A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);
=A0= File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.= py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice(de= v_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom= ainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return sel= f.getDeviceController(deviceClass).waitForDevice(devid)
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.= py", line 155, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
=A0 File "/usr/local= /lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 1= 55, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not wo= rking.
[2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.= destroy: domid=3D5
[2013-03-13 13:24:43 1983] DEBUG (XendDomainIn= fo:2407) No device model
[2013-03-13 13:24:43 1983] DEBUG (XendDo= mainInfo:2409) Releasing devices
[2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:108) Domain construct= ion failed
Traceback (most recent call last):
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py&quo= t;, line 106, in create
=A0 =A0 vm.start()
=A0 File "/usr/local/lib/python2.7/d= ist-packages/xen/xend/XendDomainInfo.py", line 474, in start
=A0 =A0 XendTask.log_progress(31, 60, self._initDomain)
=A0 File= "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", l= ine 209, in log_progress
=A0 =A0 retval =3D func(*args, **kwds)
=A0 File "/usr/l= ocal/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 284= 4, in _initDomain
=A0 =A0 self._configureBootloader()
= =A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3285, in _configureBootloader
=A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);
=A0= File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.= py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice(de= v_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom= ainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return sel= f.getDeviceController(deviceClass).waitForDevice(devid)
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.= py", line 155, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
VmError: Device 51952 (vb= d) could not be connected. Hotplug scripts not working.
=A0(devid= , self.deviceClass))
VmError: Device 51952 (vbd) could not be con= nected. Hotplug scripts not working.


Regards,

Agya
On Wed, Mar 13, 2013 at 1:14 PM, agya na= ila <agya.naila@gmail.com> wrote:
I am not sure its due to high load in my cas= e since there is still no high load in server. I didn't run any program= that have high load and no client that accessing this server. I am suspect= ing the hotplug script. In my xend.log here is the logs :

server1@server1:~$ sudo tail /var/log/xen/xend.log
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 5171= 2.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugSt= atusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03= -13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es irq.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wai= ting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomai= n:1225) Domain DomU (4) unpaused.

any hints ?

regards,

Agya=


On Wed, Mar 6, 2013 at 4:12 PM, Aaron Cossey <a= aron.cossey@gmail.com> wrote:
I've=A0encountered=A0this frequently due to high io lo= ad. If you have monitoring of load and io, did you see anything happen just= before these errors started in the logs?
<= br clear=3D"all">

On Wed, Mar 6, 2013 at 1:35 PM= , agya naila <agya.naila@gmail.com> wrote:
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


--089e0102e172b52f8504d7cda1e1-- --===============8859112764883900801== 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 --===============8859112764883900801==-- From xen-users-bounces@lists.xen.org Wed Mar 13 12:35:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 12:35: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 1UFktT-0006Lr-C7; Wed, 13 Mar 2013 12:34:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFktQ-0006Lm-7x for xen-users@lists.xen.org; Wed, 13 Mar 2013 12:34:53 +0000 Received: from [193.109.254.147:43728] by server-14.bemta-14.messagelabs.com id D9/4E-05867-B6270415; Wed, 13 Mar 2013 12:34:51 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1363178088!8720703!1 X-Originating-IP: [74.125.82.181] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14681 invoked from network); 13 Mar 2013 12:34:48 -0000 Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com) (74.125.82.181) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 12:34:48 -0000 Received: by mail-we0-f181.google.com with SMTP id t44so905911wey.26 for ; Wed, 13 Mar 2013 05:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OdynlXAD3t/RXzzYynUhQnLrOzUhQiiUstQtQ8ZQeqA=; b=QHUkkyBCMz3g0UKivuo2yF+maDBzE3+tIZ5J1D0Taz3qQae1f7bPLJRTlv1bKhefcV FhBISzlgdL/dCRBAtzIJaAZhBBfkOlnYjHBqQ5rDeI6mPVu8TB+Opkh3xdGyHRcfzgiL /fRRmu+vXB5QfeudvMiY7j5vIze9o0KJldL6vARichDalStk7OfTQxN3QklvJWDZZ+er xbiznjHelehiNLa1EOPf73AVnvHB28KwN+7SchOugMN0yoYT0vNOxJmpQKZ4dNMQ4Cwc jwPTSMFCf835vP1vPSs9duX1VKr3kH2MJFc6zT8U5aV3Nv3BNftT5z90HJpO1XS9i02g sxYg== MIME-Version: 1.0 X-Received: by 10.194.109.136 with SMTP id hs8mr33846214wjb.8.1363178088114; Wed, 13 Mar 2013 05:34:48 -0700 (PDT) Received: by 10.216.208.143 with HTTP; Wed, 13 Mar 2013 05:34:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 13:34:48 +0100 Message-ID: From: agya naila To: Aaron Cossey Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============8859112764883900801==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8859112764883900801== Content-Type: multipart/alternative; boundary=089e0102e172b52f8504d7cda1e1 --089e0102e172b52f8504d7cda1e1 Content-Type: text/plain; charset=ISO-8859-1 Here more details of my machine log : [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.destroy: domid=3 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.handleShutdownWatch [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.handleShutdownWatch [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.handleShutdownWatch [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2402) Destroying device model [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing console/0 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = console, device = c$ [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2407) No device model [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:2499) XendDomainInfo.constructDomain [2013-03-13 13:04:46 1983] DEBUG (balloon:187) Balloon: 2058876 KiB free; need 16384; done. [2013-03-13 13:04:47 1983] DEBUG (XendDomain:476) Adding Domain: 4 [2013-03-13 13:04:47 1983] DEBUG (XendDomainInfo:2842) XendDomainInfo.initDomain: 4 256 [2013-03-13 13:04:47 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm on /dev/xvdp. [2013-03-13 13:04:47 1983] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'virtual-device': '5195$ [2013-03-13 13:04:47 1983] DEBUG (DevController:97) DevController: writing {'domain': 'Domain-0', 'frontend': '/local/$ [2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting for 51952. [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$ [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$ [2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting for 51952. [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$ [2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:47 4725] DEBUG (XendBootloader:113) Launching bootloader as ['/usr/bin/pygrub', '--output=/var/run/x$ [2013-03-13 13:04:49 1983] INFO (XendDomainInfo:3295) Unmounting /dev/xvdp from /dev/xvdp. [2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = /dev/$ [2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:2869) _initDomain:shadow_memory=0x0, memory_static_max=0x40000000, me$ [2013-03-13 13:04:49 1983] INFO (image:182) buildDomain os=linux dom=4 vcpus=1 [2013-03-13 13:04:49 1983] DEBUG (image:721) domid = 4 [2013-03-13 13:04:49 1983] DEBUG (image:722) memsize = 1024 [2013-03-13 13:04:49 1983] DEBUG (image:723) image = /var/run/xend/boot/boot_kernel.bWctVs [2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn = 1 [2013-03-13 13:04:49 1983] DEBUG (image:723) image = /var/run/xend/boot/boot_kernel.bWctVs [2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn = 1 [2013-03-13 13:04:49 1983] DEBUG (image:725) console_evtchn = 2 [2013-03-13 13:04:49 1983] DEBUG (image:726) cmdline = root=UUID=f76e1730-ef98-43f3-ae37-caaff1dbe5c1 ro consol$ [2013-03-13 13:04:49 1983] DEBUG (image:727) ramdisk = /var/run/xend/boot/boot_ramdisk.GF_u4x [2013-03-13 13:04:49 1983] DEBUG (image:728) vcpus = 1 [2013-03-13 13:04:49 1983] DEBUG (image:729) features = [2013-03-13 13:04:49 1983] DEBUG (image:730) flags = 0 [2013-03-13 13:04:49 1983] DEBUG (image:731) superpages = 0 [2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vbd : {'uuid': '2601a8a4-f53c-e392-44b7-4d79ecb6bf$ [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {'virtual-device': '51712', 'device-type': $ [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing {'domain': 'Sb-Voip1-DomU', 'frontend': '/l$ [2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vif : {'ip': '192.168.129.55', 'mac': '00:16:3e:35$ [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {'mac': '00:16:3e:35:82:be', 'handle': '0',$ [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing {'bridge': 'xenbr0', 'domain': 'Sb-Voip1-Do$ [2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:3426) Storing VM details: {'on_xend_stop': 'ignore', 'pool_name': 'Po$ [2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:1795) Storing domain details: {'console/ring-ref': '270105', 'image/e$ [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {'protocol': 'x86_64-abi', 'state': '1', 'b$ [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing {'domain': 'Sb-Voip1-DomU', 'frontend': '/l$ [2013-03-13 13:04:51 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.handleShutdownWatch [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices tap2. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vif. [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0. [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/4/0/hotplug-sta$ [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/4/0/hotplug-sta$ [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/4/0/hotplug-sta$ [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/4/0/hotplug-sta$ [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vkbd. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices ioports. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices tap. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vif2. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices console. [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vscsi. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vbd. [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug$ [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug$ [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices irq. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vfb. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices pci. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vusb. [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices vtpm. [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain Sb-Voip1-DomU (4) unpaused. [2013-03-13 13:20:31 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.destroy: domid=4 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2402) Destroying device model [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing console/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = console, device = c$ [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2407) No device model [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2499) XendDomainInfo.constructDomain [2013-03-13 13:23:03 1983] DEBUG (balloon:187) Balloon: 2058700 KiB free; need 16384; done. [2013-03-13 13:23:03 1983] DEBUG (XendDomain:476) Adding Domain: 5 [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2842) XendDomainInfo.initDomain: 5 256 [2013-03-13 13:23:03 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm on /dev/xvdp. [2013-03-13 13:23:03 1983] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'virtual-device': '5195$ [2013-03-13 13:23:03 1983] DEBUG (DevController:97) DevController: writing {'domain': 'Domain-0', 'frontend': '/local/$ [2013-03-13 13:23:03 1983] DEBUG (DevController:144) Waiting for 51952. [2013-03-13 13:23:03 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$ [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be connected. Hotplug scripts not $ Traceback (most recent call last): [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be connected. Hotplug scripts not $ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3989, in create_vbd self._waitForDevice(dev_type, devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice return self.getDeviceController(deviceClass).waitForDevice(devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 155, in waitForDevice (devid, self.deviceClass)) VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not working. [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:488) VM start failed Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2844, in _initDomain self._configureBootloader() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3285, in _configureBootloader mounted_vbd_uuid = dom0.create_vbd(vbd, disk); File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3989, in create_vbd self._waitForDevice(dev_type, devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice return self.getDeviceController(deviceClass).waitForDevice(devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 155, in waitForDevice (devid, self.deviceClass)) File "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 155, in waitForDevice (devid, self.deviceClass)) VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not working. [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.destroy: domid=5 [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:2407) No device model [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:2409) Releasing devices [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:108) Domain construction failed Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 106, in create vm.start() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 474, in start XendTask.log_progress(31, 60, self._initDomain) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line 209, in log_progress retval = func(*args, **kwds) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2844, in _initDomain self._configureBootloader() File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3285, in _configureBootloader mounted_vbd_uuid = dom0.create_vbd(vbd, disk); File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 3989, in create_vbd self._waitForDevice(dev_type, devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice return self.getDeviceController(deviceClass).waitForDevice(devid) File "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 155, in waitForDevice (devid, self.deviceClass)) VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not working. (devid, self.deviceClass)) VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not working. Regards, Agya On Wed, Mar 13, 2013 at 1:14 PM, agya naila wrote: > I am not sure its due to high load in my case since there is still no high > load in server. I didn't run any program that have high load and no client > that accessing this server. I am suspecting the hotplug script. In my > xend.log here is the logs : > > server1@server1:~$ sudo tail /var/log/xen/xend.log > [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/4/51712/hotplug-status. > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/4/51712/hotplug-status. > [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > irq. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vfb. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > pci. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vusb. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vtpm. > [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain DomU (4) unpaused. > > any hints ? > > regards, > > Agya > > > On Wed, Mar 6, 2013 at 4:12 PM, Aaron Cossey wrote: > >> I've encountered this frequently due to high io load. If you have >> monitoring of load and io, did you see anything happen just before these >> errors started in the logs? >> >> Aaron Cossey >> aaron.cossey@gmail.com >> >> >> On Wed, Mar 6, 2013 at 1:35 PM, agya naila wrote: >> >>> Hi all, >>> >>> Today I got problem below and my domU become unresponsive and I should >>> restart the pc to make it running properly again. >>> >>> [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 >>> seconds. >>> [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 >>> seconds. >>> [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 >>> seconds. >>> [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 >>> seconds. >>> [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 >>> seconds. >>> [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 >>> seconds. >>> [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 >>> seconds. >>> [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 >>> seconds. >>> [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 >>> seconds. >>> [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>> disables this message. >>> >>> Does any body have clue regarding this problem? >>> >>> Regards, >>> >>> Agya >>> >>> _______________________________________________ >>> 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 >> > > --089e0102e172b52f8504d7cda1e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here more details of my machine log :

[2013-03-13 1= 3:03:05 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.destroy: domid=3D3=
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomai= nInfo.handleShutdownWatch
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:03:05 1983] DEBUG (XendDomainI= nfo:1882) XendDomainInfo.handleShutdownWatch
[2013-03-13 13:03:05= 1983] DEBUG (XendDomainInfo:2402) Destroying device model
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2409) Releasing devic= es
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removin= g vif/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) Xe= ndDomainInfo.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing consol= e/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDo= mainInfo.destroyDevice: deviceClass =3D console, device =3D c$
[2= 013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:03:06 1983] DEBUG (XendDomainInfo:2407) No device model
[2013= -03-13 13:03:06 1983] DEBUG (XendDomainInfo:2409) Releasing devices
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vif/0<= /div>
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomain= Info.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-0= 3-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm&#= 39;, ['name', 'Sb-Voip1-DomU'], ['memory$
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm&#= 39;, ['name', 'Sb-Voip1-DomU'], ['memory$
[2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:2499) XendDomainInfo.= constructDomain
[2013-03-13 13:04:46 1983] DEBUG (balloon:187) Ba= lloon: 2058876 KiB free; need 16384; done.
[2013-03-13 13:04:47 1= 983] DEBUG (XendDomain:476) Adding Domain: 4
[2013-03-13 13:04:47 1983] DEBUG (XendDomainInfo:2842) XendDomainInfo.= initDomain: 4 256
[2013-03-13 13:04:47 1983] INFO (XendDomainInfo= :3276) Mounting drbd-vm on /dev/xvdp.
[2013-03-13 13:04:47 1983] = DEBUG (DevController:95) DevController: writing {'backend-id': '= ;0', 'virtual-device': '5195$
[2013-03-13 13:04:47 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Domain-0', 'frontend': '/local= /$
[2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting f= or 51952.
[2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:= 04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0= /backend/vbd/0/51952/hotplug$
[2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:47 1983] DEBUG (DevController:144) Wait= ing for 51952.
[2013-03-13 13:04:47 1983] DEBUG (DevController:62= 8) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:47 4725] DEBUG (XendBootloader:113) Lau= nching bootloader as ['/usr/bin/pygrub', '--output=3D/var/run/x= $
[2013-03-13 13:04:49 1983] INFO (XendDomainInfo:3295) Unmounting /dev/= xvdp from /dev/xvdp.
[2013-03-13 13:04:49 1983] DEBUG (XendDomain= Info:1276) XendDomainInfo.destroyDevice: deviceClass =3D vbd, device =3D /d= ev/$
[2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:2869) _initDomain:sha= dow_memory=3D0x0, memory_static_max=3D0x40000000, me$
[2013-03-13= 13:04:49 1983] INFO (image:182) buildDomain os=3Dlinux dom=3D4 vcpus=3D1
[2013-03-13 13:04:49 1983] DEBUG (image:721) domid =A0 =A0 =A0 =A0 =A0=3D 4=
[2013-03-13 13:04:49 1983] DEBUG (image:722) memsize =A0 =A0 =A0= =A0=3D 1024
[2013-03-13 13:04:49 1983] DEBUG (image:723) image = =A0 =A0 =A0 =A0 =A0=3D /var/run/xend/boot/boot_kernel.bWctVs
[2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn =A0 =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:723) image =A0 =A0 =A0 =A0 = =A0=3D /var/run/xend/boot/boot_kernel.bWctVs
[2013-03-13 13:04:49= 1983] DEBUG (image:724) store_evtchn =A0 =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:725) console_evtchn =3D 2
[2013-03-13 13:04:49 1983] DEBUG (image:726) cmdline =A0 =A0 =A0 =A0= =3D root=3DUUID=3Df76e1730-ef98-43f3-ae37-caaff1dbe5c1 ro consol$
[2013-03-13 13:04:49 1983] DEBUG (image:727) ramdisk =A0 =A0 =A0 =A0=3D /v= ar/run/xend/boot/boot_ramdisk.GF_u4x
[2013-03-13 13:04:49 1983] DEBUG (image:728) vcpus =A0 =A0 =A0 =A0 =A0= =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:729) features =A0 = =A0 =A0 =3D
[2013-03-13 13:04:49 1983] DEBUG (image:730) flags = =A0 =A0 =A0 =A0 =A0=3D 0
[2013-03-13 13:04:49 1983] DEBUG (image:731) superpages =A0 =A0 =3D 0
=
[2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vb= d : {'uuid': '2601a8a4-f53c-e392-44b7-4d79ecb6bf$
[20= 13-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {&#= 39;virtual-device': '51712', 'device-type': $
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Sb-Voip1-DomU', 'frontend': '/= l$
[2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDe= vice: vif : {'ip': '192.168.129.55', 'mac': '00= :16:3e:35$
[2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: wri= ting {'mac': '00:16:3e:35:82:be', 'handle': '0&= #39;,$
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevCon= troller: writing {'bridge': 'xenbr0', 'domain': = 9;Sb-Voip1-Do$
[2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:3426) Storing VM deta= ils: {'on_xend_stop': 'ignore', 'pool_name': 'P= o$
[2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:1795) Storing= domain details: {'console/ring-ref': '270105', 'image/= e$
[2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: wri= ting {'protocol': 'x86_64-abi', 'state': '1'= ;, 'b$
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) De= vController: writing {'domain': 'Sb-Voip1-DomU', 'front= end': '/l$
[2013-03-13 13:04:51 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:04:51 1983] DEBUG (DevControll= er:139) Waiting for devices tap2.
[2013-03-13 13:04:51 1983] DEBU= G (DevController:139) Waiting for devices vif.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusC= allback /local/domain/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 = 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domai= n/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 13:= 04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0= /backend/vif/4/0/hotplug-sta$
[2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vkbd.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices ioports.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es tap.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vif2.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices console.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for de= vices vscsi.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139)= Waiting for devices vbd.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712= .
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugSta= tusCallback /local/domain/0/backend/vbd/4/51712/hotplug$
[2013-03= -13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/d= omain/0/backend/vbd/4/51712/hotplug$
[2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices irq.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain Sb-Voip1-DomU= (4) unpaused.
[2013-03-13 13:20:31 1983] DEBUG (XendDomainInfo:3= 077) XendDomainInfo.destroy: domid=3D4
[2013-03-13 13:20:32 1983]= DEBUG (XendDomainInfo:2402) Destroying device model
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devic= es
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removin= g vif/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Re= leasing devices
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0<= /div>
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomain= Info.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-0= 3-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing console/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D console, device =3D c$
[2013-03-13= 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2= 013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroy= Device: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2407) No device model=
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing= devices
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) R= emoving vif/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-03-13 = 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[20= 13-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyD= evice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.c= reate(['vm', ['name', 'Sb-Voip1-DomU'], ['memor= y$
[2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2499) XendDom= ainInfo.constructDomain
[2013-03-13 13:23:03 1983] DEBUG (balloon:187) Balloon: 2058700 KiB fr= ee; need 16384; done.

[2013-03-13 13:23:03 1983] D= EBUG (XendDomain:476) Adding Domain: 5
[2013-03-13 13:23:03 1983]= DEBUG (XendDomainInfo:2842) XendDomainInfo.initDomain: 5 256
[2013-03-13 13:23:03 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm= on /dev/xvdp.
[2013-03-13 13:23:03 1983] DEBUG (DevController:95= ) DevController: writing {'backend-id': '0', 'virtual-d= evice': '5195$
[2013-03-13 13:23:03 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Domain-0', 'frontend': '/local= /$
[2013-03-13 13:23:03 1983] DEBUG (DevController:144) Waiting f= or 51952.
[2013-03-13 13:23:03 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:= 24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be con= nected. Hotplug scripts not $
Traceback (most recent call last):
[2013-03-13 13:24:43 1983= ] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be connected. Ho= tplug scripts not $
Traceback (most recent call last):
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice= (dev_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-pa= ckages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return self.getDeviceController(deviceClass).waitForDevice(dev= id)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xen= d/server/DevController.py", line 155, in waitForDevice
=A0 = =A0 (devid, self.deviceClass))
VmError: Device 51952 (vbd) could not be connected. Hotplug scripts no= t working.
[2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:488) = VM start failed
Traceback (most recent call last):
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 474, in start
=A0 =A0 XendTask.log_progress(31,= 60, self._initDomain)
=A0 File "/usr/local/lib/python2.7/di= st-packages/xen/xend/XendTask.py", line 209, in log_progress
=A0 =A0 retval =3D func(*args, **kwds)
=A0 File "/usr/l= ocal/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 284= 4, in _initDomain
=A0 =A0 self._configureBootloader()
= =A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3285, in _configureBootloader
=A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);
=A0= File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.= py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice(de= v_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom= ainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return sel= f.getDeviceController(deviceClass).waitForDevice(devid)
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.= py", line 155, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
=A0 File "/usr/local= /lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 1= 55, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not wo= rking.
[2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.= destroy: domid=3D5
[2013-03-13 13:24:43 1983] DEBUG (XendDomainIn= fo:2407) No device model
[2013-03-13 13:24:43 1983] DEBUG (XendDo= mainInfo:2409) Releasing devices
[2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:108) Domain construct= ion failed
Traceback (most recent call last):
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py&quo= t;, line 106, in create
=A0 =A0 vm.start()
=A0 File "/usr/local/lib/python2.7/d= ist-packages/xen/xend/XendDomainInfo.py", line 474, in start
=A0 =A0 XendTask.log_progress(31, 60, self._initDomain)
=A0 File= "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", l= ine 209, in log_progress
=A0 =A0 retval =3D func(*args, **kwds)
=A0 File "/usr/l= ocal/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 284= 4, in _initDomain
=A0 =A0 self._configureBootloader()
= =A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3285, in _configureBootloader
=A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);
=A0= File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.= py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice(de= v_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom= ainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return sel= f.getDeviceController(deviceClass).waitForDevice(devid)
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.= py", line 155, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
VmError: Device 51952 (vb= d) could not be connected. Hotplug scripts not working.
=A0(devid= , self.deviceClass))
VmError: Device 51952 (vbd) could not be con= nected. Hotplug scripts not working.


Regards,

Agya
On Wed, Mar 13, 2013 at 1:14 PM, agya na= ila <agya.naila@gmail.com> wrote:
I am not sure its due to high load in my cas= e since there is still no high load in server. I didn't run any program= that have high load and no client that accessing this server. I am suspect= ing the hotplug script. In my xend.log here is the logs :

server1@server1:~$ sudo tail /var/log/xen/xend.log
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 5171= 2.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugSt= atusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03= -13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es irq.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wai= ting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomai= n:1225) Domain DomU (4) unpaused.

any hints ?

regards,

Agya=


On Wed, Mar 6, 2013 at 4:12 PM, Aaron Cossey <a= aron.cossey@gmail.com> wrote:
I've=A0encountered=A0this frequently due to high io lo= ad. If you have monitoring of load and io, did you see anything happen just= before these errors started in the logs?
<= br clear=3D"all">

On Wed, Mar 6, 2013 at 1:35 PM= , agya naila <agya.naila@gmail.com> wrote:
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


--089e0102e172b52f8504d7cda1e1-- --===============8859112764883900801== 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 --===============8859112764883900801==-- From xen-users-bounces@lists.xen.org Wed Mar 13 12:57:13 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 12:57: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 1UFlEN-0000IR-Fe; Wed, 13 Mar 2013 12:56:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFlEL-0000I3-TG for xen-users@lists.xen.org; Wed, 13 Mar 2013 12:56:30 +0000 Received: from [193.109.254.147:50761] by server-6.bemta-14.messagelabs.com id D4/7B-31180-D7770415; Wed, 13 Mar 2013 12:56:29 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1363179342!8699319!1 X-Originating-IP: [209.85.214.44] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8959 invoked from network); 13 Mar 2013 12:55:42 -0000 Received: from mail-bk0-f44.google.com (HELO mail-bk0-f44.google.com) (209.85.214.44) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 12:55:42 -0000 Received: by mail-bk0-f44.google.com with SMTP id j4so433898bkw.3 for ; Wed, 13 Mar 2013 05:55:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=9Tmaq85O0VEB9AhxaE8vyN56UWmLs8wduC0MstykR/w=; b=HUFQ2oAxwexNnH1NgalkxIoH9ES8sh6Q3eB6j/5h+8ts66qFoP+ZXNOnSOk0K2AEhy SzJjsH0egCO13odSxYpoXjxEYepbN4cGm33mHiZnlKs66TSMrkw0a/BK0NmRPMsF0w1p 9D5xCoPXl/NlfPGq1Qt4yWlO9iJjVAYdLyVoTZV1kmTmUmjIPRyYDLN5ZE2poOi8vSjB NgSDkTgVWQouLUkYkxg+N66DVGqYfKPtuUwuqPuwrgKYx4AcmujW4czATonBuGmfCswi mku4Y0obqz8vq9Ca5AZOs0nj8BL+3wDOvSIyNdEgQZXmlZy+XIAxr5qvT61Jgbranb61 1uTw== MIME-Version: 1.0 X-Received: by 10.205.119.19 with SMTP id fs19mr7613720bkc.105.1363179342146; Wed, 13 Mar 2013 05:55:42 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Wed, 13 Mar 2013 05:55:42 -0700 (PDT) Date: Wed, 13 Mar 2013 13:55:42 +0100 Message-ID: From: Sylvain Munaut To: "xen-users@lists.xen.org\"" X-Gm-Message-State: ALoCoQksUHvJuRlgQCfApvgeMqD9mtWb9Mq8Eu9NScooAeuW1mGdqmBvVQLsrBroxS8DBgyB9SSI Subject: [Xen-users] Race condition in sending gratuitous ARP for live migration ? X-BeenThere: xen-users@lists.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, So, the issue is a fairly common one: Network doesn't work for like a minute or so after a live migration. The setup is a debian wheezy dom0 with xen 4.1.2 running 3.6.11 kernel. The domU is a Ubuntu 12.04 with a 3.2 kernel. The networking setup uses bridges on the dom0. I also made sure that the bridge forwarding delay is set to 0. The VM doesn't initiate any network activity on its own, so it's solely relying on the gratuitous ARP to be sent for the various place (switch and dom0 bridges) to be updated. I confirmed that the gratuitous ARP is sent by the domU after migration by using tcpdump. I can also see it on the vif on the dom0. But I can't see it on the bridge interface in the dom0, nor on the network itself. I also confirmed that it I make the domU send gratuitous ARP continuously using arping, the it works fine. So I think the gratuitous ARP is sent a bit too early, before it's ready to be forwarded around with the dom0. Any idea how I can check and correct this ? Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 12:57:13 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 12:57: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 1UFlEN-0000IR-Fe; Wed, 13 Mar 2013 12:56:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFlEL-0000I3-TG for xen-users@lists.xen.org; Wed, 13 Mar 2013 12:56:30 +0000 Received: from [193.109.254.147:50761] by server-6.bemta-14.messagelabs.com id D4/7B-31180-D7770415; Wed, 13 Mar 2013 12:56:29 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1363179342!8699319!1 X-Originating-IP: [209.85.214.44] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8959 invoked from network); 13 Mar 2013 12:55:42 -0000 Received: from mail-bk0-f44.google.com (HELO mail-bk0-f44.google.com) (209.85.214.44) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 12:55:42 -0000 Received: by mail-bk0-f44.google.com with SMTP id j4so433898bkw.3 for ; Wed, 13 Mar 2013 05:55:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=9Tmaq85O0VEB9AhxaE8vyN56UWmLs8wduC0MstykR/w=; b=HUFQ2oAxwexNnH1NgalkxIoH9ES8sh6Q3eB6j/5h+8ts66qFoP+ZXNOnSOk0K2AEhy SzJjsH0egCO13odSxYpoXjxEYepbN4cGm33mHiZnlKs66TSMrkw0a/BK0NmRPMsF0w1p 9D5xCoPXl/NlfPGq1Qt4yWlO9iJjVAYdLyVoTZV1kmTmUmjIPRyYDLN5ZE2poOi8vSjB NgSDkTgVWQouLUkYkxg+N66DVGqYfKPtuUwuqPuwrgKYx4AcmujW4czATonBuGmfCswi mku4Y0obqz8vq9Ca5AZOs0nj8BL+3wDOvSIyNdEgQZXmlZy+XIAxr5qvT61Jgbranb61 1uTw== MIME-Version: 1.0 X-Received: by 10.205.119.19 with SMTP id fs19mr7613720bkc.105.1363179342146; Wed, 13 Mar 2013 05:55:42 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Wed, 13 Mar 2013 05:55:42 -0700 (PDT) Date: Wed, 13 Mar 2013 13:55:42 +0100 Message-ID: From: Sylvain Munaut To: "xen-users@lists.xen.org\"" X-Gm-Message-State: ALoCoQksUHvJuRlgQCfApvgeMqD9mtWb9Mq8Eu9NScooAeuW1mGdqmBvVQLsrBroxS8DBgyB9SSI Subject: [Xen-users] Race condition in sending gratuitous ARP for live migration ? X-BeenThere: xen-users@lists.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, So, the issue is a fairly common one: Network doesn't work for like a minute or so after a live migration. The setup is a debian wheezy dom0 with xen 4.1.2 running 3.6.11 kernel. The domU is a Ubuntu 12.04 with a 3.2 kernel. The networking setup uses bridges on the dom0. I also made sure that the bridge forwarding delay is set to 0. The VM doesn't initiate any network activity on its own, so it's solely relying on the gratuitous ARP to be sent for the various place (switch and dom0 bridges) to be updated. I confirmed that the gratuitous ARP is sent by the domU after migration by using tcpdump. I can also see it on the vif on the dom0. But I can't see it on the bridge interface in the dom0, nor on the network itself. I also confirmed that it I make the domU send gratuitous ARP continuously using arping, the it works fine. So I think the gratuitous ARP is sent a bit too early, before it's ready to be forwarded around with the dom0. Any idea how I can check and correct this ? Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 13:06:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 13:06:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFlN8-0000vV-7R; Wed, 13 Mar 2013 13:05:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFlN6-0000vN-1p for xen-users@lists.xen.org; Wed, 13 Mar 2013 13:05:32 +0000 Received: from [85.158.143.99:4460] by server-3.bemta-4.messagelabs.com id 88/CA-02186-B9970415; Wed, 13 Mar 2013 13:05:31 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1363179811!17105778!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24192 invoked from network); 13 Mar 2013 13:03:31 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 13:03:31 -0000 Received: by mail-wg0-f50.google.com with SMTP id es5so938697wgb.5 for ; Wed, 13 Mar 2013 06:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=g7wjoLds4FcLjFymdr9gbfEq2Bo2PQN6BSYCh8iVOO0=; b=uRS9+zHMAkQmdoTvw36Wxg7Fb+pFtib4yDURelRFPGKi1dn0d3UGY5Hi7lX/L10N4a j1apGE36VPHm5UsPvcfBmGxIGT2vfYYo5jiaGP4+b9KQVL5D5kxvj2ui/dNPe1YtexkA Zx9fUUM7XZNiZo6eTohlctt7XWsjHvnfu/ALoLhWbfYPNgLfasa4Qw1yA+eeRZoyrJKs n2NfzEJgWSBICDxQgb03jukOIPIbkLj/vbWAIVEzVSbUkOMv2UgOzHw5n77EzBw48ONK XdbEMPqvTxJaqQqi8TDw5RsFED6vd4nreX8douvc8Jl0+zUoa9oc9oC5XnK4CQ1Wwxto m/Kg== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr26893860wid.29.1363179810765; Wed, 13 Mar 2013 06:03:30 -0700 (PDT) Received: by 10.216.208.143 with HTTP; Wed, 13 Mar 2013 06:03:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 14:03:30 +0100 Message-ID: From: agya naila To: Aaron Cossey Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============8395776546211446022==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8395776546211446022== Content-Type: multipart/alternative; boundary=f46d0438914b62c3ac04d7ce0890 --f46d0438914b62c3ac04d7ce0890 Content-Type: text/plain; charset=ISO-8859-1 I am also got this message when reboot the machine : udevd[243]: inotify_add_watch(6, /dev/dm-3, 10) failed : Invalid argument udevd[244]: inotify_add_watch(6, /dev/dm-1, 10) failed : Invalid argument Regards, Agya On Wed, Mar 13, 2013 at 1:34 PM, agya naila wrote: > Here more details of my machine log : > > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:3077) > XendDomainInfo.destroy: domid=3 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) > XendDomainInfo.handleShutdownWatch > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) > XendDomainInfo.handleShutdownWatch > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) > XendDomainInfo.handleShutdownWatch > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2402) Destroying device > model > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing console/0 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = console, device = c$ > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2407) No device model > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:103) > XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:103) > XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ > [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:2499) > XendDomainInfo.constructDomain > [2013-03-13 13:04:46 1983] DEBUG (balloon:187) Balloon: 2058876 KiB free; > need 16384; done. > [2013-03-13 13:04:47 1983] DEBUG (XendDomain:476) Adding Domain: 4 > [2013-03-13 13:04:47 1983] DEBUG (XendDomainInfo:2842) > XendDomainInfo.initDomain: 4 256 > [2013-03-13 13:04:47 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm on > /dev/xvdp. > [2013-03-13 13:04:47 1983] DEBUG (DevController:95) DevController: writing > {'backend-id': '0', 'virtual-device': '5195$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:97) DevController: writing > {'domain': 'Domain-0', 'frontend': '/local/$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting for 51952. > [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/0/51952/hotplug$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/0/51952/hotplug$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting for 51952. > [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/0/51952/hotplug$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:47 4725] DEBUG (XendBootloader:113) Launching bootloader > as ['/usr/bin/pygrub', '--output=/var/run/x$ > [2013-03-13 13:04:49 1983] INFO (XendDomainInfo:3295) Unmounting /dev/xvdp > from /dev/xvdp. > [2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = /dev/$ > [2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:2869) > _initDomain:shadow_memory=0x0, memory_static_max=0x40000000, me$ > [2013-03-13 13:04:49 1983] INFO (image:182) buildDomain os=linux dom=4 > vcpus=1 > [2013-03-13 13:04:49 1983] DEBUG (image:721) domid = 4 > [2013-03-13 13:04:49 1983] DEBUG (image:722) memsize = 1024 > [2013-03-13 13:04:49 1983] DEBUG (image:723) image = > /var/run/xend/boot/boot_kernel.bWctVs > [2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn = 1 > [2013-03-13 13:04:49 1983] DEBUG (image:723) image = > /var/run/xend/boot/boot_kernel.bWctVs > [2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn = 1 > [2013-03-13 13:04:49 1983] DEBUG (image:725) console_evtchn = 2 > [2013-03-13 13:04:49 1983] DEBUG (image:726) cmdline = > root=UUID=f76e1730-ef98-43f3-ae37-caaff1dbe5c1 ro consol$ > [2013-03-13 13:04:49 1983] DEBUG (image:727) ramdisk = > /var/run/xend/boot/boot_ramdisk.GF_u4x > [2013-03-13 13:04:49 1983] DEBUG (image:728) vcpus = 1 > [2013-03-13 13:04:49 1983] DEBUG (image:729) features = > [2013-03-13 13:04:49 1983] DEBUG (image:730) flags = 0 > [2013-03-13 13:04:49 1983] DEBUG (image:731) superpages = 0 > [2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vbd : > {'uuid': '2601a8a4-f53c-e392-44b7-4d79ecb6bf$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing > {'virtual-device': '51712', 'device-type': $ > [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing > {'domain': 'Sb-Voip1-DomU', 'frontend': '/l$ > [2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vif : > {'ip': '192.168.129.55', 'mac': '00:16:3e:35$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing > {'mac': '00:16:3e:35:82:be', 'handle': '0',$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing > {'bridge': 'xenbr0', 'domain': 'Sb-Voip1-Do$ > [2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:3426) Storing VM details: > {'on_xend_stop': 'ignore', 'pool_name': 'Po$ > [2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:1795) Storing domain > details: {'console/ring-ref': '270105', 'image/e$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing > {'protocol': 'x86_64-abi', 'state': '1', 'b$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing > {'domain': 'Sb-Voip1-DomU', 'frontend': '/l$ > [2013-03-13 13:04:51 1983] DEBUG (XendDomainInfo:1882) > XendDomainInfo.handleShutdownWatch > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > tap2. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vif. > [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0. > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vif/4/0/hotplug-sta$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vif/4/0/hotplug-sta$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vif/4/0/hotplug-sta$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vif/4/0/hotplug-sta$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vkbd. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > ioports. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > tap. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vif2. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > console. > [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vscsi. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vbd. > [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/4/51712/hotplug$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/4/51712/hotplug$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > irq. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vfb. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > pci. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vusb. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vtpm. > [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain Sb-Voip1-DomU (4) > unpaused. > [2013-03-13 13:20:31 1983] DEBUG (XendDomainInfo:3077) > XendDomainInfo.destroy: domid=4 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2402) Destroying device > model > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing console/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = console, device = c$ > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2407) No device model > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:103) > XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ > [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2499) > XendDomainInfo.constructDomain > [2013-03-13 13:23:03 1983] DEBUG (balloon:187) Balloon: 2058700 KiB free; > need 16384; done. > > [2013-03-13 13:23:03 1983] DEBUG (XendDomain:476) Adding Domain: 5 > [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2842) > XendDomainInfo.initDomain: 5 256 > [2013-03-13 13:23:03 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm on > /dev/xvdp. > [2013-03-13 13:23:03 1983] DEBUG (DevController:95) DevController: writing > {'backend-id': '0', 'virtual-device': '5195$ > [2013-03-13 13:23:03 1983] DEBUG (DevController:97) DevController: writing > {'domain': 'Domain-0', 'frontend': '/local/$ > [2013-03-13 13:23:03 1983] DEBUG (DevController:144) Waiting for 51952. > [2013-03-13 13:23:03 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/0/51952/hotplug$ > [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) > could not be connected. Hotplug scripts not $ > Traceback (most recent call last): > [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) > could not be connected. Hotplug scripts not $ > Traceback (most recent call last): > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3989, in create_vbd > self._waitForDevice(dev_type, devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2330, in _waitForDevice > return self.getDeviceController(deviceClass).waitForDevice(devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", > line 155, in waitForDevice > (devid, self.deviceClass)) > VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not > working. > [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:488) VM start failed > Traceback (most recent call last): > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 474, in start > XendTask.log_progress(31, 60, self._initDomain) > File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line > 209, in log_progress > retval = func(*args, **kwds) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2844, in _initDomain > self._configureBootloader() > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3285, in _configureBootloader > mounted_vbd_uuid = dom0.create_vbd(vbd, disk); > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3989, in create_vbd > self._waitForDevice(dev_type, devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2330, in _waitForDevice > return self.getDeviceController(deviceClass).waitForDevice(devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", > line 155, in waitForDevice > (devid, self.deviceClass)) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", > line 155, in waitForDevice > (devid, self.deviceClass)) > VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not > working. > [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:3077) > XendDomainInfo.destroy: domid=5 > [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:2407) No device model > [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:108) Domain construction > failed > Traceback (most recent call last): > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 106, in create > vm.start() > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 474, in start > XendTask.log_progress(31, 60, self._initDomain) > File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line > 209, in log_progress > retval = func(*args, **kwds) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2844, in _initDomain > self._configureBootloader() > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3285, in _configureBootloader > mounted_vbd_uuid = dom0.create_vbd(vbd, disk); > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3989, in create_vbd > self._waitForDevice(dev_type, devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2330, in _waitForDevice > return self.getDeviceController(deviceClass).waitForDevice(devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", > line 155, in waitForDevice > (devid, self.deviceClass)) > VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not > working. > (devid, self.deviceClass)) > VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not > working. > > > Regards, > > Agya > > On Wed, Mar 13, 2013 at 1:14 PM, agya naila wrote: > >> I am not sure its due to high load in my case since there is still no >> high load in server. I didn't run any program that have high load and no >> client that accessing this server. I am suspecting the hotplug script. In >> my xend.log here is the logs : >> >> server1@server1:~$ sudo tail /var/log/xen/xend.log >> [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:628) >> hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:628) >> hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:642) >> hotplugStatusCallback 1. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> irq. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> vfb. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> pci. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> vusb. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> vtpm. >> [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain DomU (4) >> unpaused. >> >> any hints ? >> >> regards, >> >> Agya >> >> >> On Wed, Mar 6, 2013 at 4:12 PM, Aaron Cossey wrote: >> >>> I've encountered this frequently due to high io load. If you have >>> monitoring of load and io, did you see anything happen just before these >>> errors started in the logs? >>> >>> Aaron Cossey >>> aaron.cossey@gmail.com >>> >>> >>> On Wed, Mar 6, 2013 at 1:35 PM, agya naila wrote: >>> >>>> Hi all, >>>> >>>> Today I got problem below and my domU become unresponsive and I should >>>> restart the pc to make it running properly again. >>>> >>>> [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 >>>> seconds. >>>> [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 >>>> seconds. >>>> [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 >>>> seconds. >>>> [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 >>>> seconds. >>>> [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 >>>> seconds. >>>> [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 >>>> seconds. >>>> [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 >>>> seconds. >>>> [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 >>>> seconds. >>>> [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 >>>> seconds. >>>> [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> >>>> Does any body have clue regarding this problem? >>>> >>>> Regards, >>>> >>>> Agya >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> > --f46d0438914b62c3ac04d7ce0890 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am also got this message when reboot the machine :

udevd[243]: inotify_add_watch(6, /dev/dm-3, 10) failed : Invalid argument=
udevd[244]: inotify_add_watch(6, /dev/dm-1, 10) failed : Invalid= argument

Regards,

Agya

On Wed, Mar 13, 2013 at 1:34 PM, agya naila <agya= .naila@gmail.com> wrote:
Here more details of my machine log :
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:3077) Xe= ndDomainInfo.destroy: domid=3D3
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:03:05 1983] DEBUG (XendDomainI= nfo:1882) XendDomainInfo.handleShutdownWatch
[2013-03-13 13:03:05= 1983] DEBUG (XendDomainInfo:2402) Destroying device model
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2409) Releasing devic= es
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removin= g vif/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) Xe= ndDomainInfo.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing consol= e/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDo= mainInfo.destroyDevice: deviceClass =3D console, device =3D c$
[2= 013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:03:06 1983] DEBUG (XendDomainInfo:2407) No device model
[2013= -03-13 13:03:06 1983] DEBUG (XendDomainInfo:2409) Releasing devices
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vif/0<= /div>
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomain= Info.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-0= 3-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm&#= 39;, ['name', 'Sb-Voip1-DomU'], ['memory$
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm&#= 39;, ['name', 'Sb-Voip1-DomU'], ['memory$
[2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:2499) XendDomainInfo.= constructDomain
[2013-03-13 13:04:46 1983] DEBUG (balloon:187) Ba= lloon: 2058876 KiB free; need 16384; done.
[2013-03-13 13:04:47 1= 983] DEBUG (XendDomain:476) Adding Domain: 4
[2013-03-13 13:04:47 1983] DEBUG (XendDomainInfo:2842) XendDomainInfo.= initDomain: 4 256
[2013-03-13 13:04:47 1983] INFO (XendDomainInfo= :3276) Mounting drbd-vm on /dev/xvdp.
[2013-03-13 13:04:47 1983] = DEBUG (DevController:95) DevController: writing {'backend-id': '= ;0', 'virtual-device': '5195$
[2013-03-13 13:04:47 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Domain-0', 'frontend': '/local= /$
[2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting f= or 51952.
[2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:= 04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0= /backend/vbd/0/51952/hotplug$
[2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:47 1983] DEBUG (DevController:144) Wait= ing for 51952.
[2013-03-13 13:04:47 1983] DEBUG (DevController:62= 8) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:47 4725] DEBUG (XendBootloader:113) Lau= nching bootloader as ['/usr/bin/pygrub', '--output=3D/var/run/x= $
[2013-03-13 13:04:49 1983] INFO (XendDomainInfo:3295) Unmounting /dev/= xvdp from /dev/xvdp.
[2013-03-13 13:04:49 1983] DEBUG (XendDomain= Info:1276) XendDomainInfo.destroyDevice: deviceClass =3D vbd, device =3D /d= ev/$
[2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:2869) _initDomain:sha= dow_memory=3D0x0, memory_static_max=3D0x40000000, me$
[2013-03-13= 13:04:49 1983] INFO (image:182) buildDomain os=3Dlinux dom=3D4 vcpus=3D1
[2013-03-13 13:04:49 1983] DEBUG (image:721) domid =A0 =A0 =A0 =A0 =A0=3D 4=
[2013-03-13 13:04:49 1983] DEBUG (image:722) memsize =A0 =A0 =A0= =A0=3D 1024
[2013-03-13 13:04:49 1983] DEBUG (image:723) image = =A0 =A0 =A0 =A0 =A0=3D /var/run/xend/boot/boot_kernel.bWctVs
[2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn =A0 =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:723) image =A0 =A0 =A0 =A0 = =A0=3D /var/run/xend/boot/boot_kernel.bWctVs
[2013-03-13 13:04:49= 1983] DEBUG (image:724) store_evtchn =A0 =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:725) console_evtchn =3D 2
[2013-03-13 13:04:49 1983] DEBUG (image:726) cmdline =A0 =A0 =A0 =A0= =3D root=3DUUID=3Df76e1730-ef98-43f3-ae37-caaff1dbe5c1 ro consol$
[2013-03-13 13:04:49 1983] DEBUG (image:727) ramdisk =A0 =A0 =A0 =A0=3D /v= ar/run/xend/boot/boot_ramdisk.GF_u4x
[2013-03-13 13:04:49 1983] DEBUG (image:728) vcpus =A0 =A0 =A0 =A0 =A0= =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:729) features =A0 = =A0 =A0 =3D
[2013-03-13 13:04:49 1983] DEBUG (image:730) flags = =A0 =A0 =A0 =A0 =A0=3D 0
[2013-03-13 13:04:49 1983] DEBUG (image:731) superpages =A0 =A0 =3D 0
=
[2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vb= d : {'uuid': '2601a8a4-f53c-e392-44b7-4d79ecb6bf$
[20= 13-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {&#= 39;virtual-device': '51712', 'device-type': $
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Sb-Voip1-DomU', 'frontend': '/= l$
[2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDe= vice: vif : {'ip': '192.168.129.55', 'mac': '00= :16:3e:35$
[2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: wri= ting {'mac': '00:16:3e:35:82:be', 'handle': '0&= #39;,$
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevCon= troller: writing {'bridge': 'xenbr0', 'domain': = 9;Sb-Voip1-Do$
[2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:3426) Storing VM deta= ils: {'on_xend_stop': 'ignore', 'pool_name': 'P= o$
[2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:1795) Storing= domain details: {'console/ring-ref': '270105', 'image/= e$
[2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: wri= ting {'protocol': 'x86_64-abi', 'state': '1'= ;, 'b$
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) De= vController: writing {'domain': 'Sb-Voip1-DomU', 'front= end': '/l$
[2013-03-13 13:04:51 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:04:51 1983] DEBUG (DevControll= er:139) Waiting for devices tap2.
[2013-03-13 13:04:51 1983] DEBU= G (DevController:139) Waiting for devices vif.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusC= allback /local/domain/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 = 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domai= n/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 13:= 04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0= /backend/vif/4/0/hotplug-sta$
[2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139= ) Waiting for devices vkbd.
[2013-03-13 13:04:51 1983] DEBUG (Dev= Controller:139) Waiting for devices ioports.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es tap.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vif2.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices console.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for de= vices vscsi.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139)= Waiting for devices vbd.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712= .
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotp= lugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug$
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback = /local/domain/0/backend/vbd/4/51712/hotplug$
[2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices irq.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain Sb-Voip= 1-DomU (4) unpaused.
[2013-03-13 13:20:31 1983] DEBUG (XendDomain= Info:3077) XendDomainInfo.destroy: domid=3D4
[2013-03-13 13:20:32= 1983] DEBUG (XendDomainInfo:2402) Destroying device model
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devic= es
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removin= g vif/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Re= leasing devices
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0<= /div>
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomain= Info.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-0= 3-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing console/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D console, device =3D c$
[2013-03-13= 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2= 013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroy= Device: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2407) No device model=
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing= devices
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) R= emoving vif/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-03-13 = 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[20= 13-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyD= evice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.c= reate(['vm', ['name', 'Sb-Voip1-DomU'], ['memor= y$
[2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2499) XendDom= ainInfo.constructDomain
[2013-03-13 13:23:03 1983] DEBUG (balloon:187) Balloon: 2058700 KiB fr= ee; need 16384; done.

[2013-03-13 13:23:03 1983] D= EBUG (XendDomain:476) Adding Domain: 5
[2013-03-13 13:23:03 1983]= DEBUG (XendDomainInfo:2842) XendDomainInfo.initDomain: 5 256
[2013-03-13 13:23:03 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm= on /dev/xvdp.
[2013-03-13 13:23:03 1983] DEBUG (DevController:95= ) DevController: writing {'backend-id': '0', 'virtual-d= evice': '5195$
[2013-03-13 13:23:03 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Domain-0', 'frontend': '/local= /$
[2013-03-13 13:23:03 1983] DEBUG (DevController:144) Waiting f= or 51952.
[2013-03-13 13:23:03 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:= 24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be con= nected. Hotplug scripts not $
Traceback (most recent call last):
[2013-03-13 13:24:43 1983= ] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be connected. Ho= tplug scripts not $
Traceback (most recent call last):
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice= (dev_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-pa= ckages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return self.getDeviceController(deviceClass).waitForDevice(dev= id)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xen= d/server/DevController.py", line 155, in waitForDevice
=A0 = =A0 (devid, self.deviceClass))
VmError: Device 51952 (vbd) could not be connected. Hotplug scripts no= t working.
[2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:488) = VM start failed
Traceback (most recent call last):
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 474, in start
=A0 =A0 XendTask.log_progress(31,= 60, self._initDomain)
=A0 File "/usr/local/lib/python2.7/di= st-packages/xen/xend/XendTask.py", line 209, in log_progress
=A0 =A0 retval =3D func(*args, **kwds)
=A0 File "/usr/l= ocal/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 284= 4, in _initDomain
=A0 =A0 self._configureBootloader()
= =A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3285, in _configureBootloader
=A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);
=A0= File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.= py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice(de= v_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom= ainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return sel= f.getDeviceController(deviceClass).waitForDevice(devid)
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.= py", line 155, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
=A0 File "/usr/local= /lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 1= 55, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not wo= rking.
[2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.= destroy: domid=3D5
[2013-03-13 13:24:43 1983] DEBUG (XendDomainIn= fo:2407) No device model
[2013-03-13 13:24:43 1983] DEBUG (XendDo= mainInfo:2409) Releasing devices
[2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:108) Domain construct= ion failed
Traceback (most recent call last):
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py&quo= t;, line 106, in create
=A0 =A0 vm.start()
=A0 File "/usr/local/lib/python2.7/d= ist-packages/xen/xend/XendDomainInfo.py", line 474, in start
=A0 =A0 XendTask.log_progress(31, 60, self._initDomain)
=A0 File= "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", l= ine 209, in log_progress
=A0 =A0 retval =3D func(*args, **kwds)
=A0 File "/usr/l= ocal/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 284= 4, in _initDomain
=A0 =A0 self._configureBootloader()
= =A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3285, in _configureBootloader
=A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);
=A0= File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.= py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice(de= v_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom= ainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return sel= f.getDeviceController(deviceClass).waitForDevice(devid)
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.= py", line 155, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
VmError: Device 51952 (vb= d) could not be connected. Hotplug scripts not working.
=A0(devid= , self.deviceClass))
VmError: Device 51952 (vbd) could not be con= nected. Hotplug scripts not working.


Regards,

Agya

On Wed, Mar 13, 2= 013 at 1:14 PM, agya naila <agya.naila@gmail.com> wrote:<= br>
I am not sure its due to high load in my cas= e since there is still no high load in server. I didn't run any program= that have high load and no client that accessing this server. I am suspect= ing the hotplug script. In my xend.log here is the logs :

server1@server1:~$ sudo tail /var/log/xen/xend.log
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 5171= 2.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugSt= atusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03= -13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es irq.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wai= ting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomai= n:1225) Domain DomU (4) unpaused.

any hints ?

regards,

Agya=


On Wed, = Mar 6, 2013 at 4:12 PM, Aaron Cossey <aaron.cossey@gmail.com><= /span> wrote:
I've=A0encountered=A0this frequently due to high io lo= ad. If you have monitoring of load and io, did you see anything happen just= before these errors started in the logs?
<= br clear=3D"all">

On Wed, Mar 6, 2013 at 1:35 PM= , agya naila <agya.naila@gmail.com> wrote:
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users



--f46d0438914b62c3ac04d7ce0890-- --===============8395776546211446022== 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 --===============8395776546211446022==-- From xen-users-bounces@lists.xen.org Wed Mar 13 13:06:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 13:06:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFlN8-0000vV-7R; Wed, 13 Mar 2013 13:05:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFlN6-0000vN-1p for xen-users@lists.xen.org; Wed, 13 Mar 2013 13:05:32 +0000 Received: from [85.158.143.99:4460] by server-3.bemta-4.messagelabs.com id 88/CA-02186-B9970415; Wed, 13 Mar 2013 13:05:31 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-16.tower-216.messagelabs.com!1363179811!17105778!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24192 invoked from network); 13 Mar 2013 13:03:31 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 13:03:31 -0000 Received: by mail-wg0-f50.google.com with SMTP id es5so938697wgb.5 for ; Wed, 13 Mar 2013 06:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=g7wjoLds4FcLjFymdr9gbfEq2Bo2PQN6BSYCh8iVOO0=; b=uRS9+zHMAkQmdoTvw36Wxg7Fb+pFtib4yDURelRFPGKi1dn0d3UGY5Hi7lX/L10N4a j1apGE36VPHm5UsPvcfBmGxIGT2vfYYo5jiaGP4+b9KQVL5D5kxvj2ui/dNPe1YtexkA Zx9fUUM7XZNiZo6eTohlctt7XWsjHvnfu/ALoLhWbfYPNgLfasa4Qw1yA+eeRZoyrJKs n2NfzEJgWSBICDxQgb03jukOIPIbkLj/vbWAIVEzVSbUkOMv2UgOzHw5n77EzBw48ONK XdbEMPqvTxJaqQqi8TDw5RsFED6vd4nreX8douvc8Jl0+zUoa9oc9oC5XnK4CQ1Wwxto m/Kg== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr26893860wid.29.1363179810765; Wed, 13 Mar 2013 06:03:30 -0700 (PDT) Received: by 10.216.208.143 with HTTP; Wed, 13 Mar 2013 06:03:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 14:03:30 +0100 Message-ID: From: agya naila To: Aaron Cossey Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Task blocked for more than 120 seconds. X-BeenThere: xen-users@lists.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="===============8395776546211446022==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8395776546211446022== Content-Type: multipart/alternative; boundary=f46d0438914b62c3ac04d7ce0890 --f46d0438914b62c3ac04d7ce0890 Content-Type: text/plain; charset=ISO-8859-1 I am also got this message when reboot the machine : udevd[243]: inotify_add_watch(6, /dev/dm-3, 10) failed : Invalid argument udevd[244]: inotify_add_watch(6, /dev/dm-1, 10) failed : Invalid argument Regards, Agya On Wed, Mar 13, 2013 at 1:34 PM, agya naila wrote: > Here more details of my machine log : > > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:3077) > XendDomainInfo.destroy: domid=3 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) > XendDomainInfo.handleShutdownWatch > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) > XendDomainInfo.handleShutdownWatch > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) > XendDomainInfo.handleShutdownWatch > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2402) Destroying device > model > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing console/0 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = console, device = c$ > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 > [2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2407) No device model > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:103) > XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ > [2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:103) > XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ > [2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:2499) > XendDomainInfo.constructDomain > [2013-03-13 13:04:46 1983] DEBUG (balloon:187) Balloon: 2058876 KiB free; > need 16384; done. > [2013-03-13 13:04:47 1983] DEBUG (XendDomain:476) Adding Domain: 4 > [2013-03-13 13:04:47 1983] DEBUG (XendDomainInfo:2842) > XendDomainInfo.initDomain: 4 256 > [2013-03-13 13:04:47 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm on > /dev/xvdp. > [2013-03-13 13:04:47 1983] DEBUG (DevController:95) DevController: writing > {'backend-id': '0', 'virtual-device': '5195$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:97) DevController: writing > {'domain': 'Domain-0', 'frontend': '/local/$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting for 51952. > [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/0/51952/hotplug$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/0/51952/hotplug$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting for 51952. > [2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/0/51952/hotplug$ > [2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:47 4725] DEBUG (XendBootloader:113) Launching bootloader > as ['/usr/bin/pygrub', '--output=/var/run/x$ > [2013-03-13 13:04:49 1983] INFO (XendDomainInfo:3295) Unmounting /dev/xvdp > from /dev/xvdp. > [2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = /dev/$ > [2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:2869) > _initDomain:shadow_memory=0x0, memory_static_max=0x40000000, me$ > [2013-03-13 13:04:49 1983] INFO (image:182) buildDomain os=linux dom=4 > vcpus=1 > [2013-03-13 13:04:49 1983] DEBUG (image:721) domid = 4 > [2013-03-13 13:04:49 1983] DEBUG (image:722) memsize = 1024 > [2013-03-13 13:04:49 1983] DEBUG (image:723) image = > /var/run/xend/boot/boot_kernel.bWctVs > [2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn = 1 > [2013-03-13 13:04:49 1983] DEBUG (image:723) image = > /var/run/xend/boot/boot_kernel.bWctVs > [2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn = 1 > [2013-03-13 13:04:49 1983] DEBUG (image:725) console_evtchn = 2 > [2013-03-13 13:04:49 1983] DEBUG (image:726) cmdline = > root=UUID=f76e1730-ef98-43f3-ae37-caaff1dbe5c1 ro consol$ > [2013-03-13 13:04:49 1983] DEBUG (image:727) ramdisk = > /var/run/xend/boot/boot_ramdisk.GF_u4x > [2013-03-13 13:04:49 1983] DEBUG (image:728) vcpus = 1 > [2013-03-13 13:04:49 1983] DEBUG (image:729) features = > [2013-03-13 13:04:49 1983] DEBUG (image:730) flags = 0 > [2013-03-13 13:04:49 1983] DEBUG (image:731) superpages = 0 > [2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vbd : > {'uuid': '2601a8a4-f53c-e392-44b7-4d79ecb6bf$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing > {'virtual-device': '51712', 'device-type': $ > [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing > {'domain': 'Sb-Voip1-DomU', 'frontend': '/l$ > [2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vif : > {'ip': '192.168.129.55', 'mac': '00:16:3e:35$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing > {'mac': '00:16:3e:35:82:be', 'handle': '0',$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing > {'bridge': 'xenbr0', 'domain': 'Sb-Voip1-Do$ > [2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:3426) Storing VM details: > {'on_xend_stop': 'ignore', 'pool_name': 'Po$ > [2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:1795) Storing domain > details: {'console/ring-ref': '270105', 'image/e$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing > {'protocol': 'x86_64-abi', 'state': '1', 'b$ > [2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: writing > {'domain': 'Sb-Voip1-DomU', 'frontend': '/l$ > [2013-03-13 13:04:51 1983] DEBUG (XendDomainInfo:1882) > XendDomainInfo.handleShutdownWatch > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > tap2. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vif. > [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0. > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vif/4/0/hotplug-sta$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vif/4/0/hotplug-sta$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vif/4/0/hotplug-sta$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vif/4/0/hotplug-sta$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vkbd. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > ioports. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > tap. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vif2. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > console. > [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vscsi. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vbd. > [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/4/51712/hotplug$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/4/51712/hotplug$ > [2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback > 1. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > irq. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vfb. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > pci. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vusb. > [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices > vtpm. > [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain Sb-Voip1-DomU (4) > unpaused. > [2013-03-13 13:20:31 1983] DEBUG (XendDomainInfo:3077) > XendDomainInfo.destroy: domid=4 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2402) Destroying device > model > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing console/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = console, device = c$ > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2407) No device model > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712 > [2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) > XendDomainInfo.destroyDevice: deviceClass = vbd, device = vbd/5$ > [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:103) > XendDomainInfo.create(['vm', ['name', 'Sb-Voip1-DomU'], ['memory$ > [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2499) > XendDomainInfo.constructDomain > [2013-03-13 13:23:03 1983] DEBUG (balloon:187) Balloon: 2058700 KiB free; > need 16384; done. > > [2013-03-13 13:23:03 1983] DEBUG (XendDomain:476) Adding Domain: 5 > [2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2842) > XendDomainInfo.initDomain: 5 256 > [2013-03-13 13:23:03 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm on > /dev/xvdp. > [2013-03-13 13:23:03 1983] DEBUG (DevController:95) DevController: writing > {'backend-id': '0', 'virtual-device': '5195$ > [2013-03-13 13:23:03 1983] DEBUG (DevController:97) DevController: writing > {'domain': 'Domain-0', 'frontend': '/local/$ > [2013-03-13 13:23:03 1983] DEBUG (DevController:144) Waiting for 51952. > [2013-03-13 13:23:03 1983] DEBUG (DevController:628) hotplugStatusCallback > /local/domain/0/backend/vbd/0/51952/hotplug$ > [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) > could not be connected. Hotplug scripts not $ > Traceback (most recent call last): > [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) > could not be connected. Hotplug scripts not $ > Traceback (most recent call last): > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3989, in create_vbd > self._waitForDevice(dev_type, devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2330, in _waitForDevice > return self.getDeviceController(deviceClass).waitForDevice(devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", > line 155, in waitForDevice > (devid, self.deviceClass)) > VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not > working. > [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:488) VM start failed > Traceback (most recent call last): > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 474, in start > XendTask.log_progress(31, 60, self._initDomain) > File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line > 209, in log_progress > retval = func(*args, **kwds) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2844, in _initDomain > self._configureBootloader() > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3285, in _configureBootloader > mounted_vbd_uuid = dom0.create_vbd(vbd, disk); > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3989, in create_vbd > self._waitForDevice(dev_type, devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2330, in _waitForDevice > return self.getDeviceController(deviceClass).waitForDevice(devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", > line 155, in waitForDevice > (devid, self.deviceClass)) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", > line 155, in waitForDevice > (devid, self.deviceClass)) > VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not > working. > [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:3077) > XendDomainInfo.destroy: domid=5 > [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:2407) No device model > [2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:2409) Releasing devices > [2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:108) Domain construction > failed > Traceback (most recent call last): > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 106, in create > vm.start() > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 474, in start > XendTask.log_progress(31, 60, self._initDomain) > File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", line > 209, in log_progress > retval = func(*args, **kwds) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2844, in _initDomain > self._configureBootloader() > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3285, in _configureBootloader > mounted_vbd_uuid = dom0.create_vbd(vbd, disk); > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 3989, in create_vbd > self._waitForDevice(dev_type, devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line > 2330, in _waitForDevice > return self.getDeviceController(deviceClass).waitForDevice(devid) > File > "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.py", > line 155, in waitForDevice > (devid, self.deviceClass)) > VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not > working. > (devid, self.deviceClass)) > VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not > working. > > > Regards, > > Agya > > On Wed, Mar 13, 2013 at 1:14 PM, agya naila wrote: > >> I am not sure its due to high load in my case since there is still no >> high load in server. I didn't run any program that have high load and no >> client that accessing this server. I am suspecting the hotplug script. In >> my xend.log here is the logs : >> >> server1@server1:~$ sudo tail /var/log/xen/xend.log >> [2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:628) >> hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:628) >> hotplugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:642) >> hotplugStatusCallback 1. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> irq. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> vfb. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> pci. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> vusb. >> [2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devices >> vtpm. >> [2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain DomU (4) >> unpaused. >> >> any hints ? >> >> regards, >> >> Agya >> >> >> On Wed, Mar 6, 2013 at 4:12 PM, Aaron Cossey wrote: >> >>> I've encountered this frequently due to high io load. If you have >>> monitoring of load and io, did you see anything happen just before these >>> errors started in the logs? >>> >>> Aaron Cossey >>> aaron.cossey@gmail.com >>> >>> >>> On Wed, Mar 6, 2013 at 1:35 PM, agya naila wrote: >>> >>>> Hi all, >>>> >>>> Today I got problem below and my domU become unresponsive and I should >>>> restart the pc to make it running properly again. >>>> >>>> [ 240.172092] INFO: task kworker/u:0:5 blocked for more than 120 >>>> seconds. >>>> [ 240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.172376] INFO: task jbd2/xvda1-8:153 blocked for more than 120 >>>> seconds. >>>> [ 240.172388] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.172610] INFO: task flush-202:0:421 blocked for more than 120 >>>> seconds. >>>> [ 240.172619] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.172946] INFO: task freeswitch:1030 blocked for more than 120 >>>> seconds. >>>> [ 240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173215] INFO: task freeswitch:1033 blocked for more than 120 >>>> seconds. >>>> [ 240.173225] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173454] INFO: task freeswitch:1036 blocked for more than 120 >>>> seconds. >>>> [ 240.173464] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173670] INFO: task freeswitch:1044 blocked for more than 120 >>>> seconds. >>>> [ 240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173828] INFO: task freeswitch:1046 blocked for more than 120 >>>> seconds. >>>> [ 240.173839] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> [ 240.173986] INFO: task freeswitch:1047 blocked for more than 120 >>>> seconds. >>>> [ 240.173996] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" >>>> disables this message. >>>> >>>> Does any body have clue regarding this problem? >>>> >>>> Regards, >>>> >>>> Agya >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> > --f46d0438914b62c3ac04d7ce0890 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am also got this message when reboot the machine :

udevd[243]: inotify_add_watch(6, /dev/dm-3, 10) failed : Invalid argument=
udevd[244]: inotify_add_watch(6, /dev/dm-1, 10) failed : Invalid= argument

Regards,

Agya

On Wed, Mar 13, 2013 at 1:34 PM, agya naila <agya= .naila@gmail.com> wrote:
Here more details of my machine log :
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:3077) Xe= ndDomainInfo.destroy: domid=3D3
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:03:05 1983] DEBUG (XendDomainI= nfo:1882) XendDomainInfo.handleShutdownWatch
[2013-03-13 13:03:05= 1983] DEBUG (XendDomainInfo:2402) Destroying device model
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2409) Releasing devic= es
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removin= g vif/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) Xe= ndDomainInfo.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing consol= e/0
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDo= mainInfo.destroyDevice: deviceClass =3D console, device =3D c$
[2= 013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2013-03-13 13:03:05 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:03:06 1983] DEBUG (XendDomainInfo:2407) No device model
[2013= -03-13 13:03:06 1983] DEBUG (XendDomainInfo:2409) Releasing devices
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vif/0<= /div>
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomain= Info.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-0= 3-13 13:03:06 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm&#= 39;, ['name', 'Sb-Voip1-DomU'], ['memory$
[2013-03-13 13:03:06 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13= 13:04:46 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.create(['vm&#= 39;, ['name', 'Sb-Voip1-DomU'], ['memory$
[2013-03-13 13:04:46 1983] DEBUG (XendDomainInfo:2499) XendDomainInfo.= constructDomain
[2013-03-13 13:04:46 1983] DEBUG (balloon:187) Ba= lloon: 2058876 KiB free; need 16384; done.
[2013-03-13 13:04:47 1= 983] DEBUG (XendDomain:476) Adding Domain: 4
[2013-03-13 13:04:47 1983] DEBUG (XendDomainInfo:2842) XendDomainInfo.= initDomain: 4 256
[2013-03-13 13:04:47 1983] INFO (XendDomainInfo= :3276) Mounting drbd-vm on /dev/xvdp.
[2013-03-13 13:04:47 1983] = DEBUG (DevController:95) DevController: writing {'backend-id': '= ;0', 'virtual-device': '5195$
[2013-03-13 13:04:47 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Domain-0', 'frontend': '/local= /$
[2013-03-13 13:04:47 1983] DEBUG (DevController:144) Waiting f= or 51952.
[2013-03-13 13:04:47 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:= 04:47 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0= /backend/vbd/0/51952/hotplug$
[2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:47 1983] DEBUG (DevController:144) Wait= ing for 51952.
[2013-03-13 13:04:47 1983] DEBUG (DevController:62= 8) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:04:47 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:47 4725] DEBUG (XendBootloader:113) Lau= nching bootloader as ['/usr/bin/pygrub', '--output=3D/var/run/x= $
[2013-03-13 13:04:49 1983] INFO (XendDomainInfo:3295) Unmounting /dev/= xvdp from /dev/xvdp.
[2013-03-13 13:04:49 1983] DEBUG (XendDomain= Info:1276) XendDomainInfo.destroyDevice: deviceClass =3D vbd, device =3D /d= ev/$
[2013-03-13 13:04:49 1983] DEBUG (XendDomainInfo:2869) _initDomain:sha= dow_memory=3D0x0, memory_static_max=3D0x40000000, me$
[2013-03-13= 13:04:49 1983] INFO (image:182) buildDomain os=3Dlinux dom=3D4 vcpus=3D1
[2013-03-13 13:04:49 1983] DEBUG (image:721) domid =A0 =A0 =A0 =A0 =A0=3D 4=
[2013-03-13 13:04:49 1983] DEBUG (image:722) memsize =A0 =A0 =A0= =A0=3D 1024
[2013-03-13 13:04:49 1983] DEBUG (image:723) image = =A0 =A0 =A0 =A0 =A0=3D /var/run/xend/boot/boot_kernel.bWctVs
[2013-03-13 13:04:49 1983] DEBUG (image:724) store_evtchn =A0 =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:723) image =A0 =A0 =A0 =A0 = =A0=3D /var/run/xend/boot/boot_kernel.bWctVs
[2013-03-13 13:04:49= 1983] DEBUG (image:724) store_evtchn =A0 =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:725) console_evtchn =3D 2
[2013-03-13 13:04:49 1983] DEBUG (image:726) cmdline =A0 =A0 =A0 =A0= =3D root=3DUUID=3Df76e1730-ef98-43f3-ae37-caaff1dbe5c1 ro consol$
[2013-03-13 13:04:49 1983] DEBUG (image:727) ramdisk =A0 =A0 =A0 =A0=3D /v= ar/run/xend/boot/boot_ramdisk.GF_u4x
[2013-03-13 13:04:49 1983] DEBUG (image:728) vcpus =A0 =A0 =A0 =A0 =A0= =3D 1
[2013-03-13 13:04:49 1983] DEBUG (image:729) features =A0 = =A0 =A0 =3D
[2013-03-13 13:04:49 1983] DEBUG (image:730) flags = =A0 =A0 =A0 =A0 =A0=3D 0
[2013-03-13 13:04:49 1983] DEBUG (image:731) superpages =A0 =A0 =3D 0
=
[2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDevice: vb= d : {'uuid': '2601a8a4-f53c-e392-44b7-4d79ecb6bf$
[20= 13-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: writing {&#= 39;virtual-device': '51712', 'device-type': $
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Sb-Voip1-DomU', 'frontend': '/= l$
[2013-03-13 13:04:50 1983] INFO (XendDomainInfo:2358) createDe= vice: vif : {'ip': '192.168.129.55', 'mac': '00= :16:3e:35$
[2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: wri= ting {'mac': '00:16:3e:35:82:be', 'handle': '0&= #39;,$
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) DevCon= troller: writing {'bridge': 'xenbr0', 'domain': = 9;Sb-Voip1-Do$
[2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:3426) Storing VM deta= ils: {'on_xend_stop': 'ignore', 'pool_name': 'P= o$
[2013-03-13 13:04:50 1983] DEBUG (XendDomainInfo:1795) Storing= domain details: {'console/ring-ref': '270105', 'image/= e$
[2013-03-13 13:04:50 1983] DEBUG (DevController:95) DevController: wri= ting {'protocol': 'x86_64-abi', 'state': '1'= ;, 'b$
[2013-03-13 13:04:50 1983] DEBUG (DevController:97) De= vController: writing {'domain': 'Sb-Voip1-DomU', 'front= end': '/l$
[2013-03-13 13:04:51 1983] DEBUG (XendDomainInfo:1882) XendDomainInfo.= handleShutdownWatch
[2013-03-13 13:04:51 1983] DEBUG (DevControll= er:139) Waiting for devices tap2.
[2013-03-13 13:04:51 1983] DEBU= G (DevController:139) Waiting for devices vif.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusC= allback /local/domain/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 = 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domai= n/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vif/4/0/hotplug-sta$
[2013-03-13 13:= 04:51 1983] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0= /backend/vif/4/0/hotplug-sta$
[2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139= ) Waiting for devices vkbd.
[2013-03-13 13:04:51 1983] DEBUG (Dev= Controller:139) Waiting for devices ioports.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es tap.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vif2.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices console.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 0.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for de= vices vscsi.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139)= Waiting for devices vbd.
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 51712= .
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotp= lugStatusCallback /local/domain/0/backend/vbd/4/51712/hotplug$
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCallback = /local/domain/0/backend/vbd/4/51712/hotplug$
[2013-03-13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCall= back 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices irq.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevContro= ller:139) Waiting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomain:1225) Domain Sb-Voip= 1-DomU (4) unpaused.
[2013-03-13 13:20:31 1983] DEBUG (XendDomain= Info:3077) XendDomainInfo.destroy: domid=3D4
[2013-03-13 13:20:32= 1983] DEBUG (XendDomainInfo:2402) Destroying device model
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing devic= es
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removin= g vif/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Re= leasing devices
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vif/0<= /div>
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomain= Info.destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-0= 3-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing console/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D console, device =3D c$
[2013-03-13= 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[2= 013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroy= Device: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2407) No device model=
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2409) Releasing= devices
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:2415) R= emoving vif/0
[2013-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.= destroyDevice: deviceClass =3D vif, device =3D vif/0
[2013-03-13 = 13:20:32 1983] DEBUG (XendDomainInfo:2415) Removing vbd/51712
[20= 13-03-13 13:20:32 1983] DEBUG (XendDomainInfo:1276) XendDomainInfo.destroyD= evice: deviceClass =3D vbd, device =3D vbd/5$
[2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:103) XendDomainInfo.c= reate(['vm', ['name', 'Sb-Voip1-DomU'], ['memor= y$
[2013-03-13 13:23:03 1983] DEBUG (XendDomainInfo:2499) XendDom= ainInfo.constructDomain
[2013-03-13 13:23:03 1983] DEBUG (balloon:187) Balloon: 2058700 KiB fr= ee; need 16384; done.

[2013-03-13 13:23:03 1983] D= EBUG (XendDomain:476) Adding Domain: 5
[2013-03-13 13:23:03 1983]= DEBUG (XendDomainInfo:2842) XendDomainInfo.initDomain: 5 256
[2013-03-13 13:23:03 1983] INFO (XendDomainInfo:3276) Mounting drbd-vm= on /dev/xvdp.
[2013-03-13 13:23:03 1983] DEBUG (DevController:95= ) DevController: writing {'backend-id': '0', 'virtual-d= evice': '5195$
[2013-03-13 13:23:03 1983] DEBUG (DevController:97) DevController: wri= ting {'domain': 'Domain-0', 'frontend': '/local= /$
[2013-03-13 13:23:03 1983] DEBUG (DevController:144) Waiting f= or 51952.
[2013-03-13 13:23:03 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/0/51952/hotplug$
[2013-03-13 13:= 24:43 1983] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be con= nected. Hotplug scripts not $
Traceback (most recent call last):
[2013-03-13 13:24:43 1983= ] ERROR (XendDomainInfo:3993) Device 51952 (vbd) could not be connected. Ho= tplug scripts not $
Traceback (most recent call last):
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice= (dev_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-pa= ckages/xen/xend/XendDomainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return self.getDeviceController(deviceClass).waitForDevice(dev= id)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xen= d/server/DevController.py", line 155, in waitForDevice
=A0 = =A0 (devid, self.deviceClass))
VmError: Device 51952 (vbd) could not be connected. Hotplug scripts no= t working.
[2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:488) = VM start failed
Traceback (most recent call last):
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 474, in start
=A0 =A0 XendTask.log_progress(31,= 60, self._initDomain)
=A0 File "/usr/local/lib/python2.7/di= st-packages/xen/xend/XendTask.py", line 209, in log_progress
=A0 =A0 retval =3D func(*args, **kwds)
=A0 File "/usr/l= ocal/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 284= 4, in _initDomain
=A0 =A0 self._configureBootloader()
= =A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3285, in _configureBootloader
=A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);
=A0= File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.= py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice(de= v_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom= ainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return sel= f.getDeviceController(deviceClass).waitForDevice(devid)
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.= py", line 155, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
=A0 File "/usr/local= /lib/python2.7/dist-packages/xen/xend/server/DevController.py", line 1= 55, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
VmError: Device 51952 (vbd) could not be connected. Hotplug scripts not wo= rking.
[2013-03-13 13:24:43 1983] DEBUG (XendDomainInfo:3077) XendDomainInfo.= destroy: domid=3D5
[2013-03-13 13:24:43 1983] DEBUG (XendDomainIn= fo:2407) No device model
[2013-03-13 13:24:43 1983] DEBUG (XendDo= mainInfo:2409) Releasing devices
[2013-03-13 13:24:43 1983] ERROR (XendDomainInfo:108) Domain construct= ion failed
Traceback (most recent call last):
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py&quo= t;, line 106, in create
=A0 =A0 vm.start()
=A0 File "/usr/local/lib/python2.7/d= ist-packages/xen/xend/XendDomainInfo.py", line 474, in start
=A0 =A0 XendTask.log_progress(31, 60, self._initDomain)
=A0 File= "/usr/local/lib/python2.7/dist-packages/xen/xend/XendTask.py", l= ine 209, in log_progress
=A0 =A0 retval =3D func(*args, **kwds)
=A0 File "/usr/l= ocal/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.py", line 284= 4, in _initDomain
=A0 =A0 self._configureBootloader()
= =A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainIn= fo.py", line 3285, in _configureBootloader
=A0 =A0 mounted_vbd_uuid =3D dom0.create_vbd(vbd, disk);
=A0= File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDomainInfo.= py", line 3989, in create_vbd
=A0 =A0 self._waitForDevice(de= v_type, devid)
=A0 File "/usr/local/lib/python2.7/dist-packages/xen/xend/XendDom= ainInfo.py", line 2330, in _waitForDevice
=A0 =A0 return sel= f.getDeviceController(deviceClass).waitForDevice(devid)
=A0 File = "/usr/local/lib/python2.7/dist-packages/xen/xend/server/DevController.= py", line 155, in waitForDevice
=A0 =A0 (devid, self.deviceClass))
VmError: Device 51952 (vb= d) could not be connected. Hotplug scripts not working.
=A0(devid= , self.deviceClass))
VmError: Device 51952 (vbd) could not be con= nected. Hotplug scripts not working.


Regards,

Agya

On Wed, Mar 13, 2= 013 at 1:14 PM, agya naila <agya.naila@gmail.com> wrote:<= br>
I am not sure its due to high load in my cas= e since there is still no high load in server. I didn't run any program= that have high load and no client that accessing this server. I am suspect= ing the hotplug script. In my xend.log here is the logs :

server1@server1:~$ sudo tail /var/log/xen/xend.log
[2013-03-13 13:04:51 1983] DEBUG (DevController:144) Waiting for 5171= 2.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugSt= atusCallback /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03-13 13:04:51 1983] DEBUG (DevController:628) hotplugStatusCall= back /local/domain/0/backend/vbd/4/51712/hotplug-status.
[2013-03= -13 13:04:51 1983] DEBUG (DevController:642) hotplugStatusCallback 1.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es irq.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wait= ing for devices vfb.
[2013-03-13 13:04:51 1983] DEBUG (DevControl= ler:139) Waiting for devices pci.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Waiting for devic= es vusb.
[2013-03-13 13:04:51 1983] DEBUG (DevController:139) Wai= ting for devices vtpm.
[2013-03-13 13:04:51 1983] INFO (XendDomai= n:1225) Domain DomU (4) unpaused.

any hints ?

regards,

Agya=


On Wed, = Mar 6, 2013 at 4:12 PM, Aaron Cossey <aaron.cossey@gmail.com><= /span> wrote:
I've=A0encountered=A0this frequently due to high io lo= ad. If you have monitoring of load and io, did you see anything happen just= before these errors started in the logs?
<= br clear=3D"all">

On Wed, Mar 6, 2013 at 1:35 PM= , agya naila <agya.naila@gmail.com> wrote:
Hi all,

Today I got problem below and my domU= become unresponsive and I should restart the pc to make it running properl= y again.=A0

[ =A0240.172092] INFO: task kworker/u:= 0:5 blocked for more than 120 seconds.
[ =A0240.172110] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.172376] INFO: task jbd= 2/xvda1-8:153 blocked for more than 120 seconds.
[ =A0240.172388]= "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables t= his message.
[ =A0240.172610] INFO: task flush-202:0:421 blocked for more than 120 = seconds.
[ =A0240.172619] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.172946] = INFO: task freeswitch:1030 blocked for more than 120 seconds.
[ =A0240.172957] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173215] INFO: task fre= eswitch:1033 blocked for more than 120 seconds.
[ =A0240.173225] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173454] INFO: task freeswitch:1036 blocked for more than 120 = seconds.
[ =A0240.173464] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.
[ =A0240.173670] = INFO: task freeswitch:1044 blocked for more than 120 seconds.
[ =A0240.173680] "echo 0 > /proc/sys/kernel/hung_task_timeout_= secs" disables this message.
[ =A0240.173828] INFO: task fre= eswitch:1046 blocked for more than 120 seconds.
[ =A0240.173839] = "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables th= is message.
[ =A0240.173986] INFO: task freeswitch:1047 blocked for more than 120 = seconds.
[ =A0240.173996] "echo 0 > /proc/sys/kernel/hung= _task_timeout_secs" disables this message.

Do= es any body have clue regarding this problem?

Regards,

Agya

_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users



--f46d0438914b62c3ac04d7ce0890-- --===============8395776546211446022== 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 --===============8395776546211446022==-- From xen-users-bounces@lists.xen.org Wed Mar 13 14:12:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 14:12: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 1UFmOz-0002g8-Mh; Wed, 13 Mar 2013 14:11:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFmOx-0002g3-U0 for xen-users@lists.xen.org; Wed, 13 Mar 2013 14:11:32 +0000 Received: from [85.158.139.211:15236] by server-11.bemta-5.messagelabs.com id DB/91-27486-21980415; Wed, 13 Mar 2013 14:11:30 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1363183860!18034291!1 X-Originating-IP: [209.85.214.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26282 invoked from network); 13 Mar 2013 14:11:00 -0000 Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com) (209.85.214.43) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 14:11:00 -0000 Received: by mail-bk0-f43.google.com with SMTP id jm19so473447bkc.16 for ; Wed, 13 Mar 2013 07:11:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=7ZYWW3sWvn+YNEVvbQ9+Snz+ZTHxG7ktZFjc8ek9OQ4=; b=SsmdCs6aDZOBN/CLLPHg37OSmV7OsLd1s/IpfXgRdvxXDoM2deokQ1W1gS7YDrRYMI dY1QziwdOeXY67Bp6Z3QbfZ7R9ybeF5ZmU8+zVlI/CEEdtPwaAj4fJP1szROKHnqQtoJ yelzDu4ODzuN/iydbGTYVP0IvGyfj4EBi1xRijIADn8/5ajgC/VQfvnNLDaGxYLehbe9 8aKiFg8FkVSB7KJQMkToPVzpPx+rwQhW1K1tdNrrgELa5NTDitPT/iM+g+Sn4Z6f/zr+ X4BC6tKog092mSU0B00+tPP3pqhsUE1GvUWQibZzglSAOWeMmWiOyHNyXcV43FAZ4md2 AFGQ== MIME-Version: 1.0 X-Received: by 10.204.171.136 with SMTP id h8mr7633910bkz.18.1363183860318; Wed, 13 Mar 2013 07:11:00 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Wed, 13 Mar 2013 07:11:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 15:11:00 +0100 Message-ID: From: Sylvain Munaut To: "xen-users@lists.xen.org\"" X-Gm-Message-State: ALoCoQlLjW/DO9aYDfBbIAknrMSipVUhw9wjnAFuEazz2XatM627e07jZyfHsZlrBdmfPFqCjLQH Subject: Re: [Xen-users] Race condition in sending gratuitous ARP for live migration ? X-BeenThere: xen-users@lists.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, So responding to myself: There is indeed a race condition ... and it was fixed 1.5 years ago by Laszlo Ersek. Unfortunately the fix isn't present in the Ubuntu 12.04 LTS kernel, nor in the stable 3.2 tree :( http://xen.1045712.n5.nabble.com/lost-gARP-after-live-migration-td4531697.html https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/xen-netfront.c?id=08e34eb14fe4cfd934b5c169a7682a969457c4ea Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 14:12:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 14:12: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 1UFmOz-0002g8-Mh; Wed, 13 Mar 2013 14:11:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFmOx-0002g3-U0 for xen-users@lists.xen.org; Wed, 13 Mar 2013 14:11:32 +0000 Received: from [85.158.139.211:15236] by server-11.bemta-5.messagelabs.com id DB/91-27486-21980415; Wed, 13 Mar 2013 14:11:30 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1363183860!18034291!1 X-Originating-IP: [209.85.214.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26282 invoked from network); 13 Mar 2013 14:11:00 -0000 Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com) (209.85.214.43) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 14:11:00 -0000 Received: by mail-bk0-f43.google.com with SMTP id jm19so473447bkc.16 for ; Wed, 13 Mar 2013 07:11:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=7ZYWW3sWvn+YNEVvbQ9+Snz+ZTHxG7ktZFjc8ek9OQ4=; b=SsmdCs6aDZOBN/CLLPHg37OSmV7OsLd1s/IpfXgRdvxXDoM2deokQ1W1gS7YDrRYMI dY1QziwdOeXY67Bp6Z3QbfZ7R9ybeF5ZmU8+zVlI/CEEdtPwaAj4fJP1szROKHnqQtoJ yelzDu4ODzuN/iydbGTYVP0IvGyfj4EBi1xRijIADn8/5ajgC/VQfvnNLDaGxYLehbe9 8aKiFg8FkVSB7KJQMkToPVzpPx+rwQhW1K1tdNrrgELa5NTDitPT/iM+g+Sn4Z6f/zr+ X4BC6tKog092mSU0B00+tPP3pqhsUE1GvUWQibZzglSAOWeMmWiOyHNyXcV43FAZ4md2 AFGQ== MIME-Version: 1.0 X-Received: by 10.204.171.136 with SMTP id h8mr7633910bkz.18.1363183860318; Wed, 13 Mar 2013 07:11:00 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Wed, 13 Mar 2013 07:11:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 15:11:00 +0100 Message-ID: From: Sylvain Munaut To: "xen-users@lists.xen.org\"" X-Gm-Message-State: ALoCoQlLjW/DO9aYDfBbIAknrMSipVUhw9wjnAFuEazz2XatM627e07jZyfHsZlrBdmfPFqCjLQH Subject: Re: [Xen-users] Race condition in sending gratuitous ARP for live migration ? X-BeenThere: xen-users@lists.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, So responding to myself: There is indeed a race condition ... and it was fixed 1.5 years ago by Laszlo Ersek. Unfortunately the fix isn't present in the Ubuntu 12.04 LTS kernel, nor in the stable 3.2 tree :( http://xen.1045712.n5.nabble.com/lost-gARP-after-live-migration-td4531697.html https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/xen-netfront.c?id=08e34eb14fe4cfd934b5c169a7682a969457c4ea Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 14:13:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 14:13: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 1UFmQM-0002kW-D2; Wed, 13 Mar 2013 14:12:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFmQK-0002kJ-MO for xen-users@lists.xen.org; Wed, 13 Mar 2013 14:12:56 +0000 Received: from [85.158.143.99:2421] by server-3.bemta-4.messagelabs.com id 88/ED-02186-76980415; Wed, 13 Mar 2013 14:12:55 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1363183974!28342044!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22518 invoked from network); 13 Mar 2013 14:12:54 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 14:12:54 -0000 X-IronPort-AV: E=Sophos;i="4.84,837,1355097600"; d="scan'208";a="2466573" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Mar 2013 14:12:55 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Wed, 13 Mar 2013 14:12:54 +0000 Message-ID: <1363183973.32410.182.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sylvain Munaut Date: Wed, 13 Mar 2013 14:12:53 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org\"" Subject: Re: [Xen-users] Race condition in sending gratuitous ARP for live migration ? X-BeenThere: xen-users@lists.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, 2013-03-13 at 14:11 +0000, Sylvain Munaut wrote: > Hi, > > So responding to myself: There is indeed a race condition ... and it > was fixed 1.5 years ago by Laszlo Ersek. > Unfortunately the fix isn't present in the Ubuntu 12.04 LTS kernel, > nor in the stable 3.2 tree :( Can you file a bug with Ubuntu please? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 14:13:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 14:13: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 1UFmQM-0002kW-D2; Wed, 13 Mar 2013 14:12:58 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFmQK-0002kJ-MO for xen-users@lists.xen.org; Wed, 13 Mar 2013 14:12:56 +0000 Received: from [85.158.143.99:2421] by server-3.bemta-4.messagelabs.com id 88/ED-02186-76980415; Wed, 13 Mar 2013 14:12:55 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1363183974!28342044!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22518 invoked from network); 13 Mar 2013 14:12:54 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 14:12:54 -0000 X-IronPort-AV: E=Sophos;i="4.84,837,1355097600"; d="scan'208";a="2466573" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Mar 2013 14:12:55 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Wed, 13 Mar 2013 14:12:54 +0000 Message-ID: <1363183973.32410.182.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Sylvain Munaut Date: Wed, 13 Mar 2013 14:12:53 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org\"" Subject: Re: [Xen-users] Race condition in sending gratuitous ARP for live migration ? X-BeenThere: xen-users@lists.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, 2013-03-13 at 14:11 +0000, Sylvain Munaut wrote: > Hi, > > So responding to myself: There is indeed a race condition ... and it > was fixed 1.5 years ago by Laszlo Ersek. > Unfortunately the fix isn't present in the Ubuntu 12.04 LTS kernel, > nor in the stable 3.2 tree :( Can you file a bug with Ubuntu please? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 14:24:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 14:24: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 1UFmbD-0003O0-7z; Wed, 13 Mar 2013 14:24:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFmbB-0003Nv-Nc for xen-users@lists.xen.org; Wed, 13 Mar 2013 14:24:09 +0000 Received: from [85.158.139.83:28147] by server-16.bemta-5.messagelabs.com id 36/0B-02543-90C80415; Wed, 13 Mar 2013 14:24:09 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1363184648!21332140!1 X-Originating-IP: [209.85.214.52] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23811 invoked from network); 13 Mar 2013 14:24:08 -0000 Received: from mail-bk0-f52.google.com (HELO mail-bk0-f52.google.com) (209.85.214.52) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 14:24:08 -0000 Received: by mail-bk0-f52.google.com with SMTP id jk13so483600bkc.39 for ; Wed, 13 Mar 2013 07:24:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=EAY9mGsddcKRRzJHRLWIjuFGWgblql5FgQWTrsHvHKw=; b=Cs/kLxMkbkFoQiOokRUpJjcE37w1gVdxmci3GZpCNy//iKzdvRxX37SQrnzhG+yyT0 v2qh1c0o+gjUROoabinCRVhMenarVlktuB07B9MQhwRcbISH1QZfBGE+cGgD8ZgRCzMa ZjCcqLy6Ube8aDZA7c3Ch3gofMKc0PvEumLLk0QkP1IYcyxIbHtdZzh027EaYMo6vBWb eCIwdL18qSqikpYqEmQ4Ed8YWFyy4QhOm3eAXR8iKI2DJ0LtHfSt6E+cX86xXVU1lp2V jgZCDrt/J8kl6iay81Bp4lO9LdqwX6k0wWIgNBkC6aXibQIfoRhnTZ9jF2BDf7XyNSBT vzvQ== MIME-Version: 1.0 X-Received: by 10.205.32.208 with SMTP id sl16mr7842169bkb.27.1363184648083; Wed, 13 Mar 2013 07:24:08 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Wed, 13 Mar 2013 07:24:07 -0700 (PDT) In-Reply-To: <1363183973.32410.182.camel@zakaz.uk.xensource.com> References: <1363183973.32410.182.camel@zakaz.uk.xensource.com> Date: Wed, 13 Mar 2013 15:24:07 +0100 Message-ID: From: Sylvain Munaut To: Ian Campbell X-Gm-Message-State: ALoCoQnpqi8KWZYcgXHMoxyPe3X9OSzMMXW/LGLaqvd8inhG4jJOx4lg7UrEzGjCMw/4lhlImig9 Cc: "xen-users@lists.xen.org\"" Subject: Re: [Xen-users] Race condition in sending gratuitous ARP for live migration ? X-BeenThere: xen-users@lists.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, >> So responding to myself: There is indeed a race condition ... and it >> was fixed 1.5 years ago by Laszlo Ersek. >> Unfortunately the fix isn't present in the Ubuntu 12.04 LTS kernel, >> nor in the stable 3.2 tree :( > > Can you file a bug with Ubuntu please? Already did :) I'd like to not have to maintain my own kernel for the VMs :p https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1154608 Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 14:24:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 14:24: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 1UFmbD-0003O0-7z; Wed, 13 Mar 2013 14:24:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFmbB-0003Nv-Nc for xen-users@lists.xen.org; Wed, 13 Mar 2013 14:24:09 +0000 Received: from [85.158.139.83:28147] by server-16.bemta-5.messagelabs.com id 36/0B-02543-90C80415; Wed, 13 Mar 2013 14:24:09 +0000 X-Env-Sender: s.munaut@whatever-company.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1363184648!21332140!1 X-Originating-IP: [209.85.214.52] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23811 invoked from network); 13 Mar 2013 14:24:08 -0000 Received: from mail-bk0-f52.google.com (HELO mail-bk0-f52.google.com) (209.85.214.52) by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 14:24:08 -0000 Received: by mail-bk0-f52.google.com with SMTP id jk13so483600bkc.39 for ; Wed, 13 Mar 2013 07:24:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=EAY9mGsddcKRRzJHRLWIjuFGWgblql5FgQWTrsHvHKw=; b=Cs/kLxMkbkFoQiOokRUpJjcE37w1gVdxmci3GZpCNy//iKzdvRxX37SQrnzhG+yyT0 v2qh1c0o+gjUROoabinCRVhMenarVlktuB07B9MQhwRcbISH1QZfBGE+cGgD8ZgRCzMa ZjCcqLy6Ube8aDZA7c3Ch3gofMKc0PvEumLLk0QkP1IYcyxIbHtdZzh027EaYMo6vBWb eCIwdL18qSqikpYqEmQ4Ed8YWFyy4QhOm3eAXR8iKI2DJ0LtHfSt6E+cX86xXVU1lp2V jgZCDrt/J8kl6iay81Bp4lO9LdqwX6k0wWIgNBkC6aXibQIfoRhnTZ9jF2BDf7XyNSBT vzvQ== MIME-Version: 1.0 X-Received: by 10.205.32.208 with SMTP id sl16mr7842169bkb.27.1363184648083; Wed, 13 Mar 2013 07:24:08 -0700 (PDT) Received: by 10.204.237.9 with HTTP; Wed, 13 Mar 2013 07:24:07 -0700 (PDT) In-Reply-To: <1363183973.32410.182.camel@zakaz.uk.xensource.com> References: <1363183973.32410.182.camel@zakaz.uk.xensource.com> Date: Wed, 13 Mar 2013 15:24:07 +0100 Message-ID: From: Sylvain Munaut To: Ian Campbell X-Gm-Message-State: ALoCoQnpqi8KWZYcgXHMoxyPe3X9OSzMMXW/LGLaqvd8inhG4jJOx4lg7UrEzGjCMw/4lhlImig9 Cc: "xen-users@lists.xen.org\"" Subject: Re: [Xen-users] Race condition in sending gratuitous ARP for live migration ? X-BeenThere: xen-users@lists.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, >> So responding to myself: There is indeed a race condition ... and it >> was fixed 1.5 years ago by Laszlo Ersek. >> Unfortunately the fix isn't present in the Ubuntu 12.04 LTS kernel, >> nor in the stable 3.2 tree :( > > Can you file a bug with Ubuntu please? Already did :) I'd like to not have to maintain my own kernel for the VMs :p https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1154608 Cheers, Sylvain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 17:33:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 17:33: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 1UFpX3-0004YN-BZ; Wed, 13 Mar 2013 17:32:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFpX2-0004YI-7f for xen-users@lists.xen.org; Wed, 13 Mar 2013 17:32:04 +0000 Received: from [85.158.138.51:32112] by server-6.bemta-3.messagelabs.com id 8A/54-11048-318B0415; Wed, 13 Mar 2013 17:32:03 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1363195920!19335995!1 X-Originating-IP: [209.85.223.174] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13305 invoked from network); 13 Mar 2013 17:32:02 -0000 Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com) (209.85.223.174) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 17:32:02 -0000 Received: by mail-ie0-f174.google.com with SMTP id k10so1771092iea.19 for ; Wed, 13 Mar 2013 10:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PpSML8iB+lj1N1m5i/vvmpTFw6aTuf3X110C+HU35+8=; b=PP2TJMYdU3V2g9SNM/PJdgaChxVAUwddWgIrPnqizyJJ5ssPhjfrmSD2XfP31cwbFw Z5jvx7JQY7LFyrE9kJfsC1IFC03G6nibSsRuIJ5+WQjTER6qo/BmF4ZejcnMkktd0Pnt SfGIdlLSfU1VERojfMOrSgyZLAx/bgQDX2YQ+rJtWW4EzXskXTsW186fS/u1U316IzQ0 e0SVHoPdi7dtcCga3AzDRKeBdotHKI6xmyh/vWQb8EHMv4xEgGGA7Md6wFMI4/0k08f3 5JVLpztAjjdCEcm/bwgSrpYgLa9kp0oFhlTUK9MUgnuzq4FNPWv+Kz/ihctSUCHFRj/L bvHA== MIME-Version: 1.0 X-Received: by 10.50.183.233 with SMTP id ep9mr17446650igc.87.1363195920658; Wed, 13 Mar 2013 10:32:00 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Wed, 13 Mar 2013 10:32:00 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Wed, 13 Mar 2013 10:32:00 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> <1363169182.12732.YahooMailNeo@web172001.mail.ir2.yahoo.com> <1363191907.36206.YahooMailNeo@web172006.mail.ir2.yahoo.com> Date: Wed, 13 Mar 2013 14:32:00 -0300 Message-ID: From: Guilherme Suzuki To: David TECHER Cc: "xen-users@lists.xen.org" , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============1995423088899369860==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1995423088899369860== Content-Type: multipart/alternative; boundary=14dae93409599c650104d7d1c8d2 --14dae93409599c650104d7d1c8d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not sure if this is related, but everytime I shutdown a domU (win7 64bits), the display device goes to some sort of a stanby state (like my radeon went to sleep). And then, if I try to passthru again, my linux pc crashes (I can't even execute commands through ssh). On Mar 13, 2013 1:25 PM, "David TECHER" wrote: Got the same behavior for windows. But I can reboot VM only when it is a Linux-VM. ________________________________ De : Guilherme Suzuki *=C0 :* David TECHER *Cc :* Matthias ; " xen-users@lists.xen.org" *Envoy=E9 le :* Mercredi 13 mars 2013 16h03 Objet : Re: [Xen-users] VGA Passthru - FLR? David, hi! Are you able to reboot domU? Cause in my case, after rebooting domU, xen just crashes t... --14dae93409599c650104d7d1c8d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'm not sure if this is related, but everytime I shutdown a domU (wi= n7 64bits), the display device goes to some sort of a stanby state (like my= radeon went to sleep).

And then, if I try to passthru again, my linux pc crashes (I can't e= ven execute commands through ssh).

On Mar 13, 2013 1:25 PM, "David TECHER&qu= ot; <davidtech= er@yahoo.fr> wrote:

--14dae93409599c650104d7d1c8d2-- --===============1995423088899369860== 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 --===============1995423088899369860==-- From xen-users-bounces@lists.xen.org Wed Mar 13 17:33:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 17:33: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 1UFpX3-0004YN-BZ; Wed, 13 Mar 2013 17:32:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFpX2-0004YI-7f for xen-users@lists.xen.org; Wed, 13 Mar 2013 17:32:04 +0000 Received: from [85.158.138.51:32112] by server-6.bemta-3.messagelabs.com id 8A/54-11048-318B0415; Wed, 13 Mar 2013 17:32:03 +0000 X-Env-Sender: suzuki.gui@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1363195920!19335995!1 X-Originating-IP: [209.85.223.174] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13305 invoked from network); 13 Mar 2013 17:32:02 -0000 Received: from mail-ie0-f174.google.com (HELO mail-ie0-f174.google.com) (209.85.223.174) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 17:32:02 -0000 Received: by mail-ie0-f174.google.com with SMTP id k10so1771092iea.19 for ; Wed, 13 Mar 2013 10:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PpSML8iB+lj1N1m5i/vvmpTFw6aTuf3X110C+HU35+8=; b=PP2TJMYdU3V2g9SNM/PJdgaChxVAUwddWgIrPnqizyJJ5ssPhjfrmSD2XfP31cwbFw Z5jvx7JQY7LFyrE9kJfsC1IFC03G6nibSsRuIJ5+WQjTER6qo/BmF4ZejcnMkktd0Pnt SfGIdlLSfU1VERojfMOrSgyZLAx/bgQDX2YQ+rJtWW4EzXskXTsW186fS/u1U316IzQ0 e0SVHoPdi7dtcCga3AzDRKeBdotHKI6xmyh/vWQb8EHMv4xEgGGA7Md6wFMI4/0k08f3 5JVLpztAjjdCEcm/bwgSrpYgLa9kp0oFhlTUK9MUgnuzq4FNPWv+Kz/ihctSUCHFRj/L bvHA== MIME-Version: 1.0 X-Received: by 10.50.183.233 with SMTP id ep9mr17446650igc.87.1363195920658; Wed, 13 Mar 2013 10:32:00 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Wed, 13 Mar 2013 10:32:00 -0700 (PDT) Received: by 10.64.170.65 with HTTP; Wed, 13 Mar 2013 10:32:00 -0700 (PDT) In-Reply-To: References: <5135AF2B.4050007@brockmann-consult.de> <1363169182.12732.YahooMailNeo@web172001.mail.ir2.yahoo.com> <1363191907.36206.YahooMailNeo@web172006.mail.ir2.yahoo.com> Date: Wed, 13 Mar 2013 14:32:00 -0300 Message-ID: From: Guilherme Suzuki To: David TECHER Cc: "xen-users@lists.xen.org" , Matthias Subject: Re: [Xen-users] VGA Passthru - FLR? X-BeenThere: xen-users@lists.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="===============1995423088899369860==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1995423088899369860== Content-Type: multipart/alternative; boundary=14dae93409599c650104d7d1c8d2 --14dae93409599c650104d7d1c8d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not sure if this is related, but everytime I shutdown a domU (win7 64bits), the display device goes to some sort of a stanby state (like my radeon went to sleep). And then, if I try to passthru again, my linux pc crashes (I can't even execute commands through ssh). On Mar 13, 2013 1:25 PM, "David TECHER" wrote: Got the same behavior for windows. But I can reboot VM only when it is a Linux-VM. ________________________________ De : Guilherme Suzuki *=C0 :* David TECHER *Cc :* Matthias ; " xen-users@lists.xen.org" *Envoy=E9 le :* Mercredi 13 mars 2013 16h03 Objet : Re: [Xen-users] VGA Passthru - FLR? David, hi! Are you able to reboot domU? Cause in my case, after rebooting domU, xen just crashes t... --14dae93409599c650104d7d1c8d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'm not sure if this is related, but everytime I shutdown a domU (wi= n7 64bits), the display device goes to some sort of a stanby state (like my= radeon went to sleep).

And then, if I try to passthru again, my linux pc crashes (I can't e= ven execute commands through ssh).

On Mar 13, 2013 1:25 PM, "David TECHER&qu= ot; <davidtech= er@yahoo.fr> wrote:

--14dae93409599c650104d7d1c8d2-- --===============1995423088899369860== 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 --===============1995423088899369860==-- From xen-users-bounces@lists.xen.org Wed Mar 13 18:18:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 18:18: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 1UFqFE-0005pm-Ry; Wed, 13 Mar 2013 18:17:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFqFC-0005pf-Rr for xen-users@lists.xen.org; Wed, 13 Mar 2013 18:17:43 +0000 Received: from [85.158.139.83:15568] by server-11.bemta-5.messagelabs.com id B5/01-27486-5C2C0415; Wed, 13 Mar 2013 18:17:41 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-13.tower-182.messagelabs.com!1363198649!27740473!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12077 invoked from network); 13 Mar 2013 18:17:29 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-13.tower-182.messagelabs.com with SMTP; 13 Mar 2013 18:17:29 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:56023) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UFqE2-00037N-75 (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Wed, 13 Mar 2013 18:16:30 +0000 Message-ID: <5140C26B.7090409@cam.ac.uk> Date: Wed, 13 Mar 2013 18:16:11 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <513F5C1E.7010407@cam.ac.uk> In-Reply-To: Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 Just to let everyone know that patch worked like gold for me. My HD 7970 is now being passed through as the primary adapter with driver version 13.1 and up to now all seems to be working. Will run further tests over the next few days to make sure it stays that way and I'll probably test secondary passthrough also. Once that's done I need to put the second card back in and have a bit of a play but this is by far the furthest I've been in the last 2 weeks. Thanks to everybody for your advice. Matt On 12/03/2013 19:42, Matthias wrote: > Hi, > > to fix the atikmeq.sys bug, you can try two things: > > 1) Use upstream qemu. For this, just add: > > device_model_version = 'qemu-xen' > device_model_override = '/usr/lib/xen/bin/qemu-system-i386' > > to your domU config file. Note that there is currently a bug that the > domU won't start when duing vga passthrough with more then 4GB memory > assigned, so better use some less.. > > 2) If you want to have more then 4GB memory, you can patch the > traditional qemu. This is a bit more complicated cause the qemu stuff > is download through the build and can't be patched right away. Also > stopping in mid build, patching and continuing at least for me caused > some problems, so doing a full build, patch, cleanup and build again > is the safer route: > > git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging > cd xen-unstable-staging > ./configure --disable-stubdom > make -j12 world > git apply --check /path/to/xen-unstable-atipassthrough.patch > git apply /path/to/xen-unstable-atipassthrough.patch > make -j12 clean > make -j12 world > Now do your usual install.. some use the standard, i prefer creating a debball.. > > Some Notes: > - I use the staging branch from xen-unstable, but this is not exactly > necessary for the patch, you can use master just as fine > - the j12 is for multithreading and you should use double your core > number.. since i got 6 cpu cores, it's 12 for me.. > - the patch i have attached is originally from Greg > (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), > so credit goes to him, i only cleaned it up for xen-unstable. Also, > the patch itself was for providing primary passthrough with ATI cards, > but i found it fixing my ati 0x116 bluescreen.. > - due to an insufficiancy in the patch, stubdom would not build > correctly, so you have to disable it > > Please report back if the patch fixes your bluescreen for more > argumentation to bring this patch upstream.. :) (@Greg: that's why i > cc'ed you. hope you don't mind the noise) > > Hope it helps! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 18:18:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 18:18: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 1UFqFE-0005pm-Ry; Wed, 13 Mar 2013 18:17:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFqFC-0005pf-Rr for xen-users@lists.xen.org; Wed, 13 Mar 2013 18:17:43 +0000 Received: from [85.158.139.83:15568] by server-11.bemta-5.messagelabs.com id B5/01-27486-5C2C0415; Wed, 13 Mar 2013 18:17:41 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-13.tower-182.messagelabs.com!1363198649!27740473!1 X-Originating-IP: [131.111.8.142] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE0MiA9PiAxMTg0OA==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12077 invoked from network); 13 Mar 2013 18:17:29 -0000 Received: from ppsw-42.csi.cam.ac.uk (HELO ppsw-42.csi.cam.ac.uk) (131.111.8.142) by server-13.tower-182.messagelabs.com with SMTP; 13 Mar 2013 18:17:29 -0000 X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:56023) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UFqE2-00037N-75 (Exim 4.80_167-5a66dd3) for xen-users@lists.xen.org (return-path ); Wed, 13 Mar 2013 18:16:30 +0000 Message-ID: <5140C26B.7090409@cam.ac.uk> Date: Wed, 13 Mar 2013 18:16:11 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <513F5C1E.7010407@cam.ac.uk> In-Reply-To: Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 Just to let everyone know that patch worked like gold for me. My HD 7970 is now being passed through as the primary adapter with driver version 13.1 and up to now all seems to be working. Will run further tests over the next few days to make sure it stays that way and I'll probably test secondary passthrough also. Once that's done I need to put the second card back in and have a bit of a play but this is by far the furthest I've been in the last 2 weeks. Thanks to everybody for your advice. Matt On 12/03/2013 19:42, Matthias wrote: > Hi, > > to fix the atikmeq.sys bug, you can try two things: > > 1) Use upstream qemu. For this, just add: > > device_model_version = 'qemu-xen' > device_model_override = '/usr/lib/xen/bin/qemu-system-i386' > > to your domU config file. Note that there is currently a bug that the > domU won't start when duing vga passthrough with more then 4GB memory > assigned, so better use some less.. > > 2) If you want to have more then 4GB memory, you can patch the > traditional qemu. This is a bit more complicated cause the qemu stuff > is download through the build and can't be patched right away. Also > stopping in mid build, patching and continuing at least for me caused > some problems, so doing a full build, patch, cleanup and build again > is the safer route: > > git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging > cd xen-unstable-staging > ./configure --disable-stubdom > make -j12 world > git apply --check /path/to/xen-unstable-atipassthrough.patch > git apply /path/to/xen-unstable-atipassthrough.patch > make -j12 clean > make -j12 world > Now do your usual install.. some use the standard, i prefer creating a debball.. > > Some Notes: > - I use the staging branch from xen-unstable, but this is not exactly > necessary for the patch, you can use master just as fine > - the j12 is for multithreading and you should use double your core > number.. since i got 6 cpu cores, it's 12 for me.. > - the patch i have attached is originally from Greg > (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), > so credit goes to him, i only cleaned it up for xen-unstable. Also, > the patch itself was for providing primary passthrough with ATI cards, > but i found it fixing my ati 0x116 bluescreen.. > - due to an insufficiancy in the patch, stubdom would not build > correctly, so you have to disable it > > Please report back if the patch fixes your bluescreen for more > argumentation to bring this patch upstream.. :) (@Greg: that's why i > cc'ed you. hope you don't mind the noise) > > Hope it helps! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 13 21:07:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 21:07: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 1UFssk-0007bE-Aj; Wed, 13 Mar 2013 21:06:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFssi-0007b9-H5 for xen-users@lists.xen.org; Wed, 13 Mar 2013 21:06:40 +0000 Received: from [85.158.139.83:60064] by server-1.bemta-5.messagelabs.com id C1/79-14063-F5AE0415; Wed, 13 Mar 2013 21:06:39 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1363208798!27902498!1 X-Originating-IP: [74.125.82.47] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4138 invoked from network); 13 Mar 2013 21:06:38 -0000 Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com) (74.125.82.47) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 21:06:38 -0000 Received: by mail-wg0-f47.google.com with SMTP id dr13so1379620wgb.2 for ; Wed, 13 Mar 2013 14:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=50zSvz8BHsGXoPo4+dssLkH52qPjaUfWJQ2O2wF6l9c=; b=MRUw+VDCiV+zRpyWOYWeEnJcMNbSwzOTZYJ3o4z9uwpITkIcK5fOBRKZrPfxpNIAEY KkPlbuoBVVTeRxpspebnYVI5BL1hd4zEeacCszUjdBzMQhvr+yrQqvWXeNJeosbGwNgd LPFv++CQWWoOkQn6sR4KSU6z6DTwTg4qtfzjOqRvNFwe39cFW2dprV7O//3+N/ebQsdU /YAyHMPKNdD5zm8ERlC/DUrhLUa7tb//aE9JTjUPKpgcij+YY60OIYvexoFcP8BM32vN OtU8acG8FqGr/EM3n5+fACN2cPJCfzXyY5ediWm7NTFiawXoeOG8A9MvCznIrFm18Kpk eGEQ== X-Received: by 10.180.84.162 with SMTP id a2mr29533988wiz.14.1363208798559; Wed, 13 Mar 2013 14:06:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Wed, 13 Mar 2013 14:06:18 -0700 (PDT) In-Reply-To: <5140C26B.7090409@cam.ac.uk> References: <513F5C1E.7010407@cam.ac.uk> <5140C26B.7090409@cam.ac.uk> From: Matthias Date: Wed, 13 Mar 2013 22:06:18 +0100 Message-ID: To: Matthew Dean Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 Congrats! But so you don't get overly excited, dual vga passthrough sems to be broken at the moment. Been down that road (Thread: http://xen.1045712.n5.nabble.com/dual-vga-passthrough-issue-in-xen-unstable-td5714613.html), posted to xen-user and xen-devel, but never got a response. Would be interesting to see if it works for you. Oh, and just for my record-keeping: Have you used my patch or the original one from Greg? 2013/3/13 Matthew Dean : > Just to let everyone know that patch worked like gold for me. My HD 7970 is > now being passed through as the primary adapter with driver version 13.1 and > up to now all seems to be working. Will run further tests over the next few > days to make sure it stays that way and I'll probably test secondary > passthrough also. Once that's done I need to put the second card back in > and have a bit of a play but this is by far the furthest I've been in the > last 2 weeks. Thanks to everybody for your advice. > > Matt > > > On 12/03/2013 19:42, Matthias wrote: >> >> Hi, >> >> to fix the atikmeq.sys bug, you can try two things: >> >> 1) Use upstream qemu. For this, just add: >> >> device_model_version = 'qemu-xen' >> device_model_override = '/usr/lib/xen/bin/qemu-system-i386' >> >> to your domU config file. Note that there is currently a bug that the >> domU won't start when duing vga passthrough with more then 4GB memory >> assigned, so better use some less.. >> >> 2) If you want to have more then 4GB memory, you can patch the >> traditional qemu. This is a bit more complicated cause the qemu stuff >> is download through the build and can't be patched right away. Also >> stopping in mid build, patching and continuing at least for me caused >> some problems, so doing a full build, patch, cleanup and build again >> is the safer route: >> >> git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging >> cd xen-unstable-staging >> ./configure --disable-stubdom >> make -j12 world >> git apply --check /path/to/xen-unstable-atipassthrough.patch >> git apply /path/to/xen-unstable-atipassthrough.patch >> make -j12 clean >> make -j12 world >> Now do your usual install.. some use the standard, i prefer creating a >> debball.. >> >> Some Notes: >> - I use the staging branch from xen-unstable, but this is not exactly >> necessary for the patch, you can use master just as fine >> - the j12 is for multithreading and you should use double your core >> number.. since i got 6 cpu cores, it's 12 for me.. >> - the patch i have attached is originally from Greg >> (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), >> so credit goes to him, i only cleaned it up for xen-unstable. Also, >> the patch itself was for providing primary passthrough with ATI cards, >> but i found it fixing my ati 0x116 bluescreen.. >> - due to an insufficiancy in the patch, stubdom would not build >> correctly, so you have to disable it >> >> Please report back if the patch fixes your bluescreen for more >> argumentation to bring this patch upstream.. :) (@Greg: that's why i >> cc'ed you. hope you don't mind the noise) >> >> Hope it helps! > > > > _______________________________________________ > 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 Mar 13 21:07:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 21:07: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 1UFssk-0007bE-Aj; Wed, 13 Mar 2013 21:06:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFssi-0007b9-H5 for xen-users@lists.xen.org; Wed, 13 Mar 2013 21:06:40 +0000 Received: from [85.158.139.83:60064] by server-1.bemta-5.messagelabs.com id C1/79-14063-F5AE0415; Wed, 13 Mar 2013 21:06:39 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1363208798!27902498!1 X-Originating-IP: [74.125.82.47] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4138 invoked from network); 13 Mar 2013 21:06:38 -0000 Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com) (74.125.82.47) by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 21:06:38 -0000 Received: by mail-wg0-f47.google.com with SMTP id dr13so1379620wgb.2 for ; Wed, 13 Mar 2013 14:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=50zSvz8BHsGXoPo4+dssLkH52qPjaUfWJQ2O2wF6l9c=; b=MRUw+VDCiV+zRpyWOYWeEnJcMNbSwzOTZYJ3o4z9uwpITkIcK5fOBRKZrPfxpNIAEY KkPlbuoBVVTeRxpspebnYVI5BL1hd4zEeacCszUjdBzMQhvr+yrQqvWXeNJeosbGwNgd LPFv++CQWWoOkQn6sR4KSU6z6DTwTg4qtfzjOqRvNFwe39cFW2dprV7O//3+N/ebQsdU /YAyHMPKNdD5zm8ERlC/DUrhLUa7tb//aE9JTjUPKpgcij+YY60OIYvexoFcP8BM32vN OtU8acG8FqGr/EM3n5+fACN2cPJCfzXyY5ediWm7NTFiawXoeOG8A9MvCznIrFm18Kpk eGEQ== X-Received: by 10.180.84.162 with SMTP id a2mr29533988wiz.14.1363208798559; Wed, 13 Mar 2013 14:06:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Wed, 13 Mar 2013 14:06:18 -0700 (PDT) In-Reply-To: <5140C26B.7090409@cam.ac.uk> References: <513F5C1E.7010407@cam.ac.uk> <5140C26B.7090409@cam.ac.uk> From: Matthias Date: Wed, 13 Mar 2013 22:06:18 +0100 Message-ID: To: Matthew Dean Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 Congrats! But so you don't get overly excited, dual vga passthrough sems to be broken at the moment. Been down that road (Thread: http://xen.1045712.n5.nabble.com/dual-vga-passthrough-issue-in-xen-unstable-td5714613.html), posted to xen-user and xen-devel, but never got a response. Would be interesting to see if it works for you. Oh, and just for my record-keeping: Have you used my patch or the original one from Greg? 2013/3/13 Matthew Dean : > Just to let everyone know that patch worked like gold for me. My HD 7970 is > now being passed through as the primary adapter with driver version 13.1 and > up to now all seems to be working. Will run further tests over the next few > days to make sure it stays that way and I'll probably test secondary > passthrough also. Once that's done I need to put the second card back in > and have a bit of a play but this is by far the furthest I've been in the > last 2 weeks. Thanks to everybody for your advice. > > Matt > > > On 12/03/2013 19:42, Matthias wrote: >> >> Hi, >> >> to fix the atikmeq.sys bug, you can try two things: >> >> 1) Use upstream qemu. For this, just add: >> >> device_model_version = 'qemu-xen' >> device_model_override = '/usr/lib/xen/bin/qemu-system-i386' >> >> to your domU config file. Note that there is currently a bug that the >> domU won't start when duing vga passthrough with more then 4GB memory >> assigned, so better use some less.. >> >> 2) If you want to have more then 4GB memory, you can patch the >> traditional qemu. This is a bit more complicated cause the qemu stuff >> is download through the build and can't be patched right away. Also >> stopping in mid build, patching and continuing at least for me caused >> some problems, so doing a full build, patch, cleanup and build again >> is the safer route: >> >> git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging >> cd xen-unstable-staging >> ./configure --disable-stubdom >> make -j12 world >> git apply --check /path/to/xen-unstable-atipassthrough.patch >> git apply /path/to/xen-unstable-atipassthrough.patch >> make -j12 clean >> make -j12 world >> Now do your usual install.. some use the standard, i prefer creating a >> debball.. >> >> Some Notes: >> - I use the staging branch from xen-unstable, but this is not exactly >> necessary for the patch, you can use master just as fine >> - the j12 is for multithreading and you should use double your core >> number.. since i got 6 cpu cores, it's 12 for me.. >> - the patch i have attached is originally from Greg >> (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), >> so credit goes to him, i only cleaned it up for xen-unstable. Also, >> the patch itself was for providing primary passthrough with ATI cards, >> but i found it fixing my ati 0x116 bluescreen.. >> - due to an insufficiancy in the patch, stubdom would not build >> correctly, so you have to disable it >> >> Please report back if the patch fixes your bluescreen for more >> argumentation to bring this patch upstream.. :) (@Greg: that's why i >> cc'ed you. hope you don't mind the noise) >> >> Hope it helps! > > > > _______________________________________________ > 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 Mar 13 22:08:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 22:08: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 1UFtpr-0008Rb-1g; Wed, 13 Mar 2013 22:07:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFisM-0000mw-OF for xen-users@lists.xen.org; Wed, 13 Mar 2013 10:25:38 +0000 Received: from [85.158.137.99:28088] by server-11.bemta-3.messagelabs.com id 38/5C-01263-D1450415; Wed, 13 Mar 2013 10:25:33 +0000 X-Env-Sender: krishansethi@curaj.ac.in X-Msg-Ref: server-6.tower-217.messagelabs.com!1363170304!12996618!1 X-Originating-IP: [209.85.215.50] 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.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10431 invoked from network); 13 Mar 2013 10:25:05 -0000 Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com) (209.85.215.50) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 10:25:05 -0000 Received: by mail-la0-f50.google.com with SMTP id ec20so902035lab.9 for ; Wed, 13 Mar 2013 03:25:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=jBz5sv4xbE6bypCvjWa0U6BtAM5qDfxcdbwofc+SQ8U=; b=ThT4o8ja2aXXNfKTKJOfxdQyjlNn3w46BEkN0QXo4+/z+o9/JcC3KWFdrw9pVmmFtq YsEiacgIYXpJGCNjcZCBMXKKCWQ+jA59o+UPGc2fKCs93yOcBVxMjSP/4WNBzzl4b7yz 5lN5k9Podw4KfX90wW06Wt1ecMQ42LW8gZKRlhm+vUQsCbvOHevk1SZfqBUvOCCR6jJj HgY7F3I+jlPiOgKtGo9OiNWohEjWFQb6/b2UADabhcVJHG7MZzwuayaR6xgY3Fd9gzl4 gh4VRkSpabMa8FKXF1iSp66Yq+HyqEioj4/4b05uwuFNP+LCUpyoBp9SnO+okXiEW+8P rHRg== MIME-Version: 1.0 X-Received: by 10.152.131.233 with SMTP id op9mr17137797lab.3.1363170304352; Wed, 13 Mar 2013 03:25:04 -0700 (PDT) Received: by 10.112.100.69 with HTTP; Wed, 13 Mar 2013 03:25:04 -0700 (PDT) Date: Wed, 13 Mar 2013 15:55:04 +0530 Message-ID: From: Krishan Sethi To: xen-users@lists.xen.org X-Gm-Message-State: ALoCoQle3CNuauMS2e8K0/9VmvczZtX8Z/3tK/BuvBAi1bd7XMQH01ugV4T+z7EseB5E/1afhQoi X-Mailman-Approved-At: Wed, 13 Mar 2013 22:07:45 +0000 Subject: [Xen-users] Migration problem in 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: multipart/mixed; boundary="===============0737286444000318490==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0737286444000318490== Content-Type: multipart/alternative; boundary=f46d042c64b9c2853604d7cbd12c --f46d042c64b9c2853604d7cbd12c Content-Type: text/plain; charset=ISO-8859-1 hi i have loaded the virtual machine using Virt- Manager. i installed xen on 2 hosts which are connected via LAN now i am trying to migrate the VM from one host to another host. i configured xend.config.sxp accordingly for migration. Both hypervisors are remotely connected to each other successfully. when i do the migration it shows the error: Unable to migrate guest: Domain not found: xenUnifiedDomainLookupByName Detail: Unable to migrate guest: Domain not found: xenUnifiedDomainLookupByName Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/migrate.py", line 553, in _async_migrate vm.migrate(dstconn, migrate_uri, rate, live, secure, meter=meter) File "/usr/share/virt-manager/virtManager/domain.py", line 1163, in migrate self._backend.migrate(destconn.vmm, flags, newname, interface, rate) File "/usr/lib/python2.7/site-packages/libvirt.py", line 822, in migrate if ret is None:raise libvirtError('virDomainMigrate() failed', dom=self) libvirtError: Domain not found: xenUnifiedDomainLookupByName i didn't use any shared storage like NFS. If u faced such a problem then please suggest me solutions. IS it required to use shared storage for migration? if u used xen-tools to create VM. then please send me the configuration file(.cfg) with required changes in it . i actually used one but its not working.. regards and thanks -- Krishan Sethi Mtech, Computer Science & Engineering Central University of Rajasthan, kishangarh, Ajmer +91-9785673863 --f46d042c64b9c2853604d7cbd12c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi

i have loaded the= virtual=20 machine using Virt- Manager. i installed xen on 2 hosts which are=20 connected via LAN now i am trying to migrate the VM from one host to=20 another host. i configured xend.config.sxp accordingly for migration.=20 Both hypervisors are remotely connected to each other successfully. when i do the migration it shows the error:=A0

Unable to migrate guest: Domain not found: xenUnifiedDomainLookupByName=
Detail:
Unable to migrate guest: Domain not found: xenUnifiedDomainL= ookupByName


Traceback (most recent call last):
=A0 File "/usr/share/virt-manager/virtManager/asyncjob.py",= line 96, in cb_wrapper
=A0=A0=A0 callback(asyncjob, *args, **kwargs)
=A0 File "/usr/share/= virt-manager/virtManager/migrate.py", line 553, in _async_migrate
= =A0=A0=A0 vm.migrate(dstconn, migrate_uri, rate, live, secure, meter=3Dmete= r)
=A0 File "/usr/share/virt-manager/virtManager/domain.py", l= ine 1163, in migrate
=A0=A0=A0 self._backend.migrate(destconn.vmm, flags, newname, interface, ra= te)
=A0 File "/usr/lib/python2.7/site-packages/libvirt.py", li= ne 822, in migrate
=A0=A0=A0 if ret is None:raise libvirtError('virD= omainMigrate() failed', dom=3Dself)
libvirtError: Domain not found: xenUnifiedDomainLookupByName

i= didn't use any shared storage like NFS. If u faced such a problem then= please suggest me solutions.

IS it required to use shared sto= rage for migration?

if u used xen-tools to create VM. then please send me the=20 configuration file(.cfg) with required changes in it . i actually used=20 one but its not working..

regards and thanks
=
--
Krishan Sethi
<= span style=3D"background-color:rgb(192,192,192)">M= tech, Computer Science & Engineering
Central University of Rajasthan, kishangarh, Ajmer=
+91-9785673863
--f46d042c64b9c2853604d7cbd12c-- --===============0737286444000318490== 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 --===============0737286444000318490==-- From xen-users-bounces@lists.xen.org Wed Mar 13 22:08:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 13 Mar 2013 22:08: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 1UFtpr-0008Rb-1g; Wed, 13 Mar 2013 22:07:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFisM-0000mw-OF for xen-users@lists.xen.org; Wed, 13 Mar 2013 10:25:38 +0000 Received: from [85.158.137.99:28088] by server-11.bemta-3.messagelabs.com id 38/5C-01263-D1450415; Wed, 13 Mar 2013 10:25:33 +0000 X-Env-Sender: krishansethi@curaj.ac.in X-Msg-Ref: server-6.tower-217.messagelabs.com!1363170304!12996618!1 X-Originating-IP: [209.85.215.50] 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.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10431 invoked from network); 13 Mar 2013 10:25:05 -0000 Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com) (209.85.215.50) by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 13 Mar 2013 10:25:05 -0000 Received: by mail-la0-f50.google.com with SMTP id ec20so902035lab.9 for ; Wed, 13 Mar 2013 03:25:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=jBz5sv4xbE6bypCvjWa0U6BtAM5qDfxcdbwofc+SQ8U=; b=ThT4o8ja2aXXNfKTKJOfxdQyjlNn3w46BEkN0QXo4+/z+o9/JcC3KWFdrw9pVmmFtq YsEiacgIYXpJGCNjcZCBMXKKCWQ+jA59o+UPGc2fKCs93yOcBVxMjSP/4WNBzzl4b7yz 5lN5k9Podw4KfX90wW06Wt1ecMQ42LW8gZKRlhm+vUQsCbvOHevk1SZfqBUvOCCR6jJj HgY7F3I+jlPiOgKtGo9OiNWohEjWFQb6/b2UADabhcVJHG7MZzwuayaR6xgY3Fd9gzl4 gh4VRkSpabMa8FKXF1iSp66Yq+HyqEioj4/4b05uwuFNP+LCUpyoBp9SnO+okXiEW+8P rHRg== MIME-Version: 1.0 X-Received: by 10.152.131.233 with SMTP id op9mr17137797lab.3.1363170304352; Wed, 13 Mar 2013 03:25:04 -0700 (PDT) Received: by 10.112.100.69 with HTTP; Wed, 13 Mar 2013 03:25:04 -0700 (PDT) Date: Wed, 13 Mar 2013 15:55:04 +0530 Message-ID: From: Krishan Sethi To: xen-users@lists.xen.org X-Gm-Message-State: ALoCoQle3CNuauMS2e8K0/9VmvczZtX8Z/3tK/BuvBAi1bd7XMQH01ugV4T+z7EseB5E/1afhQoi X-Mailman-Approved-At: Wed, 13 Mar 2013 22:07:45 +0000 Subject: [Xen-users] Migration problem in 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: multipart/mixed; boundary="===============0737286444000318490==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0737286444000318490== Content-Type: multipart/alternative; boundary=f46d042c64b9c2853604d7cbd12c --f46d042c64b9c2853604d7cbd12c Content-Type: text/plain; charset=ISO-8859-1 hi i have loaded the virtual machine using Virt- Manager. i installed xen on 2 hosts which are connected via LAN now i am trying to migrate the VM from one host to another host. i configured xend.config.sxp accordingly for migration. Both hypervisors are remotely connected to each other successfully. when i do the migration it shows the error: Unable to migrate guest: Domain not found: xenUnifiedDomainLookupByName Detail: Unable to migrate guest: Domain not found: xenUnifiedDomainLookupByName Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/migrate.py", line 553, in _async_migrate vm.migrate(dstconn, migrate_uri, rate, live, secure, meter=meter) File "/usr/share/virt-manager/virtManager/domain.py", line 1163, in migrate self._backend.migrate(destconn.vmm, flags, newname, interface, rate) File "/usr/lib/python2.7/site-packages/libvirt.py", line 822, in migrate if ret is None:raise libvirtError('virDomainMigrate() failed', dom=self) libvirtError: Domain not found: xenUnifiedDomainLookupByName i didn't use any shared storage like NFS. If u faced such a problem then please suggest me solutions. IS it required to use shared storage for migration? if u used xen-tools to create VM. then please send me the configuration file(.cfg) with required changes in it . i actually used one but its not working.. regards and thanks -- Krishan Sethi Mtech, Computer Science & Engineering Central University of Rajasthan, kishangarh, Ajmer +91-9785673863 --f46d042c64b9c2853604d7cbd12c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi

i have loaded the= virtual=20 machine using Virt- Manager. i installed xen on 2 hosts which are=20 connected via LAN now i am trying to migrate the VM from one host to=20 another host. i configured xend.config.sxp accordingly for migration.=20 Both hypervisors are remotely connected to each other successfully. when i do the migration it shows the error:=A0

Unable to migrate guest: Domain not found: xenUnifiedDomainLookupByName=
Detail:
Unable to migrate guest: Domain not found: xenUnifiedDomainL= ookupByName


Traceback (most recent call last):
=A0 File "/usr/share/virt-manager/virtManager/asyncjob.py",= line 96, in cb_wrapper
=A0=A0=A0 callback(asyncjob, *args, **kwargs)
=A0 File "/usr/share/= virt-manager/virtManager/migrate.py", line 553, in _async_migrate
= =A0=A0=A0 vm.migrate(dstconn, migrate_uri, rate, live, secure, meter=3Dmete= r)
=A0 File "/usr/share/virt-manager/virtManager/domain.py", l= ine 1163, in migrate
=A0=A0=A0 self._backend.migrate(destconn.vmm, flags, newname, interface, ra= te)
=A0 File "/usr/lib/python2.7/site-packages/libvirt.py", li= ne 822, in migrate
=A0=A0=A0 if ret is None:raise libvirtError('virD= omainMigrate() failed', dom=3Dself)
libvirtError: Domain not found: xenUnifiedDomainLookupByName

i= didn't use any shared storage like NFS. If u faced such a problem then= please suggest me solutions.

IS it required to use shared sto= rage for migration?

if u used xen-tools to create VM. then please send me the=20 configuration file(.cfg) with required changes in it . i actually used=20 one but its not working..

regards and thanks
=
--
Krishan Sethi
<= span style=3D"background-color:rgb(192,192,192)">M= tech, Computer Science & Engineering
Central University of Rajasthan, kishangarh, Ajmer=
+91-9785673863
--f46d042c64b9c2853604d7cbd12c-- --===============0737286444000318490== 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 --===============0737286444000318490==-- From xen-users-bounces@lists.xen.org Thu Mar 14 00:29:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 00:29: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 1UFw23-0001ag-P2; Thu, 14 Mar 2013 00:28:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFw22-0001ab-TM for xen-users@lists.xen.org; Thu, 14 Mar 2013 00:28:31 +0000 Received: from [85.158.139.83:60224] by server-10.bemta-5.messagelabs.com id 11/45-23714-EA911415; Thu, 14 Mar 2013 00:28:30 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1363220909!24276386!1 X-Originating-IP: [74.125.82.175] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8634 invoked from network); 14 Mar 2013 00:28:29 -0000 Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 00:28:29 -0000 Received: by mail-we0-f175.google.com with SMTP id x8so1610965wey.20 for ; Wed, 13 Mar 2013 17:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=pU2MrV4/Eetdjz5iIvwMi2Mdcne1nJjnmagU98oR9gY=; b=oHrGszsDsBFLMk60jURqYBm2WERVS3jwepHj3gSb/FE5JsCL59VQE/gVzkpNnbrmJs FzLxcaGZ4dnruRblZ94t78l+6PGMrshbbflNsWIsdkzFBksM9TILhn+j8fSAT3J8q/TK iC/ZwhZXg1/WStqhRI9/ZFJpf4JsmhrJ3MtlV1xSDiG2bST8guQT8ZWlUJ6oJIqQWrsv XhrHI9cxscPWeR7CRv4MHmamVtoKixGSb5002nLMzdf/UMobyua5nViqXSbwEpOfaK67 prs0CqoL+iAIFFzWlRScmMlsKnXU4Bk1yQBXU2q8ADZ12WpEUxpSe54QSEdzeo0ZPFqi LZyA== X-Received: by 10.180.19.39 with SMTP id b7mr7027595wie.15.1363220909181; Wed, 13 Mar 2013 17:28:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Wed, 13 Mar 2013 17:28:08 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Wed, 13 Mar 2013 20:28:08 -0400 Message-ID: To: Katerina Mparmpopoulou Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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, Mar 13, 2013 at 5:50 AM, Katerina Mparmpopoulou wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I use xen 4.2.1 and i'm trying to do live migration without ssh. > > I read at the manual page of xl that if i place the option -s empty > the command is running as run , instead of ssh . > > I 've used the command with the following alternatives: > > - - sudo xl migrate VM3 root@ip -s > > - - sudo xl migrate VM3 root@ip -s '' > > the problem is that in the same time i run tcpdump (filtering the > particular interface/port 22/and the target host) and i can see the > ssh packets, even the -s option is empty (no parameters). > > my question is: > > How can I disable ssh???? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRQEvWAAoJEIrShLVVnSKrp94H/3dqno4IolDeyvXDLJh9JAVX > jUR+/xBSpuH49N9dKxczOc89SWjPHNhZ58lvUlvZMm/NiPrRGmm+oR2nLg5YTue+ > A5GzX4X23v2P6lDNHYiCREIULzjKvZEMrT8MwmUy/+AGl3NZ0tw+uwgdctWd2kqK > eSiKqCErDTbjK73D74Mxrt4NWwSTOcGaBBZleqGOlQtIUIvlkBT+7OzsNqAlC8Ar > j+TN9TRmiYPJBC3IHLBW2ZrDs+9sxXAVwL2braJSY4sV1sXEfI17Z4fl48ubWOX0 > 4fh+Xg6esKK9Jy6LsMEJCEzvbpPEWyb0ukqeYDD3pFf2cTVKFQfN5fZxEH0QP9E= > =XrqQ > -----END PGP SIGNATURE----- > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users I'm rather curious as to why you want to disable SSH. Since the migration is passing raw memory blocks across the network, this is certainly something that ought to be encrypted to prevent both monkeying and sniffing. Regardless, to migrate using some program other than SSH, you need something akin to it (e.g. tenlet, RSH, etc.). Xen does not create a migration "socket" on its own, AFAIK the xl migrate scheme passes the data to xl on the receiving side through stdin on the terminal. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 00:29:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 00:29: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 1UFw23-0001ag-P2; Thu, 14 Mar 2013 00:28:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFw22-0001ab-TM for xen-users@lists.xen.org; Thu, 14 Mar 2013 00:28:31 +0000 Received: from [85.158.139.83:60224] by server-10.bemta-5.messagelabs.com id 11/45-23714-EA911415; Thu, 14 Mar 2013 00:28:30 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1363220909!24276386!1 X-Originating-IP: [74.125.82.175] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8634 invoked from network); 14 Mar 2013 00:28:29 -0000 Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 00:28:29 -0000 Received: by mail-we0-f175.google.com with SMTP id x8so1610965wey.20 for ; Wed, 13 Mar 2013 17:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=pU2MrV4/Eetdjz5iIvwMi2Mdcne1nJjnmagU98oR9gY=; b=oHrGszsDsBFLMk60jURqYBm2WERVS3jwepHj3gSb/FE5JsCL59VQE/gVzkpNnbrmJs FzLxcaGZ4dnruRblZ94t78l+6PGMrshbbflNsWIsdkzFBksM9TILhn+j8fSAT3J8q/TK iC/ZwhZXg1/WStqhRI9/ZFJpf4JsmhrJ3MtlV1xSDiG2bST8guQT8ZWlUJ6oJIqQWrsv XhrHI9cxscPWeR7CRv4MHmamVtoKixGSb5002nLMzdf/UMobyua5nViqXSbwEpOfaK67 prs0CqoL+iAIFFzWlRScmMlsKnXU4Bk1yQBXU2q8ADZ12WpEUxpSe54QSEdzeo0ZPFqi LZyA== X-Received: by 10.180.19.39 with SMTP id b7mr7027595wie.15.1363220909181; Wed, 13 Mar 2013 17:28:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Wed, 13 Mar 2013 17:28:08 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Wed, 13 Mar 2013 20:28:08 -0400 Message-ID: To: Katerina Mparmpopoulou Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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, Mar 13, 2013 at 5:50 AM, Katerina Mparmpopoulou wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I use xen 4.2.1 and i'm trying to do live migration without ssh. > > I read at the manual page of xl that if i place the option -s empty > the command is running as run , instead of ssh . > > I 've used the command with the following alternatives: > > - - sudo xl migrate VM3 root@ip -s > > - - sudo xl migrate VM3 root@ip -s '' > > the problem is that in the same time i run tcpdump (filtering the > particular interface/port 22/and the target host) and i can see the > ssh packets, even the -s option is empty (no parameters). > > my question is: > > How can I disable ssh???? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRQEvWAAoJEIrShLVVnSKrp94H/3dqno4IolDeyvXDLJh9JAVX > jUR+/xBSpuH49N9dKxczOc89SWjPHNhZ58lvUlvZMm/NiPrRGmm+oR2nLg5YTue+ > A5GzX4X23v2P6lDNHYiCREIULzjKvZEMrT8MwmUy/+AGl3NZ0tw+uwgdctWd2kqK > eSiKqCErDTbjK73D74Mxrt4NWwSTOcGaBBZleqGOlQtIUIvlkBT+7OzsNqAlC8Ar > j+TN9TRmiYPJBC3IHLBW2ZrDs+9sxXAVwL2braJSY4sV1sXEfI17Z4fl48ubWOX0 > 4fh+Xg6esKK9Jy6LsMEJCEzvbpPEWyb0ukqeYDD3pFf2cTVKFQfN5fZxEH0QP9E= > =XrqQ > -----END PGP SIGNATURE----- > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users I'm rather curious as to why you want to disable SSH. Since the migration is passing raw memory blocks across the network, this is certainly something that ought to be encrypted to prevent both monkeying and sniffing. Regardless, to migrate using some program other than SSH, you need something akin to it (e.g. tenlet, RSH, etc.). Xen does not create a migration "socket" on its own, AFAIK the xl migrate scheme passes the data to xl on the receiving side through stdin on the terminal. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 00:51:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 00:51: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 1UFwNQ-00021B-5d; Thu, 14 Mar 2013 00:50:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFwNO-000216-U2 for xen-users@lists.xen.org; Thu, 14 Mar 2013 00:50:35 +0000 Received: from [85.158.143.99:7515] by server-1.bemta-4.messagelabs.com id 83/3E-06203-ADE11415; Thu, 14 Mar 2013 00:50:34 +0000 X-Env-Sender: kate_mparmpop@hotmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1363222232!18771977!1 X-Originating-IP: [65.55.111.98] X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD, ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_2, MSGID_FROM_MTA_HEADER,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30898 invoked from network); 14 Mar 2013 00:50:32 -0000 Received: from blu0-omc2-s23.blu0.hotmail.com (HELO blu0-omc2-s23.blu0.hotmail.com) (65.55.111.98) by server-14.tower-216.messagelabs.com with SMTP; 14 Mar 2013 00:50:32 -0000 Received: from BLU0-SMTP71 ([65.55.111.72]) by blu0-omc2-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Mar 2013 17:50:32 -0700 X-EIP: [W6LGfFjX6cCx40qrIFKdI/V5YX/mQyq7] X-Originating-Email: [kate_mparmpop@hotmail.com] Message-ID: Received: from [192.168.0.100] ([82.139.117.118]) by BLU0-SMTP71.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Mar 2013 17:50:30 -0700 Date: Thu, 14 Mar 2013 01:50:28 +0100 From: Katerina Mparmpopoulou User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org, zootboysean@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.5.1 X-OriginalArrivalTime: 14 Mar 2013 00:50:30.0791 (UTC) FILETIME=[ED680170:01CE204D] Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2013 01:28 AM, Sean Greenslade wrote: > On Wed, Mar 13, 2013 at 5:50 AM, Katerina Mparmpopoulou > wrote: Hi all, > > I use xen 4.2.1 and i'm trying to do live migration without ssh. > > I read at the manual page of xl that if i place the option -s > empty the command is running as run , instead of ssh . > > I 've used the command with the following alternatives: > > - sudo xl migrate VM3 root@ip -s > > - sudo xl migrate VM3 root@ip -s '' > > the problem is that in the same time i run tcpdump (filtering the > particular interface/port 22/and the target host) and i can see > the ssh packets, even the -s option is empty (no parameters). > > my question is: > > How can I disable ssh???? >> >> _______________________________________________ Xen-users mailing >> list Xen-users@lists.xen.org http://lists.xen.org/xen-users > > I'm rather curious as to why you want to disable SSH. Since the > migration is passing raw memory blocks across the network, this is > certainly something that ought to be encrypted to prevent both > monkeying and sniffing. > also if the migration takes place in a private dedicated network for example this is not the case. disabling ssh decreases cpu load and probably gives better performance. However my real intention is only to monitor the difference in performance for purely research purposes. :) > Regardless, to migrate using some program other than SSH, you need > something akin to it (e.g. tenlet, RSH, etc.). Xen does not create > a migration "socket" on its own, yeah i have understand that. I think that it uses the same certificate as the target machine uses for the ssh login for example. AFAIK the xl migrate scheme passes the > data to xl on the receiving side through stdin on the terminal. > I would be grateful if you can place me hints of how i can use that to achieve my goal. :) Thanks, Katerina -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQR7UAAoJEIrShLVVnSKr1doIAJM9CldXO+fQLZGGk1tDMF24 AZPrLcgvixQJWx72Tz84V5UcDTLzYS6GwTTidY65/6UzdANUx6lbe2FuuNKQN63X QA7w2d9mPXnmLA21I+u1iocLdeQAbpVr3uIPYbRbHGK26hkDg4X4+pbIBmncRrjO CokT1gqj+JARG+H7EdqHoy7Rh35XN2bcScXn4WY5uwN7HK7uKrHybRQU/zNh8aY6 9SQbbmuZzy7EJg0e0qtQO6b4JVSUD2TJp//1blZRK/BRGhsIiQUApFUi72QH/zXw UQPFZW2utOd7fxR8nKRVReGgtKQuoiTiWcEuzpCUL0+mgnndxmHiG/XTeSmP8MY= =oVhA -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 00:51:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 00:51: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 1UFwNQ-00021B-5d; Thu, 14 Mar 2013 00:50:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFwNO-000216-U2 for xen-users@lists.xen.org; Thu, 14 Mar 2013 00:50:35 +0000 Received: from [85.158.143.99:7515] by server-1.bemta-4.messagelabs.com id 83/3E-06203-ADE11415; Thu, 14 Mar 2013 00:50:34 +0000 X-Env-Sender: kate_mparmpop@hotmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1363222232!18771977!1 X-Originating-IP: [65.55.111.98] X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD, ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_2, MSGID_FROM_MTA_HEADER,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30898 invoked from network); 14 Mar 2013 00:50:32 -0000 Received: from blu0-omc2-s23.blu0.hotmail.com (HELO blu0-omc2-s23.blu0.hotmail.com) (65.55.111.98) by server-14.tower-216.messagelabs.com with SMTP; 14 Mar 2013 00:50:32 -0000 Received: from BLU0-SMTP71 ([65.55.111.72]) by blu0-omc2-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Mar 2013 17:50:32 -0700 X-EIP: [W6LGfFjX6cCx40qrIFKdI/V5YX/mQyq7] X-Originating-Email: [kate_mparmpop@hotmail.com] Message-ID: Received: from [192.168.0.100] ([82.139.117.118]) by BLU0-SMTP71.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Mar 2013 17:50:30 -0700 Date: Thu, 14 Mar 2013 01:50:28 +0100 From: Katerina Mparmpopoulou User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org, zootboysean@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.5.1 X-OriginalArrivalTime: 14 Mar 2013 00:50:30.0791 (UTC) FILETIME=[ED680170:01CE204D] Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2013 01:28 AM, Sean Greenslade wrote: > On Wed, Mar 13, 2013 at 5:50 AM, Katerina Mparmpopoulou > wrote: Hi all, > > I use xen 4.2.1 and i'm trying to do live migration without ssh. > > I read at the manual page of xl that if i place the option -s > empty the command is running as run , instead of ssh . > > I 've used the command with the following alternatives: > > - sudo xl migrate VM3 root@ip -s > > - sudo xl migrate VM3 root@ip -s '' > > the problem is that in the same time i run tcpdump (filtering the > particular interface/port 22/and the target host) and i can see > the ssh packets, even the -s option is empty (no parameters). > > my question is: > > How can I disable ssh???? >> >> _______________________________________________ Xen-users mailing >> list Xen-users@lists.xen.org http://lists.xen.org/xen-users > > I'm rather curious as to why you want to disable SSH. Since the > migration is passing raw memory blocks across the network, this is > certainly something that ought to be encrypted to prevent both > monkeying and sniffing. > also if the migration takes place in a private dedicated network for example this is not the case. disabling ssh decreases cpu load and probably gives better performance. However my real intention is only to monitor the difference in performance for purely research purposes. :) > Regardless, to migrate using some program other than SSH, you need > something akin to it (e.g. tenlet, RSH, etc.). Xen does not create > a migration "socket" on its own, yeah i have understand that. I think that it uses the same certificate as the target machine uses for the ssh login for example. AFAIK the xl migrate scheme passes the > data to xl on the receiving side through stdin on the terminal. > I would be grateful if you can place me hints of how i can use that to achieve my goal. :) Thanks, Katerina -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRQR7UAAoJEIrShLVVnSKr1doIAJM9CldXO+fQLZGGk1tDMF24 AZPrLcgvixQJWx72Tz84V5UcDTLzYS6GwTTidY65/6UzdANUx6lbe2FuuNKQN63X QA7w2d9mPXnmLA21I+u1iocLdeQAbpVr3uIPYbRbHGK26hkDg4X4+pbIBmncRrjO CokT1gqj+JARG+H7EdqHoy7Rh35XN2bcScXn4WY5uwN7HK7uKrHybRQU/zNh8aY6 9SQbbmuZzy7EJg0e0qtQO6b4JVSUD2TJp//1blZRK/BRGhsIiQUApFUi72QH/zXw UQPFZW2utOd7fxR8nKRVReGgtKQuoiTiWcEuzpCUL0+mgnndxmHiG/XTeSmP8MY= =oVhA -----END PGP SIGNATURE----- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 01:57:23 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 01:57: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 1UFxOx-0006i2-EA; Thu, 14 Mar 2013 01:56:15 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFxOv-0006hx-JS for xen-users@lists.xen.org; Thu, 14 Mar 2013 01:56:13 +0000 Received: from [193.109.254.147:15515] by server-5.bemta-14.messagelabs.com id 5A/6C-09030-C3E21415; Thu, 14 Mar 2013 01:56:12 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1363226168!6362036!1 X-Originating-IP: [74.125.82.182] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30449 invoked from network); 14 Mar 2013 01:56:09 -0000 Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 01:56:09 -0000 Received: by mail-we0-f182.google.com with SMTP id t57so1643350wey.41 for ; Wed, 13 Mar 2013 18:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=BhuhAcAUJP+LXiHBND3ID3UcMHWARfSerOEgl8K5ZBk=; b=RocuzKjLJjFmP+gLCKLz6U5vbFOe0VOehVe5Td+mlywAv9At8MXwXHM4qau4GDqpg0 5QkQ3nmm6Xp63j3AYjwlJ7pNYCgNhMZ1CUnAauSkzXHAgJtaemkvfoH36qSwJy9Tu4v7 4ID1FV399+gI/eyM338635y6x0UdRi9h9ifFB9+DXYviHqyOHra50VMSkPqK8oX3qkvA le+jSY4t5vPjg8sPi2PFevYMDFc2oVh8dNiHd2jgnYiVhrUxlbYkrX7S1l9UZEBaaDBk URdS/eP3O2h4HX47AKsDRmEG7x2V8rXm190DtA8L0OAOl5nckwrnV5LARjVeoRgepy0D k5Rw== X-Received: by 10.194.71.241 with SMTP id y17mr554019wju.28.1363226168551; Wed, 13 Mar 2013 18:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Wed, 13 Mar 2013 18:55:48 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Wed, 13 Mar 2013 21:55:48 -0400 Message-ID: To: Katerina Mparmpopoulou Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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 rather curious as to why you want to disable SSH. Since the >> migration is passing raw memory blocks across the network, this is >> certainly something that ought to be encrypted to prevent both >> monkeying and sniffing. >> > > also if the migration takes place in a private dedicated network for > example this is not the case. disabling ssh decreases cpu load and > probably gives better performance. However my real intention is only > to monitor the difference in performance for purely research purposes. :) Wonderful! Just had to do my due diligence. >> Regardless, to migrate using some program other than SSH, you need >> something akin to it (e.g. tenlet, RSH, etc.). Xen does not create >> a migration "socket" on its own, > > yeah i have understand that. I think that it uses the same certificate > as the target machine uses for the ssh login for example. That's because it's just ssh. Nothing special or fancy, just run of the mill ssh. It does the standard fingerprint checking that's done with any ssh initiation, with the one slight gotcha of xl being run as root, so the /root/.sshh/known_hosts file is used instead of your own. >> AFAIK the xl migrate scheme passes the >> data to xl on the receiving side through stdin on the terminal. >> > > I would be grateful if you can place me hints of how i can use that to > achieve my goal. :) > > Thanks, > > Katerina As I said, you'll first need to get some sort of remote shell working. My suggestions are for RSH or Telnet, but anything that can get you a shell will work. Unfortunately, I have absolutely no experience with either, as I have been raised in an ssh world. In fact, I use sshfs for remote file shares, and I've never had an issue with performance bottlenecks even while saturating my gigabit link. So not that I'm discouraging your academic exploration, but I would say that in all likelihood, the performance loss of using ssh is negligible and the security gained is substantial. Just my $0.02. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRQR7UAAoJEIrShLVVnSKr1doIAJM9CldXO+fQLZGGk1tDMF24 > AZPrLcgvixQJWx72Tz84V5UcDTLzYS6GwTTidY65/6UzdANUx6lbe2FuuNKQN63X > QA7w2d9mPXnmLA21I+u1iocLdeQAbpVr3uIPYbRbHGK26hkDg4X4+pbIBmncRrjO > CokT1gqj+JARG+H7EdqHoy7Rh35XN2bcScXn4WY5uwN7HK7uKrHybRQU/zNh8aY6 > 9SQbbmuZzy7EJg0e0qtQO6b4JVSUD2TJp//1blZRK/BRGhsIiQUApFUi72QH/zXw > UQPFZW2utOd7fxR8nKRVReGgtKQuoiTiWcEuzpCUL0+mgnndxmHiG/XTeSmP8MY= > =oVhA > -----END PGP SIGNATURE----- -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 01:57:23 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 01:57: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 1UFxOx-0006i2-EA; Thu, 14 Mar 2013 01:56:15 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFxOv-0006hx-JS for xen-users@lists.xen.org; Thu, 14 Mar 2013 01:56:13 +0000 Received: from [193.109.254.147:15515] by server-5.bemta-14.messagelabs.com id 5A/6C-09030-C3E21415; Thu, 14 Mar 2013 01:56:12 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1363226168!6362036!1 X-Originating-IP: [74.125.82.182] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30449 invoked from network); 14 Mar 2013 01:56:09 -0000 Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 01:56:09 -0000 Received: by mail-we0-f182.google.com with SMTP id t57so1643350wey.41 for ; Wed, 13 Mar 2013 18:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=BhuhAcAUJP+LXiHBND3ID3UcMHWARfSerOEgl8K5ZBk=; b=RocuzKjLJjFmP+gLCKLz6U5vbFOe0VOehVe5Td+mlywAv9At8MXwXHM4qau4GDqpg0 5QkQ3nmm6Xp63j3AYjwlJ7pNYCgNhMZ1CUnAauSkzXHAgJtaemkvfoH36qSwJy9Tu4v7 4ID1FV399+gI/eyM338635y6x0UdRi9h9ifFB9+DXYviHqyOHra50VMSkPqK8oX3qkvA le+jSY4t5vPjg8sPi2PFevYMDFc2oVh8dNiHd2jgnYiVhrUxlbYkrX7S1l9UZEBaaDBk URdS/eP3O2h4HX47AKsDRmEG7x2V8rXm190DtA8L0OAOl5nckwrnV5LARjVeoRgepy0D k5Rw== X-Received: by 10.194.71.241 with SMTP id y17mr554019wju.28.1363226168551; Wed, 13 Mar 2013 18:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Wed, 13 Mar 2013 18:55:48 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Wed, 13 Mar 2013 21:55:48 -0400 Message-ID: To: Katerina Mparmpopoulou Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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 rather curious as to why you want to disable SSH. Since the >> migration is passing raw memory blocks across the network, this is >> certainly something that ought to be encrypted to prevent both >> monkeying and sniffing. >> > > also if the migration takes place in a private dedicated network for > example this is not the case. disabling ssh decreases cpu load and > probably gives better performance. However my real intention is only > to monitor the difference in performance for purely research purposes. :) Wonderful! Just had to do my due diligence. >> Regardless, to migrate using some program other than SSH, you need >> something akin to it (e.g. tenlet, RSH, etc.). Xen does not create >> a migration "socket" on its own, > > yeah i have understand that. I think that it uses the same certificate > as the target machine uses for the ssh login for example. That's because it's just ssh. Nothing special or fancy, just run of the mill ssh. It does the standard fingerprint checking that's done with any ssh initiation, with the one slight gotcha of xl being run as root, so the /root/.sshh/known_hosts file is used instead of your own. >> AFAIK the xl migrate scheme passes the >> data to xl on the receiving side through stdin on the terminal. >> > > I would be grateful if you can place me hints of how i can use that to > achieve my goal. :) > > Thanks, > > Katerina As I said, you'll first need to get some sort of remote shell working. My suggestions are for RSH or Telnet, but anything that can get you a shell will work. Unfortunately, I have absolutely no experience with either, as I have been raised in an ssh world. In fact, I use sshfs for remote file shares, and I've never had an issue with performance bottlenecks even while saturating my gigabit link. So not that I'm discouraging your academic exploration, but I would say that in all likelihood, the performance loss of using ssh is negligible and the security gained is substantial. Just my $0.02. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRQR7UAAoJEIrShLVVnSKr1doIAJM9CldXO+fQLZGGk1tDMF24 > AZPrLcgvixQJWx72Tz84V5UcDTLzYS6GwTTidY65/6UzdANUx6lbe2FuuNKQN63X > QA7w2d9mPXnmLA21I+u1iocLdeQAbpVr3uIPYbRbHGK26hkDg4X4+pbIBmncRrjO > CokT1gqj+JARG+H7EdqHoy7Rh35XN2bcScXn4WY5uwN7HK7uKrHybRQU/zNh8aY6 > 9SQbbmuZzy7EJg0e0qtQO6b4JVSUD2TJp//1blZRK/BRGhsIiQUApFUi72QH/zXw > UQPFZW2utOd7fxR8nKRVReGgtKQuoiTiWcEuzpCUL0+mgnndxmHiG/XTeSmP8MY= > =oVhA > -----END PGP SIGNATURE----- -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 02:13:51 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 02:13: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 1UFxev-0007RK-8d; Thu, 14 Mar 2013 02:12:45 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFxet-0007RD-VM for xen-users@lists.xen.org; Thu, 14 Mar 2013 02:12:44 +0000 Received: from [193.109.254.147:49058] by server-11.bemta-14.messagelabs.com id 5E/B7-24840-B1231415; Thu, 14 Mar 2013 02:12:43 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1363226725!8595522!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15366 invoked from network); 14 Mar 2013 02:05:33 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 02:05:33 -0000 Received: by mail-wg0-f43.google.com with SMTP id e12so1253016wge.10 for ; Wed, 13 Mar 2013 19:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=zepUz3ywygeAf/1z4CGb903rGLgvUvLMSxCJMFBpjsE=; b=rffn7EQ0Fk1uh6woru2ie3a3fALnXhI7pHl8alJFtCWV7kQ6l97aiY2TU0vPpSk0ks YM5CNAmD3bJmZWg1qJ6xKGi8gVtDsamzzwnjuE8eNRR17dxwGGAMHaj9eO80WYycH5ss Y9vvAd3K56EkDxyqdvXkFXSqHADeLE4B0voBMV9mwqDsZxoQRhXcdL1ZLl86tFvdU0GA GEQTkgcrTx0GdrqEIpmP8KqzkcLkZmKWnlyGsdVN8z0I6gTkKGhkSQ4zGQZ9YG8UJYAS QxG1XXz7UpoWaFLTuG9NB6YAw83JbT0FMezfFplfQ619b42JBkBVvvXniyyDBe4+N/bk Fa/A== X-Received: by 10.180.78.168 with SMTP id c8mr800834wix.27.1363226721092; Wed, 13 Mar 2013 19:05:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Wed, 13 Mar 2013 19:05:00 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Wed, 13 Mar 2013 22:05:00 -0400 Message-ID: To: Katerina Mparmpopoulou Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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 > As I said, you'll first need to get some sort of remote shell working. > My suggestions are for RSH or Telnet, but anything that can get you a > shell will work. Unfortunately, I have absolutely no experience with > either, as I have been raised in an ssh world. In fact, I use sshfs > for remote file shares, and I've never had an issue with performance > bottlenecks even while saturating my gigabit link. So not that I'm > discouraging your academic exploration, but I would say that in all > likelihood, the performance loss of using ssh is negligible and the > security gained is substantial. Just my $0.02. And, of course, itchy send finger strikes again. Once you have a remote shell, you simply need the command line string necessary to open said remote shell. Then xl migrate will take over from there. Check out "man xl" for info on that, especially the -s flag. Essentially, you'll need to pass everything necessary for the shell to open within that string. I haven't played around with it enough to know if it can deal with a password prompt correctly, so you'll have to test that out for yourself. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 02:13:51 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 02:13: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 1UFxev-0007RK-8d; Thu, 14 Mar 2013 02:12:45 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UFxet-0007RD-VM for xen-users@lists.xen.org; Thu, 14 Mar 2013 02:12:44 +0000 Received: from [193.109.254.147:49058] by server-11.bemta-14.messagelabs.com id 5E/B7-24840-B1231415; Thu, 14 Mar 2013 02:12:43 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1363226725!8595522!1 X-Originating-IP: [74.125.82.43] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15366 invoked from network); 14 Mar 2013 02:05:33 -0000 Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 02:05:33 -0000 Received: by mail-wg0-f43.google.com with SMTP id e12so1253016wge.10 for ; Wed, 13 Mar 2013 19:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=zepUz3ywygeAf/1z4CGb903rGLgvUvLMSxCJMFBpjsE=; b=rffn7EQ0Fk1uh6woru2ie3a3fALnXhI7pHl8alJFtCWV7kQ6l97aiY2TU0vPpSk0ks YM5CNAmD3bJmZWg1qJ6xKGi8gVtDsamzzwnjuE8eNRR17dxwGGAMHaj9eO80WYycH5ss Y9vvAd3K56EkDxyqdvXkFXSqHADeLE4B0voBMV9mwqDsZxoQRhXcdL1ZLl86tFvdU0GA GEQTkgcrTx0GdrqEIpmP8KqzkcLkZmKWnlyGsdVN8z0I6gTkKGhkSQ4zGQZ9YG8UJYAS QxG1XXz7UpoWaFLTuG9NB6YAw83JbT0FMezfFplfQ619b42JBkBVvvXniyyDBe4+N/bk Fa/A== X-Received: by 10.180.78.168 with SMTP id c8mr800834wix.27.1363226721092; Wed, 13 Mar 2013 19:05:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.9.68 with HTTP; Wed, 13 Mar 2013 19:05:00 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Wed, 13 Mar 2013 22:05:00 -0400 Message-ID: To: Katerina Mparmpopoulou Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.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 > As I said, you'll first need to get some sort of remote shell working. > My suggestions are for RSH or Telnet, but anything that can get you a > shell will work. Unfortunately, I have absolutely no experience with > either, as I have been raised in an ssh world. In fact, I use sshfs > for remote file shares, and I've never had an issue with performance > bottlenecks even while saturating my gigabit link. So not that I'm > discouraging your academic exploration, but I would say that in all > likelihood, the performance loss of using ssh is negligible and the > security gained is substantial. Just my $0.02. And, of course, itchy send finger strikes again. Once you have a remote shell, you simply need the command line string necessary to open said remote shell. Then xl migrate will take over from there. Check out "man xl" for info on that, especially the -s flag. Essentially, you'll need to pass everything necessary for the shell to open within that string. I haven't played around with it enough to know if it can deal with a password prompt correctly, so you'll have to test that out for yourself. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 11:00:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 11: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 1UG5sS-0004Lk-Vl; Thu, 14 Mar 2013 10:59:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG5sP-0004Lb-At; Thu, 14 Mar 2013 10:59:15 +0000 Received: from [85.158.139.83:30245] by server-12.bemta-5.messagelabs.com id D2/8F-11486-08DA1415; Thu, 14 Mar 2013 10:59:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1363258730!23168884!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28452 invoked from network); 14 Mar 2013 10:58:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 10:58:50 -0000 X-IronPort-AV: E=Sophos;i="4.84,844,1355097600"; d="scan'208";a="2502918" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Mar 2013 10:58:50 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Thu, 14 Mar 2013 10:58:50 +0000 Message-ID: <1363258728.32410.241.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Felix Feng Date: Thu, 14 Mar 2013 10:58:48 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: xen-users Subject: Re: [Xen-users] [Xen-devel] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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, 2013-03-14 at 10:49 +0000, Felix Feng wrote: > I just compiled xen-4.1.3 and Dom0 kernel 2.6.32. After booting, I > executed `xl list`, but I hit this problem: This list is for the development of Xen, not user support. I have moved xen-devel to Bcc and added xen-users instead. > Is that a known issue, or any suggetsions? It seems like you have already got the information you need, in other words you need to make sure that the xen-evtchn and xen-gntdev modules are available with your kernel. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 11:00:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 11: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 1UG5sS-0004Lk-Vl; Thu, 14 Mar 2013 10:59:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG5sP-0004Lb-At; Thu, 14 Mar 2013 10:59:15 +0000 Received: from [85.158.139.83:30245] by server-12.bemta-5.messagelabs.com id D2/8F-11486-08DA1415; Thu, 14 Mar 2013 10:59:12 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1363258730!23168884!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28452 invoked from network); 14 Mar 2013 10:58:50 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 10:58:50 -0000 X-IronPort-AV: E=Sophos;i="4.84,844,1355097600"; d="scan'208";a="2502918" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Mar 2013 10:58:50 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Thu, 14 Mar 2013 10:58:50 +0000 Message-ID: <1363258728.32410.241.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Felix Feng Date: Thu, 14 Mar 2013 10:58:48 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: xen-users Subject: Re: [Xen-users] [Xen-devel] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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, 2013-03-14 at 10:49 +0000, Felix Feng wrote: > I just compiled xen-4.1.3 and Dom0 kernel 2.6.32. After booting, I > executed `xl list`, but I hit this problem: This list is for the development of Xen, not user support. I have moved xen-devel to Bcc and added xen-users instead. > Is that a known issue, or any suggetsions? It seems like you have already got the information you need, in other words you need to make sure that the xen-evtchn and xen-gntdev modules are available with your kernel. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 11:08:54 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 11:08: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 1UG60k-0004gA-BD; Thu, 14 Mar 2013 11:07:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG60j-0004g4-Gm for xen-users@lists.xen.org; Thu, 14 Mar 2013 11:07:49 +0000 Received: from [85.158.137.99:52584] by server-16.bemta-3.messagelabs.com id FD/B5-20692-48FA1415; Thu, 14 Mar 2013 11:07:48 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-14.tower-217.messagelabs.com!1363259257!16974377!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31891 invoked from network); 14 Mar 2013 11:07:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 11:07:38 -0000 X-IronPort-AV: E=Sophos;i="4.84,844,1355097600"; d="scan'208";a="2503396" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Mar 2013 11:07:38 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Thu, 14 Mar 2013 11:07:37 +0000 Message-ID: <5141AF78.3050005@citrix.com> Date: Thu, 14 Mar 2013 12:07:36 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ian Campbell References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> In-Reply-To: <1363258728.32410.241.camel@zakaz.uk.xensource.com> Cc: xen-users , Felix Feng Subject: Re: [Xen-users] [Xen-devel] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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 14/03/13 11:58, Ian Campbell wrote: > On Thu, 2013-03-14 at 10:49 +0000, Felix Feng wrote: >> I just compiled xen-4.1.3 and Dom0 kernel 2.6.32. After booting, I >> executed `xl list`, but I hit this problem: > > This list is for the development of Xen, not user support. I have moved > xen-devel to Bcc and added xen-users instead. > >> Is that a known issue, or any suggetsions? > > It seems like you have already got the information you need, in other > words you need to make sure that the xen-evtchn and xen-gntdev modules > are available with your kernel. > # ls /etc/init.d/xen* > /etc/init.d/xen-watchdog > > Is that a known issue, or any suggetsions? Seems like your installation is incomplete. What steps did you perform to install Xen from source? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 11:08:54 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 11:08: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 1UG60k-0004gA-BD; Thu, 14 Mar 2013 11:07:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG60j-0004g4-Gm for xen-users@lists.xen.org; Thu, 14 Mar 2013 11:07:49 +0000 Received: from [85.158.137.99:52584] by server-16.bemta-3.messagelabs.com id FD/B5-20692-48FA1415; Thu, 14 Mar 2013 11:07:48 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-14.tower-217.messagelabs.com!1363259257!16974377!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31891 invoked from network); 14 Mar 2013 11:07:38 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 11:07:38 -0000 X-IronPort-AV: E=Sophos;i="4.84,844,1355097600"; d="scan'208";a="2503396" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Mar 2013 11:07:38 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Thu, 14 Mar 2013 11:07:37 +0000 Message-ID: <5141AF78.3050005@citrix.com> Date: Thu, 14 Mar 2013 12:07:36 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ian Campbell References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> In-Reply-To: <1363258728.32410.241.camel@zakaz.uk.xensource.com> Cc: xen-users , Felix Feng Subject: Re: [Xen-users] [Xen-devel] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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 14/03/13 11:58, Ian Campbell wrote: > On Thu, 2013-03-14 at 10:49 +0000, Felix Feng wrote: >> I just compiled xen-4.1.3 and Dom0 kernel 2.6.32. After booting, I >> executed `xl list`, but I hit this problem: > > This list is for the development of Xen, not user support. I have moved > xen-devel to Bcc and added xen-users instead. > >> Is that a known issue, or any suggetsions? > > It seems like you have already got the information you need, in other > words you need to make sure that the xen-evtchn and xen-gntdev modules > are available with your kernel. > # ls /etc/init.d/xen* > /etc/init.d/xen-watchdog > > Is that a known issue, or any suggetsions? Seems like your installation is incomplete. What steps did you perform to install Xen from source? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 11:36:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 11:36: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 1UG6Rm-0005Qv-26; Thu, 14 Mar 2013 11:35:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG6Rk-0005Qi-4W for xen-users@lists.xen.org; Thu, 14 Mar 2013 11:35:44 +0000 Received: from [193.109.254.147:15455] by server-9.bemta-14.messagelabs.com id F3/54-04223-F06B1415; Thu, 14 Mar 2013 11:35:43 +0000 X-Env-Sender: unixwind@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1363260941!6423395!1 X-Originating-IP: [209.85.223.172] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3505 invoked from network); 14 Mar 2013 11:35:42 -0000 Received: from mail-ie0-f172.google.com (HELO mail-ie0-f172.google.com) (209.85.223.172) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 11:35:42 -0000 Received: by mail-ie0-f172.google.com with SMTP id c10so2812507ieb.17 for ; Thu, 14 Mar 2013 04:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/gGai9pKZdzP/0h/0E4P63D6RUkaTlFJewrdW7RFPy0=; b=XyJ/hvLxe00A7u66PMgIihwJEWXD+9/LPiaq/Rc4R1Y0E4e7M6rOaCs60cTGfvvqbu 42es0NvezAr3aVJF2qQINXgFwAjaSYSx1Cu+qS7oR+cmXRS0mzOF4wooVpsuvM5msbjw cC/+JKBHRLeMTxMcHRWEGBQEOv+XW6ikZW53iCfCwZxvaM3rWrfQw9kQs8VHng0e35zc L/WsAuAL/8kdKQUSH9EJ/8C1yIrZnluxTGH3nRLvsxK/1I9ByZXbQRAGBtJivkUYjhmR wfvuhkgP2CsCboRw83IofrE3sDqCXeQE+jyfzvkxC6q/WxQykGhWbS+TK4/rFSBFLnbJ 4H1w== MIME-Version: 1.0 X-Received: by 10.50.184.132 with SMTP id eu4mr19749837igc.19.1363260941123; Thu, 14 Mar 2013 04:35:41 -0700 (PDT) Received: by 10.64.39.163 with HTTP; Thu, 14 Mar 2013 04:35:41 -0700 (PDT) In-Reply-To: <5141AF78.3050005@citrix.com> References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> <5141AF78.3050005@citrix.com> Date: Thu, 14 Mar 2013 19:35:41 +0800 Message-ID: From: Felix Feng To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Cc: xen-users , Ian Campbell Subject: Re: [Xen-users] [Xen-devel] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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="===============5863335598045914840==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5863335598045914840== Content-Type: multipart/alternative; boundary=14dae9340ebd21c5c304d7e0ec3a --14dae9340ebd21c5c304d7e0ec3a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roger, I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel packages for xen. Then I installed kernel-xen, kernel-xen-firmware, kernel-xen-devel, kernel-extra-devel, kernel-utility, kernel-utility-devel packages for Dom0 kernel. After rebooting, I hit the problem. I compiled xen and Dom0 kernel on CentOS 5.9 running in Virtual Box. Is there anything I missed? Thanks. ------ Regards, Felix On Thu, Mar 14, 2013 at 7:07 PM, Roger Pau Monn=E9 wr= ote: > On 14/03/13 11:58, Ian Campbell wrote: > > On Thu, 2013-03-14 at 10:49 +0000, Felix Feng wrote: > >> I just compiled xen-4.1.3 and Dom0 kernel 2.6.32. After booting, I > >> executed `xl list`, but I hit this problem: > > > > This list is for the development of Xen, not user support. I have moved > > xen-devel to Bcc and added xen-users instead. > > > >> Is that a known issue, or any suggetsions? > > > > It seems like you have already got the information you need, in other > > words you need to make sure that the xen-evtchn and xen-gntdev modules > > are available with your kernel. > > > # ls /etc/init.d/xen* > > /etc/init.d/xen-watchdog > > > > Is that a known issue, or any suggetsions? > > Seems like your installation is incomplete. What steps did you perform > to install Xen from source? > > --14dae9340ebd21c5c304d7e0ec3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roger,

I installed xen-hypervisor, xen-firmware, xen-tools,=20 xen-devel packages for xen. Then I installed kernel-xen,=20 kernel-xen-firmware, kernel-xen-devel, kernel-extra-devel,=20 kernel-utility, kernel-utility-devel packages for Dom0 kernel. After=20 rebooting, I hit the problem. I compiled xen and Dom0 kernel on CentOS=20 5.9 running in Virtual Box. Is there anything I missed? Thanks.

------
Regards,
Felix

On Thu, M= ar 14, 2013 at 7:07 PM, Roger Pau Monn=E9 <roger.pau@citrix.com>= wrote:
On 1= 4/03/13 11:58, Ian Campbell wrote:
> On Thu, 2013-03-14 at 10:49 +0000, Felix Feng wrote:
>> I just compiled xen-4.1.3 and Dom0 kernel 2.6.32. After booting, I=
>> executed `xl list`, but I hit this problem:
>
> This list is for the development of Xen, not user support. I have move= d
> xen-devel to Bcc and added xen-users instead.
>
>> Is that a known issue, or any suggetsions?
>
> It seems like you have already got the information you need, in other<= br> > words you need to make sure that the xen-evtchn and xen-gntdev modules=
> are available with your kernel.

> # ls /etc/init.d/xen*
> /etc/init.d/xen-watchdog
>
> Is that a known issue, or any suggetsions?

Seems like your installation is incomplete. What steps did you perfor= m
to install Xen from source?


--14dae9340ebd21c5c304d7e0ec3a-- --===============5863335598045914840== 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 --===============5863335598045914840==-- From xen-users-bounces@lists.xen.org Thu Mar 14 11:36:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 11:36: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 1UG6Rm-0005Qv-26; Thu, 14 Mar 2013 11:35:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG6Rk-0005Qi-4W for xen-users@lists.xen.org; Thu, 14 Mar 2013 11:35:44 +0000 Received: from [193.109.254.147:15455] by server-9.bemta-14.messagelabs.com id F3/54-04223-F06B1415; Thu, 14 Mar 2013 11:35:43 +0000 X-Env-Sender: unixwind@gmail.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1363260941!6423395!1 X-Originating-IP: [209.85.223.172] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3505 invoked from network); 14 Mar 2013 11:35:42 -0000 Received: from mail-ie0-f172.google.com (HELO mail-ie0-f172.google.com) (209.85.223.172) by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 11:35:42 -0000 Received: by mail-ie0-f172.google.com with SMTP id c10so2812507ieb.17 for ; Thu, 14 Mar 2013 04:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/gGai9pKZdzP/0h/0E4P63D6RUkaTlFJewrdW7RFPy0=; b=XyJ/hvLxe00A7u66PMgIihwJEWXD+9/LPiaq/Rc4R1Y0E4e7M6rOaCs60cTGfvvqbu 42es0NvezAr3aVJF2qQINXgFwAjaSYSx1Cu+qS7oR+cmXRS0mzOF4wooVpsuvM5msbjw cC/+JKBHRLeMTxMcHRWEGBQEOv+XW6ikZW53iCfCwZxvaM3rWrfQw9kQs8VHng0e35zc L/WsAuAL/8kdKQUSH9EJ/8C1yIrZnluxTGH3nRLvsxK/1I9ByZXbQRAGBtJivkUYjhmR wfvuhkgP2CsCboRw83IofrE3sDqCXeQE+jyfzvkxC6q/WxQykGhWbS+TK4/rFSBFLnbJ 4H1w== MIME-Version: 1.0 X-Received: by 10.50.184.132 with SMTP id eu4mr19749837igc.19.1363260941123; Thu, 14 Mar 2013 04:35:41 -0700 (PDT) Received: by 10.64.39.163 with HTTP; Thu, 14 Mar 2013 04:35:41 -0700 (PDT) In-Reply-To: <5141AF78.3050005@citrix.com> References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> <5141AF78.3050005@citrix.com> Date: Thu, 14 Mar 2013 19:35:41 +0800 Message-ID: From: Felix Feng To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Cc: xen-users , Ian Campbell Subject: Re: [Xen-users] [Xen-devel] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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="===============5863335598045914840==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5863335598045914840== Content-Type: multipart/alternative; boundary=14dae9340ebd21c5c304d7e0ec3a --14dae9340ebd21c5c304d7e0ec3a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roger, I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel packages for xen. Then I installed kernel-xen, kernel-xen-firmware, kernel-xen-devel, kernel-extra-devel, kernel-utility, kernel-utility-devel packages for Dom0 kernel. After rebooting, I hit the problem. I compiled xen and Dom0 kernel on CentOS 5.9 running in Virtual Box. Is there anything I missed? Thanks. ------ Regards, Felix On Thu, Mar 14, 2013 at 7:07 PM, Roger Pau Monn=E9 wr= ote: > On 14/03/13 11:58, Ian Campbell wrote: > > On Thu, 2013-03-14 at 10:49 +0000, Felix Feng wrote: > >> I just compiled xen-4.1.3 and Dom0 kernel 2.6.32. After booting, I > >> executed `xl list`, but I hit this problem: > > > > This list is for the development of Xen, not user support. I have moved > > xen-devel to Bcc and added xen-users instead. > > > >> Is that a known issue, or any suggetsions? > > > > It seems like you have already got the information you need, in other > > words you need to make sure that the xen-evtchn and xen-gntdev modules > > are available with your kernel. > > > # ls /etc/init.d/xen* > > /etc/init.d/xen-watchdog > > > > Is that a known issue, or any suggetsions? > > Seems like your installation is incomplete. What steps did you perform > to install Xen from source? > > --14dae9340ebd21c5c304d7e0ec3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roger,

I installed xen-hypervisor, xen-firmware, xen-tools,=20 xen-devel packages for xen. Then I installed kernel-xen,=20 kernel-xen-firmware, kernel-xen-devel, kernel-extra-devel,=20 kernel-utility, kernel-utility-devel packages for Dom0 kernel. After=20 rebooting, I hit the problem. I compiled xen and Dom0 kernel on CentOS=20 5.9 running in Virtual Box. Is there anything I missed? Thanks.

------
Regards,
Felix

On Thu, M= ar 14, 2013 at 7:07 PM, Roger Pau Monn=E9 <roger.pau@citrix.com>= wrote:
On 1= 4/03/13 11:58, Ian Campbell wrote:
> On Thu, 2013-03-14 at 10:49 +0000, Felix Feng wrote:
>> I just compiled xen-4.1.3 and Dom0 kernel 2.6.32. After booting, I=
>> executed `xl list`, but I hit this problem:
>
> This list is for the development of Xen, not user support. I have move= d
> xen-devel to Bcc and added xen-users instead.
>
>> Is that a known issue, or any suggetsions?
>
> It seems like you have already got the information you need, in other<= br> > words you need to make sure that the xen-evtchn and xen-gntdev modules=
> are available with your kernel.

> # ls /etc/init.d/xen*
> /etc/init.d/xen-watchdog
>
> Is that a known issue, or any suggetsions?

Seems like your installation is incomplete. What steps did you perfor= m
to install Xen from source?


--14dae9340ebd21c5c304d7e0ec3a-- --===============5863335598045914840== 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 --===============5863335598045914840==-- From xen-users-bounces@lists.xen.org Thu Mar 14 11:42:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 11:42: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 1UG6XW-0005lT-6L; Thu, 14 Mar 2013 11:41:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG6XU-0005lM-TZ for xen-users@lists.xen.org; Thu, 14 Mar 2013 11:41:41 +0000 Received: from [85.158.139.211:4787] by server-6.bemta-5.messagelabs.com id F2/95-21466-477B1415; Thu, 14 Mar 2013 11:41:40 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1363261299!18297888!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23895 invoked from network); 14 Mar 2013 11:41:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 11:41:39 -0000 X-IronPort-AV: E=Sophos;i="4.84,844,1355097600"; d="scan'208";a="2504859" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Mar 2013 11:41:40 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Thu, 14 Mar 2013 11:41:39 +0000 Message-ID: <5141B772.1060900@citrix.com> Date: Thu, 14 Mar 2013 12:41:38 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Felix Feng References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> <5141AF78.3050005@citrix.com> In-Reply-To: Cc: xen-users , Ian Campbell Subject: Re: [Xen-users] [Xen-devel] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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 14/03/13 12:35, Felix Feng wrote: > Hi Roger, > > I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel packages > for xen. Then I installed kernel-xen, kernel-xen-firmware, > kernel-xen-devel, kernel-extra-devel, kernel-utility, > kernel-utility-devel packages for Dom0 kernel. After rebooting, I hit > the problem. I compiled xen and Dom0 kernel on CentOS 5.9 running in > Virtual Box. Is there anything I missed? Thanks. I don't understand this, why did you install all the Xen packages if you ended up compiling it yourself? Did you mean that you compiled the Xen kernel from a different version and tried to use it with the tools from the packages your distro provides? Because that is certainly not going to work if they are from different versions. Anyway, I would recommend using the packages your distro provides, and you seem to be missing init scripts at least, so I would check which package provides those init scripts. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 11:42:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 11:42: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 1UG6XW-0005lT-6L; Thu, 14 Mar 2013 11:41:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG6XU-0005lM-TZ for xen-users@lists.xen.org; Thu, 14 Mar 2013 11:41:41 +0000 Received: from [85.158.139.211:4787] by server-6.bemta-5.messagelabs.com id F2/95-21466-477B1415; Thu, 14 Mar 2013 11:41:40 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1363261299!18297888!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23895 invoked from network); 14 Mar 2013 11:41:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 11:41:39 -0000 X-IronPort-AV: E=Sophos;i="4.84,844,1355097600"; d="scan'208";a="2504859" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Mar 2013 11:41:40 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Thu, 14 Mar 2013 11:41:39 +0000 Message-ID: <5141B772.1060900@citrix.com> Date: Thu, 14 Mar 2013 12:41:38 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Felix Feng References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> <5141AF78.3050005@citrix.com> In-Reply-To: Cc: xen-users , Ian Campbell Subject: Re: [Xen-users] [Xen-devel] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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 14/03/13 12:35, Felix Feng wrote: > Hi Roger, > > I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel packages > for xen. Then I installed kernel-xen, kernel-xen-firmware, > kernel-xen-devel, kernel-extra-devel, kernel-utility, > kernel-utility-devel packages for Dom0 kernel. After rebooting, I hit > the problem. I compiled xen and Dom0 kernel on CentOS 5.9 running in > Virtual Box. Is there anything I missed? Thanks. I don't understand this, why did you install all the Xen packages if you ended up compiling it yourself? Did you mean that you compiled the Xen kernel from a different version and tried to use it with the tools from the packages your distro provides? Because that is certainly not going to work if they are from different versions. Anyway, I would recommend using the packages your distro provides, and you seem to be missing init scripts at least, so I would check which package provides those init scripts. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 13:39:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 13:39: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 1UG8MY-0007KN-MQ; Thu, 14 Mar 2013 13:38:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG8MW-0007KI-Ty for xen-users@lists.xen.org; Thu, 14 Mar 2013 13:38:29 +0000 Received: from [85.158.137.99:35233] by server-1.bemta-3.messagelabs.com id C1/50-13706-4C2D1415; Thu, 14 Mar 2013 13:38:12 +0000 X-Env-Sender: paul@stimpsonfamily.co.uk X-Msg-Ref: server-3.tower-217.messagelabs.com!1363268282!11963993!1 X-Originating-IP: [94.136.40.61] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n,sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7321 invoked from network); 14 Mar 2013 13:38:02 -0000 Received: from mailex.mailcore.me (HELO mailex.mailcore.me) (94.136.40.61) by server-3.tower-217.messagelabs.com with SMTP; 14 Mar 2013 13:38:02 -0000 Received: from [192.165.210.4] (helo=[192.168.225.223]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UG8M6-0000vX-1i; Thu, 14 Mar 2013 13:38:02 +0000 Message-ID: <5141D2B6.9070807@stimpsonfamily.co.uk> Date: Thu, 14 Mar 2013 13:37:58 +0000 From: Paul Stimpson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ian Campbell References: <513E2B4F.7030600@stimpsonfamily.co.uk> <1363090305.29599.14.camel@zakaz.uk.xensource.com> In-Reply-To: <1363090305.29599.14.camel@zakaz.uk.xensource.com> X-Mailcore-Auth: 8324857 X-Mailcore-Domain: 844183 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Windows QEMU resolution X-BeenThere: xen-users@lists.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 12/03/13 12:11, Ian Campbell wrote: > You need to be looking at the options relating to the emulated VGA > device and video ram etc in xl.cfg(5). Ian. Thank you. You are correct that, in my inexperience, I had insufficiently studied and understood the documentation. I managed to get the VGA correctly working using Gabor's method. I now have a different difficulty. I'm running HVM Windows Server 2008 R2. I turned the resolution up in steps and ti was fine until I hit 1600x1050. As soon as I selected that, the vnc session terminated (using gvncviewer) and I can't re-establish it (it flashes up, reports the 1600x1050 resolution in the console I launched it from then says that the session has terminated and closes). I tried increasing the videoram line but this didn't help. I then commented out both the stdvga and videoram lines and was able to access Windows in 1024x768 as before. I turned the screen rez down to 800x600, put the stdvga and videoram lines back and restarted. Windows (thinking it was being helpful) put the resolution back to 1600x1050 and it failed again. Is there any way I can stop the VNC console dying at high resolutions or stop Windows from restoring the old, non-working resolution when I put the virtual cirrus card back please? Thanks, Paul. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 13:39:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 13:39: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 1UG8MY-0007KN-MQ; Thu, 14 Mar 2013 13:38:30 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG8MW-0007KI-Ty for xen-users@lists.xen.org; Thu, 14 Mar 2013 13:38:29 +0000 Received: from [85.158.137.99:35233] by server-1.bemta-3.messagelabs.com id C1/50-13706-4C2D1415; Thu, 14 Mar 2013 13:38:12 +0000 X-Env-Sender: paul@stimpsonfamily.co.uk X-Msg-Ref: server-3.tower-217.messagelabs.com!1363268282!11963993!1 X-Originating-IP: [94.136.40.61] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n,sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7321 invoked from network); 14 Mar 2013 13:38:02 -0000 Received: from mailex.mailcore.me (HELO mailex.mailcore.me) (94.136.40.61) by server-3.tower-217.messagelabs.com with SMTP; 14 Mar 2013 13:38:02 -0000 Received: from [192.165.210.4] (helo=[192.168.225.223]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UG8M6-0000vX-1i; Thu, 14 Mar 2013 13:38:02 +0000 Message-ID: <5141D2B6.9070807@stimpsonfamily.co.uk> Date: Thu, 14 Mar 2013 13:37:58 +0000 From: Paul Stimpson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ian Campbell References: <513E2B4F.7030600@stimpsonfamily.co.uk> <1363090305.29599.14.camel@zakaz.uk.xensource.com> In-Reply-To: <1363090305.29599.14.camel@zakaz.uk.xensource.com> X-Mailcore-Auth: 8324857 X-Mailcore-Domain: 844183 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Windows QEMU resolution X-BeenThere: xen-users@lists.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 12/03/13 12:11, Ian Campbell wrote: > You need to be looking at the options relating to the emulated VGA > device and video ram etc in xl.cfg(5). Ian. Thank you. You are correct that, in my inexperience, I had insufficiently studied and understood the documentation. I managed to get the VGA correctly working using Gabor's method. I now have a different difficulty. I'm running HVM Windows Server 2008 R2. I turned the resolution up in steps and ti was fine until I hit 1600x1050. As soon as I selected that, the vnc session terminated (using gvncviewer) and I can't re-establish it (it flashes up, reports the 1600x1050 resolution in the console I launched it from then says that the session has terminated and closes). I tried increasing the videoram line but this didn't help. I then commented out both the stdvga and videoram lines and was able to access Windows in 1024x768 as before. I turned the screen rez down to 800x600, put the stdvga and videoram lines back and restarted. Windows (thinking it was being helpful) put the resolution back to 1600x1050 and it failed again. Is there any way I can stop the VNC console dying at high resolutions or stop Windows from restoring the old, non-working resolution when I put the virtual cirrus card back please? Thanks, Paul. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 13:48:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 13:48: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 1UG8VB-0007bg-VO; Thu, 14 Mar 2013 13:47:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG8VA-0007bZ-FQ for xen-users@lists.xen.org; Thu, 14 Mar 2013 13:47:24 +0000 Received: from [85.158.139.83:27595] by server-9.bemta-5.messagelabs.com id 05/CD-08547-BE4D1415; Thu, 14 Mar 2013 13:47:23 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-14.tower-182.messagelabs.com!1363268843!23208807!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32361 invoked from network); 14 Mar 2013 13:47:23 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-14.tower-182.messagelabs.com with SMTP; 14 Mar 2013 13:47:23 -0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:59420) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UG8V8-00070J-sh (Exim 4.72) for xen-users@lists.xen.org (return-path ); Thu, 14 Mar 2013 13:47:23 +0000 Message-ID: <5141D4D4.8050603@cam.ac.uk> Date: Thu, 14 Mar 2013 13:47:00 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <513F5C1E.7010407@cam.ac.uk> <5140C26B.7090409@cam.ac.uk> In-Reply-To: Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 can report some more success and a little bit of failure. I added the second GPU and was able to simultaneously do primary passthrough of the two cards to two different domUs. I have however noticed a problem with passthrough that seems to exist regardless of how many GPUs I have plugged in. Whenever I shutdown a domU, which has a passed through GPU, and then start it up again my entire dom0 locks out and I have to hard reset the whole box. To get around this I instead have to shutdown all of my domUs and then restart the whole box before starting them up again. For me this is not a massive issue as the end game is to have the vms running all the time without need for regular restarting but it is an issue none the less. I'm going to take a break from this for now but will come back to it in a couple of weeks, I just thought I'd let people know my experiences. Thanks again for everybody's help. Matt On 13/03/2013 21:06, Matthias wrote: > Congrats! > > But so you don't get overly excited, dual vga passthrough sems to be > broken at the moment. Been down that road (Thread: > http://xen.1045712.n5.nabble.com/dual-vga-passthrough-issue-in-xen-unstable-td5714613.html), > posted to xen-user and xen-devel, but never got a response. > > Would be interesting to see if it works for you. > > Oh, and just for my record-keeping: Have you used my patch or the > original one from Greg? > > 2013/3/13 Matthew Dean : >> Just to let everyone know that patch worked like gold for me. My HD 7970 is >> now being passed through as the primary adapter with driver version 13.1 and >> up to now all seems to be working. Will run further tests over the next few >> days to make sure it stays that way and I'll probably test secondary >> passthrough also. Once that's done I need to put the second card back in >> and have a bit of a play but this is by far the furthest I've been in the >> last 2 weeks. Thanks to everybody for your advice. >> >> Matt >> >> >> On 12/03/2013 19:42, Matthias wrote: >>> Hi, >>> >>> to fix the atikmeq.sys bug, you can try two things: >>> >>> 1) Use upstream qemu. For this, just add: >>> >>> device_model_version = 'qemu-xen' >>> device_model_override = '/usr/lib/xen/bin/qemu-system-i386' >>> >>> to your domU config file. Note that there is currently a bug that the >>> domU won't start when duing vga passthrough with more then 4GB memory >>> assigned, so better use some less.. >>> >>> 2) If you want to have more then 4GB memory, you can patch the >>> traditional qemu. This is a bit more complicated cause the qemu stuff >>> is download through the build and can't be patched right away. Also >>> stopping in mid build, patching and continuing at least for me caused >>> some problems, so doing a full build, patch, cleanup and build again >>> is the safer route: >>> >>> git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging >>> cd xen-unstable-staging >>> ./configure --disable-stubdom >>> make -j12 world >>> git apply --check /path/to/xen-unstable-atipassthrough.patch >>> git apply /path/to/xen-unstable-atipassthrough.patch >>> make -j12 clean >>> make -j12 world >>> Now do your usual install.. some use the standard, i prefer creating a >>> debball.. >>> >>> Some Notes: >>> - I use the staging branch from xen-unstable, but this is not exactly >>> necessary for the patch, you can use master just as fine >>> - the j12 is for multithreading and you should use double your core >>> number.. since i got 6 cpu cores, it's 12 for me.. >>> - the patch i have attached is originally from Greg >>> (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), >>> so credit goes to him, i only cleaned it up for xen-unstable. Also, >>> the patch itself was for providing primary passthrough with ATI cards, >>> but i found it fixing my ati 0x116 bluescreen.. >>> - due to an insufficiancy in the patch, stubdom would not build >>> correctly, so you have to disable it >>> >>> Please report back if the patch fixes your bluescreen for more >>> argumentation to bring this patch upstream.. :) (@Greg: that's why i >>> cc'ed you. hope you don't mind the noise) >>> >>> Hope it helps! >> >> >> _______________________________________________ >> 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 Mar 14 13:48:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 13:48: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 1UG8VB-0007bg-VO; Thu, 14 Mar 2013 13:47:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG8VA-0007bZ-FQ for xen-users@lists.xen.org; Thu, 14 Mar 2013 13:47:24 +0000 Received: from [85.158.139.83:27595] by server-9.bemta-5.messagelabs.com id 05/CD-08547-BE4D1415; Thu, 14 Mar 2013 13:47:23 +0000 X-Env-Sender: mcd40@cam.ac.uk X-Msg-Ref: server-14.tower-182.messagelabs.com!1363268843!23208807!1 X-Originating-IP: [131.111.8.150] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMxLjExMS44LjE1MCA9PiAxNDk0MDU=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32361 invoked from network); 14 Mar 2013 13:47:23 -0000 Received: from ppsw-50.csi.cam.ac.uk (HELO ppsw-50.csi.cam.ac.uk) (131.111.8.150) by server-14.tower-182.messagelabs.com with SMTP; 14 Mar 2013 13:47:23 -0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from mcd40.sp.phy.cam.ac.uk ([131.111.73.213]:59420) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:465) with esmtpsa (PLAIN:mcd40) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) id 1UG8V8-00070J-sh (Exim 4.72) for xen-users@lists.xen.org (return-path ); Thu, 14 Mar 2013 13:47:23 +0000 Message-ID: <5141D4D4.8050603@cam.ac.uk> Date: Thu, 14 Mar 2013 13:47:00 +0000 From: Matthew Dean User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Thunderbird/20.0 MIME-Version: 1.0 To: "xen-users@lists.xen.org" References: <513F5C1E.7010407@cam.ac.uk> <5140C26B.7090409@cam.ac.uk> In-Reply-To: Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 can report some more success and a little bit of failure. I added the second GPU and was able to simultaneously do primary passthrough of the two cards to two different domUs. I have however noticed a problem with passthrough that seems to exist regardless of how many GPUs I have plugged in. Whenever I shutdown a domU, which has a passed through GPU, and then start it up again my entire dom0 locks out and I have to hard reset the whole box. To get around this I instead have to shutdown all of my domUs and then restart the whole box before starting them up again. For me this is not a massive issue as the end game is to have the vms running all the time without need for regular restarting but it is an issue none the less. I'm going to take a break from this for now but will come back to it in a couple of weeks, I just thought I'd let people know my experiences. Thanks again for everybody's help. Matt On 13/03/2013 21:06, Matthias wrote: > Congrats! > > But so you don't get overly excited, dual vga passthrough sems to be > broken at the moment. Been down that road (Thread: > http://xen.1045712.n5.nabble.com/dual-vga-passthrough-issue-in-xen-unstable-td5714613.html), > posted to xen-user and xen-devel, but never got a response. > > Would be interesting to see if it works for you. > > Oh, and just for my record-keeping: Have you used my patch or the > original one from Greg? > > 2013/3/13 Matthew Dean : >> Just to let everyone know that patch worked like gold for me. My HD 7970 is >> now being passed through as the primary adapter with driver version 13.1 and >> up to now all seems to be working. Will run further tests over the next few >> days to make sure it stays that way and I'll probably test secondary >> passthrough also. Once that's done I need to put the second card back in >> and have a bit of a play but this is by far the furthest I've been in the >> last 2 weeks. Thanks to everybody for your advice. >> >> Matt >> >> >> On 12/03/2013 19:42, Matthias wrote: >>> Hi, >>> >>> to fix the atikmeq.sys bug, you can try two things: >>> >>> 1) Use upstream qemu. For this, just add: >>> >>> device_model_version = 'qemu-xen' >>> device_model_override = '/usr/lib/xen/bin/qemu-system-i386' >>> >>> to your domU config file. Note that there is currently a bug that the >>> domU won't start when duing vga passthrough with more then 4GB memory >>> assigned, so better use some less.. >>> >>> 2) If you want to have more then 4GB memory, you can patch the >>> traditional qemu. This is a bit more complicated cause the qemu stuff >>> is download through the build and can't be patched right away. Also >>> stopping in mid build, patching and continuing at least for me caused >>> some problems, so doing a full build, patch, cleanup and build again >>> is the safer route: >>> >>> git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging >>> cd xen-unstable-staging >>> ./configure --disable-stubdom >>> make -j12 world >>> git apply --check /path/to/xen-unstable-atipassthrough.patch >>> git apply /path/to/xen-unstable-atipassthrough.patch >>> make -j12 clean >>> make -j12 world >>> Now do your usual install.. some use the standard, i prefer creating a >>> debball.. >>> >>> Some Notes: >>> - I use the staging branch from xen-unstable, but this is not exactly >>> necessary for the patch, you can use master just as fine >>> - the j12 is for multithreading and you should use double your core >>> number.. since i got 6 cpu cores, it's 12 for me.. >>> - the patch i have attached is originally from Greg >>> (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), >>> so credit goes to him, i only cleaned it up for xen-unstable. Also, >>> the patch itself was for providing primary passthrough with ATI cards, >>> but i found it fixing my ati 0x116 bluescreen.. >>> - due to an insufficiancy in the patch, stubdom would not build >>> correctly, so you have to disable it >>> >>> Please report back if the patch fixes your bluescreen for more >>> argumentation to bring this patch upstream.. :) (@Greg: that's why i >>> cc'ed you. hope you don't mind the noise) >>> >>> Hope it helps! >> >> >> _______________________________________________ >> 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 Mar 14 15:09:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 15:09: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 1UG9lS-0000yH-81; Thu, 14 Mar 2013 15:08:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG9lQ-0000yC-00 for xen-users@lists.xen.org; Thu, 14 Mar 2013 15:08:16 +0000 Received: from [85.158.138.51:14657] by server-12.bemta-3.messagelabs.com id 23/80-01357-FD7E1415; Thu, 14 Mar 2013 15:08:15 +0000 X-Env-Sender: unixwind@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1363273692!8945695!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25112 invoked from network); 14 Mar 2013 15:08:14 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 15:08:14 -0000 Received: by mail-ie0-f175.google.com with SMTP id c12so3150772ieb.34 for ; Thu, 14 Mar 2013 08:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oEoyXTbBh+6wtpcpuzcmVG/1YOO8cSjvPXzd48WunvY=; b=aPdkEjKBhZYoxEtxGzMMjVzWsUGJNx1B0GVsBZkBvJllnx8xy5ArIKxfm/wXDD+/Bx sIrOFcazCv0eZ4I98ifSk3MlJuz0GYpxbnfBXMaZnb3rCgV8GNWbRa3dBGKI6Wdq9puW 2/Zqa08pRcWBmu+SuuFozDctxv94zEn0Dn/9SmAK/D35Nwp34QUSnXKyOsKwJ0V5S3Di h+leCpPFFCtzYvPuh3PMkl2IE54togc6Cq5GRYLNnzmvw5fGceZ1v9Guf2ogoqrXPgIU DHeOlP4i6l+RcTam0/v6vPqC31yINrpXfmvJLmxaKXBMjlfd+24SuADcBwzXZUyv3jE8 VGbg== MIME-Version: 1.0 X-Received: by 10.50.184.132 with SMTP id eu4mr20403881igc.19.1363273691916; Thu, 14 Mar 2013 08:08:11 -0700 (PDT) Received: by 10.64.39.163 with HTTP; Thu, 14 Mar 2013 08:08:11 -0700 (PDT) In-Reply-To: <5141B772.1060900@citrix.com> References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> <5141AF78.3050005@citrix.com> <5141B772.1060900@citrix.com> Date: Thu, 14 Mar 2013 23:08:11 +0800 Message-ID: From: Felix Feng To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Cc: xen-users , Ian Campbell Subject: [Xen-users] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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="===============5398978804017713281==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5398978804017713281== Content-Type: multipart/alternative; boundary=14dae9340ebd237ec504d7e3e4c8 --14dae9340ebd237ec504d7e3e4c8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roger, On Thursday, March 14, 2013, Roger Pau Monn=E9 wrote= : > On 14/03/13 12:35, Felix Feng wrote: >> Hi Roger, >> >> I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel packages >> for xen. Then I installed kernel-xen, kernel-xen-firmware, >> kernel-xen-devel, kernel-extra-devel, kernel-utility, >> kernel-utility-devel packages for Dom0 kernel. After rebooting, I hit >> the problem. I compiled xen and Dom0 kernel on CentOS 5.9 running in >> Virtual Box. Is there anything I missed? Thanks. > > I don't understand this, why did you install all the Xen packages if you > ended up compiling it yourself? Sorry for my confusing words. I mean I built these packages by using *.src.rpm, then I installed them. I'm not sure whether or not it is recommended. > > Did you mean that you compiled the Xen kernel from a different version > and tried to use it with the tools from the packages your distro > provides? Because that is certainly not going to work if they are from > different versions. > > Anyway, I would recommend using the packages your distro provides, and > you seem to be missing init scripts at least, so I would check which > package provides those init scripts. > > --14dae9340ebd237ec504d7e3e4c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roger,

On Thursday, March 14, 2013, Roger Pau Monn=E9 <roger.pau@citrix.com> wrote:
>= ; On 14/03/13 12:35, Felix Feng wrote:
>> Hi Roger,
>> >> I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel pac= kages
>> for xen. Then I installed kernel-xen, kernel-xen-firmware= ,
>> kernel-xen-devel, kernel-extra-devel, kernel-utility,
>> kernel-utility-devel packages for Dom0 kernel. After rebooting, I = hit
>> the problem. I compiled xen and Dom0 kernel on CentOS 5.9 r= unning in
>> Virtual Box. Is there anything I missed? Thanks.
>
> I don't understand this, why did you install all the Xen p= ackages if you
> ended up compiling it yourself?
Sorry for my conf= using words. I mean I built these packages by using *.src.rpm, then I insta= lled them. I'm not sure whether or not it is recommended.

>
> Did you mean that you compiled the Xen kernel from a diffe= rent version
> and tried to use it with the tools from the packages y= our distro
> provides? Because that is certainly not going to work if= they are from
> different versions.
>
> Anyway, I would recommend using th= e packages your distro provides, and
> you seem to be missing init sc= ripts at least, so I would check which
> package provides those init = scripts.
>
> --14dae9340ebd237ec504d7e3e4c8-- --===============5398978804017713281== 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 --===============5398978804017713281==-- From xen-users-bounces@lists.xen.org Thu Mar 14 15:09:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 15:09: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 1UG9lS-0000yH-81; Thu, 14 Mar 2013 15:08:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UG9lQ-0000yC-00 for xen-users@lists.xen.org; Thu, 14 Mar 2013 15:08:16 +0000 Received: from [85.158.138.51:14657] by server-12.bemta-3.messagelabs.com id 23/80-01357-FD7E1415; Thu, 14 Mar 2013 15:08:15 +0000 X-Env-Sender: unixwind@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1363273692!8945695!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25112 invoked from network); 14 Mar 2013 15:08:14 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 15:08:14 -0000 Received: by mail-ie0-f175.google.com with SMTP id c12so3150772ieb.34 for ; Thu, 14 Mar 2013 08:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oEoyXTbBh+6wtpcpuzcmVG/1YOO8cSjvPXzd48WunvY=; b=aPdkEjKBhZYoxEtxGzMMjVzWsUGJNx1B0GVsBZkBvJllnx8xy5ArIKxfm/wXDD+/Bx sIrOFcazCv0eZ4I98ifSk3MlJuz0GYpxbnfBXMaZnb3rCgV8GNWbRa3dBGKI6Wdq9puW 2/Zqa08pRcWBmu+SuuFozDctxv94zEn0Dn/9SmAK/D35Nwp34QUSnXKyOsKwJ0V5S3Di h+leCpPFFCtzYvPuh3PMkl2IE54togc6Cq5GRYLNnzmvw5fGceZ1v9Guf2ogoqrXPgIU DHeOlP4i6l+RcTam0/v6vPqC31yINrpXfmvJLmxaKXBMjlfd+24SuADcBwzXZUyv3jE8 VGbg== MIME-Version: 1.0 X-Received: by 10.50.184.132 with SMTP id eu4mr20403881igc.19.1363273691916; Thu, 14 Mar 2013 08:08:11 -0700 (PDT) Received: by 10.64.39.163 with HTTP; Thu, 14 Mar 2013 08:08:11 -0700 (PDT) In-Reply-To: <5141B772.1060900@citrix.com> References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> <5141AF78.3050005@citrix.com> <5141B772.1060900@citrix.com> Date: Thu, 14 Mar 2013 23:08:11 +0800 Message-ID: From: Felix Feng To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Cc: xen-users , Ian Campbell Subject: [Xen-users] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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="===============5398978804017713281==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5398978804017713281== Content-Type: multipart/alternative; boundary=14dae9340ebd237ec504d7e3e4c8 --14dae9340ebd237ec504d7e3e4c8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roger, On Thursday, March 14, 2013, Roger Pau Monn=E9 wrote= : > On 14/03/13 12:35, Felix Feng wrote: >> Hi Roger, >> >> I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel packages >> for xen. Then I installed kernel-xen, kernel-xen-firmware, >> kernel-xen-devel, kernel-extra-devel, kernel-utility, >> kernel-utility-devel packages for Dom0 kernel. After rebooting, I hit >> the problem. I compiled xen and Dom0 kernel on CentOS 5.9 running in >> Virtual Box. Is there anything I missed? Thanks. > > I don't understand this, why did you install all the Xen packages if you > ended up compiling it yourself? Sorry for my confusing words. I mean I built these packages by using *.src.rpm, then I installed them. I'm not sure whether or not it is recommended. > > Did you mean that you compiled the Xen kernel from a different version > and tried to use it with the tools from the packages your distro > provides? Because that is certainly not going to work if they are from > different versions. > > Anyway, I would recommend using the packages your distro provides, and > you seem to be missing init scripts at least, so I would check which > package provides those init scripts. > > --14dae9340ebd237ec504d7e3e4c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roger,

On Thursday, March 14, 2013, Roger Pau Monn=E9 <roger.pau@citrix.com> wrote:
>= ; On 14/03/13 12:35, Felix Feng wrote:
>> Hi Roger,
>> >> I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel pac= kages
>> for xen. Then I installed kernel-xen, kernel-xen-firmware= ,
>> kernel-xen-devel, kernel-extra-devel, kernel-utility,
>> kernel-utility-devel packages for Dom0 kernel. After rebooting, I = hit
>> the problem. I compiled xen and Dom0 kernel on CentOS 5.9 r= unning in
>> Virtual Box. Is there anything I missed? Thanks.
>
> I don't understand this, why did you install all the Xen p= ackages if you
> ended up compiling it yourself?
Sorry for my conf= using words. I mean I built these packages by using *.src.rpm, then I insta= lled them. I'm not sure whether or not it is recommended.

>
> Did you mean that you compiled the Xen kernel from a diffe= rent version
> and tried to use it with the tools from the packages y= our distro
> provides? Because that is certainly not going to work if= they are from
> different versions.
>
> Anyway, I would recommend using th= e packages your distro provides, and
> you seem to be missing init sc= ripts at least, so I would check which
> package provides those init = scripts.
>
> --14dae9340ebd237ec504d7e3e4c8-- --===============5398978804017713281== 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 --===============5398978804017713281==-- From xen-users-bounces@lists.xen.org Thu Mar 14 18:04:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 18:04: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 1UGCUE-0005oR-9A; Thu, 14 Mar 2013 18:02:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCUC-0005oM-Lq for xen-users@lists.xen.org; Thu, 14 Mar 2013 18:02:41 +0000 Received: from [85.158.143.99:52682] by server-3.bemta-4.messagelabs.com id EA/9C-02186-FB012415; Thu, 14 Mar 2013 18:02:39 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1363284158!21803847!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4853 invoked from network); 14 Mar 2013 18:02:39 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 18:02:39 -0000 Received: by mail-la0-f43.google.com with SMTP id ek20so2839731lab.30 for ; Thu, 14 Mar 2013 11:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=x0W2j6BJeaxhEVtuuxlsa7Us/Crle8n1S71c7BeyJew=; b=YrIhk4iXExfW5DitFSCU85R9BMIixqiNYH4a7X9uqbsMUIZSNC8SqOwPdvANz2hK/w k3s3JFy73v9yoQgzG6RAXpRCh0DCC4CKa3+eo0OhGy3lW68NpxqYt4NIljhPX8RzM5WM P/I7ez6/+rHaPO05LpQxTuzscSYeIR1/d4oxKrJq8Cio3ygUXcvs8Xj3c/mTr3ptdxo/ FfpsPS892V3K4ccsjidOF+JjzRlqhpdOSnQ0I5Acnfg7hKl237wg5IGT2unc6UKU7hF5 qlFev2RmpBun1e3E2BeolFRP66p72JOXyqSN6flDQXZrvxOwEsu5XhQv1woifvSPOfta i4SA== X-Received: by 10.112.29.1 with SMTP id f1mr1517658lbh.30.1363284158280; Thu, 14 Mar 2013 11:02:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.132 with HTTP; Thu, 14 Mar 2013 11:02:18 -0700 (PDT) In-Reply-To: <5141D4D4.8050603@cam.ac.uk> References: <513F5C1E.7010407@cam.ac.uk> <5140C26B.7090409@cam.ac.uk> <5141D4D4.8050603@cam.ac.uk> From: Matthias Date: Thu, 14 Mar 2013 19:02:18 +0100 Message-ID: To: Matthew Dean Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 Yes, this is exactly the behaviour I'm seeing.. dual vga passthrough works fine, but when hiding two vga's from dom0 and doing a shutdown in the passthrough-domU, the dom0 breaks down and i have to reset the whole server.. When only hiding one VGA and leaving the second to the dom0, this does not happen.. Would you be so kind and post a "Me too"-post to the thread i linked there and cc xen-user and xen-devel? It's just to raise some awareness.. 2013/3/14 Matthew Dean : > I can report some more success and a little bit of failure. I added the > second GPU and was able to simultaneously do primary passthrough of the two > cards to two different domUs. I have however noticed a problem with > passthrough that seems to exist regardless of how many GPUs I have plugged > in. Whenever I shutdown a domU, which has a passed through GPU, and then > start it up again my entire dom0 locks out and I have to hard reset the > whole box. To get around this I instead have to shutdown all of my domUs > and then restart the whole box before starting them up again. For me this > is not a massive issue as the end game is to have the vms running all the > time without need for regular restarting but it is an issue none the less. > I'm going to take a break from this for now but will come back to it in a > couple of weeks, I just thought I'd let people know my experiences. Thanks > again for everybody's help. > > Matt > > > On 13/03/2013 21:06, Matthias wrote: >> >> Congrats! >> >> But so you don't get overly excited, dual vga passthrough sems to be >> broken at the moment. Been down that road (Thread: >> >> http://xen.1045712.n5.nabble.com/dual-vga-passthrough-issue-in-xen-unstable-td5714613.html), >> posted to xen-user and xen-devel, but never got a response. >> >> Would be interesting to see if it works for you. >> >> Oh, and just for my record-keeping: Have you used my patch or the >> original one from Greg? >> >> 2013/3/13 Matthew Dean : >>> >>> Just to let everyone know that patch worked like gold for me. My HD 7970 >>> is >>> now being passed through as the primary adapter with driver version 13.1 >>> and >>> up to now all seems to be working. Will run further tests over the next >>> few >>> days to make sure it stays that way and I'll probably test secondary >>> passthrough also. Once that's done I need to put the second card back in >>> and have a bit of a play but this is by far the furthest I've been in the >>> last 2 weeks. Thanks to everybody for your advice. >>> >>> Matt >>> >>> >>> On 12/03/2013 19:42, Matthias wrote: >>>> >>>> Hi, >>>> >>>> to fix the atikmeq.sys bug, you can try two things: >>>> >>>> 1) Use upstream qemu. For this, just add: >>>> >>>> device_model_version = 'qemu-xen' >>>> device_model_override = '/usr/lib/xen/bin/qemu-system-i386' >>>> >>>> to your domU config file. Note that there is currently a bug that the >>>> domU won't start when duing vga passthrough with more then 4GB memory >>>> assigned, so better use some less.. >>>> >>>> 2) If you want to have more then 4GB memory, you can patch the >>>> traditional qemu. This is a bit more complicated cause the qemu stuff >>>> is download through the build and can't be patched right away. Also >>>> stopping in mid build, patching and continuing at least for me caused >>>> some problems, so doing a full build, patch, cleanup and build again >>>> is the safer route: >>>> >>>> git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging >>>> cd xen-unstable-staging >>>> ./configure --disable-stubdom >>>> make -j12 world >>>> git apply --check /path/to/xen-unstable-atipassthrough.patch >>>> git apply /path/to/xen-unstable-atipassthrough.patch >>>> make -j12 clean >>>> make -j12 world >>>> Now do your usual install.. some use the standard, i prefer creating a >>>> debball.. >>>> >>>> Some Notes: >>>> - I use the staging branch from xen-unstable, but this is not exactly >>>> necessary for the patch, you can use master just as fine >>>> - the j12 is for multithreading and you should use double your core >>>> number.. since i got 6 cpu cores, it's 12 for me.. >>>> - the patch i have attached is originally from Greg >>>> (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), >>>> so credit goes to him, i only cleaned it up for xen-unstable. Also, >>>> the patch itself was for providing primary passthrough with ATI cards, >>>> but i found it fixing my ati 0x116 bluescreen.. >>>> - due to an insufficiancy in the patch, stubdom would not build >>>> correctly, so you have to disable it >>>> >>>> Please report back if the patch fixes your bluescreen for more >>>> argumentation to bring this patch upstream.. :) (@Greg: that's why i >>>> cc'ed you. hope you don't mind the noise) >>>> >>>> Hope it helps! >>> >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 18:04:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 18:04: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 1UGCUE-0005oR-9A; Thu, 14 Mar 2013 18:02:42 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCUC-0005oM-Lq for xen-users@lists.xen.org; Thu, 14 Mar 2013 18:02:41 +0000 Received: from [85.158.143.99:52682] by server-3.bemta-4.messagelabs.com id EA/9C-02186-FB012415; Thu, 14 Mar 2013 18:02:39 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1363284158!21803847!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4853 invoked from network); 14 Mar 2013 18:02:39 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 18:02:39 -0000 Received: by mail-la0-f43.google.com with SMTP id ek20so2839731lab.30 for ; Thu, 14 Mar 2013 11:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=x0W2j6BJeaxhEVtuuxlsa7Us/Crle8n1S71c7BeyJew=; b=YrIhk4iXExfW5DitFSCU85R9BMIixqiNYH4a7X9uqbsMUIZSNC8SqOwPdvANz2hK/w k3s3JFy73v9yoQgzG6RAXpRCh0DCC4CKa3+eo0OhGy3lW68NpxqYt4NIljhPX8RzM5WM P/I7ez6/+rHaPO05LpQxTuzscSYeIR1/d4oxKrJq8Cio3ygUXcvs8Xj3c/mTr3ptdxo/ FfpsPS892V3K4ccsjidOF+JjzRlqhpdOSnQ0I5Acnfg7hKl237wg5IGT2unc6UKU7hF5 qlFev2RmpBun1e3E2BeolFRP66p72JOXyqSN6flDQXZrvxOwEsu5XhQv1woifvSPOfta i4SA== X-Received: by 10.112.29.1 with SMTP id f1mr1517658lbh.30.1363284158280; Thu, 14 Mar 2013 11:02:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.132 with HTTP; Thu, 14 Mar 2013 11:02:18 -0700 (PDT) In-Reply-To: <5141D4D4.8050603@cam.ac.uk> References: <513F5C1E.7010407@cam.ac.uk> <5140C26B.7090409@cam.ac.uk> <5141D4D4.8050603@cam.ac.uk> From: Matthias Date: Thu, 14 Mar 2013 19:02:18 +0100 Message-ID: To: Matthew Dean Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] GPU passthrough with xen 4.2.1 on ubuntu 12.10 X-BeenThere: xen-users@lists.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 Yes, this is exactly the behaviour I'm seeing.. dual vga passthrough works fine, but when hiding two vga's from dom0 and doing a shutdown in the passthrough-domU, the dom0 breaks down and i have to reset the whole server.. When only hiding one VGA and leaving the second to the dom0, this does not happen.. Would you be so kind and post a "Me too"-post to the thread i linked there and cc xen-user and xen-devel? It's just to raise some awareness.. 2013/3/14 Matthew Dean : > I can report some more success and a little bit of failure. I added the > second GPU and was able to simultaneously do primary passthrough of the two > cards to two different domUs. I have however noticed a problem with > passthrough that seems to exist regardless of how many GPUs I have plugged > in. Whenever I shutdown a domU, which has a passed through GPU, and then > start it up again my entire dom0 locks out and I have to hard reset the > whole box. To get around this I instead have to shutdown all of my domUs > and then restart the whole box before starting them up again. For me this > is not a massive issue as the end game is to have the vms running all the > time without need for regular restarting but it is an issue none the less. > I'm going to take a break from this for now but will come back to it in a > couple of weeks, I just thought I'd let people know my experiences. Thanks > again for everybody's help. > > Matt > > > On 13/03/2013 21:06, Matthias wrote: >> >> Congrats! >> >> But so you don't get overly excited, dual vga passthrough sems to be >> broken at the moment. Been down that road (Thread: >> >> http://xen.1045712.n5.nabble.com/dual-vga-passthrough-issue-in-xen-unstable-td5714613.html), >> posted to xen-user and xen-devel, but never got a response. >> >> Would be interesting to see if it works for you. >> >> Oh, and just for my record-keeping: Have you used my patch or the >> original one from Greg? >> >> 2013/3/13 Matthew Dean : >>> >>> Just to let everyone know that patch worked like gold for me. My HD 7970 >>> is >>> now being passed through as the primary adapter with driver version 13.1 >>> and >>> up to now all seems to be working. Will run further tests over the next >>> few >>> days to make sure it stays that way and I'll probably test secondary >>> passthrough also. Once that's done I need to put the second card back in >>> and have a bit of a play but this is by far the furthest I've been in the >>> last 2 weeks. Thanks to everybody for your advice. >>> >>> Matt >>> >>> >>> On 12/03/2013 19:42, Matthias wrote: >>>> >>>> Hi, >>>> >>>> to fix the atikmeq.sys bug, you can try two things: >>>> >>>> 1) Use upstream qemu. For this, just add: >>>> >>>> device_model_version = 'qemu-xen' >>>> device_model_override = '/usr/lib/xen/bin/qemu-system-i386' >>>> >>>> to your domU config file. Note that there is currently a bug that the >>>> domU won't start when duing vga passthrough with more then 4GB memory >>>> assigned, so better use some less.. >>>> >>>> 2) If you want to have more then 4GB memory, you can patch the >>>> traditional qemu. This is a bit more complicated cause the qemu stuff >>>> is download through the build and can't be patched right away. Also >>>> stopping in mid build, patching and continuing at least for me caused >>>> some problems, so doing a full build, patch, cleanup and build again >>>> is the safer route: >>>> >>>> git clone -b staging git://xenbits.xen.org/xen.git xen-unstable-staging >>>> cd xen-unstable-staging >>>> ./configure --disable-stubdom >>>> make -j12 world >>>> git apply --check /path/to/xen-unstable-atipassthrough.patch >>>> git apply /path/to/xen-unstable-atipassthrough.patch >>>> make -j12 clean >>>> make -j12 world >>>> Now do your usual install.. some use the standard, i prefer creating a >>>> debball.. >>>> >>>> Some Notes: >>>> - I use the staging branch from xen-unstable, but this is not exactly >>>> necessary for the patch, you can use master just as fine >>>> - the j12 is for multithreading and you should use double your core >>>> number.. since i got 6 cpu cores, it's 12 for me.. >>>> - the patch i have attached is originally from Greg >>>> (http://lists.xen.org/archives/html/xen-devel/2012-12/msg00009.html), >>>> so credit goes to him, i only cleaned it up for xen-unstable. Also, >>>> the patch itself was for providing primary passthrough with ATI cards, >>>> but i found it fixing my ati 0x116 bluescreen.. >>>> - due to an insufficiancy in the patch, stubdom would not build >>>> correctly, so you have to disable it >>>> >>>> Please report back if the patch fixes your bluescreen for more >>>> argumentation to bring this patch upstream.. :) (@Greg: that's why i >>>> cc'ed you. hope you don't mind the noise) >>>> >>>> Hope it helps! >>> >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 18:26:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 18:26: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 1UGCpm-0006RY-Cs; Thu, 14 Mar 2013 18:24:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCpk-0006RK-V6 for xen-users@lists.xen.org; Thu, 14 Mar 2013 18:24:57 +0000 Received: from [85.158.137.99:54910] by server-3.bemta-3.messagelabs.com id B8/D0-26934-3F512415; Thu, 14 Mar 2013 18:24:51 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1363285490!12344694!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4615 invoked from network); 14 Mar 2013 18:24:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 18:24:51 -0000 X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="2522870" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Mar 2013 18:24:51 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Thu, 14 Mar 2013 18:24:51 +0000 Message-ID: <514215F1.7080009@citrix.com> Date: Thu, 14 Mar 2013 19:24:49 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Felix Feng References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> <5141AF78.3050005@citrix.com> <5141B772.1060900@citrix.com> In-Reply-To: Cc: xen-users , Ian Campbell Subject: Re: [Xen-users] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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 On 14/03/13 16:08, Felix Feng wrote: > Hi Roger, > = > On Thursday, March 14, 2013, Roger Pau Monn=E9 > wrote: >> On 14/03/13 12:35, Felix Feng wrote: >>> Hi Roger, >>> >>> I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel packages >>> for xen. Then I installed kernel-xen, kernel-xen-firmware, >>> kernel-xen-devel, kernel-extra-devel, kernel-utility, >>> kernel-utility-devel packages for Dom0 kernel. After rebooting, I hit >>> the problem. I compiled xen and Dom0 kernel on CentOS 5.9 running in >>> Virtual Box. Is there anything I missed? Thanks. >> >> I don't understand this, why did you install all the Xen packages if you >> ended up compiling it yourself? > Sorry for my confusing words. I mean I built these packages by using > *.src.rpm, then I installed them. I'm not sure whether or not it is > recommended. I don't build packages myself, because AFAIK the result is exactly the same as the prebuild ones that your distro supplies (unless you applied some local patches). Either way, you have to check which package provides the init scripts, and install it. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 18:26:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 18:26: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 1UGCpm-0006RY-Cs; Thu, 14 Mar 2013 18:24:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGCpk-0006RK-V6 for xen-users@lists.xen.org; Thu, 14 Mar 2013 18:24:57 +0000 Received: from [85.158.137.99:54910] by server-3.bemta-3.messagelabs.com id B8/D0-26934-3F512415; Thu, 14 Mar 2013 18:24:51 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1363285490!12344694!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4615 invoked from network); 14 Mar 2013 18:24:51 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 18:24:51 -0000 X-IronPort-AV: E=Sophos;i="4.84,846,1355097600"; d="scan'208";a="2522870" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 14 Mar 2013 18:24:51 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Thu, 14 Mar 2013 18:24:51 +0000 Message-ID: <514215F1.7080009@citrix.com> Date: Thu, 14 Mar 2013 19:24:49 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Felix Feng References: <1363258728.32410.241.camel@zakaz.uk.xensource.com> <5141AF78.3050005@citrix.com> <5141B772.1060900@citrix.com> In-Reply-To: Cc: xen-users , Ian Campbell Subject: Re: [Xen-users] [xen-devel]unable to run xenstored X-BeenThere: xen-users@lists.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 On 14/03/13 16:08, Felix Feng wrote: > Hi Roger, > = > On Thursday, March 14, 2013, Roger Pau Monn=E9 > wrote: >> On 14/03/13 12:35, Felix Feng wrote: >>> Hi Roger, >>> >>> I installed xen-hypervisor, xen-firmware, xen-tools, xen-devel packages >>> for xen. Then I installed kernel-xen, kernel-xen-firmware, >>> kernel-xen-devel, kernel-extra-devel, kernel-utility, >>> kernel-utility-devel packages for Dom0 kernel. After rebooting, I hit >>> the problem. I compiled xen and Dom0 kernel on CentOS 5.9 running in >>> Virtual Box. Is there anything I missed? Thanks. >> >> I don't understand this, why did you install all the Xen packages if you >> ended up compiling it yourself? > Sorry for my confusing words. I mean I built these packages by using > *.src.rpm, then I installed them. I'm not sure whether or not it is > recommended. I don't build packages myself, because AFAIK the result is exactly the same as the prebuild ones that your distro supplies (unless you applied some local patches). Either way, you have to check which package provides the init scripts, and install it. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 19:27:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 19:27: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 1UGDnT-0008NG-Px; Thu, 14 Mar 2013 19:26:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDnR-0008N9-UT for xen-users@lists.xen.org; Thu, 14 Mar 2013 19:26:38 +0000 Received: from [85.158.139.211:10021] by server-6.bemta-5.messagelabs.com id 43/B4-21466-D6422415; Thu, 14 Mar 2013 19:26:37 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1363289195!18368275!1 X-Originating-IP: [209.85.210.175] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 970 invoked from network); 14 Mar 2013 19:26:36 -0000 Received: from mail-ia0-f175.google.com (HELO mail-ia0-f175.google.com) (209.85.210.175) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 19:26:36 -0000 Received: by mail-ia0-f175.google.com with SMTP id y26so190476iab.20 for ; Thu, 14 Mar 2013 12:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=5IuBBiob7/bkOXG2f3f3w41SNUNy6OlXo6ls4+IbpPE=; b=NKBj4Wnz64J35zbWyAvzDucXEisLfghB37feW7YsIbfkQCNzSH8FDvSgBdBoqE2TN6 mEQ+XqauYHSvclyHzHIH9mG4Ph7CsTtrUr4PF6KbYJBJxwTa6U7SDN/M6h+676rfcJkY Uzr6K3V53acS16wwinGFFtsagKOAToNYnNKVQoCbyNYsbJ/o+xX2WDN7r3WJawl7BCEF PvZoqXdBaw0T/Ns7b+6oRjv9RYWAZyRkg3iX1P9CQfuJtgrIgrX5TAYAu8p36NtqU3Sz EPuDh5iCfp3FbX8hBN4NqcQeaip3saXKJfP+1Dw/juAvPILe4aPftXk4DCTcrSZxjudM i61g== MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr3236054igb.90.1363289195157; Thu, 14 Mar 2013 12:26:35 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Thu, 14 Mar 2013 12:26:34 -0700 (PDT) Date: Thu, 14 Mar 2013 13:26:34 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] best os for 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: multipart/mixed; boundary="===============6478376399028004971==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6478376399028004971== Content-Type: multipart/alternative; boundary=089e011847f634271904d7e7808b --089e011847f634271904d7e7808b Content-Type: text/plain; charset=ISO-8859-1 I wonder if anyone has recommendation for very stable os for xen. I trying to decide between netbsd opensuse and arch linux.Opensuse seems to have lots of patches directed at xen. Arch is very nice update system. --089e011847f634271904d7e7808b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I wonder if anyone has=A0recommendation=A0for very stable os for xen. I try= ing to decide between netbsd opensuse and arch linux.Opensuse seems to have= lots of patches directed at xen. Arch is very nice update system.=A0
<= br>
--089e011847f634271904d7e7808b-- --===============6478376399028004971== 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 --===============6478376399028004971==-- From xen-users-bounces@lists.xen.org Thu Mar 14 19:27:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 19:27: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 1UGDnT-0008NG-Px; Thu, 14 Mar 2013 19:26:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGDnR-0008N9-UT for xen-users@lists.xen.org; Thu, 14 Mar 2013 19:26:38 +0000 Received: from [85.158.139.211:10021] by server-6.bemta-5.messagelabs.com id 43/B4-21466-D6422415; Thu, 14 Mar 2013 19:26:37 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1363289195!18368275!1 X-Originating-IP: [209.85.210.175] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 970 invoked from network); 14 Mar 2013 19:26:36 -0000 Received: from mail-ia0-f175.google.com (HELO mail-ia0-f175.google.com) (209.85.210.175) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 19:26:36 -0000 Received: by mail-ia0-f175.google.com with SMTP id y26so190476iab.20 for ; Thu, 14 Mar 2013 12:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=5IuBBiob7/bkOXG2f3f3w41SNUNy6OlXo6ls4+IbpPE=; b=NKBj4Wnz64J35zbWyAvzDucXEisLfghB37feW7YsIbfkQCNzSH8FDvSgBdBoqE2TN6 mEQ+XqauYHSvclyHzHIH9mG4Ph7CsTtrUr4PF6KbYJBJxwTa6U7SDN/M6h+676rfcJkY Uzr6K3V53acS16wwinGFFtsagKOAToNYnNKVQoCbyNYsbJ/o+xX2WDN7r3WJawl7BCEF PvZoqXdBaw0T/Ns7b+6oRjv9RYWAZyRkg3iX1P9CQfuJtgrIgrX5TAYAu8p36NtqU3Sz EPuDh5iCfp3FbX8hBN4NqcQeaip3saXKJfP+1Dw/juAvPILe4aPftXk4DCTcrSZxjudM i61g== MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr3236054igb.90.1363289195157; Thu, 14 Mar 2013 12:26:35 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Thu, 14 Mar 2013 12:26:34 -0700 (PDT) Date: Thu, 14 Mar 2013 13:26:34 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] best os for 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: multipart/mixed; boundary="===============6478376399028004971==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6478376399028004971== Content-Type: multipart/alternative; boundary=089e011847f634271904d7e7808b --089e011847f634271904d7e7808b Content-Type: text/plain; charset=ISO-8859-1 I wonder if anyone has recommendation for very stable os for xen. I trying to decide between netbsd opensuse and arch linux.Opensuse seems to have lots of patches directed at xen. Arch is very nice update system. --089e011847f634271904d7e7808b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I wonder if anyone has=A0recommendation=A0for very stable os for xen. I try= ing to decide between netbsd opensuse and arch linux.Opensuse seems to have= lots of patches directed at xen. Arch is very nice update system.=A0
<= br>
--089e011847f634271904d7e7808b-- --===============6478376399028004971== 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 --===============6478376399028004971==-- From xen-users-bounces@lists.xen.org Thu Mar 14 20:09:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 20:09: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 1UGERk-00010x-Oh; Thu, 14 Mar 2013 20:08:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGERf-00010n-IT for xen-users@lists.xen.org; Thu, 14 Mar 2013 20:08:15 +0000 Received: from [193.109.254.147:9310] by server-6.bemta-14.messagelabs.com id 80/8F-31180-A2E22415; Thu, 14 Mar 2013 20:08:10 +0000 X-Env-Sender: xensource.com@bloms.de X-Msg-Ref: server-9.tower-27.messagelabs.com!1363291688!8899386!1 X-Originating-IP: [84.200.248.35] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11853 invoked from network); 14 Mar 2013 20:08:09 -0000 Received: from unknown (HELO smtp.bloms.de) (84.200.248.35) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Mar 2013 20:08:09 -0000 Received: from smtp.bloms.de (localhost [127.0.0.1]) by smtp.bloms.de (Postfix) with ESMTP id 509C240350 for ; Thu, 14 Mar 2013 21:06:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to :subject:message-id:mime-version:content-type; s=selector1; bh=g CQZnpUReOgrnzMeyT6v8yyMKRo=; b=Q77ZX+UMdkxH1IgYoru7HLGvdHGRNpNnZ oNE0BO0+/3XmnP0MaMeITX7XkmoT0EUV5slXim2ZmBu3tqKAivfNClUAozVDp84X 3i0JVzSTWr02h8I8MxE7z4b/oiNfFvrMgTZ9xt5UEqJiJXujlvqdSxVIFHcOUpRp C7He7+e0enotTciipsnIpyaWCtcqrwsJez59Fdn4GTC6oLxeP1rYajH7o9rkoUcQ CZBCkI6LlgEO+Egz7PaWx3EykO7BDrHsVydxSxer7NFEol2uQaRT1Gob7nNpGDKB Jq9iywxvx9sCnnDjVDkpXCP6jQEmf35tE5pPUGu4LUfQISHZN5Hg2/fif0mbCkW4 g65/sJHfvuUgz02UPdn4NK0A5I+FCp5a3E5Gp2SwttY1ZK1C1Z0iPKzH4xfh35v5 7oNh/kYMFfUZmUDFtGnC6Fosv1oaTyWysWPKQlEyBvYbK/72qcUFImF2qhoIu3b/ sM3FA8UhBTD7PQQr1XQ3ax+LICp6SLnjr3xYCmYRtywRd1uO9cwmkvWLExBAeo0y NqV5BDKu9ESWXXoi4i6JZ0Hz98eBfdGeXkAIiKZTv8h5kjta+oMcV+3Bz+7qp53o JadECpOHUfjyrQKjDeJimGpnlSfKPMQMQQqQGA8m9gvKdzRZEE3b/ZiktoYwyzss wfdX4pcaOY= Received: by smtp.bloms.de (Postfix, from userid 1000) id 20D5A40546; Thu, 14 Mar 2013 21:06:10 +0100 (CET) Date: Thu, 14 Mar 2013 21:06:09 +0100 From: Dieter Bloms To: xen-users@lists.xen.org Message-ID: <20130314200609.GA9498@bloms.de> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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 try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my pv-grub config doesn't work anymore. With alpinelinux as dom0 (with xen 4.2.1) I had no problem. With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error messages, when I try to start a domU with pv-grub: http://pastebin.com/PHLQKrsb the config file looks like: http://pastebin.com/jbtEgcnv when I change my config to use pygrub, I can start my domU with this configfile: http://pastebin.com/RJVerpRA Does anybody have a clue what the reason is for pv-grub can not be used ? -- Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 20:09:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 20:09: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 1UGERk-00010x-Oh; Thu, 14 Mar 2013 20:08:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGERf-00010n-IT for xen-users@lists.xen.org; Thu, 14 Mar 2013 20:08:15 +0000 Received: from [193.109.254.147:9310] by server-6.bemta-14.messagelabs.com id 80/8F-31180-A2E22415; Thu, 14 Mar 2013 20:08:10 +0000 X-Env-Sender: xensource.com@bloms.de X-Msg-Ref: server-9.tower-27.messagelabs.com!1363291688!8899386!1 X-Originating-IP: [84.200.248.35] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11853 invoked from network); 14 Mar 2013 20:08:09 -0000 Received: from unknown (HELO smtp.bloms.de) (84.200.248.35) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Mar 2013 20:08:09 -0000 Received: from smtp.bloms.de (localhost [127.0.0.1]) by smtp.bloms.de (Postfix) with ESMTP id 509C240350 for ; Thu, 14 Mar 2013 21:06:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to :subject:message-id:mime-version:content-type; s=selector1; bh=g CQZnpUReOgrnzMeyT6v8yyMKRo=; b=Q77ZX+UMdkxH1IgYoru7HLGvdHGRNpNnZ oNE0BO0+/3XmnP0MaMeITX7XkmoT0EUV5slXim2ZmBu3tqKAivfNClUAozVDp84X 3i0JVzSTWr02h8I8MxE7z4b/oiNfFvrMgTZ9xt5UEqJiJXujlvqdSxVIFHcOUpRp C7He7+e0enotTciipsnIpyaWCtcqrwsJez59Fdn4GTC6oLxeP1rYajH7o9rkoUcQ CZBCkI6LlgEO+Egz7PaWx3EykO7BDrHsVydxSxer7NFEol2uQaRT1Gob7nNpGDKB Jq9iywxvx9sCnnDjVDkpXCP6jQEmf35tE5pPUGu4LUfQISHZN5Hg2/fif0mbCkW4 g65/sJHfvuUgz02UPdn4NK0A5I+FCp5a3E5Gp2SwttY1ZK1C1Z0iPKzH4xfh35v5 7oNh/kYMFfUZmUDFtGnC6Fosv1oaTyWysWPKQlEyBvYbK/72qcUFImF2qhoIu3b/ sM3FA8UhBTD7PQQr1XQ3ax+LICp6SLnjr3xYCmYRtywRd1uO9cwmkvWLExBAeo0y NqV5BDKu9ESWXXoi4i6JZ0Hz98eBfdGeXkAIiKZTv8h5kjta+oMcV+3Bz+7qp53o JadECpOHUfjyrQKjDeJimGpnlSfKPMQMQQqQGA8m9gvKdzRZEE3b/ZiktoYwyzss wfdX4pcaOY= Received: by smtp.bloms.de (Postfix, from userid 1000) id 20D5A40546; Thu, 14 Mar 2013 21:06:10 +0100 (CET) Date: Thu, 14 Mar 2013 21:06:09 +0100 From: Dieter Bloms To: xen-users@lists.xen.org Message-ID: <20130314200609.GA9498@bloms.de> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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 try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my pv-grub config doesn't work anymore. With alpinelinux as dom0 (with xen 4.2.1) I had no problem. With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error messages, when I try to start a domU with pv-grub: http://pastebin.com/PHLQKrsb the config file looks like: http://pastebin.com/jbtEgcnv when I change my config to use pygrub, I can start my domU with this configfile: http://pastebin.com/RJVerpRA Does anybody have a clue what the reason is for pv-grub can not be used ? -- Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 21:18:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 21:18: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 1UGFVt-0002IL-SX; Thu, 14 Mar 2013 21:16:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGFVs-0002IG-PJ for xen-users@lists.xen.org; Thu, 14 Mar 2013 21:16:36 +0000 Received: from [193.109.254.147:26245] by server-1.bemta-14.messagelabs.com id 10/D5-28280-43E32415; Thu, 14 Mar 2013 21:16:36 +0000 X-Env-Sender: knockknock@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1363295791!8997903!1 X-Originating-IP: [209.85.212.178] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26829 invoked from network); 14 Mar 2013 21:16:32 -0000 Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 21:16:32 -0000 Received: by mail-wi0-f178.google.com with SMTP id hq4so2246691wib.17 for ; Thu, 14 Mar 2013 14:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=wh1havhgvEkruS9uc0Q2QHWW7phlYGotkzWLV/+c/LU=; b=fjWduq4sXx5OmGAplY5Hy5suRxbmtwUTvvwu+pWB8zXSoys5WxXlvGzHJY2eNyHV2U V6+J1gVRNftmg+ArZxnzg/JV+YMkL0BRyiCrGtdEUz8kJY18+nmNzhSv7GiDrR1BXlhS nSBTbSex8oCdLgntUyxXZ8SMv/58ccbNs5w0c+Z1tCMq71gPyotcx8m8r87N0Aezc4aK Vww5r8vzquvgto6baekwF3pjsWwHBZ0H/odgWbdYIYnupD2kryfVfwv12gcxHWQqSzkC IuDjCvK/jEgh05VcWdvfbcR+terak0nicDql3cc+peGJ51ee1/L4wGvyFRdSc6e7S+iA sngA== X-Received: by 10.194.119.33 with SMTP id kr1mr6558031wjb.36.1363295791868; Thu, 14 Mar 2013 14:16:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.166 with HTTP; Thu, 14 Mar 2013 14:16:11 -0700 (PDT) From: Eric Shelton Date: Thu, 14 Mar 2013 17:16:11 -0400 X-Google-Sender-Auth: HcDYpmb0z_xQpv7K7THjb0JQX6E Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] opensolaris on PVHVM? X-BeenThere: xen-users@lists.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 Is anyone successfully running opensolaris with PV drivers under HVM on Xen 4.x.y? I am running on an AMD IOMMU capable computer. The closest I have gotten is: 1) coaxing openindiana into booting up as a PV guest 2) with acpi=0 and use of the kernel bugger, openindiana gets pretty far into boot, but there is a bug present in 151a7, in which the hvm_ps module OmniOS seems Also, in an attempt to get up in it looks like the "xen_platform_pci" parameter in xl.cfg type files does nothing as the code presently stands, or at least when using qemu-unstable. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 21:18:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 21:18: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 1UGFVt-0002IL-SX; Thu, 14 Mar 2013 21:16:37 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGFVs-0002IG-PJ for xen-users@lists.xen.org; Thu, 14 Mar 2013 21:16:36 +0000 Received: from [193.109.254.147:26245] by server-1.bemta-14.messagelabs.com id 10/D5-28280-43E32415; Thu, 14 Mar 2013 21:16:36 +0000 X-Env-Sender: knockknock@gmail.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1363295791!8997903!1 X-Originating-IP: [209.85.212.178] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26829 invoked from network); 14 Mar 2013 21:16:32 -0000 Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 21:16:32 -0000 Received: by mail-wi0-f178.google.com with SMTP id hq4so2246691wib.17 for ; Thu, 14 Mar 2013 14:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=wh1havhgvEkruS9uc0Q2QHWW7phlYGotkzWLV/+c/LU=; b=fjWduq4sXx5OmGAplY5Hy5suRxbmtwUTvvwu+pWB8zXSoys5WxXlvGzHJY2eNyHV2U V6+J1gVRNftmg+ArZxnzg/JV+YMkL0BRyiCrGtdEUz8kJY18+nmNzhSv7GiDrR1BXlhS nSBTbSex8oCdLgntUyxXZ8SMv/58ccbNs5w0c+Z1tCMq71gPyotcx8m8r87N0Aezc4aK Vww5r8vzquvgto6baekwF3pjsWwHBZ0H/odgWbdYIYnupD2kryfVfwv12gcxHWQqSzkC IuDjCvK/jEgh05VcWdvfbcR+terak0nicDql3cc+peGJ51ee1/L4wGvyFRdSc6e7S+iA sngA== X-Received: by 10.194.119.33 with SMTP id kr1mr6558031wjb.36.1363295791868; Thu, 14 Mar 2013 14:16:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.166 with HTTP; Thu, 14 Mar 2013 14:16:11 -0700 (PDT) From: Eric Shelton Date: Thu, 14 Mar 2013 17:16:11 -0400 X-Google-Sender-Auth: HcDYpmb0z_xQpv7K7THjb0JQX6E Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] opensolaris on PVHVM? X-BeenThere: xen-users@lists.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 Is anyone successfully running opensolaris with PV drivers under HVM on Xen 4.x.y? I am running on an AMD IOMMU capable computer. The closest I have gotten is: 1) coaxing openindiana into booting up as a PV guest 2) with acpi=0 and use of the kernel bugger, openindiana gets pretty far into boot, but there is a bug present in 151a7, in which the hvm_ps module OmniOS seems Also, in an attempt to get up in it looks like the "xen_platform_pci" parameter in xl.cfg type files does nothing as the code presently stands, or at least when using qemu-unstable. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 22:32:34 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 22:32: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 1UGGg5-00040h-N6; Thu, 14 Mar 2013 22:31:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGGg4-00040c-4n for xen-users@lists.xen.org; Thu, 14 Mar 2013 22:31:12 +0000 Received: from [85.158.143.99:42926] by server-3.bemta-4.messagelabs.com id EB/0E-02186-FAF42415; Thu, 14 Mar 2013 22:31:11 +0000 X-Env-Sender: knockknock@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1363300257!27988364!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13492 invoked from network); 14 Mar 2013 22:30:57 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 22:30:57 -0000 Received: by mail-wg0-f50.google.com with SMTP id es5so2576080wgb.5 for ; Thu, 14 Mar 2013 15:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=sahIVDTdJ63KoCusQGXYe1/wFdtDati+q7JnYPtk/5U=; b=vt3GSXvOIiQ+YvtfvRwG58patjce7JJ9qeygI7IbeEVCTZsE6ho5q67x8utQwNd91Z oQGkXemZnvmRzYNiVBshD4nGKkYV3YS2PGadvTZaZSsvoJXaKcBGChNoTsnvF0P7x61A +2R+5bMmtpkLyFuHPBXK5kV++A87YwxxL7c3z06IS8gztWZ3QrDjTdyMV2MY2pkM7qhz cuhECZhB/Gfaq5cEjmK/m4wsa7Gl8ieGwSaMfElBcbiT1kiDIbZLJrW66LmyKre7koYh xgFsXne8wC2v2oVQH8KIHsmzgmDwyHIZ/LLQQbWV39i9pz6EZbnn+MJ8e3vvyzeOk4us bb/w== X-Received: by 10.194.119.33 with SMTP id kr1mr6812867wjb.36.1363300257338; Thu, 14 Mar 2013 15:30:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.166 with HTTP; Thu, 14 Mar 2013 15:30:37 -0700 (PDT) From: Eric Shelton Date: Thu, 14 Mar 2013 18:30:37 -0400 X-Google-Sender-Auth: Vv-IXG_8MeCgbk9aMlSriWLhAqA Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] opensolaris/illumos on PVHVM under 4.x.y? X-BeenThere: xen-users@lists.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 [sorry for the dupe, the previous message was sent out prematurely...] I was hoping to implement a storage domain using blkback to serve up ZFS zvols, to see how it works out. Is anyone successfully running opensolaris with PV drivers under HVM on Xen 4.x.y? I am running on an AMD IOMMU capable computer. The closest I have gotten is: (1) coaxing openindiana into booting up as a PV guest (not a smooth out-of-the-box type of install) (2) with acpi=0, an HVM boot will go pretty far, but there is a bug present in 151a7, in which the hvm_sd and sd modules fail to load due to being improperly built and take down the boot. A patch for this issue was entered into the illumos-gate repository, but does not appear to have been used for any current distribution. (3) with acpi=0 and use of the kernel bugger (::bp get_hwenv, :c, platform_type/W 0, ::delete 1, :c), I can get openindiana to boot up a plain PC kernel. I think I recall network and/or PV driver issues being a problem. (4) I tried out some illumos-gate kernel build/installs, but the typical response from a new build is some kind of a hang or lockup that is unresponsive to the F1-A kernel debugger. However, I am definitely stumbling my way through this, so I may not have run the kernel build or install correctly. OmniOS dies pretty quickly, whether under PV or HVM. I am beginning to get the impression that there was an active PV and functional driver under Xen 3, but that the illumos PV drivers did not keep up with various changes required to interoperate with Xen 4 (or at least the more recent Xen releases). Even if I were to consider KVM, although virtio-blk looks like it may be OK, a proposed virtio-net driver has not been accepted into illumos-gate, and is of unknown quality (it appears to be a slightly tweaked version of a prototype driver that was admitted to be incomplete by its original author). There appear to be suggestions that PVHVM has been maintained and works in Solaris 11, but I would much more strongly prefer using one of the illumos-based distributions. If there is anyone running opensolaris outside of PV (in other words, under HVM) under Xen 4.x.y, what is your Xen guest config, and which distribution are you using? Also, in sorting out how I might boot a plain non-HVM kernel (see use of the kernel debugger under (3) above), it looks like the "xen_platform_pci" parameter in xl.cfg-type files does nothing as the code presently stands - defeinitely when using qemu-upstream, and I think also under qemu-traditional. The xenpci device continues to show up on the virtual PCI bus under "xen_platform_pci=0". However, even if the xenpci device was toggled on/off, it turns out illumos would still boot an HVM kernel, as it uses the availability of the 0x40000000 cpuid info to identify when it is running under Xen (hence the debugger procedure set out in (3) above). If xen_platform_pci is set to 0, is this Xen cpuid functionality supposed to be diabled? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 14 22:32:34 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 14 Mar 2013 22:32: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 1UGGg5-00040h-N6; Thu, 14 Mar 2013 22:31:13 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGGg4-00040c-4n for xen-users@lists.xen.org; Thu, 14 Mar 2013 22:31:12 +0000 Received: from [85.158.143.99:42926] by server-3.bemta-4.messagelabs.com id EB/0E-02186-FAF42415; Thu, 14 Mar 2013 22:31:11 +0000 X-Env-Sender: knockknock@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1363300257!27988364!1 X-Originating-IP: [74.125.82.50] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13492 invoked from network); 14 Mar 2013 22:30:57 -0000 Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 14 Mar 2013 22:30:57 -0000 Received: by mail-wg0-f50.google.com with SMTP id es5so2576080wgb.5 for ; Thu, 14 Mar 2013 15:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=sahIVDTdJ63KoCusQGXYe1/wFdtDati+q7JnYPtk/5U=; b=vt3GSXvOIiQ+YvtfvRwG58patjce7JJ9qeygI7IbeEVCTZsE6ho5q67x8utQwNd91Z oQGkXemZnvmRzYNiVBshD4nGKkYV3YS2PGadvTZaZSsvoJXaKcBGChNoTsnvF0P7x61A +2R+5bMmtpkLyFuHPBXK5kV++A87YwxxL7c3z06IS8gztWZ3QrDjTdyMV2MY2pkM7qhz cuhECZhB/Gfaq5cEjmK/m4wsa7Gl8ieGwSaMfElBcbiT1kiDIbZLJrW66LmyKre7koYh xgFsXne8wC2v2oVQH8KIHsmzgmDwyHIZ/LLQQbWV39i9pz6EZbnn+MJ8e3vvyzeOk4us bb/w== X-Received: by 10.194.119.33 with SMTP id kr1mr6812867wjb.36.1363300257338; Thu, 14 Mar 2013 15:30:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.166 with HTTP; Thu, 14 Mar 2013 15:30:37 -0700 (PDT) From: Eric Shelton Date: Thu, 14 Mar 2013 18:30:37 -0400 X-Google-Sender-Auth: Vv-IXG_8MeCgbk9aMlSriWLhAqA Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] opensolaris/illumos on PVHVM under 4.x.y? X-BeenThere: xen-users@lists.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 [sorry for the dupe, the previous message was sent out prematurely...] I was hoping to implement a storage domain using blkback to serve up ZFS zvols, to see how it works out. Is anyone successfully running opensolaris with PV drivers under HVM on Xen 4.x.y? I am running on an AMD IOMMU capable computer. The closest I have gotten is: (1) coaxing openindiana into booting up as a PV guest (not a smooth out-of-the-box type of install) (2) with acpi=0, an HVM boot will go pretty far, but there is a bug present in 151a7, in which the hvm_sd and sd modules fail to load due to being improperly built and take down the boot. A patch for this issue was entered into the illumos-gate repository, but does not appear to have been used for any current distribution. (3) with acpi=0 and use of the kernel bugger (::bp get_hwenv, :c, platform_type/W 0, ::delete 1, :c), I can get openindiana to boot up a plain PC kernel. I think I recall network and/or PV driver issues being a problem. (4) I tried out some illumos-gate kernel build/installs, but the typical response from a new build is some kind of a hang or lockup that is unresponsive to the F1-A kernel debugger. However, I am definitely stumbling my way through this, so I may not have run the kernel build or install correctly. OmniOS dies pretty quickly, whether under PV or HVM. I am beginning to get the impression that there was an active PV and functional driver under Xen 3, but that the illumos PV drivers did not keep up with various changes required to interoperate with Xen 4 (or at least the more recent Xen releases). Even if I were to consider KVM, although virtio-blk looks like it may be OK, a proposed virtio-net driver has not been accepted into illumos-gate, and is of unknown quality (it appears to be a slightly tweaked version of a prototype driver that was admitted to be incomplete by its original author). There appear to be suggestions that PVHVM has been maintained and works in Solaris 11, but I would much more strongly prefer using one of the illumos-based distributions. If there is anyone running opensolaris outside of PV (in other words, under HVM) under Xen 4.x.y, what is your Xen guest config, and which distribution are you using? Also, in sorting out how I might boot a plain non-HVM kernel (see use of the kernel debugger under (3) above), it looks like the "xen_platform_pci" parameter in xl.cfg-type files does nothing as the code presently stands - defeinitely when using qemu-upstream, and I think also under qemu-traditional. The xenpci device continues to show up on the virtual PCI bus under "xen_platform_pci=0". However, even if the xenpci device was toggled on/off, it turns out illumos would still boot an HVM kernel, as it uses the availability of the 0x40000000 cpuid info to identify when it is running under Xen (hence the debugger procedure set out in (3) above). If xen_platform_pci is set to 0, is this Xen cpuid functionality supposed to be diabled? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 01:33:31 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 01:33: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 1UGJVC-0001jF-WB; Fri, 15 Mar 2013 01:32:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGJVB-0001jA-IZ for xen-users@lists.xen.org; Fri, 15 Mar 2013 01:32:09 +0000 Received: from [193.109.254.147:19884] by server-1.bemta-14.messagelabs.com id F5/3D-28280-81A72415; Fri, 15 Mar 2013 01:32:08 +0000 X-Env-Sender: vijay.phadke@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1363311124!2975719!1 X-Originating-IP: [209.85.215.181] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24751 invoked from network); 15 Mar 2013 01:32:06 -0000 Received: from mail-ea0-f181.google.com (HELO mail-ea0-f181.google.com) (209.85.215.181) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 01:32:06 -0000 Received: by mail-ea0-f181.google.com with SMTP id z10so1268616ead.12 for ; Thu, 14 Mar 2013 18:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6jOpq5I7PyxuQjkj2x8VwH4mW4NP6OnZxxNc3DFOxLs=; b=bbeJUX3k9aEawHztrUY8lxZ674HhANoJ/CJF7xxWD2S1AS5PqQhMxpycyXdRD6Pgrd HyGm+SilsCDEVjndI4FkooP60m7sQGRgDYUt9IzPQJqDMFAo9yowtDbA1WFDA1Qibu2x pXiK2xCbl8Q3CizcPpvFVkIGBucF2QTBQlZ/ghxhjMAeZ/r0z5fXnC8jhUe8l/kP/Jn+ Rten7RI1iJ0DaUQjVfy4tJM12/AG/Ezmgz9YhbW4yUDoMXJMofbuAvoRFs3J2Qe0wmn4 E8zc3Iy7vU7fvDmOOCZNMKE12sCD/zdnTVMnXg7THnxUoroVaWnfoZSmZQn5cQ2lBlTL HgWw== MIME-Version: 1.0 X-Received: by 10.14.3.133 with SMTP id 5mr12402945eeh.43.1363311123213; Thu, 14 Mar 2013 18:32:03 -0700 (PDT) Received: by 10.15.81.199 with HTTP; Thu, 14 Mar 2013 18:32:03 -0700 (PDT) In-Reply-To: <20130314200609.GA9498@bloms.de> References: <20130314200609.GA9498@bloms.de> Date: Thu, 14 Mar 2013 18:32:03 -0700 Message-ID: From: Vijay Phadke To: Dieter Bloms Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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="===============4455904782092580514==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4455904782092580514== Content-Type: multipart/alternative; boundary=047d7b6226a437dbfd04d7ec9bbd --047d7b6226a437dbfd04d7ec9bbd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 14, 2013 at 1:06 PM, Dieter Bloms wrote: > Hi, > > I try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my > pv-grub config doesn't work anymore. > With alpinelinux as dom0 (with xen 4.2.1) I had no problem. > With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error > messages, when I try to start a domU with pv-grub: > http://pastebin.com/PHLQKrsb > > the config file looks like: > http://pastebin.com/jbtEgcnv > > when I change my config to use pygrub, I can start my domU > with this configfile: > http://pastebin.com/RJVerpRA > > Does anybody have a clue what the reason is for pv-grub can not be used ? > > -- > Best regards > > Dieter > > Not sure but alpinelinux is uClibc/Busybox based vs OpenSUSE which is standard desktop version. Both are quite different, so I guess it might be the driver issue. Look at the dom0/domU kernel config and that might point to the problem. Also if you have used stock kernel it might not have necessary xen options in the kernel, check that as well. --047d7b6226a437dbfd04d7ec9bbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 14, 2013 at 1:06 PM, Dieter = Bloms <xensource.com@bloms.de> wrote:
Hi,

I try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my
pv-grub config doesn't work anymore.
With alpinelinux as dom0 (with xen 4.2.1) I had no problem.
With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error
messages, when I try to start a domU with pv-grub:
http://pastebin.= com/PHLQKrsb

the config file looks like:
http://pastebin.= com/jbtEgcnv

when I change my config to use pygrub, I can start my domU
with this configfile:
http://pastebin.= com/RJVerpRA

Does anybody have a clue what the reason is for pv-grub can not be used ?
--
Best regards

=A0 Dieter


Not sure but alpinelinux is uClibc/Busybox based = vs OpenSUSE which is standard desktop version. Both are quite different, so= I guess it might be the driver issue. Look at the dom0/domU kernel config = and that might point to the problem. Also if you have used stock kernel it = might not have necessary xen options in the kernel, check that as well.
--047d7b6226a437dbfd04d7ec9bbd-- --===============4455904782092580514== 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 --===============4455904782092580514==-- From xen-users-bounces@lists.xen.org Fri Mar 15 01:33:31 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 01:33: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 1UGJVC-0001jF-WB; Fri, 15 Mar 2013 01:32:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGJVB-0001jA-IZ for xen-users@lists.xen.org; Fri, 15 Mar 2013 01:32:09 +0000 Received: from [193.109.254.147:19884] by server-1.bemta-14.messagelabs.com id F5/3D-28280-81A72415; Fri, 15 Mar 2013 01:32:08 +0000 X-Env-Sender: vijay.phadke@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1363311124!2975719!1 X-Originating-IP: [209.85.215.181] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24751 invoked from network); 15 Mar 2013 01:32:06 -0000 Received: from mail-ea0-f181.google.com (HELO mail-ea0-f181.google.com) (209.85.215.181) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 01:32:06 -0000 Received: by mail-ea0-f181.google.com with SMTP id z10so1268616ead.12 for ; Thu, 14 Mar 2013 18:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6jOpq5I7PyxuQjkj2x8VwH4mW4NP6OnZxxNc3DFOxLs=; b=bbeJUX3k9aEawHztrUY8lxZ674HhANoJ/CJF7xxWD2S1AS5PqQhMxpycyXdRD6Pgrd HyGm+SilsCDEVjndI4FkooP60m7sQGRgDYUt9IzPQJqDMFAo9yowtDbA1WFDA1Qibu2x pXiK2xCbl8Q3CizcPpvFVkIGBucF2QTBQlZ/ghxhjMAeZ/r0z5fXnC8jhUe8l/kP/Jn+ Rten7RI1iJ0DaUQjVfy4tJM12/AG/Ezmgz9YhbW4yUDoMXJMofbuAvoRFs3J2Qe0wmn4 E8zc3Iy7vU7fvDmOOCZNMKE12sCD/zdnTVMnXg7THnxUoroVaWnfoZSmZQn5cQ2lBlTL HgWw== MIME-Version: 1.0 X-Received: by 10.14.3.133 with SMTP id 5mr12402945eeh.43.1363311123213; Thu, 14 Mar 2013 18:32:03 -0700 (PDT) Received: by 10.15.81.199 with HTTP; Thu, 14 Mar 2013 18:32:03 -0700 (PDT) In-Reply-To: <20130314200609.GA9498@bloms.de> References: <20130314200609.GA9498@bloms.de> Date: Thu, 14 Mar 2013 18:32:03 -0700 Message-ID: From: Vijay Phadke To: Dieter Bloms Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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="===============4455904782092580514==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4455904782092580514== Content-Type: multipart/alternative; boundary=047d7b6226a437dbfd04d7ec9bbd --047d7b6226a437dbfd04d7ec9bbd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 14, 2013 at 1:06 PM, Dieter Bloms wrote: > Hi, > > I try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my > pv-grub config doesn't work anymore. > With alpinelinux as dom0 (with xen 4.2.1) I had no problem. > With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error > messages, when I try to start a domU with pv-grub: > http://pastebin.com/PHLQKrsb > > the config file looks like: > http://pastebin.com/jbtEgcnv > > when I change my config to use pygrub, I can start my domU > with this configfile: > http://pastebin.com/RJVerpRA > > Does anybody have a clue what the reason is for pv-grub can not be used ? > > -- > Best regards > > Dieter > > Not sure but alpinelinux is uClibc/Busybox based vs OpenSUSE which is standard desktop version. Both are quite different, so I guess it might be the driver issue. Look at the dom0/domU kernel config and that might point to the problem. Also if you have used stock kernel it might not have necessary xen options in the kernel, check that as well. --047d7b6226a437dbfd04d7ec9bbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 14, 2013 at 1:06 PM, Dieter = Bloms <xensource.com@bloms.de> wrote:
Hi,

I try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my
pv-grub config doesn't work anymore.
With alpinelinux as dom0 (with xen 4.2.1) I had no problem.
With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error
messages, when I try to start a domU with pv-grub:
http://pastebin.= com/PHLQKrsb

the config file looks like:
http://pastebin.= com/jbtEgcnv

when I change my config to use pygrub, I can start my domU
with this configfile:
http://pastebin.= com/RJVerpRA

Does anybody have a clue what the reason is for pv-grub can not be used ?
--
Best regards

=A0 Dieter


Not sure but alpinelinux is uClibc/Busybox based = vs OpenSUSE which is standard desktop version. Both are quite different, so= I guess it might be the driver issue. Look at the dom0/domU kernel config = and that might point to the problem. Also if you have used stock kernel it = might not have necessary xen options in the kernel, check that as well.
--047d7b6226a437dbfd04d7ec9bbd-- --===============4455904782092580514== 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 --===============4455904782092580514==-- From xen-users-bounces@lists.xen.org Fri Mar 15 05:33:03 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 05:33: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 1UGNFC-0007XL-Pv; Fri, 15 Mar 2013 05:31:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGNFB-0007XG-Pm for xen-users@lists.xen.org; Fri, 15 Mar 2013 05:31:53 +0000 Received: from [193.109.254.147:21339] by server-2.bemta-14.messagelabs.com id 62/A1-14115-842B2415; Fri, 15 Mar 2013 05:31:52 +0000 X-Env-Sender: digvijaych@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1363325505!8961632!1 X-Originating-IP: [209.85.215.50] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19966 invoked from network); 15 Mar 2013 05:31:45 -0000 Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com) (209.85.215.50) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 05:31:45 -0000 Received: by mail-la0-f50.google.com with SMTP id ec20so3371847lab.9 for ; Thu, 14 Mar 2013 22:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=k0tXHXzXi1WE2Ukh0HlXgf+B05LP/h4HKiZrvuFURg8=; b=iUHCJMCXIpwYIhkBg9QMqoxBjJqyqai53tZhgjqOE+hl9ubbkbFGkcAR3h/S6yOvUd xWvf0Nz9f+cRYww9XkWIYFef4bnurV5XcFN7gC9T140ehOnbjmTOwDudilHFsshIRUt7 A4gTETrk9+/cg3wbZSf6QZftfervugZsvZmXTW4MzBRZL8pRrVMkvroQ1fCVxMf0z3sa YC6Fc+QRxo3AqHbpR1hxWVRQOxM5LAy2oUB2pbCklaMr1dMHgaHR0EsdP0QlIzSLIuEg bvzirUC9vyXtB/Rkv6n1fToiQ1ECv+0NAe3FCR7GmRGQLMCAqWqhZyfB4pJYLCebS53a 1zrw== MIME-Version: 1.0 X-Received: by 10.152.128.98 with SMTP id nn2mr4569562lab.17.1363325504756; Thu, 14 Mar 2013 22:31:44 -0700 (PDT) Received: by 10.112.101.65 with HTTP; Thu, 14 Mar 2013 22:31:44 -0700 (PDT) Date: Fri, 15 Mar 2013 11:01:44 +0530 Message-ID: From: digvijay chauhan To: xen-users@lists.xen.org Subject: [Xen-users] make tools fail X-BeenThere: xen-users@lists.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="===============6108044186618511274==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6108044186618511274== Content-Type: multipart/alternative; boundary=f46d042c64236ca29c04d7eff4b8 --f46d042c64236ca29c04d7eff4b8 Content-Type: text/plain; charset=ISO-8859-1 Hello, I am trying to install xen4.2 but when ifire make tools command it gives me, Cloning into 'seabios-dir-remote.tmp'... fatal: unable to connect to xenbits.xen.org: xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out make[3]: *** [seabios-dir] Error 128 make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/firmware' make[2]: *** [subdir-install-firmware] Error 2 make[2]: Leaving directory `/home/ce/xen-4.2.0/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/home/ce/xen-4.2.0/tools' make: *** [install-tools] Error 2 so how can i overcome it. regards, DigvijaySingh --f46d042c64236ca29c04d7eff4b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I am trying to install xen4.2 b= ut when ifire make tools command it gives me,

Cloning into 'seab= ios-dir-remote.tmp'...
fatal: unable to connect to xenbits.xen.org:
xenbits.xen.org[0: 50.57.170.242]: e= rrno=3DConnection timed out

make[3]: *** [seabios-dir] Error 128
= make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/firmware'
make[= 2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [= subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/= tools'
make: *** [install-tools] Error 2


so how can i ove= rcome it.

regards,
DigvijaySingh
--f46d042c64236ca29c04d7eff4b8-- --===============6108044186618511274== 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 --===============6108044186618511274==-- From xen-users-bounces@lists.xen.org Fri Mar 15 05:33:03 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 05:33: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 1UGNFC-0007XL-Pv; Fri, 15 Mar 2013 05:31:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGNFB-0007XG-Pm for xen-users@lists.xen.org; Fri, 15 Mar 2013 05:31:53 +0000 Received: from [193.109.254.147:21339] by server-2.bemta-14.messagelabs.com id 62/A1-14115-842B2415; Fri, 15 Mar 2013 05:31:52 +0000 X-Env-Sender: digvijaych@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1363325505!8961632!1 X-Originating-IP: [209.85.215.50] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19966 invoked from network); 15 Mar 2013 05:31:45 -0000 Received: from mail-la0-f50.google.com (HELO mail-la0-f50.google.com) (209.85.215.50) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 05:31:45 -0000 Received: by mail-la0-f50.google.com with SMTP id ec20so3371847lab.9 for ; Thu, 14 Mar 2013 22:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=k0tXHXzXi1WE2Ukh0HlXgf+B05LP/h4HKiZrvuFURg8=; b=iUHCJMCXIpwYIhkBg9QMqoxBjJqyqai53tZhgjqOE+hl9ubbkbFGkcAR3h/S6yOvUd xWvf0Nz9f+cRYww9XkWIYFef4bnurV5XcFN7gC9T140ehOnbjmTOwDudilHFsshIRUt7 A4gTETrk9+/cg3wbZSf6QZftfervugZsvZmXTW4MzBRZL8pRrVMkvroQ1fCVxMf0z3sa YC6Fc+QRxo3AqHbpR1hxWVRQOxM5LAy2oUB2pbCklaMr1dMHgaHR0EsdP0QlIzSLIuEg bvzirUC9vyXtB/Rkv6n1fToiQ1ECv+0NAe3FCR7GmRGQLMCAqWqhZyfB4pJYLCebS53a 1zrw== MIME-Version: 1.0 X-Received: by 10.152.128.98 with SMTP id nn2mr4569562lab.17.1363325504756; Thu, 14 Mar 2013 22:31:44 -0700 (PDT) Received: by 10.112.101.65 with HTTP; Thu, 14 Mar 2013 22:31:44 -0700 (PDT) Date: Fri, 15 Mar 2013 11:01:44 +0530 Message-ID: From: digvijay chauhan To: xen-users@lists.xen.org Subject: [Xen-users] make tools fail X-BeenThere: xen-users@lists.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="===============6108044186618511274==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6108044186618511274== Content-Type: multipart/alternative; boundary=f46d042c64236ca29c04d7eff4b8 --f46d042c64236ca29c04d7eff4b8 Content-Type: text/plain; charset=ISO-8859-1 Hello, I am trying to install xen4.2 but when ifire make tools command it gives me, Cloning into 'seabios-dir-remote.tmp'... fatal: unable to connect to xenbits.xen.org: xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out make[3]: *** [seabios-dir] Error 128 make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/firmware' make[2]: *** [subdir-install-firmware] Error 2 make[2]: Leaving directory `/home/ce/xen-4.2.0/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/home/ce/xen-4.2.0/tools' make: *** [install-tools] Error 2 so how can i overcome it. regards, DigvijaySingh --f46d042c64236ca29c04d7eff4b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I am trying to install xen4.2 b= ut when ifire make tools command it gives me,

Cloning into 'seab= ios-dir-remote.tmp'...
fatal: unable to connect to xenbits.xen.org:
xenbits.xen.org[0: 50.57.170.242]: e= rrno=3DConnection timed out

make[3]: *** [seabios-dir] Error 128
= make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/firmware'
make[= 2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [= subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/= tools'
make: *** [install-tools] Error 2


so how can i ove= rcome it.

regards,
DigvijaySingh
--f46d042c64236ca29c04d7eff4b8-- --===============6108044186618511274== 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 --===============6108044186618511274==-- From xen-users-bounces@lists.xen.org Fri Mar 15 07:41:18 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 07:41: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 1UGPFH-000155-Gf; Fri, 15 Mar 2013 07:40:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGPFF-00014e-Il; Fri, 15 Mar 2013 07:40:05 +0000 Received: from [85.158.139.83:36337] by server-9.bemta-5.messagelabs.com id 44/A7-08547-450D2415; Fri, 15 Mar 2013 07:40:04 +0000 X-Env-Sender: digvijaych@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1363333203!27878511!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=2.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, MISSING_SUBJECT,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25322 invoked from network); 15 Mar 2013 07:40:03 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 07:40:03 -0000 Received: by mail-la0-f43.google.com with SMTP id ek20so3437934lab.30 for ; Fri, 15 Mar 2013 00:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=fgQ/gKbP5822FyOq79Ajz6vguEndGrPW/wN/CMnLStE=; b=vMM3MTFkFLC+wEUAz9wvk6M56E2IpW4ZN6PKQxh7TslJlxF2SvXUmj2HyAIGdhhALx 1y5+9vyCu4w2cxdm3A/wtRyQpcOx1PIh3Wm+tgX9cDh1/H5y/JXxv4zbJIJhqiE3BIhp DInGJ+SNitRyrIg3B4YMh+TlsX+Jg65wZF7effUYKwlSy+VZVJSouJLlBOeXFsoIfCVR Fp5/bnn0DLCibT7WDPrbT33N29Hw9rOS51qMWJqM4w2JOaPtazhU37QBSWFQfy5bBg1S yKgtf/jcO1pfowSf3Oa5HcKSY/yFMSWbN3j2oVQxjcx4TWPE5NovnVa9G7FYPJAaY3Ui t/9A== MIME-Version: 1.0 X-Received: by 10.112.102.197 with SMTP id fq5mr2163360lbb.83.1363333202901; Fri, 15 Mar 2013 00:40:02 -0700 (PDT) Received: by 10.112.101.65 with HTTP; Fri, 15 Mar 2013 00:40:02 -0700 (PDT) Date: Fri, 15 Mar 2013 13:10:02 +0530 Message-ID: From: digvijay chauhan To: xen-users@lists.xen.org, xen-devel@lists.xen.org, xen-devel@lists.xensource.com, Ian Campbell , Christian Limpach Subject: [Xen-users] (no subject) X-BeenThere: xen-users@lists.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="===============1626073320987364441==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1626073320987364441== Content-Type: multipart/alternative; boundary=f46d0401f9d545043804d7f1bfbc --f46d0401f9d545043804d7f1bfbc Content-Type: text/plain; charset=ISO-8859-1 Hello, I am trying to install xen4.2 but when ifire make tools command it gives me, Cloning into 'seabios-dir-remote.tmp'... fatal: unable to connect to xenbits.xen.org: xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out make[3]: *** [seabios-dir] Error 128 make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ firmware' make[2]: *** [subdir-install-firmware] Error 2 make[2]: Leaving directory `/home/ce/xen-4.2.0/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/home/ce/xen-4.2.0/tools' make: *** [install-tools] Error 2 so how can i overcome it. regards, DigvijaySingh --f46d0401f9d545043804d7f1bfbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I am trying to install xen4.2 b= ut when ifire make tools command it gives me,

Cloning into 'seab= ios-dir-remote.tmp'...
fatal: unable to connect to xenbits.xen.org:
xenbits.xen.org[0:= 50.57.170.242]: errno=3DConnection timed out

make[3]: *** [seabios-= dir] Error 128
make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [= subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/= tools'
make: *** [install-tools] Error 2


so how can i ove= rcome it.

regards,
DigvijaySingh
--f46d0401f9d545043804d7f1bfbc-- --===============1626073320987364441== 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 --===============1626073320987364441==-- From xen-users-bounces@lists.xen.org Fri Mar 15 07:41:18 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 07:41: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 1UGPFH-000155-Gf; Fri, 15 Mar 2013 07:40:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGPFF-00014e-Il; Fri, 15 Mar 2013 07:40:05 +0000 Received: from [85.158.139.83:36337] by server-9.bemta-5.messagelabs.com id 44/A7-08547-450D2415; Fri, 15 Mar 2013 07:40:04 +0000 X-Env-Sender: digvijaych@gmail.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1363333203!27878511!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=2.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, MISSING_SUBJECT,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25322 invoked from network); 15 Mar 2013 07:40:03 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 07:40:03 -0000 Received: by mail-la0-f43.google.com with SMTP id ek20so3437934lab.30 for ; Fri, 15 Mar 2013 00:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=fgQ/gKbP5822FyOq79Ajz6vguEndGrPW/wN/CMnLStE=; b=vMM3MTFkFLC+wEUAz9wvk6M56E2IpW4ZN6PKQxh7TslJlxF2SvXUmj2HyAIGdhhALx 1y5+9vyCu4w2cxdm3A/wtRyQpcOx1PIh3Wm+tgX9cDh1/H5y/JXxv4zbJIJhqiE3BIhp DInGJ+SNitRyrIg3B4YMh+TlsX+Jg65wZF7effUYKwlSy+VZVJSouJLlBOeXFsoIfCVR Fp5/bnn0DLCibT7WDPrbT33N29Hw9rOS51qMWJqM4w2JOaPtazhU37QBSWFQfy5bBg1S yKgtf/jcO1pfowSf3Oa5HcKSY/yFMSWbN3j2oVQxjcx4TWPE5NovnVa9G7FYPJAaY3Ui t/9A== MIME-Version: 1.0 X-Received: by 10.112.102.197 with SMTP id fq5mr2163360lbb.83.1363333202901; Fri, 15 Mar 2013 00:40:02 -0700 (PDT) Received: by 10.112.101.65 with HTTP; Fri, 15 Mar 2013 00:40:02 -0700 (PDT) Date: Fri, 15 Mar 2013 13:10:02 +0530 Message-ID: From: digvijay chauhan To: xen-users@lists.xen.org, xen-devel@lists.xen.org, xen-devel@lists.xensource.com, Ian Campbell , Christian Limpach Subject: [Xen-users] (no subject) X-BeenThere: xen-users@lists.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="===============1626073320987364441==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1626073320987364441== Content-Type: multipart/alternative; boundary=f46d0401f9d545043804d7f1bfbc --f46d0401f9d545043804d7f1bfbc Content-Type: text/plain; charset=ISO-8859-1 Hello, I am trying to install xen4.2 but when ifire make tools command it gives me, Cloning into 'seabios-dir-remote.tmp'... fatal: unable to connect to xenbits.xen.org: xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out make[3]: *** [seabios-dir] Error 128 make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ firmware' make[2]: *** [subdir-install-firmware] Error 2 make[2]: Leaving directory `/home/ce/xen-4.2.0/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/home/ce/xen-4.2.0/tools' make: *** [install-tools] Error 2 so how can i overcome it. regards, DigvijaySingh --f46d0401f9d545043804d7f1bfbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I am trying to install xen4.2 b= ut when ifire make tools command it gives me,

Cloning into 'seab= ios-dir-remote.tmp'...
fatal: unable to connect to xenbits.xen.org:
xenbits.xen.org[0:= 50.57.170.242]: errno=3DConnection timed out

make[3]: *** [seabios-= dir] Error 128
make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [= subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/= tools'
make: *** [install-tools] Error 2


so how can i ove= rcome it.

regards,
DigvijaySingh
--f46d0401f9d545043804d7f1bfbc-- --===============1626073320987364441== 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 --===============1626073320987364441==-- From xen-users-bounces@lists.xen.org Fri Mar 15 07:41:56 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 07:41: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 1UGPG8-0001DU-0C; Fri, 15 Mar 2013 07:41:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGPG5-0001Cp-KR; Fri, 15 Mar 2013 07:40:57 +0000 Received: from [85.158.139.83:42669] by server-10.bemta-5.messagelabs.com id 73/E6-23714-880D2415; Fri, 15 Mar 2013 07:40:56 +0000 X-Env-Sender: digvijaych@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1363333253!27517595!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31404 invoked from network); 15 Mar 2013 07:40:53 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 07:40:53 -0000 Received: by mail-la0-f43.google.com with SMTP id ek20so3438506lab.16 for ; Fri, 15 Mar 2013 00:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=wlvhdCp+rUflJhoucXdAEQ2NGU65N9XqRMSMk61lwqI=; b=vuQ99jY74wEY3D/cAS7/Zg1AxtujnppTSdqvj3EIM48frMnqUSlrEENMczDyA+rXfM uKbKUDcSoZkWR8c1O+d/4jaY3B1pAYqYsogRb6eJrUbb1hgvWy2TXK4mu1628ChbwslO O1wf6lOoWrwnAOxsFk4RsAT5UnHsa5tHKhZnauOhNyy+vKmGSLwym5PvTtKyYr5G+0Zv FHo+X3ixtIB4Zc2dSpjTh9vwiwR3DVUFfxO0pWInuLube/oeZgQcCL705YQOdFe9iamT xfglE4kGqewmD/vJMzHfdNC1+8v8dNvKzE0z8GD4MBSL0VM2SGivAgOHDKD3yepqt1Sp nfaw== MIME-Version: 1.0 X-Received: by 10.152.144.202 with SMTP id so10mr4895412lab.9.1363333252684; Fri, 15 Mar 2013 00:40:52 -0700 (PDT) Received: by 10.112.101.65 with HTTP; Fri, 15 Mar 2013 00:40:52 -0700 (PDT) Date: Fri, 15 Mar 2013 13:10:52 +0530 Message-ID: From: digvijay chauhan To: xen-users@lists.xen.org, xen-devel@lists.xen.org, xen-devel@lists.xensource.com, Ian Campbell , Christian Limpach Subject: [Xen-users] make tools fail in 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: multipart/mixed; boundary="===============2465238583495386265==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2465238583495386265== Content-Type: multipart/alternative; boundary=e89a8f22bcc33ca18304d7f1c2de --e89a8f22bcc33ca18304d7f1c2de Content-Type: text/plain; charset=ISO-8859-1 Hello, I am trying to install xen4.2 but when ifire make tools command it gives me, Cloning into 'seabios-dir-remote.tmp'... fatal: unable to connect to xenbits.xen.org: xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out make[3]: *** [seabios-dir] Error 128 make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ firmware' make[2]: *** [subdir-install-firmware] Error 2 make[2]: Leaving directory `/home/ce/xen-4.2.0/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/home/ce/xen-4.2.0/tools' make: *** [install-tools] Error 2 so how can i overcome it. regards, DigvijaySingh --e89a8f22bcc33ca18304d7f1c2de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 I am trying to install xen4.2 but when ifire make tools command it give= s me,

Cloning into 'seabios-dir-remote.tmp'...
fatal: una= ble to connect to xenb= its.xen.org:
xenbits.xen.org[0:= 50.57.170.242]: errno=3DConnection timed out

make[3]: *** [seabios-= dir] Error 128
make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [= subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/= tools'
make: *** [install-tools] Error 2


so how can i ove= rcome it.

regards,
DigvijaySingh

--e89a8f22bcc33ca18304d7f1c2de-- --===============2465238583495386265== 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 --===============2465238583495386265==-- From xen-users-bounces@lists.xen.org Fri Mar 15 07:41:56 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 07:41: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 1UGPG8-0001DU-0C; Fri, 15 Mar 2013 07:41:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGPG5-0001Cp-KR; Fri, 15 Mar 2013 07:40:57 +0000 Received: from [85.158.139.83:42669] by server-10.bemta-5.messagelabs.com id 73/E6-23714-880D2415; Fri, 15 Mar 2013 07:40:56 +0000 X-Env-Sender: digvijaych@gmail.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1363333253!27517595!1 X-Originating-IP: [209.85.215.43] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31404 invoked from network); 15 Mar 2013 07:40:53 -0000 Received: from mail-la0-f43.google.com (HELO mail-la0-f43.google.com) (209.85.215.43) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 07:40:53 -0000 Received: by mail-la0-f43.google.com with SMTP id ek20so3438506lab.16 for ; Fri, 15 Mar 2013 00:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=wlvhdCp+rUflJhoucXdAEQ2NGU65N9XqRMSMk61lwqI=; b=vuQ99jY74wEY3D/cAS7/Zg1AxtujnppTSdqvj3EIM48frMnqUSlrEENMczDyA+rXfM uKbKUDcSoZkWR8c1O+d/4jaY3B1pAYqYsogRb6eJrUbb1hgvWy2TXK4mu1628ChbwslO O1wf6lOoWrwnAOxsFk4RsAT5UnHsa5tHKhZnauOhNyy+vKmGSLwym5PvTtKyYr5G+0Zv FHo+X3ixtIB4Zc2dSpjTh9vwiwR3DVUFfxO0pWInuLube/oeZgQcCL705YQOdFe9iamT xfglE4kGqewmD/vJMzHfdNC1+8v8dNvKzE0z8GD4MBSL0VM2SGivAgOHDKD3yepqt1Sp nfaw== MIME-Version: 1.0 X-Received: by 10.152.144.202 with SMTP id so10mr4895412lab.9.1363333252684; Fri, 15 Mar 2013 00:40:52 -0700 (PDT) Received: by 10.112.101.65 with HTTP; Fri, 15 Mar 2013 00:40:52 -0700 (PDT) Date: Fri, 15 Mar 2013 13:10:52 +0530 Message-ID: From: digvijay chauhan To: xen-users@lists.xen.org, xen-devel@lists.xen.org, xen-devel@lists.xensource.com, Ian Campbell , Christian Limpach Subject: [Xen-users] make tools fail in 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: multipart/mixed; boundary="===============2465238583495386265==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2465238583495386265== Content-Type: multipart/alternative; boundary=e89a8f22bcc33ca18304d7f1c2de --e89a8f22bcc33ca18304d7f1c2de Content-Type: text/plain; charset=ISO-8859-1 Hello, I am trying to install xen4.2 but when ifire make tools command it gives me, Cloning into 'seabios-dir-remote.tmp'... fatal: unable to connect to xenbits.xen.org: xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out make[3]: *** [seabios-dir] Error 128 make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ firmware' make[2]: *** [subdir-install-firmware] Error 2 make[2]: Leaving directory `/home/ce/xen-4.2.0/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/home/ce/xen-4.2.0/tools' make: *** [install-tools] Error 2 so how can i overcome it. regards, DigvijaySingh --e89a8f22bcc33ca18304d7f1c2de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 I am trying to install xen4.2 but when ifire make tools command it give= s me,

Cloning into 'seabios-dir-remote.tmp'...
fatal: una= ble to connect to xenb= its.xen.org:
xenbits.xen.org[0:= 50.57.170.242]: errno=3DConnection timed out

make[3]: *** [seabios-= dir] Error 128
make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/home/ce/xen-4.2.0/tools'
make[1]: *** [= subdirs-install] Error 2
make[1]: Leaving directory `/home/ce/xen-4.2.0/= tools'
make: *** [install-tools] Error 2


so how can i ove= rcome it.

regards,
DigvijaySingh

--e89a8f22bcc33ca18304d7f1c2de-- --===============2465238583495386265== 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 --===============2465238583495386265==-- From xen-users-bounces@lists.xen.org Fri Mar 15 08:20:35 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 08:20: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 1UGPrR-0003Cv-7D; Fri, 15 Mar 2013 08:19:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGPrP-0003Cn-Qa for xen-users@lists.xen.org; Fri, 15 Mar 2013 08:19:32 +0000 Received: from [85.158.143.99:48820] by server-2.bemta-4.messagelabs.com id 87/81-12656-399D2415; Fri, 15 Mar 2013 08:19:31 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363335569!23383081!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8006 invoked from network); 15 Mar 2013 08:19:30 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-12.tower-216.messagelabs.com with SMTP; 15 Mar 2013 08:19:30 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r2F8JQTB019187; Fri, 15 Mar 2013 03:19:26 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r2F8JPGo019186; Fri, 15 Mar 2013 03:19:25 -0500 Date: Fri, 15 Mar 2013 03:19:25 -0500 From: "Dr. Greg Wettstein" Message-Id: <201303150819.r2F8JPGo019186@wind.enjellic.com> In-Reply-To: Sean Greenslade "Re: [Xen-users] xl migrate command - disable ssh" (Mar 13, 9:55pm) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Sean Greenslade , Katerina Mparmpopoulou X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Fri, 15 Mar 2013 03:19:26 -0500 (CDT) Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: greg@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Mar 13, 9:55pm, Sean Greenslade wrote: } Subject: Re: [Xen-users] xl migrate command - disable ssh Good morning, hope the end of the week is going well for everyone. > As I said, you'll first need to get some sort of remote shell > working. My suggestions are for RSH or Telnet, but anything that > can get you a shell will work. Unfortunately, I have absolutely no > experience with either, as I have been raised in an ssh world. In > fact, I use sshfs for remote file shares, and I've never had an > issue with performance bottlenecks even while saturating my gigabit > link. So not that I'm discouraging your academic exploration, but I > would say that in all likelihood, the performance loss of using ssh > is negligible and the security gained is substantial. Just my $0.02. Our group has just spent a fair amount of time working out issues with VM migration on 4.2.1. Using SSH as the transport framework has a number of advantages, modulo the generic security concerns of having to have root access to SSH enabled and having to have root credentials floating around to authenticate the remote shell invocation. We have a setuid wrapper program I should clean up and make available which exec's the 'xl migrate-receive' command. It has all the obvious issues of any setuid program but it does provide the ability to implement a somewhat stronger security architecture. The other issue is that depending on the configuraton of the migration target there may not be a path to the xl command. The following wrapper script is useful for automating migration on the send side: #! /bin/bash exec ssh -C $1 /usr/sbin/xl migrate-receive; The following snippet should be saved in a file named 'xen-migrate' and placed in a directory accessible to the PATH variable of the user requesting migration. Migration of a virtual machine can then be requested with the following command: xl migrate -s xen-migrate DomainID TargetHost Where: DomainID = id of domain to migrate TargetHost = name of host to migrate VM to. The -C switch to ssh requests compression of the data stream which tends to positively impact the transfer rates of the VM image. The other issue is that you have to have a method for making sure the VM disk image is available to both the sender and receiver dom0 environments. NFS will work for a simple setup but if you are a bit crafty and can setup an iSCSI target using a Linux target stack such as SCST the following package allows domU instances to be implemented as first class SAN guests: ftp://ftp.enjellic.com/pub/xen/Xen-SAN-0.1.0.tar.gz The hotplug support implemented in that package will automtically setup and teardown the iSCSI block connections for the guest as part of the migration process. The functionality of this support has been extensively tested with the 4.2.1 Xen release. Hopefully the above is useful to others. VM migration is incredibly useful but does have some generic usability barriers which one has to putz with in order to get everything working. Best wishes for a pleasant weekend to everyone. Greg }-- End of excerpt from Sean Greenslade As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk." -- Bruce Schneier Beyond Fear _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 08:20:35 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 08:20: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 1UGPrR-0003Cv-7D; Fri, 15 Mar 2013 08:19:33 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGPrP-0003Cn-Qa for xen-users@lists.xen.org; Fri, 15 Mar 2013 08:19:32 +0000 Received: from [85.158.143.99:48820] by server-2.bemta-4.messagelabs.com id 87/81-12656-399D2415; Fri, 15 Mar 2013 08:19:31 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363335569!23383081!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8006 invoked from network); 15 Mar 2013 08:19:30 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-12.tower-216.messagelabs.com with SMTP; 15 Mar 2013 08:19:30 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r2F8JQTB019187; Fri, 15 Mar 2013 03:19:26 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r2F8JPGo019186; Fri, 15 Mar 2013 03:19:25 -0500 Date: Fri, 15 Mar 2013 03:19:25 -0500 From: "Dr. Greg Wettstein" Message-Id: <201303150819.r2F8JPGo019186@wind.enjellic.com> In-Reply-To: Sean Greenslade "Re: [Xen-users] xl migrate command - disable ssh" (Mar 13, 9:55pm) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Sean Greenslade , Katerina Mparmpopoulou X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Fri, 15 Mar 2013 03:19:26 -0500 (CDT) Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] xl migrate command - disable ssh X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: greg@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Mar 13, 9:55pm, Sean Greenslade wrote: } Subject: Re: [Xen-users] xl migrate command - disable ssh Good morning, hope the end of the week is going well for everyone. > As I said, you'll first need to get some sort of remote shell > working. My suggestions are for RSH or Telnet, but anything that > can get you a shell will work. Unfortunately, I have absolutely no > experience with either, as I have been raised in an ssh world. In > fact, I use sshfs for remote file shares, and I've never had an > issue with performance bottlenecks even while saturating my gigabit > link. So not that I'm discouraging your academic exploration, but I > would say that in all likelihood, the performance loss of using ssh > is negligible and the security gained is substantial. Just my $0.02. Our group has just spent a fair amount of time working out issues with VM migration on 4.2.1. Using SSH as the transport framework has a number of advantages, modulo the generic security concerns of having to have root access to SSH enabled and having to have root credentials floating around to authenticate the remote shell invocation. We have a setuid wrapper program I should clean up and make available which exec's the 'xl migrate-receive' command. It has all the obvious issues of any setuid program but it does provide the ability to implement a somewhat stronger security architecture. The other issue is that depending on the configuraton of the migration target there may not be a path to the xl command. The following wrapper script is useful for automating migration on the send side: #! /bin/bash exec ssh -C $1 /usr/sbin/xl migrate-receive; The following snippet should be saved in a file named 'xen-migrate' and placed in a directory accessible to the PATH variable of the user requesting migration. Migration of a virtual machine can then be requested with the following command: xl migrate -s xen-migrate DomainID TargetHost Where: DomainID = id of domain to migrate TargetHost = name of host to migrate VM to. The -C switch to ssh requests compression of the data stream which tends to positively impact the transfer rates of the VM image. The other issue is that you have to have a method for making sure the VM disk image is available to both the sender and receiver dom0 environments. NFS will work for a simple setup but if you are a bit crafty and can setup an iSCSI target using a Linux target stack such as SCST the following package allows domU instances to be implemented as first class SAN guests: ftp://ftp.enjellic.com/pub/xen/Xen-SAN-0.1.0.tar.gz The hotplug support implemented in that package will automtically setup and teardown the iSCSI block connections for the guest as part of the migration process. The functionality of this support has been extensively tested with the 4.2.1 Xen release. Hopefully the above is useful to others. VM migration is incredibly useful but does have some generic usability barriers which one has to putz with in order to get everything working. Best wishes for a pleasant weekend to everyone. Greg }-- End of excerpt from Sean Greenslade As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk." -- Bruce Schneier Beyond Fear _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 08:36:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 08:36: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 1UGQ72-0003qv-FS; Fri, 15 Mar 2013 08:35:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGQ71-0003qq-2J for xen-users@lists.xen.org; Fri, 15 Mar 2013 08:35:39 +0000 Received: from [85.158.139.83:19016] by server-11.bemta-5.messagelabs.com id 08/74-27486-A5DD2415; Fri, 15 Mar 2013 08:35:38 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1363336537!26931508!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28097 invoked from network); 15 Mar 2013 08:35:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 08:35:37 -0000 X-IronPort-AV: E=Sophos;i="4.84,849,1355097600"; d="scan'208";a="2540475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Mar 2013 08:35:38 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Fri, 15 Mar 2013 08:35:37 +0000 Message-ID: <5142DD57.4070709@citrix.com> Date: Fri, 15 Mar 2013 09:35:35 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: digvijay chauhan References: In-Reply-To: Cc: "xen-users@lists.xen.org" , Ian Campbell , Christian Limpach Subject: Re: [Xen-users] [Xen-devel] (no subject) X-BeenThere: xen-users@lists.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 15/03/13 08:40, digvijay chauhan wrote: > Hello, > I am trying to install xen4.2 but when ifire make tools > command it gives me, > > Cloning into 'seabios-dir-remote.tmp'... > fatal: unable to connect to xenbits.xen.org : > xenbits.xen.org [0: 50.57.170.242]: > errno=Connection timed out Are you behind a firewall? If so, it is possible that your firewall is blocking git connections, try to append --enable-githttp to configure, that should make git use http and hopefully bypass the firewall. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 08:36:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 08:36: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 1UGQ72-0003qv-FS; Fri, 15 Mar 2013 08:35:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGQ71-0003qq-2J for xen-users@lists.xen.org; Fri, 15 Mar 2013 08:35:39 +0000 Received: from [85.158.139.83:19016] by server-11.bemta-5.messagelabs.com id 08/74-27486-A5DD2415; Fri, 15 Mar 2013 08:35:38 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1363336537!26931508!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28097 invoked from network); 15 Mar 2013 08:35:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 08:35:37 -0000 X-IronPort-AV: E=Sophos;i="4.84,849,1355097600"; d="scan'208";a="2540475" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Mar 2013 08:35:38 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Fri, 15 Mar 2013 08:35:37 +0000 Message-ID: <5142DD57.4070709@citrix.com> Date: Fri, 15 Mar 2013 09:35:35 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: digvijay chauhan References: In-Reply-To: Cc: "xen-users@lists.xen.org" , Ian Campbell , Christian Limpach Subject: Re: [Xen-users] [Xen-devel] (no subject) X-BeenThere: xen-users@lists.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 15/03/13 08:40, digvijay chauhan wrote: > Hello, > I am trying to install xen4.2 but when ifire make tools > command it gives me, > > Cloning into 'seabios-dir-remote.tmp'... > fatal: unable to connect to xenbits.xen.org : > xenbits.xen.org [0: 50.57.170.242]: > errno=Connection timed out Are you behind a firewall? If so, it is possible that your firewall is blocking git connections, try to append --enable-githttp to configure, that should make git use http and hopefully bypass the firewall. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 09:55:13 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 09:55: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 1UGRKv-0005VY-EU; Fri, 15 Mar 2013 09:54:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGRKt-0005VT-NB for xen-users@lists.xen.org; Fri, 15 Mar 2013 09:54:03 +0000 Received: from [85.158.138.51:20639] by server-2.bemta-3.messagelabs.com id D1/F7-05208-ABFE2415; Fri, 15 Mar 2013 09:54:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1363341242!27654253!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19456 invoked from network); 15 Mar 2013 09:54:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 09:54:02 -0000 X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="2543587" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Mar 2013 09:53:50 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Fri, 15 Mar 2013 09:53:50 +0000 Message-ID: <1363341228.32410.297.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dieter Bloms Date: Fri, 15 Mar 2013 09:53:48 +0000 In-Reply-To: <20130314200609.GA9498@bloms.de> References: <20130314200609.GA9498@bloms.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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, 2013-03-14 at 20:06 +0000, Dieter Bloms wrote: > Hi, > > I try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my > pv-grub config doesn't work anymore. > With alpinelinux as dom0 (with xen 4.2.1) I had no problem. > With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error > messages, when I try to start a domU with pv-grub: > http://pastebin.com/PHLQKrsb > > the config file looks like: > http://pastebin.com/jbtEgcnv > > when I change my config to use pygrub, I can start my domU > with this configfile: > http://pastebin.com/RJVerpRA > > Does anybody have a clue what the reason is for pv-grub can not be used ? The most obvious answer is in the first log, which shows pv-grub crashing: Booting 'Xen -- openSUSE 12.2 - 3.4.11-2.16' root (hd0) Filesystem type is ext2fs, using whole disk kernel /boot/vmlinuz-xen root=/dev/xvda1 console=xvc0 independent_wallclock=1 s plash=silent quiet showopts initrd /boot/initrd-xen Page fault at linear address 0x7f50277fe728, rip 0x40c0b, regs 0xe6f768, sp 0xe6f818, our_sp 0xe6f730, code 0 Thread: main RIP: e030:[<0000000000040c0b>] RSP: e02b:0000000000e6f818 EFLAGS: 00010206 RAX: 00000000001bef44 RBX: 0000002031003e30 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000e6fd08 R08: 0000002031003e30 R09: 0000000000000000 R10: 0000000000000e74 R11: 000000000000027f R12: 00000000000bdc8e R13: 0000002031003e90 R14: 0000000000b6ca88 R15: 0000002030003e20 base is 0xe6fd08 caller is 0x40eeb base is 0xe6fd18 caller is 0x18c63 base is 0xe6fd98 caller is 0x3be0 base is 0xe6fda8 caller is 0x8fc3 base is 0xe6fdc8 caller is 0xabd9 base is 0xe6fe08 caller is 0x1063a base is 0xe6fea8 caller is 0x10d46 base is 0xe6ff48 caller is 0x43ee base is 0xe6ff58 caller is 0x562fa base is 0xe6ffe8 caller is 0x33da Do you also get any logs on the Xen console? Particularly if you increase the guest log lvl on the hypervisor command line? Can you use addr2line on the pv-grub binary to convert the RIP addresses and "caller is" addresses into meaningful line numbers please. Were you using the exact same guest configuration file on SuSE? Was the guest image (in particular the kernel) identical? Did you build Xen 4.2.1 yourself on opensuse or did you get it from packages? Was it patched from pristine upstream Xen 4.2.1 at all? Likewise in the alpine Linux case. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 09:55:13 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 09:55: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 1UGRKv-0005VY-EU; Fri, 15 Mar 2013 09:54:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGRKt-0005VT-NB for xen-users@lists.xen.org; Fri, 15 Mar 2013 09:54:03 +0000 Received: from [85.158.138.51:20639] by server-2.bemta-3.messagelabs.com id D1/F7-05208-ABFE2415; Fri, 15 Mar 2013 09:54:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1363341242!27654253!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19456 invoked from network); 15 Mar 2013 09:54:02 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 09:54:02 -0000 X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="2543587" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Mar 2013 09:53:50 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Fri, 15 Mar 2013 09:53:50 +0000 Message-ID: <1363341228.32410.297.camel@zakaz.uk.xensource.com> From: Ian Campbell To: Dieter Bloms Date: Fri, 15 Mar 2013 09:53:48 +0000 In-Reply-To: <20130314200609.GA9498@bloms.de> References: <20130314200609.GA9498@bloms.de> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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, 2013-03-14 at 20:06 +0000, Dieter Bloms wrote: > Hi, > > I try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my > pv-grub config doesn't work anymore. > With alpinelinux as dom0 (with xen 4.2.1) I had no problem. > With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error > messages, when I try to start a domU with pv-grub: > http://pastebin.com/PHLQKrsb > > the config file looks like: > http://pastebin.com/jbtEgcnv > > when I change my config to use pygrub, I can start my domU > with this configfile: > http://pastebin.com/RJVerpRA > > Does anybody have a clue what the reason is for pv-grub can not be used ? The most obvious answer is in the first log, which shows pv-grub crashing: Booting 'Xen -- openSUSE 12.2 - 3.4.11-2.16' root (hd0) Filesystem type is ext2fs, using whole disk kernel /boot/vmlinuz-xen root=/dev/xvda1 console=xvc0 independent_wallclock=1 s plash=silent quiet showopts initrd /boot/initrd-xen Page fault at linear address 0x7f50277fe728, rip 0x40c0b, regs 0xe6f768, sp 0xe6f818, our_sp 0xe6f730, code 0 Thread: main RIP: e030:[<0000000000040c0b>] RSP: e02b:0000000000e6f818 EFLAGS: 00010206 RAX: 00000000001bef44 RBX: 0000002031003e30 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000e6fd08 R08: 0000002031003e30 R09: 0000000000000000 R10: 0000000000000e74 R11: 000000000000027f R12: 00000000000bdc8e R13: 0000002031003e90 R14: 0000000000b6ca88 R15: 0000002030003e20 base is 0xe6fd08 caller is 0x40eeb base is 0xe6fd18 caller is 0x18c63 base is 0xe6fd98 caller is 0x3be0 base is 0xe6fda8 caller is 0x8fc3 base is 0xe6fdc8 caller is 0xabd9 base is 0xe6fe08 caller is 0x1063a base is 0xe6fea8 caller is 0x10d46 base is 0xe6ff48 caller is 0x43ee base is 0xe6ff58 caller is 0x562fa base is 0xe6ffe8 caller is 0x33da Do you also get any logs on the Xen console? Particularly if you increase the guest log lvl on the hypervisor command line? Can you use addr2line on the pv-grub binary to convert the RIP addresses and "caller is" addresses into meaningful line numbers please. Were you using the exact same guest configuration file on SuSE? Was the guest image (in particular the kernel) identical? Did you build Xen 4.2.1 yourself on opensuse or did you get it from packages? Was it patched from pristine upstream Xen 4.2.1 at all? Likewise in the alpine Linux case. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 10:06:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 10:06: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 1UGRW6-00062W-Ol; Fri, 15 Mar 2013 10:05:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGRW5-00062E-4u; Fri, 15 Mar 2013 10:05:37 +0000 Received: from [193.109.254.147:14408] by server-4.bemta-14.messagelabs.com id 51/F1-17387-072F2415; Fri, 15 Mar 2013 10:05:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1363341577!2142840!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25800 invoked from network); 15 Mar 2013 09:59:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 09:59:37 -0000 X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="2543894" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Mar 2013 09:59:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Fri, 15 Mar 2013 09:59:37 +0000 Message-ID: <1363341575.32410.301.camel@zakaz.uk.xensource.com> From: Ian Campbell To: digvijay chauhan Date: Fri, 15 Mar 2013 09:59:35 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , Christian Limpach , "xen-devel@lists.xensource.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] (no subject) X-BeenThere: xen-users@lists.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 Digvijay, You have cross posted this message to multiple lists I have already asked you not to do this on at least one occasion. You have also CCd various people, including myself, seemingly at random, *and* posted the same message three times in quick succession. Please stop this antisocial behaviour. Post to a single list (xen-users@ in the common case for the sorts of questions you are asking) and wait a reasonable amount of time (i.e. measured in days) for a response before pinging. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 10:06:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 10:06: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 1UGRW6-00062W-Ol; Fri, 15 Mar 2013 10:05:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGRW5-00062E-4u; Fri, 15 Mar 2013 10:05:37 +0000 Received: from [193.109.254.147:14408] by server-4.bemta-14.messagelabs.com id 51/F1-17387-072F2415; Fri, 15 Mar 2013 10:05:36 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1363341577!2142840!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25800 invoked from network); 15 Mar 2013 09:59:37 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 09:59:37 -0000 X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="2543894" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Mar 2013 09:59:37 +0000 Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Fri, 15 Mar 2013 09:59:37 +0000 Message-ID: <1363341575.32410.301.camel@zakaz.uk.xensource.com> From: Ian Campbell To: digvijay chauhan Date: Fri, 15 Mar 2013 09:59:35 +0000 In-Reply-To: References: Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-1 MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , Christian Limpach , "xen-devel@lists.xensource.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] (no subject) X-BeenThere: xen-users@lists.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 Digvijay, You have cross posted this message to multiple lists I have already asked you not to do this on at least one occasion. You have also CCd various people, including myself, seemingly at random, *and* posted the same message three times in quick succession. Please stop this antisocial behaviour. Post to a single list (xen-users@ in the common case for the sorts of questions you are asking) and wait a reasonable amount of time (i.e. measured in days) for a response before pinging. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 11:19:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 11:19: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 1UGSej-00080P-QB; Fri, 15 Mar 2013 11:18:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGSeh-0007zz-Lp; Fri, 15 Mar 2013 11:18:35 +0000 Received: from [85.158.139.211:14684] by server-13.bemta-5.messagelabs.com id 24/63-16871-A8303415; Fri, 15 Mar 2013 11:18:34 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-3.tower-206.messagelabs.com!1363346313!18418615!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzM1NzU=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12068 invoked from network); 15 Mar 2013 11:18:34 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2013 11:18:34 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 1878027E4; Fri, 15 Mar 2013 13:18:33 +0200 (EET) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 845872006E; Fri, 15 Mar 2013 13:18:32 +0200 (EET) Date: Fri, 15 Mar 2013 13:18:32 +0200 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: digvijay chauhan Message-ID: <20130315111831.GY8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-users@lists.xen.org, Christian Limpach , xen-devel@lists.xensource.com, Ian Campbell , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] (no subject) X-BeenThere: xen-users@lists.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, Mar 15, 2013 at 01:10:02PM +0530, digvijay chauhan wrote: > Hello, > I am trying to install xen4.2 but when ifire make tools > command it gives me, > > Cloning into 'seabios-dir-remote.tmp'... > fatal: unable to connect to [1]xenbits.xen.org: > [2]xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out > So maybe your firewall is blocking the connection? -- Pasi > make[3]: *** [seabios-dir] Error 128 > make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ > firmware' > make[2]: *** [subdir-install-firmware] Error 2 > make[2]: Leaving directory `/home/ce/xen-4.2.0/tools' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/home/ce/xen-4.2.0/tools' > make: *** [install-tools] Error 2 > > so how can i overcome it. > > regards, > DigvijaySingh > > References > > Visible links > 1. http://xenbits.xen.org/ > 2. http://xenbits.xen.org/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 11:19:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 11:19: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 1UGSej-00080P-QB; Fri, 15 Mar 2013 11:18:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGSeh-0007zz-Lp; Fri, 15 Mar 2013 11:18:35 +0000 Received: from [85.158.139.211:14684] by server-13.bemta-5.messagelabs.com id 24/63-16871-A8303415; Fri, 15 Mar 2013 11:18:34 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-3.tower-206.messagelabs.com!1363346313!18418615!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzM1NzU=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12068 invoked from network); 15 Mar 2013 11:18:34 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2013 11:18:34 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 1878027E4; Fri, 15 Mar 2013 13:18:33 +0200 (EET) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 845872006E; Fri, 15 Mar 2013 13:18:32 +0200 (EET) Date: Fri, 15 Mar 2013 13:18:32 +0200 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: digvijay chauhan Message-ID: <20130315111831.GY8912@reaktio.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: xen-users@lists.xen.org, Christian Limpach , xen-devel@lists.xensource.com, Ian Campbell , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] (no subject) X-BeenThere: xen-users@lists.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, Mar 15, 2013 at 01:10:02PM +0530, digvijay chauhan wrote: > Hello, > I am trying to install xen4.2 but when ifire make tools > command it gives me, > > Cloning into 'seabios-dir-remote.tmp'... > fatal: unable to connect to [1]xenbits.xen.org: > [2]xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out > So maybe your firewall is blocking the connection? -- Pasi > make[3]: *** [seabios-dir] Error 128 > make[3]: Leaving directory `/home/ce/xen-4.2.0/tools/ > firmware' > make[2]: *** [subdir-install-firmware] Error 2 > make[2]: Leaving directory `/home/ce/xen-4.2.0/tools' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/home/ce/xen-4.2.0/tools' > make: *** [install-tools] Error 2 > > so how can i overcome it. > > regards, > DigvijaySingh > > References > > Visible links > 1. http://xenbits.xen.org/ > 2. http://xenbits.xen.org/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 11:45:18 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 11: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 1UGT3e-0001S0-6P; Fri, 15 Mar 2013 11:44:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGT3Z-0001RR-Mm for xen-users@lists.xen.org; Fri, 15 Mar 2013 11:44:20 +0000 Received: from [85.158.138.51:58551] by server-3.bemta-3.messagelabs.com id FF/A8-26934-09903415; Fri, 15 Mar 2013 11:44:16 +0000 X-Env-Sender: dieter@bloms.de X-Msg-Ref: server-15.tower-174.messagelabs.com!1363347855!26013349!1 X-Originating-IP: [84.200.248.35] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27786 invoked from network); 15 Mar 2013 11:44:16 -0000 Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2013 11:44:16 -0000 Received: from smtp.bloms.de (localhost [127.0.0.1]) by smtp.bloms.de (Postfix) with ESMTP id 520A240320; Fri, 15 Mar 2013 12:44:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=TK60x6oN7EzfLDIBLcpnCgDlZ/c=; b=Y1 1JuWZo26JgftsNSRTg1fq75eY6sa/nJXPjbw9HSsaIXHvAlADtr+EMUZXe4UGurJ +khL5oMLUZoUUbWYXF1OKH5NTFprbOo7dLXeaiaNGnncd9Cn7GiXvVG5StVuTf+Z y3XSiCE0A+c9xc9m+sWvZQjIo0XoMFuo+Gd9vARPXOMbVubkTo0jd1qPfmcEIJyc h1CH46tKtm1AJhRKB9oIGFz3RxKAmmXRv8+V8RrASax7V0iIgIRGm/2sYYa6tbwg HxobCbCArOzL77vrMqEs1cH56UYsAS54QDGU1RtIGPmoROqtrzC5xg5lB76K81Mh A0ROuLJ4hFB4ZDWg1U+6YZ00RMDP6PEmHjZySsmn2iH4DmMTHa5X+gneQu+3cP/D GPXiGALPey4tmR3iaOWGHRydWYVGYNzBUqrJZyCQsaFncLswwd5SJ5+S3EB40Nur /ePlbJZuGbZwoIey3aXEiEtS/WDoFUQvyANZ9zpAkOssysLxHPAkgPGgRF3jEzwg BPFXwO9NmgrySiC0L6qfznj3T4W6qncCKRbY3RPB5q/oajlUaSpujzc5BedqvrYs GPqVydI7KpbV+MxWOyHifPLwGfBNhQbr3R5TWZ1WZgjFZG0yySwiFCmaTANx6QDj zhOr6HfwKtG6JCaVNY/0XoVG2DKJuqKYpOTxlmTvM= Received: by smtp.bloms.de (Postfix, from userid 1000) id 2684240546; Fri, 15 Mar 2013 12:44:15 +0100 (CET) Date: Fri, 15 Mar 2013 12:44:15 +0100 From: Dieter Bloms To: Ian Campbell Message-ID: <20130315114414.GB14228@bloms.de> References: <20130314200609.GA9498@bloms.de> <1363341228.32410.297.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1363341228.32410.297.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-users@lists.xen.org" , Dieter Bloms Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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 Fri, Mar 15, Ian Campbell wrote: > On Thu, 2013-03-14 at 20:06 +0000, Dieter Bloms wrote: > > Hi, > > > > I try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my > > pv-grub config doesn't work anymore. > > With alpinelinux as dom0 (with xen 4.2.1) I had no problem. > > With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error > > messages, when I try to start a domU with pv-grub: > > http://pastebin.com/PHLQKrsb > > > > the config file looks like: > > http://pastebin.com/jbtEgcnv > > > > when I change my config to use pygrub, I can start my domU > > with this configfile: > > http://pastebin.com/RJVerpRA > > > > Does anybody have a clue what the reason is for pv-grub can not be used ? > > The most obvious answer is in the first log, which shows pv-grub > crashing: > > > Booting 'Xen -- openSUSE 12.2 - 3.4.11-2.16' > > root (hd0) > Filesystem type is ext2fs, using whole disk > kernel /boot/vmlinuz-xen root=/dev/xvda1 console=xvc0 independent_wallclock=1 s > plash=silent quiet showopts > initrd /boot/initrd-xen > > Page fault at linear address 0x7f50277fe728, rip 0x40c0b, regs 0xe6f768, sp 0xe6f818, our_sp 0xe6f730, code 0 > Thread: main > RIP: e030:[<0000000000040c0b>] > RSP: e02b:0000000000e6f818 EFLAGS: 00010206 > RAX: 00000000001bef44 RBX: 0000002031003e30 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 > RBP: 0000000000e6fd08 R08: 0000002031003e30 R09: 0000000000000000 > R10: 0000000000000e74 R11: 000000000000027f R12: 00000000000bdc8e > R13: 0000002031003e90 R14: 0000000000b6ca88 R15: 0000002030003e20 > base is 0xe6fd08 caller is 0x40eeb > base is 0xe6fd18 caller is 0x18c63 > base is 0xe6fd98 caller is 0x3be0 > base is 0xe6fda8 caller is 0x8fc3 > base is 0xe6fdc8 caller is 0xabd9 > base is 0xe6fe08 caller is 0x1063a > base is 0xe6fea8 caller is 0x10d46 > base is 0xe6ff48 caller is 0x43ee > base is 0xe6ff58 caller is 0x562fa > base is 0xe6ffe8 caller is 0x33da > > Do you also get any logs on the Xen console? Particularly if you > increase the guest log lvl on the hypervisor command line? no, I see nothing. My command line for xen hypervisor ist: --snip-- xen:~ # xl info |grep xen_commandline xen_commandline : dom0_mem=1024M,max:1024M sched=credit sched_credit_tslice_ms=3 sched_ratelimit_us=300 loglvl=all guest_loglvl=all --snip-- > Can you use addr2line on the pv-grub binary to convert the RIP addresses > and "caller is" addresses into meaningful line numbers please. How can I do that ? > Were you using the exact same guest configuration file on SuSE? Was the > guest image (in particular the kernel) identical? yes, my config is exact the same (copied it from my alpinelinux instance) and the images are the same (because, I use the same (old) disc). > Did you build Xen 4.2.1 yourself on opensuse or did you get it from > packages? Was it patched from pristine upstream Xen 4.2.1 at all? > Likewise in the alpine Linux case. I use xen as shipped with both distributions -- Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 11:45:18 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 11: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 1UGT3e-0001S0-6P; Fri, 15 Mar 2013 11:44:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGT3Z-0001RR-Mm for xen-users@lists.xen.org; Fri, 15 Mar 2013 11:44:20 +0000 Received: from [85.158.138.51:58551] by server-3.bemta-3.messagelabs.com id FF/A8-26934-09903415; Fri, 15 Mar 2013 11:44:16 +0000 X-Env-Sender: dieter@bloms.de X-Msg-Ref: server-15.tower-174.messagelabs.com!1363347855!26013349!1 X-Originating-IP: [84.200.248.35] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27786 invoked from network); 15 Mar 2013 11:44:16 -0000 Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35) by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2013 11:44:16 -0000 Received: from smtp.bloms.de (localhost [127.0.0.1]) by smtp.bloms.de (Postfix) with ESMTP id 520A240320; Fri, 15 Mar 2013 12:44:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=TK60x6oN7EzfLDIBLcpnCgDlZ/c=; b=Y1 1JuWZo26JgftsNSRTg1fq75eY6sa/nJXPjbw9HSsaIXHvAlADtr+EMUZXe4UGurJ +khL5oMLUZoUUbWYXF1OKH5NTFprbOo7dLXeaiaNGnncd9Cn7GiXvVG5StVuTf+Z y3XSiCE0A+c9xc9m+sWvZQjIo0XoMFuo+Gd9vARPXOMbVubkTo0jd1qPfmcEIJyc h1CH46tKtm1AJhRKB9oIGFz3RxKAmmXRv8+V8RrASax7V0iIgIRGm/2sYYa6tbwg HxobCbCArOzL77vrMqEs1cH56UYsAS54QDGU1RtIGPmoROqtrzC5xg5lB76K81Mh A0ROuLJ4hFB4ZDWg1U+6YZ00RMDP6PEmHjZySsmn2iH4DmMTHa5X+gneQu+3cP/D GPXiGALPey4tmR3iaOWGHRydWYVGYNzBUqrJZyCQsaFncLswwd5SJ5+S3EB40Nur /ePlbJZuGbZwoIey3aXEiEtS/WDoFUQvyANZ9zpAkOssysLxHPAkgPGgRF3jEzwg BPFXwO9NmgrySiC0L6qfznj3T4W6qncCKRbY3RPB5q/oajlUaSpujzc5BedqvrYs GPqVydI7KpbV+MxWOyHifPLwGfBNhQbr3R5TWZ1WZgjFZG0yySwiFCmaTANx6QDj zhOr6HfwKtG6JCaVNY/0XoVG2DKJuqKYpOTxlmTvM= Received: by smtp.bloms.de (Postfix, from userid 1000) id 2684240546; Fri, 15 Mar 2013 12:44:15 +0100 (CET) Date: Fri, 15 Mar 2013 12:44:15 +0100 From: Dieter Bloms To: Ian Campbell Message-ID: <20130315114414.GB14228@bloms.de> References: <20130314200609.GA9498@bloms.de> <1363341228.32410.297.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1363341228.32410.297.camel@zakaz.uk.xensource.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-users@lists.xen.org" , Dieter Bloms Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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 Fri, Mar 15, Ian Campbell wrote: > On Thu, 2013-03-14 at 20:06 +0000, Dieter Bloms wrote: > > Hi, > > > > I try to migrate my dom0 from alpinelinux to opensuse 12.3 and now my > > pv-grub config doesn't work anymore. > > With alpinelinux as dom0 (with xen 4.2.1) I had no problem. > > With opensuse 12.3 as dom0 (with xen 4.2.1) I get the follwing error > > messages, when I try to start a domU with pv-grub: > > http://pastebin.com/PHLQKrsb > > > > the config file looks like: > > http://pastebin.com/jbtEgcnv > > > > when I change my config to use pygrub, I can start my domU > > with this configfile: > > http://pastebin.com/RJVerpRA > > > > Does anybody have a clue what the reason is for pv-grub can not be used ? > > The most obvious answer is in the first log, which shows pv-grub > crashing: > > > Booting 'Xen -- openSUSE 12.2 - 3.4.11-2.16' > > root (hd0) > Filesystem type is ext2fs, using whole disk > kernel /boot/vmlinuz-xen root=/dev/xvda1 console=xvc0 independent_wallclock=1 s > plash=silent quiet showopts > initrd /boot/initrd-xen > > Page fault at linear address 0x7f50277fe728, rip 0x40c0b, regs 0xe6f768, sp 0xe6f818, our_sp 0xe6f730, code 0 > Thread: main > RIP: e030:[<0000000000040c0b>] > RSP: e02b:0000000000e6f818 EFLAGS: 00010206 > RAX: 00000000001bef44 RBX: 0000002031003e30 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 > RBP: 0000000000e6fd08 R08: 0000002031003e30 R09: 0000000000000000 > R10: 0000000000000e74 R11: 000000000000027f R12: 00000000000bdc8e > R13: 0000002031003e90 R14: 0000000000b6ca88 R15: 0000002030003e20 > base is 0xe6fd08 caller is 0x40eeb > base is 0xe6fd18 caller is 0x18c63 > base is 0xe6fd98 caller is 0x3be0 > base is 0xe6fda8 caller is 0x8fc3 > base is 0xe6fdc8 caller is 0xabd9 > base is 0xe6fe08 caller is 0x1063a > base is 0xe6fea8 caller is 0x10d46 > base is 0xe6ff48 caller is 0x43ee > base is 0xe6ff58 caller is 0x562fa > base is 0xe6ffe8 caller is 0x33da > > Do you also get any logs on the Xen console? Particularly if you > increase the guest log lvl on the hypervisor command line? no, I see nothing. My command line for xen hypervisor ist: --snip-- xen:~ # xl info |grep xen_commandline xen_commandline : dom0_mem=1024M,max:1024M sched=credit sched_credit_tslice_ms=3 sched_ratelimit_us=300 loglvl=all guest_loglvl=all --snip-- > Can you use addr2line on the pv-grub binary to convert the RIP addresses > and "caller is" addresses into meaningful line numbers please. How can I do that ? > Were you using the exact same guest configuration file on SuSE? Was the > guest image (in particular the kernel) identical? yes, my config is exact the same (copied it from my alpinelinux instance) and the images are the same (because, I use the same (old) disc). > Did you build Xen 4.2.1 yourself on opensuse or did you get it from > packages? Was it patched from pristine upstream Xen 4.2.1 at all? > Likewise in the alpine Linux case. I use xen as shipped with both distributions -- Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 12:14:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 12:14: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 1UGTW2-0003Ed-LR; Fri, 15 Mar 2013 12:13:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGTW0-0003EX-QR for xen-users@lists.xen.org; Fri, 15 Mar 2013 12:13:40 +0000 Received: from [85.158.139.83:57662] by server-4.bemta-5.messagelabs.com id 00/57-01980-47013415; Fri, 15 Mar 2013 12:13:40 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1363349619!27570646!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14398 invoked from network); 15 Mar 2013 12:13:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 12:13:39 -0000 X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="2549329" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Mar 2013 12:13:40 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Fri, 15 Mar 2013 12:13:39 +0000 Message-ID: <51431072.2080009@citrix.com> Date: Fri, 15 Mar 2013 13:13:38 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ian Campbell References: <20130314200609.GA9498@bloms.de> <1363341228.32410.297.camel@zakaz.uk.xensource.com> In-Reply-To: <1363341228.32410.297.camel@zakaz.uk.xensource.com> Cc: "xen-users@lists.xen.org" , Dieter Bloms Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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 15/03/13 10:53, Ian Campbell wrote: > Did you build Xen 4.2.1 yourself on opensuse or did you get it from > packages? Was it patched from pristine upstream Xen 4.2.1 at all? > Likewise in the alpine Linux case. Xen in Alpine is mostly pristine, with a few added patches to make Qemu play nice with uclibc, but stubdomains are not patched at all. Patches applied and build process can be found here: http://git.alpinelinux.org/cgit/aports/tree/main/xen _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 12:14:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 12:14: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 1UGTW2-0003Ed-LR; Fri, 15 Mar 2013 12:13:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGTW0-0003EX-QR for xen-users@lists.xen.org; Fri, 15 Mar 2013 12:13:40 +0000 Received: from [85.158.139.83:57662] by server-4.bemta-5.messagelabs.com id 00/57-01980-47013415; Fri, 15 Mar 2013 12:13:40 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1363349619!27570646!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14398 invoked from network); 15 Mar 2013 12:13:39 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2013 12:13:39 -0000 X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="2549329" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 15 Mar 2013 12:13:40 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Fri, 15 Mar 2013 12:13:39 +0000 Message-ID: <51431072.2080009@citrix.com> Date: Fri, 15 Mar 2013 13:13:38 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ian Campbell References: <20130314200609.GA9498@bloms.de> <1363341228.32410.297.camel@zakaz.uk.xensource.com> In-Reply-To: <1363341228.32410.297.camel@zakaz.uk.xensource.com> Cc: "xen-users@lists.xen.org" , Dieter Bloms Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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 15/03/13 10:53, Ian Campbell wrote: > Did you build Xen 4.2.1 yourself on opensuse or did you get it from > packages? Was it patched from pristine upstream Xen 4.2.1 at all? > Likewise in the alpine Linux case. Xen in Alpine is mostly pristine, with a few added patches to make Qemu play nice with uclibc, but stubdomains are not patched at all. Patches applied and build process can be found here: http://git.alpinelinux.org/cgit/aports/tree/main/xen _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 15:53:55 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 15:53: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 1UGWw9-0005Jk-Cv; Fri, 15 Mar 2013 15:52:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGWw7-0005Jf-K3 for xen-users@lists.xen.org; Fri, 15 Mar 2013 15:52:52 +0000 Received: from [85.158.139.83:35493] by server-9.bemta-5.messagelabs.com id 24/3F-08547-2D343415; Fri, 15 Mar 2013 15:52:50 +0000 X-Env-Sender: dieter@bloms.de X-Msg-Ref: server-13.tower-182.messagelabs.com!1363362770!27172986!1 X-Originating-IP: [84.200.248.35] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8327 invoked from network); 15 Mar 2013 15:52:50 -0000 Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2013 15:52:50 -0000 Received: from smtp.bloms.de (localhost [127.0.0.1]) by smtp.bloms.de (Postfix) with ESMTP id CB86040320; Fri, 15 Mar 2013 16:52:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :content-transfer-encoding:in-reply-to; s=selector1; bh=1a/ADkc1 Ryi7qvpvowKVAAmNpCs=; b=yUoh+KNGfVgid5v2pgkQxJetc4TsuRdJPI0s69OV cuuNZjXKehxqBlRE96bQYgTmn5hcJUDO8JNrqfu5V83k8IodELprc0xAVFMhjWx5 HNRAUF4v8DAL3VFAQRT4xKrluKfzWSXAgWNdSNpsulgJJrSxmoNmuJa5TDzbjBOq 9Mdgw8fFCV0AvLnKArwIdy+9Mbl/iutvSLAcTSp0eDk9mjHNXq2M0FG/KaHE1JLH hKwgKDUslbZ4bEIcc/iLqiDiPg5cOqHE5TStbHnGI4J9VRuhuZ04xf+qevb7noAS 729tTqqFV7o+3Rj9Xs7TfMSSlumPOmti0B2K5X+iGO9rtx3RVnoRy6wFV726MFNS yldbKZgjAiDmCX9TdRAKmJ1AaGZmWNcmiXqFk3mmlIaHP0BX/AIrLoCEQ5kd0n6y yqKdgl9ZH0NaLBcda07Qh1B+OA8WjzoevrCKyISO+2n9jXBAFqvOFW8RCWW9pfXP nnWGYMDVRZp/nNLyzHhqpFLuA/wiUtHOvXr6KKKIPv9hNUhTnXJcbtRqCfUD9HqK 0Auwzt6X1Sq7hxne2Dr5srV+Pj5NFq12flhTOt5DL1byuwag17uXFTwntQg79ktD ykG1PiKYDOy3L0BvjxqC0HQJHLyP+188gcrg5qAktNhaIlr6ckfGSLspyGYlEw22 7ww= Received: by smtp.bloms.de (Postfix, from userid 1000) id AB9DC40546; Fri, 15 Mar 2013 16:52:49 +0100 (CET) Date: Fri, 15 Mar 2013 16:52:49 +0100 From: Dieter Bloms To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20130315155249.GA15014@bloms.de> References: <20130314200609.GA9498@bloms.de> <1363341228.32410.297.camel@zakaz.uk.xensource.com> <51431072.2080009@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51431072.2080009@citrix.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-users@lists.xen.org" , Dieter Bloms , Ian Campbell Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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, On Fri, Mar 15, Roger Pau Monn=E9 wrote: > Xen in Alpine is mostly pristine, with a few added patches to make Qemu > play nice with uclibc, but stubdomains are not patched at all. Patches > applied and build process can be found here: > = > http://git.alpinelinux.org/cgit/aports/tree/main/xen I've opened a bugreport for the opensuse distribution. -- = Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 15:53:55 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 15:53: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 1UGWw9-0005Jk-Cv; Fri, 15 Mar 2013 15:52:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGWw7-0005Jf-K3 for xen-users@lists.xen.org; Fri, 15 Mar 2013 15:52:52 +0000 Received: from [85.158.139.83:35493] by server-9.bemta-5.messagelabs.com id 24/3F-08547-2D343415; Fri, 15 Mar 2013 15:52:50 +0000 X-Env-Sender: dieter@bloms.de X-Msg-Ref: server-13.tower-182.messagelabs.com!1363362770!27172986!1 X-Originating-IP: [84.200.248.35] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8327 invoked from network); 15 Mar 2013 15:52:50 -0000 Received: from smtp.bloms.de (HELO smtp.bloms.de) (84.200.248.35) by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2013 15:52:50 -0000 Received: from smtp.bloms.de (localhost [127.0.0.1]) by smtp.bloms.de (Postfix) with ESMTP id CB86040320; Fri, 15 Mar 2013 16:52:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bloms.de; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :content-transfer-encoding:in-reply-to; s=selector1; bh=1a/ADkc1 Ryi7qvpvowKVAAmNpCs=; b=yUoh+KNGfVgid5v2pgkQxJetc4TsuRdJPI0s69OV cuuNZjXKehxqBlRE96bQYgTmn5hcJUDO8JNrqfu5V83k8IodELprc0xAVFMhjWx5 HNRAUF4v8DAL3VFAQRT4xKrluKfzWSXAgWNdSNpsulgJJrSxmoNmuJa5TDzbjBOq 9Mdgw8fFCV0AvLnKArwIdy+9Mbl/iutvSLAcTSp0eDk9mjHNXq2M0FG/KaHE1JLH hKwgKDUslbZ4bEIcc/iLqiDiPg5cOqHE5TStbHnGI4J9VRuhuZ04xf+qevb7noAS 729tTqqFV7o+3Rj9Xs7TfMSSlumPOmti0B2K5X+iGO9rtx3RVnoRy6wFV726MFNS yldbKZgjAiDmCX9TdRAKmJ1AaGZmWNcmiXqFk3mmlIaHP0BX/AIrLoCEQ5kd0n6y yqKdgl9ZH0NaLBcda07Qh1B+OA8WjzoevrCKyISO+2n9jXBAFqvOFW8RCWW9pfXP nnWGYMDVRZp/nNLyzHhqpFLuA/wiUtHOvXr6KKKIPv9hNUhTnXJcbtRqCfUD9HqK 0Auwzt6X1Sq7hxne2Dr5srV+Pj5NFq12flhTOt5DL1byuwag17uXFTwntQg79ktD ykG1PiKYDOy3L0BvjxqC0HQJHLyP+188gcrg5qAktNhaIlr6ckfGSLspyGYlEw22 7ww= Received: by smtp.bloms.de (Postfix, from userid 1000) id AB9DC40546; Fri, 15 Mar 2013 16:52:49 +0100 (CET) Date: Fri, 15 Mar 2013 16:52:49 +0100 From: Dieter Bloms To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20130315155249.GA15014@bloms.de> References: <20130314200609.GA9498@bloms.de> <1363341228.32410.297.camel@zakaz.uk.xensource.com> <51431072.2080009@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51431072.2080009@citrix.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-users@lists.xen.org" , Dieter Bloms , Ian Campbell Subject: Re: [Xen-users] pv-grub doesn't work with opensuse 12.3 (Page fault at linear address 0x7f50277fe728) X-BeenThere: xen-users@lists.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, On Fri, Mar 15, Roger Pau Monn=E9 wrote: > Xen in Alpine is mostly pristine, with a few added patches to make Qemu > play nice with uclibc, but stubdomains are not patched at all. Patches > applied and build process can be found here: > = > http://git.alpinelinux.org/cgit/aports/tree/main/xen I've opened a bugreport for the opensuse distribution. -- = Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 22:30:56 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 22: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 1UGd7l-0001y4-Lr; Fri, 15 Mar 2013 22:29:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGbGs-0007sF-SB; Fri, 15 Mar 2013 20:30:35 +0000 Received: from [85.158.138.51:36899] by server-6.bemta-3.messagelabs.com id 7E/AD-11048-9E483415; Fri, 15 Mar 2013 20:30:33 +0000 X-Env-Sender: Matthew.Fioravante@jhuapl.edu X-Msg-Ref: server-14.tower-174.messagelabs.com!1363379430!21491548!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17333 invoked from network); 15 Mar 2013 20:30:32 -0000 Received: from piper.jhuapl.edu (HELO piper.jhuapl.edu) (128.244.251.37) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2013 20:30:32 -0000 Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 706a_936a_969ead2f_5df8_4b9e_b4ba_32a9402f1974; Fri, 15 Mar 2013 16:30:26 -0400 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 15 Mar 2013 16:29:27 -0400 From: "Fioravante, Matthew E." To: tech mailinglists , xen-users , "xen-devel@lists.xen.org" Date: Fri, 15 Mar 2013 16:29:26 -0400 Thread-Topic: [Xen-devel] Actual method to compile Xen with vtpm on Linux and NetBSD Thread-Index: Ac4YmfJBN7zAAx4JSW+raW1m5fVa3AJIbLNA Message-ID: <068F06DC4D106941B297C0C5F9F446EA4921744189@aplesstripe.dom1.jhuapl.edu> References: <5134324F.6060300@gmail.com> In-Reply-To: <5134324F.6060300@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 15 Mar 2013 22:29:16 +0000 Subject: Re: [Xen-users] [Xen-devel] Actual method to compile Xen with vtpm on Linux and NetBSD X-BeenThere: xen-users@lists.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 vTPM has not been tested on NetBSD and not officially supported. You would mostly be on your own for getting it to work but if you are up to the task feel free to submit patches . > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of tech mailinglists > Sent: Monday, March 04, 2013 12:34 AM > To: xen-users; xen-devel@lists.xen.org > Subject: [Xen-devel] Actual method to compile Xen with vtpm on Linux and > NetBSD > > Hello all, > > I have a question about the implementation of vTPM in Xen. I want to setup > vTPM in the next time on my Xen infrastructure and so I read a little bit about it. > I actually have compiled Xen with the configure option --enable-vtpm. > > I read that this option is more or less "deprecated" and I was never able to > compile Xen with vTPM on NetBSD because of the fact that libgmp seems to be > not available on NetBSD. > > So I have two question about this: > > Is --enable-vtpm still the way to go in Xen 4.2.1 or is there another method to > compile Xen with vTPM (I read that a reimplementation is work in progress) And > is it possible to compile Xen with vTPM on NetBSD with the old or new way? I > found just a little bit about this but no definitiv answer. > > Best Regards > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 15 22:30:56 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 15 Mar 2013 22: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 1UGd7l-0001y4-Lr; Fri, 15 Mar 2013 22:29:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGbGs-0007sF-SB; Fri, 15 Mar 2013 20:30:35 +0000 Received: from [85.158.138.51:36899] by server-6.bemta-3.messagelabs.com id 7E/AD-11048-9E483415; Fri, 15 Mar 2013 20:30:33 +0000 X-Env-Sender: Matthew.Fioravante@jhuapl.edu X-Msg-Ref: server-14.tower-174.messagelabs.com!1363379430!21491548!1 X-Originating-IP: [128.244.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17333 invoked from network); 15 Mar 2013 20:30:32 -0000 Received: from piper.jhuapl.edu (HELO piper.jhuapl.edu) (128.244.251.37) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2013 20:30:32 -0000 Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 706a_936a_969ead2f_5df8_4b9e_b4ba_32a9402f1974; Fri, 15 Mar 2013 16:30:26 -0400 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 15 Mar 2013 16:29:27 -0400 From: "Fioravante, Matthew E." To: tech mailinglists , xen-users , "xen-devel@lists.xen.org" Date: Fri, 15 Mar 2013 16:29:26 -0400 Thread-Topic: [Xen-devel] Actual method to compile Xen with vtpm on Linux and NetBSD Thread-Index: Ac4YmfJBN7zAAx4JSW+raW1m5fVa3AJIbLNA Message-ID: <068F06DC4D106941B297C0C5F9F446EA4921744189@aplesstripe.dom1.jhuapl.edu> References: <5134324F.6060300@gmail.com> In-Reply-To: <5134324F.6060300@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 15 Mar 2013 22:29:16 +0000 Subject: Re: [Xen-users] [Xen-devel] Actual method to compile Xen with vtpm on Linux and NetBSD X-BeenThere: xen-users@lists.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 vTPM has not been tested on NetBSD and not officially supported. You would mostly be on your own for getting it to work but if you are up to the task feel free to submit patches . > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of tech mailinglists > Sent: Monday, March 04, 2013 12:34 AM > To: xen-users; xen-devel@lists.xen.org > Subject: [Xen-devel] Actual method to compile Xen with vtpm on Linux and > NetBSD > > Hello all, > > I have a question about the implementation of vTPM in Xen. I want to setup > vTPM in the next time on my Xen infrastructure and so I read a little bit about it. > I actually have compiled Xen with the configure option --enable-vtpm. > > I read that this option is more or less "deprecated" and I was never able to > compile Xen with vTPM on NetBSD because of the fact that libgmp seems to be > not available on NetBSD. > > So I have two question about this: > > Is --enable-vtpm still the way to go in Xen 4.2.1 or is there another method to > compile Xen with vTPM (I read that a reimplementation is work in progress) And > is it possible to compile Xen with vTPM on NetBSD with the old or new way? I > found just a little bit about this but no definitiv answer. > > Best Regards > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 16 06:57:28 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 16 Mar 2013 06:57: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 1UGl2L-0001ag-Ej; Sat, 16 Mar 2013 06:56:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGl2I-0001aP-M7 for xen-users@lists.xen.org; Sat, 16 Mar 2013 06:56:10 +0000 Received: from [85.158.139.211:31184] by server-6.bemta-5.messagelabs.com id 41/8A-21466-A8714415; Sat, 16 Mar 2013 06:56:10 +0000 X-Env-Sender: digvijaych@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1363416969!18557971!1 X-Originating-IP: [209.85.217.174] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31878 invoked from network); 16 Mar 2013 06:56:09 -0000 Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com) (209.85.217.174) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 16 Mar 2013 06:56:09 -0000 Received: by mail-lb0-f174.google.com with SMTP id l12so3376252lbo.33 for ; Fri, 15 Mar 2013 23:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=d0nQ8ND2zixm0SwaeMHuDEiOi4FdzvKwhKUwioZF1OY=; b=uTq44zbAuL617XDKwEe23TYTTSS7NNhXUSlEHANEqoY/3+x4hGe6RMVGj03vFy3B/2 iJQZ8gRJtFg7BIuVHDO2sJRU04z3Ptf1wQnOAwWAudOjjwEVNKrPWaMft3lV+PpeH6Hc mLXfRR0R1RiOvw7j6KXzJHadgPiKU8IvyGFAa4Hsf6bCSKUN5WlBg/u4sM5K8R/l7Amr XELGK+ZnsrGsHbWTmbhhWm4ilYxBDZzlYa2wS27FpKjNCOul3xgNCDfEYqb3203uy0h6 rPZEoyCxTeY1j+ebVZAIvsCsgo0xA+U8U1PKrH+wc8JFgEdDlvpFOYkpVOqaVeiZrxNx mpGA== MIME-Version: 1.0 X-Received: by 10.152.147.36 with SMTP id th4mr8147359lab.19.1363416968933; Fri, 15 Mar 2013 23:56:08 -0700 (PDT) Received: by 10.112.101.65 with HTTP; Fri, 15 Mar 2013 23:56:08 -0700 (PDT) Date: Sat, 16 Mar 2013 12:26:08 +0530 Message-ID: From: digvijay chauhan To: xen-users@lists.xen.org, xen-devel@lists.xensource.com Subject: [Xen-users] how to uninstall 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: multipart/mixed; boundary="===============6932776671337019274==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6932776671337019274== Content-Type: multipart/alternative; boundary=e89a8f22c3811d37d404d8054058 --e89a8f22c3811d37d404d8054058 Content-Type: text/plain; charset=ISO-8859-1 Hello, I installed xen but when i rebooted the pc,then the fedora with xen hypervisor is not visible.What is the problem. Or How can I uninstall xen from my fedora17. --e89a8f22c3811d37d404d8054058 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I installed xen but when i r= ebooted the pc,then the fedora with xen hypervisor is not visible.What is t= he problem. Or How can I uninstall xen from my fedora17.
--e89a8f22c3811d37d404d8054058-- --===============6932776671337019274== 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 --===============6932776671337019274==-- From xen-users-bounces@lists.xen.org Sat Mar 16 06:57:28 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 16 Mar 2013 06:57: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 1UGl2L-0001ag-Ej; Sat, 16 Mar 2013 06:56:13 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGl2I-0001aP-M7 for xen-users@lists.xen.org; Sat, 16 Mar 2013 06:56:10 +0000 Received: from [85.158.139.211:31184] by server-6.bemta-5.messagelabs.com id 41/8A-21466-A8714415; Sat, 16 Mar 2013 06:56:10 +0000 X-Env-Sender: digvijaych@gmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1363416969!18557971!1 X-Originating-IP: [209.85.217.174] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31878 invoked from network); 16 Mar 2013 06:56:09 -0000 Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com) (209.85.217.174) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 16 Mar 2013 06:56:09 -0000 Received: by mail-lb0-f174.google.com with SMTP id l12so3376252lbo.33 for ; Fri, 15 Mar 2013 23:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=d0nQ8ND2zixm0SwaeMHuDEiOi4FdzvKwhKUwioZF1OY=; b=uTq44zbAuL617XDKwEe23TYTTSS7NNhXUSlEHANEqoY/3+x4hGe6RMVGj03vFy3B/2 iJQZ8gRJtFg7BIuVHDO2sJRU04z3Ptf1wQnOAwWAudOjjwEVNKrPWaMft3lV+PpeH6Hc mLXfRR0R1RiOvw7j6KXzJHadgPiKU8IvyGFAa4Hsf6bCSKUN5WlBg/u4sM5K8R/l7Amr XELGK+ZnsrGsHbWTmbhhWm4ilYxBDZzlYa2wS27FpKjNCOul3xgNCDfEYqb3203uy0h6 rPZEoyCxTeY1j+ebVZAIvsCsgo0xA+U8U1PKrH+wc8JFgEdDlvpFOYkpVOqaVeiZrxNx mpGA== MIME-Version: 1.0 X-Received: by 10.152.147.36 with SMTP id th4mr8147359lab.19.1363416968933; Fri, 15 Mar 2013 23:56:08 -0700 (PDT) Received: by 10.112.101.65 with HTTP; Fri, 15 Mar 2013 23:56:08 -0700 (PDT) Date: Sat, 16 Mar 2013 12:26:08 +0530 Message-ID: From: digvijay chauhan To: xen-users@lists.xen.org, xen-devel@lists.xensource.com Subject: [Xen-users] how to uninstall 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: multipart/mixed; boundary="===============6932776671337019274==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6932776671337019274== Content-Type: multipart/alternative; boundary=e89a8f22c3811d37d404d8054058 --e89a8f22c3811d37d404d8054058 Content-Type: text/plain; charset=ISO-8859-1 Hello, I installed xen but when i rebooted the pc,then the fedora with xen hypervisor is not visible.What is the problem. Or How can I uninstall xen from my fedora17. --e89a8f22c3811d37d404d8054058 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I installed xen but when i r= ebooted the pc,then the fedora with xen hypervisor is not visible.What is t= he problem. Or How can I uninstall xen from my fedora17.
--e89a8f22c3811d37d404d8054058-- --===============6932776671337019274== 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 --===============6932776671337019274==-- From xen-users-bounces@lists.xen.org Sat Mar 16 13:49:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 16 Mar 2013 13:49:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGrSc-0001vu-9W; Sat, 16 Mar 2013 13:47:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGrM4-0001Sl-EK for xen-users@lists.xen.org; Sat, 16 Mar 2013 13:41:00 +0000 Received: from [193.109.254.147:58453] by server-9.bemta-14.messagelabs.com id 29/1C-04223-B6674415; Sat, 16 Mar 2013 13:40:59 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1363441253!3145490!1 X-Originating-IP: [209.85.220.182] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28428 invoked from network); 16 Mar 2013 13:40:55 -0000 Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com) (209.85.220.182) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 16 Mar 2013 13:40:55 -0000 Received: by mail-vc0-f182.google.com with SMTP id ht11so1934865vcb.27 for ; Sat, 16 Mar 2013 06:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=pO5XudLigoz8IxVBM+Dn+88ZaLYJbx/8GsTFg3s23i4=; b=LGDUQDWmXRW0ecs4dmRxqvusYEJ5OElcgc/TPHQUvSs1/NZ//jdhXXJCPKL86eIUZd wlZh5bVZIcEFeNwkOHd69OzWnG+mOuL/wVHqGTktjsR5WH6mQFAi6fz8ZIJUtWNPJpFs 633Jqyt/W0Z5htNeK9Vttdp829H8si6QcuVxhbxi8/xz5It6SnkP/63GRYd1mXeMCzy+ F0H4W7EisMalU0NaWR/pMA13JhgBbDpHro1SIUXOnVvqQNwbk5MW4IyVHNsLxv7d4GDH ccXlJPOrsj3lRhMlonS7Kc1KJ2NOvwVnxtm7433eh8sxtggHhUW+0AHMy5g7fZSPMpNq XWbw== X-Received: by 10.52.65.171 with SMTP id y11mr9948970vds.32.1363441253575; Sat, 16 Mar 2013 06:40:53 -0700 (PDT) Received: from konrad-lan.dumpdata.com (pool-71-254-10-21.burl.east.myfairpoint.net. [71.254.10.21]) by mx.google.com with ESMTPS id qq6sm9869670vec.2.2013.03.16.06.40.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 16 Mar 2013 06:40:52 -0700 (PDT) Date: Sat, 16 Mar 2013 09:40:50 -0400 From: Konrad Rzeszutek Wilk To: digvijay chauhan Message-ID: <20130316134049.GC7297@konrad-lan.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 16 Mar 2013 13:47:45 +0000 Cc: xen-users@lists.xen.org, xen-devel@lists.xensource.com Subject: Re: [Xen-users] [Xen-devel] how to uninstall 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 Sat, Mar 16, 2013 at 12:26:08PM +0530, digvijay chauhan wrote: > Hello, > I installed xen but when i rebooted the pc,then the fedora > with xen hypervisor is not visible.What is the problem. Or How can I Not visible? As in it is not part of the GRUB menu? Did you install it via 'yum install xen' ? > uninstall xen from my fedora17. yum remove xen-* ? > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 16 13:49:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 16 Mar 2013 13:49:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGrSc-0001vu-9W; Sat, 16 Mar 2013 13:47:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGrM4-0001Sl-EK for xen-users@lists.xen.org; Sat, 16 Mar 2013 13:41:00 +0000 Received: from [193.109.254.147:58453] by server-9.bemta-14.messagelabs.com id 29/1C-04223-B6674415; Sat, 16 Mar 2013 13:40:59 +0000 X-Env-Sender: ketuzsezr@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1363441253!3145490!1 X-Originating-IP: [209.85.220.182] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28428 invoked from network); 16 Mar 2013 13:40:55 -0000 Received: from mail-vc0-f182.google.com (HELO mail-vc0-f182.google.com) (209.85.220.182) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 16 Mar 2013 13:40:55 -0000 Received: by mail-vc0-f182.google.com with SMTP id ht11so1934865vcb.27 for ; Sat, 16 Mar 2013 06:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=pO5XudLigoz8IxVBM+Dn+88ZaLYJbx/8GsTFg3s23i4=; b=LGDUQDWmXRW0ecs4dmRxqvusYEJ5OElcgc/TPHQUvSs1/NZ//jdhXXJCPKL86eIUZd wlZh5bVZIcEFeNwkOHd69OzWnG+mOuL/wVHqGTktjsR5WH6mQFAi6fz8ZIJUtWNPJpFs 633Jqyt/W0Z5htNeK9Vttdp829H8si6QcuVxhbxi8/xz5It6SnkP/63GRYd1mXeMCzy+ F0H4W7EisMalU0NaWR/pMA13JhgBbDpHro1SIUXOnVvqQNwbk5MW4IyVHNsLxv7d4GDH ccXlJPOrsj3lRhMlonS7Kc1KJ2NOvwVnxtm7433eh8sxtggHhUW+0AHMy5g7fZSPMpNq XWbw== X-Received: by 10.52.65.171 with SMTP id y11mr9948970vds.32.1363441253575; Sat, 16 Mar 2013 06:40:53 -0700 (PDT) Received: from konrad-lan.dumpdata.com (pool-71-254-10-21.burl.east.myfairpoint.net. [71.254.10.21]) by mx.google.com with ESMTPS id qq6sm9869670vec.2.2013.03.16.06.40.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 16 Mar 2013 06:40:52 -0700 (PDT) Date: Sat, 16 Mar 2013 09:40:50 -0400 From: Konrad Rzeszutek Wilk To: digvijay chauhan Message-ID: <20130316134049.GC7297@konrad-lan.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 16 Mar 2013 13:47:45 +0000 Cc: xen-users@lists.xen.org, xen-devel@lists.xensource.com Subject: Re: [Xen-users] [Xen-devel] how to uninstall 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 Sat, Mar 16, 2013 at 12:26:08PM +0530, digvijay chauhan wrote: > Hello, > I installed xen but when i rebooted the pc,then the fedora > with xen hypervisor is not visible.What is the problem. Or How can I Not visible? As in it is not part of the GRUB menu? Did you install it via 'yum install xen' ? > uninstall xen from my fedora17. yum remove xen-* ? > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 16 17:22:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 16 Mar 2013 17:22: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 1UGund-00071U-15; Sat, 16 Mar 2013 17:21:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGuna-00071P-Uj for xen-users@lists.xen.org; Sat, 16 Mar 2013 17:21:39 +0000 Received: from [85.158.139.211:48250] by server-4.bemta-5.messagelabs.com id CE/E2-01980-22AA4415; Sat, 16 Mar 2013 17:21:38 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1363454496!18611137!1 X-Originating-IP: [209.85.210.172] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2541 invoked from network); 16 Mar 2013 17:21:37 -0000 Received: from mail-ia0-f172.google.com (HELO mail-ia0-f172.google.com) (209.85.210.172) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 16 Mar 2013 17:21:37 -0000 Received: by mail-ia0-f172.google.com with SMTP id l29so4087382iag.17 for ; Sat, 16 Mar 2013 10:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=kvLZ8rgZXF3y8rgWK4OdkjrbqyVoejkoG2l3ppepqVA=; b=O+uowODWX2en4M/DYETnUHzF0L85J19X7y1nK03jXRJn2F2MFIJZAaW3VfxYRVqqfh Qr9hGB3oppZeXEXvp3e0FK1mVKldwKO9FbD4WsAstaUAnf1SEtEWLtITjnvfYhypo2ED b6cVcA+vOTGf6NsADem1rUrCnyN3EU2MNHD7MJ6XauIobmjlvs1wRj2GP0pHtDCxhce6 KiIColZ5X/+hzf92OK8WpFh/TRj63UD0iEIfcw/JKew8t4E8nJGoWc34Ggr/TNpKygu4 i9i8q2dOxxCzS8pYgEk7oJB6MXs+MWu+m9sNklj7zmrspr+kX0e5KdBuXgcMsgS1Mwsh qV7A== MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr3519133igb.90.1363454495919; Sat, 16 Mar 2013 10:21:35 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Sat, 16 Mar 2013 10:21:35 -0700 (PDT) Date: Sat, 16 Mar 2013 11:21:35 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] opensuse kernel and no xenfs X-BeenThere: xen-users@lists.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="===============5890140237687455887==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5890140237687455887== Content-Type: multipart/alternative; boundary=089e011847f6e5951404d80dfc23 --089e011847f6e5951404d80dfc23 Content-Type: text/plain; charset=ISO-8859-1 I was looking at opensuse 3.8.3 kernel it seems that per default it disables xenfs. It makes impossible to mount /proce/xen with xen kernel. O wonder how I can boot custom xen unstable on it if I am unable to mount /proc/xen? --089e011847f6e5951404d80dfc23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was looking at opensuse 3.8.3 kernel it seems that per default it disable= s xenfs. It makes impossible to mount /proce/xen with xen kernel. =A0 O won= der how I can boot custom xen unstable on it if I am unable to mount /proc/= xen?
--089e011847f6e5951404d80dfc23-- --===============5890140237687455887== 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 --===============5890140237687455887==-- From xen-users-bounces@lists.xen.org Sat Mar 16 17:22:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 16 Mar 2013 17:22: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 1UGund-00071U-15; Sat, 16 Mar 2013 17:21:41 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UGuna-00071P-Uj for xen-users@lists.xen.org; Sat, 16 Mar 2013 17:21:39 +0000 Received: from [85.158.139.211:48250] by server-4.bemta-5.messagelabs.com id CE/E2-01980-22AA4415; Sat, 16 Mar 2013 17:21:38 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1363454496!18611137!1 X-Originating-IP: [209.85.210.172] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2541 invoked from network); 16 Mar 2013 17:21:37 -0000 Received: from mail-ia0-f172.google.com (HELO mail-ia0-f172.google.com) (209.85.210.172) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 16 Mar 2013 17:21:37 -0000 Received: by mail-ia0-f172.google.com with SMTP id l29so4087382iag.17 for ; Sat, 16 Mar 2013 10:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=kvLZ8rgZXF3y8rgWK4OdkjrbqyVoejkoG2l3ppepqVA=; b=O+uowODWX2en4M/DYETnUHzF0L85J19X7y1nK03jXRJn2F2MFIJZAaW3VfxYRVqqfh Qr9hGB3oppZeXEXvp3e0FK1mVKldwKO9FbD4WsAstaUAnf1SEtEWLtITjnvfYhypo2ED b6cVcA+vOTGf6NsADem1rUrCnyN3EU2MNHD7MJ6XauIobmjlvs1wRj2GP0pHtDCxhce6 KiIColZ5X/+hzf92OK8WpFh/TRj63UD0iEIfcw/JKew8t4E8nJGoWc34Ggr/TNpKygu4 i9i8q2dOxxCzS8pYgEk7oJB6MXs+MWu+m9sNklj7zmrspr+kX0e5KdBuXgcMsgS1Mwsh qV7A== MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr3519133igb.90.1363454495919; Sat, 16 Mar 2013 10:21:35 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Sat, 16 Mar 2013 10:21:35 -0700 (PDT) Date: Sat, 16 Mar 2013 11:21:35 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] opensuse kernel and no xenfs X-BeenThere: xen-users@lists.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="===============5890140237687455887==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5890140237687455887== Content-Type: multipart/alternative; boundary=089e011847f6e5951404d80dfc23 --089e011847f6e5951404d80dfc23 Content-Type: text/plain; charset=ISO-8859-1 I was looking at opensuse 3.8.3 kernel it seems that per default it disables xenfs. It makes impossible to mount /proce/xen with xen kernel. O wonder how I can boot custom xen unstable on it if I am unable to mount /proc/xen? --089e011847f6e5951404d80dfc23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was looking at opensuse 3.8.3 kernel it seems that per default it disable= s xenfs. It makes impossible to mount /proce/xen with xen kernel. =A0 O won= der how I can boot custom xen unstable on it if I am unable to mount /proc/= xen?
--089e011847f6e5951404d80dfc23-- --===============5890140237687455887== 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 --===============5890140237687455887==-- From xen-users-bounces@lists.xen.org Sun Mar 17 07:16:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 17 Mar 2013 07:16: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 1UH7nn-0001Tw-VO; Sun, 17 Mar 2013 07: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 1UH7nl-0001Tp-SP for xen-users@lists.xen.org; Sun, 17 Mar 2013 07:14:42 +0000 Received: from [85.158.139.211:48131] by server-8.bemta-5.messagelabs.com id 2A/C5-05790-16D65415; Sun, 17 Mar 2013 07:14:41 +0000 X-Env-Sender: pigeon@pigeond.net X-Msg-Ref: server-13.tower-206.messagelabs.com!1363504478!14331123!1 X-Originating-IP: [203.59.1.218] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAzLjU5LjEuMjE4ID0+IDIxNjEx\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3940 invoked from network); 17 Mar 2013 07:14:40 -0000 Received: from icp-osb-irony-out2.external.iinet.net.au (HELO icp-osb-irony-out2.external.iinet.net.au) (203.59.1.218) by server-13.tower-206.messagelabs.com with SMTP; 17 Mar 2013 07:14:40 -0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0MAKBsRVF8lWUl/2dsb2JhbABCjGunW5BlAwGBagIWbQeCKgEBBAE6PxALDRQlDzoBDQYtAYdzBcIdjjpbB4NAA5ZdhiGKYoMeKA X-IronPort-AV: E=Sophos;i="4.84,859,1355068800"; d="scan'208";a="96879288" Received: from unknown (HELO torankusu.pigeond.net) ([124.149.101.37]) by icp-osb-irony-out2.iinet.net.au with ESMTP; 17 Mar 2013 15:14:36 +0800 Received: from furiza.pigeond.net ([192.168.42.20]:41186 helo=114.40.77.101) by torankusu.pigeond.net with esmtp (Exim 4.72) (envelope-from ) id 1UH7nf-0003xC-SS; Sun, 17 Mar 2013 18:14:36 +1100 Date: Sun, 17 Mar 2013 18:14:29 +1100 From: Howell Tam To: "xen-users@lists.xen.org" Message-ID: <20130317181429.41706fa6@114.40.77.101> In-Reply-To: <20130218214525.5afe4b19@114.40.77.101> References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> Organization: pigeond.net X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Cc: Matthias , James Harper Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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 again, > > have you found a solution for this behaviour? Cause I'm currently > > seeing a similar result with my installation. I've been away for a few weeks and I'm finally back on trying to figure out this problem. I was using xl + xl pci-assignable-add when I get the full machine freeze when I reboot the domU windows7. I just tried with the same domu config file, but with xm + pci-stub, and I do not seem to get the freeze (yet, so far 3 reboots/shutdowns). The VGA passthrough (an HD7770) is still working even after the reboot (i.e. no more blank screen). This is semi-good news. If the bug is in xl, then I guess we will have to debug this since xm is deprecated. -- Regards, Howell. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 17 07:16:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 17 Mar 2013 07:16: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 1UH7nn-0001Tw-VO; Sun, 17 Mar 2013 07: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 1UH7nl-0001Tp-SP for xen-users@lists.xen.org; Sun, 17 Mar 2013 07:14:42 +0000 Received: from [85.158.139.211:48131] by server-8.bemta-5.messagelabs.com id 2A/C5-05790-16D65415; Sun, 17 Mar 2013 07:14:41 +0000 X-Env-Sender: pigeon@pigeond.net X-Msg-Ref: server-13.tower-206.messagelabs.com!1363504478!14331123!1 X-Originating-IP: [203.59.1.218] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjAzLjU5LjEuMjE4ID0+IDIxNjEx\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3940 invoked from network); 17 Mar 2013 07:14:40 -0000 Received: from icp-osb-irony-out2.external.iinet.net.au (HELO icp-osb-irony-out2.external.iinet.net.au) (203.59.1.218) by server-13.tower-206.messagelabs.com with SMTP; 17 Mar 2013 07:14:40 -0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0MAKBsRVF8lWUl/2dsb2JhbABCjGunW5BlAwGBagIWbQeCKgEBBAE6PxALDRQlDzoBDQYtAYdzBcIdjjpbB4NAA5ZdhiGKYoMeKA X-IronPort-AV: E=Sophos;i="4.84,859,1355068800"; d="scan'208";a="96879288" Received: from unknown (HELO torankusu.pigeond.net) ([124.149.101.37]) by icp-osb-irony-out2.iinet.net.au with ESMTP; 17 Mar 2013 15:14:36 +0800 Received: from furiza.pigeond.net ([192.168.42.20]:41186 helo=114.40.77.101) by torankusu.pigeond.net with esmtp (Exim 4.72) (envelope-from ) id 1UH7nf-0003xC-SS; Sun, 17 Mar 2013 18:14:36 +1100 Date: Sun, 17 Mar 2013 18:14:29 +1100 From: Howell Tam To: "xen-users@lists.xen.org" Message-ID: <20130317181429.41706fa6@114.40.77.101> In-Reply-To: <20130218214525.5afe4b19@114.40.77.101> References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> Organization: pigeond.net X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Cc: Matthias , James Harper Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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 again, > > have you found a solution for this behaviour? Cause I'm currently > > seeing a similar result with my installation. I've been away for a few weeks and I'm finally back on trying to figure out this problem. I was using xl + xl pci-assignable-add when I get the full machine freeze when I reboot the domU windows7. I just tried with the same domu config file, but with xm + pci-stub, and I do not seem to get the freeze (yet, so far 3 reboots/shutdowns). The VGA passthrough (an HD7770) is still working even after the reboot (i.e. no more blank screen). This is semi-good news. If the bug is in xl, then I guess we will have to debug this since xm is deprecated. -- Regards, Howell. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 17 14:16:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 17 Mar 2013 14:16: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 1UHEM6-0000np-Di; Sun, 17 Mar 2013 14:14:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHEM4-0000nk-Nv for xen-users@lists.xen.org; Sun, 17 Mar 2013 14:14:32 +0000 Received: from [85.158.143.99:25667] by server-3.bemta-4.messagelabs.com id 27/DA-02186-8CFC5415; Sun, 17 Mar 2013 14:14:32 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1363529671!22163207!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21166 invoked from network); 17 Mar 2013 14:14:31 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 17 Mar 2013 14:14:31 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so4413250wgb.24 for ; Sun, 17 Mar 2013 07:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/qUd1TVjqn2VusIw7R/X/7lMA/5a8f1xbKYBNMHamow=; b=QLhcV+ZbH+5ytsorupjcnGJfAaLe5mRCK0TmToSOkRNHvVbK0mVN4iKPTa1SydBGFM nsJV94enFaTGZR8RJdfSoGTpJjKVtqpViCZoTkuDMipzseghuXHok95Jr2jJzdANm+fR YlMxL80AGO6DlmhRoP7JPpzEO23JnLb4QO/twXNo73UUw0R97vPfvqE6ryIOD2DFM4NJ FySwqJ9kRXT+hPnLT/b7bBDY0a//A6ydCku5mVHh636hYc2nGfbkyDxYvCSpVa/h12xQ OjRKRbRO8wiaMpAz/qKkWFdysyY1+ZZQAN3keHEw5CkDV9y3gfb4GnsbKyK6kP+wXH6K anAA== X-Received: by 10.194.20.40 with SMTP id k8mr19973292wje.16.1363529671210; Sun, 17 Mar 2013 07:14:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Sun, 17 Mar 2013 07:14:10 -0700 (PDT) In-Reply-To: <20130317181429.41706fa6@114.40.77.101> References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> <20130317181429.41706fa6@114.40.77.101> From: Matthias Date: Sun, 17 Mar 2013 15:14:10 +0100 Message-ID: To: Howell Tam Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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, may I take an educated guess: You only see the dom0 freeze when you are hiding 2 vgas from dom0? Cause this is what my behaviour (http://www.gossamer-threads.com/lists/xen/users/273630) and i've seen this issue coming up on the mailing list by others.. Also, we got a patch for the blankscreen-on-domU-restart thing if you are still experiancing this.. I posted it here: http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html (in this thread the guy has the dual vga passthrough as well, so it might be worth reeding furthor) Oh yeah, and one last thing: I don't know what git branch you are using but they switched default qemu in unstable and the new qemu-upstream has a bug so vga passthrough doesn't work with more then 4GB of Ram assigned to a domU (bug described here: http://lists.xen.org/archives/html/xen-devel/2013-03/msg00211.html ).. so for the behaviour you are used to (using qemu-xen-traditional) you have to now say that explicitly in your domU config) 2013/3/17 Howell Tam : > > Hi all again, > > >> > have you found a solution for this behaviour? Cause I'm currently >> > seeing a similar result with my installation. > > > I've been away for a few weeks and I'm finally back on trying to figure > out this problem. > > > I was using xl + xl pci-assignable-add when I get the full > machine freeze when I reboot the domU windows7. > > > I just tried with the same domu config file, but with xm + > pci-stub, and I do not seem to get the freeze (yet, so far 3 reboots/shutdowns). > > > The VGA passthrough (an HD7770) is still working even after the > reboot (i.e. no more blank screen). > > > This is semi-good news. If the bug is in xl, then I guess we > will have to debug this since xm is deprecated. > > > -- > Regards, > Howell. > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 17 14:16:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 17 Mar 2013 14:16: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 1UHEM6-0000np-Di; Sun, 17 Mar 2013 14:14:34 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHEM4-0000nk-Nv for xen-users@lists.xen.org; Sun, 17 Mar 2013 14:14:32 +0000 Received: from [85.158.143.99:25667] by server-3.bemta-4.messagelabs.com id 27/DA-02186-8CFC5415; Sun, 17 Mar 2013 14:14:32 +0000 X-Env-Sender: matthias.kannenberg@googlemail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1363529671!22163207!1 X-Originating-IP: [74.125.82.45] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21166 invoked from network); 17 Mar 2013 14:14:31 -0000 Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 17 Mar 2013 14:14:31 -0000 Received: by mail-wg0-f45.google.com with SMTP id dq12so4413250wgb.24 for ; Sun, 17 Mar 2013 07:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/qUd1TVjqn2VusIw7R/X/7lMA/5a8f1xbKYBNMHamow=; b=QLhcV+ZbH+5ytsorupjcnGJfAaLe5mRCK0TmToSOkRNHvVbK0mVN4iKPTa1SydBGFM nsJV94enFaTGZR8RJdfSoGTpJjKVtqpViCZoTkuDMipzseghuXHok95Jr2jJzdANm+fR YlMxL80AGO6DlmhRoP7JPpzEO23JnLb4QO/twXNo73UUw0R97vPfvqE6ryIOD2DFM4NJ FySwqJ9kRXT+hPnLT/b7bBDY0a//A6ydCku5mVHh636hYc2nGfbkyDxYvCSpVa/h12xQ OjRKRbRO8wiaMpAz/qKkWFdysyY1+ZZQAN3keHEw5CkDV9y3gfb4GnsbKyK6kP+wXH6K anAA== X-Received: by 10.194.20.40 with SMTP id k8mr19973292wje.16.1363529671210; Sun, 17 Mar 2013 07:14:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.118.167 with HTTP; Sun, 17 Mar 2013 07:14:10 -0700 (PDT) In-Reply-To: <20130317181429.41706fa6@114.40.77.101> References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> <20130317181429.41706fa6@114.40.77.101> From: Matthias Date: Sun, 17 Mar 2013 15:14:10 +0100 Message-ID: To: Howell Tam Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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, may I take an educated guess: You only see the dom0 freeze when you are hiding 2 vgas from dom0? Cause this is what my behaviour (http://www.gossamer-threads.com/lists/xen/users/273630) and i've seen this issue coming up on the mailing list by others.. Also, we got a patch for the blankscreen-on-domU-restart thing if you are still experiancing this.. I posted it here: http://lists.xen.org/archives/html/xen-users/2013-03/msg00127.html (in this thread the guy has the dual vga passthrough as well, so it might be worth reeding furthor) Oh yeah, and one last thing: I don't know what git branch you are using but they switched default qemu in unstable and the new qemu-upstream has a bug so vga passthrough doesn't work with more then 4GB of Ram assigned to a domU (bug described here: http://lists.xen.org/archives/html/xen-devel/2013-03/msg00211.html ).. so for the behaviour you are used to (using qemu-xen-traditional) you have to now say that explicitly in your domU config) 2013/3/17 Howell Tam : > > Hi all again, > > >> > have you found a solution for this behaviour? Cause I'm currently >> > seeing a similar result with my installation. > > > I've been away for a few weeks and I'm finally back on trying to figure > out this problem. > > > I was using xl + xl pci-assignable-add when I get the full > machine freeze when I reboot the domU windows7. > > > I just tried with the same domu config file, but with xm + > pci-stub, and I do not seem to get the freeze (yet, so far 3 reboots/shutdowns). > > > The VGA passthrough (an HD7770) is still working even after the > reboot (i.e. no more blank screen). > > > This is semi-good news. If the bug is in xl, then I guess we > will have to debug this since xm is deprecated. > > > -- > Regards, > Howell. > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 17 15:03:57 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 17 Mar 2013 15:03: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 1UHF6d-0001sb-HC; Sun, 17 Mar 2013 15:02:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHF6c-0001sK-9n; Sun, 17 Mar 2013 15:02:38 +0000 Received: from [85.158.143.99:17549] by server-3.bemta-4.messagelabs.com id 1B/C2-02186-D0BD5415; Sun, 17 Mar 2013 15:02:37 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1363532556!28901165!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19598 invoked from network); 17 Mar 2013 15:02:36 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-15.tower-216.messagelabs.com with SMTP; 17 Mar 2013 15:02:36 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r2HF1x54002751; Sun, 17 Mar 2013 10:01:59 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r2HF1woL002750; Sun, 17 Mar 2013 10:01:58 -0500 Date: Sun, 17 Mar 2013 10:01:58 -0500 From: "Dr. Greg Wettstein" Message-Id: <201303171501.r2HF1woL002750@wind.enjellic.com> In-Reply-To: Howell Tam "Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough" (Mar 17, 6:14pm) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Howell Tam , "xen-users@lists.xen.org" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Sun, 17 Mar 2013 10:01:59 -0500 (CDT) Cc: Matthias , xen-devel@lists.xen.org, James Harper Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: greg@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Mar 17, 6:14pm, Howell Tam wrote: } Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA p > Hi all again, Hi, hope the weekend is going well for everyone. > > > have you found a solution for this behaviour? Cause I'm currently > > > seeing a similar result with my installation. > > I've been away for a few weeks and I'm finally back on trying to figure > out this problem. > > I was using xl + xl pci-assignable-add when I get the full > machine freeze when I reboot the domU windows7. > > I just tried with the same domu config file, but with xm + > pci-stub, and I do not seem to get the freeze (yet, so far 3 reboots/shutdowns). > > The VGA passthrough (an HD7770) is still working even after the > reboot (i.e. no more blank screen). > > This is semi-good news. If the bug is in xl, then I guess we > will have to debug this since xm is deprecated. I believe its reasonable to say we have worked with VGA pass-through as much as anyone at this point, given we try to maintain the 'unofficial' VGA pass-through patch for QEMU. So the community can take the following as a datapoint. All of our research and development work is based on 4.2.x and as of 4.2.1 using xl for VGA pass-through is a complete non-starter. This is primary pass-through using Radeon with our patch as we do not use the secondary model. The target VM is Windows 7. The primary behavior we see is that the VM will boot to the login screen. After logging in the VM crashes and it isn't very subtle. Re-starting the VM requires Windows to go through a full crash recovery sequence. In a small number of cases dom0 gets completely taken out leaving the sound card buzzing..... :-) Other priorities have kept us from going hunting for this but it is on our agenda. We just found a bug in blktap2 teardown which we have been hunting since 4.2.x came out so hopefully we will find some cycles for it. > Regards, Have a good week. Greg }-- End of excerpt from Howell Tam As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "The price of reliability is the pursuit of the utmost simplicity." -- C.A.R. Hoare 1980 ACM Turning Award Lecture _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 17 15:03:57 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 17 Mar 2013 15:03: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 1UHF6d-0001sb-HC; Sun, 17 Mar 2013 15:02:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHF6c-0001sK-9n; Sun, 17 Mar 2013 15:02:38 +0000 Received: from [85.158.143.99:17549] by server-3.bemta-4.messagelabs.com id 1B/C2-02186-D0BD5415; Sun, 17 Mar 2013 15:02:37 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1363532556!28901165!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19598 invoked from network); 17 Mar 2013 15:02:36 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-15.tower-216.messagelabs.com with SMTP; 17 Mar 2013 15:02:36 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r2HF1x54002751; Sun, 17 Mar 2013 10:01:59 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r2HF1woL002750; Sun, 17 Mar 2013 10:01:58 -0500 Date: Sun, 17 Mar 2013 10:01:58 -0500 From: "Dr. Greg Wettstein" Message-Id: <201303171501.r2HF1woL002750@wind.enjellic.com> In-Reply-To: Howell Tam "Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough" (Mar 17, 6:14pm) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Howell Tam , "xen-users@lists.xen.org" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Sun, 17 Mar 2013 10:01:59 -0500 (CDT) Cc: Matthias , xen-devel@lists.xen.org, James Harper Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: greg@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Mar 17, 6:14pm, Howell Tam wrote: } Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA p > Hi all again, Hi, hope the weekend is going well for everyone. > > > have you found a solution for this behaviour? Cause I'm currently > > > seeing a similar result with my installation. > > I've been away for a few weeks and I'm finally back on trying to figure > out this problem. > > I was using xl + xl pci-assignable-add when I get the full > machine freeze when I reboot the domU windows7. > > I just tried with the same domu config file, but with xm + > pci-stub, and I do not seem to get the freeze (yet, so far 3 reboots/shutdowns). > > The VGA passthrough (an HD7770) is still working even after the > reboot (i.e. no more blank screen). > > This is semi-good news. If the bug is in xl, then I guess we > will have to debug this since xm is deprecated. I believe its reasonable to say we have worked with VGA pass-through as much as anyone at this point, given we try to maintain the 'unofficial' VGA pass-through patch for QEMU. So the community can take the following as a datapoint. All of our research and development work is based on 4.2.x and as of 4.2.1 using xl for VGA pass-through is a complete non-starter. This is primary pass-through using Radeon with our patch as we do not use the secondary model. The target VM is Windows 7. The primary behavior we see is that the VM will boot to the login screen. After logging in the VM crashes and it isn't very subtle. Re-starting the VM requires Windows to go through a full crash recovery sequence. In a small number of cases dom0 gets completely taken out leaving the sound card buzzing..... :-) Other priorities have kept us from going hunting for this but it is on our agenda. We just found a bug in blktap2 teardown which we have been hunting since 4.2.x came out so hopefully we will find some cycles for it. > Regards, Have a good week. Greg }-- End of excerpt from Howell Tam As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "The price of reliability is the pursuit of the utmost simplicity." -- C.A.R. Hoare 1980 ACM Turning Award Lecture _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 17 17:31:46 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 17 Mar 2013 17:31: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 1UHHPw-0004Wf-DZ; Sun, 17 Mar 2013 17:30:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHHPu-0004WO-Iz; Sun, 17 Mar 2013 17:30:42 +0000 Received: from [193.109.254.147:10885] by server-2.bemta-14.messagelabs.com id AD/87-14115-1CDF5415; Sun, 17 Mar 2013 17:30:41 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-7.tower-27.messagelabs.com!1363541439!1271423!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzM1NzU=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26533 invoked from network); 17 Mar 2013 17:30:40 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Mar 2013 17:30:40 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 4354427BD; Sun, 17 Mar 2013 19:30:35 +0200 (EET) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 9E7372006E; Sun, 17 Mar 2013 19:30:35 +0200 (EET) Date: Sun, 17 Mar 2013 19:30:35 +0200 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: greg@enjellic.com Message-ID: <20130317173035.GB11427@reaktio.net> References: <201303171501.r2HF1woL002750@wind.enjellic.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <201303171501.r2HF1woL002750@wind.enjellic.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-users@lists.xen.org" , James Harper , Matthias , Howell Tam , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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, Mar 17, 2013 at 10:01:58AM -0500, Dr. Greg Wettstein wrote: > We just found a bug in blktap2 teardown which we have > been hunting since 4.2.x came out so hopefully we will find some > cycles for it. > Is this possibly the libxl blktap bug that has already been fixed in xen-unstable? http://xenbits.xen.org/hg/xen-unstable.hg/rev/948f232e0228 4.2 backport of the patch can be found from xen-devel archives. -- Pasi _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Mar 17 17:31:46 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 17 Mar 2013 17:31: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 1UHHPw-0004Wf-DZ; Sun, 17 Mar 2013 17:30:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHHPu-0004WO-Iz; Sun, 17 Mar 2013 17:30:42 +0000 Received: from [193.109.254.147:10885] by server-2.bemta-14.messagelabs.com id AD/87-14115-1CDF5415; Sun, 17 Mar 2013 17:30:41 +0000 X-Env-Sender: pasik@iki.fi X-Msg-Ref: server-7.tower-27.messagelabs.com!1363541439!1271423!1 X-Originating-IP: [192.89.123.25] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NzM1NzU=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26533 invoked from network); 17 Mar 2013 17:30:40 -0000 Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Mar 2013 17:30:40 -0000 X-Originating-Ip: [194.89.68.22] Received: from ydin.reaktio.net (reaktio.net [194.89.68.22]) by smtp.tele.fi (Postfix) with ESMTP id 4354427BD; Sun, 17 Mar 2013 19:30:35 +0200 (EET) Received: by ydin.reaktio.net (Postfix, from userid 1001) id 9E7372006E; Sun, 17 Mar 2013 19:30:35 +0200 (EET) Date: Sun, 17 Mar 2013 19:30:35 +0200 From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= To: greg@enjellic.com Message-ID: <20130317173035.GB11427@reaktio.net> References: <201303171501.r2HF1woL002750@wind.enjellic.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <201303171501.r2HF1woL002750@wind.enjellic.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "xen-users@lists.xen.org" , James Harper , Matthias , Howell Tam , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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, Mar 17, 2013 at 10:01:58AM -0500, Dr. Greg Wettstein wrote: > We just found a bug in blktap2 teardown which we have > been hunting since 4.2.x came out so hopefully we will find some > cycles for it. > Is this possibly the libxl blktap bug that has already been fixed in xen-unstable? http://xenbits.xen.org/hg/xen-unstable.hg/rev/948f232e0228 4.2 backport of the patch can be found from xen-devel archives. -- Pasi _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 03:40:38 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 03:40: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 1UHQuo-0000KG-CN; Mon, 18 Mar 2013 03:39:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHQun-0000KB-5W for xen-users@lists.xen.org; Mon, 18 Mar 2013 03:39:13 +0000 Received: from [85.158.139.83:59437] by server-8.bemta-5.messagelabs.com id 0C/43-05790-06C86415; Mon, 18 Mar 2013 03:39:12 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1363577950!27401157!1 X-Originating-IP: [209.85.210.180] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15323 invoked from network); 18 Mar 2013 03:39:11 -0000 Received: from mail-ia0-f180.google.com (HELO mail-ia0-f180.google.com) (209.85.210.180) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 03:39:11 -0000 Received: by mail-ia0-f180.google.com with SMTP id f27so4797560iae.25 for ; Sun, 17 Mar 2013 20:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xvgizJiaPvCXFQBiyNv9/up7TB7gXcmIb74OcdQ8V9I=; b=wvVQiCDpcTGEK2EqD0h+KCrnhSX0zKbHlmDUbT/Sk0UlvlQUWYNjq8musTuUWHsq6c u7dkpG6O7bC0WMaT8Iel5UQW8sseUYTbahpMDy3y8OOc302QkiT5SgtiRCHqoOB7FJKn 7kQPCqnC+4j8SstJv1jERQEDzxozyJe24Ss7AvcC6HzawtvKNQH26LVr/G+HsNbJWBvC E5TNX0K+lMlIq0hyBWnRVl20v6Ah3O0eWID42HOX7T75R1YdEe/k49H9csua5gAwi7jL G2d2dzxcy9m2OCaxWATNABEXgPs2DRSn40CXmlVrZEDC4Xm8gnkCgm6CCUDYdsPUhFPU T46A== MIME-Version: 1.0 X-Received: by 10.50.77.230 with SMTP id v6mr5623184igw.29.1363577950137; Sun, 17 Mar 2013 20:39:10 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Sun, 17 Mar 2013 20:39:09 -0700 (PDT) Date: Sun, 17 Mar 2013 21:39:09 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] osx lion on 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: multipart/mixed; boundary="===============5478720808907410438==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5478720808907410438== Content-Type: multipart/alternative; boundary=e89a8f3ba87f57749004d82abbb3 --e89a8f3ba87f57749004d82abbb3 Content-Type: text/plain; charset=ISO-8859-1 I just installed osx lion on xen and It boot fine I can;t get the osx to recognize mice and network. Any way to configure xen to emulate mice that os x will recognize. I had installed ps/2 driver. --e89a8f3ba87f57749004d82abbb3 Content-Type: text/html; charset=ISO-8859-1 I just installed osx lion on xen and It boot fine I can;t get the osx to recognize mice and network.
Any way to configure xen to emulate mice that os x will recognize. I had installed ps/2 driver.
--e89a8f3ba87f57749004d82abbb3-- --===============5478720808907410438== 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 --===============5478720808907410438==-- From xen-users-bounces@lists.xen.org Mon Mar 18 03:40:38 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 03:40: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 1UHQuo-0000KG-CN; Mon, 18 Mar 2013 03:39:14 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHQun-0000KB-5W for xen-users@lists.xen.org; Mon, 18 Mar 2013 03:39:13 +0000 Received: from [85.158.139.83:59437] by server-8.bemta-5.messagelabs.com id 0C/43-05790-06C86415; Mon, 18 Mar 2013 03:39:12 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1363577950!27401157!1 X-Originating-IP: [209.85.210.180] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15323 invoked from network); 18 Mar 2013 03:39:11 -0000 Received: from mail-ia0-f180.google.com (HELO mail-ia0-f180.google.com) (209.85.210.180) by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 03:39:11 -0000 Received: by mail-ia0-f180.google.com with SMTP id f27so4797560iae.25 for ; Sun, 17 Mar 2013 20:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=xvgizJiaPvCXFQBiyNv9/up7TB7gXcmIb74OcdQ8V9I=; b=wvVQiCDpcTGEK2EqD0h+KCrnhSX0zKbHlmDUbT/Sk0UlvlQUWYNjq8musTuUWHsq6c u7dkpG6O7bC0WMaT8Iel5UQW8sseUYTbahpMDy3y8OOc302QkiT5SgtiRCHqoOB7FJKn 7kQPCqnC+4j8SstJv1jERQEDzxozyJe24Ss7AvcC6HzawtvKNQH26LVr/G+HsNbJWBvC E5TNX0K+lMlIq0hyBWnRVl20v6Ah3O0eWID42HOX7T75R1YdEe/k49H9csua5gAwi7jL G2d2dzxcy9m2OCaxWATNABEXgPs2DRSn40CXmlVrZEDC4Xm8gnkCgm6CCUDYdsPUhFPU T46A== MIME-Version: 1.0 X-Received: by 10.50.77.230 with SMTP id v6mr5623184igw.29.1363577950137; Sun, 17 Mar 2013 20:39:10 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Sun, 17 Mar 2013 20:39:09 -0700 (PDT) Date: Sun, 17 Mar 2013 21:39:09 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] osx lion on 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: multipart/mixed; boundary="===============5478720808907410438==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============5478720808907410438== Content-Type: multipart/alternative; boundary=e89a8f3ba87f57749004d82abbb3 --e89a8f3ba87f57749004d82abbb3 Content-Type: text/plain; charset=ISO-8859-1 I just installed osx lion on xen and It boot fine I can;t get the osx to recognize mice and network. Any way to configure xen to emulate mice that os x will recognize. I had installed ps/2 driver. --e89a8f3ba87f57749004d82abbb3 Content-Type: text/html; charset=ISO-8859-1 I just installed osx lion on xen and It boot fine I can;t get the osx to recognize mice and network.
Any way to configure xen to emulate mice that os x will recognize. I had installed ps/2 driver.
--e89a8f3ba87f57749004d82abbb3-- --===============5478720808907410438== 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 --===============5478720808907410438==-- From xen-users-bounces@lists.xen.org Mon Mar 18 03:51:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 03:51: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 1UHR5V-0000fV-0j; Mon, 18 Mar 2013 03:50:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHR5S-0000fO-G5 for xen-users@lists.xen.org; Mon, 18 Mar 2013 03:50:14 +0000 Received: from [85.158.139.211:59615] by server-8.bemta-5.messagelabs.com id D4/08-05790-5FE86415; Mon, 18 Mar 2013 03:50:13 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1363578611!18726046!1 X-Originating-IP: [74.125.82.195] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15135 invoked from network); 18 Mar 2013 03:50:11 -0000 Received: from mail-we0-f195.google.com (HELO mail-we0-f195.google.com) (74.125.82.195) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 03:50:11 -0000 Received: by mail-we0-f195.google.com with SMTP id k14so1265695wer.6 for ; Sun, 17 Mar 2013 20:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=S33rnu+nZiIaBpgn9X9DPCEP6AaS6ZO1sOGmYt5RMyA=; b=b7n1URGDpPxvtIKZyCbfISsTV545dg91S6XN15eN9V0ojgevqAZyesw8r6TnyN7vWc E4mXOGSPj2Kg8NLpo9aDElZDoXwfVTSfw/1j8WgDTt/ylYXo8oNsZms8zCnt+8hHLHFZ Qce55mAzGUxh19Nf6WIKLu5OwzdDPhWmhpNaalpZtY9VJO5//bXpmO5aq7MstTyAYhJb GPmj/0X301UPVCBWkpt9oh+PJs1V73FTFdSl1N0nGAPw+P3AddtubJCV7JztQOuM6uBs /cmADXuFLtiNby5lo20s4ivvu7qQWMwGYJG/vAz623X+Os08Cjow7NHbsH+0dHK7ySTo hJow== MIME-Version: 1.0 X-Received: by 10.180.38.101 with SMTP id f5mr13751129wik.25.1363578610952; Sun, 17 Mar 2013 20:50:10 -0700 (PDT) Received: by 10.194.153.36 with HTTP; Sun, 17 Mar 2013 20:50:10 -0700 (PDT) Date: Mon, 18 Mar 2013 11:50:10 +0800 Message-ID: From: Cao Wenz To: xen-users@lists.xen.org Subject: [Xen-users] VM is paused when it is created X-BeenThere: xen-users@lists.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="===============3756310565365579030==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3756310565365579030== Content-Type: multipart/alternative; boundary=e89a8f643372bab0d404d82ae289 --e89a8f643372bab0d404d82ae289 Content-Type: text/plain; charset=ISO-8859-1 Hi, ALL I install Centos 5.5 and Xen 4.0 in my VMware VM. The dom0 is OK, I can get vm list by "xm list", show bridge config by "brctl show". Than I create a VM image, and try to start it. But when "xm create -c", the vm is paused. I do not know why. my config is: 1 # Kernel image file. 2 kernel = "/boot/vmlinuz-2.6.31.8-xen" 3 4 # Optional ramdisk. 5 # ramdisk = "/boot/initrd-2.6.31.8-xen.img" 6 ramdisk = "/vm/initrd-2.6.31.8-xen.domu.img" 7 8 memory = 512 9 name = "DomainU" 10 vcpus = 1 11 12 vif = [ '' ] 13 14 ip = "192.168.1.2" 15 netmask = "255.255.255.0" 16 gateway = "192.168.1.1" 17 18 isk = [ 'file:/vm/domU.img,sda1,w' ] 19 20 # Set root device. 21 root = "/dev/sda1 ro" And print is : ... [ 60.987475] XENBUS: Device with no driver: device/console/0 [ 62.494841] IP-Config: Complete: [ 62.494866] device=eth0, addr=192.168.1.2, mask=255.255.255.0, gw=192.168.1.1, [ 62.494894] host=192.168.1.2, domain=, nis-domain=(none), [ 62.494907] bootserver=127.0.255.255, rootserver=127.0.255.255, rootpath= [ 62.495267] Freeing unused kernel memory: 376k freed [ 62.496155] Write protecting the kernel read-only data: 7556k [ 62.834612] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 62.842823] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 62.852827] uhci_hcd: USB Universal Host Controller Interface driver [ 62.981896] Fusion MPT base driver 3.04.10 [ 62.983314] Copyright (c) 1999-2008 LSI Corporation [ 63.002120] Fusion MPT SPI Host driver 3.04.10 [ 63.099169] kjournald starting. Commit interval 5 seconds [ 63.099201] EXT3-fs: mounted filesystem with writeback data mode. [ 64.275946] hostname used greatest stack depth: 5728 bytes left [ 64.347479] uname used greatest stack depth: 5576 bytes left [ 64.518539] mount used greatest stack depth: 4408 bytes left dmesg is: ... [ 79.645608] md: ... autorun DONE. [ 79.646727] nash used greatest stack depth: 4400 bytes left [ 80.902473] EXT3 FS on sda3, internal journal [ 81.463346] kjournald starting. Commit interval 5 seconds [ 81.464179] EXT3 FS on sda2, internal journal [ 81.464192] EXT3-fs: mounted filesystem with writeback data mode. [ 81.466375] kjournald starting. Commit interval 5 seconds [ 81.467110] EXT3 FS on sda1, internal journal [ 81.467123] EXT3-fs: mounted filesystem with writeback data mode. [ 82.727149] rc.sysinit used greatest stack depth: 4200 bytes left [ 87.845535] e1000: eth0: e1000_set_tso: TSO is Enabled [ 88.531915] warning: process `kudzu' used the deprecated sysctl system call with 1.23. [ 97.266951] warning: `dbus-daemon' uses 32-bit capabilities (legacy support in use) [ 98.190488] usb usb2: usb auto-resume [ 98.190498] usb usb2: wakeup_rh [ 98.225296] hub 2-0:1.0: hub_resume [ 98.225950] usb usb1: usb auto-resume [ 98.226101] ehci_hcd 0000:02:03.0: resume root hub [ 98.226499] hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 98.247844] hub 1-0:1.0: hub_resume [ 98.249594] hub 1-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 99.453025] usb usb2: suspend_rh (auto-stop) [ 118.807147] e1000: peth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 118.346076] device peth0 entered promiscuous mode [ 119.104176] eth0: port 1(peth0) entering forwarding state [ 129.170323] eth0: no IPv6 routers present [ 129.607094] peth0: no IPv6 routers present [ 180.944579] alloc irq_desc for 432 on node 0 [ 180.944584] alloc kstat_irqs on node 0 [ 180.951443] alloc irq_desc for 433 on node 0 [ 180.951446] alloc kstat_irqs on node 0 [ 180.951457] suspend: event channel 27 [ 398.792388] kjournald starting. Commit interval 5 seconds [ 398.838106] EXT3 FS on sdb1, internal journal [ 398.838123] EXT3-fs: mounted filesystem with writeback data mode. [ 413.818582] device vif1.0 entered promiscuous mode [ 413.029060] eth0: port 2(vif1.0) entering forwarding state [ 413.911324] (cdrom_add_media_watch() file=drivers/xen/blkback/cdrom.c, line=108) nodename:backend/vbd/1/2049 [ 413.911353] (cdrom_is_type() file=drivers/xen/blkback/cdrom.c, line=95) type:0 [ 423.171717] vif1.0: no IPv6 routers present [ 474.792898] blkback: ring-ref 8, event-channel 10, protocol 1 (x86_64-abi) [ 474.792958] alloc irq_desc for 434 on node 0 [ 474.792960] alloc kstat_irqs on node 0 [ 474.805759] alloc irq_desc for 435 on node 0 [ 474.805762] alloc kstat_irqs on node 0 in Xend.log: ... 174 [2013-03-18 11:33:57 4422] DEBUG (XendDomainInfo:1891) XendDomainInfo.handleShutdownWatch 175 [2013-03-18 11:33:58 4422] DEBUG (DevController:139) Waiting for devices vif2. 176 [2013-03-18 11:33:58 4422] DEBUG (DevController:139) Waiting for devices vif. 177 [2013-03-18 11:33:58 4422] DEBUG (DevController:144) Waiting for 0. 178 [2013-03-18 11:33:58 4422] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status. 179 [2013-03-18 11:33:59 4422] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status. 180 [2013-03-18 11:33:59 4422] DEBUG (DevController:642) hotplugStatusCallback 1. 181 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vscsi. 182 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vbd. 183 [2013-03-18 11:33:59 4422] DEBUG (DevController:144) Waiting for 2049. 184 [2013-03-18 11:33:59 4422] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/1/2049/hotplug-stat us. 185 [2013-03-18 11:33:59 4422] DEBUG (DevController:642) hotplugStatusCallback 1. 186 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices ioports. 187 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices irq. 188 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vkbd. 189 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vfb. 190 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices console. 191 [2013-03-18 11:33:59 4422] DEBUG (DevController:144) Waiting for 0. 192 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices pci. 193 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices tap2. 194 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices tap. 195 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vusb. 196 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vtpm. 197 [2013-03-18 11:33:59 4422] INFO (XendDomain:1206) Domain DomainU (1) unpaused. There is not any error or warning. SO how do I fix it? --e89a8f643372bab0d404d82ae289 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, ALL

I install Centos 5.5 and Xen 4.0 in my VMware VM= . The dom0 is OK, I can get vm list by "xm list", show bridge con= fig by "brctl show". Than I create a VM image, and try to start i= t. But when "xm create -c", the vm=A0=A0is paused. I do not know = why.

my config is:
=A0 1 # Kernel image file.=
=A0 2 kernel =3D "/boot/vmlinuz-2.6.31.8-xen"
=A0 3=A0
=A0 4 # Optional ramdisk.
=A0 5 # ramdisk = =3D "/boot/initrd-2.6.31.8-xen.img"
=A0 6 ramdisk =3D "/vm/initrd-2.6.31.8-xen.domu.img"
=A0 7=A0
=A0 8 memory =3D 512
=A0 9 name =3D "D= omainU"
=A010 vcpus =3D 1
=A011=A0
=A012= vif =3D [ '' ]
=A013=A0
=A014 ip =3D "192.168.1.2"
=A01= 5 netmask =3D "255.255.255.0"
=A016 gateway =3D "1= 92.168.1.1"
=A017=A0
=A018 isk =3D [ 'file:/vm= /domU.img,sda1,w' ]
=A019=A0
=A020 # Set root device.
=A021 root =3D &= quot;/dev/sda1 ro"


And p= rint is :
...
[ =A0 60.987475] XENBUS: Device with= no driver: device/console/0
[ =A0 62.494841] IP-Config: Complete:
[ =A0 62.494866] =A0 = =A0 =A0device=3Deth0, addr=3D192.168.1.2, mask=3D255.255.255.0, gw=3D192.16= 8.1.1,
[ =A0 62.494894] =A0 =A0 =A0host=3D192.168.1.2, domain=3D,= nis-domain=3D(none),
[ =A0 62.494907] =A0 =A0 =A0bootserver=3D127.0.255.255, rootserver=3D127.0.= 255.255, rootpath=3D
[ =A0 62.495267] Freeing unused kernel memor= y: 376k freed
[ =A0 62.496155] Write protecting the kernel read-o= nly data: 7556k
[ =A0 62.834612] ehci_hcd: USB 2.0 'Enhanced' Host Controller = (EHCI) Driver
[ =A0 62.842823] ohci_hcd: USB 1.1 'Open' H= ost Controller (OHCI) Driver
[ =A0 62.852827] uhci_hcd: USB Unive= rsal Host Controller Interface driver
[ =A0 62.981896] Fusion MPT base driver 3.04.10
[ =A0 62.983= 314] Copyright (c) 1999-2008 LSI Corporation
[ =A0 63.002120] Fus= ion MPT SPI Host driver 3.04.10
[ =A0 63.099169] kjournald starti= ng. =A0Commit interval 5 seconds
[ =A0 63.099201] EXT3-fs: mounted filesystem with writeback data mode.=
[ =A0 64.275946] hostname used greatest stack depth: 5728 bytes = left
[ =A0 64.347479] uname used greatest stack depth: 5576 bytes= left
[ =A0 64.518539] mount used greatest stack depth: 4408 bytes left

dmesg is:
...
[ =A0 79.= 645608] md: ... autorun DONE.
[ =A0 79.646727] nash used greatest= stack depth: 4400 bytes left
[ =A0 80.902473] EXT3 FS on sda3, internal journal
[ =A0 81.= 463346] kjournald starting. =A0Commit interval 5 seconds
[ =A0 81= .464179] EXT3 FS on sda2, internal journal
[ =A0 81.464192] EXT3-= fs: mounted filesystem with writeback data mode.
[ =A0 81.466375] kjournald starting. =A0Commit interval 5 seconds
[ =A0 81.467110] EXT3 FS on sda1, internal journal
[ =A0 81= .467123] EXT3-fs: mounted filesystem with writeback data mode.
[ = =A0 82.727149] rc.sysinit used greatest stack depth: 4200 bytes left
[ =A0 87.845535] e1000: eth0: e1000_set_tso: TSO is Enabled
= [ =A0 88.531915] warning: process `kudzu' used the deprecated sysctl sy= stem call with 1.23.
[ =A0 97.266951] warning: `dbus-daemon' = uses 32-bit capabilities (legacy support in use)
[ =A0 98.190488] usb usb2: usb auto-resume
[ =A0 98.190498] = usb usb2: wakeup_rh
[ =A0 98.225296] hub 2-0:1.0: hub_resume
[ =A0 98.225950] usb usb1: usb auto-resume
[ =A0 98.226101]= ehci_hcd 0000:02:03.0: resume root hub
[ =A0 98.226499] hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
<= div>[ =A0 98.247844] hub 1-0:1.0: hub_resume
[ =A0 98.249594] hub= 1-0:1.0: state 7 ports 6 chg 0000 evt 0000
[ =A0 99.453025] usb = usb2: suspend_rh (auto-stop)
[ =A0118.807147] e1000: peth0 NIC Link is Up 1000 Mbps Full Duplex, Fl= ow Control: None
[ =A0118.346076] device peth0 entered promiscuou= s mode
[ =A0119.104176] eth0: port 1(peth0) entering forwarding s= tate
[ =A0129.170323] eth0: no IPv6 routers present
[ =A0129.6070= 94] peth0: no IPv6 routers present
[ =A0180.944579] =A0 alloc irq= _desc for 432 on node 0
[ =A0180.944584] =A0 alloc kstat_irqs on = node 0
[ =A0180.951443] =A0 alloc irq_desc for 433 on node 0
[ =A01= 80.951446] =A0 alloc kstat_irqs on node 0
[ =A0180.951457] suspen= d: event channel 27
[ =A0398.792388] kjournald starting. =A0Commi= t interval 5 seconds
[ =A0398.838106] EXT3 FS on sdb1, internal journal
[ =A0398.= 838123] EXT3-fs: mounted filesystem with writeback data mode.
[ = =A0413.818582] device vif1.0 entered promiscuous mode
[ =A0413.02= 9060] eth0: port 2(vif1.0) entering forwarding state
[ =A0413.911324] (cdrom_add_media_watch() file=3Ddrivers/xen/blkback/c= drom.c, line=3D108) nodename:backend/vbd/1/2049
[ =A0413.911353] = (cdrom_is_type() file=3Ddrivers/xen/blkback/cdrom.c, line=3D95) type:0
[ =A0423.171717] vif1.0: no IPv6 routers present
[ =A0474.792898] blkback: ring-ref 8, event-channel 10, protocol 1 (x8= 6_64-abi)
[ =A0474.792958] =A0 alloc irq_desc for 434 on node 0
[ =A0474.792960] =A0 alloc kstat_irqs on node 0
[ =A0474= .805759] =A0 alloc irq_desc for 435 on node 0
[ =A0474.805762] =A0 alloc kstat_irqs on node 0

in Xend.log:
...
174 [2013-03-18 11:33:57= 4422] DEBUG (XendDomainInfo:1891) XendDomainInfo.handleShutdownWatch
175 [2013-03-18 11:33:58 4422] DEBUG (DevController:139) Waiting for d= evices vif2.
176 [2013-03-18 11:33:58 4422] DEBUG (DevController:= 139) Waiting for devices vif.
177 [2013-03-18 11:33:58 4422] DEBU= G (DevController:144) Waiting for 0.
178 [2013-03-18 11:33:58 4422] DEBUG (DevController:628) hotplugStatus= Callback /local/domain/0/backend/vif/1/0/hotplug-status.
179 [201= 3-03-18 11:33:59 4422] DEBUG (DevController:628) hotplugStatusCallback /loc= al/domain/0/backend/vif/1/0/hotplug-status.
180 [2013-03-18 11:33:59 4422] DEBUG (DevController:642) hotplugStatus= Callback 1.
181 [2013-03-18 11:33:59 4422] DEBUG (DevController:1= 39) Waiting for devices vscsi.
182 [2013-03-18 11:33:59 4422] DEB= UG (DevController:139) Waiting for devices vbd.
183 [2013-03-18 11:33:59 4422] DEBUG (DevController:144) Waiting for 2= 049.
184 [2013-03-18 11:33:59 4422] DEBUG (DevController:628) hot= plugStatusCallback /local/domain/0/backend/vbd/1/2049/hotplug-stat =A0 =A0u= s.
185 [2013-03-18 11:33:59 4422] DEBUG (DevController:642) hotplugStatus= Callback 1.
186 [2013-03-18 11:33:59 4422] DEBUG (DevController:1= 39) Waiting for devices ioports.
187 [2013-03-18 11:33:59 4422] D= EBUG (DevController:139) Waiting for devices irq.
188 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for d= evices vkbd.
189 [2013-03-18 11:33:59 4422] DEBUG (DevController:= 139) Waiting for devices vfb.
190 [2013-03-18 11:33:59 4422] DEBU= G (DevController:139) Waiting for devices console.
191 [2013-03-18 11:33:59 4422] DEBUG (DevController:144) Waiting for 0= .
192 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waitin= g for devices pci.
193 [2013-03-18 11:33:59 4422] DEBUG (DevContr= oller:139) Waiting for devices tap2.
194 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for d= evices tap.
195 [2013-03-18 11:33:59 4422] DEBUG (DevController:1= 39) Waiting for devices vusb.
196 [2013-03-18 11:33:59 4422] DEBU= G (DevController:139) Waiting for devices vtpm.
197 [2013-03-18 11:33:59 4422] INFO (XendDomain:1206) Domain DomainU (= 1) unpaused.

There is not any error or warni= ng. SO how do I fix it?
--e89a8f643372bab0d404d82ae289-- --===============3756310565365579030== 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 --===============3756310565365579030==-- From xen-users-bounces@lists.xen.org Mon Mar 18 03:51:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 03:51: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 1UHR5V-0000fV-0j; Mon, 18 Mar 2013 03:50:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHR5S-0000fO-G5 for xen-users@lists.xen.org; Mon, 18 Mar 2013 03:50:14 +0000 Received: from [85.158.139.211:59615] by server-8.bemta-5.messagelabs.com id D4/08-05790-5FE86415; Mon, 18 Mar 2013 03:50:13 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1363578611!18726046!1 X-Originating-IP: [74.125.82.195] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15135 invoked from network); 18 Mar 2013 03:50:11 -0000 Received: from mail-we0-f195.google.com (HELO mail-we0-f195.google.com) (74.125.82.195) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 03:50:11 -0000 Received: by mail-we0-f195.google.com with SMTP id k14so1265695wer.6 for ; Sun, 17 Mar 2013 20:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=S33rnu+nZiIaBpgn9X9DPCEP6AaS6ZO1sOGmYt5RMyA=; b=b7n1URGDpPxvtIKZyCbfISsTV545dg91S6XN15eN9V0ojgevqAZyesw8r6TnyN7vWc E4mXOGSPj2Kg8NLpo9aDElZDoXwfVTSfw/1j8WgDTt/ylYXo8oNsZms8zCnt+8hHLHFZ Qce55mAzGUxh19Nf6WIKLu5OwzdDPhWmhpNaalpZtY9VJO5//bXpmO5aq7MstTyAYhJb GPmj/0X301UPVCBWkpt9oh+PJs1V73FTFdSl1N0nGAPw+P3AddtubJCV7JztQOuM6uBs /cmADXuFLtiNby5lo20s4ivvu7qQWMwGYJG/vAz623X+Os08Cjow7NHbsH+0dHK7ySTo hJow== MIME-Version: 1.0 X-Received: by 10.180.38.101 with SMTP id f5mr13751129wik.25.1363578610952; Sun, 17 Mar 2013 20:50:10 -0700 (PDT) Received: by 10.194.153.36 with HTTP; Sun, 17 Mar 2013 20:50:10 -0700 (PDT) Date: Mon, 18 Mar 2013 11:50:10 +0800 Message-ID: From: Cao Wenz To: xen-users@lists.xen.org Subject: [Xen-users] VM is paused when it is created X-BeenThere: xen-users@lists.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="===============3756310565365579030==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3756310565365579030== Content-Type: multipart/alternative; boundary=e89a8f643372bab0d404d82ae289 --e89a8f643372bab0d404d82ae289 Content-Type: text/plain; charset=ISO-8859-1 Hi, ALL I install Centos 5.5 and Xen 4.0 in my VMware VM. The dom0 is OK, I can get vm list by "xm list", show bridge config by "brctl show". Than I create a VM image, and try to start it. But when "xm create -c", the vm is paused. I do not know why. my config is: 1 # Kernel image file. 2 kernel = "/boot/vmlinuz-2.6.31.8-xen" 3 4 # Optional ramdisk. 5 # ramdisk = "/boot/initrd-2.6.31.8-xen.img" 6 ramdisk = "/vm/initrd-2.6.31.8-xen.domu.img" 7 8 memory = 512 9 name = "DomainU" 10 vcpus = 1 11 12 vif = [ '' ] 13 14 ip = "192.168.1.2" 15 netmask = "255.255.255.0" 16 gateway = "192.168.1.1" 17 18 isk = [ 'file:/vm/domU.img,sda1,w' ] 19 20 # Set root device. 21 root = "/dev/sda1 ro" And print is : ... [ 60.987475] XENBUS: Device with no driver: device/console/0 [ 62.494841] IP-Config: Complete: [ 62.494866] device=eth0, addr=192.168.1.2, mask=255.255.255.0, gw=192.168.1.1, [ 62.494894] host=192.168.1.2, domain=, nis-domain=(none), [ 62.494907] bootserver=127.0.255.255, rootserver=127.0.255.255, rootpath= [ 62.495267] Freeing unused kernel memory: 376k freed [ 62.496155] Write protecting the kernel read-only data: 7556k [ 62.834612] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 62.842823] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 62.852827] uhci_hcd: USB Universal Host Controller Interface driver [ 62.981896] Fusion MPT base driver 3.04.10 [ 62.983314] Copyright (c) 1999-2008 LSI Corporation [ 63.002120] Fusion MPT SPI Host driver 3.04.10 [ 63.099169] kjournald starting. Commit interval 5 seconds [ 63.099201] EXT3-fs: mounted filesystem with writeback data mode. [ 64.275946] hostname used greatest stack depth: 5728 bytes left [ 64.347479] uname used greatest stack depth: 5576 bytes left [ 64.518539] mount used greatest stack depth: 4408 bytes left dmesg is: ... [ 79.645608] md: ... autorun DONE. [ 79.646727] nash used greatest stack depth: 4400 bytes left [ 80.902473] EXT3 FS on sda3, internal journal [ 81.463346] kjournald starting. Commit interval 5 seconds [ 81.464179] EXT3 FS on sda2, internal journal [ 81.464192] EXT3-fs: mounted filesystem with writeback data mode. [ 81.466375] kjournald starting. Commit interval 5 seconds [ 81.467110] EXT3 FS on sda1, internal journal [ 81.467123] EXT3-fs: mounted filesystem with writeback data mode. [ 82.727149] rc.sysinit used greatest stack depth: 4200 bytes left [ 87.845535] e1000: eth0: e1000_set_tso: TSO is Enabled [ 88.531915] warning: process `kudzu' used the deprecated sysctl system call with 1.23. [ 97.266951] warning: `dbus-daemon' uses 32-bit capabilities (legacy support in use) [ 98.190488] usb usb2: usb auto-resume [ 98.190498] usb usb2: wakeup_rh [ 98.225296] hub 2-0:1.0: hub_resume [ 98.225950] usb usb1: usb auto-resume [ 98.226101] ehci_hcd 0000:02:03.0: resume root hub [ 98.226499] hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000 [ 98.247844] hub 1-0:1.0: hub_resume [ 98.249594] hub 1-0:1.0: state 7 ports 6 chg 0000 evt 0000 [ 99.453025] usb usb2: suspend_rh (auto-stop) [ 118.807147] e1000: peth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 118.346076] device peth0 entered promiscuous mode [ 119.104176] eth0: port 1(peth0) entering forwarding state [ 129.170323] eth0: no IPv6 routers present [ 129.607094] peth0: no IPv6 routers present [ 180.944579] alloc irq_desc for 432 on node 0 [ 180.944584] alloc kstat_irqs on node 0 [ 180.951443] alloc irq_desc for 433 on node 0 [ 180.951446] alloc kstat_irqs on node 0 [ 180.951457] suspend: event channel 27 [ 398.792388] kjournald starting. Commit interval 5 seconds [ 398.838106] EXT3 FS on sdb1, internal journal [ 398.838123] EXT3-fs: mounted filesystem with writeback data mode. [ 413.818582] device vif1.0 entered promiscuous mode [ 413.029060] eth0: port 2(vif1.0) entering forwarding state [ 413.911324] (cdrom_add_media_watch() file=drivers/xen/blkback/cdrom.c, line=108) nodename:backend/vbd/1/2049 [ 413.911353] (cdrom_is_type() file=drivers/xen/blkback/cdrom.c, line=95) type:0 [ 423.171717] vif1.0: no IPv6 routers present [ 474.792898] blkback: ring-ref 8, event-channel 10, protocol 1 (x86_64-abi) [ 474.792958] alloc irq_desc for 434 on node 0 [ 474.792960] alloc kstat_irqs on node 0 [ 474.805759] alloc irq_desc for 435 on node 0 [ 474.805762] alloc kstat_irqs on node 0 in Xend.log: ... 174 [2013-03-18 11:33:57 4422] DEBUG (XendDomainInfo:1891) XendDomainInfo.handleShutdownWatch 175 [2013-03-18 11:33:58 4422] DEBUG (DevController:139) Waiting for devices vif2. 176 [2013-03-18 11:33:58 4422] DEBUG (DevController:139) Waiting for devices vif. 177 [2013-03-18 11:33:58 4422] DEBUG (DevController:144) Waiting for 0. 178 [2013-03-18 11:33:58 4422] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status. 179 [2013-03-18 11:33:59 4422] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status. 180 [2013-03-18 11:33:59 4422] DEBUG (DevController:642) hotplugStatusCallback 1. 181 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vscsi. 182 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vbd. 183 [2013-03-18 11:33:59 4422] DEBUG (DevController:144) Waiting for 2049. 184 [2013-03-18 11:33:59 4422] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/1/2049/hotplug-stat us. 185 [2013-03-18 11:33:59 4422] DEBUG (DevController:642) hotplugStatusCallback 1. 186 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices ioports. 187 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices irq. 188 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vkbd. 189 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vfb. 190 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices console. 191 [2013-03-18 11:33:59 4422] DEBUG (DevController:144) Waiting for 0. 192 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices pci. 193 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices tap2. 194 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices tap. 195 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vusb. 196 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for devices vtpm. 197 [2013-03-18 11:33:59 4422] INFO (XendDomain:1206) Domain DomainU (1) unpaused. There is not any error or warning. SO how do I fix it? --e89a8f643372bab0d404d82ae289 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, ALL

I install Centos 5.5 and Xen 4.0 in my VMware VM= . The dom0 is OK, I can get vm list by "xm list", show bridge con= fig by "brctl show". Than I create a VM image, and try to start i= t. But when "xm create -c", the vm=A0=A0is paused. I do not know = why.

my config is:
=A0 1 # Kernel image file.=
=A0 2 kernel =3D "/boot/vmlinuz-2.6.31.8-xen"
=A0 3=A0
=A0 4 # Optional ramdisk.
=A0 5 # ramdisk = =3D "/boot/initrd-2.6.31.8-xen.img"
=A0 6 ramdisk =3D "/vm/initrd-2.6.31.8-xen.domu.img"
=A0 7=A0
=A0 8 memory =3D 512
=A0 9 name =3D "D= omainU"
=A010 vcpus =3D 1
=A011=A0
=A012= vif =3D [ '' ]
=A013=A0
=A014 ip =3D "192.168.1.2"
=A01= 5 netmask =3D "255.255.255.0"
=A016 gateway =3D "1= 92.168.1.1"
=A017=A0
=A018 isk =3D [ 'file:/vm= /domU.img,sda1,w' ]
=A019=A0
=A020 # Set root device.
=A021 root =3D &= quot;/dev/sda1 ro"


And p= rint is :
...
[ =A0 60.987475] XENBUS: Device with= no driver: device/console/0
[ =A0 62.494841] IP-Config: Complete:
[ =A0 62.494866] =A0 = =A0 =A0device=3Deth0, addr=3D192.168.1.2, mask=3D255.255.255.0, gw=3D192.16= 8.1.1,
[ =A0 62.494894] =A0 =A0 =A0host=3D192.168.1.2, domain=3D,= nis-domain=3D(none),
[ =A0 62.494907] =A0 =A0 =A0bootserver=3D127.0.255.255, rootserver=3D127.0.= 255.255, rootpath=3D
[ =A0 62.495267] Freeing unused kernel memor= y: 376k freed
[ =A0 62.496155] Write protecting the kernel read-o= nly data: 7556k
[ =A0 62.834612] ehci_hcd: USB 2.0 'Enhanced' Host Controller = (EHCI) Driver
[ =A0 62.842823] ohci_hcd: USB 1.1 'Open' H= ost Controller (OHCI) Driver
[ =A0 62.852827] uhci_hcd: USB Unive= rsal Host Controller Interface driver
[ =A0 62.981896] Fusion MPT base driver 3.04.10
[ =A0 62.983= 314] Copyright (c) 1999-2008 LSI Corporation
[ =A0 63.002120] Fus= ion MPT SPI Host driver 3.04.10
[ =A0 63.099169] kjournald starti= ng. =A0Commit interval 5 seconds
[ =A0 63.099201] EXT3-fs: mounted filesystem with writeback data mode.=
[ =A0 64.275946] hostname used greatest stack depth: 5728 bytes = left
[ =A0 64.347479] uname used greatest stack depth: 5576 bytes= left
[ =A0 64.518539] mount used greatest stack depth: 4408 bytes left

dmesg is:
...
[ =A0 79.= 645608] md: ... autorun DONE.
[ =A0 79.646727] nash used greatest= stack depth: 4400 bytes left
[ =A0 80.902473] EXT3 FS on sda3, internal journal
[ =A0 81.= 463346] kjournald starting. =A0Commit interval 5 seconds
[ =A0 81= .464179] EXT3 FS on sda2, internal journal
[ =A0 81.464192] EXT3-= fs: mounted filesystem with writeback data mode.
[ =A0 81.466375] kjournald starting. =A0Commit interval 5 seconds
[ =A0 81.467110] EXT3 FS on sda1, internal journal
[ =A0 81= .467123] EXT3-fs: mounted filesystem with writeback data mode.
[ = =A0 82.727149] rc.sysinit used greatest stack depth: 4200 bytes left
[ =A0 87.845535] e1000: eth0: e1000_set_tso: TSO is Enabled
= [ =A0 88.531915] warning: process `kudzu' used the deprecated sysctl sy= stem call with 1.23.
[ =A0 97.266951] warning: `dbus-daemon' = uses 32-bit capabilities (legacy support in use)
[ =A0 98.190488] usb usb2: usb auto-resume
[ =A0 98.190498] = usb usb2: wakeup_rh
[ =A0 98.225296] hub 2-0:1.0: hub_resume
[ =A0 98.225950] usb usb1: usb auto-resume
[ =A0 98.226101]= ehci_hcd 0000:02:03.0: resume root hub
[ =A0 98.226499] hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0000
<= div>[ =A0 98.247844] hub 1-0:1.0: hub_resume
[ =A0 98.249594] hub= 1-0:1.0: state 7 ports 6 chg 0000 evt 0000
[ =A0 99.453025] usb = usb2: suspend_rh (auto-stop)
[ =A0118.807147] e1000: peth0 NIC Link is Up 1000 Mbps Full Duplex, Fl= ow Control: None
[ =A0118.346076] device peth0 entered promiscuou= s mode
[ =A0119.104176] eth0: port 1(peth0) entering forwarding s= tate
[ =A0129.170323] eth0: no IPv6 routers present
[ =A0129.6070= 94] peth0: no IPv6 routers present
[ =A0180.944579] =A0 alloc irq= _desc for 432 on node 0
[ =A0180.944584] =A0 alloc kstat_irqs on = node 0
[ =A0180.951443] =A0 alloc irq_desc for 433 on node 0
[ =A01= 80.951446] =A0 alloc kstat_irqs on node 0
[ =A0180.951457] suspen= d: event channel 27
[ =A0398.792388] kjournald starting. =A0Commi= t interval 5 seconds
[ =A0398.838106] EXT3 FS on sdb1, internal journal
[ =A0398.= 838123] EXT3-fs: mounted filesystem with writeback data mode.
[ = =A0413.818582] device vif1.0 entered promiscuous mode
[ =A0413.02= 9060] eth0: port 2(vif1.0) entering forwarding state
[ =A0413.911324] (cdrom_add_media_watch() file=3Ddrivers/xen/blkback/c= drom.c, line=3D108) nodename:backend/vbd/1/2049
[ =A0413.911353] = (cdrom_is_type() file=3Ddrivers/xen/blkback/cdrom.c, line=3D95) type:0
[ =A0423.171717] vif1.0: no IPv6 routers present
[ =A0474.792898] blkback: ring-ref 8, event-channel 10, protocol 1 (x8= 6_64-abi)
[ =A0474.792958] =A0 alloc irq_desc for 434 on node 0
[ =A0474.792960] =A0 alloc kstat_irqs on node 0
[ =A0474= .805759] =A0 alloc irq_desc for 435 on node 0
[ =A0474.805762] =A0 alloc kstat_irqs on node 0

in Xend.log:
...
174 [2013-03-18 11:33:57= 4422] DEBUG (XendDomainInfo:1891) XendDomainInfo.handleShutdownWatch
175 [2013-03-18 11:33:58 4422] DEBUG (DevController:139) Waiting for d= evices vif2.
176 [2013-03-18 11:33:58 4422] DEBUG (DevController:= 139) Waiting for devices vif.
177 [2013-03-18 11:33:58 4422] DEBU= G (DevController:144) Waiting for 0.
178 [2013-03-18 11:33:58 4422] DEBUG (DevController:628) hotplugStatus= Callback /local/domain/0/backend/vif/1/0/hotplug-status.
179 [201= 3-03-18 11:33:59 4422] DEBUG (DevController:628) hotplugStatusCallback /loc= al/domain/0/backend/vif/1/0/hotplug-status.
180 [2013-03-18 11:33:59 4422] DEBUG (DevController:642) hotplugStatus= Callback 1.
181 [2013-03-18 11:33:59 4422] DEBUG (DevController:1= 39) Waiting for devices vscsi.
182 [2013-03-18 11:33:59 4422] DEB= UG (DevController:139) Waiting for devices vbd.
183 [2013-03-18 11:33:59 4422] DEBUG (DevController:144) Waiting for 2= 049.
184 [2013-03-18 11:33:59 4422] DEBUG (DevController:628) hot= plugStatusCallback /local/domain/0/backend/vbd/1/2049/hotplug-stat =A0 =A0u= s.
185 [2013-03-18 11:33:59 4422] DEBUG (DevController:642) hotplugStatus= Callback 1.
186 [2013-03-18 11:33:59 4422] DEBUG (DevController:1= 39) Waiting for devices ioports.
187 [2013-03-18 11:33:59 4422] D= EBUG (DevController:139) Waiting for devices irq.
188 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for d= evices vkbd.
189 [2013-03-18 11:33:59 4422] DEBUG (DevController:= 139) Waiting for devices vfb.
190 [2013-03-18 11:33:59 4422] DEBU= G (DevController:139) Waiting for devices console.
191 [2013-03-18 11:33:59 4422] DEBUG (DevController:144) Waiting for 0= .
192 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waitin= g for devices pci.
193 [2013-03-18 11:33:59 4422] DEBUG (DevContr= oller:139) Waiting for devices tap2.
194 [2013-03-18 11:33:59 4422] DEBUG (DevController:139) Waiting for d= evices tap.
195 [2013-03-18 11:33:59 4422] DEBUG (DevController:1= 39) Waiting for devices vusb.
196 [2013-03-18 11:33:59 4422] DEBU= G (DevController:139) Waiting for devices vtpm.
197 [2013-03-18 11:33:59 4422] INFO (XendDomain:1206) Domain DomainU (= 1) unpaused.

There is not any error or warni= ng. SO how do I fix it?
--e89a8f643372bab0d404d82ae289-- --===============3756310565365579030== 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 --===============3756310565365579030==-- From xen-users-bounces@lists.xen.org Mon Mar 18 05:05:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 05:05: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 1UHSFC-0002GA-KC; Mon, 18 Mar 2013 05:04:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHSFA-0002G5-Ms for xen-users@lists.xen.org; Mon, 18 Mar 2013 05:04:20 +0000 Received: from [193.109.254.147:40490] by server-3.bemta-14.messagelabs.com id 89/77-17488-350A6415; Mon, 18 Mar 2013 05:04:19 +0000 X-Env-Sender: pigeon@pigeond.net X-Msg-Ref: server-8.tower-27.messagelabs.com!1363583056!8783853!1 X-Originating-IP: [202.65.223.218] X-SpamReason: No, hits=1.8 required=7.0 tests=SUBJ_HAS_SPACES X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25515 invoked from network); 18 Mar 2013 05:04:18 -0000 Received: from static-ip-218-223-65-202.rev.dyxnet.com (HELO pan.pigeond.net) (202.65.223.218) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2013 05:04:18 -0000 Received: from saba.fluffyspider.com.au (eth5284.nsw.adsl.internode.on.net [150.101.116.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pan.pigeond.net (Postfix) with ESMTPSA id E1C1E137DD for ; Mon, 18 Mar 2013 13:04:13 +0800 (HKT) Date: Mon, 18 Mar 2013 16:04:09 +1100 From: Howell Tam To: "xen-users@lists.xen.org" Message-ID: <20130318160409.1a2cb341@saba.fluffyspider.com.au> In-Reply-To: References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> <20130317181429.41706fa6@114.40.77.101> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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, > may I take an educated guess: You only see the dom0 freeze when you > are hiding 2 vgas from dom0? I do have two VGA cards, but I have tested passing through only one card, using xl, without pciback.hide. > Also, we got a patch for the blankscreen-on-domU-restart thing if you > are still experiancing this.. Thanks, that's good to know. > Oh yeah, and one last thing: I don't know what git branch you are > using but they switched default qemu in unstable and the new > qemu-upstream has a bug so vga passthrough doesn't work with more then > 4GB of Ram assigned to a domU (bug described here: > http://lists.xen.org/archives/html/xen-devel/2013-03/msg00211.html ).. > so for the behaviour you are used to (using qemu-xen-traditional) you > have to now say that explicitly in your domU config) I've been testing with xen 4.2.1 from git (bb4d9534d139615190c752cb0b8a05ef39e2d84b). I guess I will some more tests with xl and qemu-traditional tonight. -- Regards, Howell. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 05:05:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 05:05: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 1UHSFC-0002GA-KC; Mon, 18 Mar 2013 05:04:22 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHSFA-0002G5-Ms for xen-users@lists.xen.org; Mon, 18 Mar 2013 05:04:20 +0000 Received: from [193.109.254.147:40490] by server-3.bemta-14.messagelabs.com id 89/77-17488-350A6415; Mon, 18 Mar 2013 05:04:19 +0000 X-Env-Sender: pigeon@pigeond.net X-Msg-Ref: server-8.tower-27.messagelabs.com!1363583056!8783853!1 X-Originating-IP: [202.65.223.218] X-SpamReason: No, hits=1.8 required=7.0 tests=SUBJ_HAS_SPACES X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25515 invoked from network); 18 Mar 2013 05:04:18 -0000 Received: from static-ip-218-223-65-202.rev.dyxnet.com (HELO pan.pigeond.net) (202.65.223.218) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2013 05:04:18 -0000 Received: from saba.fluffyspider.com.au (eth5284.nsw.adsl.internode.on.net [150.101.116.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pan.pigeond.net (Postfix) with ESMTPSA id E1C1E137DD for ; Mon, 18 Mar 2013 13:04:13 +0800 (HKT) Date: Mon, 18 Mar 2013 16:04:09 +1100 From: Howell Tam To: "xen-users@lists.xen.org" Message-ID: <20130318160409.1a2cb341@saba.fluffyspider.com.au> In-Reply-To: References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> <20130317181429.41706fa6@114.40.77.101> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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, > may I take an educated guess: You only see the dom0 freeze when you > are hiding 2 vgas from dom0? I do have two VGA cards, but I have tested passing through only one card, using xl, without pciback.hide. > Also, we got a patch for the blankscreen-on-domU-restart thing if you > are still experiancing this.. Thanks, that's good to know. > Oh yeah, and one last thing: I don't know what git branch you are > using but they switched default qemu in unstable and the new > qemu-upstream has a bug so vga passthrough doesn't work with more then > 4GB of Ram assigned to a domU (bug described here: > http://lists.xen.org/archives/html/xen-devel/2013-03/msg00211.html ).. > so for the behaviour you are used to (using qemu-xen-traditional) you > have to now say that explicitly in your domU config) I've been testing with xen 4.2.1 from git (bb4d9534d139615190c752cb0b8a05ef39e2d84b). I guess I will some more tests with xl and qemu-traditional tonight. -- Regards, Howell. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 08:35:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 08:35: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 1UHVVr-0005cx-FX; Mon, 18 Mar 2013 08:33:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHVVp-0005cs-Aj for xen-users@lists.xen.org; Mon, 18 Mar 2013 08:33:45 +0000 Received: from [85.158.138.51:39876] by server-9.bemta-3.messagelabs.com id 05/04-32531-861D6415; Mon, 18 Mar 2013 08:33:44 +0000 X-Env-Sender: falck.andreas.lists@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1363595623!27967282!1 X-Originating-IP: [209.85.217.176] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4566 invoked from network); 18 Mar 2013 08:33:43 -0000 Received: from mail-lb0-f176.google.com (HELO mail-lb0-f176.google.com) (209.85.217.176) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 08:33:43 -0000 Received: by mail-lb0-f176.google.com with SMTP id s4so4430704lbc.35 for ; Mon, 18 Mar 2013 01:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q3RaAd5MvmhUNFDaoFZUlHoFKRXH5k7LxPYqXJea3Tg=; b=a1FHCaOttmySofu2E8pOHY931tdtj4ghg4wofS4U+XXSQ293txsCZ+eFvOIZEIV9OI 3RO1MHkOvdNkeIqWyo1ph3Z6a+7yoOs1YRveSMhzavO2pbCLRjwm9+9FwxkWp04IdubR C7ggG/7J336Wfvhk5sRwSx1ezySqJrNbebR3zK+gQ++yZT4zF88pM3gRss49u9imr9Jg zekhKYPginplFClWpkYmgmzY3GnlUxb4HhQRIlE/okJDeHgnEOJHkhzes2+T2IkDkUVH Zr2JpMkJQe41LQRP0tT8k067/lgd6zvHjswwusZRJUj2Q06MF3eSu9IAvnB0tyuhL11t jOGw== MIME-Version: 1.0 X-Received: by 10.112.40.36 with SMTP id u4mr4385748lbk.36.1363595622633; Mon, 18 Mar 2013 01:33:42 -0700 (PDT) Received: by 10.114.21.230 with HTTP; Mon, 18 Mar 2013 01:33:42 -0700 (PDT) In-Reply-To: <20130317181429.41706fa6@114.40.77.101> References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> <20130317181429.41706fa6@114.40.77.101> Date: Mon, 18 Mar 2013 09:33:42 +0100 Message-ID: From: Andreas Falck To: Howell Tam Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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="===============7601318578935360859==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7601318578935360859== Content-Type: multipart/alternative; boundary=e0cb4efe3014b4597504d82ed8a7 --e0cb4efe3014b4597504d82ed8a7 Content-Type: text/plain; charset=ISO-8859-1 Hi, My experience so far is also that xl gives more problems for VGA passthru compared to xm. I have only tried xen <= 4.1, first 4.1.2 with xl on gentoo and then 4.1.2 and 4.1.3 with xm on ubuntu. My problems with xl were different from yours though, I experienced the performance degradation issue (http://lists.xen.org/archives/html/xen-users/2012-02/msg00443.html), which could be solved as indicated in the post. This did not happen with xm on ubuntu (win7-64 vm in both cases, radeon 6850). But the performance issue might also be unrelated to the blank screen issue. If the issues are related though, it might have to do with how xm vs xl handles resetting the card at VM reboot. It could lead to different issues with different cards, which would explain our different problems. Regards, Andreas 2013/3/17 Howell Tam > > Hi all again, > > > > > have you found a solution for this behaviour? Cause I'm currently > > > seeing a similar result with my installation. > > > I've been away for a few weeks and I'm finally back on trying to > figure > out this problem. > > > I was using xl + xl pci-assignable-add when I get the full > machine freeze when I reboot the domU windows7. > > > I just tried with the same domu config file, but with xm + > pci-stub, and I do not seem to get the freeze (yet, so far 3 > reboots/shutdowns). > > > The VGA passthrough (an HD7770) is still working even after the > reboot (i.e. no more blank screen). > > > This is semi-good news. If the bug is in xl, then I guess we > will have to debug this since xm is deprecated. > > > -- > Regards, > Howell. > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --e0cb4efe3014b4597504d82ed8a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

My experience so far is also that xl gives more problems for VGA= passthru compared to xm. I have only tried xen <=3D 4.1, first 4.1.2 wi= th xl on gentoo and then 4.1.2 and 4.1.3 with xm on ubuntu. My problems wit= h xl were different from yours though, I experienced the performance degrad= ation issue (http://lists.xen.org/archives/html/xen-users/2012-02/msg00= 443.html), which could be solved as indicated in the post. This did not= happen with xm on ubuntu (win7-64 vm in both cases, radeon 6850).

But the performance issue might also be unrelated to the blank screen i= ssue. If the issues are related though, it might have to do with how xm vs = xl handles resetting the card at VM reboot. It could lead to different issu= es with different cards, which would explain our different problems.

Regards,
Andreas

2013/3/17 Howell = Tam <pigeon@pigeond.net>

Hi all again,


> > have you found a solution for this behaviour? Cause I'm curre= ntly
> > seeing a similar result with my installation.


=A0 =A0 =A0 =A0 I've been away for a few weeks and I'm finall= y back on trying to figure
out this problem.


=A0 =A0 =A0 =A0 I was using xl + xl pci-assignable-add when I get the full<= br> machine freeze when I reboot the domU windows7.


=A0 =A0 =A0 =A0 I just tried with the same domu config file, but with xm +<= br> pci-stub, and I do not seem to get the freeze (yet, so far 3 reboots/shutdo= wns).


=A0 =A0 =A0 =A0 The VGA passthrough (an HD7770) is still working even after= the
reboot (i.e. no more blank screen).


=A0 =A0 =A0 =A0 This is semi-good news. If the bug is in xl, then I guess w= e
will have to debug this since xm is deprecated.


--
Regards,
Howell.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--e0cb4efe3014b4597504d82ed8a7-- --===============7601318578935360859== 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 --===============7601318578935360859==-- From xen-users-bounces@lists.xen.org Mon Mar 18 08:35:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 08:35: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 1UHVVr-0005cx-FX; Mon, 18 Mar 2013 08:33:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHVVp-0005cs-Aj for xen-users@lists.xen.org; Mon, 18 Mar 2013 08:33:45 +0000 Received: from [85.158.138.51:39876] by server-9.bemta-3.messagelabs.com id 05/04-32531-861D6415; Mon, 18 Mar 2013 08:33:44 +0000 X-Env-Sender: falck.andreas.lists@gmail.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1363595623!27967282!1 X-Originating-IP: [209.85.217.176] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4566 invoked from network); 18 Mar 2013 08:33:43 -0000 Received: from mail-lb0-f176.google.com (HELO mail-lb0-f176.google.com) (209.85.217.176) by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 08:33:43 -0000 Received: by mail-lb0-f176.google.com with SMTP id s4so4430704lbc.35 for ; Mon, 18 Mar 2013 01:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q3RaAd5MvmhUNFDaoFZUlHoFKRXH5k7LxPYqXJea3Tg=; b=a1FHCaOttmySofu2E8pOHY931tdtj4ghg4wofS4U+XXSQ293txsCZ+eFvOIZEIV9OI 3RO1MHkOvdNkeIqWyo1ph3Z6a+7yoOs1YRveSMhzavO2pbCLRjwm9+9FwxkWp04IdubR C7ggG/7J336Wfvhk5sRwSx1ezySqJrNbebR3zK+gQ++yZT4zF88pM3gRss49u9imr9Jg zekhKYPginplFClWpkYmgmzY3GnlUxb4HhQRIlE/okJDeHgnEOJHkhzes2+T2IkDkUVH Zr2JpMkJQe41LQRP0tT8k067/lgd6zvHjswwusZRJUj2Q06MF3eSu9IAvnB0tyuhL11t jOGw== MIME-Version: 1.0 X-Received: by 10.112.40.36 with SMTP id u4mr4385748lbk.36.1363595622633; Mon, 18 Mar 2013 01:33:42 -0700 (PDT) Received: by 10.114.21.230 with HTTP; Mon, 18 Mar 2013 01:33:42 -0700 (PDT) In-Reply-To: <20130317181429.41706fa6@114.40.77.101> References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> <20130317181429.41706fa6@114.40.77.101> Date: Mon, 18 Mar 2013 09:33:42 +0100 Message-ID: From: Andreas Falck To: Howell Tam Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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="===============7601318578935360859==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7601318578935360859== Content-Type: multipart/alternative; boundary=e0cb4efe3014b4597504d82ed8a7 --e0cb4efe3014b4597504d82ed8a7 Content-Type: text/plain; charset=ISO-8859-1 Hi, My experience so far is also that xl gives more problems for VGA passthru compared to xm. I have only tried xen <= 4.1, first 4.1.2 with xl on gentoo and then 4.1.2 and 4.1.3 with xm on ubuntu. My problems with xl were different from yours though, I experienced the performance degradation issue (http://lists.xen.org/archives/html/xen-users/2012-02/msg00443.html), which could be solved as indicated in the post. This did not happen with xm on ubuntu (win7-64 vm in both cases, radeon 6850). But the performance issue might also be unrelated to the blank screen issue. If the issues are related though, it might have to do with how xm vs xl handles resetting the card at VM reboot. It could lead to different issues with different cards, which would explain our different problems. Regards, Andreas 2013/3/17 Howell Tam > > Hi all again, > > > > > have you found a solution for this behaviour? Cause I'm currently > > > seeing a similar result with my installation. > > > I've been away for a few weeks and I'm finally back on trying to > figure > out this problem. > > > I was using xl + xl pci-assignable-add when I get the full > machine freeze when I reboot the domU windows7. > > > I just tried with the same domu config file, but with xm + > pci-stub, and I do not seem to get the freeze (yet, so far 3 > reboots/shutdowns). > > > The VGA passthrough (an HD7770) is still working even after the > reboot (i.e. no more blank screen). > > > This is semi-good news. If the bug is in xl, then I guess we > will have to debug this since xm is deprecated. > > > -- > Regards, > Howell. > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --e0cb4efe3014b4597504d82ed8a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

My experience so far is also that xl gives more problems for VGA= passthru compared to xm. I have only tried xen <=3D 4.1, first 4.1.2 wi= th xl on gentoo and then 4.1.2 and 4.1.3 with xm on ubuntu. My problems wit= h xl were different from yours though, I experienced the performance degrad= ation issue (http://lists.xen.org/archives/html/xen-users/2012-02/msg00= 443.html), which could be solved as indicated in the post. This did not= happen with xm on ubuntu (win7-64 vm in both cases, radeon 6850).

But the performance issue might also be unrelated to the blank screen i= ssue. If the issues are related though, it might have to do with how xm vs = xl handles resetting the card at VM reboot. It could lead to different issu= es with different cards, which would explain our different problems.

Regards,
Andreas

2013/3/17 Howell = Tam <pigeon@pigeond.net>

Hi all again,


> > have you found a solution for this behaviour? Cause I'm curre= ntly
> > seeing a similar result with my installation.


=A0 =A0 =A0 =A0 I've been away for a few weeks and I'm finall= y back on trying to figure
out this problem.


=A0 =A0 =A0 =A0 I was using xl + xl pci-assignable-add when I get the full<= br> machine freeze when I reboot the domU windows7.


=A0 =A0 =A0 =A0 I just tried with the same domu config file, but with xm +<= br> pci-stub, and I do not seem to get the freeze (yet, so far 3 reboots/shutdo= wns).


=A0 =A0 =A0 =A0 The VGA passthrough (an HD7770) is still working even after= the
reboot (i.e. no more blank screen).


=A0 =A0 =A0 =A0 This is semi-good news. If the bug is in xl, then I guess w= e
will have to debug this since xm is deprecated.


--
Regards,
Howell.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--e0cb4efe3014b4597504d82ed8a7-- --===============7601318578935360859== 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 --===============7601318578935360859==-- From xen-users-bounces@lists.xen.org Mon Mar 18 08:35:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 08:35: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 1UHVWR-0005eS-4X; Mon, 18 Mar 2013 08:34:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHVWQ-0005eN-7e for xen-users@lists.xen.org; Mon, 18 Mar 2013 08:34:22 +0000 Received: from [85.158.143.99:10644] by server-3.bemta-4.messagelabs.com id 23/12-02186-D81D6415; Mon, 18 Mar 2013 08:34:21 +0000 X-Env-Sender: almir@kadric.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1363595659!27282398!1 X-Originating-IP: [67.23.45.131] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9064 invoked from network); 18 Mar 2013 08:34:19 -0000 Received: from kadricenterprises.com (HELO kadricenterprises.com) (67.23.45.131) by server-15.tower-216.messagelabs.com with SMTP; 18 Mar 2013 08:34:19 -0000 Received: from [192.168.2.234] (113x33x180x18.ap113.ftth.ucom.ne.jp [113.33.180.18]) by kadricenterprises.com (Postfix) with ESMTP id 9113F4800C7 for ; Mon, 18 Mar 2013 08:26:41 +0000 (UTC) From: Almir Kadric Date: Mon, 18 Mar 2013 17:34:16 +0900 Message-Id: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> To: xen-users@lists.xen.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============8970837345133525979==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8970837345133525979== Content-Type: multipart/alternative; boundary="Apple-Mail=_D165A701-D042-4A3B-98E8-9E1F5F6FD644" --Apple-Mail=_D165A701-D042-4A3B-98E8-9E1F5F6FD644 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I'm coming from a lxc background and recently found a real need for a = full virtualised windows solution. In the past I have stuck it out with = Linux, but Wine just hasn't been performing and I've had nothing but = problems. Anyways I tried a few things, and just could not get XEN to = work for the life of me. I got KVM working but VGA passthrough was a = pain, I could never get it to accept a device, even after I blacklisted = it. Eventually I got around to XEN as it is supposed to do this better, = however I could not get past the first stage ... a simple minimal = virtual machine. No matter what I did, no matter which distro (Debian = 6,7 and Ubuntu 12.10) my Host (dom0) would either reboot or lockup. I = tried looking for errors in messages, kernel, xen/* but nothing really = stood out. So my question would be what am I missing? What logs should I be looking = at? I managed to fix the small bugs which popped up like files being in = wrong places etc. Lastly I ran this using xm create and after = that it would just hang. Machine would become unresponsive, or reboot. Also I did look around if anyone was having these problems, and found a = few threads with the exact same issue, but no answers so far. http://lists.debian.org/debian-user/2011/12/msg01779.html = http://xen.markmail.org/search/?q=3DGA-970A#query:GA-970A+page:1+mid:fwgjn= zmfy4pylgiu+state:results I would really appreciate some help to just be able to start the machine = with nothing fancy then I could possibly take it from there. Also if anyone has any good links to guides for successful setups = compiling from source, preferably on Debian installation. Don't get me = wrong, I'm no Linux dummy, just would be nice to have something that = proven to work before I start stabbing around. I've been working on this on and off for about a week, and quite frankly = feel extremely defeated by it =3D_=3D To help you understand what I may have done wrong I will attach some = information below: System: Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) CPU: AMD FX 8300 @ 3.3GHz GPU: Powercolor ATI Radeon 5970 RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 Setups tried: All were done with a Windows 7 x86_64 guest VM Debian 6: Standard bridge. Installed xen-linux-system, in-fact I = followed the official guide http://wiki.debian.org/Xen and quite a few = others. Debian 7: same as above, found more guides etc Above 2 would crash and just become plain unresponsive Ubuntu 12.10: Similar, instead followed ubuntu related guides This one would reboot the dom0 Things I tried or did do before you ask them: - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) - Enabled IOMMU via kernel options as per XEN wiki documents (referenced = these a lot). - Made sure that svm was enabled during kernel boot (xm dmsg) - Made sure that IOMMU was enabled during kernel boot (xm dmsg), however = this behaved a bit wierd, so i didnt use pci pass through right off the = bat. Well again I couldnt even start the vm so no point. Things I didn't try: - Compile XEN kernel and dom0 kernel from source My HVM config: (Though I technically tried a few different combinations from different = guide, including some very minimal ones) name =3D 'xenvm1' kernel =3D '/usr/lib/xen-4.0/boot/hvmloader' builder =3D 'hvm' memory =3D '34096' shadow_memory =3D '8' device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm' disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef'] boot=3D'dc' vnc=3D1 vncviewer=3D0 sdl=3D0 vcpus=3D4 usbdevice=3D'tablet' on_poweroff =3D 'destroy' on_reboot =3D 'restart' on_crash =3D 'restart' Best Regards, Almir kadric= --Apple-Mail=_D165A701-D042-4A3B-98E8-9E1F5F6FD644 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://= lists.debian.org/debian-user/2011/12/msg01779.html

I would really appreciate some help to just be able to = start the machine with nothing fancy then I could possibly take it from = there.
Also if anyone has any good links to guides for = successful setups compiling from source, preferably on Debian = installation. Don't get me wrong, I'm no Linux dummy, just would be nice = to have something that proven to work before I start stabbing = around.

I've been working on this on and off = for about a week, and quite frankly feel extremely defeated by it = =3D_=3D

To help you understand what I may have = done wrong I will attach some information = below:

System:
Motherboard: = GA-970A-D3 (rev 1.3, BIOS F10)
CPU: AMD FX 8300 @ = 3.3GHz
GPU: Powercolor ATI Radeon 5970
RAM: 16GB = Corsair CML16GX3M2A1600C10B @ = 1333

Setups tried:
All were = done with a Windows 7 x86_64 guest = VM

Debian 6: Standard bridge. Installed = xen-linux-system, in-fact I followed the official guide http://wiki.debian.org/Xen an= d quite a few others.
Debian 7: same as above, found more = guides etc
Above 2 would crash and just become plain = unresponsive

Ubuntu 12.10: Similar, instead = followed ubuntu related guides
This one would reboot the = dom0

Things I tried or did do before you ask = them:
- Yes I booted into the XEN kernel (Linux x.y.z with = XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki = documents (referenced these a lot).
- Made sure that svm was = enabled during kernel boot (xm dmsg)
- Made sure that IOMMU = was enabled during kernel boot (xm dmsg), however this behaved a bit = wierd, so i didnt use pci pass through right off the bat. Well again I = couldnt even start the vm so no = point.

Things I didn't try:
- = Compile XEN kernel and dom0 kernel from = source

My HVM = config:
(Though I technically tried a few different = combinations from different guide, including some very minimal = ones)
Best Regards,
Almir kadric
= --Apple-Mail=_D165A701-D042-4A3B-98E8-9E1F5F6FD644-- --===============8970837345133525979== 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 --===============8970837345133525979==-- From xen-users-bounces@lists.xen.org Mon Mar 18 08:35:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 08:35: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 1UHVWR-0005eS-4X; Mon, 18 Mar 2013 08:34:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHVWQ-0005eN-7e for xen-users@lists.xen.org; Mon, 18 Mar 2013 08:34:22 +0000 Received: from [85.158.143.99:10644] by server-3.bemta-4.messagelabs.com id 23/12-02186-D81D6415; Mon, 18 Mar 2013 08:34:21 +0000 X-Env-Sender: almir@kadric.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1363595659!27282398!1 X-Originating-IP: [67.23.45.131] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9064 invoked from network); 18 Mar 2013 08:34:19 -0000 Received: from kadricenterprises.com (HELO kadricenterprises.com) (67.23.45.131) by server-15.tower-216.messagelabs.com with SMTP; 18 Mar 2013 08:34:19 -0000 Received: from [192.168.2.234] (113x33x180x18.ap113.ftth.ucom.ne.jp [113.33.180.18]) by kadricenterprises.com (Postfix) with ESMTP id 9113F4800C7 for ; Mon, 18 Mar 2013 08:26:41 +0000 (UTC) From: Almir Kadric Date: Mon, 18 Mar 2013 17:34:16 +0900 Message-Id: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> To: xen-users@lists.xen.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============8970837345133525979==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8970837345133525979== Content-Type: multipart/alternative; boundary="Apple-Mail=_D165A701-D042-4A3B-98E8-9E1F5F6FD644" --Apple-Mail=_D165A701-D042-4A3B-98E8-9E1F5F6FD644 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I'm coming from a lxc background and recently found a real need for a = full virtualised windows solution. In the past I have stuck it out with = Linux, but Wine just hasn't been performing and I've had nothing but = problems. Anyways I tried a few things, and just could not get XEN to = work for the life of me. I got KVM working but VGA passthrough was a = pain, I could never get it to accept a device, even after I blacklisted = it. Eventually I got around to XEN as it is supposed to do this better, = however I could not get past the first stage ... a simple minimal = virtual machine. No matter what I did, no matter which distro (Debian = 6,7 and Ubuntu 12.10) my Host (dom0) would either reboot or lockup. I = tried looking for errors in messages, kernel, xen/* but nothing really = stood out. So my question would be what am I missing? What logs should I be looking = at? I managed to fix the small bugs which popped up like files being in = wrong places etc. Lastly I ran this using xm create and after = that it would just hang. Machine would become unresponsive, or reboot. Also I did look around if anyone was having these problems, and found a = few threads with the exact same issue, but no answers so far. http://lists.debian.org/debian-user/2011/12/msg01779.html = http://xen.markmail.org/search/?q=3DGA-970A#query:GA-970A+page:1+mid:fwgjn= zmfy4pylgiu+state:results I would really appreciate some help to just be able to start the machine = with nothing fancy then I could possibly take it from there. Also if anyone has any good links to guides for successful setups = compiling from source, preferably on Debian installation. Don't get me = wrong, I'm no Linux dummy, just would be nice to have something that = proven to work before I start stabbing around. I've been working on this on and off for about a week, and quite frankly = feel extremely defeated by it =3D_=3D To help you understand what I may have done wrong I will attach some = information below: System: Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) CPU: AMD FX 8300 @ 3.3GHz GPU: Powercolor ATI Radeon 5970 RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 Setups tried: All were done with a Windows 7 x86_64 guest VM Debian 6: Standard bridge. Installed xen-linux-system, in-fact I = followed the official guide http://wiki.debian.org/Xen and quite a few = others. Debian 7: same as above, found more guides etc Above 2 would crash and just become plain unresponsive Ubuntu 12.10: Similar, instead followed ubuntu related guides This one would reboot the dom0 Things I tried or did do before you ask them: - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) - Enabled IOMMU via kernel options as per XEN wiki documents (referenced = these a lot). - Made sure that svm was enabled during kernel boot (xm dmsg) - Made sure that IOMMU was enabled during kernel boot (xm dmsg), however = this behaved a bit wierd, so i didnt use pci pass through right off the = bat. Well again I couldnt even start the vm so no point. Things I didn't try: - Compile XEN kernel and dom0 kernel from source My HVM config: (Though I technically tried a few different combinations from different = guide, including some very minimal ones) name =3D 'xenvm1' kernel =3D '/usr/lib/xen-4.0/boot/hvmloader' builder =3D 'hvm' memory =3D '34096' shadow_memory =3D '8' device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm' disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef'] boot=3D'dc' vnc=3D1 vncviewer=3D0 sdl=3D0 vcpus=3D4 usbdevice=3D'tablet' on_poweroff =3D 'destroy' on_reboot =3D 'restart' on_crash =3D 'restart' Best Regards, Almir kadric= --Apple-Mail=_D165A701-D042-4A3B-98E8-9E1F5F6FD644 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://= lists.debian.org/debian-user/2011/12/msg01779.html

I would really appreciate some help to just be able to = start the machine with nothing fancy then I could possibly take it from = there.
Also if anyone has any good links to guides for = successful setups compiling from source, preferably on Debian = installation. Don't get me wrong, I'm no Linux dummy, just would be nice = to have something that proven to work before I start stabbing = around.

I've been working on this on and off = for about a week, and quite frankly feel extremely defeated by it = =3D_=3D

To help you understand what I may have = done wrong I will attach some information = below:

System:
Motherboard: = GA-970A-D3 (rev 1.3, BIOS F10)
CPU: AMD FX 8300 @ = 3.3GHz
GPU: Powercolor ATI Radeon 5970
RAM: 16GB = Corsair CML16GX3M2A1600C10B @ = 1333

Setups tried:
All were = done with a Windows 7 x86_64 guest = VM

Debian 6: Standard bridge. Installed = xen-linux-system, in-fact I followed the official guide http://wiki.debian.org/Xen an= d quite a few others.
Debian 7: same as above, found more = guides etc
Above 2 would crash and just become plain = unresponsive

Ubuntu 12.10: Similar, instead = followed ubuntu related guides
This one would reboot the = dom0

Things I tried or did do before you ask = them:
- Yes I booted into the XEN kernel (Linux x.y.z with = XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki = documents (referenced these a lot).
- Made sure that svm was = enabled during kernel boot (xm dmsg)
- Made sure that IOMMU = was enabled during kernel boot (xm dmsg), however this behaved a bit = wierd, so i didnt use pci pass through right off the bat. Well again I = couldnt even start the vm so no = point.

Things I didn't try:
- = Compile XEN kernel and dom0 kernel from = source

My HVM = config:
(Though I technically tried a few different = combinations from different guide, including some very minimal = ones)
Best Regards,
Almir kadric
= --Apple-Mail=_D165A701-D042-4A3B-98E8-9E1F5F6FD644-- --===============8970837345133525979== 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 --===============8970837345133525979==-- From xen-users-bounces@lists.xen.org Mon Mar 18 09:00:31 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09:00: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 1UHVuq-0006ip-Le; Mon, 18 Mar 2013 08:59:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHVup-0006ik-1T for xen-users@lists.xen.org; Mon, 18 Mar 2013 08:59:35 +0000 Received: from [85.158.143.99:52206] by server-3.bemta-4.messagelabs.com id 1E/89-02186-677D6415; Mon, 18 Mar 2013 08:59:34 +0000 X-Env-Sender: falck.andreas.lists@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363597171!22058102!1 X-Originating-IP: [209.85.217.179] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29483 invoked from network); 18 Mar 2013 08:59:32 -0000 Received: from mail-lb0-f179.google.com (HELO mail-lb0-f179.google.com) (209.85.217.179) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 08:59:32 -0000 Received: by mail-lb0-f179.google.com with SMTP id j14so4454209lbo.10 for ; Mon, 18 Mar 2013 01:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=T1odBW6YAbkn/ycQhlkrL5ofF89QzbevbQGCv2edJy8=; b=tXgmvzjEZDPMaAqKD1n77PvdSl8iOY+1FYQs+WCxujTTW5WWMX1jgSmMnJBFHyZHdY LlfVax7Vv7Ms4HppEHZnCTxFZ9SsQQ7N0q44CAtzhEHxzP1TAF6OUIf/OXXOms6ffcQz 4pGMZYxU4o8LI2aAr6Y6QL/SD0oI/znovKL0CvEAjAEW0O0vbiLsmgk+dRj6tf7OfXhp wZf8rxqMBIlqbAiqLlwjhYHC94vKl+UymbcJgrgkX56VcHWpE5rO3zriYHbPevP6m+la hH8QEAModYjp1WfPvnJh5hKCDKVDbY/S6fGDkOmBOawAeIrGiup1qw1BIN4ZCEd5TCjY CHqw== MIME-Version: 1.0 X-Received: by 10.112.17.196 with SMTP id q4mr5841043lbd.21.1363597171337; Mon, 18 Mar 2013 01:59:31 -0700 (PDT) Received: by 10.114.21.230 with HTTP; Mon, 18 Mar 2013 01:59:31 -0700 (PDT) In-Reply-To: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> Date: Mon, 18 Mar 2013 09:59:31 +0100 Message-ID: From: Andreas Falck To: Almir Kadric Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============1295709746335891842==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1295709746335891842== Content-Type: multipart/alternative; boundary=bcaec554044c03b24a04d82f3512 --bcaec554044c03b24a04d82f3512 Content-Type: text/plain; charset=ISO-8859-1 Hi, Sounds like you have been testing extensively. If I get you right, dom0 freezes or reboots when you try to start the VM, but works otherwise? I assume you have tried with IOMMU disabled in bios too? In case of a buggy bios, turning IOMMU off could possibly make a difference (in order to find the problem, I realize that you plan to use IOMMU). Also, I assume that memory = '34096' Is a typo? Since you say that you have tried different vm configs. Regards, Andreas 2013/3/18 Almir Kadric > Hi all, > > I'm coming from a lxc background and recently found a real need for a full > virtualised windows solution. In the past I have stuck it out with Linux, > but Wine just hasn't been performing and I've had nothing but problems. > Anyways I tried a few things, and just could not get XEN to work for the > life of me. I got KVM working but VGA passthrough was a pain, I could never > get it to accept a device, even after I blacklisted it. Eventually I got > around to XEN as it is supposed to do this better, however I could not get > past the first stage ... a simple minimal virtual machine. No matter what I > did, no matter which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) > would either reboot or lockup. I tried looking for errors in messages, > kernel, xen/* but nothing really stood out. > > So my question would be what am I missing? What logs should I be looking > at? > > I managed to fix the small bugs which popped up like files being in wrong > places etc. Lastly I ran this using xm create and after that it > would just hang. Machine would become unresponsive, or reboot. > > Also I did look around if anyone was having these problems, and found a > few threads with the exact same issue, but no answers so far. > http://lists.debian.org/debian-user/2011/12/msg01779.html > > http://xen.markmail.org/search/?q=GA-970A#query:GA-970A+page:1+mid:fwgjnzmfy4pylgiu+state:results > > I would really appreciate some help to just be able to start the machine > with nothing fancy then I could possibly take it from there. > Also if anyone has any good links to guides for successful setups > compiling from source, preferably on Debian installation. Don't get me > wrong, I'm no Linux dummy, just would be nice to have something that proven > to work before I start stabbing around. > > I've been working on this on and off for about a week, and quite frankly > feel extremely defeated by it =_= > > To help you understand what I may have done wrong I will attach some > information below: > > *System:* > Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) > CPU: AMD FX 8300 @ 3.3GHz > GPU: Powercolor ATI Radeon 5970 > RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 > > *Setups tried:* > All were done with a Windows 7 x86_64 guest VM > * > * > Debian 6: Standard bridge. Installed xen-linux-system, in-fact I followed > the official guide http://wiki.debian.org/Xen and quite a few others. > Debian 7: same as above, found more guides etc > Above 2 would crash and just become plain unresponsive > > Ubuntu 12.10: Similar, instead followed ubuntu related guides > This one would reboot the dom0 > > *Things I tried or did do before you ask them:* > - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) > - Enabled IOMMU via kernel options as per XEN wiki documents (referenced > these a lot). > - Made sure that svm was enabled during kernel boot (xm dmsg) > - Made sure that IOMMU was enabled during kernel boot (xm dmsg), however > this behaved a bit wierd, so i didnt use pci pass through right off the > bat. Well again I couldnt even start the vm so no point. > > *Things I didn't try:* > - Compile XEN kernel and dom0 kernel from source > > *My HVM config:* > *(Though I technically tried a few different combinations from different > guide, including some very minimal ones)* > > name = 'xenvm1' > > kernel = '/usr/lib/xen-4.0/boot/hvmloader' > builder = 'hvm' > memory = '34096' > shadow_memory = '8' > device_model='/usr/lib/xen-4.0/bin/qemu-dm' > disk = [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] > vif = ['bridge=br0, mac=01:23:de:ad:be:ef'] > boot='dc' > vnc=1 > vncviewer=0 > sdl=0 > vcpus=4 > usbdevice='tablet' > on_poweroff = 'destroy' > on_reboot = 'restart' > on_crash = 'restart' > > > > Best Regards, > Almir kadric > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --bcaec554044c03b24a04d82f3512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Sounds like you have been testing extensively. If I get you righ= t, dom0 freezes or reboots when you try to start the VM, but works otherwis= e?

I assume you have tried with IOMMU disabled in bios too? In case = of a buggy bios, turning IOMMU off could possibly make a difference (in ord= er to find the problem, I realize that you plan to use IOMMU).

Also, I assume that 

memory =3D '34096'

Is a typo? Since you say that you h= ave tried different vm configs.

Regards,
Andreas


2013/= 3/18 Almir Kadric <almir@kadric.com>
Hi all,

I'm coming fro= m a lxc background and recently found a real need for a full virtualised wi= ndows solution. In the past I have stuck it out with Linux, but Wine just h= asn't been performing and I've had nothing but problems. Anyways I = tried a few things, and just could not get XEN to work for the life of me. = I got KVM working but VGA passthrough was a pain, I could never get it to a= ccept a device, even after I blacklisted it. Eventually I got around to XEN= as it is supposed to do this better, however I could not get past the firs= t stage ... a simple minimal virtual machine. No matter what I did, no matt= er which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) would either r= eboot or lockup. I tried looking for errors in messages, kernel, xen/* but = nothing really stood out.

So my question would be what am I missing? What logs sh= ould I be looking at?

I managed to fix the small b= ugs which popped up like files being in wrong places etc. Lastly I ran this= using xm create <config> and after that it would just hang. Machine = would become unresponsive, or reboot.

Also I did look around if anyone was having these probl= ems, and found a few threads with the exact same issue, but no answers so f= ar.

I would really appreciate some help to just be able to = start the machine with nothing fancy then I could possibly take it from the= re.
Also if anyone has any good links to guides for successful se= tups compiling from source, preferably on Debian installation. Don't ge= t me wrong, I'm no Linux dummy, just would be nice to have something th= at proven to work before I start stabbing around.

I've been working on this on and off for about a we= ek, and quite frankly feel extremely defeated by it =3D_=3D

<= /div>
To help you understand what I may have done wrong I will attach s= ome information below:

System:
Motherboard: GA-970A-D3 (rev 1= .3, BIOS F10)
CPU: AMD FX 8300 @ 3.3GHz
GPU: Powercolor= ATI Radeon 5970
RAM: 16GB Corsair=A0CML16GX3M2A1600C10B @ 1333

Setups tried:
All were done with a Win= dows 7 x86_64 guest VM

Debian 6: Standard b= ridge. Installed xen-linux-system, in-fact I followed the official guide=A0= http://wiki.debian= .org/Xen=A0and=A0quite a few others.
Debian 7: same as above, found more guides etc
Above 2 would= crash and just become plain unresponsive

Ubuntu 1= 2.10: Similar, instead followed ubuntu related guides
This one wo= uld reboot the dom0

Things I tried or did do before you ask them:
- Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki documents (refere= nced these a lot).
- Made sure that svm was enabled during kernel boot (xm dmsg)
- Made sure that IOMMU was enabled during kernel boot (xm dmsg), however = this behaved a bit wierd, so i didnt use pci pass through right off the bat= . Well again I couldnt even start the vm so no point.

Things I didn't try:
- Compile XEN= kernel and dom0 kernel from source

My HVM conf= ig:
(Though I technically tried a few different combinatio= ns from different guide, including some very minimal ones)
name =3D 'xenvm1'

kernel =3D '/usr/lib/xen-4.0/boot/hvmloader'
builder =3D 'hvm'
memory =3D '34096'
shadow_memory =3D '8'
device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm'
disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ]
vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef']
boot=3D'dc'
vnc=3D1
vncviewer=3D0
sdl=3D0
vcpus=3D4
usbdevice=3D'tablet'
on_poweroff =3D 'destroy'
on_reboot =3D 'restart'
on_crash =3D 'restart'


Best Regards,
Almir kadric

____________= ___________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--bcaec554044c03b24a04d82f3512-- --===============1295709746335891842== 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 --===============1295709746335891842==-- From xen-users-bounces@lists.xen.org Mon Mar 18 09:00:31 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09:00: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 1UHVuq-0006ip-Le; Mon, 18 Mar 2013 08:59:36 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHVup-0006ik-1T for xen-users@lists.xen.org; Mon, 18 Mar 2013 08:59:35 +0000 Received: from [85.158.143.99:52206] by server-3.bemta-4.messagelabs.com id 1E/89-02186-677D6415; Mon, 18 Mar 2013 08:59:34 +0000 X-Env-Sender: falck.andreas.lists@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363597171!22058102!1 X-Originating-IP: [209.85.217.179] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29483 invoked from network); 18 Mar 2013 08:59:32 -0000 Received: from mail-lb0-f179.google.com (HELO mail-lb0-f179.google.com) (209.85.217.179) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 08:59:32 -0000 Received: by mail-lb0-f179.google.com with SMTP id j14so4454209lbo.10 for ; Mon, 18 Mar 2013 01:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=T1odBW6YAbkn/ycQhlkrL5ofF89QzbevbQGCv2edJy8=; b=tXgmvzjEZDPMaAqKD1n77PvdSl8iOY+1FYQs+WCxujTTW5WWMX1jgSmMnJBFHyZHdY LlfVax7Vv7Ms4HppEHZnCTxFZ9SsQQ7N0q44CAtzhEHxzP1TAF6OUIf/OXXOms6ffcQz 4pGMZYxU4o8LI2aAr6Y6QL/SD0oI/znovKL0CvEAjAEW0O0vbiLsmgk+dRj6tf7OfXhp wZf8rxqMBIlqbAiqLlwjhYHC94vKl+UymbcJgrgkX56VcHWpE5rO3zriYHbPevP6m+la hH8QEAModYjp1WfPvnJh5hKCDKVDbY/S6fGDkOmBOawAeIrGiup1qw1BIN4ZCEd5TCjY CHqw== MIME-Version: 1.0 X-Received: by 10.112.17.196 with SMTP id q4mr5841043lbd.21.1363597171337; Mon, 18 Mar 2013 01:59:31 -0700 (PDT) Received: by 10.114.21.230 with HTTP; Mon, 18 Mar 2013 01:59:31 -0700 (PDT) In-Reply-To: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> Date: Mon, 18 Mar 2013 09:59:31 +0100 Message-ID: From: Andreas Falck To: Almir Kadric Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============1295709746335891842==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1295709746335891842== Content-Type: multipart/alternative; boundary=bcaec554044c03b24a04d82f3512 --bcaec554044c03b24a04d82f3512 Content-Type: text/plain; charset=ISO-8859-1 Hi, Sounds like you have been testing extensively. If I get you right, dom0 freezes or reboots when you try to start the VM, but works otherwise? I assume you have tried with IOMMU disabled in bios too? In case of a buggy bios, turning IOMMU off could possibly make a difference (in order to find the problem, I realize that you plan to use IOMMU). Also, I assume that memory = '34096' Is a typo? Since you say that you have tried different vm configs. Regards, Andreas 2013/3/18 Almir Kadric > Hi all, > > I'm coming from a lxc background and recently found a real need for a full > virtualised windows solution. In the past I have stuck it out with Linux, > but Wine just hasn't been performing and I've had nothing but problems. > Anyways I tried a few things, and just could not get XEN to work for the > life of me. I got KVM working but VGA passthrough was a pain, I could never > get it to accept a device, even after I blacklisted it. Eventually I got > around to XEN as it is supposed to do this better, however I could not get > past the first stage ... a simple minimal virtual machine. No matter what I > did, no matter which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) > would either reboot or lockup. I tried looking for errors in messages, > kernel, xen/* but nothing really stood out. > > So my question would be what am I missing? What logs should I be looking > at? > > I managed to fix the small bugs which popped up like files being in wrong > places etc. Lastly I ran this using xm create and after that it > would just hang. Machine would become unresponsive, or reboot. > > Also I did look around if anyone was having these problems, and found a > few threads with the exact same issue, but no answers so far. > http://lists.debian.org/debian-user/2011/12/msg01779.html > > http://xen.markmail.org/search/?q=GA-970A#query:GA-970A+page:1+mid:fwgjnzmfy4pylgiu+state:results > > I would really appreciate some help to just be able to start the machine > with nothing fancy then I could possibly take it from there. > Also if anyone has any good links to guides for successful setups > compiling from source, preferably on Debian installation. Don't get me > wrong, I'm no Linux dummy, just would be nice to have something that proven > to work before I start stabbing around. > > I've been working on this on and off for about a week, and quite frankly > feel extremely defeated by it =_= > > To help you understand what I may have done wrong I will attach some > information below: > > *System:* > Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) > CPU: AMD FX 8300 @ 3.3GHz > GPU: Powercolor ATI Radeon 5970 > RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 > > *Setups tried:* > All were done with a Windows 7 x86_64 guest VM > * > * > Debian 6: Standard bridge. Installed xen-linux-system, in-fact I followed > the official guide http://wiki.debian.org/Xen and quite a few others. > Debian 7: same as above, found more guides etc > Above 2 would crash and just become plain unresponsive > > Ubuntu 12.10: Similar, instead followed ubuntu related guides > This one would reboot the dom0 > > *Things I tried or did do before you ask them:* > - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) > - Enabled IOMMU via kernel options as per XEN wiki documents (referenced > these a lot). > - Made sure that svm was enabled during kernel boot (xm dmsg) > - Made sure that IOMMU was enabled during kernel boot (xm dmsg), however > this behaved a bit wierd, so i didnt use pci pass through right off the > bat. Well again I couldnt even start the vm so no point. > > *Things I didn't try:* > - Compile XEN kernel and dom0 kernel from source > > *My HVM config:* > *(Though I technically tried a few different combinations from different > guide, including some very minimal ones)* > > name = 'xenvm1' > > kernel = '/usr/lib/xen-4.0/boot/hvmloader' > builder = 'hvm' > memory = '34096' > shadow_memory = '8' > device_model='/usr/lib/xen-4.0/bin/qemu-dm' > disk = [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] > vif = ['bridge=br0, mac=01:23:de:ad:be:ef'] > boot='dc' > vnc=1 > vncviewer=0 > sdl=0 > vcpus=4 > usbdevice='tablet' > on_poweroff = 'destroy' > on_reboot = 'restart' > on_crash = 'restart' > > > > Best Regards, > Almir kadric > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --bcaec554044c03b24a04d82f3512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Sounds like you have been testing extensively. If I get you righ= t, dom0 freezes or reboots when you try to start the VM, but works otherwis= e?

I assume you have tried with IOMMU disabled in bios too? In case = of a buggy bios, turning IOMMU off could possibly make a difference (in ord= er to find the problem, I realize that you plan to use IOMMU).

Also, I assume that 

memory =3D '34096'

Is a typo? Since you say that you h= ave tried different vm configs.

Regards,
Andreas


2013/= 3/18 Almir Kadric <almir@kadric.com>
Hi all,

I'm coming fro= m a lxc background and recently found a real need for a full virtualised wi= ndows solution. In the past I have stuck it out with Linux, but Wine just h= asn't been performing and I've had nothing but problems. Anyways I = tried a few things, and just could not get XEN to work for the life of me. = I got KVM working but VGA passthrough was a pain, I could never get it to a= ccept a device, even after I blacklisted it. Eventually I got around to XEN= as it is supposed to do this better, however I could not get past the firs= t stage ... a simple minimal virtual machine. No matter what I did, no matt= er which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) would either r= eboot or lockup. I tried looking for errors in messages, kernel, xen/* but = nothing really stood out.

So my question would be what am I missing? What logs sh= ould I be looking at?

I managed to fix the small b= ugs which popped up like files being in wrong places etc. Lastly I ran this= using xm create <config> and after that it would just hang. Machine = would become unresponsive, or reboot.

Also I did look around if anyone was having these probl= ems, and found a few threads with the exact same issue, but no answers so f= ar.

I would really appreciate some help to just be able to = start the machine with nothing fancy then I could possibly take it from the= re.
Also if anyone has any good links to guides for successful se= tups compiling from source, preferably on Debian installation. Don't ge= t me wrong, I'm no Linux dummy, just would be nice to have something th= at proven to work before I start stabbing around.

I've been working on this on and off for about a we= ek, and quite frankly feel extremely defeated by it =3D_=3D

<= /div>
To help you understand what I may have done wrong I will attach s= ome information below:

System:
Motherboard: GA-970A-D3 (rev 1= .3, BIOS F10)
CPU: AMD FX 8300 @ 3.3GHz
GPU: Powercolor= ATI Radeon 5970
RAM: 16GB Corsair=A0CML16GX3M2A1600C10B @ 1333

Setups tried:
All were done with a Win= dows 7 x86_64 guest VM

Debian 6: Standard b= ridge. Installed xen-linux-system, in-fact I followed the official guide=A0= http://wiki.debian= .org/Xen=A0and=A0quite a few others.
Debian 7: same as above, found more guides etc
Above 2 would= crash and just become plain unresponsive

Ubuntu 1= 2.10: Similar, instead followed ubuntu related guides
This one wo= uld reboot the dom0

Things I tried or did do before you ask them:
- Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki documents (refere= nced these a lot).
- Made sure that svm was enabled during kernel boot (xm dmsg)
- Made sure that IOMMU was enabled during kernel boot (xm dmsg), however = this behaved a bit wierd, so i didnt use pci pass through right off the bat= . Well again I couldnt even start the vm so no point.

Things I didn't try:
- Compile XEN= kernel and dom0 kernel from source

My HVM conf= ig:
(Though I technically tried a few different combinatio= ns from different guide, including some very minimal ones)
name =3D 'xenvm1'

kernel =3D '/usr/lib/xen-4.0/boot/hvmloader'
builder =3D 'hvm'
memory =3D '34096'
shadow_memory =3D '8'
device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm'
disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ]
vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef']
boot=3D'dc'
vnc=3D1
vncviewer=3D0
sdl=3D0
vcpus=3D4
usbdevice=3D'tablet'
on_poweroff =3D 'destroy'
on_reboot =3D 'restart'
on_crash =3D 'restart'


Best Regards,
Almir kadric

____________= ___________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--bcaec554044c03b24a04d82f3512-- --===============1295709746335891842== 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 --===============1295709746335891842==-- From xen-users-bounces@lists.xen.org Mon Mar 18 09:18:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09:18: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 1UHWCl-0007GN-QH; Mon, 18 Mar 2013 09:18:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHWCk-0007GI-PU for xen-users@lists.xen.org; Mon, 18 Mar 2013 09:18:06 +0000 Received: from [85.158.137.99:61172] by server-1.bemta-3.messagelabs.com id F1/4E-13706-ECBD6415; Mon, 18 Mar 2013 09:18:06 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-14.tower-217.messagelabs.com!1363598247!17434289!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14014 invoked from network); 18 Mar 2013 09:17:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 09:17:29 -0000 X-IronPort-AV: E=Sophos;i="4.84,863,1355097600"; d="scan'208";a="13108495" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 18 Mar 2013 09:17:26 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.3; Mon, 18 Mar 2013 05:17:26 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UHWC6-0005fs-52; Mon, 18 Mar 2013 09:17:26 +0000 Message-ID: <1363598246.29093.188.camel@zion.uk.xensource.com> From: Wei Liu To: Cao Wenz Date: Mon, 18 Mar 2013 09:17:26 +0000 In-Reply-To: References: X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , wei.liu2@citrix.com Subject: Re: [Xen-users] VM is paused when it is created X-BeenThere: xen-users@lists.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, 2013-03-18 at 03:50 +0000, Cao Wenz wrote: > Hi, ALL > > > I install Centos 5.5 and Xen 4.0 in my VMware VM. The dom0 is OK, I > can get vm list by "xm list", show bridge config by "brctl show". Than > I create a VM image, and try to start it. But when "xm create -c", the > vm is paused. I do not know why. > No. Your VM is running but it hangs during bootup. > > my config is: > 1 # Kernel image file. > 2 kernel = "/boot/vmlinuz-2.6.31.8-xen" > 3 > 4 # Optional ramdisk. > 5 # ramdisk = "/boot/initrd-2.6.31.8-xen.img" > 6 ramdisk = "/vm/initrd-2.6.31.8-xen.domu.img" > 7 > 8 memory = 512 > 9 name = "DomainU" > 10 vcpus = 1 > 11 > 12 vif = [ '' ] > 13 > 14 ip = "192.168.1.2" > 15 netmask = "255.255.255.0" > 16 gateway = "192.168.1.1" > 17 > 18 isk = [ 'file:/vm/domU.img,sda1,w' ] > 19 > 20 # Set root device. > 21 root = "/dev/sda1 ro" > > Try replacing "sda1" with "xvda1" or "xvda". Wei. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 09:18:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09:18: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 1UHWCl-0007GN-QH; Mon, 18 Mar 2013 09:18:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHWCk-0007GI-PU for xen-users@lists.xen.org; Mon, 18 Mar 2013 09:18:06 +0000 Received: from [85.158.137.99:61172] by server-1.bemta-3.messagelabs.com id F1/4E-13706-ECBD6415; Mon, 18 Mar 2013 09:18:06 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-14.tower-217.messagelabs.com!1363598247!17434289!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14014 invoked from network); 18 Mar 2013 09:17:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 09:17:29 -0000 X-IronPort-AV: E=Sophos;i="4.84,863,1355097600"; d="scan'208";a="13108495" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 18 Mar 2013 09:17:26 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.3; Mon, 18 Mar 2013 05:17:26 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UHWC6-0005fs-52; Mon, 18 Mar 2013 09:17:26 +0000 Message-ID: <1363598246.29093.188.camel@zion.uk.xensource.com> From: Wei Liu To: Cao Wenz Date: Mon, 18 Mar 2013 09:17:26 +0000 In-Reply-To: References: X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , wei.liu2@citrix.com Subject: Re: [Xen-users] VM is paused when it is created X-BeenThere: xen-users@lists.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, 2013-03-18 at 03:50 +0000, Cao Wenz wrote: > Hi, ALL > > > I install Centos 5.5 and Xen 4.0 in my VMware VM. The dom0 is OK, I > can get vm list by "xm list", show bridge config by "brctl show". Than > I create a VM image, and try to start it. But when "xm create -c", the > vm is paused. I do not know why. > No. Your VM is running but it hangs during bootup. > > my config is: > 1 # Kernel image file. > 2 kernel = "/boot/vmlinuz-2.6.31.8-xen" > 3 > 4 # Optional ramdisk. > 5 # ramdisk = "/boot/initrd-2.6.31.8-xen.img" > 6 ramdisk = "/vm/initrd-2.6.31.8-xen.domu.img" > 7 > 8 memory = 512 > 9 name = "DomainU" > 10 vcpus = 1 > 11 > 12 vif = [ '' ] > 13 > 14 ip = "192.168.1.2" > 15 netmask = "255.255.255.0" > 16 gateway = "192.168.1.1" > 17 > 18 isk = [ 'file:/vm/domU.img,sda1,w' ] > 19 > 20 # Set root device. > 21 root = "/dev/sda1 ro" > > Try replacing "sda1" with "xvda1" or "xvda". Wei. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 09:22:10 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09: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 1UHWFz-0007W4-MG; Mon, 18 Mar 2013 09:21:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHWFx-0007Vw-Vg for xen-users@lists.xen.org; Mon, 18 Mar 2013 09:21:26 +0000 Received: from [85.158.143.99:20624] by server-2.bemta-4.messagelabs.com id 20/80-12656-59CD6415; Mon, 18 Mar 2013 09:21:25 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363598484!22062860!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23980 invoked from network); 18 Mar 2013 09:21:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 09:21:24 -0000 X-IronPort-AV: E=Sophos;i="4.84,863,1355097600"; d="scan'208";a="2594408" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 18 Mar 2013 09:20:25 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Mon, 18 Mar 2013 09:20:24 +0000 Message-ID: <5146DC57.4050102@citrix.com> Date: Mon, 18 Mar 2013 10:20:23 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Eric Shelton References: In-Reply-To: Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] opensolaris/illumos on PVHVM under 4.x.y? X-BeenThere: xen-users@lists.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 14/03/13 23:30, Eric Shelton wrote: > [sorry for the dupe, the previous message was sent out prematurely...] > > I was hoping to implement a storage domain using blkback to serve up > ZFS zvols, to see how it works out. Is anyone successfully running > opensolaris with PV drivers under HVM on Xen 4.x.y? PVHVM is not just getting a PV guest booting under a HVM container. There are some differences in the way PV or PVHVM perform certain operations, so it's not just a matter of putting the PV drivers, for example the event channel callback used in PVHVM is different from the one used in PV, and also the way to map grant frames. AFAIK Illumos doesn't have PVHVM support, so it will take some work to get it running. If you are interested in running ZFS backends why don't you take a look at FreeBSD PVHVM? It comes with ZFS, frontends and backends, and runs in PVHVM mode without problems. > I am running on an > AMD IOMMU capable computer. The closest I have gotten is: > (1) coaxing openindiana into booting up as a PV guest (not a smooth > out-of-the-box type of install) > (2) with acpi=0, an HVM boot will go pretty far, but there is a bug > present in 151a7, in which the hvm_sd and sd modules fail to load due > to being improperly built and take down the boot. A patch for this > issue was entered into the illumos-gate repository, but does not > appear to have been used for any current distribution. > (3) with acpi=0 and use of the kernel bugger (::bp get_hwenv, :c, > platform_type/W 0, ::delete 1, :c), I can get openindiana to boot up a > plain PC kernel. I think I recall network and/or PV driver issues > being a problem. > (4) I tried out some illumos-gate kernel build/installs, but the > typical response from a new build is some kind of a hang or lockup > that is unresponsive to the F1-A kernel debugger. However, I am > definitely stumbling my way through this, so I may not have run the > kernel build or install correctly. > > OmniOS dies pretty quickly, whether under PV or HVM. > > I am beginning to get the impression that there was an active PV and > functional driver under Xen 3, but that the illumos PV drivers did not > keep up with various changes required to interoperate with Xen 4 (or > at least the more recent Xen releases). There was someone from the Illumos community working on getting back the full Xen PV support to Illumos, both as Dom0/DomU, but I think the work is stalled right now. > Even if I were to consider > KVM, although virtio-blk looks like it may be OK, a proposed > virtio-net driver has not been accepted into illumos-gate, and is of > unknown quality (it appears to be a slightly tweaked version of a > prototype driver that was admitted to be incomplete by its original > author). There appear to be suggestions that PVHVM has been > maintained and works in Solaris 11, but I would much more strongly > prefer using one of the illumos-based distributions. > > > If there is anyone running opensolaris outside of PV (in other words, > under HVM) under Xen 4.x.y, what is your Xen guest config, and which > distribution are you using? > > > Also, in sorting out how I might boot a plain non-HVM kernel (see use > of the kernel debugger under (3) above), it looks like the > "xen_platform_pci" parameter in xl.cfg-type files does nothing as the > code presently stands - defeinitely when using qemu-upstream, and I > think also under qemu-traditional. The xenpci device continues to > show up on the virtual PCI bus under "xen_platform_pci=0". However, > even if the xenpci device was toggled on/off, it turns out illumos > would still boot an HVM kernel, as it uses the availability of the > 0x40000000 cpuid info to identify when it is running under Xen (hence > the debugger procedure set out in (3) above). If xen_platform_pci is > set to 0, is this Xen cpuid functionality supposed to be diabled? > > _______________________________________________ > 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 Mar 18 09:22:10 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09: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 1UHWFz-0007W4-MG; Mon, 18 Mar 2013 09:21:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHWFx-0007Vw-Vg for xen-users@lists.xen.org; Mon, 18 Mar 2013 09:21:26 +0000 Received: from [85.158.143.99:20624] by server-2.bemta-4.messagelabs.com id 20/80-12656-59CD6415; Mon, 18 Mar 2013 09:21:25 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363598484!22062860!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23980 invoked from network); 18 Mar 2013 09:21:24 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 09:21:24 -0000 X-IronPort-AV: E=Sophos;i="4.84,863,1355097600"; d="scan'208";a="2594408" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 18 Mar 2013 09:20:25 +0000 Received: from [192.168.1.30] (10.30.249.242) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Mon, 18 Mar 2013 09:20:24 +0000 Message-ID: <5146DC57.4050102@citrix.com> Date: Mon, 18 Mar 2013 10:20:23 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Eric Shelton References: In-Reply-To: Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] opensolaris/illumos on PVHVM under 4.x.y? X-BeenThere: xen-users@lists.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 14/03/13 23:30, Eric Shelton wrote: > [sorry for the dupe, the previous message was sent out prematurely...] > > I was hoping to implement a storage domain using blkback to serve up > ZFS zvols, to see how it works out. Is anyone successfully running > opensolaris with PV drivers under HVM on Xen 4.x.y? PVHVM is not just getting a PV guest booting under a HVM container. There are some differences in the way PV or PVHVM perform certain operations, so it's not just a matter of putting the PV drivers, for example the event channel callback used in PVHVM is different from the one used in PV, and also the way to map grant frames. AFAIK Illumos doesn't have PVHVM support, so it will take some work to get it running. If you are interested in running ZFS backends why don't you take a look at FreeBSD PVHVM? It comes with ZFS, frontends and backends, and runs in PVHVM mode without problems. > I am running on an > AMD IOMMU capable computer. The closest I have gotten is: > (1) coaxing openindiana into booting up as a PV guest (not a smooth > out-of-the-box type of install) > (2) with acpi=0, an HVM boot will go pretty far, but there is a bug > present in 151a7, in which the hvm_sd and sd modules fail to load due > to being improperly built and take down the boot. A patch for this > issue was entered into the illumos-gate repository, but does not > appear to have been used for any current distribution. > (3) with acpi=0 and use of the kernel bugger (::bp get_hwenv, :c, > platform_type/W 0, ::delete 1, :c), I can get openindiana to boot up a > plain PC kernel. I think I recall network and/or PV driver issues > being a problem. > (4) I tried out some illumos-gate kernel build/installs, but the > typical response from a new build is some kind of a hang or lockup > that is unresponsive to the F1-A kernel debugger. However, I am > definitely stumbling my way through this, so I may not have run the > kernel build or install correctly. > > OmniOS dies pretty quickly, whether under PV or HVM. > > I am beginning to get the impression that there was an active PV and > functional driver under Xen 3, but that the illumos PV drivers did not > keep up with various changes required to interoperate with Xen 4 (or > at least the more recent Xen releases). There was someone from the Illumos community working on getting back the full Xen PV support to Illumos, both as Dom0/DomU, but I think the work is stalled right now. > Even if I were to consider > KVM, although virtio-blk looks like it may be OK, a proposed > virtio-net driver has not been accepted into illumos-gate, and is of > unknown quality (it appears to be a slightly tweaked version of a > prototype driver that was admitted to be incomplete by its original > author). There appear to be suggestions that PVHVM has been > maintained and works in Solaris 11, but I would much more strongly > prefer using one of the illumos-based distributions. > > > If there is anyone running opensolaris outside of PV (in other words, > under HVM) under Xen 4.x.y, what is your Xen guest config, and which > distribution are you using? > > > Also, in sorting out how I might boot a plain non-HVM kernel (see use > of the kernel debugger under (3) above), it looks like the > "xen_platform_pci" parameter in xl.cfg-type files does nothing as the > code presently stands - defeinitely when using qemu-upstream, and I > think also under qemu-traditional. The xenpci device continues to > show up on the virtual PCI bus under "xen_platform_pci=0". However, > even if the xenpci device was toggled on/off, it turns out illumos > would still boot an HVM kernel, as it uses the availability of the > 0x40000000 cpuid info to identify when it is running under Xen (hence > the debugger procedure set out in (3) above). If xen_platform_pci is > set to 0, is this Xen cpuid functionality supposed to be diabled? > > _______________________________________________ > 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 Mar 18 09:34:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09:34: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 1UHWRj-0008Cm-J9; Mon, 18 Mar 2013 09:33:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHWRh-0008Ce-RJ for xen-users@lists.xen.org; Mon, 18 Mar 2013 09:33:34 +0000 Received: from [85.158.139.83:62924] by server-10.bemta-5.messagelabs.com id 4E/FD-23714-D6FD6415; Mon, 18 Mar 2013 09:33:33 +0000 X-Env-Sender: almir@kadric.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1363599207!16259013!1 X-Originating-IP: [67.23.45.131] 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.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16377 invoked from network); 18 Mar 2013 09:33:28 -0000 Received: from kadricenterprises.com (HELO kadricenterprises.com) (67.23.45.131) by server-8.tower-182.messagelabs.com with SMTP; 18 Mar 2013 09:33:28 -0000 Received: from [192.168.2.234] (113x33x180x18.ap113.ftth.ucom.ne.jp [113.33.180.18]) by kadricenterprises.com (Postfix) with ESMTP id CD94C4800C7; Mon, 18 Mar 2013 09:25:49 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1283) From: Almir Kadric In-Reply-To: Date: Mon, 18 Mar 2013 18:33:25 +0900 Message-Id: References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> To: Andreas Falck X-Mailer: Apple Mail (2.1283) Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============2657649881243537573==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2657649881243537573== Content-Type: multipart/alternative; boundary="Apple-Mail=_C5E5BB9C-7CF7-4014-BCE4-B28BDEF1216B" --Apple-Mail=_C5E5BB9C-7CF7-4014-BCE4-B28BDEF1216B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Andreas, Thanks for your quick response ^_^ > Sounds like you have been testing extensively. If I get you right, = dom0 freezes or reboots when you try to start the VM, but works = otherwise? To say the least yes I have, a lot of sleep lost over this. orz > If I get you right, dom0 freezes or reboots when you try to start the = VM, but works otherwise? That's correct, dom0 works perfectly fine, right up until I start a = domU. Regardless of what's in that domU. > I assume you have tried with IOMMU disabled in bios too? Hmmm I can't quite remember, it's quite a blur after a week of sleepless = nights. I'll give it another whirl and see what happens. > Also, I assume that=20 >=20 > memory =3D '34096' Yes sorry typo, I pulled that up quickly from a site I borrowed that = config from, was changing it to "4096" Any recommendations for logging to watch? Generally I tail -f a log on = my screen and then ssh in to execute xm create. But the logs just die, = hoping to find that right one which just shows the error before a = freeze. Best Regards, Almir kadric Website: www.almirkadric.com Mobile: +81 90 8008 1578 Office: +81 03 4550 1448 Email: almir@kadric.com On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote: > Hi, >=20 > Sounds like you have been testing extensively. If I get you right, = dom0 freezes or reboots when you try to start the VM, but works = otherwise? >=20 > I assume you have tried with IOMMU disabled in bios too? In case of a = buggy bios, turning IOMMU off could possibly make a difference (in order = to find the problem, I realize that you plan to use IOMMU). >=20 > Also, I assume that=20 >=20 > memory =3D '34096' >=20 > Is a typo? Since you say that you have tried different vm configs. >=20 > Regards, > Andreas >=20 >=20 > 2013/3/18 Almir Kadric > Hi all, >=20 > I'm coming from a lxc background and recently found a real need for a = full virtualised windows solution. In the past I have stuck it out with = Linux, but Wine just hasn't been performing and I've had nothing but = problems. Anyways I tried a few things, and just could not get XEN to = work for the life of me. I got KVM working but VGA passthrough was a = pain, I could never get it to accept a device, even after I blacklisted = it. Eventually I got around to XEN as it is supposed to do this better, = however I could not get past the first stage ... a simple minimal = virtual machine. No matter what I did, no matter which distro (Debian = 6,7 and Ubuntu 12.10) my Host (dom0) would either reboot or lockup. I = tried looking for errors in messages, kernel, xen/* but nothing really = stood out. >=20 > So my question would be what am I missing? What logs should I be = looking at? >=20 > I managed to fix the small bugs which popped up like files being in = wrong places etc. Lastly I ran this using xm create and after = that it would just hang. Machine would become unresponsive, or reboot. >=20 > Also I did look around if anyone was having these problems, and found = a few threads with the exact same issue, but no answers so far. > http://lists.debian.org/debian-user/2011/12/msg01779.html > = http://xen.markmail.org/search/?q=3DGA-970A#query:GA-970A+page:1+mid:fwgjn= zmfy4pylgiu+state:results >=20 > I would really appreciate some help to just be able to start the = machine with nothing fancy then I could possibly take it from there. > Also if anyone has any good links to guides for successful setups = compiling from source, preferably on Debian installation. Don't get me = wrong, I'm no Linux dummy, just would be nice to have something that = proven to work before I start stabbing around. >=20 > I've been working on this on and off for about a week, and quite = frankly feel extremely defeated by it =3D_=3D >=20 > To help you understand what I may have done wrong I will attach some = information below: >=20 > System: > Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) > CPU: AMD FX 8300 @ 3.3GHz > GPU: Powercolor ATI Radeon 5970 > RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 >=20 > Setups tried: > All were done with a Windows 7 x86_64 guest VM >=20 > Debian 6: Standard bridge. Installed xen-linux-system, in-fact I = followed the official guide http://wiki.debian.org/Xen and quite a few = others. > Debian 7: same as above, found more guides etc > Above 2 would crash and just become plain unresponsive >=20 > Ubuntu 12.10: Similar, instead followed ubuntu related guides > This one would reboot the dom0 >=20 > Things I tried or did do before you ask them: > - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) > - Enabled IOMMU via kernel options as per XEN wiki documents = (referenced these a lot). > - Made sure that svm was enabled during kernel boot (xm dmsg) > - Made sure that IOMMU was enabled during kernel boot (xm dmsg), = however this behaved a bit wierd, so i didnt use pci pass through right = off the bat. Well again I couldnt even start the vm so no point. >=20 > Things I didn't try: > - Compile XEN kernel and dom0 kernel from source >=20 > My HVM config: > (Though I technically tried a few different combinations from = different guide, including some very minimal ones) > name =3D 'xenvm1' > kernel =3D '/usr/lib/xen-4.0/boot/hvmloader' > builder =3D 'hvm' > memory =3D '34096' > shadow_memory =3D '8' > device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm' > disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] > vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef'] > boot=3D'dc' > vnc=3D1 > vncviewer=3D0 > sdl=3D0 > vcpus=3D4 > usbdevice=3D'tablet' > on_poweroff =3D 'destroy' > on_reboot =3D 'restart' > on_crash =3D 'restart' >=20 >=20 > Best Regards, > Almir kadric >=20 > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users >=20 > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --Apple-Mail=_C5E5BB9C-7CF7-4014-BCE4-B28BDEF1216B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Sounds like you = have been testing extensively. If I get you right, dom0 freezes or = reboots when you try to start the VM, but works = otherwise?To say the least yes I have, a lot of sleep lost = over this.  orz

If= I get you right, dom0 freezes or reboots when you try to start the VM, = but works otherwise?
That's correct, dom0 works perfectly = fine, right up until I start a domU. Regardless of what's in that = domU.

I assume you = have tried with IOMMU disabled in bios too?
Hmmm I can't = quite remember, it's quite a blur after a week of sleepless nights. I'll = give it another whirl and see what = happens.

Also, I = assume that 

memory =3D '34096'
Yes sorry typo, I = pulled that up quickly from a site I borrowed that config from, was = changing it to "4096"


Any = recommendations for logging to watch? Generally I tail -f a log on my = screen and then ssh in to execute xm create. But the logs just die, = hoping to find that right one which just shows the error before a = freeze.


Best = Regards,
Almir kadric

Website: www.almirkadric.com
Mobile:     +81 90 8008 = 1578
Office:      +81 03 = 4550 1448
Email: almir@kadric.com

On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote:

Hi,

Sounds like you have been testing extensively. = If I get you right, dom0 freezes or reboots when you try to start the = VM, but works otherwise?

I assume you have tried with IOMMU = disabled in bios too? In case of a buggy bios, turning IOMMU off could = possibly make a difference (in order to find the problem, I realize that = you plan to use IOMMU).

Also, I assume that 

memory =3D =
'34096'

Is a typo? Since you say that you have tried = different vm configs.

Regards,
Andreas


2013/3/18 = Almir Kadric <almir@kadric.com>
Hi = all,

I'm coming from a lxc background and = recently found a real need for a full virtualised windows solution. In = the past I have stuck it out with Linux, but Wine just hasn't been = performing and I've had nothing but problems. Anyways I tried a few = things, and just could not get XEN to work for the life of me. I got KVM = working but VGA passthrough was a pain, I could never get it to accept a = device, even after I blacklisted it. Eventually I got around to XEN as = it is supposed to do this better, however I could not get past the first = stage ... a simple minimal virtual machine. No matter what I did, no = matter which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) would = either reboot or lockup. I tried looking for errors in messages, kernel, = xen/* but nothing really stood out.

So my question would be what am I missing? What logs = should I be looking at?

I managed to fix the = small bugs which popped up like files being in wrong places etc. Lastly = I ran this using xm create <config> and after that it would just = hang. Machine would become unresponsive, or reboot.

Also I did look around if anyone was having these = problems, and found a few threads with the exact same issue, but no = answers so far.

I would really appreciate some help to just be able = to start the machine with nothing fancy then I could possibly take it = from there.
Also if anyone has any good links to guides for = successful setups compiling from source, preferably on Debian = installation. Don't get me wrong, I'm no Linux dummy, just would be nice = to have something that proven to work before I start stabbing = around.

I've been working on this on and off for about a = week, and quite frankly feel extremely defeated by it = =3D_=3D

To help you understand what I may have = done wrong I will attach some information below:

System:
Motherboard: GA-970A-D3 = (rev 1.3, BIOS F10)
CPU: AMD FX 8300 @ 3.3GHz
GPU: = Powercolor ATI Radeon 5970
RAM: 16GB = Corsair CML16GX3M2A1600C10B @ 1333

Setups tried:
All were done with a = Windows 7 x86_64 guest VM

Debian 6: = Standard bridge. Installed xen-linux-system, in-fact I followed the = official guide http://wiki.debian.org/Xen and quite a = few others.
Debian 7: same as above, found more guides etc
Above 2 = would crash and just become plain = unresponsive

Ubuntu 12.10: Similar, instead = followed ubuntu related guides
This one would reboot the = dom0

Things I tried or did do before you ask = them:
- Yes I booted into the XEN kernel (Linux x.y.z with = XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki = documents (referenced these a lot).
- Made sure that svm was enabled during kernel boot (xm = dmsg)
- Made sure that IOMMU was enabled during kernel boot = (xm dmsg), however this behaved a bit wierd, so i didnt use pci pass = through right off the bat. Well again I couldnt even start the vm so no = point.

Things I didn't try:
- Compile XEN = kernel and dom0 kernel from source

My HVM = config:
(Though I technically tried a few different = combinations from different guide, including some very minimal = ones)
name =3D 'xenvm1'

kernel =3D =
'/usr/lib/xen-4.0/boot/hvmloader'
builder =3D 'hvm'
memory =3D '34096'
shadow_memory =3D '8'
device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm'
disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ]
vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef']
boot=3D'dc'
vnc=3D1
vncviewer=3D0
sdl=3D0
vcpus=3D4
usbdevice=3D'tablet'
on_poweroff =3D 'destroy'
on_reboot =3D 'restart'
on_crash =3D 'restart'


Best Regards,
Almir = kadric

________________________________________= _______
Xen-users mailing list
Xen-users@lists.xen.org
= http://lists.xen.org/xen-users

_______________________________________________
Xen-users mailing = list
Xen-users@lists.xen.org
htt= p://lists.xen.org/xen-users

= --Apple-Mail=_C5E5BB9C-7CF7-4014-BCE4-B28BDEF1216B-- --===============2657649881243537573== 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 --===============2657649881243537573==-- From xen-users-bounces@lists.xen.org Mon Mar 18 09:34:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09:34: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 1UHWRj-0008Cm-J9; Mon, 18 Mar 2013 09:33:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHWRh-0008Ce-RJ for xen-users@lists.xen.org; Mon, 18 Mar 2013 09:33:34 +0000 Received: from [85.158.139.83:62924] by server-10.bemta-5.messagelabs.com id 4E/FD-23714-D6FD6415; Mon, 18 Mar 2013 09:33:33 +0000 X-Env-Sender: almir@kadric.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1363599207!16259013!1 X-Originating-IP: [67.23.45.131] 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.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16377 invoked from network); 18 Mar 2013 09:33:28 -0000 Received: from kadricenterprises.com (HELO kadricenterprises.com) (67.23.45.131) by server-8.tower-182.messagelabs.com with SMTP; 18 Mar 2013 09:33:28 -0000 Received: from [192.168.2.234] (113x33x180x18.ap113.ftth.ucom.ne.jp [113.33.180.18]) by kadricenterprises.com (Postfix) with ESMTP id CD94C4800C7; Mon, 18 Mar 2013 09:25:49 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1283) From: Almir Kadric In-Reply-To: Date: Mon, 18 Mar 2013 18:33:25 +0900 Message-Id: References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> To: Andreas Falck X-Mailer: Apple Mail (2.1283) Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============2657649881243537573==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2657649881243537573== Content-Type: multipart/alternative; boundary="Apple-Mail=_C5E5BB9C-7CF7-4014-BCE4-B28BDEF1216B" --Apple-Mail=_C5E5BB9C-7CF7-4014-BCE4-B28BDEF1216B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Andreas, Thanks for your quick response ^_^ > Sounds like you have been testing extensively. If I get you right, = dom0 freezes or reboots when you try to start the VM, but works = otherwise? To say the least yes I have, a lot of sleep lost over this. orz > If I get you right, dom0 freezes or reboots when you try to start the = VM, but works otherwise? That's correct, dom0 works perfectly fine, right up until I start a = domU. Regardless of what's in that domU. > I assume you have tried with IOMMU disabled in bios too? Hmmm I can't quite remember, it's quite a blur after a week of sleepless = nights. I'll give it another whirl and see what happens. > Also, I assume that=20 >=20 > memory =3D '34096' Yes sorry typo, I pulled that up quickly from a site I borrowed that = config from, was changing it to "4096" Any recommendations for logging to watch? Generally I tail -f a log on = my screen and then ssh in to execute xm create. But the logs just die, = hoping to find that right one which just shows the error before a = freeze. Best Regards, Almir kadric Website: www.almirkadric.com Mobile: +81 90 8008 1578 Office: +81 03 4550 1448 Email: almir@kadric.com On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote: > Hi, >=20 > Sounds like you have been testing extensively. If I get you right, = dom0 freezes or reboots when you try to start the VM, but works = otherwise? >=20 > I assume you have tried with IOMMU disabled in bios too? In case of a = buggy bios, turning IOMMU off could possibly make a difference (in order = to find the problem, I realize that you plan to use IOMMU). >=20 > Also, I assume that=20 >=20 > memory =3D '34096' >=20 > Is a typo? Since you say that you have tried different vm configs. >=20 > Regards, > Andreas >=20 >=20 > 2013/3/18 Almir Kadric > Hi all, >=20 > I'm coming from a lxc background and recently found a real need for a = full virtualised windows solution. In the past I have stuck it out with = Linux, but Wine just hasn't been performing and I've had nothing but = problems. Anyways I tried a few things, and just could not get XEN to = work for the life of me. I got KVM working but VGA passthrough was a = pain, I could never get it to accept a device, even after I blacklisted = it. Eventually I got around to XEN as it is supposed to do this better, = however I could not get past the first stage ... a simple minimal = virtual machine. No matter what I did, no matter which distro (Debian = 6,7 and Ubuntu 12.10) my Host (dom0) would either reboot or lockup. I = tried looking for errors in messages, kernel, xen/* but nothing really = stood out. >=20 > So my question would be what am I missing? What logs should I be = looking at? >=20 > I managed to fix the small bugs which popped up like files being in = wrong places etc. Lastly I ran this using xm create and after = that it would just hang. Machine would become unresponsive, or reboot. >=20 > Also I did look around if anyone was having these problems, and found = a few threads with the exact same issue, but no answers so far. > http://lists.debian.org/debian-user/2011/12/msg01779.html > = http://xen.markmail.org/search/?q=3DGA-970A#query:GA-970A+page:1+mid:fwgjn= zmfy4pylgiu+state:results >=20 > I would really appreciate some help to just be able to start the = machine with nothing fancy then I could possibly take it from there. > Also if anyone has any good links to guides for successful setups = compiling from source, preferably on Debian installation. Don't get me = wrong, I'm no Linux dummy, just would be nice to have something that = proven to work before I start stabbing around. >=20 > I've been working on this on and off for about a week, and quite = frankly feel extremely defeated by it =3D_=3D >=20 > To help you understand what I may have done wrong I will attach some = information below: >=20 > System: > Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) > CPU: AMD FX 8300 @ 3.3GHz > GPU: Powercolor ATI Radeon 5970 > RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 >=20 > Setups tried: > All were done with a Windows 7 x86_64 guest VM >=20 > Debian 6: Standard bridge. Installed xen-linux-system, in-fact I = followed the official guide http://wiki.debian.org/Xen and quite a few = others. > Debian 7: same as above, found more guides etc > Above 2 would crash and just become plain unresponsive >=20 > Ubuntu 12.10: Similar, instead followed ubuntu related guides > This one would reboot the dom0 >=20 > Things I tried or did do before you ask them: > - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) > - Enabled IOMMU via kernel options as per XEN wiki documents = (referenced these a lot). > - Made sure that svm was enabled during kernel boot (xm dmsg) > - Made sure that IOMMU was enabled during kernel boot (xm dmsg), = however this behaved a bit wierd, so i didnt use pci pass through right = off the bat. Well again I couldnt even start the vm so no point. >=20 > Things I didn't try: > - Compile XEN kernel and dom0 kernel from source >=20 > My HVM config: > (Though I technically tried a few different combinations from = different guide, including some very minimal ones) > name =3D 'xenvm1' > kernel =3D '/usr/lib/xen-4.0/boot/hvmloader' > builder =3D 'hvm' > memory =3D '34096' > shadow_memory =3D '8' > device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm' > disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] > vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef'] > boot=3D'dc' > vnc=3D1 > vncviewer=3D0 > sdl=3D0 > vcpus=3D4 > usbdevice=3D'tablet' > on_poweroff =3D 'destroy' > on_reboot =3D 'restart' > on_crash =3D 'restart' >=20 >=20 > Best Regards, > Almir kadric >=20 > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users >=20 > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --Apple-Mail=_C5E5BB9C-7CF7-4014-BCE4-B28BDEF1216B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Sounds like you = have been testing extensively. If I get you right, dom0 freezes or = reboots when you try to start the VM, but works = otherwise?To say the least yes I have, a lot of sleep lost = over this.  orz

If= I get you right, dom0 freezes or reboots when you try to start the VM, = but works otherwise?
That's correct, dom0 works perfectly = fine, right up until I start a domU. Regardless of what's in that = domU.

I assume you = have tried with IOMMU disabled in bios too?
Hmmm I can't = quite remember, it's quite a blur after a week of sleepless nights. I'll = give it another whirl and see what = happens.

Also, I = assume that 

memory =3D '34096'
Yes sorry typo, I = pulled that up quickly from a site I borrowed that config from, was = changing it to "4096"


Any = recommendations for logging to watch? Generally I tail -f a log on my = screen and then ssh in to execute xm create. But the logs just die, = hoping to find that right one which just shows the error before a = freeze.


Best = Regards,
Almir kadric

Website: www.almirkadric.com
Mobile:     +81 90 8008 = 1578
Office:      +81 03 = 4550 1448
Email: almir@kadric.com

On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote:

Hi,

Sounds like you have been testing extensively. = If I get you right, dom0 freezes or reboots when you try to start the = VM, but works otherwise?

I assume you have tried with IOMMU = disabled in bios too? In case of a buggy bios, turning IOMMU off could = possibly make a difference (in order to find the problem, I realize that = you plan to use IOMMU).

Also, I assume that 

memory =3D =
'34096'

Is a typo? Since you say that you have tried = different vm configs.

Regards,
Andreas


2013/3/18 = Almir Kadric <almir@kadric.com>
Hi = all,

I'm coming from a lxc background and = recently found a real need for a full virtualised windows solution. In = the past I have stuck it out with Linux, but Wine just hasn't been = performing and I've had nothing but problems. Anyways I tried a few = things, and just could not get XEN to work for the life of me. I got KVM = working but VGA passthrough was a pain, I could never get it to accept a = device, even after I blacklisted it. Eventually I got around to XEN as = it is supposed to do this better, however I could not get past the first = stage ... a simple minimal virtual machine. No matter what I did, no = matter which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) would = either reboot or lockup. I tried looking for errors in messages, kernel, = xen/* but nothing really stood out.

So my question would be what am I missing? What logs = should I be looking at?

I managed to fix the = small bugs which popped up like files being in wrong places etc. Lastly = I ran this using xm create <config> and after that it would just = hang. Machine would become unresponsive, or reboot.

Also I did look around if anyone was having these = problems, and found a few threads with the exact same issue, but no = answers so far.

I would really appreciate some help to just be able = to start the machine with nothing fancy then I could possibly take it = from there.
Also if anyone has any good links to guides for = successful setups compiling from source, preferably on Debian = installation. Don't get me wrong, I'm no Linux dummy, just would be nice = to have something that proven to work before I start stabbing = around.

I've been working on this on and off for about a = week, and quite frankly feel extremely defeated by it = =3D_=3D

To help you understand what I may have = done wrong I will attach some information below:

System:
Motherboard: GA-970A-D3 = (rev 1.3, BIOS F10)
CPU: AMD FX 8300 @ 3.3GHz
GPU: = Powercolor ATI Radeon 5970
RAM: 16GB = Corsair CML16GX3M2A1600C10B @ 1333

Setups tried:
All were done with a = Windows 7 x86_64 guest VM

Debian 6: = Standard bridge. Installed xen-linux-system, in-fact I followed the = official guide http://wiki.debian.org/Xen and quite a = few others.
Debian 7: same as above, found more guides etc
Above 2 = would crash and just become plain = unresponsive

Ubuntu 12.10: Similar, instead = followed ubuntu related guides
This one would reboot the = dom0

Things I tried or did do before you ask = them:
- Yes I booted into the XEN kernel (Linux x.y.z with = XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki = documents (referenced these a lot).
- Made sure that svm was enabled during kernel boot (xm = dmsg)
- Made sure that IOMMU was enabled during kernel boot = (xm dmsg), however this behaved a bit wierd, so i didnt use pci pass = through right off the bat. Well again I couldnt even start the vm so no = point.

Things I didn't try:
- Compile XEN = kernel and dom0 kernel from source

My HVM = config:
(Though I technically tried a few different = combinations from different guide, including some very minimal = ones)
name =3D 'xenvm1'

kernel =3D =
'/usr/lib/xen-4.0/boot/hvmloader'
builder =3D 'hvm'
memory =3D '34096'
shadow_memory =3D '8'
device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm'
disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ]
vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef']
boot=3D'dc'
vnc=3D1
vncviewer=3D0
sdl=3D0
vcpus=3D4
usbdevice=3D'tablet'
on_poweroff =3D 'destroy'
on_reboot =3D 'restart'
on_crash =3D 'restart'


Best Regards,
Almir = kadric

________________________________________= _______
Xen-users mailing list
Xen-users@lists.xen.org
= http://lists.xen.org/xen-users

_______________________________________________
Xen-users mailing = list
Xen-users@lists.xen.org
htt= p://lists.xen.org/xen-users

= --Apple-Mail=_C5E5BB9C-7CF7-4014-BCE4-B28BDEF1216B-- --===============2657649881243537573== 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 --===============2657649881243537573==-- From xen-users-bounces@lists.xen.org Mon Mar 18 09:49:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09:49: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 1UHWgy-0000ei-RW; Mon, 18 Mar 2013 09:49:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHWgv-0000eX-N5 for xen-users@lists.xen.org; Mon, 18 Mar 2013 09:49:18 +0000 Received: from [85.158.138.51:50360] by server-5.bemta-3.messagelabs.com id 59/22-30636-B13E6415; Mon, 18 Mar 2013 09:49:15 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1363600154!28087982!1 X-Originating-IP: [209.85.212.194] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20466 invoked from network); 18 Mar 2013 09:49:14 -0000 Received: from mail-wi0-f194.google.com (HELO mail-wi0-f194.google.com) (209.85.212.194) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 09:49:14 -0000 Received: by mail-wi0-f194.google.com with SMTP id hm11so784572wib.9 for ; Mon, 18 Mar 2013 02:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=5Suh0Yld4QYu5fLx5AEEBj1q9a22pg9ZLbqcADkmNqQ=; b=Zxe9udNkT4rSSDHjMyb3HzlD9KZn1OcjY9c9g/vvGQowCxwScZEH7jF1MP0ZyQkZcj wlLwOUTGRfdwKwo7sIDWu8ze3Zg8F+u73OwFS82zfCBbr5r4ZxkYCaZTVCagMBIuLTz4 i4TNSJXreGocfnVZLaauADCRQt4mpG9st1LiQPetGd1ydGdT/Leh3U2En7ZijxsOH3Ms r6OVDvglko2OQt0eIA2FBhJDKAz5pVmXa+V50FPWRxEdmGntl00bx4Iy8niUlfpnmcDv euZWVyWJnwrfDlGZ/DlX41hCbAqFtTT/A1RU/Lsbfg50AZZtwFlM61dnokAF4kqobNIC iC+A== MIME-Version: 1.0 X-Received: by 10.180.38.101 with SMTP id f5mr15069436wik.25.1363600154274; Mon, 18 Mar 2013 02:49:14 -0700 (PDT) Received: by 10.194.153.36 with HTTP; Mon, 18 Mar 2013 02:49:14 -0700 (PDT) In-Reply-To: References: <1363598246.29093.188.camel@zion.uk.xensource.com> Date: Mon, 18 Mar 2013 17:49:14 +0800 Message-ID: From: Cao Wenz To: "xen-users@lists.xen.org" Subject: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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 ---------- Forwarded message ---------- From: Cao Wenz Date: 2013/3/18 Subject: Re: [Xen-users] VM is paused when it is created To: Wei Liu > > Try replacing "sda1" with "xvda1" or "xvda". > > I try it, but the VM also hangs during bootup. BTW, when VM hangs, I can 'ping' it. Than I try ssh it. When I have inputed passwd, it does not any respond. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 09:49:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 09:49: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 1UHWgy-0000ei-RW; Mon, 18 Mar 2013 09:49:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHWgv-0000eX-N5 for xen-users@lists.xen.org; Mon, 18 Mar 2013 09:49:18 +0000 Received: from [85.158.138.51:50360] by server-5.bemta-3.messagelabs.com id 59/22-30636-B13E6415; Mon, 18 Mar 2013 09:49:15 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1363600154!28087982!1 X-Originating-IP: [209.85.212.194] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20466 invoked from network); 18 Mar 2013 09:49:14 -0000 Received: from mail-wi0-f194.google.com (HELO mail-wi0-f194.google.com) (209.85.212.194) by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 09:49:14 -0000 Received: by mail-wi0-f194.google.com with SMTP id hm11so784572wib.9 for ; Mon, 18 Mar 2013 02:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=5Suh0Yld4QYu5fLx5AEEBj1q9a22pg9ZLbqcADkmNqQ=; b=Zxe9udNkT4rSSDHjMyb3HzlD9KZn1OcjY9c9g/vvGQowCxwScZEH7jF1MP0ZyQkZcj wlLwOUTGRfdwKwo7sIDWu8ze3Zg8F+u73OwFS82zfCBbr5r4ZxkYCaZTVCagMBIuLTz4 i4TNSJXreGocfnVZLaauADCRQt4mpG9st1LiQPetGd1ydGdT/Leh3U2En7ZijxsOH3Ms r6OVDvglko2OQt0eIA2FBhJDKAz5pVmXa+V50FPWRxEdmGntl00bx4Iy8niUlfpnmcDv euZWVyWJnwrfDlGZ/DlX41hCbAqFtTT/A1RU/Lsbfg50AZZtwFlM61dnokAF4kqobNIC iC+A== MIME-Version: 1.0 X-Received: by 10.180.38.101 with SMTP id f5mr15069436wik.25.1363600154274; Mon, 18 Mar 2013 02:49:14 -0700 (PDT) Received: by 10.194.153.36 with HTTP; Mon, 18 Mar 2013 02:49:14 -0700 (PDT) In-Reply-To: References: <1363598246.29093.188.camel@zion.uk.xensource.com> Date: Mon, 18 Mar 2013 17:49:14 +0800 Message-ID: From: Cao Wenz To: "xen-users@lists.xen.org" Subject: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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 ---------- Forwarded message ---------- From: Cao Wenz Date: 2013/3/18 Subject: Re: [Xen-users] VM is paused when it is created To: Wei Liu > > Try replacing "sda1" with "xvda1" or "xvda". > > I try it, but the VM also hangs during bootup. BTW, when VM hangs, I can 'ping' it. Than I try ssh it. When I have inputed passwd, it does not any respond. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 10:17:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:17: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 1UHX7Y-0001kQ-Ez; Mon, 18 Mar 2013 10:16:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHX7W-0001kL-Rf for xen-users@lists.xen.org; Mon, 18 Mar 2013 10:16:47 +0000 Received: from [85.158.137.99:22143] by server-9.bemta-3.messagelabs.com id 86/3F-32531-D89E6415; Mon, 18 Mar 2013 10:16:45 +0000 X-Env-Sender: falck.andreas.lists@gmail.com X-Msg-Ref: server-3.tower-217.messagelabs.com!1363601802!12030344!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19358 invoked from network); 18 Mar 2013 10:16:42 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 10:16:42 -0000 Received: by mail-la0-f46.google.com with SMTP id fq12so5735297lab.5 for ; Mon, 18 Mar 2013 03:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FQHTkLEq/iWORWflryP4S2xwOZXvEmwle8NKWFMwrvk=; b=WBu5DZNh7metp/plK3YweERmtbH/h1BPpauYriVaAeIZdzk8+7cC7XOQT0w1NGqlyr USZbXHFLGWhi+9jWgUU054wuf9/Li0vl4jLHyf/AUU/naN6yRJuAZOLimxotUN3G1mIx 6FYjYDk4e/oxDyxRPV7omhCfguMg7nMrP04Oc9iury6zLLGpoLcSlnMkfKodExX5C5Xc inryYPhv23KL/4huUn0XoxSnU4rMu2uimAyfY8kyvnnrOMmLiCh0+JwpDKlxpWU7DNNv EP3yDHo8Zp81jT3F99fYOKOqkIsVGrlpK/2z1j2nsYyOTbN2CgVD6uxyD5dhuYVlVpE+ RBog== MIME-Version: 1.0 X-Received: by 10.152.28.3 with SMTP id x3mr13061253lag.27.1363601801776; Mon, 18 Mar 2013 03:16:41 -0700 (PDT) Received: by 10.114.21.230 with HTTP; Mon, 18 Mar 2013 03:16:41 -0700 (PDT) In-Reply-To: References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> Date: Mon, 18 Mar 2013 11:16:41 +0100 Message-ID: From: Andreas Falck To: Almir Kadric Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============0890766988162148421==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0890766988162148421== Content-Type: multipart/alternative; boundary=089e0158c3960292cd04d83049bc --089e0158c3960292cd04d83049bc Content-Type: text/plain; charset=ISO-8859-1 Hi Almir, Sorry, I have no good advice on which logs to watch. It is possible that if the dom0 kernel ever gets time to ouput something, it will do it to the console. One piece of information that might be useful for further debugging is whether the error occurs when the VM kernel boots or already when the HVM bios boots. You can try this by starting a HVM vm without any virtual disk, thus booting only the HVM bios. Also, it would probably be of interest to know if a PV guest works (you can probably do this easily by starting only a PV kernel, no need to install a full PV system). However, I am not sure on what to do with that information, but someone else might have a clue. Regards, Andreas 2013/3/18 Almir Kadric > Hi, Andreas, > > Thanks for your quick response ^_^ > > Sounds like you have been testing extensively. If I get you right, dom0 > freezes or reboots when you try to start the VM, but works otherwise? > > To say the least yes I have, a lot of sleep lost over this. orz > > If I get you right, dom0 freezes or reboots when you try to start the VM, > but works otherwise? > > That's correct, dom0 works perfectly fine, right up until I start a domU. > Regardless of what's in that domU. > > I assume you have tried with IOMMU disabled in bios too? > > Hmmm I can't quite remember, it's quite a blur after a week of sleepless > nights. I'll give it another whirl and see what happens. > > Also, I assume that > > memory = '34096' > > Yes sorry typo, I pulled that up quickly from a site I borrowed that > config from, was changing it to "4096" > > > Any recommendations for logging to watch? Generally I tail -f a log on my > screen and then ssh in to execute xm create. But the logs just die, hoping > to find that right one which just shows the error before a freeze. > > > Best Regards, > Almir kadric > > Website: www.almirkadric.com > Mobile: +81 90 8008 1578**** > Office: +81 03 4550 1448 > Email: almir@kadric.com > > On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote: > > Hi, > > Sounds like you have been testing extensively. If I get you right, dom0 > freezes or reboots when you try to start the VM, but works otherwise? > > I assume you have tried with IOMMU disabled in bios too? In case of a > buggy bios, turning IOMMU off could possibly make a difference (in order to > find the problem, I realize that you plan to use IOMMU). > > Also, I assume that > > memory = '34096' > > > Is a typo? Since you say that you have tried different vm configs. > > Regards, > Andreas > > > 2013/3/18 Almir Kadric > >> Hi all, >> >> I'm coming from a lxc background and recently found a real need for a >> full virtualised windows solution. In the past I have stuck it out with >> Linux, but Wine just hasn't been performing and I've had nothing but >> problems. Anyways I tried a few things, and just could not get XEN to work >> for the life of me. I got KVM working but VGA passthrough was a pain, I >> could never get it to accept a device, even after I blacklisted it. >> Eventually I got around to XEN as it is supposed to do this better, however >> I could not get past the first stage ... a simple minimal virtual machine. >> No matter what I did, no matter which distro (Debian 6,7 and Ubuntu 12.10) >> my Host (dom0) would either reboot or lockup. I tried looking for errors in >> messages, kernel, xen/* but nothing really stood out. >> >> So my question would be what am I missing? What logs should I be looking >> at? >> >> I managed to fix the small bugs which popped up like files being in wrong >> places etc. Lastly I ran this using xm create and after that it >> would just hang. Machine would become unresponsive, or reboot. >> >> Also I did look around if anyone was having these problems, and found a >> few threads with the exact same issue, but no answers so far. >> http://lists.debian.org/debian-user/2011/12/msg01779.html >> >> http://xen.markmail.org/search/?q=GA-970A#query:GA-970A+page:1+mid:fwgjnzmfy4pylgiu+state:results >> >> I would really appreciate some help to just be able to start the machine >> with nothing fancy then I could possibly take it from there. >> Also if anyone has any good links to guides for successful setups >> compiling from source, preferably on Debian installation. Don't get me >> wrong, I'm no Linux dummy, just would be nice to have something that proven >> to work before I start stabbing around. >> >> I've been working on this on and off for about a week, and quite frankly >> feel extremely defeated by it =_= >> >> To help you understand what I may have done wrong I will attach some >> information below: >> >> *System:* >> Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) >> CPU: AMD FX 8300 @ 3.3GHz >> GPU: Powercolor ATI Radeon 5970 >> RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 >> >> *Setups tried:* >> All were done with a Windows 7 x86_64 guest VM >> * >> * >> Debian 6: Standard bridge. Installed xen-linux-system, in-fact I followed >> the official guide http://wiki.debian.org/Xen and quite a few others. >> Debian 7: same as above, found more guides etc >> Above 2 would crash and just become plain unresponsive >> >> Ubuntu 12.10: Similar, instead followed ubuntu related guides >> This one would reboot the dom0 >> >> *Things I tried or did do before you ask them:* >> - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) >> - Enabled IOMMU via kernel options as per XEN wiki documents (referenced >> these a lot). >> - Made sure that svm was enabled during kernel boot (xm dmsg) >> - Made sure that IOMMU was enabled during kernel boot (xm dmsg), however >> this behaved a bit wierd, so i didnt use pci pass through right off the >> bat. Well again I couldnt even start the vm so no point. >> >> *Things I didn't try:* >> - Compile XEN kernel and dom0 kernel from source >> >> *My HVM config:* >> *(Though I technically tried a few different combinations from different >> guide, including some very minimal ones)* >> >> name = 'xenvm1' >> >> kernel = '/usr/lib/xen-4.0/boot/hvmloader' >> builder = 'hvm' >> memory = '34096' >> shadow_memory = '8' >> device_model='/usr/lib/xen-4.0/bin/qemu-dm' >> disk = [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] >> vif = ['bridge=br0, mac=01:23:de:ad:be:ef'] >> boot='dc' >> vnc=1 >> vncviewer=0 >> sdl=0 >> vcpus=4 >> usbdevice='tablet' >> on_poweroff = 'destroy' >> on_reboot = 'restart' >> on_crash = 'restart' >> >> >> >> Best Regards, >> Almir kadric >> >> _______________________________________________ >> 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 > > > --089e0158c3960292cd04d83049bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Almir,

Sorry, I have no good advice on which logs to watch. It is= possible that if the dom0 kernel ever gets time to ouput something, it wil= l do it to the console.

One piece of information that might be usefu= l for further debugging is whether the error occurs when the VM kernel boot= s or already when the HVM bios boots. You can try this by starting a HVM vm= without any virtual disk, thus booting only the HVM bios. Also, it would p= robably be of interest to know if a PV guest works (you can probably do thi= s easily by starting only a PV kernel, no need to install a full PV system)= . However, I am not sure on what to do with that information, but someone e= lse might have a clue.

Regards,
Andreas

2013/3/18 Almir K= adric <almir@kadric.com>
Hi, Andreas,

<= div>Thanks for your quick response ^_^

Sounds like you have been testing extensively. If I g= et you right, dom0 freezes or reboots when you try to start the VM, but wor= ks otherwise?
To say the least yes I have, a lot of sleep lost over this. =A0orz

If I get= you right, dom0 freezes or reboots when you try to start the VM, but works= otherwise?
That's correct, dom0 works perfectly fine, right up until I start= a domU. Regardless of what's in that domU.

I assume you have tried with IOMM= U disabled in bios too?
Hmmm I can't quite remember, it's quite a blur after a week o= f sleepless nights. I'll give it another whirl and see what happens.

Also, I = assume that=A0

memory =3D '34096'
Yes sorry typo, I p= ulled that up quickly from a site I borrowed that config from, was changing= it to "4096"


Any r= ecommendations for logging to watch? Generally I tail -f a log on my screen= and then ssh in to execute xm create. But the logs just die, hoping to fin= d that right one which just shows the error before a freeze.


Best Regards,
Almir kadric

Website: www.almirkadric.com
Mobile:=A0=A0= =A0=A0 +81 90 8008 1578
Office:=A0=A0=A0=A0= =A0 +81 03 4550 1448
Email: almir@kadric.com

On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote:

Hi,

Sounds like you have been testing extens= ively. If I get you right, dom0 freezes or reboots when you try to start th= e VM, but works otherwise?

I assume you have tried with IOMMU disabled in bios too? In case of a b= uggy bios, turning IOMMU off could possibly make a difference (in order to = find the problem, I realize that you plan to use IOMMU).

Also, I assume that 

memory =3D '34096'

Is a typo? Since you say that you h= ave tried different vm configs.

Regards,
Andreas


2013/= 3/18 Almir Kadric <almir@kadric.com>
Hi all,

I'm coming fro= m a lxc background and recently found a real need for a full virtualised wi= ndows solution. In the past I have stuck it out with Linux, but Wine just h= asn't been performing and I've had nothing but problems. Anyways I = tried a few things, and just could not get XEN to work for the life of me. = I got KVM working but VGA passthrough was a pain, I could never get it to a= ccept a device, even after I blacklisted it. Eventually I got around to XEN= as it is supposed to do this better, however I could not get past the firs= t stage ... a simple minimal virtual machine. No matter what I did, no matt= er which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) would either r= eboot or lockup. I tried looking for errors in messages, kernel, xen/* but = nothing really stood out.

So my question would be what am I missing? What logs sh= ould I be looking at?

I managed to fix the small b= ugs which popped up like files being in wrong places etc. Lastly I ran this= using xm create <config> and after that it would just hang. Machine = would become unresponsive, or reboot.

Also I did look around if anyone was having these probl= ems, and found a few threads with the exact same issue, but no answers so f= ar.

I would really appreciate some help to just be able to = start the machine with nothing fancy then I could possibly take it from the= re.
Also if anyone has any good links to guides for successful se= tups compiling from source, preferably on Debian installation. Don't ge= t me wrong, I'm no Linux dummy, just would be nice to have something th= at proven to work before I start stabbing around.

I've been working on this on and off for about a we= ek, and quite frankly feel extremely defeated by it =3D_=3D

<= /div>
To help you understand what I may have done wrong I will attach s= ome information below:

System:
Motherboard: GA-970A-D3 (rev 1= .3, BIOS F10)
CPU: AMD FX 8300 @ 3.3GHz
GPU: Powercolor= ATI Radeon 5970
RAM: 16GB Corsair=A0CML16GX3M2A1600C10B @ 1333

Setups tried:
All were done with a Win= dows 7 x86_64 guest VM

Debian 6: Standard b= ridge. Installed xen-linux-system, in-fact I followed the official guide=A0= http://wiki.debian= .org/Xen=A0and=A0quite a few others.
Debian 7: same as above, found more guides etc
Above 2 would= crash and just become plain unresponsive

Ubuntu 1= 2.10: Similar, instead followed ubuntu related guides
This one wo= uld reboot the dom0

Things I tried or did do before you ask them:
- Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki documents (refere= nced these a lot).
- Made sure that svm was enabled during kernel boot (xm dmsg)
- Made sure that IOMMU was enabled during kernel boot (xm dmsg), however = this behaved a bit wierd, so i didnt use pci pass through right off the bat= . Well again I couldnt even start the vm so no point.

Things I didn't try:
- Compile XEN= kernel and dom0 kernel from source

My HVM conf= ig:
(Though I technically tried a few different combinatio= ns from different guide, including some very minimal ones)
name =3D 'xenvm1'

kernel =3D '/usr/lib/xen-4.0/boot/hvmloader'
builder =3D 'hvm'
memory =3D '34096'
shadow_memory =3D '8'
device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm'
disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ]
vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef']
boot=3D'dc'
vnc=3D1
vncviewer=3D0
sdl=3D0
vcpus=3D4
usbdevice=3D'tablet'
on_poweroff =3D 'destroy'
on_reboot =3D 'restart'
on_crash =3D 'restart'


Best Regards,
Almir kadric

____________= ___________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

_______________________________________________
Xen-users mailing listXen-users@li= sts.xen.org
http://lists.xen.org/xen-users


--089e0158c3960292cd04d83049bc-- --===============0890766988162148421== 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 --===============0890766988162148421==-- From xen-users-bounces@lists.xen.org Mon Mar 18 10:17:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:17: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 1UHX7Y-0001kQ-Ez; Mon, 18 Mar 2013 10:16:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHX7W-0001kL-Rf for xen-users@lists.xen.org; Mon, 18 Mar 2013 10:16:47 +0000 Received: from [85.158.137.99:22143] by server-9.bemta-3.messagelabs.com id 86/3F-32531-D89E6415; Mon, 18 Mar 2013 10:16:45 +0000 X-Env-Sender: falck.andreas.lists@gmail.com X-Msg-Ref: server-3.tower-217.messagelabs.com!1363601802!12030344!1 X-Originating-IP: [209.85.215.46] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19358 invoked from network); 18 Mar 2013 10:16:42 -0000 Received: from mail-la0-f46.google.com (HELO mail-la0-f46.google.com) (209.85.215.46) by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 10:16:42 -0000 Received: by mail-la0-f46.google.com with SMTP id fq12so5735297lab.5 for ; Mon, 18 Mar 2013 03:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FQHTkLEq/iWORWflryP4S2xwOZXvEmwle8NKWFMwrvk=; b=WBu5DZNh7metp/plK3YweERmtbH/h1BPpauYriVaAeIZdzk8+7cC7XOQT0w1NGqlyr USZbXHFLGWhi+9jWgUU054wuf9/Li0vl4jLHyf/AUU/naN6yRJuAZOLimxotUN3G1mIx 6FYjYDk4e/oxDyxRPV7omhCfguMg7nMrP04Oc9iury6zLLGpoLcSlnMkfKodExX5C5Xc inryYPhv23KL/4huUn0XoxSnU4rMu2uimAyfY8kyvnnrOMmLiCh0+JwpDKlxpWU7DNNv EP3yDHo8Zp81jT3F99fYOKOqkIsVGrlpK/2z1j2nsYyOTbN2CgVD6uxyD5dhuYVlVpE+ RBog== MIME-Version: 1.0 X-Received: by 10.152.28.3 with SMTP id x3mr13061253lag.27.1363601801776; Mon, 18 Mar 2013 03:16:41 -0700 (PDT) Received: by 10.114.21.230 with HTTP; Mon, 18 Mar 2013 03:16:41 -0700 (PDT) In-Reply-To: References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> Date: Mon, 18 Mar 2013 11:16:41 +0100 Message-ID: From: Andreas Falck To: Almir Kadric Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============0890766988162148421==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0890766988162148421== Content-Type: multipart/alternative; boundary=089e0158c3960292cd04d83049bc --089e0158c3960292cd04d83049bc Content-Type: text/plain; charset=ISO-8859-1 Hi Almir, Sorry, I have no good advice on which logs to watch. It is possible that if the dom0 kernel ever gets time to ouput something, it will do it to the console. One piece of information that might be useful for further debugging is whether the error occurs when the VM kernel boots or already when the HVM bios boots. You can try this by starting a HVM vm without any virtual disk, thus booting only the HVM bios. Also, it would probably be of interest to know if a PV guest works (you can probably do this easily by starting only a PV kernel, no need to install a full PV system). However, I am not sure on what to do with that information, but someone else might have a clue. Regards, Andreas 2013/3/18 Almir Kadric > Hi, Andreas, > > Thanks for your quick response ^_^ > > Sounds like you have been testing extensively. If I get you right, dom0 > freezes or reboots when you try to start the VM, but works otherwise? > > To say the least yes I have, a lot of sleep lost over this. orz > > If I get you right, dom0 freezes or reboots when you try to start the VM, > but works otherwise? > > That's correct, dom0 works perfectly fine, right up until I start a domU. > Regardless of what's in that domU. > > I assume you have tried with IOMMU disabled in bios too? > > Hmmm I can't quite remember, it's quite a blur after a week of sleepless > nights. I'll give it another whirl and see what happens. > > Also, I assume that > > memory = '34096' > > Yes sorry typo, I pulled that up quickly from a site I borrowed that > config from, was changing it to "4096" > > > Any recommendations for logging to watch? Generally I tail -f a log on my > screen and then ssh in to execute xm create. But the logs just die, hoping > to find that right one which just shows the error before a freeze. > > > Best Regards, > Almir kadric > > Website: www.almirkadric.com > Mobile: +81 90 8008 1578**** > Office: +81 03 4550 1448 > Email: almir@kadric.com > > On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote: > > Hi, > > Sounds like you have been testing extensively. If I get you right, dom0 > freezes or reboots when you try to start the VM, but works otherwise? > > I assume you have tried with IOMMU disabled in bios too? In case of a > buggy bios, turning IOMMU off could possibly make a difference (in order to > find the problem, I realize that you plan to use IOMMU). > > Also, I assume that > > memory = '34096' > > > Is a typo? Since you say that you have tried different vm configs. > > Regards, > Andreas > > > 2013/3/18 Almir Kadric > >> Hi all, >> >> I'm coming from a lxc background and recently found a real need for a >> full virtualised windows solution. In the past I have stuck it out with >> Linux, but Wine just hasn't been performing and I've had nothing but >> problems. Anyways I tried a few things, and just could not get XEN to work >> for the life of me. I got KVM working but VGA passthrough was a pain, I >> could never get it to accept a device, even after I blacklisted it. >> Eventually I got around to XEN as it is supposed to do this better, however >> I could not get past the first stage ... a simple minimal virtual machine. >> No matter what I did, no matter which distro (Debian 6,7 and Ubuntu 12.10) >> my Host (dom0) would either reboot or lockup. I tried looking for errors in >> messages, kernel, xen/* but nothing really stood out. >> >> So my question would be what am I missing? What logs should I be looking >> at? >> >> I managed to fix the small bugs which popped up like files being in wrong >> places etc. Lastly I ran this using xm create and after that it >> would just hang. Machine would become unresponsive, or reboot. >> >> Also I did look around if anyone was having these problems, and found a >> few threads with the exact same issue, but no answers so far. >> http://lists.debian.org/debian-user/2011/12/msg01779.html >> >> http://xen.markmail.org/search/?q=GA-970A#query:GA-970A+page:1+mid:fwgjnzmfy4pylgiu+state:results >> >> I would really appreciate some help to just be able to start the machine >> with nothing fancy then I could possibly take it from there. >> Also if anyone has any good links to guides for successful setups >> compiling from source, preferably on Debian installation. Don't get me >> wrong, I'm no Linux dummy, just would be nice to have something that proven >> to work before I start stabbing around. >> >> I've been working on this on and off for about a week, and quite frankly >> feel extremely defeated by it =_= >> >> To help you understand what I may have done wrong I will attach some >> information below: >> >> *System:* >> Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) >> CPU: AMD FX 8300 @ 3.3GHz >> GPU: Powercolor ATI Radeon 5970 >> RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 >> >> *Setups tried:* >> All were done with a Windows 7 x86_64 guest VM >> * >> * >> Debian 6: Standard bridge. Installed xen-linux-system, in-fact I followed >> the official guide http://wiki.debian.org/Xen and quite a few others. >> Debian 7: same as above, found more guides etc >> Above 2 would crash and just become plain unresponsive >> >> Ubuntu 12.10: Similar, instead followed ubuntu related guides >> This one would reboot the dom0 >> >> *Things I tried or did do before you ask them:* >> - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) >> - Enabled IOMMU via kernel options as per XEN wiki documents (referenced >> these a lot). >> - Made sure that svm was enabled during kernel boot (xm dmsg) >> - Made sure that IOMMU was enabled during kernel boot (xm dmsg), however >> this behaved a bit wierd, so i didnt use pci pass through right off the >> bat. Well again I couldnt even start the vm so no point. >> >> *Things I didn't try:* >> - Compile XEN kernel and dom0 kernel from source >> >> *My HVM config:* >> *(Though I technically tried a few different combinations from different >> guide, including some very minimal ones)* >> >> name = 'xenvm1' >> >> kernel = '/usr/lib/xen-4.0/boot/hvmloader' >> builder = 'hvm' >> memory = '34096' >> shadow_memory = '8' >> device_model='/usr/lib/xen-4.0/bin/qemu-dm' >> disk = [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] >> vif = ['bridge=br0, mac=01:23:de:ad:be:ef'] >> boot='dc' >> vnc=1 >> vncviewer=0 >> sdl=0 >> vcpus=4 >> usbdevice='tablet' >> on_poweroff = 'destroy' >> on_reboot = 'restart' >> on_crash = 'restart' >> >> >> >> Best Regards, >> Almir kadric >> >> _______________________________________________ >> 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 > > > --089e0158c3960292cd04d83049bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Almir,

Sorry, I have no good advice on which logs to watch. It is= possible that if the dom0 kernel ever gets time to ouput something, it wil= l do it to the console.

One piece of information that might be usefu= l for further debugging is whether the error occurs when the VM kernel boot= s or already when the HVM bios boots. You can try this by starting a HVM vm= without any virtual disk, thus booting only the HVM bios. Also, it would p= robably be of interest to know if a PV guest works (you can probably do thi= s easily by starting only a PV kernel, no need to install a full PV system)= . However, I am not sure on what to do with that information, but someone e= lse might have a clue.

Regards,
Andreas

2013/3/18 Almir K= adric <almir@kadric.com>
Hi, Andreas,

<= div>Thanks for your quick response ^_^

Sounds like you have been testing extensively. If I g= et you right, dom0 freezes or reboots when you try to start the VM, but wor= ks otherwise?
To say the least yes I have, a lot of sleep lost over this. =A0orz

If I get= you right, dom0 freezes or reboots when you try to start the VM, but works= otherwise?
That's correct, dom0 works perfectly fine, right up until I start= a domU. Regardless of what's in that domU.

I assume you have tried with IOMM= U disabled in bios too?
Hmmm I can't quite remember, it's quite a blur after a week o= f sleepless nights. I'll give it another whirl and see what happens.

Also, I = assume that=A0

memory =3D '34096'
Yes sorry typo, I p= ulled that up quickly from a site I borrowed that config from, was changing= it to "4096"


Any r= ecommendations for logging to watch? Generally I tail -f a log on my screen= and then ssh in to execute xm create. But the logs just die, hoping to fin= d that right one which just shows the error before a freeze.


Best Regards,
Almir kadric

Website: www.almirkadric.com
Mobile:=A0=A0= =A0=A0 +81 90 8008 1578
Office:=A0=A0=A0=A0= =A0 +81 03 4550 1448
Email: almir@kadric.com

On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote:

Hi,

Sounds like you have been testing extens= ively. If I get you right, dom0 freezes or reboots when you try to start th= e VM, but works otherwise?

I assume you have tried with IOMMU disabled in bios too? In case of a b= uggy bios, turning IOMMU off could possibly make a difference (in order to = find the problem, I realize that you plan to use IOMMU).

Also, I assume that 

memory =3D '34096'

Is a typo? Since you say that you h= ave tried different vm configs.

Regards,
Andreas


2013/= 3/18 Almir Kadric <almir@kadric.com>
Hi all,

I'm coming fro= m a lxc background and recently found a real need for a full virtualised wi= ndows solution. In the past I have stuck it out with Linux, but Wine just h= asn't been performing and I've had nothing but problems. Anyways I = tried a few things, and just could not get XEN to work for the life of me. = I got KVM working but VGA passthrough was a pain, I could never get it to a= ccept a device, even after I blacklisted it. Eventually I got around to XEN= as it is supposed to do this better, however I could not get past the firs= t stage ... a simple minimal virtual machine. No matter what I did, no matt= er which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) would either r= eboot or lockup. I tried looking for errors in messages, kernel, xen/* but = nothing really stood out.

So my question would be what am I missing? What logs sh= ould I be looking at?

I managed to fix the small b= ugs which popped up like files being in wrong places etc. Lastly I ran this= using xm create <config> and after that it would just hang. Machine = would become unresponsive, or reboot.

Also I did look around if anyone was having these probl= ems, and found a few threads with the exact same issue, but no answers so f= ar.

I would really appreciate some help to just be able to = start the machine with nothing fancy then I could possibly take it from the= re.
Also if anyone has any good links to guides for successful se= tups compiling from source, preferably on Debian installation. Don't ge= t me wrong, I'm no Linux dummy, just would be nice to have something th= at proven to work before I start stabbing around.

I've been working on this on and off for about a we= ek, and quite frankly feel extremely defeated by it =3D_=3D

<= /div>
To help you understand what I may have done wrong I will attach s= ome information below:

System:
Motherboard: GA-970A-D3 (rev 1= .3, BIOS F10)
CPU: AMD FX 8300 @ 3.3GHz
GPU: Powercolor= ATI Radeon 5970
RAM: 16GB Corsair=A0CML16GX3M2A1600C10B @ 1333

Setups tried:
All were done with a Win= dows 7 x86_64 guest VM

Debian 6: Standard b= ridge. Installed xen-linux-system, in-fact I followed the official guide=A0= http://wiki.debian= .org/Xen=A0and=A0quite a few others.
Debian 7: same as above, found more guides etc
Above 2 would= crash and just become plain unresponsive

Ubuntu 1= 2.10: Similar, instead followed ubuntu related guides
This one wo= uld reboot the dom0

Things I tried or did do before you ask them:
- Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki documents (refere= nced these a lot).
- Made sure that svm was enabled during kernel boot (xm dmsg)
- Made sure that IOMMU was enabled during kernel boot (xm dmsg), however = this behaved a bit wierd, so i didnt use pci pass through right off the bat= . Well again I couldnt even start the vm so no point.

Things I didn't try:
- Compile XEN= kernel and dom0 kernel from source

My HVM conf= ig:
(Though I technically tried a few different combinatio= ns from different guide, including some very minimal ones)
name =3D 'xenvm1'

kernel =3D '/usr/lib/xen-4.0/boot/hvmloader'
builder =3D 'hvm'
memory =3D '34096'
shadow_memory =3D '8'
device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm'
disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ]
vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef']
boot=3D'dc'
vnc=3D1
vncviewer=3D0
sdl=3D0
vcpus=3D4
usbdevice=3D'tablet'
on_poweroff =3D 'destroy'
on_reboot =3D 'restart'
on_crash =3D 'restart'


Best Regards,
Almir kadric

____________= ___________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

_______________________________________________
Xen-users mailing listXen-users@li= sts.xen.org
http://lists.xen.org/xen-users


--089e0158c3960292cd04d83049bc-- --===============0890766988162148421== 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 --===============0890766988162148421==-- From xen-users-bounces@lists.xen.org Mon Mar 18 10:20:16 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:20: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 1UHXAK-0001tT-Ar; Mon, 18 Mar 2013 10:19:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHXAI-0001tG-9M for xen-users@lists.xen.org; Mon, 18 Mar 2013 10:19:38 +0000 Received: from [85.158.138.51:23368] by server-12.bemta-3.messagelabs.com id E5/FB-01357-93AE6415; Mon, 18 Mar 2013 10:19:37 +0000 X-Env-Sender: aaron.cossey@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1363601976!19174544!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3836 invoked from network); 18 Mar 2013 10:19:36 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 10:19:36 -0000 Received: by mail-wi0-f182.google.com with SMTP id hi18so2363207wib.9 for ; Mon, 18 Mar 2013 03:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+knWR2+1/FXnZ5VpR0Ih2tf8nR40VTw5nwCEnf3u9Yk=; b=tL2TLMM0naCiy1PlTYZcsGmxwfMj9FXh/rL2YO3XXTo22/AeCNgJMC2y3N6M1DBqFP MMUL5ci5tr8o1y8xGcfz/uLO97DBdYEYMYkGKJhcEoAvNoACknM8LWqrPybB2cmATNb7 gT4xkXN10rOYG3sroJmzBXQKw8H1pDyRb/Z6NS0JtCpfKnVgKIlnIldXHlgnoYts44aS xmxi9/4Y/S+Z7klfmgBe9pYoLEyoyJenYiXf0MmLpg5ZG10Fz/KFCl3b8EXI13neltbp ur8YZ7KipQVQo3DEWPJAIFBcmkW1u9i12VvKjdbSXYLbMNuqMuYcSJoCWmMV0B2Hg141 m+xg== MIME-Version: 1.0 X-Received: by 10.194.21.233 with SMTP id y9mr15959124wje.47.1363601976291; Mon, 18 Mar 2013 03:19:36 -0700 (PDT) Received: by 10.194.138.40 with HTTP; Mon, 18 Mar 2013 03:19:36 -0700 (PDT) In-Reply-To: References: <1363598246.29093.188.camel@zion.uk.xensource.com> Date: Mon, 18 Mar 2013 11:19:36 +0100 Message-ID: From: Aaron Cossey To: Cao Wenz Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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="===============3271309314456454514==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3271309314456454514== Content-Type: multipart/alternative; boundary=047d7b5d2774697e4b04d83053cd --047d7b5d2774697e4b04d83053cd Content-Type: text/plain; charset=ISO-8859-1 Is this a copy/paste error or a missing "d" ? 18 isk = [ 'file:/vm/domU.img,sda1,w' ] Aaron Cossey aaron.cossey@gmail.com On Mon, Mar 18, 2013 at 10:49 AM, Cao Wenz wrote: > ---------- Forwarded message ---------- > From: Cao Wenz > Date: 2013/3/18 > Subject: Re: [Xen-users] VM is paused when it is created > To: Wei Liu > > > > > > Try replacing "sda1" with "xvda1" or "xvda". > > > > > > I try it, but the VM also hangs during bootup. > > BTW, when VM hangs, I can 'ping' it. > Than I try ssh it. When I have inputed passwd, it does not any respond. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --047d7b5d2774697e4b04d83053cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is this a copy/paste error or a missing "d"= ?

18 isk =3D [ 'file:/vm/domU.img,sda1,w' ]

Aaron Cossey
aaron.cossey@gmail.com


On Mon, Mar 18, 2013 at 10:49 AM, Cao We= nz <wenzcao@gmail.com> wrote:
---------- Forwarded message ----------
From: Cao Wenz <wenzcao@gmail.com>
Date: 2013/3/18
Subject: Re: [Xen-users] VM is paused when it is created
To: Wei Liu <wei.liu2@citrix.com<= /a>>


>
> Try replacing "sda1" with "xvda1" or "xvda&qu= ot;.
>
>

I try it, but the VM also hangs during bootup.

BTW, when VM hangs, I can 'ping' it.
Than I try ssh it. When I have inputed passwd, it does not any respond.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--047d7b5d2774697e4b04d83053cd-- --===============3271309314456454514== 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 --===============3271309314456454514==-- From xen-users-bounces@lists.xen.org Mon Mar 18 10:20:16 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:20: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 1UHXAK-0001tT-Ar; Mon, 18 Mar 2013 10:19:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHXAI-0001tG-9M for xen-users@lists.xen.org; Mon, 18 Mar 2013 10:19:38 +0000 Received: from [85.158.138.51:23368] by server-12.bemta-3.messagelabs.com id E5/FB-01357-93AE6415; Mon, 18 Mar 2013 10:19:37 +0000 X-Env-Sender: aaron.cossey@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1363601976!19174544!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3836 invoked from network); 18 Mar 2013 10:19:36 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 10:19:36 -0000 Received: by mail-wi0-f182.google.com with SMTP id hi18so2363207wib.9 for ; Mon, 18 Mar 2013 03:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+knWR2+1/FXnZ5VpR0Ih2tf8nR40VTw5nwCEnf3u9Yk=; b=tL2TLMM0naCiy1PlTYZcsGmxwfMj9FXh/rL2YO3XXTo22/AeCNgJMC2y3N6M1DBqFP MMUL5ci5tr8o1y8xGcfz/uLO97DBdYEYMYkGKJhcEoAvNoACknM8LWqrPybB2cmATNb7 gT4xkXN10rOYG3sroJmzBXQKw8H1pDyRb/Z6NS0JtCpfKnVgKIlnIldXHlgnoYts44aS xmxi9/4Y/S+Z7klfmgBe9pYoLEyoyJenYiXf0MmLpg5ZG10Fz/KFCl3b8EXI13neltbp ur8YZ7KipQVQo3DEWPJAIFBcmkW1u9i12VvKjdbSXYLbMNuqMuYcSJoCWmMV0B2Hg141 m+xg== MIME-Version: 1.0 X-Received: by 10.194.21.233 with SMTP id y9mr15959124wje.47.1363601976291; Mon, 18 Mar 2013 03:19:36 -0700 (PDT) Received: by 10.194.138.40 with HTTP; Mon, 18 Mar 2013 03:19:36 -0700 (PDT) In-Reply-To: References: <1363598246.29093.188.camel@zion.uk.xensource.com> Date: Mon, 18 Mar 2013 11:19:36 +0100 Message-ID: From: Aaron Cossey To: Cao Wenz Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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="===============3271309314456454514==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3271309314456454514== Content-Type: multipart/alternative; boundary=047d7b5d2774697e4b04d83053cd --047d7b5d2774697e4b04d83053cd Content-Type: text/plain; charset=ISO-8859-1 Is this a copy/paste error or a missing "d" ? 18 isk = [ 'file:/vm/domU.img,sda1,w' ] Aaron Cossey aaron.cossey@gmail.com On Mon, Mar 18, 2013 at 10:49 AM, Cao Wenz wrote: > ---------- Forwarded message ---------- > From: Cao Wenz > Date: 2013/3/18 > Subject: Re: [Xen-users] VM is paused when it is created > To: Wei Liu > > > > > > Try replacing "sda1" with "xvda1" or "xvda". > > > > > > I try it, but the VM also hangs during bootup. > > BTW, when VM hangs, I can 'ping' it. > Than I try ssh it. When I have inputed passwd, it does not any respond. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --047d7b5d2774697e4b04d83053cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is this a copy/paste error or a missing "d"= ?

18 isk =3D [ 'file:/vm/domU.img,sda1,w' ]

Aaron Cossey
aaron.cossey@gmail.com


On Mon, Mar 18, 2013 at 10:49 AM, Cao We= nz <wenzcao@gmail.com> wrote:
---------- Forwarded message ----------
From: Cao Wenz <wenzcao@gmail.com>
Date: 2013/3/18
Subject: Re: [Xen-users] VM is paused when it is created
To: Wei Liu <wei.liu2@citrix.com<= /a>>


>
> Try replacing "sda1" with "xvda1" or "xvda&qu= ot;.
>
>

I try it, but the VM also hangs during bootup.

BTW, when VM hangs, I can 'ping' it.
Than I try ssh it. When I have inputed passwd, it does not any respond.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--047d7b5d2774697e4b04d83053cd-- --===============3271309314456454514== 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 --===============3271309314456454514==-- From xen-users-bounces@lists.xen.org Mon Mar 18 10:25:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:25: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 1UHXFZ-0002JB-IL; Mon, 18 Mar 2013 10:25:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHXFY-0002J0-Lz for xen-users@lists.xensource.com; Mon, 18 Mar 2013 10:25:04 +0000 Received: from [85.158.138.51:50215] by server-9.bemta-3.messagelabs.com id 88/55-32531-F7BE6415; Mon, 18 Mar 2013 10:25:03 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1363602301!28084881!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18270 invoked from network); 18 Mar 2013 10:25:03 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 18 Mar 2013 10:25:03 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UHXFV-0002Bv-64 for xen-users@lists.xensource.com; Mon, 18 Mar 2013 03:25:01 -0700 Date: Mon, 18 Mar 2013 03:25:01 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363602301181-5714901.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 want to create a full-virtualization xen VM with autoyast installation. how can i do that? and how does the configuration file to be configured? I use suse linux 11 SP2. looking forward your replay. Jing. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901.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 Mon Mar 18 10:25:42 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:25: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 1UHXFZ-0002JB-IL; Mon, 18 Mar 2013 10:25:05 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHXFY-0002J0-Lz for xen-users@lists.xensource.com; Mon, 18 Mar 2013 10:25:04 +0000 Received: from [85.158.138.51:50215] by server-9.bemta-3.messagelabs.com id 88/55-32531-F7BE6415; Mon, 18 Mar 2013 10:25:03 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-11.tower-174.messagelabs.com!1363602301!28084881!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18270 invoked from network); 18 Mar 2013 10:25:03 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 18 Mar 2013 10:25:03 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UHXFV-0002Bv-64 for xen-users@lists.xensource.com; Mon, 18 Mar 2013 03:25:01 -0700 Date: Mon, 18 Mar 2013 03:25:01 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363602301181-5714901.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 want to create a full-virtualization xen VM with autoyast installation. how can i do that? and how does the configuration file to be configured? I use suse linux 11 SP2. looking forward your replay. Jing. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901.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 Mon Mar 18 10:40:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:40: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 1UHXUG-0003iN-Cu; Mon, 18 Mar 2013 10:40:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHXUE-0003iD-RS for xen-users@lists.xen.org; Mon, 18 Mar 2013 10:40:15 +0000 Received: from [85.158.139.83:49963] by server-1.bemta-5.messagelabs.com id D6/CA-14063-E0FE6415; Mon, 18 Mar 2013 10:40:14 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1363603188!24039346!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27511 invoked from network); 18 Mar 2013 10:39:49 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 10:39:49 -0000 X-IronPort-AV: E=Sophos;i="4.84,863,1355097600"; d="scan'208";a="13779518" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 18 Mar 2013 10:39:47 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.3; Mon, 18 Mar 2013 06:39:47 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UHXTm-0006w8-W4; Mon, 18 Mar 2013 10:39:46 +0000 Message-ID: <1363603186.29093.191.camel@zion.uk.xensource.com> From: Wei Liu To: Cao Wenz Date: Mon, 18 Mar 2013 10:39:46 +0000 In-Reply-To: References: <1363598246.29093.188.camel@zion.uk.xensource.com> X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , wei.liu2@citrix.com Subject: Re: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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, 2013-03-18 at 09:49 +0000, Cao Wenz wrote: > ---------- Forwarded message ---------- > From: Cao Wenz > Date: 2013/3/18 > Subject: Re: [Xen-users] VM is paused when it is created > To: Wei Liu > > > > > > Try replacing "sda1" with "xvda1" or "xvda". > > > > > > I try it, but the VM also hangs during bootup. > > BTW, when VM hangs, I can 'ping' it. > Than I try ssh it. When I have inputed passwd, it does not any respond. > Then if you can see the prompt for password, it is running -- network is up, and presumably your sshd resides in your disk image, that means the disk works to. It could be just that you didn't spawn a tty on the serial console. As for the ssh problem, I cannot help much with it. Wei. > _______________________________________________ > 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 Mar 18 10:40:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:40: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 1UHXUG-0003iN-Cu; Mon, 18 Mar 2013 10:40:16 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHXUE-0003iD-RS for xen-users@lists.xen.org; Mon, 18 Mar 2013 10:40:15 +0000 Received: from [85.158.139.83:49963] by server-1.bemta-5.messagelabs.com id D6/CA-14063-E0FE6415; Mon, 18 Mar 2013 10:40:14 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1363603188!24039346!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27511 invoked from network); 18 Mar 2013 10:39:49 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 10:39:49 -0000 X-IronPort-AV: E=Sophos;i="4.84,863,1355097600"; d="scan'208";a="13779518" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 18 Mar 2013 10:39:47 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.3; Mon, 18 Mar 2013 06:39:47 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UHXTm-0006w8-W4; Mon, 18 Mar 2013 10:39:46 +0000 Message-ID: <1363603186.29093.191.camel@zion.uk.xensource.com> From: Wei Liu To: Cao Wenz Date: Mon, 18 Mar 2013 10:39:46 +0000 In-Reply-To: References: <1363598246.29093.188.camel@zion.uk.xensource.com> X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , wei.liu2@citrix.com Subject: Re: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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, 2013-03-18 at 09:49 +0000, Cao Wenz wrote: > ---------- Forwarded message ---------- > From: Cao Wenz > Date: 2013/3/18 > Subject: Re: [Xen-users] VM is paused when it is created > To: Wei Liu > > > > > > Try replacing "sda1" with "xvda1" or "xvda". > > > > > > I try it, but the VM also hangs during bootup. > > BTW, when VM hangs, I can 'ping' it. > Than I try ssh it. When I have inputed passwd, it does not any respond. > Then if you can see the prompt for password, it is running -- network is up, and presumably your sshd resides in your disk image, that means the disk works to. It could be just that you didn't spawn a tty on the serial console. As for the ssh problem, I cannot help much with it. Wei. > _______________________________________________ > 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 Mar 18 10:57:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:57: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 1UHXkK-0004vX-JT; Mon, 18 Mar 2013 10:56:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHXkI-0004vE-PK for xen-users@lists.xen.org; Mon, 18 Mar 2013 10:56:51 +0000 Received: from [85.158.138.51:29411] by server-10.bemta-3.messagelabs.com id D7/20-19664-DE2F6415; Mon, 18 Mar 2013 10:56:45 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1363604204!19182206!1 X-Originating-IP: [74.125.82.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16022 invoked from network); 18 Mar 2013 10:56:44 -0000 Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com) (74.125.82.171) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 10:56:44 -0000 Received: by mail-we0-f171.google.com with SMTP id u54so4820102wey.30 for ; Mon, 18 Mar 2013 03:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=00M2DwPnGA9aFgKhP+K88Pkul0DdcgPjEwiIdnc55Qs=; b=ISyuMN+khzDspifP9+JchloyMmUmv7UyguKsVl92+CzK+oY8U1b+JljL4NgVv8jgDv W4YZw/Sho7ULGdkhJ64M6mfTq0vL4VTlfjKOSuCDFhhwgY8RjO2ihoK3JQL2DYNwDu5f 1r1UU2NJEJtzkBBNzNpQ+PKz1/ynu9wedjGFgqLf+iGFpLUwRMfb2YQ3An4nfnmrFp2n OX1Owh/yGsk5n1dvZNcHh2LRN1ZFXyXxoi/0Z3pwreyqGugP1D8EjIepzA6IFTMXzv3x 8Ef6gS76BSaMFT+KHg7RsGR2k9/MTTdzw+Bo0553w0A7d0KltUqcpke9iHyOIqNHo6Bw 59cw== MIME-Version: 1.0 X-Received: by 10.180.104.225 with SMTP id gh1mr3781791wib.27.1363604204188; Mon, 18 Mar 2013 03:56:44 -0700 (PDT) Received: by 10.194.153.36 with HTTP; Mon, 18 Mar 2013 03:56:44 -0700 (PDT) In-Reply-To: References: <1363598246.29093.188.camel@zion.uk.xensource.com> Date: Mon, 18 Mar 2013 18:56:44 +0800 Message-ID: From: Cao Wenz To: Aaron Cossey Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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 it is a copy/paste error 2013/3/18 Aaron Cossey : > Is this a copy/paste error or a missing "d" ? > > 18 isk = [ 'file:/vm/domU.img,sda1,w' ] > > Aaron Cossey > aaron.cossey@gmail.com > > > On Mon, Mar 18, 2013 at 10:49 AM, Cao Wenz wrote: >> >> ---------- Forwarded message ---------- >> From: Cao Wenz >> Date: 2013/3/18 >> Subject: Re: [Xen-users] VM is paused when it is created >> To: Wei Liu >> >> >> > >> > Try replacing "sda1" with "xvda1" or "xvda". >> > >> > >> >> I try it, but the VM also hangs during bootup. >> >> BTW, when VM hangs, I can 'ping' it. >> Than I try ssh it. When I have inputed passwd, it does not any respond. >> >> _______________________________________________ >> 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 Mar 18 10:57:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 10:57: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 1UHXkK-0004vX-JT; Mon, 18 Mar 2013 10:56:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHXkI-0004vE-PK for xen-users@lists.xen.org; Mon, 18 Mar 2013 10:56:51 +0000 Received: from [85.158.138.51:29411] by server-10.bemta-3.messagelabs.com id D7/20-19664-DE2F6415; Mon, 18 Mar 2013 10:56:45 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1363604204!19182206!1 X-Originating-IP: [74.125.82.171] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16022 invoked from network); 18 Mar 2013 10:56:44 -0000 Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com) (74.125.82.171) by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 10:56:44 -0000 Received: by mail-we0-f171.google.com with SMTP id u54so4820102wey.30 for ; Mon, 18 Mar 2013 03:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=00M2DwPnGA9aFgKhP+K88Pkul0DdcgPjEwiIdnc55Qs=; b=ISyuMN+khzDspifP9+JchloyMmUmv7UyguKsVl92+CzK+oY8U1b+JljL4NgVv8jgDv W4YZw/Sho7ULGdkhJ64M6mfTq0vL4VTlfjKOSuCDFhhwgY8RjO2ihoK3JQL2DYNwDu5f 1r1UU2NJEJtzkBBNzNpQ+PKz1/ynu9wedjGFgqLf+iGFpLUwRMfb2YQ3An4nfnmrFp2n OX1Owh/yGsk5n1dvZNcHh2LRN1ZFXyXxoi/0Z3pwreyqGugP1D8EjIepzA6IFTMXzv3x 8Ef6gS76BSaMFT+KHg7RsGR2k9/MTTdzw+Bo0553w0A7d0KltUqcpke9iHyOIqNHo6Bw 59cw== MIME-Version: 1.0 X-Received: by 10.180.104.225 with SMTP id gh1mr3781791wib.27.1363604204188; Mon, 18 Mar 2013 03:56:44 -0700 (PDT) Received: by 10.194.153.36 with HTTP; Mon, 18 Mar 2013 03:56:44 -0700 (PDT) In-Reply-To: References: <1363598246.29093.188.camel@zion.uk.xensource.com> Date: Mon, 18 Mar 2013 18:56:44 +0800 Message-ID: From: Cao Wenz To: Aaron Cossey Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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 it is a copy/paste error 2013/3/18 Aaron Cossey : > Is this a copy/paste error or a missing "d" ? > > 18 isk = [ 'file:/vm/domU.img,sda1,w' ] > > Aaron Cossey > aaron.cossey@gmail.com > > > On Mon, Mar 18, 2013 at 10:49 AM, Cao Wenz wrote: >> >> ---------- Forwarded message ---------- >> From: Cao Wenz >> Date: 2013/3/18 >> Subject: Re: [Xen-users] VM is paused when it is created >> To: Wei Liu >> >> >> > >> > Try replacing "sda1" with "xvda1" or "xvda". >> > >> > >> >> I try it, but the VM also hangs during bootup. >> >> BTW, when VM hangs, I can 'ping' it. >> Than I try ssh it. When I have inputed passwd, it does not any respond. >> >> _______________________________________________ >> 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 Mar 18 11:46:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 11:46: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 1UHYVJ-0007Y7-DW; Mon, 18 Mar 2013 11:45:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHYVH-0007Xl-Oi for xen-users@lists.xen.org; Mon, 18 Mar 2013 11:45:23 +0000 Received: from [85.158.138.51:56277] by server-3.bemta-3.messagelabs.com id 56/B3-26934-25EF6415; Mon, 18 Mar 2013 11:45:22 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1363607121!19963712!1 X-Originating-IP: [74.125.82.175] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17429 invoked from network); 18 Mar 2013 11:45:21 -0000 Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 11:45:21 -0000 Received: by mail-we0-f175.google.com with SMTP id x8so4792464wey.20 for ; Mon, 18 Mar 2013 04:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lIGZ5vwq1evYqmlrfPTiBMCC5xZfwwQ5xUn3x1M1Fj4=; b=1A7LGs/x3qsLhjvvSz00wevRy0pzk/vq29DPagWmFnAyptqJD+mfWXI7hTipLzwVLA 30I1nhbDwwhzDAUgUd+MLr3p3A2wk2eUKyZ3jStviqZu0QtdiZVBwqx9SX8tWtBz5vZW iJQGy3KcfgMRn7pokdc08q+yMbmr6gDlJn4FJEVJzLeGxO2ALrJLjn+4S8TrCoZvnoNM qbythGoA1KKGX0zDpYW3S7tg5/WzLDdKk4Po487KGkYG42Jfuh14Ewe8AIyAr22Am7iM KrdI3LIhyxHoUqF4C3oXhGBh+F5TCS/v/MdIB1oicUcxBX9f20tTLPbff3wc5vJ5vMTt s1ww== MIME-Version: 1.0 X-Received: by 10.194.57.137 with SMTP id i9mr24259397wjq.18.1363607119087; Mon, 18 Mar 2013 04:45:19 -0700 (PDT) Received: by 10.194.153.36 with HTTP; Mon, 18 Mar 2013 04:45:18 -0700 (PDT) In-Reply-To: <1363603186.29093.191.camel@zion.uk.xensource.com> References: <1363598246.29093.188.camel@zion.uk.xensource.com> <1363603186.29093.191.camel@zion.uk.xensource.com> Date: Mon, 18 Mar 2013 19:45:18 +0800 Message-ID: From: Cao Wenz To: Wei Liu Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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 Thank you, Wei. I get it. I creat a xvc device, and can enter in VM. 2013/3/18 Wei Liu : > On Mon, 2013-03-18 at 09:49 +0000, Cao Wenz wrote: >> ---------- Forwarded message ---------- >> From: Cao Wenz >> Date: 2013/3/18 >> Subject: Re: [Xen-users] VM is paused when it is created >> To: Wei Liu >> >> >> > >> > Try replacing "sda1" with "xvda1" or "xvda". >> > >> > >> >> I try it, but the VM also hangs during bootup. >> >> BTW, when VM hangs, I can 'ping' it. >> Than I try ssh it. When I have inputed passwd, it does not any respond. >> > > Then if you can see the prompt for password, it is running -- network is > up, and presumably your sshd resides in your disk image, that means the > disk works to. > > It could be just that you didn't spawn a tty on the serial console. As > for the ssh problem, I cannot help much with it. > > > Wei. > >> _______________________________________________ >> 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 Mar 18 11:46:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 11:46: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 1UHYVJ-0007Y7-DW; Mon, 18 Mar 2013 11:45:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHYVH-0007Xl-Oi for xen-users@lists.xen.org; Mon, 18 Mar 2013 11:45:23 +0000 Received: from [85.158.138.51:56277] by server-3.bemta-3.messagelabs.com id 56/B3-26934-25EF6415; Mon, 18 Mar 2013 11:45:22 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1363607121!19963712!1 X-Originating-IP: [74.125.82.175] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17429 invoked from network); 18 Mar 2013 11:45:21 -0000 Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 11:45:21 -0000 Received: by mail-we0-f175.google.com with SMTP id x8so4792464wey.20 for ; Mon, 18 Mar 2013 04:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lIGZ5vwq1evYqmlrfPTiBMCC5xZfwwQ5xUn3x1M1Fj4=; b=1A7LGs/x3qsLhjvvSz00wevRy0pzk/vq29DPagWmFnAyptqJD+mfWXI7hTipLzwVLA 30I1nhbDwwhzDAUgUd+MLr3p3A2wk2eUKyZ3jStviqZu0QtdiZVBwqx9SX8tWtBz5vZW iJQGy3KcfgMRn7pokdc08q+yMbmr6gDlJn4FJEVJzLeGxO2ALrJLjn+4S8TrCoZvnoNM qbythGoA1KKGX0zDpYW3S7tg5/WzLDdKk4Po487KGkYG42Jfuh14Ewe8AIyAr22Am7iM KrdI3LIhyxHoUqF4C3oXhGBh+F5TCS/v/MdIB1oicUcxBX9f20tTLPbff3wc5vJ5vMTt s1ww== MIME-Version: 1.0 X-Received: by 10.194.57.137 with SMTP id i9mr24259397wjq.18.1363607119087; Mon, 18 Mar 2013 04:45:19 -0700 (PDT) Received: by 10.194.153.36 with HTTP; Mon, 18 Mar 2013 04:45:18 -0700 (PDT) In-Reply-To: <1363603186.29093.191.camel@zion.uk.xensource.com> References: <1363598246.29093.188.camel@zion.uk.xensource.com> <1363603186.29093.191.camel@zion.uk.xensource.com> Date: Mon, 18 Mar 2013 19:45:18 +0800 Message-ID: From: Cao Wenz To: Wei Liu Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Fwd: VM is paused when it is created X-BeenThere: xen-users@lists.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 Thank you, Wei. I get it. I creat a xvc device, and can enter in VM. 2013/3/18 Wei Liu : > On Mon, 2013-03-18 at 09:49 +0000, Cao Wenz wrote: >> ---------- Forwarded message ---------- >> From: Cao Wenz >> Date: 2013/3/18 >> Subject: Re: [Xen-users] VM is paused when it is created >> To: Wei Liu >> >> >> > >> > Try replacing "sda1" with "xvda1" or "xvda". >> > >> > >> >> I try it, but the VM also hangs during bootup. >> >> BTW, when VM hangs, I can 'ping' it. >> Than I try ssh it. When I have inputed passwd, it does not any respond. >> > > Then if you can see the prompt for password, it is running -- network is > up, and presumably your sshd resides in your disk image, that means the > disk works to. > > It could be just that you didn't spawn a tty on the serial console. As > for the ssh problem, I cannot help much with it. > > > Wei. > >> _______________________________________________ >> 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 Mar 18 13:31:05 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 13:31:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHa8o-0008Is-SA; Mon, 18 Mar 2013 13:30:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHa8n-0008Ig-Ps for xen-users@lists.xen.org; Mon, 18 Mar 2013 13:30:18 +0000 Received: from [85.158.143.99:64251] by server-2.bemta-4.messagelabs.com id 60/BA-12656-9E617415; Mon, 18 Mar 2013 13:30:17 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1363613412!26800412!1 X-Originating-IP: [209.85.128.172] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5032 invoked from network); 18 Mar 2013 13:30:14 -0000 Received: from mail-ve0-f172.google.com (HELO mail-ve0-f172.google.com) (209.85.128.172) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 13:30:14 -0000 Received: by mail-ve0-f172.google.com with SMTP id cz11so4321345veb.31 for ; Mon, 18 Mar 2013 06:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=i3zDyv+watOMUwKyoXtp6/Ajxv7gGe6DG6adD+NdymQ=; b=xRMnTmWsXRvz2iEXGvybxr5HPn2MGe9LiVgPbBKSrpIxixHn1kUhZhzmOBuHrixnME kRKK7U62IIVfz9RORFxrnVC2YclE3t4c6vRhR+7hXutoDXF42VA8tyVWRvS6vsKGRCgL jndXAnmc1MHjONsfHgQ6/f3V4goq4pAHJ7K9Ecv6qMx/9eEI5e8lY9EwJNZ13G+Pv82x SUUr+5Yu4pYjWGyquvW4clSwss/SAu/92/TOqAnzK6g2Q4bzWF/NQd2V4kwd3PDUtYWD KdFVQz445HSy0B34BmasAYAo4Q7kC8nRnO1uDY6xs2CEUpPeMxQ4UaC+z4/qmlnks6qe 3hQQ== MIME-Version: 1.0 X-Received: by 10.58.50.7 with SMTP id y7mr20073747ven.24.1363613412288; Mon, 18 Mar 2013 06:30:12 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Mon, 18 Mar 2013 06:30:12 -0700 (PDT) In-Reply-To: References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> Date: Mon, 18 Mar 2013 09:30:12 -0400 Message-ID: From: Casey DeLorme To: Andreas Falck Cc: Almir Kadric , "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============1720837810467904045==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1720837810467904045== Content-Type: multipart/alternative; boundary=089e0112c63a0d355e04d832fd86 --089e0112c63a0d355e04d832fd86 Content-Type: text/plain; charset=UTF-8 Hi Almir, I don't have much to offer by way of suggestions for packaged Xen and the xm toolstack, but I wrote a (slightly dated) guide for Debian Wheezybuilding Xen from source, which should hold mostly accurate for Xen 4.2 stable with minor changes. Primary benefit is it is comprehensive, starts with installing Debian and works all the way to running a Windows 7 HVM (DomU), complete with videos. Following that guides instructions minus the EFI Source Modification (which has been patched and only applies) and using Xen 4.2.1 stable (revision 25950 I believe) should take approx. 2~ hours to complete, substantially longer to understand all the details. I intend to update the guide when Debian Wheezy releases as stable. In March last year I was in your shoes, just getting my feet wet with Xen and after a month of failed package tests I went with building from source. If it makes you feel any better about your week, it took me half a year to get things sorted out. Hope this helps, ~Casey On Mon, Mar 18, 2013 at 6:16 AM, Andreas Falck < falck.andreas.lists@gmail.com> wrote: > Hi Almir, > > Sorry, I have no good advice on which logs to watch. It is possible that > if the dom0 kernel ever gets time to ouput something, it will do it to the > console. > > One piece of information that might be useful for further debugging is > whether the error occurs when the VM kernel boots or already when the HVM > bios boots. You can try this by starting a HVM vm without any virtual disk, > thus booting only the HVM bios. Also, it would probably be of interest to > know if a PV guest works (you can probably do this easily by starting only > a PV kernel, no need to install a full PV system). However, I am not sure > on what to do with that information, but someone else might have a clue. > > > Regards, > Andreas > > 2013/3/18 Almir Kadric > >> Hi, Andreas, >> >> Thanks for your quick response ^_^ >> >> Sounds like you have been testing extensively. If I get you right, dom0 >> freezes or reboots when you try to start the VM, but works otherwise? >> >> To say the least yes I have, a lot of sleep lost over this. orz >> >> If I get you right, dom0 freezes or reboots when you try to start the VM, >> but works otherwise? >> >> That's correct, dom0 works perfectly fine, right up until I start a domU. >> Regardless of what's in that domU. >> >> I assume you have tried with IOMMU disabled in bios too? >> >> Hmmm I can't quite remember, it's quite a blur after a week of sleepless >> nights. I'll give it another whirl and see what happens. >> >> Also, I assume that >> >> memory = '34096' >> >> Yes sorry typo, I pulled that up quickly from a site I borrowed that >> config from, was changing it to "4096" >> >> >> Any recommendations for logging to watch? Generally I tail -f a log on my >> screen and then ssh in to execute xm create. But the logs just die, hoping >> to find that right one which just shows the error before a freeze. >> >> >> Best Regards, >> Almir kadric >> >> Website: www.almirkadric.com >> Mobile: +81 90 8008 1578**** >> Office: +81 03 4550 1448 >> Email: almir@kadric.com >> >> On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote: >> >> Hi, >> >> Sounds like you have been testing extensively. If I get you right, dom0 >> freezes or reboots when you try to start the VM, but works otherwise? >> >> I assume you have tried with IOMMU disabled in bios too? In case of a >> buggy bios, turning IOMMU off could possibly make a difference (in order to >> find the problem, I realize that you plan to use IOMMU). >> >> Also, I assume that >> >> memory = '34096' >> >> >> Is a typo? Since you say that you have tried different vm configs. >> >> Regards, >> Andreas >> >> >> 2013/3/18 Almir Kadric >> >>> Hi all, >>> >>> I'm coming from a lxc background and recently found a real need for a >>> full virtualised windows solution. In the past I have stuck it out with >>> Linux, but Wine just hasn't been performing and I've had nothing but >>> problems. Anyways I tried a few things, and just could not get XEN to work >>> for the life of me. I got KVM working but VGA passthrough was a pain, I >>> could never get it to accept a device, even after I blacklisted it. >>> Eventually I got around to XEN as it is supposed to do this better, however >>> I could not get past the first stage ... a simple minimal virtual machine. >>> No matter what I did, no matter which distro (Debian 6,7 and Ubuntu 12.10) >>> my Host (dom0) would either reboot or lockup. I tried looking for errors in >>> messages, kernel, xen/* but nothing really stood out. >>> >>> So my question would be what am I missing? What logs should I be looking >>> at? >>> >>> I managed to fix the small bugs which popped up like files being in >>> wrong places etc. Lastly I ran this using xm create and after that >>> it would just hang. Machine would become unresponsive, or reboot. >>> >>> Also I did look around if anyone was having these problems, and found a >>> few threads with the exact same issue, but no answers so far. >>> http://lists.debian.org/debian-user/2011/12/msg01779.html >>> >>> http://xen.markmail.org/search/?q=GA-970A#query:GA-970A+page:1+mid:fwgjnzmfy4pylgiu+state:results >>> >>> I would really appreciate some help to just be able to start the machine >>> with nothing fancy then I could possibly take it from there. >>> Also if anyone has any good links to guides for successful setups >>> compiling from source, preferably on Debian installation. Don't get me >>> wrong, I'm no Linux dummy, just would be nice to have something that proven >>> to work before I start stabbing around. >>> >>> I've been working on this on and off for about a week, and quite frankly >>> feel extremely defeated by it =_= >>> >>> To help you understand what I may have done wrong I will attach some >>> information below: >>> >>> *System:* >>> Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) >>> CPU: AMD FX 8300 @ 3.3GHz >>> GPU: Powercolor ATI Radeon 5970 >>> RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 >>> >>> *Setups tried:* >>> All were done with a Windows 7 x86_64 guest VM >>> * >>> * >>> Debian 6: Standard bridge. Installed xen-linux-system, in-fact I >>> followed the official guide http://wiki.debian.org/Xen and quite a few >>> others. >>> Debian 7: same as above, found more guides etc >>> Above 2 would crash and just become plain unresponsive >>> >>> Ubuntu 12.10: Similar, instead followed ubuntu related guides >>> This one would reboot the dom0 >>> >>> *Things I tried or did do before you ask them:* >>> - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) >>> - Enabled IOMMU via kernel options as per XEN wiki documents (referenced >>> these a lot). >>> - Made sure that svm was enabled during kernel boot (xm dmsg) >>> - Made sure that IOMMU was enabled during kernel boot (xm dmsg), however >>> this behaved a bit wierd, so i didnt use pci pass through right off the >>> bat. Well again I couldnt even start the vm so no point. >>> >>> *Things I didn't try:* >>> - Compile XEN kernel and dom0 kernel from source >>> >>> *My HVM config:* >>> *(Though I technically tried a few different combinations from >>> different guide, including some very minimal ones)* >>> >>> name = 'xenvm1' >>> >>> kernel = '/usr/lib/xen-4.0/boot/hvmloader' >>> builder = 'hvm' >>> memory = '34096' >>> shadow_memory = '8' >>> device_model='/usr/lib/xen-4.0/bin/qemu-dm' >>> disk = [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] >>> vif = ['bridge=br0, mac=01:23:de:ad:be:ef'] >>> boot='dc' >>> vnc=1 >>> vncviewer=0 >>> sdl=0 >>> vcpus=4 >>> usbdevice='tablet' >>> on_poweroff = 'destroy' >>> on_reboot = 'restart' >>> on_crash = 'restart' >>> >>> >>> >>> Best Regards, >>> Almir kadric >>> >>> _______________________________________________ >>> 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 >> >> >> > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --089e0112c63a0d355e04d832fd86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Almir,


Following that guides instructions minus the EFI Source= Modification (which has been patched and only applies) and using Xen 4.2.1= stable (revision 25950 I believe) should take approx. 2~ hours to complete= , substantially longer to understand all the details.

I intend to update the guide when Debian Wheezy release= s as stable. =C2=A0In March last year I was in your shoes, just getting my = feet wet with Xen and after a month of failed package tests I went with bui= lding from source. =C2=A0If it makes you feel any better about your week, i= t took me half a year to get things sorted out.

Hope this helps,

~Casey


On Mon, Mar 18, 2013 at 6:16 AM, Andreas Falck = <falc= k.andreas.lists@gmail.com> wrote:
Hi Almir,

Sorry, I have no good advic= e on which logs to watch. It is possible that if the dom0 kernel ever gets = time to ouput something, it will do it to the console.

One piece of information that might be useful for further debugging is = whether the error occurs when the VM kernel boots or already when the HVM b= ios boots. You can try this by starting a HVM vm without any virtual disk, = thus booting only the HVM bios. Also, it would probably be of interest to k= now if a PV guest works (you can probably do this easily by starting only a= PV kernel, no need to install a full PV system). However, I am not sure on= what to do with that information, but someone else might have a clue.


Regards,
Andreas

2013/3/18 Almir K= adric <almir@kadric.com>
Hi, Andreas,

<= div>Thanks for your quick response ^_^

Sounds like you have been testing extensively. If I get you right= , dom0 freezes or reboots when you try to start the VM, but works otherwise= ?
To say the least yes I have, a lot of sleep lost over this. =C2=A0orz=

If I get you right= , dom0 freezes or reboots when you try to start the VM, but works otherwise= ?
That's correct, dom0 works perfectly fine, right up until I start= a domU. Regardless of what's in that domU.

I assume you have tried with IOMMU disabled in= bios too?
Hmmm I can't quite remember, it's quite a blur after a week o= f sleepless nights. I'll give it another whirl and see what happens.

Also, I assume that= =C2=A0

memory =3D '34096'
Yes sorry typo, I p= ulled that up quickly from a site I borrowed that config from, was changing= it to "4096"


Any r= ecommendations for logging to watch? Generally I tail -f a log on my screen= and then ssh in to execute xm create. But the logs just die, hoping to fin= d that right one which just shows the error before a freeze.


Best Regards,
Almir kadric

Website: www.almirkadric.com
Mobile:=C2=A0= =C2=A0=C2=A0=C2=A0 +81 90 8008 1578
Office:=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +81 03 4550 1448
Email: almir@kadric.com

On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote:

Hi,

Sounds like you have been testing extens= ively. If I get you right, dom0 freezes or reboots when you try to start th= e VM, but works otherwise?

I assume you have tried with IOMMU disabled in bios too? In case of a b= uggy bios, turning IOMMU off could possibly make a difference (in order to = find the problem, I realize that you plan to use IOMMU).

Also, I assume that 

memory =3D '34096'

Is a typo? Since you say that you h= ave tried different vm configs.

Regards,
Andreas


2013/= 3/18 Almir Kadric <almir@kadric.com>
Hi all,

I'm coming fro= m a lxc background and recently found a real need for a full virtualised wi= ndows solution. In the past I have stuck it out with Linux, but Wine just h= asn't been performing and I've had nothing but problems. Anyways I = tried a few things, and just could not get XEN to work for the life of me. = I got KVM working but VGA passthrough was a pain, I could never get it to a= ccept a device, even after I blacklisted it. Eventually I got around to XEN= as it is supposed to do this better, however I could not get past the firs= t stage ... a simple minimal virtual machine. No matter what I did, no matt= er which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) would either r= eboot or lockup. I tried looking for errors in messages, kernel, xen/* but = nothing really stood out.

So my question would be what am I missing? What logs sh= ould I be looking at?

I managed to fix the small b= ugs which popped up like files being in wrong places etc. Lastly I ran this= using xm create <config> and after that it would just hang. Machine = would become unresponsive, or reboot.

Also I did look around if anyone was having these probl= ems, and found a few threads with the exact same issue, but no answers so f= ar.

I would really appreciate some help to just be able to = start the machine with nothing fancy then I could possibly take it from the= re.
Also if anyone has any good links to guides for successful se= tups compiling from source, preferably on Debian installation. Don't ge= t me wrong, I'm no Linux dummy, just would be nice to have something th= at proven to work before I start stabbing around.

I've been working on this on and off for about a we= ek, and quite frankly feel extremely defeated by it =3D_=3D

<= /div>
To help you understand what I may have done wrong I will attach s= ome information below:

System:
Motherboard: GA-970A-D3 (rev 1= .3, BIOS F10)
CPU: AMD FX 8300 @ 3.3GHz
GPU: Powercolor= ATI Radeon 5970
RAM: 16GB Corsair=C2=A0CML16GX3M2A1600C10B @ 133= 3

Setups tried:
All were done with a Win= dows 7 x86_64 guest VM

Debian 6: Standard b= ridge. Installed xen-linux-system, in-fact I followed the official guide=C2= =A0http://wiki.deb= ian.org/Xen=C2=A0and=C2=A0quite a few others.
Debian 7: same as above, found more guides etc
Above 2 would= crash and just become plain unresponsive

Ubuntu 1= 2.10: Similar, instead followed ubuntu related guides
This one wo= uld reboot the dom0

Things I tried or did do before you ask them:
- Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki documents (refere= nced these a lot).
- Made sure that svm was enabled during kernel boot (xm dmsg)
- Made sure that IOMMU was enabled during kernel boot (xm dmsg), however = this behaved a bit wierd, so i didnt use pci pass through right off the bat= . Well again I couldnt even start the vm so no point.

Things I didn't try:
- Compile XEN= kernel and dom0 kernel from source

My HVM conf= ig:
(Though I technically tried a few different combinatio= ns from different guide, including some very minimal ones)
name =3D 'xenvm1'

kernel =3D '/usr/lib/xen-4.0/boot/hvmloader'
builder =3D 'hvm'
memory =3D '34096'
shadow_memory =3D '8'
device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm'
disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ]
vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef']
boot=3D'dc'
vnc=3D1
vncviewer=3D0
sdl=3D0
vcpus=3D4
usbdevice=3D'tablet'
on_poweroff =3D 'destroy'
on_reboot =3D 'restart'
on_crash =3D 'restart'


Best Regards,
Almir kadric

____________= ___________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

_______________________________________________
Xen-users mailing listXen-users@li= sts.xen.org
http://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--089e0112c63a0d355e04d832fd86-- --===============1720837810467904045== 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 --===============1720837810467904045==-- From xen-users-bounces@lists.xen.org Mon Mar 18 13:31:05 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 13:31:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHa8o-0008Is-SA; Mon, 18 Mar 2013 13:30:18 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHa8n-0008Ig-Ps for xen-users@lists.xen.org; Mon, 18 Mar 2013 13:30:18 +0000 Received: from [85.158.143.99:64251] by server-2.bemta-4.messagelabs.com id 60/BA-12656-9E617415; Mon, 18 Mar 2013 13:30:17 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1363613412!26800412!1 X-Originating-IP: [209.85.128.172] X-SpamReason: No, hits=1.4 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5032 invoked from network); 18 Mar 2013 13:30:14 -0000 Received: from mail-ve0-f172.google.com (HELO mail-ve0-f172.google.com) (209.85.128.172) by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 13:30:14 -0000 Received: by mail-ve0-f172.google.com with SMTP id cz11so4321345veb.31 for ; Mon, 18 Mar 2013 06:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=i3zDyv+watOMUwKyoXtp6/Ajxv7gGe6DG6adD+NdymQ=; b=xRMnTmWsXRvz2iEXGvybxr5HPn2MGe9LiVgPbBKSrpIxixHn1kUhZhzmOBuHrixnME kRKK7U62IIVfz9RORFxrnVC2YclE3t4c6vRhR+7hXutoDXF42VA8tyVWRvS6vsKGRCgL jndXAnmc1MHjONsfHgQ6/f3V4goq4pAHJ7K9Ecv6qMx/9eEI5e8lY9EwJNZ13G+Pv82x SUUr+5Yu4pYjWGyquvW4clSwss/SAu/92/TOqAnzK6g2Q4bzWF/NQd2V4kwd3PDUtYWD KdFVQz445HSy0B34BmasAYAo4Q7kC8nRnO1uDY6xs2CEUpPeMxQ4UaC+z4/qmlnks6qe 3hQQ== MIME-Version: 1.0 X-Received: by 10.58.50.7 with SMTP id y7mr20073747ven.24.1363613412288; Mon, 18 Mar 2013 06:30:12 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Mon, 18 Mar 2013 06:30:12 -0700 (PDT) In-Reply-To: References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> Date: Mon, 18 Mar 2013 09:30:12 -0400 Message-ID: From: Casey DeLorme To: Andreas Falck Cc: Almir Kadric , "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============1720837810467904045==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1720837810467904045== Content-Type: multipart/alternative; boundary=089e0112c63a0d355e04d832fd86 --089e0112c63a0d355e04d832fd86 Content-Type: text/plain; charset=UTF-8 Hi Almir, I don't have much to offer by way of suggestions for packaged Xen and the xm toolstack, but I wrote a (slightly dated) guide for Debian Wheezybuilding Xen from source, which should hold mostly accurate for Xen 4.2 stable with minor changes. Primary benefit is it is comprehensive, starts with installing Debian and works all the way to running a Windows 7 HVM (DomU), complete with videos. Following that guides instructions minus the EFI Source Modification (which has been patched and only applies) and using Xen 4.2.1 stable (revision 25950 I believe) should take approx. 2~ hours to complete, substantially longer to understand all the details. I intend to update the guide when Debian Wheezy releases as stable. In March last year I was in your shoes, just getting my feet wet with Xen and after a month of failed package tests I went with building from source. If it makes you feel any better about your week, it took me half a year to get things sorted out. Hope this helps, ~Casey On Mon, Mar 18, 2013 at 6:16 AM, Andreas Falck < falck.andreas.lists@gmail.com> wrote: > Hi Almir, > > Sorry, I have no good advice on which logs to watch. It is possible that > if the dom0 kernel ever gets time to ouput something, it will do it to the > console. > > One piece of information that might be useful for further debugging is > whether the error occurs when the VM kernel boots or already when the HVM > bios boots. You can try this by starting a HVM vm without any virtual disk, > thus booting only the HVM bios. Also, it would probably be of interest to > know if a PV guest works (you can probably do this easily by starting only > a PV kernel, no need to install a full PV system). However, I am not sure > on what to do with that information, but someone else might have a clue. > > > Regards, > Andreas > > 2013/3/18 Almir Kadric > >> Hi, Andreas, >> >> Thanks for your quick response ^_^ >> >> Sounds like you have been testing extensively. If I get you right, dom0 >> freezes or reboots when you try to start the VM, but works otherwise? >> >> To say the least yes I have, a lot of sleep lost over this. orz >> >> If I get you right, dom0 freezes or reboots when you try to start the VM, >> but works otherwise? >> >> That's correct, dom0 works perfectly fine, right up until I start a domU. >> Regardless of what's in that domU. >> >> I assume you have tried with IOMMU disabled in bios too? >> >> Hmmm I can't quite remember, it's quite a blur after a week of sleepless >> nights. I'll give it another whirl and see what happens. >> >> Also, I assume that >> >> memory = '34096' >> >> Yes sorry typo, I pulled that up quickly from a site I borrowed that >> config from, was changing it to "4096" >> >> >> Any recommendations for logging to watch? Generally I tail -f a log on my >> screen and then ssh in to execute xm create. But the logs just die, hoping >> to find that right one which just shows the error before a freeze. >> >> >> Best Regards, >> Almir kadric >> >> Website: www.almirkadric.com >> Mobile: +81 90 8008 1578**** >> Office: +81 03 4550 1448 >> Email: almir@kadric.com >> >> On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote: >> >> Hi, >> >> Sounds like you have been testing extensively. If I get you right, dom0 >> freezes or reboots when you try to start the VM, but works otherwise? >> >> I assume you have tried with IOMMU disabled in bios too? In case of a >> buggy bios, turning IOMMU off could possibly make a difference (in order to >> find the problem, I realize that you plan to use IOMMU). >> >> Also, I assume that >> >> memory = '34096' >> >> >> Is a typo? Since you say that you have tried different vm configs. >> >> Regards, >> Andreas >> >> >> 2013/3/18 Almir Kadric >> >>> Hi all, >>> >>> I'm coming from a lxc background and recently found a real need for a >>> full virtualised windows solution. In the past I have stuck it out with >>> Linux, but Wine just hasn't been performing and I've had nothing but >>> problems. Anyways I tried a few things, and just could not get XEN to work >>> for the life of me. I got KVM working but VGA passthrough was a pain, I >>> could never get it to accept a device, even after I blacklisted it. >>> Eventually I got around to XEN as it is supposed to do this better, however >>> I could not get past the first stage ... a simple minimal virtual machine. >>> No matter what I did, no matter which distro (Debian 6,7 and Ubuntu 12.10) >>> my Host (dom0) would either reboot or lockup. I tried looking for errors in >>> messages, kernel, xen/* but nothing really stood out. >>> >>> So my question would be what am I missing? What logs should I be looking >>> at? >>> >>> I managed to fix the small bugs which popped up like files being in >>> wrong places etc. Lastly I ran this using xm create and after that >>> it would just hang. Machine would become unresponsive, or reboot. >>> >>> Also I did look around if anyone was having these problems, and found a >>> few threads with the exact same issue, but no answers so far. >>> http://lists.debian.org/debian-user/2011/12/msg01779.html >>> >>> http://xen.markmail.org/search/?q=GA-970A#query:GA-970A+page:1+mid:fwgjnzmfy4pylgiu+state:results >>> >>> I would really appreciate some help to just be able to start the machine >>> with nothing fancy then I could possibly take it from there. >>> Also if anyone has any good links to guides for successful setups >>> compiling from source, preferably on Debian installation. Don't get me >>> wrong, I'm no Linux dummy, just would be nice to have something that proven >>> to work before I start stabbing around. >>> >>> I've been working on this on and off for about a week, and quite frankly >>> feel extremely defeated by it =_= >>> >>> To help you understand what I may have done wrong I will attach some >>> information below: >>> >>> *System:* >>> Motherboard: GA-970A-D3 (rev 1.3, BIOS F10) >>> CPU: AMD FX 8300 @ 3.3GHz >>> GPU: Powercolor ATI Radeon 5970 >>> RAM: 16GB Corsair CML16GX3M2A1600C10B @ 1333 >>> >>> *Setups tried:* >>> All were done with a Windows 7 x86_64 guest VM >>> * >>> * >>> Debian 6: Standard bridge. Installed xen-linux-system, in-fact I >>> followed the official guide http://wiki.debian.org/Xen and quite a few >>> others. >>> Debian 7: same as above, found more guides etc >>> Above 2 would crash and just become plain unresponsive >>> >>> Ubuntu 12.10: Similar, instead followed ubuntu related guides >>> This one would reboot the dom0 >>> >>> *Things I tried or did do before you ask them:* >>> - Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x) >>> - Enabled IOMMU via kernel options as per XEN wiki documents (referenced >>> these a lot). >>> - Made sure that svm was enabled during kernel boot (xm dmsg) >>> - Made sure that IOMMU was enabled during kernel boot (xm dmsg), however >>> this behaved a bit wierd, so i didnt use pci pass through right off the >>> bat. Well again I couldnt even start the vm so no point. >>> >>> *Things I didn't try:* >>> - Compile XEN kernel and dom0 kernel from source >>> >>> *My HVM config:* >>> *(Though I technically tried a few different combinations from >>> different guide, including some very minimal ones)* >>> >>> name = 'xenvm1' >>> >>> kernel = '/usr/lib/xen-4.0/boot/hvmloader' >>> builder = 'hvm' >>> memory = '34096' >>> shadow_memory = '8' >>> device_model='/usr/lib/xen-4.0/bin/qemu-dm' >>> disk = [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ] >>> vif = ['bridge=br0, mac=01:23:de:ad:be:ef'] >>> boot='dc' >>> vnc=1 >>> vncviewer=0 >>> sdl=0 >>> vcpus=4 >>> usbdevice='tablet' >>> on_poweroff = 'destroy' >>> on_reboot = 'restart' >>> on_crash = 'restart' >>> >>> >>> >>> Best Regards, >>> Almir kadric >>> >>> _______________________________________________ >>> 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 >> >> >> > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --089e0112c63a0d355e04d832fd86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Almir,


Following that guides instructions minus the EFI Source= Modification (which has been patched and only applies) and using Xen 4.2.1= stable (revision 25950 I believe) should take approx. 2~ hours to complete= , substantially longer to understand all the details.

I intend to update the guide when Debian Wheezy release= s as stable. =C2=A0In March last year I was in your shoes, just getting my = feet wet with Xen and after a month of failed package tests I went with bui= lding from source. =C2=A0If it makes you feel any better about your week, i= t took me half a year to get things sorted out.

Hope this helps,

~Casey


On Mon, Mar 18, 2013 at 6:16 AM, Andreas Falck = <falc= k.andreas.lists@gmail.com> wrote:
Hi Almir,

Sorry, I have no good advic= e on which logs to watch. It is possible that if the dom0 kernel ever gets = time to ouput something, it will do it to the console.

One piece of information that might be useful for further debugging is = whether the error occurs when the VM kernel boots or already when the HVM b= ios boots. You can try this by starting a HVM vm without any virtual disk, = thus booting only the HVM bios. Also, it would probably be of interest to k= now if a PV guest works (you can probably do this easily by starting only a= PV kernel, no need to install a full PV system). However, I am not sure on= what to do with that information, but someone else might have a clue.


Regards,
Andreas

2013/3/18 Almir K= adric <almir@kadric.com>
Hi, Andreas,

<= div>Thanks for your quick response ^_^

Sounds like you have been testing extensively. If I get you right= , dom0 freezes or reboots when you try to start the VM, but works otherwise= ?
To say the least yes I have, a lot of sleep lost over this. =C2=A0orz=

If I get you right= , dom0 freezes or reboots when you try to start the VM, but works otherwise= ?
That's correct, dom0 works perfectly fine, right up until I start= a domU. Regardless of what's in that domU.

I assume you have tried with IOMMU disabled in= bios too?
Hmmm I can't quite remember, it's quite a blur after a week o= f sleepless nights. I'll give it another whirl and see what happens.

Also, I assume that= =C2=A0

memory =3D '34096'
Yes sorry typo, I p= ulled that up quickly from a site I borrowed that config from, was changing= it to "4096"


Any r= ecommendations for logging to watch? Generally I tail -f a log on my screen= and then ssh in to execute xm create. But the logs just die, hoping to fin= d that right one which just shows the error before a freeze.


Best Regards,
Almir kadric

Website: www.almirkadric.com
Mobile:=C2=A0= =C2=A0=C2=A0=C2=A0 +81 90 8008 1578
Office:=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +81 03 4550 1448
Email: almir@kadric.com

On Mar 18, 2013, at 5:59 PM, Andreas Falck wrote:

Hi,

Sounds like you have been testing extens= ively. If I get you right, dom0 freezes or reboots when you try to start th= e VM, but works otherwise?

I assume you have tried with IOMMU disabled in bios too? In case of a b= uggy bios, turning IOMMU off could possibly make a difference (in order to = find the problem, I realize that you plan to use IOMMU).

Also, I assume that 

memory =3D '34096'

Is a typo? Since you say that you h= ave tried different vm configs.

Regards,
Andreas


2013/= 3/18 Almir Kadric <almir@kadric.com>
Hi all,

I'm coming fro= m a lxc background and recently found a real need for a full virtualised wi= ndows solution. In the past I have stuck it out with Linux, but Wine just h= asn't been performing and I've had nothing but problems. Anyways I = tried a few things, and just could not get XEN to work for the life of me. = I got KVM working but VGA passthrough was a pain, I could never get it to a= ccept a device, even after I blacklisted it. Eventually I got around to XEN= as it is supposed to do this better, however I could not get past the firs= t stage ... a simple minimal virtual machine. No matter what I did, no matt= er which distro (Debian 6,7 and Ubuntu 12.10) my Host (dom0) would either r= eboot or lockup. I tried looking for errors in messages, kernel, xen/* but = nothing really stood out.

So my question would be what am I missing? What logs sh= ould I be looking at?

I managed to fix the small b= ugs which popped up like files being in wrong places etc. Lastly I ran this= using xm create <config> and after that it would just hang. Machine = would become unresponsive, or reboot.

Also I did look around if anyone was having these probl= ems, and found a few threads with the exact same issue, but no answers so f= ar.

I would really appreciate some help to just be able to = start the machine with nothing fancy then I could possibly take it from the= re.
Also if anyone has any good links to guides for successful se= tups compiling from source, preferably on Debian installation. Don't ge= t me wrong, I'm no Linux dummy, just would be nice to have something th= at proven to work before I start stabbing around.

I've been working on this on and off for about a we= ek, and quite frankly feel extremely defeated by it =3D_=3D

<= /div>
To help you understand what I may have done wrong I will attach s= ome information below:

System:
Motherboard: GA-970A-D3 (rev 1= .3, BIOS F10)
CPU: AMD FX 8300 @ 3.3GHz
GPU: Powercolor= ATI Radeon 5970
RAM: 16GB Corsair=C2=A0CML16GX3M2A1600C10B @ 133= 3

Setups tried:
All were done with a Win= dows 7 x86_64 guest VM

Debian 6: Standard b= ridge. Installed xen-linux-system, in-fact I followed the official guide=C2= =A0http://wiki.deb= ian.org/Xen=C2=A0and=C2=A0quite a few others.
Debian 7: same as above, found more guides etc
Above 2 would= crash and just become plain unresponsive

Ubuntu 1= 2.10: Similar, instead followed ubuntu related guides
This one wo= uld reboot the dom0

Things I tried or did do before you ask them:
- Yes I booted into the XEN kernel (Linux x.y.z with XEN 4.0.x)
- Enabled IOMMU via kernel options as per XEN wiki documents (refere= nced these a lot).
- Made sure that svm was enabled during kernel boot (xm dmsg)
- Made sure that IOMMU was enabled during kernel boot (xm dmsg), however = this behaved a bit wierd, so i didnt use pci pass through right off the bat= . Well again I couldnt even start the vm so no point.

Things I didn't try:
- Compile XEN= kernel and dom0 kernel from source

My HVM conf= ig:
(Though I technically tried a few different combinatio= ns from different guide, including some very minimal ones)
name =3D 'xenvm1'

kernel =3D '/usr/lib/xen-4.0/boot/hvmloader'
builder =3D 'hvm'
memory =3D '34096'
shadow_memory =3D '8'
device_model=3D'/usr/lib/xen-4.0/bin/qemu-dm'
disk =3D [ 'phy:RAID10_LVM/Windows_7_Ultimate.x86_64,hda,w' ]
vif =3D ['bridge=3Dbr0, mac=3D01:23:de:ad:be:ef']
boot=3D'dc'
vnc=3D1
vncviewer=3D0
sdl=3D0
vcpus=3D4
usbdevice=3D'tablet'
on_poweroff =3D 'destroy'
on_reboot =3D 'restart'
on_crash =3D 'restart'


Best Regards,
Almir kadric

____________= ___________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

_______________________________________________
Xen-users mailing listXen-users@li= sts.xen.org
http://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--089e0112c63a0d355e04d832fd86-- --===============1720837810467904045== 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 --===============1720837810467904045==-- From xen-users-bounces@lists.xen.org Mon Mar 18 17:26:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 17:26: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 1UHdoY-0007lA-NR; Mon, 18 Mar 2013 17:25:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHdoX-0007kv-Kl; Mon, 18 Mar 2013 17:25:37 +0000 Received: from [85.158.139.83:60800] by server-9.bemta-5.messagelabs.com id 64/3C-08547-E0E47415; Mon, 18 Mar 2013 17:25:34 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1363627531!27394218!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30957 invoked from network); 18 Mar 2013 17:25:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 17:25:33 -0000 X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="13218763" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 18 Mar 2013 17:25:31 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.3; Mon, 18 Mar 2013 13:25:30 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UHdoQ-0005oY-DH; Mon, 18 Mar 2013 17:25:30 +0000 Date: Mon, 18 Mar 2013 17:25:27 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Katerina Mparmpopoulou In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Ian Jackson , xen-users@lists.xensource.com, Stefano Stabellini Subject: Re: [Xen-users] XEN 4.2 - xl migration -s X-BeenThere: xen-users@lists.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 Katerina, In general I would recommend to send these questions to xen-users or xen-devel (CC'ed), where other people can help you and benefit from the answers. Ian Jackson (also CC'ed) wrote this feature and I am hoping he can better explain how it's supposed to work. Cheers, Stefano On Wed, 13 Mar 2013, Katerina Mparmpopoulou wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Stefano, > > I found your mail from a thread relative to Xen Migration. I read that > you have written the xl man page, so probably you are the one that you > may know how can i use the -s option in the xl migrate command. > > This I want to do is to disable ssh during migration. I though that > the correct option for changing the default shh was the -s one. > > Firstly, I read the manual page of xl and i placed the > option -s empty considering that this will run , instead of ssh > . > > I 've used the command with the following alternatives: > > - - sudo xl migrate VM3 root@ip -s > > - - sudo xl migrate VM3 root@ip -s '' > > > the problem is that during migration time I'm running tcpdump > (filtering the particular interface/port 22/and the target host) and i > can see the ssh packets, even the -s option is empty (no parameters). > > I would be grateful if you could help me :) > > Thanks, Katerina > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRQHFRAAoJEIrShLVVnSKrmNgH/2ECT8JYp96QMuikbKnem0AE > ZwPyrjzcrok3FpZl7uwb4iKjAvIiO9sqZAvoxBRX9L1riNpbsMWNPzCNncCqJ5fy > c6eMSsMNFDGaNhbod7xuKQswggRa53eaSNXJki+VPTJGoieW+VV3VZU4k7Ky2mjq > No5E9VYo2vn92vi2r7ntDTF9keeHxRs/zNvUXc3K+F0O9sLF28BW37cWygblsh61 > 8ifQzIcfqSYNIxf8ok/PdEINqEAZ6Ka2/d8mFe8fYGB/qOW9a+FA+Wo/m2MIDbwu > ov7PqhJAAw8adilqcRu8kEKirhnJxtpkS0S1ysGdSbWdy1ZO4R2EaKurxWHyKlk= > =B5dY > -----END PGP SIGNATURE----- > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 17:26:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 17:26: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 1UHdoY-0007lA-NR; Mon, 18 Mar 2013 17:25:38 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHdoX-0007kv-Kl; Mon, 18 Mar 2013 17:25:37 +0000 Received: from [85.158.139.83:60800] by server-9.bemta-5.messagelabs.com id 64/3C-08547-E0E47415; Mon, 18 Mar 2013 17:25:34 +0000 X-Env-Sender: Stefano.Stabellini@eu.citrix.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1363627531!27394218!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30957 invoked from network); 18 Mar 2013 17:25:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 17:25:33 -0000 X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="13218763" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 18 Mar 2013 17:25:31 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.3; Mon, 18 Mar 2013 13:25:30 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UHdoQ-0005oY-DH; Mon, 18 Mar 2013 17:25:30 +0000 Date: Mon, 18 Mar 2013 17:25:27 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Katerina Mparmpopoulou In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Cc: xen-devel@lists.xensource.com, Ian Jackson , xen-users@lists.xensource.com, Stefano Stabellini Subject: Re: [Xen-users] XEN 4.2 - xl migration -s X-BeenThere: xen-users@lists.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 Katerina, In general I would recommend to send these questions to xen-users or xen-devel (CC'ed), where other people can help you and benefit from the answers. Ian Jackson (also CC'ed) wrote this feature and I am hoping he can better explain how it's supposed to work. Cheers, Stefano On Wed, 13 Mar 2013, Katerina Mparmpopoulou wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Stefano, > > I found your mail from a thread relative to Xen Migration. I read that > you have written the xl man page, so probably you are the one that you > may know how can i use the -s option in the xl migrate command. > > This I want to do is to disable ssh during migration. I though that > the correct option for changing the default shh was the -s one. > > Firstly, I read the manual page of xl and i placed the > option -s empty considering that this will run , instead of ssh > . > > I 've used the command with the following alternatives: > > - - sudo xl migrate VM3 root@ip -s > > - - sudo xl migrate VM3 root@ip -s '' > > > the problem is that during migration time I'm running tcpdump > (filtering the particular interface/port 22/and the target host) and i > can see the ssh packets, even the -s option is empty (no parameters). > > I would be grateful if you could help me :) > > Thanks, Katerina > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRQHFRAAoJEIrShLVVnSKrmNgH/2ECT8JYp96QMuikbKnem0AE > ZwPyrjzcrok3FpZl7uwb4iKjAvIiO9sqZAvoxBRX9L1riNpbsMWNPzCNncCqJ5fy > c6eMSsMNFDGaNhbod7xuKQswggRa53eaSNXJki+VPTJGoieW+VV3VZU4k7Ky2mjq > No5E9VYo2vn92vi2r7ntDTF9keeHxRs/zNvUXc3K+F0O9sLF28BW37cWygblsh61 > 8ifQzIcfqSYNIxf8ok/PdEINqEAZ6Ka2/d8mFe8fYGB/qOW9a+FA+Wo/m2MIDbwu > ov7PqhJAAw8adilqcRu8kEKirhnJxtpkS0S1ysGdSbWdy1ZO4R2EaKurxWHyKlk= > =B5dY > -----END PGP SIGNATURE----- > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 22:00:06 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 22:00: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 1UHi4p-0007YY-5G; Mon, 18 Mar 2013 21:58:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHi4n-0007YT-L3 for xen-users@lists.xen.org; Mon, 18 Mar 2013 21:58:41 +0000 Received: from [193.109.254.147:54074] by server-12.bemta-14.messagelabs.com id F3/24-05449-01E87415; Mon, 18 Mar 2013 21:58:40 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1363643918!8565615!1 X-Originating-IP: [209.85.223.181] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18139 invoked from network); 18 Mar 2013 21:58:39 -0000 Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com) (209.85.223.181) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 21:58:39 -0000 Received: by mail-ie0-f181.google.com with SMTP id 17so7609243iea.26 for ; Mon, 18 Mar 2013 14:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=U4rjxQEHbAngRGWa3dp/dhd94pohIXusRjxNL96gU4k=; b=FzyOC+VxFkGYemAlPcUvhWc9xz8JYZuOACxdp0xGxEfP93P3M6+wHl7hn036DI1+Wi rqUKud9MfF+loxHN6cK9Za0vXKWSdUj7mnZZaChUjLn7uMkbedEXom1QUhAfmQFxxyES 4nEHV7PAlOQ8yj6HWzo9vV7Ucw9BrjhipmQ3I1Vr7rKew8khFDEbRPcLY0/JBkGTJoWT ohN/KdgC/oYSeowfxBiIZ0fZox0FIcwLCZjMlmvWegWEDM+GWuDauBTiEAwm0zBeytrV +PuMW0X5UmMCTmycOHmHwWSCy+4LOx4b1DjIwu0CVCVqgjtxWx0EjQz2PG8f5eSgavxu 4bxA== MIME-Version: 1.0 X-Received: by 10.50.202.6 with SMTP id ke6mr319269igc.30.1363643917902; Mon, 18 Mar 2013 14:58:37 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 14:58:37 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 14:58:37 -0700 (PDT) Date: Mon, 18 Mar 2013 15:58:37 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] A10 or A8 with 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: multipart/mixed; boundary="===============7434972404986268919==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7434972404986268919== Content-Type: multipart/alternative; boundary=f46d0447a29153ae4404d83a17f7 --f46d0447a29153ae4404d83a17f7 Content-Type: text/plain; charset=ISO-8859-1 I wonder if anyone had been able to run xen on laptop with A8 or A10 and pass the video card. Or if someone can recommend laptop that can run xen and can pass video card --f46d0447a29153ae4404d83a17f7 Content-Type: text/html; charset=ISO-8859-1

I wonder if anyone had been able to run xen on laptop with A8 or A10 and pass the video card. Or if someone can recommend laptop that can run xen and can pass video card

--f46d0447a29153ae4404d83a17f7-- --===============7434972404986268919== 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 --===============7434972404986268919==-- From xen-users-bounces@lists.xen.org Mon Mar 18 22:00:06 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 22:00: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 1UHi4p-0007YY-5G; Mon, 18 Mar 2013 21:58:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHi4n-0007YT-L3 for xen-users@lists.xen.org; Mon, 18 Mar 2013 21:58:41 +0000 Received: from [193.109.254.147:54074] by server-12.bemta-14.messagelabs.com id F3/24-05449-01E87415; Mon, 18 Mar 2013 21:58:40 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1363643918!8565615!1 X-Originating-IP: [209.85.223.181] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18139 invoked from network); 18 Mar 2013 21:58:39 -0000 Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com) (209.85.223.181) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 18 Mar 2013 21:58:39 -0000 Received: by mail-ie0-f181.google.com with SMTP id 17so7609243iea.26 for ; Mon, 18 Mar 2013 14:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=U4rjxQEHbAngRGWa3dp/dhd94pohIXusRjxNL96gU4k=; b=FzyOC+VxFkGYemAlPcUvhWc9xz8JYZuOACxdp0xGxEfP93P3M6+wHl7hn036DI1+Wi rqUKud9MfF+loxHN6cK9Za0vXKWSdUj7mnZZaChUjLn7uMkbedEXom1QUhAfmQFxxyES 4nEHV7PAlOQ8yj6HWzo9vV7Ucw9BrjhipmQ3I1Vr7rKew8khFDEbRPcLY0/JBkGTJoWT ohN/KdgC/oYSeowfxBiIZ0fZox0FIcwLCZjMlmvWegWEDM+GWuDauBTiEAwm0zBeytrV +PuMW0X5UmMCTmycOHmHwWSCy+4LOx4b1DjIwu0CVCVqgjtxWx0EjQz2PG8f5eSgavxu 4bxA== MIME-Version: 1.0 X-Received: by 10.50.202.6 with SMTP id ke6mr319269igc.30.1363643917902; Mon, 18 Mar 2013 14:58:37 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 14:58:37 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 14:58:37 -0700 (PDT) Date: Mon, 18 Mar 2013 15:58:37 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] A10 or A8 with 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: multipart/mixed; boundary="===============7434972404986268919==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7434972404986268919== Content-Type: multipart/alternative; boundary=f46d0447a29153ae4404d83a17f7 --f46d0447a29153ae4404d83a17f7 Content-Type: text/plain; charset=ISO-8859-1 I wonder if anyone had been able to run xen on laptop with A8 or A10 and pass the video card. Or if someone can recommend laptop that can run xen and can pass video card --f46d0447a29153ae4404d83a17f7 Content-Type: text/html; charset=ISO-8859-1

I wonder if anyone had been able to run xen on laptop with A8 or A10 and pass the video card. Or if someone can recommend laptop that can run xen and can pass video card

--f46d0447a29153ae4404d83a17f7-- --===============7434972404986268919== 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 --===============7434972404986268919==-- From xen-users-bounces@lists.xen.org Mon Mar 18 23:23:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 23:23: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 1UHjNi-0001OR-Gf; Mon, 18 Mar 2013 23:22:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHgmV-0005hU-6l for xen-users@lists.xen.org; Mon, 18 Mar 2013 20:35:43 +0000 Received: from [85.158.138.51:33493] by server-11.bemta-3.messagelabs.com id 60/B5-01263-E9A77415; Mon, 18 Mar 2013 20:35:42 +0000 X-Env-Sender: john@clustered.net X-Msg-Ref: server-14.tower-174.messagelabs.com!1363638941!21831624!1 X-Originating-IP: [193.227.111.2] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1584 invoked from network); 18 Mar 2013 20:35:41 -0000 Received: from mail1.clustered.net (HELO clients.clustered.net) (193.227.111.2) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2013 20:35:41 -0000 Received: from [10.1.254.2] by clients.clustered.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1UHgmS-0004o6-Jm for xen-users@lists.xen.org; Mon, 18 Mar 2013 20:35:40 +0000 From: John Morrison Message-Id: Date: Mon, 18 Mar 2013 20:35:40 +0000 To: xen-users@lists.xen.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Mon, 18 Mar 2013 23:22:17 +0000 Subject: [Xen-users] Disk iops performance scalability X-BeenThere: xen-users@lists.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, Seeing a drop-off in iops when more vcpu's are added:- 3.8.2 kernel/xen-4.2.1/single domU/LVM backend/8GB RAM domU/2GB RAM dom0 dom0_max_vcpus=2 dom0_vcpus_pin domU 8 cores fio result 145k iops domU 10 cores fio result 99k iops domU 12 cores fio result 89k iops domU 14 cores fio result 81k iops ioping . -c 3 4096 bytes from . (ext4 /dev/xvda1): request=1 time=0.1 ms 4096 bytes from . (ext4 /dev/xvda1): request=2 time=0.7 ms 4096 bytes from . (ext4 /dev/xvda1): request=3 time=0.8 ms --- . (ext4 /dev/xvda1) ioping statistics --- 3 requests completed in 2002.0 ms, 1836 iops, 7.2 mb/s min/avg/max/mdev = 0.1/0.5/0.8/0.3 ms The initial ioping response is good, then a lot of latency with later ones. Any ideas ? Thanks John _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 18 23:23:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 18 Mar 2013 23:23: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 1UHjNi-0001OR-Gf; Mon, 18 Mar 2013 23:22:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHgmV-0005hU-6l for xen-users@lists.xen.org; Mon, 18 Mar 2013 20:35:43 +0000 Received: from [85.158.138.51:33493] by server-11.bemta-3.messagelabs.com id 60/B5-01263-E9A77415; Mon, 18 Mar 2013 20:35:42 +0000 X-Env-Sender: john@clustered.net X-Msg-Ref: server-14.tower-174.messagelabs.com!1363638941!21831624!1 X-Originating-IP: [193.227.111.2] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1584 invoked from network); 18 Mar 2013 20:35:41 -0000 Received: from mail1.clustered.net (HELO clients.clustered.net) (193.227.111.2) by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2013 20:35:41 -0000 Received: from [10.1.254.2] by clients.clustered.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1UHgmS-0004o6-Jm for xen-users@lists.xen.org; Mon, 18 Mar 2013 20:35:40 +0000 From: John Morrison Message-Id: Date: Mon, 18 Mar 2013 20:35:40 +0000 To: xen-users@lists.xen.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Mon, 18 Mar 2013 23:22:17 +0000 Subject: [Xen-users] Disk iops performance scalability X-BeenThere: xen-users@lists.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, Seeing a drop-off in iops when more vcpu's are added:- 3.8.2 kernel/xen-4.2.1/single domU/LVM backend/8GB RAM domU/2GB RAM dom0 dom0_max_vcpus=2 dom0_vcpus_pin domU 8 cores fio result 145k iops domU 10 cores fio result 99k iops domU 12 cores fio result 89k iops domU 14 cores fio result 81k iops ioping . -c 3 4096 bytes from . (ext4 /dev/xvda1): request=1 time=0.1 ms 4096 bytes from . (ext4 /dev/xvda1): request=2 time=0.7 ms 4096 bytes from . (ext4 /dev/xvda1): request=3 time=0.8 ms --- . (ext4 /dev/xvda1) ioping statistics --- 3 requests completed in 2002.0 ms, 1836 iops, 7.2 mb/s min/avg/max/mdev = 0.1/0.5/0.8/0.3 ms The initial ioping response is good, then a lot of latency with later ones. Any ideas ? Thanks John _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 00:04:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 00:04: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 1UHk20-0003D9-0n; Tue, 19 Mar 2013 00:03:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHk1y-0003D4-1I for xen-users@lists.xen.org; Tue, 19 Mar 2013 00:03:54 +0000 Received: from [85.158.137.99:16882] by server-7.bemta-3.messagelabs.com id 26/B0-06591-96BA7415; Tue, 19 Mar 2013 00:03:53 +0000 X-Env-Sender: murrayie@yahoo.co.uk X-Msg-Ref: server-4.tower-217.messagelabs.com!1363651432!17251410!1 X-Originating-IP: [77.238.189.218] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5950 invoked from network); 19 Mar 2013 00:03:52 -0000 Received: from nm11-vm0.bullet.mail.ird.yahoo.com (HELO nm11-vm0.bullet.mail.ird.yahoo.com) (77.238.189.218) by server-4.tower-217.messagelabs.com with SMTP; 19 Mar 2013 00:03:52 -0000 Received: from [77.238.189.55] by nm11.bullet.mail.ird.yahoo.com with NNFMP; 19 Mar 2013 00:03:52 -0000 Received: from [46.228.39.107] by tm8.bullet.mail.ird.yahoo.com with NNFMP; 19 Mar 2013 00:03:52 -0000 Received: from [127.0.0.1] by smtp144.mail.ir2.yahoo.com with NNFMP; 19 Mar 2013 00:03:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1363651432; bh=ZJU+IIsI5VTT5li7QOpPGjo+x/9Jq0w0JczRrP1VxEo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=r7dclgLHAGyL6fKbn5XUPW1z4toJMkaxG8G36a4WWlPMJGfhIWKKg1o9spr/ZIs6coR3Vfu+NHJgY3HcoXAJXtAjfj24ywn17SpTxEXRiQaaPceRaUWpgzNywpf+2RU+wat5RXVDtgpkOKuW0eg7q1Oha2RxedjbgbWXbtKfVpE= X-Yahoo-Newman-Id: 209343.71769.bm@smtp144.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: G_fxwVEVM1n1ExWlyvqw5lcbPmlwB9Ge6C6qZs_J8MKuysQ EXAEX.fj6stUR1VeX0bdoB88I29Ck5dC0Cppy07ddk1FzBQLyJbuhj3zSlBV 2uzZaRmRSGyB7N4RULMU3u5d3HwxIZKAgxDsM3mflByDWU9CvcLHgMxWayoC ZwT2yjgznL9AM14sJCwOv4OXb8LPK7MtN_sMc1yEZEYBNoEdbqCGzRZF8T8z eU0TyisZpC2seDy2qp_zqwIr_HWb3Sr.xLFjCGN2CKCFphQXXgGgl3wfweXm dhewphi6uF9xscHaKmovdWNvmaI7Ufk2wLOdqzh8f51u448QaZ9mj0uNWQV8 mh.Tcn6HIUMrpjXt4NoujHRUd860VZPx0wkw9FDssaWdaKtS6rmKzynmMiP_ DXKTnmqXpvGEZ0DSf8ot3_rGzEFHT_lw5RDbIXlf4Y4Fuk4mosRo- X-Yahoo-SMTP: P.LfrmaswBDlKN6tCvtOaEZlSVsY X-Rocket-Received: from [192.168.1.136] (murrayie@81.132.197.225 with plain) by smtp144.mail.ir2.yahoo.com with SMTP; 19 Mar 2013 00:03:52 +0000 UTC Message-ID: <5147AB67.9050705@yahoo.co.uk> Date: Tue, 19 Mar 2013 00:03:51 +0000 From: Ian User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> In-Reply-To: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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 > *Things I didn't try:* > - Compile XEN kernel and dom0 kernel from source > I had a pretty frustrating time using various pre-built Xen dom0 stuff until I started compiling from source. I have Xen 4.2.1 working on a Dom0 12.04 server. Never tried IOMMU, however. I had similar problems to you (reboots, etc) using a compiled-from-source 3.8.0 kernel so I reverted back to 3.4.0 which was fine apart from being out of date. This was on a Scientific Linux box. I need to revisit that at some point. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 00:04:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 00:04: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 1UHk20-0003D9-0n; Tue, 19 Mar 2013 00:03:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHk1y-0003D4-1I for xen-users@lists.xen.org; Tue, 19 Mar 2013 00:03:54 +0000 Received: from [85.158.137.99:16882] by server-7.bemta-3.messagelabs.com id 26/B0-06591-96BA7415; Tue, 19 Mar 2013 00:03:53 +0000 X-Env-Sender: murrayie@yahoo.co.uk X-Msg-Ref: server-4.tower-217.messagelabs.com!1363651432!17251410!1 X-Originating-IP: [77.238.189.218] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5950 invoked from network); 19 Mar 2013 00:03:52 -0000 Received: from nm11-vm0.bullet.mail.ird.yahoo.com (HELO nm11-vm0.bullet.mail.ird.yahoo.com) (77.238.189.218) by server-4.tower-217.messagelabs.com with SMTP; 19 Mar 2013 00:03:52 -0000 Received: from [77.238.189.55] by nm11.bullet.mail.ird.yahoo.com with NNFMP; 19 Mar 2013 00:03:52 -0000 Received: from [46.228.39.107] by tm8.bullet.mail.ird.yahoo.com with NNFMP; 19 Mar 2013 00:03:52 -0000 Received: from [127.0.0.1] by smtp144.mail.ir2.yahoo.com with NNFMP; 19 Mar 2013 00:03:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1363651432; bh=ZJU+IIsI5VTT5li7QOpPGjo+x/9Jq0w0JczRrP1VxEo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=r7dclgLHAGyL6fKbn5XUPW1z4toJMkaxG8G36a4WWlPMJGfhIWKKg1o9spr/ZIs6coR3Vfu+NHJgY3HcoXAJXtAjfj24ywn17SpTxEXRiQaaPceRaUWpgzNywpf+2RU+wat5RXVDtgpkOKuW0eg7q1Oha2RxedjbgbWXbtKfVpE= X-Yahoo-Newman-Id: 209343.71769.bm@smtp144.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: G_fxwVEVM1n1ExWlyvqw5lcbPmlwB9Ge6C6qZs_J8MKuysQ EXAEX.fj6stUR1VeX0bdoB88I29Ck5dC0Cppy07ddk1FzBQLyJbuhj3zSlBV 2uzZaRmRSGyB7N4RULMU3u5d3HwxIZKAgxDsM3mflByDWU9CvcLHgMxWayoC ZwT2yjgznL9AM14sJCwOv4OXb8LPK7MtN_sMc1yEZEYBNoEdbqCGzRZF8T8z eU0TyisZpC2seDy2qp_zqwIr_HWb3Sr.xLFjCGN2CKCFphQXXgGgl3wfweXm dhewphi6uF9xscHaKmovdWNvmaI7Ufk2wLOdqzh8f51u448QaZ9mj0uNWQV8 mh.Tcn6HIUMrpjXt4NoujHRUd860VZPx0wkw9FDssaWdaKtS6rmKzynmMiP_ DXKTnmqXpvGEZ0DSf8ot3_rGzEFHT_lw5RDbIXlf4Y4Fuk4mosRo- X-Yahoo-SMTP: P.LfrmaswBDlKN6tCvtOaEZlSVsY X-Rocket-Received: from [192.168.1.136] (murrayie@81.132.197.225 with plain) by smtp144.mail.ir2.yahoo.com with SMTP; 19 Mar 2013 00:03:52 +0000 UTC Message-ID: <5147AB67.9050705@yahoo.co.uk> Date: Tue, 19 Mar 2013 00:03:51 +0000 From: Ian User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> In-Reply-To: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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 > *Things I didn't try:* > - Compile XEN kernel and dom0 kernel from source > I had a pretty frustrating time using various pre-built Xen dom0 stuff until I started compiling from source. I have Xen 4.2.1 working on a Dom0 12.04 server. Never tried IOMMU, however. I had similar problems to you (reboots, etc) using a compiled-from-source 3.8.0 kernel so I reverted back to 3.4.0 which was fine apart from being out of date. This was on a Scientific Linux box. I need to revisit that at some point. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 00:31:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 00:31: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 1UHkR7-0004LC-L6; Tue, 19 Mar 2013 00:29:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHkR5-0004L7-IZ for xen-users@lists.xensource.com; Tue, 19 Mar 2013 00:29:51 +0000 Received: from [193.109.254.147:44255] by server-3.bemta-14.messagelabs.com id B9/23-17488-D71B7415; Tue, 19 Mar 2013 00:29:49 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1363652988!8575043!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3543 invoked from network); 19 Mar 2013 00:29:49 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 19 Mar 2013 00:29:49 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UHkR1-0005sH-E5 for xen-users@lists.xensource.com; Mon, 18 Mar 2013 17:29:47 -0700 Date: Mon, 18 Mar 2013 17:29:47 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363652987430-5714910.post@n5.nabble.com> In-Reply-To: <1363602301181-5714901.post@n5.nabble.com> References: <1363602301181-5714901.post@n5.nabble.com> MIME-Version: 1.0 Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 everybody. This is a emergency issue. can anybody reply as soon as possible? Thanks. Jing. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901p5714910.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 Tue Mar 19 00:31:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 00:31: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 1UHkR7-0004LC-L6; Tue, 19 Mar 2013 00:29:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHkR5-0004L7-IZ for xen-users@lists.xensource.com; Tue, 19 Mar 2013 00:29:51 +0000 Received: from [193.109.254.147:44255] by server-3.bemta-14.messagelabs.com id B9/23-17488-D71B7415; Tue, 19 Mar 2013 00:29:49 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1363652988!8575043!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3543 invoked from network); 19 Mar 2013 00:29:49 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 19 Mar 2013 00:29:49 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UHkR1-0005sH-E5 for xen-users@lists.xensource.com; Mon, 18 Mar 2013 17:29:47 -0700 Date: Mon, 18 Mar 2013 17:29:47 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363652987430-5714910.post@n5.nabble.com> In-Reply-To: <1363602301181-5714901.post@n5.nabble.com> References: <1363602301181-5714901.post@n5.nabble.com> MIME-Version: 1.0 Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 everybody. This is a emergency issue. can anybody reply as soon as possible? Thanks. Jing. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901p5714910.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 Tue Mar 19 00:36:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 00:36: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 1UHkWR-0004jK-Lr; Tue, 19 Mar 2013 00:35:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHkWQ-0004jE-E9 for xen-users@lists.xen.org; Tue, 19 Mar 2013 00:35:22 +0000 Received: from [85.158.138.51:22280] by server-14.bemta-3.messagelabs.com id 8C/02-27076-9C2B7415; Tue, 19 Mar 2013 00:35:21 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1363653319!20250889!1 X-Originating-IP: [193.180.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkzLjE4MC4yNTEuMzcgPT4gMjcxMTU2\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1906 invoked from network); 19 Mar 2013 00:35:20 -0000 Received: from mailgw2.ericsson.se (HELO mailgw2.ericsson.se) (193.180.251.37) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2013 00:35:20 -0000 X-AuditID: c1b4fb25-b7f366d000004d10-df-5147b2c6777a Received: from ESGSCHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D5.76.19728.6C2B7415; Tue, 19 Mar 2013 01:35:19 +0100 (CET) Received: from ESGSCMB105.ericsson.se ([169.254.5.80]) by ESGSCHC003.ericsson.se ([146.11.116.74]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 08:35:16 +0800 From: Jing Chen To: Alexandre Kouznetsov , "xen-users@lists.xen.org" Thread-Topic: [Xen-users] how to create a full-virtualization xen VM with autoyast Thread-Index: AQHOI8MuOuFDrVF8ikGDuZvZh1QAlpisKwAA Date: Tue, 19 Mar 2013 00:35:16 +0000 Message-ID: <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> References: <1363602301181-5714901.post@n5.nabble.com> In-Reply-To: <1363602301181-5714901.post@n5.nabble.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.127] MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje7xTe6BBjdvcFksu/WS3WLV1QOs DkweR3f/ZvLou7eZPYApissmJTUnsyy1SN8ugStj9vPlTAUXuSvOd8c3MG7h7GLk5JAQMJH4 taSRDcIWk7hwbz2QzcUhJHCIUaL9/kR2CGcxo8Sjs68YQarYBDQkNnX8BOsQEUiQmHJ/PwuI LSwQLHF3+SOoeIjE7UPtjBC2kcT0WQ+YQWwWAVWJ88ePgMV5Bbwlnt18CmYLCZhJfDpwH8zm FDCXuLR+PSuIzQh00fdTa5hAbGYBcYlbT+YzQVwqILFkz3lmCFtU4uXjf6wQtpLE1/5NrBD1 OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXInpuYmZNebrSJ ERgLB7f8Vt3BeOecyCFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYu//u S1bgSKt0NXq2UN51tf3GklNvn3aGqPJGaNxc8yi5TaFAn3OC2mNuaZm7he+n+DuLn0m3qNtZ 8Pem1cTNl03t+qcrmd6Z5vH8aPrFL6HH/FSFn2x5PeegAveBOzPmljy158q8/7+nXVVROH/7 hv9PEv30FdjrxSeWyzy0y14h0ZhyqVxUiaU4I9FQi7moOBEARSbFO1MCAAA= Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 Alexandre. I post a new topic in xen forum. Please see below email and link. I got the reply that Frank Zhang is out of office for long time. I am wondering if I put to the wrong place? Could you help to answer this question? Thanks very much. Jing Chen CBC/XIB/K No.5 Lize East Street, Chaoyang District 100102, Beijing, China Phone +86 10 84767586 Mobile +86 13801223973 jing.chen@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer -----Original Message----- From: xen-users-bounces@lists.xen.org [mailto:xen-users-bounces@lists.xen.org] On Behalf Of Jing Chen Sent: Monday, March 18, 2013 6:25 PM To: xen-users@lists.xensource.com Subject: [Xen-users] how to create a full-virtualization xen VM with autoyast Hi. I want to create a full-virtualization xen VM with autoyast installation. how can i do that? and how does the configuration file to be configured? I use suse linux 11 SP2. looking forward your replay. Jing. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901.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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 00:36:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 00:36: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 1UHkWR-0004jK-Lr; Tue, 19 Mar 2013 00:35:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHkWQ-0004jE-E9 for xen-users@lists.xen.org; Tue, 19 Mar 2013 00:35:22 +0000 Received: from [85.158.138.51:22280] by server-14.bemta-3.messagelabs.com id 8C/02-27076-9C2B7415; Tue, 19 Mar 2013 00:35:21 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1363653319!20250889!1 X-Originating-IP: [193.180.251.37] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkzLjE4MC4yNTEuMzcgPT4gMjcxMTU2\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1906 invoked from network); 19 Mar 2013 00:35:20 -0000 Received: from mailgw2.ericsson.se (HELO mailgw2.ericsson.se) (193.180.251.37) by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2013 00:35:20 -0000 X-AuditID: c1b4fb25-b7f366d000004d10-df-5147b2c6777a Received: from ESGSCHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D5.76.19728.6C2B7415; Tue, 19 Mar 2013 01:35:19 +0100 (CET) Received: from ESGSCMB105.ericsson.se ([169.254.5.80]) by ESGSCHC003.ericsson.se ([146.11.116.74]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 08:35:16 +0800 From: Jing Chen To: Alexandre Kouznetsov , "xen-users@lists.xen.org" Thread-Topic: [Xen-users] how to create a full-virtualization xen VM with autoyast Thread-Index: AQHOI8MuOuFDrVF8ikGDuZvZh1QAlpisKwAA Date: Tue, 19 Mar 2013 00:35:16 +0000 Message-ID: <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> References: <1363602301181-5714901.post@n5.nabble.com> In-Reply-To: <1363602301181-5714901.post@n5.nabble.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.127] MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje7xTe6BBjdvcFksu/WS3WLV1QOs DkweR3f/ZvLou7eZPYApissmJTUnsyy1SN8ugStj9vPlTAUXuSvOd8c3MG7h7GLk5JAQMJH4 taSRDcIWk7hwbz2QzcUhJHCIUaL9/kR2CGcxo8Sjs68YQarYBDQkNnX8BOsQEUiQmHJ/PwuI LSwQLHF3+SOoeIjE7UPtjBC2kcT0WQ+YQWwWAVWJ88ePgMV5Bbwlnt18CmYLCZhJfDpwH8zm FDCXuLR+PSuIzQh00fdTa5hAbGYBcYlbT+YzQVwqILFkz3lmCFtU4uXjf6wQtpLE1/5NrBD1 OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXInpuYmZNebrSJ ERgLB7f8Vt3BeOecyCFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYu//u S1bgSKt0NXq2UN51tf3GklNvn3aGqPJGaNxc8yi5TaFAn3OC2mNuaZm7he+n+DuLn0m3qNtZ 8Pem1cTNl03t+qcrmd6Z5vH8aPrFL6HH/FSFn2x5PeegAveBOzPmljy158q8/7+nXVVROH/7 hv9PEv30FdjrxSeWyzy0y14h0ZhyqVxUiaU4I9FQi7moOBEARSbFO1MCAAA= Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 Alexandre. I post a new topic in xen forum. Please see below email and link. I got the reply that Frank Zhang is out of office for long time. I am wondering if I put to the wrong place? Could you help to answer this question? Thanks very much. Jing Chen CBC/XIB/K No.5 Lize East Street, Chaoyang District 100102, Beijing, China Phone +86 10 84767586 Mobile +86 13801223973 jing.chen@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer -----Original Message----- From: xen-users-bounces@lists.xen.org [mailto:xen-users-bounces@lists.xen.org] On Behalf Of Jing Chen Sent: Monday, March 18, 2013 6:25 PM To: xen-users@lists.xensource.com Subject: [Xen-users] how to create a full-virtualization xen VM with autoyast Hi. I want to create a full-virtualization xen VM with autoyast installation. how can i do that? and how does the configuration file to be configured? I use suse linux 11 SP2. looking forward your replay. Jing. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901.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 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 01:30:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 01:30: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 1UHlN8-000296-AS; Tue, 19 Mar 2013 01:29:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHlN6-000291-Qw for xen-users@lists.xen.org; Tue, 19 Mar 2013 01:29:49 +0000 Received: from [85.158.137.99:42585] by server-9.bemta-3.messagelabs.com id 20/EE-32531-C8FB7415; Tue, 19 Mar 2013 01:29:48 +0000 X-Env-Sender: duanshuidao@hotmail.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1363656586!17655073!1 X-Originating-IP: [65.55.111.81] X-SpamReason: No, hits=0.3 required=7.0 tests=FORGED_HOTMAIL_RCVD, MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_2,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30414 invoked from network); 19 Mar 2013 01:29:47 -0000 Received: from blu0-omc2-s6.blu0.hotmail.com (HELO blu0-omc2-s6.blu0.hotmail.com) (65.55.111.81) by server-16.tower-217.messagelabs.com with SMTP; 19 Mar 2013 01:29:47 -0000 Received: from BLU405-EAS42 ([65.55.111.73]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 18:29:46 -0700 X-EIP: [mO/Q3Rb+OW44PEOZa8EF4NYBed75BMkS] X-Originating-Email: [duanshuidao@hotmail.com] Message-ID: References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> From: Jun Hu MIME-Version: 1.0 (1.0) In-Reply-To: <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> Date: Tue, 19 Mar 2013 09:29:40 +0800 To: Jing Chen X-OriginalArrivalTime: 19 Mar 2013 01:29:46.0520 (UTC) FILETIME=[3D987980:01CE2441] Cc: "xen-users@lists.xen.org" , Alexandre Kouznetsov Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 you can contact suse techinical engineer from hujun's iphone On 2013-3-19, at 8:37, "Jing Chen" wrote: > Hi Alexandre. > I post a new topic in xen forum. Please see below email and link. I got the reply that Frank Zhang is out of office for long time. I am wondering if I put to the wrong place? > > Could you help to answer this question? > > > Thanks very much. > > > Jing Chen > > CBC/XIB/K > No.5 Lize East Street, Chaoyang District > 100102, Beijing, China > Phone +86 10 84767586 > Mobile +86 13801223973 > jing.chen@ericsson.com > www.ericsson.com > > > > > This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer > > -----Original Message----- > From: xen-users-bounces@lists.xen.org [mailto:xen-users-bounces@lists.xen.org] On Behalf Of Jing Chen > Sent: Monday, March 18, 2013 6:25 PM > To: xen-users@lists.xensource.com > Subject: [Xen-users] how to create a full-virtualization xen VM with autoyast > > Hi. > I want to create a full-virtualization xen VM with autoyast installation. > how can i do that? and how does the configuration file to be configured? > > I use suse linux 11 SP2. > > > > looking forward your replay. > > > > Jing. > > > > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901.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 > > _______________________________________________ > 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 Mar 19 01:30:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 01:30: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 1UHlN8-000296-AS; Tue, 19 Mar 2013 01:29:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHlN6-000291-Qw for xen-users@lists.xen.org; Tue, 19 Mar 2013 01:29:49 +0000 Received: from [85.158.137.99:42585] by server-9.bemta-3.messagelabs.com id 20/EE-32531-C8FB7415; Tue, 19 Mar 2013 01:29:48 +0000 X-Env-Sender: duanshuidao@hotmail.com X-Msg-Ref: server-16.tower-217.messagelabs.com!1363656586!17655073!1 X-Originating-IP: [65.55.111.81] X-SpamReason: No, hits=0.3 required=7.0 tests=FORGED_HOTMAIL_RCVD, MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_2,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30414 invoked from network); 19 Mar 2013 01:29:47 -0000 Received: from blu0-omc2-s6.blu0.hotmail.com (HELO blu0-omc2-s6.blu0.hotmail.com) (65.55.111.81) by server-16.tower-217.messagelabs.com with SMTP; 19 Mar 2013 01:29:47 -0000 Received: from BLU405-EAS42 ([65.55.111.73]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 18:29:46 -0700 X-EIP: [mO/Q3Rb+OW44PEOZa8EF4NYBed75BMkS] X-Originating-Email: [duanshuidao@hotmail.com] Message-ID: References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> From: Jun Hu MIME-Version: 1.0 (1.0) In-Reply-To: <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> Date: Tue, 19 Mar 2013 09:29:40 +0800 To: Jing Chen X-OriginalArrivalTime: 19 Mar 2013 01:29:46.0520 (UTC) FILETIME=[3D987980:01CE2441] Cc: "xen-users@lists.xen.org" , Alexandre Kouznetsov Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 you can contact suse techinical engineer from hujun's iphone On 2013-3-19, at 8:37, "Jing Chen" wrote: > Hi Alexandre. > I post a new topic in xen forum. Please see below email and link. I got the reply that Frank Zhang is out of office for long time. I am wondering if I put to the wrong place? > > Could you help to answer this question? > > > Thanks very much. > > > Jing Chen > > CBC/XIB/K > No.5 Lize East Street, Chaoyang District > 100102, Beijing, China > Phone +86 10 84767586 > Mobile +86 13801223973 > jing.chen@ericsson.com > www.ericsson.com > > > > > This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer > > -----Original Message----- > From: xen-users-bounces@lists.xen.org [mailto:xen-users-bounces@lists.xen.org] On Behalf Of Jing Chen > Sent: Monday, March 18, 2013 6:25 PM > To: xen-users@lists.xensource.com > Subject: [Xen-users] how to create a full-virtualization xen VM with autoyast > > Hi. > I want to create a full-virtualization xen VM with autoyast installation. > how can i do that? and how does the configuration file to be configured? > > I use suse linux 11 SP2. > > > > looking forward your replay. > > > > Jing. > > > > > > -- > View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901.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 > > _______________________________________________ > 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 Mar 19 01:49:54 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 01:49: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 1UHlfS-00030X-Tc; Tue, 19 Mar 2013 01:48:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHlfR-00030S-T8 for xen-users@lists.xen.org; Tue, 19 Mar 2013 01:48:46 +0000 Received: from [85.158.138.51:43390] by server-3.bemta-3.messagelabs.com id 0D/24-26934-8F3C7415; Tue, 19 Mar 2013 01:48:40 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1363657718!9508311!1 X-Originating-IP: [209.85.223.172] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21019 invoked from network); 19 Mar 2013 01:48:39 -0000 Received: from mail-ie0-f172.google.com (HELO mail-ie0-f172.google.com) (209.85.223.172) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 01:48:39 -0000 Received: by mail-ie0-f172.google.com with SMTP id c10so7923979ieb.3 for ; Mon, 18 Mar 2013 18:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=co756cG0pX80i+p9ZdVHNacVA2gbGpuZhun/zMNEHpY=; b=fGkp6kn/m/Qr95I6pYUObIrvXscHNbQJ/E2c1a4G+B0lxhiXuTxXumQ33C8saYFnbp 6IWAdgYgsmNy9C92zfLJV7RgJdimqmN+KW00lFmmdop7Lln4R6H3O5HsuqZ1Lp67It+f egEXHY2vdwIQ+6OFHx/hZTf2W8j/CQSE23+iu76bwljickrcL+OlAuI7tOsvDKkG6P+E C30zdyClWszK1pk/tDM+XEHnCdPDKpl4aaqiKU0ieD07RQ4GCvbeThmLgzigJ+7EoDUJ I1Ueo3Bkf4j7NCKWrMYplTU5MJXvSH5jfwj4ZmQv4jnon1ACX2I7yDUAGpBhSlb/HyEn jj1g== MIME-Version: 1.0 X-Received: by 10.50.202.6 with SMTP id ke6mr64894igc.30.1363657718047; Mon, 18 Mar 2013 18:48:38 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 18:48:37 -0700 (PDT) In-Reply-To: <5147AB67.9050705@yahoo.co.uk> References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> <5147AB67.9050705@yahoo.co.uk> Date: Mon, 18 Mar 2013 19:48:37 -0600 Message-ID: From: jacek burghardt To: Ian Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============0744616435389831807==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0744616435389831807== Content-Type: multipart/alternative; boundary=f46d0447a291e12a8f04d83d4d0f --f46d0447a291e12a8f04d83d4d0f Content-Type: text/plain; charset=ISO-8859-1 Maybe problem is caused by domO ballooning I have this line in grub dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all and I am using 3.8.3 kernel with opensuse patches and seems to be very stable with 4.3 unstable --f46d0447a291e12a8f04d83d4d0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Maybe problem is caused by domO ballooning I have this line in grub dom= 0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall and I am using 3.8.= 3 kernel with opensuse patches and seems to be very stable with 4.3 unstabl= e=A0

--f46d0447a291e12a8f04d83d4d0f-- --===============0744616435389831807== 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 --===============0744616435389831807==-- From xen-users-bounces@lists.xen.org Tue Mar 19 01:49:54 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 01:49: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 1UHlfS-00030X-Tc; Tue, 19 Mar 2013 01:48:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHlfR-00030S-T8 for xen-users@lists.xen.org; Tue, 19 Mar 2013 01:48:46 +0000 Received: from [85.158.138.51:43390] by server-3.bemta-3.messagelabs.com id 0D/24-26934-8F3C7415; Tue, 19 Mar 2013 01:48:40 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1363657718!9508311!1 X-Originating-IP: [209.85.223.172] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21019 invoked from network); 19 Mar 2013 01:48:39 -0000 Received: from mail-ie0-f172.google.com (HELO mail-ie0-f172.google.com) (209.85.223.172) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 01:48:39 -0000 Received: by mail-ie0-f172.google.com with SMTP id c10so7923979ieb.3 for ; Mon, 18 Mar 2013 18:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=co756cG0pX80i+p9ZdVHNacVA2gbGpuZhun/zMNEHpY=; b=fGkp6kn/m/Qr95I6pYUObIrvXscHNbQJ/E2c1a4G+B0lxhiXuTxXumQ33C8saYFnbp 6IWAdgYgsmNy9C92zfLJV7RgJdimqmN+KW00lFmmdop7Lln4R6H3O5HsuqZ1Lp67It+f egEXHY2vdwIQ+6OFHx/hZTf2W8j/CQSE23+iu76bwljickrcL+OlAuI7tOsvDKkG6P+E C30zdyClWszK1pk/tDM+XEHnCdPDKpl4aaqiKU0ieD07RQ4GCvbeThmLgzigJ+7EoDUJ I1Ueo3Bkf4j7NCKWrMYplTU5MJXvSH5jfwj4ZmQv4jnon1ACX2I7yDUAGpBhSlb/HyEn jj1g== MIME-Version: 1.0 X-Received: by 10.50.202.6 with SMTP id ke6mr64894igc.30.1363657718047; Mon, 18 Mar 2013 18:48:38 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 18:48:37 -0700 (PDT) In-Reply-To: <5147AB67.9050705@yahoo.co.uk> References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> <5147AB67.9050705@yahoo.co.uk> Date: Mon, 18 Mar 2013 19:48:37 -0600 Message-ID: From: jacek burghardt To: Ian Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============0744616435389831807==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0744616435389831807== Content-Type: multipart/alternative; boundary=f46d0447a291e12a8f04d83d4d0f --f46d0447a291e12a8f04d83d4d0f Content-Type: text/plain; charset=ISO-8859-1 Maybe problem is caused by domO ballooning I have this line in grub dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all and I am using 3.8.3 kernel with opensuse patches and seems to be very stable with 4.3 unstable --f46d0447a291e12a8f04d83d4d0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Maybe problem is caused by domO ballooning I have this line in grub dom= 0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall and I am using 3.8.= 3 kernel with opensuse patches and seems to be very stable with 4.3 unstabl= e=A0

--f46d0447a291e12a8f04d83d4d0f-- --===============0744616435389831807== 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 --===============0744616435389831807==-- From xen-users-bounces@lists.xen.org Tue Mar 19 02:02:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 02:02: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 1UHlsK-00041h-Je; Tue, 19 Mar 2013 02:02:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHlsI-00041c-Ku for xen-users@lists.xen.org; Tue, 19 Mar 2013 02:02:02 +0000 Received: from [85.158.138.51:18925] by server-15.bemta-3.messagelabs.com id E4/61-23142-917C7415; Tue, 19 Mar 2013 02:02:01 +0000 X-Env-Sender: E.Istomin@edss.ee X-Msg-Ref: server-3.tower-174.messagelabs.com!1363658521!20058603!1 X-Originating-IP: [88.196.162.246] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26176 invoked from network); 19 Mar 2013 02:02:01 -0000 Received: from mailcluster1.edss.ee (HELO mailcluster1.edss.ee) (88.196.162.246) by server-3.tower-174.messagelabs.com with SMTP; 19 Mar 2013 02:02:01 -0000 Received: from imap.edss.ee (imap.edss.ee [88.196.163.239]) by mailcluster1.edss.ee (Postfix) with ESMTP id 4F3CA820F4; Tue, 19 Mar 2013 04:02:00 +0200 (EET) Received: from eistomin.users.edss.local (istomin.edss.ee [194.204.32.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by imap.edss.ee (Postfix) with ESMTPSA id 47750602CB; Tue, 19 Mar 2013 04:02:00 +0200 (EET) From: Eugene Istomin To: xen-users Date: Tue, 19 Mar 2013 04:01:55 +0200 Message-ID: <14060997.pf0ahXB1Me@eistomin.users.edss.local> Organization: EDSS User-Agent: KMail/4.9.5 (Linux/3.8.2-2-desktop; KDE/4.9.5; x86_64; ; ) MIME-Version: 1.0 Cc: james.harper@bendigoit.com.au Subject: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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="===============7059554080381019903==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7059554080381019903== Content-Type: multipart/alternative; boundary="nextPart3353174.9MkU865tha" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart3353174.9MkU865tha Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Hello, we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode. The exact bug is described here: http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html What is surprising: Windows 2008 R2 Standard from the same ISO is running well and network is workin properly. I tried .372 & .389 GPLPV builds - results are the same. Can anyone have Win2k8 R2 Ent in qemu-xen mode? -- Best regards, Eugene Istomin --nextPart3353174.9MkU865tha Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="utf-8"

Hello,

 

we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode.

The exact bug is described here:

http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html

 

What is surprising: Windows 2008 R2 Standard from the same ISO is running well and network is workin properly.

 

I tried .372 & .389 GPLPV builds - results are the same.

 

Can anyone have Win2k8 R2 Ent in qemu-xen mode?

--

Best regards,

Eugene Istomin

--nextPart3353174.9MkU865tha-- --===============7059554080381019903== 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 --===============7059554080381019903==-- From xen-users-bounces@lists.xen.org Tue Mar 19 02:02:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 02:02: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 1UHlsK-00041h-Je; Tue, 19 Mar 2013 02:02:04 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHlsI-00041c-Ku for xen-users@lists.xen.org; Tue, 19 Mar 2013 02:02:02 +0000 Received: from [85.158.138.51:18925] by server-15.bemta-3.messagelabs.com id E4/61-23142-917C7415; Tue, 19 Mar 2013 02:02:01 +0000 X-Env-Sender: E.Istomin@edss.ee X-Msg-Ref: server-3.tower-174.messagelabs.com!1363658521!20058603!1 X-Originating-IP: [88.196.162.246] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26176 invoked from network); 19 Mar 2013 02:02:01 -0000 Received: from mailcluster1.edss.ee (HELO mailcluster1.edss.ee) (88.196.162.246) by server-3.tower-174.messagelabs.com with SMTP; 19 Mar 2013 02:02:01 -0000 Received: from imap.edss.ee (imap.edss.ee [88.196.163.239]) by mailcluster1.edss.ee (Postfix) with ESMTP id 4F3CA820F4; Tue, 19 Mar 2013 04:02:00 +0200 (EET) Received: from eistomin.users.edss.local (istomin.edss.ee [194.204.32.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by imap.edss.ee (Postfix) with ESMTPSA id 47750602CB; Tue, 19 Mar 2013 04:02:00 +0200 (EET) From: Eugene Istomin To: xen-users Date: Tue, 19 Mar 2013 04:01:55 +0200 Message-ID: <14060997.pf0ahXB1Me@eistomin.users.edss.local> Organization: EDSS User-Agent: KMail/4.9.5 (Linux/3.8.2-2-desktop; KDE/4.9.5; x86_64; ; ) MIME-Version: 1.0 Cc: james.harper@bendigoit.com.au Subject: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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="===============7059554080381019903==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7059554080381019903== Content-Type: multipart/alternative; boundary="nextPart3353174.9MkU865tha" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart3353174.9MkU865tha Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Hello, we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode. The exact bug is described here: http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html What is surprising: Windows 2008 R2 Standard from the same ISO is running well and network is workin properly. I tried .372 & .389 GPLPV builds - results are the same. Can anyone have Win2k8 R2 Ent in qemu-xen mode? -- Best regards, Eugene Istomin --nextPart3353174.9MkU865tha Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="utf-8"

Hello,

 

we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode.

The exact bug is described here:

http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html

 

What is surprising: Windows 2008 R2 Standard from the same ISO is running well and network is workin properly.

 

I tried .372 & .389 GPLPV builds - results are the same.

 

Can anyone have Win2k8 R2 Ent in qemu-xen mode?

--

Best regards,

Eugene Istomin

--nextPart3353174.9MkU865tha-- --===============7059554080381019903== 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 --===============7059554080381019903==-- From xen-users-bounces@lists.xen.org Tue Mar 19 02:21:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 02: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 1UHmAO-0004Ye-L5; Tue, 19 Mar 2013 02:20:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHmAN-0004YZ-5Z for xen-users@lists.xen.org; Tue, 19 Mar 2013 02:20:43 +0000 Received: from [193.109.254.147:39562] by server-7.bemta-14.messagelabs.com id E7/84-19255-A7BC7415; Tue, 19 Mar 2013 02:20:42 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1363659640!1859069!1 X-Originating-IP: [209.85.210.178] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17712 invoked from network); 19 Mar 2013 02:20:41 -0000 Received: from mail-ia0-f178.google.com (HELO mail-ia0-f178.google.com) (209.85.210.178) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 02:20:41 -0000 Received: by mail-ia0-f178.google.com with SMTP id y10so3694776iak.9 for ; Mon, 18 Mar 2013 19:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VavJWxRkOxg7nTf/OpQZsX6+lT+fLXlSFpsWz0FhMgI=; b=VTE3ww7+t9kW/6U9NSA6Dy/RwkGMf9Lv9Uq3iuH/HfJC/BX+tFijnPr7uxnX9yWbhK L1DNURw34b43uJjQ0ehocyEbHxGONIsOBmXqNdMALvcpZXBoEFnIdM76NnVSZzjHj84n 7bNyoNz7zp0iRYNSEJM3uaDFVk2cP3L7oO9RCqhEJBDArmirsXwQ/k00mP67CN+NNI57 SGgW1LdrRgf3IqEGKOsD95VRVQvJehFxxr3RsGJ/JVBxDj0bw4oi8fLdKIXO+L8y5OfT xyPyqUuwFoWjAxq/2zEDs3xxh8UP/l5o5W0AiG9NXCVZZCG1MrEwwqIPWu0tNLlvcDq3 iuSg== MIME-Version: 1.0 X-Received: by 10.50.77.230 with SMTP id v6mr116147igw.29.1363659640413; Mon, 18 Mar 2013 19:20:40 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 19:20:40 -0700 (PDT) In-Reply-To: <14060997.pf0ahXB1Me@eistomin.users.edss.local> References: <14060997.pf0ahXB1Me@eistomin.users.edss.local> Date: Mon, 18 Mar 2013 20:20:40 -0600 Message-ID: From: jacek burghardt To: Eugene Istomin Cc: xen-users , james.harper@bendigoit.com.au Subject: Re: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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="===============1515192462557437930==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1515192462557437930== Content-Type: multipart/alternative; boundary=e89a8f3ba87f76273304d83dc0ba --e89a8f3ba87f76273304d83dc0ba Content-Type: text/plain; charset=ISO-8859-1 I had no problems wit with data center edition and standard using signed drivers and quemu-xen. I have no issues with server 2012 with signed drivers using qemu-xen seabios master git. I am running arch linux with.3.8.3 kernel and xen 4.3 --e89a8f3ba87f76273304d83dc0ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had no problems wit with data=A0 center edition and standard using signed= drivers and quemu-xen. I have no issues with server 2012 with signed drive= rs using qemu-xen seabios master git. I am running arch linux with.3.8.3 ke= rnel and xen 4.3


--e89a8f3ba87f76273304d83dc0ba-- --===============1515192462557437930== 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 --===============1515192462557437930==-- From xen-users-bounces@lists.xen.org Tue Mar 19 02:21:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 02: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 1UHmAO-0004Ye-L5; Tue, 19 Mar 2013 02:20:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHmAN-0004YZ-5Z for xen-users@lists.xen.org; Tue, 19 Mar 2013 02:20:43 +0000 Received: from [193.109.254.147:39562] by server-7.bemta-14.messagelabs.com id E7/84-19255-A7BC7415; Tue, 19 Mar 2013 02:20:42 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1363659640!1859069!1 X-Originating-IP: [209.85.210.178] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17712 invoked from network); 19 Mar 2013 02:20:41 -0000 Received: from mail-ia0-f178.google.com (HELO mail-ia0-f178.google.com) (209.85.210.178) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 02:20:41 -0000 Received: by mail-ia0-f178.google.com with SMTP id y10so3694776iak.9 for ; Mon, 18 Mar 2013 19:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VavJWxRkOxg7nTf/OpQZsX6+lT+fLXlSFpsWz0FhMgI=; b=VTE3ww7+t9kW/6U9NSA6Dy/RwkGMf9Lv9Uq3iuH/HfJC/BX+tFijnPr7uxnX9yWbhK L1DNURw34b43uJjQ0ehocyEbHxGONIsOBmXqNdMALvcpZXBoEFnIdM76NnVSZzjHj84n 7bNyoNz7zp0iRYNSEJM3uaDFVk2cP3L7oO9RCqhEJBDArmirsXwQ/k00mP67CN+NNI57 SGgW1LdrRgf3IqEGKOsD95VRVQvJehFxxr3RsGJ/JVBxDj0bw4oi8fLdKIXO+L8y5OfT xyPyqUuwFoWjAxq/2zEDs3xxh8UP/l5o5W0AiG9NXCVZZCG1MrEwwqIPWu0tNLlvcDq3 iuSg== MIME-Version: 1.0 X-Received: by 10.50.77.230 with SMTP id v6mr116147igw.29.1363659640413; Mon, 18 Mar 2013 19:20:40 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 19:20:40 -0700 (PDT) In-Reply-To: <14060997.pf0ahXB1Me@eistomin.users.edss.local> References: <14060997.pf0ahXB1Me@eistomin.users.edss.local> Date: Mon, 18 Mar 2013 20:20:40 -0600 Message-ID: From: jacek burghardt To: Eugene Istomin Cc: xen-users , james.harper@bendigoit.com.au Subject: Re: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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="===============1515192462557437930==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1515192462557437930== Content-Type: multipart/alternative; boundary=e89a8f3ba87f76273304d83dc0ba --e89a8f3ba87f76273304d83dc0ba Content-Type: text/plain; charset=ISO-8859-1 I had no problems wit with data center edition and standard using signed drivers and quemu-xen. I have no issues with server 2012 with signed drivers using qemu-xen seabios master git. I am running arch linux with.3.8.3 kernel and xen 4.3 --e89a8f3ba87f76273304d83dc0ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I had no problems wit with data=A0 center edition and standard using signed= drivers and quemu-xen. I have no issues with server 2012 with signed drive= rs using qemu-xen seabios master git. I am running arch linux with.3.8.3 ke= rnel and xen 4.3


--e89a8f3ba87f76273304d83dc0ba-- --===============1515192462557437930== 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 --===============1515192462557437930==-- From xen-users-bounces@lists.xen.org Tue Mar 19 02:25:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 02:25: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 1UHmE7-0004w4-IN; Tue, 19 Mar 2013 02:24:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHmE5-0004vu-6X for xen-users@lists.xen.org; Tue, 19 Mar 2013 02:24:33 +0000 Received: from [85.158.139.211:16766] by server-6.bemta-5.messagelabs.com id 90/4A-21466-06CC7415; Tue, 19 Mar 2013 02:24:32 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-14.tower-206.messagelabs.com!1363659868!18814521!1 X-Originating-IP: [203.16.207.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22316 invoked from network); 19 Mar 2013 02:24:30 -0000 Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-14.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 19 Mar 2013 02:24:30 -0000 Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d] (helo=BITCOM1.int.sbss.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.80) (envelope-from ) id 1UHmDx-00023O-3A; Tue, 19 Mar 2013 13:24:25 +1100 Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id 14.01.0438.000; Tue, 19 Mar 2013 13:24:24 +1100 From: James Harper To: Eugene Istomin , xen-users Thread-Topic: BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl Thread-Index: AQHOJEXVZYQjV1/XEUOeu78m0nN+jZisSLlw Date: Tue, 19 Mar 2013 02:24:23 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B387F13E3@BITCOM1.int.sbss.com.au> References: <14060997.pf0ahXB1Me@eistomin.users.edss.local> In-Reply-To: <14060997.pf0ahXB1Me@eistomin.users.edss.local> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:388:e000:712:9159:c0c6:76a3:4613] x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19728.003 x-tm-as-result: No--34.653700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No MIME-Version: 1.0 X-Really-From-Bendigo-IT: magichashvalue Subject: Re: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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 > > we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode. > > The exact bug is described here: > > http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html > > What is surprising: Windows 2008 R2 Standard from the same ISO is running > well and network is workin properly. > > I tried .372 & .389 GPLPV builds - results are the same. > > Can anyone have Win2k8 R2 Ent in qemu-xen mode? First, install the debug version then get me a copy of /var/log/xen/qemu-dm-.log and I'll see if there is anything obvious in there. If that fails, i'll need a crash dump to investigate further. If Windows won't write a dump then the output of xm dump-core should be sufficient although that is quite a bit larger. James _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 02:25:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 02:25: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 1UHmE7-0004w4-IN; Tue, 19 Mar 2013 02:24:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHmE5-0004vu-6X for xen-users@lists.xen.org; Tue, 19 Mar 2013 02:24:33 +0000 Received: from [85.158.139.211:16766] by server-6.bemta-5.messagelabs.com id 90/4A-21466-06CC7415; Tue, 19 Mar 2013 02:24:32 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-14.tower-206.messagelabs.com!1363659868!18814521!1 X-Originating-IP: [203.16.207.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22316 invoked from network); 19 Mar 2013 02:24:30 -0000 Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-14.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 19 Mar 2013 02:24:30 -0000 Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d] (helo=BITCOM1.int.sbss.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.80) (envelope-from ) id 1UHmDx-00023O-3A; Tue, 19 Mar 2013 13:24:25 +1100 Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id 14.01.0438.000; Tue, 19 Mar 2013 13:24:24 +1100 From: James Harper To: Eugene Istomin , xen-users Thread-Topic: BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl Thread-Index: AQHOJEXVZYQjV1/XEUOeu78m0nN+jZisSLlw Date: Tue, 19 Mar 2013 02:24:23 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B387F13E3@BITCOM1.int.sbss.com.au> References: <14060997.pf0ahXB1Me@eistomin.users.edss.local> In-Reply-To: <14060997.pf0ahXB1Me@eistomin.users.edss.local> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:388:e000:712:9159:c0c6:76a3:4613] x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19728.003 x-tm-as-result: No--34.653700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No MIME-Version: 1.0 X-Really-From-Bendigo-IT: magichashvalue Subject: Re: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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 > > we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode. > > The exact bug is described here: > > http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html > > What is surprising: Windows 2008 R2 Standard from the same ISO is running > well and network is workin properly. > > I tried .372 & .389 GPLPV builds - results are the same. > > Can anyone have Win2k8 R2 Ent in qemu-xen mode? First, install the debug version then get me a copy of /var/log/xen/qemu-dm-.log and I'll see if there is anything obvious in there. If that fails, i'll need a crash dump to investigate further. If Windows won't write a dump then the output of xm dump-core should be sufficient although that is quite a bit larger. James _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 02:34:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 02:34: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 1UHmNM-0005Xz-Ti; Tue, 19 Mar 2013 02:34:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHmNL-0005Xr-MW for xen-users@lists.xen.org; Tue, 19 Mar 2013 02:34:07 +0000 Received: from [193.109.254.147:12236] by server-14.bemta-14.messagelabs.com id 75/E2-05867-F9EC7415; Tue, 19 Mar 2013 02:34:07 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1363659993!8863161!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24796 invoked from network); 19 Mar 2013 02:26:35 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 02:26:35 -0000 Received: by mail-ie0-f175.google.com with SMTP id c12so7905474ieb.34 for ; Mon, 18 Mar 2013 19:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=pTfJ2jXvPmvDug7BJpG8gUfc+AG8Nye2uD8LjkTxqRE=; b=YKMma23aXOMTXDOCZ0HFeSOA7eRu8P7HIhiATQQuHklo/V67Ipv0ZWwcL86lKjZ9i0 oPUPIOzj/3YoVJdSkEHxh019zmvfGvHJKKLGCXXxrsy39EqYLOJNpWsxPolik+E8RPn0 4MKEftIYDISiIXyxUZqmp5/vM+tPjCTKoecq8GRDfF1km46DieA5NHovH8hEa5tm5AjM QA600LStyIItTCyps+LonH+B/VcwWRcXuvJiH56hNkkxALg+Ssx8VLy4PW8l7oQucVGu /Ngba3Xrr3me3ruAbJvXyO27rvogFdzOl+7w2rQgXuDlGmSsw3BYklhUG6JwwGLUYr0K BbiA== MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr72695igb.90.1363659993537; Mon, 18 Mar 2013 19:26:33 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 19:26:33 -0700 (PDT) Date: Mon, 18 Mar 2013 20:26:33 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] reboot not implemented X-BeenThere: xen-users@lists.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="===============1214513136253279953==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1214513136253279953== Content-Type: multipart/alternative; boundary=089e011847f68268fe04d83dd5ee --089e011847f68268fe04d83dd5ee Content-Type: text/plain; charset=ISO-8859-1 xen 4.3 it is missing reboot function is there patch or any plans on implementing it ? When I type in xl reboot -F I get this Rebooting domain 17 PV control interface not available: sending ACPI reset button event. libxl: error: libxl.c:4570:libxl_send_trigger: Send trigger 'reset' failed: Function not implemented reboot failed (rc=-3) I get the same with attempting to send power press. --089e011847f68268fe04d83dd5ee Content-Type: text/html; charset=ISO-8859-1 xen 4.3 it is missing reboot function is there patch or any plans on implementing it ? When I type in xl reboot -F
I get this
Rebooting domain 17
PV control interface not available: sending ACPI reset button event.
libxl: error: libxl.c:4570:libxl_send_trigger: Send trigger 'reset' failed: Function not implemented
reboot failed (rc=-3)
I get the same with attempting to send power press. --089e011847f68268fe04d83dd5ee-- --===============1214513136253279953== 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 --===============1214513136253279953==-- From xen-users-bounces@lists.xen.org Tue Mar 19 02:34:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 02:34: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 1UHmNM-0005Xz-Ti; Tue, 19 Mar 2013 02:34:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHmNL-0005Xr-MW for xen-users@lists.xen.org; Tue, 19 Mar 2013 02:34:07 +0000 Received: from [193.109.254.147:12236] by server-14.bemta-14.messagelabs.com id 75/E2-05867-F9EC7415; Tue, 19 Mar 2013 02:34:07 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1363659993!8863161!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24796 invoked from network); 19 Mar 2013 02:26:35 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 02:26:35 -0000 Received: by mail-ie0-f175.google.com with SMTP id c12so7905474ieb.34 for ; Mon, 18 Mar 2013 19:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=pTfJ2jXvPmvDug7BJpG8gUfc+AG8Nye2uD8LjkTxqRE=; b=YKMma23aXOMTXDOCZ0HFeSOA7eRu8P7HIhiATQQuHklo/V67Ipv0ZWwcL86lKjZ9i0 oPUPIOzj/3YoVJdSkEHxh019zmvfGvHJKKLGCXXxrsy39EqYLOJNpWsxPolik+E8RPn0 4MKEftIYDISiIXyxUZqmp5/vM+tPjCTKoecq8GRDfF1km46DieA5NHovH8hEa5tm5AjM QA600LStyIItTCyps+LonH+B/VcwWRcXuvJiH56hNkkxALg+Ssx8VLy4PW8l7oQucVGu /Ngba3Xrr3me3ruAbJvXyO27rvogFdzOl+7w2rQgXuDlGmSsw3BYklhUG6JwwGLUYr0K BbiA== MIME-Version: 1.0 X-Received: by 10.50.119.67 with SMTP id ks3mr72695igb.90.1363659993537; Mon, 18 Mar 2013 19:26:33 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Mon, 18 Mar 2013 19:26:33 -0700 (PDT) Date: Mon, 18 Mar 2013 20:26:33 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] reboot not implemented X-BeenThere: xen-users@lists.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="===============1214513136253279953==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1214513136253279953== Content-Type: multipart/alternative; boundary=089e011847f68268fe04d83dd5ee --089e011847f68268fe04d83dd5ee Content-Type: text/plain; charset=ISO-8859-1 xen 4.3 it is missing reboot function is there patch or any plans on implementing it ? When I type in xl reboot -F I get this Rebooting domain 17 PV control interface not available: sending ACPI reset button event. libxl: error: libxl.c:4570:libxl_send_trigger: Send trigger 'reset' failed: Function not implemented reboot failed (rc=-3) I get the same with attempting to send power press. --089e011847f68268fe04d83dd5ee Content-Type: text/html; charset=ISO-8859-1 xen 4.3 it is missing reboot function is there patch or any plans on implementing it ? When I type in xl reboot -F
I get this
Rebooting domain 17
PV control interface not available: sending ACPI reset button event.
libxl: error: libxl.c:4570:libxl_send_trigger: Send trigger 'reset' failed: Function not implemented
reboot failed (rc=-3)
I get the same with attempting to send power press. --089e011847f68268fe04d83dd5ee-- --===============1214513136253279953== 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 --===============1214513136253279953==-- From xen-users-bounces@lists.xen.org Tue Mar 19 04:00:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 04:00: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 1UHnhp-00081z-GG; Tue, 19 Mar 2013 03:59:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHnhn-00081u-ID for xen-users@lists.xen.org; Tue, 19 Mar 2013 03:59:19 +0000 Received: from [193.109.254.147:4632] by server-4.bemta-14.messagelabs.com id 44/46-17387-692E7415; Tue, 19 Mar 2013 03:59:18 +0000 X-Env-Sender: pigeon@pigeond.net X-Msg-Ref: server-4.tower-27.messagelabs.com!1363665555!8564010!1 X-Originating-IP: [202.65.223.218] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20854 invoked from network); 19 Mar 2013 03:59:17 -0000 Received: from static-ip-218-223-65-202.rev.dyxnet.com (HELO pan.pigeond.net) (202.65.223.218) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2013 03:59:17 -0000 Received: from saba.fluffyspider.com.au (eth5284.nsw.adsl.internode.on.net [150.101.116.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pan.pigeond.net (Postfix) with ESMTPSA id 2DA94137AB for ; Tue, 19 Mar 2013 11:59:13 +0800 (HKT) Date: Tue, 19 Mar 2013 14:59:10 +1100 From: Howell Tam To: "xen-users@lists.xen.org" Message-ID: <20130319145910.614bb63f@saba.fluffyspider.com.au> In-Reply-To: <20130318160409.1a2cb341@saba.fluffyspider.com.au> References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> <20130317181429.41706fa6@114.40.77.101> <20130318160409.1a2cb341@saba.fluffyspider.com.au> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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 been testing with xen 4.2.1 from git > (bb4d9534d139615190c752cb0b8a05ef39e2d84b). I guess I will some > more tests with xl and qemu-traditional tonight. Just for the record, with xl + qemu-xen-traditional + qemu-dm, the full freeze problem has gone away. And I get the blank-screen-after-reboot problem, which is expected. Regards, Howell. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 04:00:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 04:00: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 1UHnhp-00081z-GG; Tue, 19 Mar 2013 03:59:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHnhn-00081u-ID for xen-users@lists.xen.org; Tue, 19 Mar 2013 03:59:19 +0000 Received: from [193.109.254.147:4632] by server-4.bemta-14.messagelabs.com id 44/46-17387-692E7415; Tue, 19 Mar 2013 03:59:18 +0000 X-Env-Sender: pigeon@pigeond.net X-Msg-Ref: server-4.tower-27.messagelabs.com!1363665555!8564010!1 X-Originating-IP: [202.65.223.218] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20854 invoked from network); 19 Mar 2013 03:59:17 -0000 Received: from static-ip-218-223-65-202.rev.dyxnet.com (HELO pan.pigeond.net) (202.65.223.218) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2013 03:59:17 -0000 Received: from saba.fluffyspider.com.au (eth5284.nsw.adsl.internode.on.net [150.101.116.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pan.pigeond.net (Postfix) with ESMTPSA id 2DA94137AB for ; Tue, 19 Mar 2013 11:59:13 +0800 (HKT) Date: Tue, 19 Mar 2013 14:59:10 +1100 From: Howell Tam To: "xen-users@lists.xen.org" Message-ID: <20130319145910.614bb63f@saba.fluffyspider.com.au> In-Reply-To: <20130318160409.1a2cb341@saba.fluffyspider.com.au> References: <20130210235853.4ebb70b8@pigeond.net> <20130212084728.64c49ea1@pigeond.net> <6035A0D088A63A46850C3988ED045A4B35667928@BITCOM1.int.sbss.com.au> <20130212210541.3b71b98f@pigeond.net> <6035A0D088A63A46850C3988ED045A4B3566C353@BITCOM1.int.sbss.com.au> <20130213220535.06c0de16@pigeond.net> <20130218214525.5afe4b19@114.40.77.101> <20130317181429.41706fa6@114.40.77.101> <20130318160409.1a2cb341@saba.fluffyspider.com.au> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Subject: Re: [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.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 been testing with xen 4.2.1 from git > (bb4d9534d139615190c752cb0b8a05ef39e2d84b). I guess I will some > more tests with xl and qemu-traditional tonight. Just for the record, with xl + qemu-xen-traditional + qemu-dm, the full freeze problem has gone away. And I get the blank-screen-after-reboot problem, which is expected. Regards, Howell. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 06:44:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 06:44: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 1UHqG0-0003nH-Fa; Tue, 19 Mar 2013 06:42:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHqFz-0003nC-52 for xen-users@lists.xensource.com; Tue, 19 Mar 2013 06:42:47 +0000 Received: from [85.158.137.99:32114] by server-15.bemta-3.messagelabs.com id 79/F1-23142-6E808415; Tue, 19 Mar 2013 06:42:46 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1363675364!17584875!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18355 invoked from network); 19 Mar 2013 06:42:45 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-2.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 19 Mar 2013 06:42:45 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UHqFv-0005ei-Uv for xen-users@lists.xensource.com; Mon, 18 Mar 2013 23:42:43 -0700 Date: Mon, 18 Mar 2013 23:42:43 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363675363939-5714919.post@n5.nabble.com> In-Reply-To: References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> MIME-Version: 1.0 Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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. jun. how can i contact you? you can send you phone number directly to my emaill. Jing. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901p5714919.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 Tue Mar 19 06:44:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 06:44: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 1UHqG0-0003nH-Fa; Tue, 19 Mar 2013 06:42:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHqFz-0003nC-52 for xen-users@lists.xensource.com; Tue, 19 Mar 2013 06:42:47 +0000 Received: from [85.158.137.99:32114] by server-15.bemta-3.messagelabs.com id 79/F1-23142-6E808415; Tue, 19 Mar 2013 06:42:46 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-2.tower-217.messagelabs.com!1363675364!17584875!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18355 invoked from network); 19 Mar 2013 06:42:45 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-2.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 19 Mar 2013 06:42:45 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UHqFv-0005ei-Uv for xen-users@lists.xensource.com; Mon, 18 Mar 2013 23:42:43 -0700 Date: Mon, 18 Mar 2013 23:42:43 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363675363939-5714919.post@n5.nabble.com> In-Reply-To: References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> MIME-Version: 1.0 Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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. jun. how can i contact you? you can send you phone number directly to my emaill. Jing. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901p5714919.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 Tue Mar 19 07:54:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 07:54: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 1UHrMp-0006Dw-FI; Tue, 19 Mar 2013 07:53:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHrMn-0006Dp-JZ for xen-users@lists.xensource.com; Tue, 19 Mar 2013 07:53:53 +0000 Received: from [85.158.139.211:5476] by server-16.bemta-5.messagelabs.com id 69/78-02543-09918415; Tue, 19 Mar 2013 07:53:52 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1363679630!17413701!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17437 invoked from network); 19 Mar 2013 07:53:51 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-206.messagelabs.com with AES256-SHA encrypted SMTP; 19 Mar 2013 07:53:51 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UHrMj-0006DI-Tz for xen-users@lists.xensource.com; Tue, 19 Mar 2013 00:53:49 -0700 Date: Tue, 19 Mar 2013 00:53:49 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363679629921-5714920.post@n5.nabble.com> In-Reply-To: References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> MIME-Version: 1.0 Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 create Full-virtualization VM using below configu file. name="sles11" description="None" uuid="cc2f5ec7-9568-0bd9-d89b-f4fe13e60b08" memory=8192 maxmem=8192 vcpus=2 on_poweroff="destroy" on_reboot="destroy" on_crash="destroy" localtime=0 keymap="en-us" builder="hvm" device_model="/usr/lib/xen/bin/qemu-dm" kernel="/usr/lib/xen/boot/hvmloader" disk=[ 'phy:/dev/sda3,hda,w', 'file:/var/nsmbuild/linux/3_19089-CNA10802_2_Ux_C.iso,hdb:cdrom,r', 'file:/opt/ericsson/HA/tmp/autoyast.sles11_sp2,hdp,r'] vif=[ 'mac=00:16:3e:0e:c9:4e,bridge=br0,type=netfront', ] stdvga=0 vnc=1 vncunused=1 viridian=0 acpi=1 pae=1 serial="pty" I create device hdp for autoyast. but seem hvmloader do not take any parameter. so I have to manually input "autoyast=device://hdp/autoinst.xml" in installation process. can this manual step be replaced by automatic step? Regards Jing -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901p5714920.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 Tue Mar 19 07:54:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 07:54: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 1UHrMp-0006Dw-FI; Tue, 19 Mar 2013 07:53:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHrMn-0006Dp-JZ for xen-users@lists.xensource.com; Tue, 19 Mar 2013 07:53:53 +0000 Received: from [85.158.139.211:5476] by server-16.bemta-5.messagelabs.com id 69/78-02543-09918415; Tue, 19 Mar 2013 07:53:52 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1363679630!17413701!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17437 invoked from network); 19 Mar 2013 07:53:51 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-9.tower-206.messagelabs.com with AES256-SHA encrypted SMTP; 19 Mar 2013 07:53:51 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UHrMj-0006DI-Tz for xen-users@lists.xensource.com; Tue, 19 Mar 2013 00:53:49 -0700 Date: Tue, 19 Mar 2013 00:53:49 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363679629921-5714920.post@n5.nabble.com> In-Reply-To: References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> MIME-Version: 1.0 Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 create Full-virtualization VM using below configu file. name="sles11" description="None" uuid="cc2f5ec7-9568-0bd9-d89b-f4fe13e60b08" memory=8192 maxmem=8192 vcpus=2 on_poweroff="destroy" on_reboot="destroy" on_crash="destroy" localtime=0 keymap="en-us" builder="hvm" device_model="/usr/lib/xen/bin/qemu-dm" kernel="/usr/lib/xen/boot/hvmloader" disk=[ 'phy:/dev/sda3,hda,w', 'file:/var/nsmbuild/linux/3_19089-CNA10802_2_Ux_C.iso,hdb:cdrom,r', 'file:/opt/ericsson/HA/tmp/autoyast.sles11_sp2,hdp,r'] vif=[ 'mac=00:16:3e:0e:c9:4e,bridge=br0,type=netfront', ] stdvga=0 vnc=1 vncunused=1 viridian=0 acpi=1 pae=1 serial="pty" I create device hdp for autoyast. but seem hvmloader do not take any parameter. so I have to manually input "autoyast=device://hdp/autoinst.xml" in installation process. can this manual step be replaced by automatic step? Regards Jing -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901p5714920.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 Tue Mar 19 09:10:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 09:10: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 1UHsXT-0000qX-Iu; Tue, 19 Mar 2013 09:08:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHsXR-0000qO-SH for xen-users@lists.xen.org; Tue, 19 Mar 2013 09:08:57 +0000 Received: from [85.158.139.83:64315] by server-3.bemta-5.messagelabs.com id 77/07-17256-92B28415; Tue, 19 Mar 2013 09:08:57 +0000 X-Env-Sender: adi@cg.tuwien.ac.at X-Msg-Ref: server-12.tower-182.messagelabs.com!1363684041!28168862!1 X-Originating-IP: [213.129.229.198] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10151 invoked from network); 19 Mar 2013 09:07:25 -0000 Received: from iris.vrvis.at (HELO iris.vrvis.at) (213.129.229.198) by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 19 Mar 2013 09:07:25 -0000 Received: from actoris.vrvis.lan ([10.42.1.75] helo=vrvis.at) by iris.vrvis.at with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UHsVs-0006wD-IF; Tue, 19 Mar 2013 10:07:20 +0100 Date: Tue, 19 Mar 2013 10:07:19 +0100 From: Adi Kriegisch To: John Morrison Message-ID: <20130319090719.GF11334@vrvis.at> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: 10.42.1.75 X-SA-Exim-Rcpt-To: john@clustered.net, xen-users@lists.xen.org X-SA-Exim-Mail-From: adi@cg.tuwien.ac.at X-SA-Exim-Scanned: No (on iris.vrvis.at); SAEximRunCond expanded to false Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Disk iops performance scalability X-BeenThere: xen-users@lists.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! > Seeing a drop-off in iops when more vcpu's are added:- > > 3.8.2 kernel/xen-4.2.1/single domU/LVM backend/8GB RAM domU/2GB RAM dom0 > > dom0_max_vcpus=2 dom0_vcpus_pin > > domU 8 cores fio result 145k iops [...] > domU 14 cores fio result 81k iops [...] > The initial ioping response is good, then a lot of latency with later ones. Any ideas ? There are several possible optimizations: * At first I'd try to set the I/O-Scheduler for all DomUs to 'noop'; there is no benefit in scheduling I/Os twice. * Second thing I'd try is to give Dom0 more scheduler weight (xm sched-credit -d 0 -w 512). Now do the benchmarks again and try to find the bottlenecks by using dstat/iostat/... to find out what is going on. Probably rebalancing interrupts on the Dom0 may help (either manual or with the help of irqbalance). There are several other optimizations possible, but most of them depend on your usecase (like increasing RAM on Dom0 for caching, changeing readahead settings in Dom0 for the storage backend to better fit the I/O requests or adding more CPUs to Dom0 to be able to better handle the storage backend and things like that.) Please post your results! -- Adi _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 09:10:07 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 09:10: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 1UHsXT-0000qX-Iu; Tue, 19 Mar 2013 09:08:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHsXR-0000qO-SH for xen-users@lists.xen.org; Tue, 19 Mar 2013 09:08:57 +0000 Received: from [85.158.139.83:64315] by server-3.bemta-5.messagelabs.com id 77/07-17256-92B28415; Tue, 19 Mar 2013 09:08:57 +0000 X-Env-Sender: adi@cg.tuwien.ac.at X-Msg-Ref: server-12.tower-182.messagelabs.com!1363684041!28168862!1 X-Originating-IP: [213.129.229.198] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10151 invoked from network); 19 Mar 2013 09:07:25 -0000 Received: from iris.vrvis.at (HELO iris.vrvis.at) (213.129.229.198) by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 19 Mar 2013 09:07:25 -0000 Received: from actoris.vrvis.lan ([10.42.1.75] helo=vrvis.at) by iris.vrvis.at with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UHsVs-0006wD-IF; Tue, 19 Mar 2013 10:07:20 +0100 Date: Tue, 19 Mar 2013 10:07:19 +0100 From: Adi Kriegisch To: John Morrison Message-ID: <20130319090719.GF11334@vrvis.at> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: 10.42.1.75 X-SA-Exim-Rcpt-To: john@clustered.net, xen-users@lists.xen.org X-SA-Exim-Mail-From: adi@cg.tuwien.ac.at X-SA-Exim-Scanned: No (on iris.vrvis.at); SAEximRunCond expanded to false Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Disk iops performance scalability X-BeenThere: xen-users@lists.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! > Seeing a drop-off in iops when more vcpu's are added:- > > 3.8.2 kernel/xen-4.2.1/single domU/LVM backend/8GB RAM domU/2GB RAM dom0 > > dom0_max_vcpus=2 dom0_vcpus_pin > > domU 8 cores fio result 145k iops [...] > domU 14 cores fio result 81k iops [...] > The initial ioping response is good, then a lot of latency with later ones. Any ideas ? There are several possible optimizations: * At first I'd try to set the I/O-Scheduler for all DomUs to 'noop'; there is no benefit in scheduling I/Os twice. * Second thing I'd try is to give Dom0 more scheduler weight (xm sched-credit -d 0 -w 512). Now do the benchmarks again and try to find the bottlenecks by using dstat/iostat/... to find out what is going on. Probably rebalancing interrupts on the Dom0 may help (either manual or with the help of irqbalance). There are several other optimizations possible, but most of them depend on your usecase (like increasing RAM on Dom0 for caching, changeing readahead settings in Dom0 for the storage backend to better fit the I/O requests or adding more CPUs to Dom0 to be able to better handle the storage backend and things like that.) Please post your results! -- Adi _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 12:19:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 12:19: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 1UHvUX-0000Ap-6z; Tue, 19 Mar 2013 12:18:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHvUV-0000Ah-VG for xen-users@lists.xen.org; Tue, 19 Mar 2013 12:18:08 +0000 Received: from [85.158.143.99:49012] by server-1.bemta-4.messagelabs.com id 1A/44-06203-F7758415; Tue, 19 Mar 2013 12:18:07 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363695465!22308979!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_32,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDcwNDczNDAgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11528 invoked from network); 19 Mar 2013 12:17:45 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 12:17:45 -0000 Received: by mail-wi0-f179.google.com with SMTP id ez12so407634wid.12 for ; Tue, 19 Mar 2013 05:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=XzX2Ku3u2y8qLkbOzOq9m+jPaElctaO0/NwDb9MHrVY=; b=SvuaKp6rBfVunSLjyyE+zEcFEmkYaFGvwMgH+rON7Tt87UNePDmkS+FZoCh2UlxVop +B8jpd32pj5KBNAdha2FFJt9z7RKdYa+Ojdxx3buFvedNKD7q1qtPi5+BBVqxBq26CiR nZd+cXo1MVI/7Cb+/+dDD7XRw1ViwmQtujT1r/rm0S9oNHOkc2fFRci76IHD3V4+StRq L5lfWLuBEfc5tJkK5GEe/e+l/E7irddWdpVWJsRWKKEAJtJxaDD0PJe0c0+sIHd4gNib ES9LUS0v6ot3fJS/Ur7NkoXtH7I7erb3pU1oWBqjKxBSR83q0D9TmG8yP1qGDO7PspXi 5wcA== MIME-Version: 1.0 X-Received: by 10.180.105.99 with SMTP id gl3mr2748170wib.22.1363695464982; Tue, 19 Mar 2013 05:17:44 -0700 (PDT) Received: by 10.216.208.143 with HTTP; Tue, 19 Mar 2013 05:17:44 -0700 (PDT) Date: Tue, 19 Mar 2013 13:17:44 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: [Xen-users] Remus DRBD frozen X-BeenThere: xen-users@lists.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="===============4971176609620207207==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4971176609620207207== Content-Type: multipart/alternative; boundary=f46d04426d76c5ae9a04d8461765 --f46d04426d76c5ae9a04d8461765 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I don't know if my question doesn't related to xen at all, how ever I am trying to use DRBD as my disk replication when I ran Remus. However when I run remus sometimes my Dom-U will be freezing. I see the log file and it seem caused by drbd frozen : 875.616068] block drbd1: Local backing block device frozen? [ 887.648072] block drbd1: Local backing block device frozen? [ 899.680068] block drbd1: Local backing block device frozen? [ 911.712069] block drbd1: Local backing block device frozen? I read this patching file http://lists.linbit.com/pipermail/drbd-dev/2011-October/001961.html but I can't find the dbrd file on those directory especially on include directory. Anyone could hel me to point out, I install my DRBD follow instruction from here http://remusha.wikidot.com/#toc4 best regards, Agya --f46d04426d76c5ae9a04d8461765 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I don't know if my question doesn't rela= ted to xen at all, how ever I am trying to use DRBD as my disk replication = when I ran Remus. However when I run remus sometimes my Dom-U will be freez= ing. I see the log file and it seem caused by drbd frozen :

=A0 875.616068] block drbd1: Local backing block d= evice frozen?
[ =A0887.648072] block drbd1: Local backing block d= evice frozen?
[ =A0899.680068] block drbd1: Local backing block d= evice frozen?
[ =A0911.712069] block drbd1: Local backing block device frozen?
=


I read this patching file=A0h= ttp://lists.linbit.com/pipermail/drbd-dev/2011-October/001961.html but = I can't find the dbrd file on those directory especially on include dir= ectory.
Anyone could hel me to point out, I install my DRBD follow instruction= from here=A0http://remusha.wi= kidot.com/#toc4

best regards,

Agya
--f46d04426d76c5ae9a04d8461765-- --===============4971176609620207207== 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 --===============4971176609620207207==-- From xen-users-bounces@lists.xen.org Tue Mar 19 12:19:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 12:19: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 1UHvUX-0000Ap-6z; Tue, 19 Mar 2013 12:18:09 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHvUV-0000Ah-VG for xen-users@lists.xen.org; Tue, 19 Mar 2013 12:18:08 +0000 Received: from [85.158.143.99:49012] by server-1.bemta-4.messagelabs.com id 1A/44-06203-F7758415; Tue, 19 Mar 2013 12:18:07 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363695465!22308979!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_32,ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDcwNDczNDAgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11528 invoked from network); 19 Mar 2013 12:17:45 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 12:17:45 -0000 Received: by mail-wi0-f179.google.com with SMTP id ez12so407634wid.12 for ; Tue, 19 Mar 2013 05:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=XzX2Ku3u2y8qLkbOzOq9m+jPaElctaO0/NwDb9MHrVY=; b=SvuaKp6rBfVunSLjyyE+zEcFEmkYaFGvwMgH+rON7Tt87UNePDmkS+FZoCh2UlxVop +B8jpd32pj5KBNAdha2FFJt9z7RKdYa+Ojdxx3buFvedNKD7q1qtPi5+BBVqxBq26CiR nZd+cXo1MVI/7Cb+/+dDD7XRw1ViwmQtujT1r/rm0S9oNHOkc2fFRci76IHD3V4+StRq L5lfWLuBEfc5tJkK5GEe/e+l/E7irddWdpVWJsRWKKEAJtJxaDD0PJe0c0+sIHd4gNib ES9LUS0v6ot3fJS/Ur7NkoXtH7I7erb3pU1oWBqjKxBSR83q0D9TmG8yP1qGDO7PspXi 5wcA== MIME-Version: 1.0 X-Received: by 10.180.105.99 with SMTP id gl3mr2748170wib.22.1363695464982; Tue, 19 Mar 2013 05:17:44 -0700 (PDT) Received: by 10.216.208.143 with HTTP; Tue, 19 Mar 2013 05:17:44 -0700 (PDT) Date: Tue, 19 Mar 2013 13:17:44 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org Subject: [Xen-users] Remus DRBD frozen X-BeenThere: xen-users@lists.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="===============4971176609620207207==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4971176609620207207== Content-Type: multipart/alternative; boundary=f46d04426d76c5ae9a04d8461765 --f46d04426d76c5ae9a04d8461765 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I don't know if my question doesn't related to xen at all, how ever I am trying to use DRBD as my disk replication when I ran Remus. However when I run remus sometimes my Dom-U will be freezing. I see the log file and it seem caused by drbd frozen : 875.616068] block drbd1: Local backing block device frozen? [ 887.648072] block drbd1: Local backing block device frozen? [ 899.680068] block drbd1: Local backing block device frozen? [ 911.712069] block drbd1: Local backing block device frozen? I read this patching file http://lists.linbit.com/pipermail/drbd-dev/2011-October/001961.html but I can't find the dbrd file on those directory especially on include directory. Anyone could hel me to point out, I install my DRBD follow instruction from here http://remusha.wikidot.com/#toc4 best regards, Agya --f46d04426d76c5ae9a04d8461765 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I don't know if my question doesn't rela= ted to xen at all, how ever I am trying to use DRBD as my disk replication = when I ran Remus. However when I run remus sometimes my Dom-U will be freez= ing. I see the log file and it seem caused by drbd frozen :

=A0 875.616068] block drbd1: Local backing block d= evice frozen?
[ =A0887.648072] block drbd1: Local backing block d= evice frozen?
[ =A0899.680068] block drbd1: Local backing block d= evice frozen?
[ =A0911.712069] block drbd1: Local backing block device frozen?
=


I read this patching file=A0h= ttp://lists.linbit.com/pipermail/drbd-dev/2011-October/001961.html but = I can't find the dbrd file on those directory especially on include dir= ectory.
Anyone could hel me to point out, I install my DRBD follow instruction= from here=A0http://remusha.wi= kidot.com/#toc4

best regards,

Agya
--f46d04426d76c5ae9a04d8461765-- --===============4971176609620207207== 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 --===============4971176609620207207==-- From xen-users-bounces@lists.xen.org Tue Mar 19 13:06:26 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 13:06: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 1UHwEH-0002Iz-Jv; Tue, 19 Mar 2013 13:05:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHwEG-0002Is-43 for xen-users@lists.xen.org; Tue, 19 Mar 2013 13:05:24 +0000 Received: from [85.158.139.83:43714] by server-13.bemta-5.messagelabs.com id 7F/36-16871-39268415; Tue, 19 Mar 2013 13:05:23 +0000 X-Env-Sender: janno@kodu.ee X-Msg-Ref: server-16.tower-182.messagelabs.com!1363698322!20886905!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3199 invoked from network); 19 Mar 2013 13:05:22 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-16.tower-182.messagelabs.com with SMTP; 19 Mar 2013 13:05:22 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id B16951A2D4 for ; Tue, 19 Mar 2013 15:05:21 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id N1S65EFnemQL for ; Tue, 19 Mar 2013 15:05:19 +0200 (EET) Received: from [192.168.45.25] (km.kernel.ee [80.250.116.5]) by asum.kodu.ee (Postfix) with ESMTPSA id 9E3241A29B for ; Tue, 19 Mar 2013 15:05:19 +0200 (EET) Message-ID: <51486290.30901@kodu.ee> Date: Tue, 19 Mar 2013 15:05:20 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] Xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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! I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 install on an IBM x3550 server. The system is booted via EFI with Grub2 bootloader and it boots up normally, either with or without Xen. But i have one trouble with it: I can't get console access working with Xen. The strange thing is, despite the "WARNING: no console will be available to OS" message appearing during xen loading, the console actually starts, the graphical login screen does even appear... and then freezes. Just the console; the system iself continues to run normally. Booting the system up without xen leaves also the console working. Yet i do need this console: after some testing i have to implement this new Suse/Xen install on a distant server (which has a management module for remote console access) and I just can't risk being blinded and cut off in case there will be some confusion with network interfaces, for example. Some googling on this matter didn't give any help also. It did reveal some opinions, though, suggesting that this console problem is related to EFI.. but, unfortunately, nothing useful. Can anyone please tell me if/how it's possible to get console access with Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen 4.2?, Xen 4.1.2?, ELILO? With best regards, Janno _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 13:06:26 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 13:06: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 1UHwEH-0002Iz-Jv; Tue, 19 Mar 2013 13:05:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHwEG-0002Is-43 for xen-users@lists.xen.org; Tue, 19 Mar 2013 13:05:24 +0000 Received: from [85.158.139.83:43714] by server-13.bemta-5.messagelabs.com id 7F/36-16871-39268415; Tue, 19 Mar 2013 13:05:23 +0000 X-Env-Sender: janno@kodu.ee X-Msg-Ref: server-16.tower-182.messagelabs.com!1363698322!20886905!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3199 invoked from network); 19 Mar 2013 13:05:22 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-16.tower-182.messagelabs.com with SMTP; 19 Mar 2013 13:05:22 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id B16951A2D4 for ; Tue, 19 Mar 2013 15:05:21 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id N1S65EFnemQL for ; Tue, 19 Mar 2013 15:05:19 +0200 (EET) Received: from [192.168.45.25] (km.kernel.ee [80.250.116.5]) by asum.kodu.ee (Postfix) with ESMTPSA id 9E3241A29B for ; Tue, 19 Mar 2013 15:05:19 +0200 (EET) Message-ID: <51486290.30901@kodu.ee> Date: Tue, 19 Mar 2013 15:05:20 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] Xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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! I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 install on an IBM x3550 server. The system is booted via EFI with Grub2 bootloader and it boots up normally, either with or without Xen. But i have one trouble with it: I can't get console access working with Xen. The strange thing is, despite the "WARNING: no console will be available to OS" message appearing during xen loading, the console actually starts, the graphical login screen does even appear... and then freezes. Just the console; the system iself continues to run normally. Booting the system up without xen leaves also the console working. Yet i do need this console: after some testing i have to implement this new Suse/Xen install on a distant server (which has a management module for remote console access) and I just can't risk being blinded and cut off in case there will be some confusion with network interfaces, for example. Some googling on this matter didn't give any help also. It did reveal some opinions, though, suggesting that this console problem is related to EFI.. but, unfortunately, nothing useful. Can anyone please tell me if/how it's possible to get console access with Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen 4.2?, Xen 4.1.2?, ELILO? With best regards, Janno _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 13:56:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 13:56: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 1UHx0c-0004rs-2k; Tue, 19 Mar 2013 13:55:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHvZK-0000PN-JT for xen-users@lists.xen.org; Tue, 19 Mar 2013 12:23:06 +0000 Received: from [85.158.139.83:54318] by server-13.bemta-5.messagelabs.com id 41/18-16871-9A858415; Tue, 19 Mar 2013 12:23:05 +0000 X-Env-Sender: janno@kernel.ee X-Msg-Ref: server-13.tower-182.messagelabs.com!1363695776!27684062!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6711 invoked from network); 19 Mar 2013 12:22:56 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-13.tower-182.messagelabs.com with SMTP; 19 Mar 2013 12:22:56 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id 31FE71CC99 for ; Tue, 19 Mar 2013 14:22:55 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id 2HwjkciIx6h4 for ; Tue, 19 Mar 2013 14:22:53 +0200 (EET) Received: from [192.168.45.25] (km.kernel.ee [80.250.116.5]) by asum.kodu.ee (Postfix) with ESMTPSA id 38D561CC8E for ; Tue, 19 Mar 2013 14:22:53 +0200 (EET) Message-ID: <5148589D.4020307@kernel.ee> Date: Tue, 19 Mar 2013 14:22:53 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org X-Mailman-Approved-At: Tue, 19 Mar 2013 13:55:20 +0000 Subject: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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! I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 install on an IBM x3550 server. The system is booted via EFI with Grub2 bootloader and it boots up normally, either with or without Xen. But i have one trouble with it: I can't get console access working with Xen. The strange thing is, despite the "WARNING: no console will be available to OS" appearing during xen loading, the console actually starts, the graphical login screen does even appear... and then freezes. Just the console; the system iself continues to run normally. Booting the system up without xen leaves also the console working. Yet i do need this console: after some testing i have to implement this new Suse/Xen install on a distant server (which has a management module for remote console access) and I just can't risk being blinded and cut off in case there will be some confusion with network interfaces, for example. Some googling on this matter didn't give any help also. It did reveal some opinions, though, suggesting that this console problem is related to EFI.. but, unfortunately, nothing useful. Can anyone please tell me if/how it's possible to get console access with Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen 4.2?, Xen 4.1.2?, ELILO? With best regards, Janno _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 13:56:12 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 13:56: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 1UHx0c-0004rs-2k; Tue, 19 Mar 2013 13:55:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHvZK-0000PN-JT for xen-users@lists.xen.org; Tue, 19 Mar 2013 12:23:06 +0000 Received: from [85.158.139.83:54318] by server-13.bemta-5.messagelabs.com id 41/18-16871-9A858415; Tue, 19 Mar 2013 12:23:05 +0000 X-Env-Sender: janno@kernel.ee X-Msg-Ref: server-13.tower-182.messagelabs.com!1363695776!27684062!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6711 invoked from network); 19 Mar 2013 12:22:56 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-13.tower-182.messagelabs.com with SMTP; 19 Mar 2013 12:22:56 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id 31FE71CC99 for ; Tue, 19 Mar 2013 14:22:55 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id 2HwjkciIx6h4 for ; Tue, 19 Mar 2013 14:22:53 +0200 (EET) Received: from [192.168.45.25] (km.kernel.ee [80.250.116.5]) by asum.kodu.ee (Postfix) with ESMTPSA id 38D561CC8E for ; Tue, 19 Mar 2013 14:22:53 +0200 (EET) Message-ID: <5148589D.4020307@kernel.ee> Date: Tue, 19 Mar 2013 14:22:53 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org X-Mailman-Approved-At: Tue, 19 Mar 2013 13:55:20 +0000 Subject: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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! I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 install on an IBM x3550 server. The system is booted via EFI with Grub2 bootloader and it boots up normally, either with or without Xen. But i have one trouble with it: I can't get console access working with Xen. The strange thing is, despite the "WARNING: no console will be available to OS" appearing during xen loading, the console actually starts, the graphical login screen does even appear... and then freezes. Just the console; the system iself continues to run normally. Booting the system up without xen leaves also the console working. Yet i do need this console: after some testing i have to implement this new Suse/Xen install on a distant server (which has a management module for remote console access) and I just can't risk being blinded and cut off in case there will be some confusion with network interfaces, for example. Some googling on this matter didn't give any help also. It did reveal some opinions, though, suggesting that this console problem is related to EFI.. but, unfortunately, nothing useful. Can anyone please tell me if/how it's possible to get console access with Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen 4.2?, Xen 4.1.2?, ELILO? With best regards, Janno _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 13:56:18 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 13:56: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 1UHx0b-0004rj-F4; Tue, 19 Mar 2013 13:55:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHpyj-0003NN-2M; Tue, 19 Mar 2013 06:24:57 +0000 Received: from [85.158.143.99:15824] by server-3.bemta-4.messagelabs.com id C8/A7-02186-8B408415; Tue, 19 Mar 2013 06:24:56 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1363674295!27502221!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 584 invoked from network); 19 Mar 2013 06:24:55 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-9.tower-216.messagelabs.com with SMTP; 19 Mar 2013 06:24:55 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r2J6Onjw019234; Tue, 19 Mar 2013 01:24:49 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r2J6Onvx019233; Tue, 19 Mar 2013 01:24:49 -0500 Date: Tue, 19 Mar 2013 01:24:49 -0500 From: "Dr. Greg Wettstein" Message-Id: <201303190624.r2J6Onvx019233@wind.enjellic.com> In-Reply-To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= "Re: [Xen-devel] [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough" (Mar 17, 7:30pm) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Tue, 19 Mar 2013 01:24:49 -0500 (CDT) X-Mailman-Approved-At: Tue, 19 Mar 2013 13:55:20 +0000 Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: xen@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Mar 17, 7:30pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote: } Subject: Re: [Xen-devel] [Xen-users] Dom0 freeze on HVM DomU Windows reboo Hi Pasi, hope your day is goin gwell. > On Sun, Mar 17, 2013 at 10:01:58AM -0500, Dr. Greg Wettstein wrote: > > We just found a bug in blktap2 teardown which we have > > been hunting since 4.2.x came out so hopefully we will find some > > cycles for it. > Is this possibly the libxl blktap bug that has already been fixed in > xen-unstable? > http://xenbits.xen.org/hg/xen-unstable.hg/rev/948f232e0228 > > 4.2 backport of the patch can be found from xen-devel archives. No its a completely different problem which has probably been around as long as blktap2 has existed. Something in 4.2.1 seems to really be provoking it, at least in our test platforms. It is about a one function call wide race which causes the select call in the blktap2 IPC control plane to get interrupted and since we don't retry the system call the teardown of the tapdisk instance collapses, leaving the framework in various states of composition. Adding a function call anywhere in the call chain makes it go away so it was a classic Heisenbug. I suspect this bug may have been implicated in a lot of the rather strange behavior with blktap2 cleanup. I'm putting a patch together right now so people can evaluate it. > -- Pasi Have a good day. }-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "I had far rather walk, as I do, in daily terror of eternity, than feel that this was only a children's game in which all of the contestants would get equally worthless prizes in the end." -- T. S. Elliot _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 13:56:18 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 13:56: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 1UHx0b-0004rj-F4; Tue, 19 Mar 2013 13:55:21 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHpyj-0003NN-2M; Tue, 19 Mar 2013 06:24:57 +0000 Received: from [85.158.143.99:15824] by server-3.bemta-4.messagelabs.com id C8/A7-02186-8B408415; Tue, 19 Mar 2013 06:24:56 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-9.tower-216.messagelabs.com!1363674295!27502221!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 584 invoked from network); 19 Mar 2013 06:24:55 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-9.tower-216.messagelabs.com with SMTP; 19 Mar 2013 06:24:55 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r2J6Onjw019234; Tue, 19 Mar 2013 01:24:49 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r2J6Onvx019233; Tue, 19 Mar 2013 01:24:49 -0500 Date: Tue, 19 Mar 2013 01:24:49 -0500 From: "Dr. Greg Wettstein" Message-Id: <201303190624.r2J6Onvx019233@wind.enjellic.com> In-Reply-To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= "Re: [Xen-devel] [Xen-users] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough" (Mar 17, 7:30pm) X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Tue, 19 Mar 2013 01:24:49 -0500 (CDT) X-Mailman-Approved-At: Tue, 19 Mar 2013 13:55:20 +0000 Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Dom0 freeze on HVM DomU Windows reboot with VGA passthrough X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: xen@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Mar 17, 7:30pm, Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= wrote: } Subject: Re: [Xen-devel] [Xen-users] Dom0 freeze on HVM DomU Windows reboo Hi Pasi, hope your day is goin gwell. > On Sun, Mar 17, 2013 at 10:01:58AM -0500, Dr. Greg Wettstein wrote: > > We just found a bug in blktap2 teardown which we have > > been hunting since 4.2.x came out so hopefully we will find some > > cycles for it. > Is this possibly the libxl blktap bug that has already been fixed in > xen-unstable? > http://xenbits.xen.org/hg/xen-unstable.hg/rev/948f232e0228 > > 4.2 backport of the patch can be found from xen-devel archives. No its a completely different problem which has probably been around as long as blktap2 has existed. Something in 4.2.1 seems to really be provoking it, at least in our test platforms. It is about a one function call wide race which causes the select call in the blktap2 IPC control plane to get interrupted and since we don't retry the system call the teardown of the tapdisk instance collapses, leaving the framework in various states of composition. Adding a function call anywhere in the call chain makes it go away so it was a classic Heisenbug. I suspect this bug may have been implicated in a lot of the rather strange behavior with blktap2 cleanup. I'm putting a patch together right now so people can evaluate it. > -- Pasi Have a good day. }-- End of excerpt from Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "I had far rather walk, as I do, in daily terror of eternity, than feel that this was only a children's game in which all of the contestants would get equally worthless prizes in the end." -- T. S. Elliot _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 14:55:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 14:55: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 1UHxvX-00007u-KV; Tue, 19 Mar 2013 14:54:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHxvV-00007k-Cj for xen-users@lists.xen.org; Tue, 19 Mar 2013 14:54:09 +0000 Received: from [85.158.139.211:8655] by server-14.bemta-5.messagelabs.com id 25/81-13158-01C78415; Tue, 19 Mar 2013 14:54:08 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1363704757!19003050!1 X-Originating-IP: [209.85.220.175] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13110 invoked from network); 19 Mar 2013 14:52:38 -0000 Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 14:52:38 -0000 Received: by mail-vc0-f175.google.com with SMTP id hf12so434143vcb.6 for ; Tue, 19 Mar 2013 07:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=21Y8BGE4ALHtlAoXRChXahOdt4KilW/L3pTGg65sfk8=; b=uYHGdBDoh2bJqkV6qSiiRe8/+jqrbBu+wO7ecrWd+kghWovB52YpXJzezuGOoDNGQ8 5aFS1KlOdFGmNexL1Byqeh6bxY8VEvzlyT/gto/bUIcd0XSs/9xRWey8EzNvnGSoTEjd zfIieJpOFntx7I9JFWZFNMfoRMy1t27ncv1xkl1pRNPXmAHAN3vQPbZEhX4GUfTWBXOK mrl285PoaVD+Zi0pDg/81/AZ8w7hKLXbDZ3UsOPCWSx+0hIVpY7YQQY5t9NYVvkFt9oY N8wst+kt7+IU3RZASxFuthfC39c7y78UVSCnVyM4430HjhdtpfLlYrl0T6K20EMXYG6+ SL0A== MIME-Version: 1.0 X-Received: by 10.58.50.7 with SMTP id y7mr2826868ven.24.1363704757205; Tue, 19 Mar 2013 07:52:37 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Tue, 19 Mar 2013 07:52:37 -0700 (PDT) In-Reply-To: <5148589D.4020307@kernel.ee> References: <5148589D.4020307@kernel.ee> Date: Tue, 19 Mar 2013 10:52:37 -0400 Message-ID: From: Casey DeLorme To: Janno Loide Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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="===============4443554085383986518==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4443554085383986518== Content-Type: multipart/alternative; boundary=089e0112c63aa1fe3104d84841e7 --089e0112c63aa1fe3104d84841e7 Content-Type: text/plain; charset=UTF-8 Hello Janno, First question, do you have SSH configured and can you access via SSH? Second, have you tried switching TTY consoles after the login screen freezes? Is it possible it could just be the GUI and not the console? Hotkeys like ctrl+alt+F# will switch you to various terminal consoles which may allow you to at least gain access and try to debug locally. This may be a long shot, but what GUI are you using? Xen 4.1 had an EFI bug for me where it would not recognize all available memory, and Gnome3 (as an example) locks up with 512MB or less. If you can access the system via the alternative TTY or via SSH you may be able to check using the xm or xl toolstacks `dmesg` and searching for "System RAM". Unfortunately if that is the cause the only solution I am aware of involves modifying the source and rebuilding, which is not at all helpful if you are using packages. Hope these suggestions help with troubleshooting. ~Casey On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide wrote: > Hello All! > > I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 > install on an IBM x3550 server. The system is booted via EFI with Grub2 > bootloader and it boots up normally, either with or without Xen. > But i have one trouble with it: I can't get console access working with > Xen. > > The strange thing is, despite the "WARNING: no console will be available > to OS" appearing during xen loading, the console actually starts, the > graphical login screen does even appear... and then freezes. Just the > console; the system iself continues to run normally. > Booting the system up without xen leaves also the console working. > > Yet i do need this console: after some testing i have to implement this > new Suse/Xen install on a distant server (which has a management module for > remote console access) and I just can't risk being blinded and cut off in > case there will be some confusion with network interfaces, for example. > > Some googling on this matter didn't give any help also. It did reveal some > opinions, though, suggesting that this console problem is related to EFI.. > but, unfortunately, nothing useful. > > > Can anyone please tell me if/how it's possible to get console access with > Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen > 4.2?, Xen 4.1.2?, ELILO? > > > With best regards, > Janno > > > ______________________________**_________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --089e0112c63aa1fe3104d84841e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Janno,

First question,= do you have SSH configured and can you access via SSH?

Second, have you tried switching TTY consoles after the login screen = freezes? =C2=A0Is it possible it could just be the GUI and not the console?= =C2=A0Hotkeys like ctrl+alt+F# will switch you to various terminal console= s which may allow you to at least gain access and try to debug locally.

This may be a long shot, but what GUI are you using? = =C2=A0Xen 4.1 had an EFI bug for me where it would not recognize all availa= ble memory, and Gnome3 (as an example) locks up with 512MB or less.

If you can access the system via the alternative TTY or via = SSH you may be able to check using the xm or xl toolstacks `dmesg` and sear= ching for "System RAM".

Unfortunately if= that is the cause the only solution I am aware of involves modifying the s= ource and rebuilding, which is not at all helpful if you are using packages= .

Hope these suggestions help with troubleshooting.
=

~Casey


On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide <janno= @kernel.ee> wrote:
Hello All!

=C2=A0 =C2=A0 I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xe= n 4.1.3 install on an IBM x3550 server. The system is booted via EFI with G= rub2 bootloader and it boots up normally, either with or without Xen.
But i have one trouble with it: I can't get console access working with= Xen.

The strange thing is, despite the "WARNING: no console will be availab= le to OS" appearing during xen loading, the console actually starts, t= he graphical login screen does even appear... and then freezes. Just the co= nsole; the system iself continues to run normally.
Booting the system up without xen leaves also the console working.

Yet i do need this console: after some testing i have to implement this new= Suse/Xen install on a distant server (which has a management module for re= mote console access) and I just can't risk being blinded and cut off in= case there will be some confusion with network interfaces, for example.
Some googling on this matter didn't give any help also. It did reveal s= ome opinions, though, suggesting that this console problem is related to EF= I.. but, unfortunately, nothing useful.


Can anyone please tell me if/how it's possible to get console access wi= th Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? = Xen 4.2?, Xen 4.1.2?, ELILO?


With best regards,
=C2=A0 =C2=A0 Janno


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

--089e0112c63aa1fe3104d84841e7-- --===============4443554085383986518== 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 --===============4443554085383986518==-- From xen-users-bounces@lists.xen.org Tue Mar 19 14:55:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 14:55: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 1UHxvX-00007u-KV; Tue, 19 Mar 2013 14:54:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHxvV-00007k-Cj for xen-users@lists.xen.org; Tue, 19 Mar 2013 14:54:09 +0000 Received: from [85.158.139.211:8655] by server-14.bemta-5.messagelabs.com id 25/81-13158-01C78415; Tue, 19 Mar 2013 14:54:08 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1363704757!19003050!1 X-Originating-IP: [209.85.220.175] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13110 invoked from network); 19 Mar 2013 14:52:38 -0000 Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 14:52:38 -0000 Received: by mail-vc0-f175.google.com with SMTP id hf12so434143vcb.6 for ; Tue, 19 Mar 2013 07:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=21Y8BGE4ALHtlAoXRChXahOdt4KilW/L3pTGg65sfk8=; b=uYHGdBDoh2bJqkV6qSiiRe8/+jqrbBu+wO7ecrWd+kghWovB52YpXJzezuGOoDNGQ8 5aFS1KlOdFGmNexL1Byqeh6bxY8VEvzlyT/gto/bUIcd0XSs/9xRWey8EzNvnGSoTEjd zfIieJpOFntx7I9JFWZFNMfoRMy1t27ncv1xkl1pRNPXmAHAN3vQPbZEhX4GUfTWBXOK mrl285PoaVD+Zi0pDg/81/AZ8w7hKLXbDZ3UsOPCWSx+0hIVpY7YQQY5t9NYVvkFt9oY N8wst+kt7+IU3RZASxFuthfC39c7y78UVSCnVyM4430HjhdtpfLlYrl0T6K20EMXYG6+ SL0A== MIME-Version: 1.0 X-Received: by 10.58.50.7 with SMTP id y7mr2826868ven.24.1363704757205; Tue, 19 Mar 2013 07:52:37 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Tue, 19 Mar 2013 07:52:37 -0700 (PDT) In-Reply-To: <5148589D.4020307@kernel.ee> References: <5148589D.4020307@kernel.ee> Date: Tue, 19 Mar 2013 10:52:37 -0400 Message-ID: From: Casey DeLorme To: Janno Loide Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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="===============4443554085383986518==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4443554085383986518== Content-Type: multipart/alternative; boundary=089e0112c63aa1fe3104d84841e7 --089e0112c63aa1fe3104d84841e7 Content-Type: text/plain; charset=UTF-8 Hello Janno, First question, do you have SSH configured and can you access via SSH? Second, have you tried switching TTY consoles after the login screen freezes? Is it possible it could just be the GUI and not the console? Hotkeys like ctrl+alt+F# will switch you to various terminal consoles which may allow you to at least gain access and try to debug locally. This may be a long shot, but what GUI are you using? Xen 4.1 had an EFI bug for me where it would not recognize all available memory, and Gnome3 (as an example) locks up with 512MB or less. If you can access the system via the alternative TTY or via SSH you may be able to check using the xm or xl toolstacks `dmesg` and searching for "System RAM". Unfortunately if that is the cause the only solution I am aware of involves modifying the source and rebuilding, which is not at all helpful if you are using packages. Hope these suggestions help with troubleshooting. ~Casey On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide wrote: > Hello All! > > I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 > install on an IBM x3550 server. The system is booted via EFI with Grub2 > bootloader and it boots up normally, either with or without Xen. > But i have one trouble with it: I can't get console access working with > Xen. > > The strange thing is, despite the "WARNING: no console will be available > to OS" appearing during xen loading, the console actually starts, the > graphical login screen does even appear... and then freezes. Just the > console; the system iself continues to run normally. > Booting the system up without xen leaves also the console working. > > Yet i do need this console: after some testing i have to implement this > new Suse/Xen install on a distant server (which has a management module for > remote console access) and I just can't risk being blinded and cut off in > case there will be some confusion with network interfaces, for example. > > Some googling on this matter didn't give any help also. It did reveal some > opinions, though, suggesting that this console problem is related to EFI.. > but, unfortunately, nothing useful. > > > Can anyone please tell me if/how it's possible to get console access with > Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen > 4.2?, Xen 4.1.2?, ELILO? > > > With best regards, > Janno > > > ______________________________**_________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --089e0112c63aa1fe3104d84841e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Janno,

First question,= do you have SSH configured and can you access via SSH?

Second, have you tried switching TTY consoles after the login screen = freezes? =C2=A0Is it possible it could just be the GUI and not the console?= =C2=A0Hotkeys like ctrl+alt+F# will switch you to various terminal console= s which may allow you to at least gain access and try to debug locally.

This may be a long shot, but what GUI are you using? = =C2=A0Xen 4.1 had an EFI bug for me where it would not recognize all availa= ble memory, and Gnome3 (as an example) locks up with 512MB or less.

If you can access the system via the alternative TTY or via = SSH you may be able to check using the xm or xl toolstacks `dmesg` and sear= ching for "System RAM".

Unfortunately if= that is the cause the only solution I am aware of involves modifying the s= ource and rebuilding, which is not at all helpful if you are using packages= .

Hope these suggestions help with troubleshooting.
=

~Casey


On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide <janno= @kernel.ee> wrote:
Hello All!

=C2=A0 =C2=A0 I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xe= n 4.1.3 install on an IBM x3550 server. The system is booted via EFI with G= rub2 bootloader and it boots up normally, either with or without Xen.
But i have one trouble with it: I can't get console access working with= Xen.

The strange thing is, despite the "WARNING: no console will be availab= le to OS" appearing during xen loading, the console actually starts, t= he graphical login screen does even appear... and then freezes. Just the co= nsole; the system iself continues to run normally.
Booting the system up without xen leaves also the console working.

Yet i do need this console: after some testing i have to implement this new= Suse/Xen install on a distant server (which has a management module for re= mote console access) and I just can't risk being blinded and cut off in= case there will be some confusion with network interfaces, for example.
Some googling on this matter didn't give any help also. It did reveal s= ome opinions, though, suggesting that this console problem is related to EF= I.. but, unfortunately, nothing useful.


Can anyone please tell me if/how it's possible to get console access wi= th Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? = Xen 4.2?, Xen 4.1.2?, ELILO?


With best regards,
=C2=A0 =C2=A0 Janno


_______________________________________________
Xen-users mailing list
Xen-users@list= s.xen.org
http://lists.x= en.org/xen-users

--089e0112c63aa1fe3104d84841e7-- --===============4443554085383986518== 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 --===============4443554085383986518==-- From xen-users-bounces@lists.xen.org Tue Mar 19 15:40:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 15:40: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 1UHydi-0003gf-9c; Tue, 19 Mar 2013 15:39:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHydg-0003gQ-6y for xen-users@lists.xen.org; Tue, 19 Mar 2013 15:39:48 +0000 Received: from [85.158.143.99:27755] by server-1.bemta-4.messagelabs.com id 4D/62-06203-3C688415; Tue, 19 Mar 2013 15:39:47 +0000 X-Env-Sender: E.Istomin@edss.ee X-Msg-Ref: server-8.tower-216.messagelabs.com!1363705779!17826269!1 X-Originating-IP: [88.196.162.246] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13881 invoked from network); 19 Mar 2013 15:09:40 -0000 Received: from mailcluster1.edss.ee (HELO mailcluster1.edss.ee) (88.196.162.246) by server-8.tower-216.messagelabs.com with SMTP; 19 Mar 2013 15:09:40 -0000 Received: from imap.edss.ee (imap.edss.ee [88.196.163.239]) by mailcluster1.edss.ee (Postfix) with ESMTP id 2566981571; Tue, 19 Mar 2013 17:09:39 +0200 (EET) Received: from eistomin.localnet (istomin.edss.ee [194.204.32.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by imap.edss.ee (Postfix) with ESMTPSA id A5AA5602CB; Tue, 19 Mar 2013 17:09:38 +0200 (EET) From: Eugene Istomin To: xen-users@lists.xen.org Date: Tue, 19 Mar 2013 17:09:33 +0200 Message-ID: <2765182.d5BzhGrGb7@eistomin> Organization: EDSS User-Agent: KMail/4.9.5 (Linux/3.8.2-2-desktop; KDE/4.9.5; x86_64; ; ) In-Reply-To: <6035A0D088A63A46850C3988ED045A4B387F13E3@BITCOM1.int.sbss.com.au> References: <14060997.pf0ahXB1Me@eistomin.users.edss.local> <6035A0D088A63A46850C3988ED045A4B387F13E3@BITCOM1.int.sbss.com.au> MIME-Version: 1.0 Cc: James Harper Subject: Re: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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="===============5185399997930596411==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5185399997930596411== Content-Type: multipart/alternative; boundary="nextPart30997957.jn8TVqVkiM" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart30997957.jn8TVqVkiM Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" in qemu-xen-traditional model everything is working fine, in qemu-xen (upstream qemu) BSOD appears only after xennet install. I tried Win2k8 Std/Ent/DC Win2k13 Std/DC, only Win2k8 Ent/DC not worked properly. James, how i can get debug logs in qemu-upstream mode? May be this is xen issue? # kernel 3.4.35-1-xen # xen-4.2.1_06 -- Best regards, Eugene Istomin On Tuesday 19 March 2013 02:24:23 James Harper wrote: > > we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode. > > > > The exact bug is described here: > > > > http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html > > > > What is surprising: Windows 2008 R2 Standard from the same ISO is running > > well and network is workin properly. > > > > I tried .372 & .389 GPLPV builds - results are the same. > > > > Can anyone have Win2k8 R2 Ent in qemu-xen mode? > > First, install the debug version then get me a copy of > /var/log/xen/qemu-dm-.log and I'll see if there is anything > obvious in there. > > If that fails, i'll need a crash dump to investigate further. If Windows > won't write a dump then the output of xm dump-core should be sufficient > although that is quite a bit larger. > > James > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --nextPart30997957.jn8TVqVkiM Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="utf-8"

in qemu-xen-traditional model everything is working fine, in qemu-xen (upstream qemu) BSOD appears only after xennet install. I tried Win2k8 Std/Ent/DC Win2k13 Std/DC, only Win2k8 Ent/DC not worked properly.

 

James,

 

how i can get debug logs in qemu-upstream mode?

 

 

May be this is xen issue?

# kernel 3.4.35-1-xen

# xen-4.2.1_06

 

--

Best regards,

Eugene Istomin

 

 


On Tuesday 19 March 2013 02:24:23 James Harper wrote:

> > we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode.

> >

> > The exact bug is described here:

> >

> > http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html

> >

> > What is surprising: Windows 2008 R2 Standard from the same ISO is running

> > well and network is workin properly.

> >

> > I tried .372 & .389 GPLPV builds - results are the same.

> >

> > Can anyone have Win2k8 R2 Ent in qemu-xen mode?

>

> First, install the debug version then get me a copy of

> /var/log/xen/qemu-dm-<domu name>.log and I'll see if there is anything

> obvious in there.

>

> If that fails, i'll need a crash dump to investigate further. If Windows

> won't write a dump then the output of xm dump-core should be sufficient

> although that is quite a bit larger.

>

> James

>

> _______________________________________________

> Xen-users mailing list

> Xen-users@lists.xen.org

> http://lists.xen.org/xen-users

--nextPart30997957.jn8TVqVkiM-- --===============5185399997930596411== 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 --===============5185399997930596411==-- From xen-users-bounces@lists.xen.org Tue Mar 19 15:40:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 15:40: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 1UHydi-0003gf-9c; Tue, 19 Mar 2013 15:39:50 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UHydg-0003gQ-6y for xen-users@lists.xen.org; Tue, 19 Mar 2013 15:39:48 +0000 Received: from [85.158.143.99:27755] by server-1.bemta-4.messagelabs.com id 4D/62-06203-3C688415; Tue, 19 Mar 2013 15:39:47 +0000 X-Env-Sender: E.Istomin@edss.ee X-Msg-Ref: server-8.tower-216.messagelabs.com!1363705779!17826269!1 X-Originating-IP: [88.196.162.246] X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13881 invoked from network); 19 Mar 2013 15:09:40 -0000 Received: from mailcluster1.edss.ee (HELO mailcluster1.edss.ee) (88.196.162.246) by server-8.tower-216.messagelabs.com with SMTP; 19 Mar 2013 15:09:40 -0000 Received: from imap.edss.ee (imap.edss.ee [88.196.163.239]) by mailcluster1.edss.ee (Postfix) with ESMTP id 2566981571; Tue, 19 Mar 2013 17:09:39 +0200 (EET) Received: from eistomin.localnet (istomin.edss.ee [194.204.32.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by imap.edss.ee (Postfix) with ESMTPSA id A5AA5602CB; Tue, 19 Mar 2013 17:09:38 +0200 (EET) From: Eugene Istomin To: xen-users@lists.xen.org Date: Tue, 19 Mar 2013 17:09:33 +0200 Message-ID: <2765182.d5BzhGrGb7@eistomin> Organization: EDSS User-Agent: KMail/4.9.5 (Linux/3.8.2-2-desktop; KDE/4.9.5; x86_64; ; ) In-Reply-To: <6035A0D088A63A46850C3988ED045A4B387F13E3@BITCOM1.int.sbss.com.au> References: <14060997.pf0ahXB1Me@eistomin.users.edss.local> <6035A0D088A63A46850C3988ED045A4B387F13E3@BITCOM1.int.sbss.com.au> MIME-Version: 1.0 Cc: James Harper Subject: Re: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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="===============5185399997930596411==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5185399997930596411== Content-Type: multipart/alternative; boundary="nextPart30997957.jn8TVqVkiM" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart30997957.jn8TVqVkiM Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" in qemu-xen-traditional model everything is working fine, in qemu-xen (upstream qemu) BSOD appears only after xennet install. I tried Win2k8 Std/Ent/DC Win2k13 Std/DC, only Win2k8 Ent/DC not worked properly. James, how i can get debug logs in qemu-upstream mode? May be this is xen issue? # kernel 3.4.35-1-xen # xen-4.2.1_06 -- Best regards, Eugene Istomin On Tuesday 19 March 2013 02:24:23 James Harper wrote: > > we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode. > > > > The exact bug is described here: > > > > http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html > > > > What is surprising: Windows 2008 R2 Standard from the same ISO is running > > well and network is workin properly. > > > > I tried .372 & .389 GPLPV builds - results are the same. > > > > Can anyone have Win2k8 R2 Ent in qemu-xen mode? > > First, install the debug version then get me a copy of > /var/log/xen/qemu-dm-.log and I'll see if there is anything > obvious in there. > > If that fails, i'll need a crash dump to investigate further. If Windows > won't write a dump then the output of xm dump-core should be sufficient > although that is quite a bit larger. > > James > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --nextPart30997957.jn8TVqVkiM Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="utf-8"

in qemu-xen-traditional model everything is working fine, in qemu-xen (upstream qemu) BSOD appears only after xennet install. I tried Win2k8 Std/Ent/DC Win2k13 Std/DC, only Win2k8 Ent/DC not worked properly.

 

James,

 

how i can get debug logs in qemu-upstream mode?

 

 

May be this is xen issue?

# kernel 3.4.35-1-xen

# xen-4.2.1_06

 

--

Best regards,

Eugene Istomin

 

 


On Tuesday 19 March 2013 02:24:23 James Harper wrote:

> > we have BSOD on Windows 2008 R2 Enterprise in qemu-xen mode.

> >

> > The exact bug is described here:

> >

> > http://lists.xen.org/archives/html/xen-users/2012-09/msg00291.html

> >

> > What is surprising: Windows 2008 R2 Standard from the same ISO is running

> > well and network is workin properly.

> >

> > I tried .372 & .389 GPLPV builds - results are the same.

> >

> > Can anyone have Win2k8 R2 Ent in qemu-xen mode?

>

> First, install the debug version then get me a copy of

> /var/log/xen/qemu-dm-<domu name>.log and I'll see if there is anything

> obvious in there.

>

> If that fails, i'll need a crash dump to investigate further. If Windows

> won't write a dump then the output of xm dump-core should be sufficient

> although that is quite a bit larger.

>

> James

>

> _______________________________________________

> Xen-users mailing list

> Xen-users@lists.xen.org

> http://lists.xen.org/xen-users

--nextPart30997957.jn8TVqVkiM-- --===============5185399997930596411== 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 --===============5185399997930596411==-- From xen-users-bounces@lists.xen.org Tue Mar 19 17:38:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 17:38: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 1UI0Tx-0003dK-QU; Tue, 19 Mar 2013 17:37:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI0Tv-0003dB-PB for xen-users@lists.xen.org; Tue, 19 Mar 2013 17:37:52 +0000 Received: from [85.158.138.51:59528] by server-11.bemta-3.messagelabs.com id CD/30-01263-A62A8415; Tue, 19 Mar 2013 17:37:46 +0000 X-Env-Sender: nodelorda@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1363714663!9660923!1 X-Originating-IP: [209.85.192.174] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24494 invoked from network); 19 Mar 2013 17:37:45 -0000 Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com) (209.85.192.174) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 17:37:45 -0000 Received: by mail-pd0-f174.google.com with SMTP id 10so260215pdi.33 for ; Tue, 19 Mar 2013 10:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=lvgulkv7YscPGl9mbU5csS1jzSy+IOtY47HdSpmsevg=; b=D/bMFH4Fl0KHMzHNFqRBSEXveWs9QLsYiod8l98xqR+oi4RhYC1bmFn1pnt7c1Y47q H8qrz9gnmnRGhvGcINCIqb0k2BIbvJXubXs2KvcsnoeFOQzrJ8PsGHOXXOQpC0plTCvj v0495yUrszpkETa6EEwhv2G9hf4BQKcJcZC3w9ZB39v9pW37J6y8rEJ7QTvE7uTBfXTA bXfn4tl0UiZEeIwlvdxKHfbcgSzY/7Hd6K8fy3MwnXasPVBpLfZsbZKylFRxhWwbfNUF yvYFBioBlXri75+CGfNMd03K8w/z9QGqWIvw+UwBYTLBccV/N0MivcVEgPcCGNI6V1MY K6Iw== MIME-Version: 1.0 X-Received: by 10.68.204.164 with SMTP id kz4mr4284922pbc.158.1363714663546; Tue, 19 Mar 2013 10:37:43 -0700 (PDT) Received: by 10.68.221.3 with HTTP; Tue, 19 Mar 2013 10:37:43 -0700 (PDT) Date: Tue, 19 Mar 2013 18:37:43 +0100 Message-ID: From: Alex Bartolome To: xen-users@lists.xen.org Subject: [Xen-users] Slow Network X-BeenThere: xen-users@lists.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="===============4491363193987328630==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4491363193987328630== Content-Type: multipart/alternative; boundary=047d7b2e4cf61882eb04d84a9091 --047d7b2e4cf61882eb04d84a9091 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have a server running Xen 4.1 on a Debian 7 testitng the problem is that when you download a file from internet download slower, 70% less than with a physical machine as the dom0, dom0 is in decarga to 12.2 MB / s in a virtual machine to 3.8 MB / S, use fiber optics for internet access. However in my local network behaves quite well, only 5% lower. Thank you all. --047d7b2e4cf61882eb04d84a9091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all, I have a server running Xen 4.1 on a Debian 7= testitng the problem is that when you download a file from internet downlo= ad slower, 70% less than with a physical machine as the dom0, dom0 is in de= carga to 12.2 MB / s in a virtual machine to 3.8 MB / S, use fiber optics f= or internet access.
However in my local network behaves quite well, only 5% lower.

Thank you all.
--047d7b2e4cf61882eb04d84a9091-- --===============4491363193987328630== 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 --===============4491363193987328630==-- From xen-users-bounces@lists.xen.org Tue Mar 19 17:38:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 17:38: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 1UI0Tx-0003dK-QU; Tue, 19 Mar 2013 17:37:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI0Tv-0003dB-PB for xen-users@lists.xen.org; Tue, 19 Mar 2013 17:37:52 +0000 Received: from [85.158.138.51:59528] by server-11.bemta-3.messagelabs.com id CD/30-01263-A62A8415; Tue, 19 Mar 2013 17:37:46 +0000 X-Env-Sender: nodelorda@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1363714663!9660923!1 X-Originating-IP: [209.85.192.174] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24494 invoked from network); 19 Mar 2013 17:37:45 -0000 Received: from mail-pd0-f174.google.com (HELO mail-pd0-f174.google.com) (209.85.192.174) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 17:37:45 -0000 Received: by mail-pd0-f174.google.com with SMTP id 10so260215pdi.33 for ; Tue, 19 Mar 2013 10:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=lvgulkv7YscPGl9mbU5csS1jzSy+IOtY47HdSpmsevg=; b=D/bMFH4Fl0KHMzHNFqRBSEXveWs9QLsYiod8l98xqR+oi4RhYC1bmFn1pnt7c1Y47q H8qrz9gnmnRGhvGcINCIqb0k2BIbvJXubXs2KvcsnoeFOQzrJ8PsGHOXXOQpC0plTCvj v0495yUrszpkETa6EEwhv2G9hf4BQKcJcZC3w9ZB39v9pW37J6y8rEJ7QTvE7uTBfXTA bXfn4tl0UiZEeIwlvdxKHfbcgSzY/7Hd6K8fy3MwnXasPVBpLfZsbZKylFRxhWwbfNUF yvYFBioBlXri75+CGfNMd03K8w/z9QGqWIvw+UwBYTLBccV/N0MivcVEgPcCGNI6V1MY K6Iw== MIME-Version: 1.0 X-Received: by 10.68.204.164 with SMTP id kz4mr4284922pbc.158.1363714663546; Tue, 19 Mar 2013 10:37:43 -0700 (PDT) Received: by 10.68.221.3 with HTTP; Tue, 19 Mar 2013 10:37:43 -0700 (PDT) Date: Tue, 19 Mar 2013 18:37:43 +0100 Message-ID: From: Alex Bartolome To: xen-users@lists.xen.org Subject: [Xen-users] Slow Network X-BeenThere: xen-users@lists.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="===============4491363193987328630==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4491363193987328630== Content-Type: multipart/alternative; boundary=047d7b2e4cf61882eb04d84a9091 --047d7b2e4cf61882eb04d84a9091 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have a server running Xen 4.1 on a Debian 7 testitng the problem is that when you download a file from internet download slower, 70% less than with a physical machine as the dom0, dom0 is in decarga to 12.2 MB / s in a virtual machine to 3.8 MB / S, use fiber optics for internet access. However in my local network behaves quite well, only 5% lower. Thank you all. --047d7b2e4cf61882eb04d84a9091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all, I have a server running Xen 4.1 on a Debian 7= testitng the problem is that when you download a file from internet downlo= ad slower, 70% less than with a physical machine as the dom0, dom0 is in de= carga to 12.2 MB / s in a virtual machine to 3.8 MB / S, use fiber optics f= or internet access.
However in my local network behaves quite well, only 5% lower.

Thank you all.
--047d7b2e4cf61882eb04d84a9091-- --===============4491363193987328630== 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 --===============4491363193987328630==-- From xen-users-bounces@lists.xen.org Tue Mar 19 18:08:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 18:08: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 1UI0wZ-0005k2-N9; Tue, 19 Mar 2013 18:07:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI0wY-0005jx-3x for xen-users@lists.xen.org; Tue, 19 Mar 2013 18:07:26 +0000 Received: from [85.158.139.211:23443] by server-8.bemta-5.messagelabs.com id B9/13-05790-D59A8415; Tue, 19 Mar 2013 18:07:25 +0000 X-Env-Sender: janno@kodu.ee X-Msg-Ref: server-3.tower-206.messagelabs.com!1363716443!19011751!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24696 invoked from network); 19 Mar 2013 18:07:23 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-3.tower-206.messagelabs.com with SMTP; 19 Mar 2013 18:07:23 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id 819781C2F4 for ; Tue, 19 Mar 2013 20:07:22 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id E8_YYmxuEVaw for ; Tue, 19 Mar 2013 20:07:19 +0200 (EET) Received: from [192.168.45.25] (km.kernel.ee [80.250.116.5]) by asum.kodu.ee (Postfix) with ESMTPSA id 7579A1C2E0 for ; Tue, 19 Mar 2013 20:07:19 +0200 (EET) Message-ID: <5148A957.6010204@kodu.ee> Date: Tue, 19 Mar 2013 20:07:19 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5148589D.4020307@kernel.ee> In-Reply-To: Subject: Re: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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="===============4237683972575960948==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============4237683972575960948== Content-Type: multipart/alternative; boundary="------------040508000907050903090809" This is a multi-part message in MIME format. --------------040508000907050903090809 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi Casey, Fortunately, yes, I do have ssh access, and even vnc. So I can probably debug it in any possible way you'll recommend :) But this is just my testing configuraton, laying on a desk next to me. Implementing that software on the remote production site is what makes me really worried. I did try to switch TTYs, from the usb keyboard, without any result :( The keyboard, connected to usb port, doesn't even put any leds on, neither blinks when disconnecting/connecting after loading Xen. The system does recongize the keyboard, though: --- kernel: [ 4.510357] input: Lite-On Technology Corp. Lenovo Low Profile USB Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input1 ... kernel: [ 4.517658] usbcore: registered new interface driver usbhid Mar 19 17:54:58 linux-z01z kernel: [ 4.517659] usbhid: USB HID core driver --- The system has a remote management module with java-based remote console applet and that behaves exactly the same as the real console: Kdm login screen appears, the cursor blinks, but typing on a keyboard has no effect. The graphics adapter is Matrox G200e2 with 16MB RAM. Before Xen loading the console input works normally, btw. On the GRUB menu I can choose between entries. And when I boot up with either default or desktop profiled kernel the console stays on, fully functional. Just when I choose Xen kernel, the input disappears (the usb keyboard stops responding to NumLock) just after the ramdisk is loaded and screen blanks for a moment. Xen seems to recognize the right amount of RAM, though: #xm dmesg | grep -i 'system ram' (XEN) System RAM: 98237MB (100595124kB) Some other thing I noticed -- 'xm dmesg' output ends with: --- (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 232kB init memory. (XEN) physdev.c:172: dom0: wrong map_pirq type 3 --- And exept host console, everything else seems to work. I can even install and run guest vm-s without problems (though tested HVM and PVHVM guests so far). I do prefer standardized solutions of course, but modifying source and recompiling things is ok also, if only this would help. Janno > Hello Janno, > > First question, do you have SSH configured and can you access via SSH? > > Second, have you tried switching TTY consoles after the login screen > freezes? Is it possible it could just be the GUI and not the console? > Hotkeys like ctrl+alt+F# will switch you to various terminal consoles > which may allow you to at least gain access and try to debug locally. > > This may be a long shot, but what GUI are you using? Xen 4.1 had an > EFI bug for me where it would not recognize all available memory, and > Gnome3 (as an example) locks up with 512MB or less. > > If you can access the system via the alternative TTY or via SSH you > may be able to check using the xm or xl toolstacks `dmesg` and > searching for "System RAM". > > Unfortunately if that is the cause the only solution I am aware of > involves modifying the source and rebuilding, which is not at all > helpful if you are using packages. > > Hope these suggestions help with troubleshooting. > > ~Casey > > > On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide > wrote: > > Hello All! > > I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen > 4.1.3 install on an IBM x3550 server. The system is booted via EFI > with Grub2 bootloader and it boots up normally, either with or > without Xen. > But i have one trouble with it: I can't get console access working > with Xen. > > The strange thing is, despite the "WARNING: no console will be > available to OS" appearing during xen loading, the console > actually starts, the graphical login screen does even appear... > and then freezes. Just the console; the system iself continues to > run normally. > Booting the system up without xen leaves also the console working. > > Yet i do need this console: after some testing i have to implement > this new Suse/Xen install on a distant server (which has a > management module for remote console access) and I just can't risk > being blinded and cut off in case there will be some confusion > with network interfaces, for example. > > Some googling on this matter didn't give any help also. It did > reveal some opinions, though, suggesting that this console problem > is related to EFI.. but, unfortunately, nothing useful. > > > Can anyone please tell me if/how it's possible to get console > access with Xen 4.1.3 and EFI boot? And if not, what would be the > closest solution? Xen 4.2?, Xen 4.1.2?, ELILO? > > > With best regards, > Janno > > > _______________________________________________ > 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 --------------040508000907050903090809 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit
Hi Casey,

Fortunately, yes, I do have ssh access, and even vnc. So I can probably debug it in any possible way you'll recommend :)

But this is just my testing configuraton, laying on a desk next to me. Implementing that software on the remote production site is what makes me really worried.

I did try to switch TTYs, from the usb keyboard, without any result :( The keyboard, connected to usb port, doesn't even put any leds on, neither blinks when disconnecting/connecting after loading Xen. The system does recongize the keyboard, though:
---
kernel: [    4.510357] input: Lite-On Technology Corp. Lenovo Low Profile USB Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
...
kernel: [    4.517658] usbcore: registered new interface driver usbhid
Mar 19 17:54:58 linux-z01z kernel: [    4.517659] usbhid: USB HID core driver
---

The system has a remote management module with java-based remote console applet and that behaves exactly the same as the real console: Kdm login screen appears, the cursor blinks, but typing on a keyboard has no effect.


The graphics adapter is Matrox G200e2 with 16MB RAM.
Before Xen loading the console input works normally, btw. On the GRUB menu I can choose between entries. And when I boot up with either default or desktop profiled kernel the console stays on, fully functional. Just when I choose Xen kernel, the input disappears (the usb keyboard stops responding to NumLock) just after the ramdisk is loaded and screen blanks for a moment.


Xen seems to recognize the right amount of RAM, though:
#xm dmesg | grep -i 'system ram'
(XEN) System RAM: 98237MB (100595124kB)

Some other thing I noticed -- 'xm dmesg' output ends with:
---
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 232kB init memory.
(XEN) physdev.c:172: dom0: wrong map_pirq type 3
---

And exept host console, everything else seems to work. I can even install and run guest vm-s without problems (though tested HVM and PVHVM guests so far).

I do prefer standardized solutions of course, but modifying source and recompiling things is ok also, if only this would help.


Janno


Hello Janno,

First question, do you have SSH configured and can you access via SSH?

Second, have you tried switching TTY consoles after the login screen freezes?  Is it possible it could just be the GUI and not the console?  Hotkeys like ctrl+alt+F# will switch you to various terminal consoles which may allow you to at least gain access and try to debug locally.

This may be a long shot, but what GUI are you using?  Xen 4.1 had an EFI bug for me where it would not recognize all available memory, and Gnome3 (as an example) locks up with 512MB or less.

If you can access the system via the alternative TTY or via SSH you may be able to check using the xm or xl toolstacks `dmesg` and searching for "System RAM".

Unfortunately if that is the cause the only solution I am aware of involves modifying the source and rebuilding, which is not at all helpful if you are using packages.

Hope these suggestions help with troubleshooting.

~Casey


On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide <janno@kernel.ee> wrote:
Hello All!

    I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 install on an IBM x3550 server. The system is booted via EFI with Grub2 bootloader and it boots up normally, either with or without Xen.
But i have one trouble with it: I can't get console access working with Xen.

The strange thing is, despite the "WARNING: no console will be available to OS" appearing during xen loading, the console actually starts, the graphical login screen does even appear... and then freezes. Just the console; the system iself continues to run normally.
Booting the system up without xen leaves also the console working.

Yet i do need this console: after some testing i have to implement this new Suse/Xen install on a distant server (which has a management module for remote console access) and I just can't risk being blinded and cut off in case there will be some confusion with network interfaces, for example.

Some googling on this matter didn't give any help also. It did reveal some opinions, though, suggesting that this console problem is related to EFI.. but, unfortunately, nothing useful.


Can anyone please tell me if/how it's possible to get console access with Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen 4.2?, Xen 4.1.2?, ELILO?


With best regards,
    Janno


_______________________________________________
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

--------------040508000907050903090809-- --===============4237683972575960948== 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 --===============4237683972575960948==-- From xen-users-bounces@lists.xen.org Tue Mar 19 18:08:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 18:08: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 1UI0wZ-0005k2-N9; Tue, 19 Mar 2013 18:07:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI0wY-0005jx-3x for xen-users@lists.xen.org; Tue, 19 Mar 2013 18:07:26 +0000 Received: from [85.158.139.211:23443] by server-8.bemta-5.messagelabs.com id B9/13-05790-D59A8415; Tue, 19 Mar 2013 18:07:25 +0000 X-Env-Sender: janno@kodu.ee X-Msg-Ref: server-3.tower-206.messagelabs.com!1363716443!19011751!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24696 invoked from network); 19 Mar 2013 18:07:23 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-3.tower-206.messagelabs.com with SMTP; 19 Mar 2013 18:07:23 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id 819781C2F4 for ; Tue, 19 Mar 2013 20:07:22 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id E8_YYmxuEVaw for ; Tue, 19 Mar 2013 20:07:19 +0200 (EET) Received: from [192.168.45.25] (km.kernel.ee [80.250.116.5]) by asum.kodu.ee (Postfix) with ESMTPSA id 7579A1C2E0 for ; Tue, 19 Mar 2013 20:07:19 +0200 (EET) Message-ID: <5148A957.6010204@kodu.ee> Date: Tue, 19 Mar 2013 20:07:19 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5148589D.4020307@kernel.ee> In-Reply-To: Subject: Re: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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="===============4237683972575960948==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============4237683972575960948== Content-Type: multipart/alternative; boundary="------------040508000907050903090809" This is a multi-part message in MIME format. --------------040508000907050903090809 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi Casey, Fortunately, yes, I do have ssh access, and even vnc. So I can probably debug it in any possible way you'll recommend :) But this is just my testing configuraton, laying on a desk next to me. Implementing that software on the remote production site is what makes me really worried. I did try to switch TTYs, from the usb keyboard, without any result :( The keyboard, connected to usb port, doesn't even put any leds on, neither blinks when disconnecting/connecting after loading Xen. The system does recongize the keyboard, though: --- kernel: [ 4.510357] input: Lite-On Technology Corp. Lenovo Low Profile USB Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input1 ... kernel: [ 4.517658] usbcore: registered new interface driver usbhid Mar 19 17:54:58 linux-z01z kernel: [ 4.517659] usbhid: USB HID core driver --- The system has a remote management module with java-based remote console applet and that behaves exactly the same as the real console: Kdm login screen appears, the cursor blinks, but typing on a keyboard has no effect. The graphics adapter is Matrox G200e2 with 16MB RAM. Before Xen loading the console input works normally, btw. On the GRUB menu I can choose between entries. And when I boot up with either default or desktop profiled kernel the console stays on, fully functional. Just when I choose Xen kernel, the input disappears (the usb keyboard stops responding to NumLock) just after the ramdisk is loaded and screen blanks for a moment. Xen seems to recognize the right amount of RAM, though: #xm dmesg | grep -i 'system ram' (XEN) System RAM: 98237MB (100595124kB) Some other thing I noticed -- 'xm dmesg' output ends with: --- (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 232kB init memory. (XEN) physdev.c:172: dom0: wrong map_pirq type 3 --- And exept host console, everything else seems to work. I can even install and run guest vm-s without problems (though tested HVM and PVHVM guests so far). I do prefer standardized solutions of course, but modifying source and recompiling things is ok also, if only this would help. Janno > Hello Janno, > > First question, do you have SSH configured and can you access via SSH? > > Second, have you tried switching TTY consoles after the login screen > freezes? Is it possible it could just be the GUI and not the console? > Hotkeys like ctrl+alt+F# will switch you to various terminal consoles > which may allow you to at least gain access and try to debug locally. > > This may be a long shot, but what GUI are you using? Xen 4.1 had an > EFI bug for me where it would not recognize all available memory, and > Gnome3 (as an example) locks up with 512MB or less. > > If you can access the system via the alternative TTY or via SSH you > may be able to check using the xm or xl toolstacks `dmesg` and > searching for "System RAM". > > Unfortunately if that is the cause the only solution I am aware of > involves modifying the source and rebuilding, which is not at all > helpful if you are using packages. > > Hope these suggestions help with troubleshooting. > > ~Casey > > > On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide > wrote: > > Hello All! > > I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen > 4.1.3 install on an IBM x3550 server. The system is booted via EFI > with Grub2 bootloader and it boots up normally, either with or > without Xen. > But i have one trouble with it: I can't get console access working > with Xen. > > The strange thing is, despite the "WARNING: no console will be > available to OS" appearing during xen loading, the console > actually starts, the graphical login screen does even appear... > and then freezes. Just the console; the system iself continues to > run normally. > Booting the system up without xen leaves also the console working. > > Yet i do need this console: after some testing i have to implement > this new Suse/Xen install on a distant server (which has a > management module for remote console access) and I just can't risk > being blinded and cut off in case there will be some confusion > with network interfaces, for example. > > Some googling on this matter didn't give any help also. It did > reveal some opinions, though, suggesting that this console problem > is related to EFI.. but, unfortunately, nothing useful. > > > Can anyone please tell me if/how it's possible to get console > access with Xen 4.1.3 and EFI boot? And if not, what would be the > closest solution? Xen 4.2?, Xen 4.1.2?, ELILO? > > > With best regards, > Janno > > > _______________________________________________ > 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 --------------040508000907050903090809 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit
Hi Casey,

Fortunately, yes, I do have ssh access, and even vnc. So I can probably debug it in any possible way you'll recommend :)

But this is just my testing configuraton, laying on a desk next to me. Implementing that software on the remote production site is what makes me really worried.

I did try to switch TTYs, from the usb keyboard, without any result :( The keyboard, connected to usb port, doesn't even put any leds on, neither blinks when disconnecting/connecting after loading Xen. The system does recongize the keyboard, though:
---
kernel: [    4.510357] input: Lite-On Technology Corp. Lenovo Low Profile USB Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
...
kernel: [    4.517658] usbcore: registered new interface driver usbhid
Mar 19 17:54:58 linux-z01z kernel: [    4.517659] usbhid: USB HID core driver
---

The system has a remote management module with java-based remote console applet and that behaves exactly the same as the real console: Kdm login screen appears, the cursor blinks, but typing on a keyboard has no effect.


The graphics adapter is Matrox G200e2 with 16MB RAM.
Before Xen loading the console input works normally, btw. On the GRUB menu I can choose between entries. And when I boot up with either default or desktop profiled kernel the console stays on, fully functional. Just when I choose Xen kernel, the input disappears (the usb keyboard stops responding to NumLock) just after the ramdisk is loaded and screen blanks for a moment.


Xen seems to recognize the right amount of RAM, though:
#xm dmesg | grep -i 'system ram'
(XEN) System RAM: 98237MB (100595124kB)

Some other thing I noticed -- 'xm dmesg' output ends with:
---
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 232kB init memory.
(XEN) physdev.c:172: dom0: wrong map_pirq type 3
---

And exept host console, everything else seems to work. I can even install and run guest vm-s without problems (though tested HVM and PVHVM guests so far).

I do prefer standardized solutions of course, but modifying source and recompiling things is ok also, if only this would help.


Janno


Hello Janno,

First question, do you have SSH configured and can you access via SSH?

Second, have you tried switching TTY consoles after the login screen freezes?  Is it possible it could just be the GUI and not the console?  Hotkeys like ctrl+alt+F# will switch you to various terminal consoles which may allow you to at least gain access and try to debug locally.

This may be a long shot, but what GUI are you using?  Xen 4.1 had an EFI bug for me where it would not recognize all available memory, and Gnome3 (as an example) locks up with 512MB or less.

If you can access the system via the alternative TTY or via SSH you may be able to check using the xm or xl toolstacks `dmesg` and searching for "System RAM".

Unfortunately if that is the cause the only solution I am aware of involves modifying the source and rebuilding, which is not at all helpful if you are using packages.

Hope these suggestions help with troubleshooting.

~Casey


On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide <janno@kernel.ee> wrote:
Hello All!

    I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 install on an IBM x3550 server. The system is booted via EFI with Grub2 bootloader and it boots up normally, either with or without Xen.
But i have one trouble with it: I can't get console access working with Xen.

The strange thing is, despite the "WARNING: no console will be available to OS" appearing during xen loading, the console actually starts, the graphical login screen does even appear... and then freezes. Just the console; the system iself continues to run normally.
Booting the system up without xen leaves also the console working.

Yet i do need this console: after some testing i have to implement this new Suse/Xen install on a distant server (which has a management module for remote console access) and I just can't risk being blinded and cut off in case there will be some confusion with network interfaces, for example.

Some googling on this matter didn't give any help also. It did reveal some opinions, though, suggesting that this console problem is related to EFI.. but, unfortunately, nothing useful.


Can anyone please tell me if/how it's possible to get console access with Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen 4.2?, Xen 4.1.2?, ELILO?


With best regards,
    Janno


_______________________________________________
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

--------------040508000907050903090809-- --===============4237683972575960948== 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 --===============4237683972575960948==-- From xen-users-bounces@lists.xen.org Tue Mar 19 19:54:05 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 19:54:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI2ac-0007Pt-R6; Tue, 19 Mar 2013 19:52:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI2ab-0007Po-Oa for xen-users@lists.xen.org; Tue, 19 Mar 2013 19:52:54 +0000 Received: from [85.158.139.211:16718] by server-14.bemta-5.messagelabs.com id 87/94-13158-412C8415; Tue, 19 Mar 2013 19:52:52 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1363722770!19024765!1 X-Originating-IP: [209.85.220.180] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23925 invoked from network); 19 Mar 2013 19:52:51 -0000 Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com) (209.85.220.180) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 19:52:51 -0000 Received: by mail-vc0-f180.google.com with SMTP id m17so719791vca.39 for ; Tue, 19 Mar 2013 12:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KozVun8ZGCmpaZMOLAwr4+hwTkWmY/2CI3BglSa+vzE=; b=yrn3NfkspsIWY3LFKAXBXd+d2hEMvbPsWVROOM88mI74jOL3iPR8WLa3j/u2nDuCKB qsnQ9MAP2v8MYzXTcJbbLeQRX2iXv0XSjOHPBJjhuKy0nRlHP3ZW+wOS5XjE7s8RJD3W tMKt6UHstQnHrxk4YgSeTwFTNlS+QMlGKyVULI5cuXxR+qvaZpmm+YkfW+m/ql5LzN8l 9Uz89qhbF9jEG/i2VjSD0d0tfeX4YdcpiThDgV8GyntQrO1VJIPlxNgHXAcK4jEwkI/d rNjhgs/36K1Wid5oSf3MIw4iw8fG9gQWSn1UnmgC3lb4/Z30KmEz5acKzu9TleHtXqwf NR9Q== MIME-Version: 1.0 X-Received: by 10.52.90.211 with SMTP id by19mr3577831vdb.114.1363722769785; Tue, 19 Mar 2013 12:52:49 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Tue, 19 Mar 2013 12:52:49 -0700 (PDT) In-Reply-To: <5148A957.6010204@kodu.ee> References: <5148589D.4020307@kernel.ee> <5148A957.6010204@kodu.ee> Date: Tue, 19 Mar 2013 15:52:49 -0400 Message-ID: From: Casey DeLorme To: Janno Loide Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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="===============0144785630301395461==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0144785630301395461== Content-Type: multipart/alternative; boundary=20cf307d063043ed7604d84c735c --20cf307d063043ed7604d84c735c Content-Type: text/plain; charset=UTF-8 Good news is if Xen recognizes all your memory the patch I mentioned is unrelated and I can think of no reason to modify the source. However that brings us back to the console not accepting input. --- Based on what you've said, the KDM login is not frozen (cursor is actively blinking?), but the input is not in the right place somehow. If I am understanding this right, the Java applet sits between the real VGA output and the Matrox adapter, as a layer? If so maybe some connection is belong list in transit when Xen hands VGA over to the Dom0. >From the tail you posted the only line not in my xl dmesg is this one: (XEN) physdev.c:172: dom0: wrong map_pirq type 3 Google only has a series of unrelated links, a wide range of Dom0's and generally paravirtualization questions, so possibly an unrelated error. --- Here are some questions and tests you can try: Does your VNC connection take you strait to the same KDM login or a new one? If it is the same one can you watch it change from the matrox adapter while using it? Can you kill the KDM instance from SSH? Does it return you to terminal, and does the keyboard work after? Can you unplug and reconnect the USB keyboard, and when you do what does `tail /var/log/messages` contain? Does the VNC run through the Java applet as well? Finally, is there any configuration options for the Java applet? Because if it is a layer then I am guessing something is happening at that stage of the system. The only other thoughts I have at the moment are whether the grub.cfg contains any special configuration settings that are different than the Xen version or that might be related to the Java applet. On Tue, Mar 19, 2013 at 2:07 PM, Janno Loide wrote: > Hi Casey, > > Fortunately, yes, I do have ssh access, and even vnc. So I can probably > debug it in any possible way you'll recommend :) > > But this is just my testing configuraton, laying on a desk next to me. > Implementing that software on the remote production site is what makes me > really worried. > > I did try to switch TTYs, from the usb keyboard, without any result :( The > keyboard, connected to usb port, doesn't even put any leds on, neither > blinks when disconnecting/connecting after loading Xen. The system does > recongize the keyboard, though: > --- > kernel: [ 4.510357] input: Lite-On Technology Corp. Lenovo Low Profile > USB Keyboard as > /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input1 > ... > kernel: [ 4.517658] usbcore: registered new interface driver usbhid > Mar 19 17:54:58 linux-z01z kernel: [ 4.517659] usbhid: USB HID core > driver > --- > > The system has a remote management module with java-based remote console > applet and that behaves exactly the same as the real console: Kdm login > screen appears, the cursor blinks, but typing on a keyboard has no effect. > > > The graphics adapter is Matrox G200e2 with 16MB RAM. > Before Xen loading the console input works normally, btw. On the GRUB menu > I can choose between entries. And when I boot up with either default or > desktop profiled kernel the console stays on, fully functional. Just when I > choose Xen kernel, the input disappears (the usb keyboard stops responding > to NumLock) just after the ramdisk is loaded and screen blanks for a moment. > > > Xen seems to recognize the right amount of RAM, though: > #xm dmesg | grep -i 'system ram' > (XEN) System RAM: 98237MB (100595124kB) > > Some other thing I noticed -- 'xm dmesg' output ends with: > --- > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input > to Xen) > (XEN) Freed 232kB init memory. > (XEN) physdev.c:172: dom0: wrong map_pirq type 3 > --- > > And exept host console, everything else seems to work. I can even install > and run guest vm-s without problems (though tested HVM and PVHVM guests so > far). > > I do prefer standardized solutions of course, but modifying source and > recompiling things is ok also, if only this would help. > > > Janno > > > Hello Janno, > > First question, do you have SSH configured and can you access via SSH? > > Second, have you tried switching TTY consoles after the login screen > freezes? Is it possible it could just be the GUI and not the console? > Hotkeys like ctrl+alt+F# will switch you to various terminal consoles > which may allow you to at least gain access and try to debug locally. > > This may be a long shot, but what GUI are you using? Xen 4.1 had an EFI > bug for me where it would not recognize all available memory, and Gnome3 > (as an example) locks up with 512MB or less. > > If you can access the system via the alternative TTY or via SSH you may > be able to check using the xm or xl toolstacks `dmesg` and searching for > "System RAM". > > Unfortunately if that is the cause the only solution I am aware of > involves modifying the source and rebuilding, which is not at all helpful > if you are using packages. > > Hope these suggestions help with troubleshooting. > > ~Casey > > > On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide wrote: > >> Hello All! >> >> I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 >> install on an IBM x3550 server. The system is booted via EFI with Grub2 >> bootloader and it boots up normally, either with or without Xen. >> But i have one trouble with it: I can't get console access working with >> Xen. >> >> The strange thing is, despite the "WARNING: no console will be available >> to OS" appearing during xen loading, the console actually starts, the >> graphical login screen does even appear... and then freezes. Just the >> console; the system iself continues to run normally. >> Booting the system up without xen leaves also the console working. >> >> Yet i do need this console: after some testing i have to implement this >> new Suse/Xen install on a distant server (which has a management module for >> remote console access) and I just can't risk being blinded and cut off in >> case there will be some confusion with network interfaces, for example. >> >> Some googling on this matter didn't give any help also. It did reveal >> some opinions, though, suggesting that this console problem is related to >> EFI.. but, unfortunately, nothing useful. >> >> >> Can anyone please tell me if/how it's possible to get console access with >> Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen >> 4.2?, Xen 4.1.2?, ELILO? >> >> >> With best regards, >> Janno >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users >> > > > > _______________________________________________ > Xen-users mailing listXen-users@lists.xen.orghttp://lists.xen.org/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --20cf307d063043ed7604d84c735c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good news is if Xen recognizes all your memory the pa= tch I mentioned is unrelated and I can think of no reason to modify the sou= rce. =C2=A0However that brings us back to the console not accepting input.<= /div>

---

Based on what you've s= aid, the KDM login is not frozen (cursor is actively blinking?), but the in= put is not in the right place somehow.

If I am und= erstanding this right, the Java applet sits between the real VGA output and= the Matrox adapter, as a layer? =C2=A0If so maybe some connection is belon= g list in transit when Xen hands VGA over to the Dom0.

From the tail you posted the only line not in my xl dme= sg is this one:

(XEN) physdev.c:172: dom0: wrong map_pirq type 3

Google only has a series of unrelated links, a wide range of= Dom0's and generally paravirtualization questions, so possibly an unre= lated error.

---

Here are= some questions and tests you can try:

Does your VNC connection take you strait to the same KD= M login or a new one? =C2=A0If it is the same one can you watch it change f= rom the matrox adapter while using it?

Can you kil= l the KDM instance from SSH? =C2=A0Does it return you to terminal, and does= the keyboard work after?

Can you unplug and reconnect the USB keyboard, and when= you do what does `tail /var/log/messages` contain?

Does the VNC run through the Java applet as well?

Finally, is there any configuration options for the Java applet? =C2= =A0Because if it is a layer then I am guessing something is happening at th= at stage of the system.

The only other thoughts I = have at the moment are whether the grub.cfg contains any special configurat= ion settings that are different than the Xen version or that might be relat= ed to the Java applet.



On Tue, Mar 19, 2013 at 2:07 PM, Janno Loide <= janno@kodu.ee> wrote:
=20 =20 =20
Hi Casey,

Fortunately, yes, I do have ssh access, and even vnc. So I can probably debug it in any possible way you'll recommend :)

But this is just my testing configuraton, laying on a desk next to me. Implementing that software on the remote production site is what makes me really worried.

I did try to switch TTYs, from the usb keyboard, without any result :( The keyboard, connected to usb port, doesn't even put any leds on, neither blinks when disconnecting/connecting after loading Xen. The system does recongize the keyboard, though:
---
kernel: [=C2=A0=C2=A0=C2=A0 4.510357] input: Lite-On Technology Corp.= Lenovo Low Profile USB Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input= 1
...
kernel: [=C2=A0=C2=A0=C2=A0 4.517658] usbcore: registered new interfa= ce driver usbhid
Mar 19 17:54:58 linux-z01z kernel: [=C2=A0=C2=A0=C2=A0 4.517659] usbh= id: USB HID core driver
---

The system has a remote management module with java-based remote console applet and that behaves exactly the same as the real console: Kdm login screen appears, the cursor blinks, but typing on a keyboard has no effect.


The graphics adapter is Matrox G200e2 with 16MB RAM.
Before Xen loading the console input works normally, btw. On the GRUB menu I can choose between entries. And when I boot up with either default or desktop profiled kernel the console stays on, fully functional. Just when I choose Xen kernel, the input disappears (the usb keyboard stops responding to NumLock) just after the ramdisk is loaded and screen blanks for a moment.


Xen seems to recognize the right amount of RAM, though:
#xm dmesg | grep -i 'system ram'
(XEN) System RAM: 98237MB (100595124kB)

Some other thing I noticed -- 'xm dmesg' output ends with: ---
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times = to switch input to Xen)
(XEN) Freed 232kB init memory.
(XEN) physdev.c:172: dom0: wrong map_pirq type 3
---

And exept host console, everything else seems to work. I can even install and run guest vm-s without problems (though tested HVM and PVHVM guests so far).

I do prefer standardized solutions of course, but modifying source and recompiling things is ok also, if only this would help.


Janno


Hello Janno,

First question, do you have SSH configured and can you access via SSH?

Second, have you tried switching TTY consoles after the login screen freezes? =C2=A0Is it possible it could just be the G= UI and not the console? =C2=A0Hotkeys like ctrl+alt+F# will switch y= ou to various terminal consoles which may allow you to at least gain access and try to debug locally.

This may be a long shot, but what GUI are you using? =C2=A0Xen 4.1 had an EFI bug for me where it would not recognize all available memory, and Gnome3 (as an example) locks up with 512MB or less.

If you can access the system via the alternative TTY or via SSH you may be able to check using the xm or xl toolstacks `dmesg` and searching for "System RAM".

Unfortunately if that is the cause the only solution I am aware of involves modifying the source and rebuilding, which is not at all helpful if you are using packages.

Hope these suggestions help with troubleshooting.

~Casey


On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide <janno@kernel.ee> wrote:
Hello All!

=C2=A0 =C2=A0 I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen = kernel) + Xen 4.1.3 install on an IBM x3550 server. The system is booted via EFI with Grub2 bootloader and it boots up normally, either with or without Xen.
But i have one trouble with it: I can't get console access working with Xen.

The strange thing is, despite the "WARNING: no console wil= l be available to OS" appearing during xen loading, the console actually starts, the graphical login screen does even appear... and then freezes. Just the console; the system iself continues to run normally.
Booting the system up without xen leaves also the console working.

Yet i do need this console: after some testing i have to implement this new Suse/Xen install on a distant server (which has a management module for remote console access) and I just can't risk being blinded and cut off in case there will be some confusion with network interfaces, for example.

Some googling on this matter didn't give any help also. It did reveal some opinions, though, suggesting that this console problem is related to EFI.. but, unfortunately, nothing useful.


Can anyone please tell me if/how it's possible to get console access with Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen 4.2?, Xen 4.1.2?, ELILO?


With best regards,
=C2=A0 =C2=A0 Janno


_______________________________________________
Xen-users mailing list
Xe= n-users@lists.xen.org
ht= tp://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@list=
s.xen.org
http://lists.x=
en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--20cf307d063043ed7604d84c735c-- --===============0144785630301395461== 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 --===============0144785630301395461==-- From xen-users-bounces@lists.xen.org Tue Mar 19 19:54:05 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 19:54:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI2ac-0007Pt-R6; Tue, 19 Mar 2013 19:52:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI2ab-0007Po-Oa for xen-users@lists.xen.org; Tue, 19 Mar 2013 19:52:54 +0000 Received: from [85.158.139.211:16718] by server-14.bemta-5.messagelabs.com id 87/94-13158-412C8415; Tue, 19 Mar 2013 19:52:52 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1363722770!19024765!1 X-Originating-IP: [209.85.220.180] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23925 invoked from network); 19 Mar 2013 19:52:51 -0000 Received: from mail-vc0-f180.google.com (HELO mail-vc0-f180.google.com) (209.85.220.180) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 19:52:51 -0000 Received: by mail-vc0-f180.google.com with SMTP id m17so719791vca.39 for ; Tue, 19 Mar 2013 12:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KozVun8ZGCmpaZMOLAwr4+hwTkWmY/2CI3BglSa+vzE=; b=yrn3NfkspsIWY3LFKAXBXd+d2hEMvbPsWVROOM88mI74jOL3iPR8WLa3j/u2nDuCKB qsnQ9MAP2v8MYzXTcJbbLeQRX2iXv0XSjOHPBJjhuKy0nRlHP3ZW+wOS5XjE7s8RJD3W tMKt6UHstQnHrxk4YgSeTwFTNlS+QMlGKyVULI5cuXxR+qvaZpmm+YkfW+m/ql5LzN8l 9Uz89qhbF9jEG/i2VjSD0d0tfeX4YdcpiThDgV8GyntQrO1VJIPlxNgHXAcK4jEwkI/d rNjhgs/36K1Wid5oSf3MIw4iw8fG9gQWSn1UnmgC3lb4/Z30KmEz5acKzu9TleHtXqwf NR9Q== MIME-Version: 1.0 X-Received: by 10.52.90.211 with SMTP id by19mr3577831vdb.114.1363722769785; Tue, 19 Mar 2013 12:52:49 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Tue, 19 Mar 2013 12:52:49 -0700 (PDT) In-Reply-To: <5148A957.6010204@kodu.ee> References: <5148589D.4020307@kernel.ee> <5148A957.6010204@kodu.ee> Date: Tue, 19 Mar 2013 15:52:49 -0400 Message-ID: From: Casey DeLorme To: Janno Loide Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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="===============0144785630301395461==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0144785630301395461== Content-Type: multipart/alternative; boundary=20cf307d063043ed7604d84c735c --20cf307d063043ed7604d84c735c Content-Type: text/plain; charset=UTF-8 Good news is if Xen recognizes all your memory the patch I mentioned is unrelated and I can think of no reason to modify the source. However that brings us back to the console not accepting input. --- Based on what you've said, the KDM login is not frozen (cursor is actively blinking?), but the input is not in the right place somehow. If I am understanding this right, the Java applet sits between the real VGA output and the Matrox adapter, as a layer? If so maybe some connection is belong list in transit when Xen hands VGA over to the Dom0. >From the tail you posted the only line not in my xl dmesg is this one: (XEN) physdev.c:172: dom0: wrong map_pirq type 3 Google only has a series of unrelated links, a wide range of Dom0's and generally paravirtualization questions, so possibly an unrelated error. --- Here are some questions and tests you can try: Does your VNC connection take you strait to the same KDM login or a new one? If it is the same one can you watch it change from the matrox adapter while using it? Can you kill the KDM instance from SSH? Does it return you to terminal, and does the keyboard work after? Can you unplug and reconnect the USB keyboard, and when you do what does `tail /var/log/messages` contain? Does the VNC run through the Java applet as well? Finally, is there any configuration options for the Java applet? Because if it is a layer then I am guessing something is happening at that stage of the system. The only other thoughts I have at the moment are whether the grub.cfg contains any special configuration settings that are different than the Xen version or that might be related to the Java applet. On Tue, Mar 19, 2013 at 2:07 PM, Janno Loide wrote: > Hi Casey, > > Fortunately, yes, I do have ssh access, and even vnc. So I can probably > debug it in any possible way you'll recommend :) > > But this is just my testing configuraton, laying on a desk next to me. > Implementing that software on the remote production site is what makes me > really worried. > > I did try to switch TTYs, from the usb keyboard, without any result :( The > keyboard, connected to usb port, doesn't even put any leds on, neither > blinks when disconnecting/connecting after loading Xen. The system does > recongize the keyboard, though: > --- > kernel: [ 4.510357] input: Lite-On Technology Corp. Lenovo Low Profile > USB Keyboard as > /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input1 > ... > kernel: [ 4.517658] usbcore: registered new interface driver usbhid > Mar 19 17:54:58 linux-z01z kernel: [ 4.517659] usbhid: USB HID core > driver > --- > > The system has a remote management module with java-based remote console > applet and that behaves exactly the same as the real console: Kdm login > screen appears, the cursor blinks, but typing on a keyboard has no effect. > > > The graphics adapter is Matrox G200e2 with 16MB RAM. > Before Xen loading the console input works normally, btw. On the GRUB menu > I can choose between entries. And when I boot up with either default or > desktop profiled kernel the console stays on, fully functional. Just when I > choose Xen kernel, the input disappears (the usb keyboard stops responding > to NumLock) just after the ramdisk is loaded and screen blanks for a moment. > > > Xen seems to recognize the right amount of RAM, though: > #xm dmesg | grep -i 'system ram' > (XEN) System RAM: 98237MB (100595124kB) > > Some other thing I noticed -- 'xm dmesg' output ends with: > --- > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input > to Xen) > (XEN) Freed 232kB init memory. > (XEN) physdev.c:172: dom0: wrong map_pirq type 3 > --- > > And exept host console, everything else seems to work. I can even install > and run guest vm-s without problems (though tested HVM and PVHVM guests so > far). > > I do prefer standardized solutions of course, but modifying source and > recompiling things is ok also, if only this would help. > > > Janno > > > Hello Janno, > > First question, do you have SSH configured and can you access via SSH? > > Second, have you tried switching TTY consoles after the login screen > freezes? Is it possible it could just be the GUI and not the console? > Hotkeys like ctrl+alt+F# will switch you to various terminal consoles > which may allow you to at least gain access and try to debug locally. > > This may be a long shot, but what GUI are you using? Xen 4.1 had an EFI > bug for me where it would not recognize all available memory, and Gnome3 > (as an example) locks up with 512MB or less. > > If you can access the system via the alternative TTY or via SSH you may > be able to check using the xm or xl toolstacks `dmesg` and searching for > "System RAM". > > Unfortunately if that is the cause the only solution I am aware of > involves modifying the source and rebuilding, which is not at all helpful > if you are using packages. > > Hope these suggestions help with troubleshooting. > > ~Casey > > > On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide wrote: > >> Hello All! >> >> I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen kernel) + Xen 4.1.3 >> install on an IBM x3550 server. The system is booted via EFI with Grub2 >> bootloader and it boots up normally, either with or without Xen. >> But i have one trouble with it: I can't get console access working with >> Xen. >> >> The strange thing is, despite the "WARNING: no console will be available >> to OS" appearing during xen loading, the console actually starts, the >> graphical login screen does even appear... and then freezes. Just the >> console; the system iself continues to run normally. >> Booting the system up without xen leaves also the console working. >> >> Yet i do need this console: after some testing i have to implement this >> new Suse/Xen install on a distant server (which has a management module for >> remote console access) and I just can't risk being blinded and cut off in >> case there will be some confusion with network interfaces, for example. >> >> Some googling on this matter didn't give any help also. It did reveal >> some opinions, though, suggesting that this console problem is related to >> EFI.. but, unfortunately, nothing useful. >> >> >> Can anyone please tell me if/how it's possible to get console access with >> Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen >> 4.2?, Xen 4.1.2?, ELILO? >> >> >> With best regards, >> Janno >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users >> > > > > _______________________________________________ > Xen-users mailing listXen-users@lists.xen.orghttp://lists.xen.org/xen-users > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --20cf307d063043ed7604d84c735c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good news is if Xen recognizes all your memory the pa= tch I mentioned is unrelated and I can think of no reason to modify the sou= rce. =C2=A0However that brings us back to the console not accepting input.<= /div>

---

Based on what you've s= aid, the KDM login is not frozen (cursor is actively blinking?), but the in= put is not in the right place somehow.

If I am und= erstanding this right, the Java applet sits between the real VGA output and= the Matrox adapter, as a layer? =C2=A0If so maybe some connection is belon= g list in transit when Xen hands VGA over to the Dom0.

From the tail you posted the only line not in my xl dme= sg is this one:

(XEN) physdev.c:172: dom0: wrong map_pirq type 3

Google only has a series of unrelated links, a wide range of= Dom0's and generally paravirtualization questions, so possibly an unre= lated error.

---

Here are= some questions and tests you can try:

Does your VNC connection take you strait to the same KD= M login or a new one? =C2=A0If it is the same one can you watch it change f= rom the matrox adapter while using it?

Can you kil= l the KDM instance from SSH? =C2=A0Does it return you to terminal, and does= the keyboard work after?

Can you unplug and reconnect the USB keyboard, and when= you do what does `tail /var/log/messages` contain?

Does the VNC run through the Java applet as well?

Finally, is there any configuration options for the Java applet? =C2= =A0Because if it is a layer then I am guessing something is happening at th= at stage of the system.

The only other thoughts I = have at the moment are whether the grub.cfg contains any special configurat= ion settings that are different than the Xen version or that might be relat= ed to the Java applet.



On Tue, Mar 19, 2013 at 2:07 PM, Janno Loide <= janno@kodu.ee> wrote:
=20 =20 =20
Hi Casey,

Fortunately, yes, I do have ssh access, and even vnc. So I can probably debug it in any possible way you'll recommend :)

But this is just my testing configuraton, laying on a desk next to me. Implementing that software on the remote production site is what makes me really worried.

I did try to switch TTYs, from the usb keyboard, without any result :( The keyboard, connected to usb port, doesn't even put any leds on, neither blinks when disconnecting/connecting after loading Xen. The system does recongize the keyboard, though:
---
kernel: [=C2=A0=C2=A0=C2=A0 4.510357] input: Lite-On Technology Corp.= Lenovo Low Profile USB Keyboard as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input= 1
...
kernel: [=C2=A0=C2=A0=C2=A0 4.517658] usbcore: registered new interfa= ce driver usbhid
Mar 19 17:54:58 linux-z01z kernel: [=C2=A0=C2=A0=C2=A0 4.517659] usbh= id: USB HID core driver
---

The system has a remote management module with java-based remote console applet and that behaves exactly the same as the real console: Kdm login screen appears, the cursor blinks, but typing on a keyboard has no effect.


The graphics adapter is Matrox G200e2 with 16MB RAM.
Before Xen loading the console input works normally, btw. On the GRUB menu I can choose between entries. And when I boot up with either default or desktop profiled kernel the console stays on, fully functional. Just when I choose Xen kernel, the input disappears (the usb keyboard stops responding to NumLock) just after the ramdisk is loaded and screen blanks for a moment.


Xen seems to recognize the right amount of RAM, though:
#xm dmesg | grep -i 'system ram'
(XEN) System RAM: 98237MB (100595124kB)

Some other thing I noticed -- 'xm dmesg' output ends with: ---
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times = to switch input to Xen)
(XEN) Freed 232kB init memory.
(XEN) physdev.c:172: dom0: wrong map_pirq type 3
---

And exept host console, everything else seems to work. I can even install and run guest vm-s without problems (though tested HVM and PVHVM guests so far).

I do prefer standardized solutions of course, but modifying source and recompiling things is ok also, if only this would help.


Janno


Hello Janno,

First question, do you have SSH configured and can you access via SSH?

Second, have you tried switching TTY consoles after the login screen freezes? =C2=A0Is it possible it could just be the G= UI and not the console? =C2=A0Hotkeys like ctrl+alt+F# will switch y= ou to various terminal consoles which may allow you to at least gain access and try to debug locally.

This may be a long shot, but what GUI are you using? =C2=A0Xen 4.1 had an EFI bug for me where it would not recognize all available memory, and Gnome3 (as an example) locks up with 512MB or less.

If you can access the system via the alternative TTY or via SSH you may be able to check using the xm or xl toolstacks `dmesg` and searching for "System RAM".

Unfortunately if that is the cause the only solution I am aware of involves modifying the source and rebuilding, which is not at all helpful if you are using packages.

Hope these suggestions help with troubleshooting.

~Casey


On Tue, Mar 19, 2013 at 8:22 AM, Janno Loide <janno@kernel.ee> wrote:
Hello All!

=C2=A0 =C2=A0 I have a new OpenSuse 12.2 (with 3.4.33-2.24-xen = kernel) + Xen 4.1.3 install on an IBM x3550 server. The system is booted via EFI with Grub2 bootloader and it boots up normally, either with or without Xen.
But i have one trouble with it: I can't get console access working with Xen.

The strange thing is, despite the "WARNING: no console wil= l be available to OS" appearing during xen loading, the console actually starts, the graphical login screen does even appear... and then freezes. Just the console; the system iself continues to run normally.
Booting the system up without xen leaves also the console working.

Yet i do need this console: after some testing i have to implement this new Suse/Xen install on a distant server (which has a management module for remote console access) and I just can't risk being blinded and cut off in case there will be some confusion with network interfaces, for example.

Some googling on this matter didn't give any help also. It did reveal some opinions, though, suggesting that this console problem is related to EFI.. but, unfortunately, nothing useful.


Can anyone please tell me if/how it's possible to get console access with Xen 4.1.3 and EFI boot? And if not, what would be the closest solution? Xen 4.2?, Xen 4.1.2?, ELILO?


With best regards,
=C2=A0 =C2=A0 Janno


_______________________________________________
Xen-users mailing list
Xe= n-users@lists.xen.org
ht= tp://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@list=
s.xen.org
http://lists.x=
en.org/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--20cf307d063043ed7604d84c735c-- --===============0144785630301395461== 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 --===============0144785630301395461==-- From xen-users-bounces@lists.xen.org Tue Mar 19 22:09:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 22:09: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 1UI4hz-0004XJ-Vp; Tue, 19 Mar 2013 22:08:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI4dR-0004WL-Q7 for xen-users@lists.xen.org; Tue, 19 Mar 2013 22:03:58 +0000 Received: from [85.158.138.51:52067] by server-12.bemta-3.messagelabs.com id 42/45-01357-DC0E8415; Tue, 19 Mar 2013 22:03:57 +0000 X-Env-Sender: john@clustered.net X-Msg-Ref: server-16.tower-174.messagelabs.com!1363730636!28279337!1 X-Originating-IP: [193.227.111.2] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26841 invoked from network); 19 Mar 2013 22:03:56 -0000 Received: from mail1.clustered.net (HELO clients.clustered.net) (193.227.111.2) by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2013 22:03:56 -0000 Received: from [10.1.254.2] by clients.clustered.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1UI4dF-00018C-KU; Tue, 19 Mar 2013 22:03:45 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Morrison In-Reply-To: <20130319090719.GF11334@vrvis.at> Date: Tue, 19 Mar 2013 22:03:44 +0000 Message-Id: References: <20130319090719.GF11334@vrvis.at> To: Adi Kriegisch X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Tue, 19 Mar 2013 22:08:39 +0000 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Disk iops performance scalability X-BeenThere: xen-users@lists.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, It was a typo in the config file (cpus=) that caused the drop in iops. Now I get 145k consistently. The other issue still remains, very low ioping output, especially as the first comes back in 1ms then the rest take 6 times as long Thanks John On 19 Mar 2013, at 09:07, Adi Kriegisch wrote: > Hi! > >> Seeing a drop-off in iops when more vcpu's are added:- >> >> 3.8.2 kernel/xen-4.2.1/single domU/LVM backend/8GB RAM domU/2GB RAM dom0 >> >> dom0_max_vcpus=2 dom0_vcpus_pin >> >> domU 8 cores fio result 145k iops > [...] >> domU 14 cores fio result 81k iops > [...] >> The initial ioping response is good, then a lot of latency with later ones. Any ideas ? > There are several possible optimizations: > * At first I'd try to set the I/O-Scheduler for all DomUs to 'noop'; there is > no benefit in scheduling I/Os twice. > * Second thing I'd try is to give Dom0 more scheduler weight > (xm sched-credit -d 0 -w 512). > Now do the benchmarks again and try to find the bottlenecks by using > dstat/iostat/... to find out what is going on. Probably rebalancing > interrupts on the Dom0 may help (either manual or with the help of > irqbalance). > There are several other optimizations possible, but most of them depend on > your usecase (like increasing RAM on Dom0 for caching, changeing readahead > settings in Dom0 for the storage backend to better fit the I/O requests or > adding more CPUs to Dom0 to be able to better handle the storage backend > and things like that.) > > Please post your results! > > -- Adi _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 22:09:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 22:09: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 1UI4hz-0004XJ-Vp; Tue, 19 Mar 2013 22:08:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI4dR-0004WL-Q7 for xen-users@lists.xen.org; Tue, 19 Mar 2013 22:03:58 +0000 Received: from [85.158.138.51:52067] by server-12.bemta-3.messagelabs.com id 42/45-01357-DC0E8415; Tue, 19 Mar 2013 22:03:57 +0000 X-Env-Sender: john@clustered.net X-Msg-Ref: server-16.tower-174.messagelabs.com!1363730636!28279337!1 X-Originating-IP: [193.227.111.2] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26841 invoked from network); 19 Mar 2013 22:03:56 -0000 Received: from mail1.clustered.net (HELO clients.clustered.net) (193.227.111.2) by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2013 22:03:56 -0000 Received: from [10.1.254.2] by clients.clustered.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1UI4dF-00018C-KU; Tue, 19 Mar 2013 22:03:45 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Morrison In-Reply-To: <20130319090719.GF11334@vrvis.at> Date: Tue, 19 Mar 2013 22:03:44 +0000 Message-Id: References: <20130319090719.GF11334@vrvis.at> To: Adi Kriegisch X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Tue, 19 Mar 2013 22:08:39 +0000 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Disk iops performance scalability X-BeenThere: xen-users@lists.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, It was a typo in the config file (cpus=) that caused the drop in iops. Now I get 145k consistently. The other issue still remains, very low ioping output, especially as the first comes back in 1ms then the rest take 6 times as long Thanks John On 19 Mar 2013, at 09:07, Adi Kriegisch wrote: > Hi! > >> Seeing a drop-off in iops when more vcpu's are added:- >> >> 3.8.2 kernel/xen-4.2.1/single domU/LVM backend/8GB RAM domU/2GB RAM dom0 >> >> dom0_max_vcpus=2 dom0_vcpus_pin >> >> domU 8 cores fio result 145k iops > [...] >> domU 14 cores fio result 81k iops > [...] >> The initial ioping response is good, then a lot of latency with later ones. Any ideas ? > There are several possible optimizations: > * At first I'd try to set the I/O-Scheduler for all DomUs to 'noop'; there is > no benefit in scheduling I/Os twice. > * Second thing I'd try is to give Dom0 more scheduler weight > (xm sched-credit -d 0 -w 512). > Now do the benchmarks again and try to find the bottlenecks by using > dstat/iostat/... to find out what is going on. Probably rebalancing > interrupts on the Dom0 may help (either manual or with the help of > irqbalance). > There are several other optimizations possible, but most of them depend on > your usecase (like increasing RAM on Dom0 for caching, changeing readahead > settings in Dom0 for the storage backend to better fit the I/O requests or > adding more CPUs to Dom0 to be able to better handle the storage backend > and things like that.) > > Please post your results! > > -- Adi _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 22:23:46 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 22:23: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 1UI4vq-00056v-1s; Tue, 19 Mar 2013 22:22:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI4vo-00056p-T3 for xen-users@lists.xen.org; Tue, 19 Mar 2013 22:22:57 +0000 Received: from [85.158.139.83:44186] by server-12.bemta-5.messagelabs.com id 30/D1-11486-045E8415; Tue, 19 Mar 2013 22:22:56 +0000 X-Env-Sender: knockknock@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1363731775!23494994!1 X-Originating-IP: [74.125.82.42] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11157 invoked from network); 19 Mar 2013 22:22:55 -0000 Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com) (74.125.82.42) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 22:22:55 -0000 Received: by mail-wg0-f42.google.com with SMTP id 12so3863260wgh.5 for ; Tue, 19 Mar 2013 15:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Sk1e+fiHwiohEybCmeqbiZIR1GXCq6DLbWanaMOWWMY=; b=rCpyOPcCZhOuIJvps5W0o1p/MqKekl7LQ4YjadaKrPkamuNXGxEXhm1y7o3AowTypZ 9hQLtY2RE38TS1X/v28+wGNNKuBl3zZzAo3BzXO6+g2nzu4+hkN9CmnJtS7pkFIEzJ7v T7WHWFyKZKS8OUDYy6kbyHIH2K9X92/lTlTACPAltZJWmBjYaqHwqFBZuNhIxDilzjkp e2nQ+kya28kG7IV0+lj0Xqb9toawiRs2okg8V9mmeB5N6gLaOkQd4tjfEJTnKrvE5DkN kHdfwutEDYUnqMT4O5t/YBchtXtK0QYUhdLcMGQRawn6zzjkxAaU5uAhYKwINqmmDbM8 4SNQ== X-Received: by 10.180.11.194 with SMTP id s2mr6413961wib.5.1363731774781; Tue, 19 Mar 2013 15:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.166 with HTTP; Tue, 19 Mar 2013 15:22:34 -0700 (PDT) In-Reply-To: <5146DC57.4050102@citrix.com> References: <5146DC57.4050102@citrix.com> From: Eric Shelton Date: Tue, 19 Mar 2013 18:22:34 -0400 X-Google-Sender-Auth: ggb5OtTw8Ets15ci6WsrkU8iBZA Message-ID: To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] opensolaris/illumos on PVHVM under 4.x.y? X-BeenThere: xen-users@lists.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 [I will inline just your comments, given the length of the original email..= .] > PVHVM is not just getting a PV guest booting under a HVM container. > There are some differences in the way PV or PVHVM perform certain > operations, so it's not just a matter of putting the PV drivers, for > example the event channel callback used in PVHVM is different from the > one used in PV, and also the way to map grant frames. Although distinguishing the various flavors, including the upcoming PVH, may not be easy, I think my post was consistent with this. Just to be clea= r, I am looking for something like running Windows under Xen: running the OS in an HVM DomU, and using at least netfront and blkfront PV drivers to improve I/O performance. Any discussion of PV in my earlier post was merely to document where I had succeeded or failed to get Illumos running under Xen 4.3 unstable. > AFAIK Illumos > doesn't have PVHVM support, so it will take some work to get it running. I do not think that is correct, or at least not too long ago it would seem = that PVHVM was working under Illumos. For example, in October 2010, someone commented: "Are you looking for Solaris as a dom0? If not then why not just run it in an HVM container as a domU. The PV drivers should 'just work'." (http://comments.gmane.org/gmane.os.solaris.opensolaris.xen/5890) In my attempts to run Illumos under HVM, it is clear that the kernel has and executes code to identify whether it is running under PV, under HVM, or natively. Based on which of these three platforms it decides it is running= on, it appears to load in modules/drivers from the respective i86xpv, i86hvm, and i86pc subdirectories of /platform. More recently, it would seem that someone is running Illumos in HVM with XenServer 6.1 (which I think is based on Xen 4.1.x): "Xen HVM hangs during boot on Citrix XenServer 6.1 (probably older versions have the same problem) if apix is enabled. . . . Workaround is to enable_apix=3D0." (https://www.illumos.org/issues/3605) https://illumos.org/issues/3551 also reflects recent use under HVM. I do n= ot know if XenServer might have some "secret sauce" responsible for improved compatability with HVM Illumos. Anyways, I figured my XL config file might just need a tweak, and that someone who is getting Illumos to work under a recent version of Xen would have a working config to share. > If you are interested in running ZFS backends why don't you take a look > at FreeBSD PVHVM? It comes with ZFS, frontends and backends, and runs in > PVHVM mode without problems. It appears that is the only option, absent trying out the efforts at a native Linux port. I was hoping to have more than one option to choose from, particularly as the ZFS codebase is more "dialed in" to Opensolaris. Stability and speed seem to be fairly recent features for ZFS under FreeBSD, although a working blkback implementation is helpful. > There was someone from the Illumos community working on getting back the > full Xen PV support to Illumos, both as Dom0/DomU, but I think the work > is stalled right now. Those efforts seem to have been directed primarily at reincorporating older= Dom0 code that was ripped out, and getting Dom0 support up and running on Illumo= s. However, they seem beyond stalled. From what I gather from the Illumnos IRC logs, that person switched employers and abandoned their efforts on this project, and may have all but given up on even more general development work on Illu= mos. It also appears that the most recent Xen 4.3 development update dropped this from the list of possible upcoming features. Thank you, Eric On Mon, Mar 18, 2013 at 5:20 AM, Roger Pau Monn=E9 w= rote: > On 14/03/13 23:30, Eric Shelton wrote: >> [sorry for the dupe, the previous message was sent out prematurely...] >> >> I was hoping to implement a storage domain using blkback to serve up >> ZFS zvols, to see how it works out. Is anyone successfully running >> opensolaris with PV drivers under HVM on Xen 4.x.y? > > PVHVM is not just getting a PV guest booting under a HVM container. > There are some differences in the way PV or PVHVM perform certain > operations, so it's not just a matter of putting the PV drivers, for > example the event channel callback used in PVHVM is different from the > one used in PV, and also the way to map grant frames. AFAIK Illumos > doesn't have PVHVM support, so it will take some work to get it running. > > If you are interested in running ZFS backends why don't you take a look > at FreeBSD PVHVM? It comes with ZFS, frontends and backends, and runs in > PVHVM mode without problems. > >> I am running on an >> AMD IOMMU capable computer. The closest I have gotten is: >> (1) coaxing openindiana into booting up as a PV guest (not a smooth >> out-of-the-box type of install) >> (2) with acpi=3D0, an HVM boot will go pretty far, but there is a bug >> present in 151a7, in which the hvm_sd and sd modules fail to load due >> to being improperly built and take down the boot. A patch for this >> issue was entered into the illumos-gate repository, but does not >> appear to have been used for any current distribution. >> (3) with acpi=3D0 and use of the kernel bugger (::bp get_hwenv, :c, >> platform_type/W 0, ::delete 1, :c), I can get openindiana to boot up a >> plain PC kernel. I think I recall network and/or PV driver issues >> being a problem. >> (4) I tried out some illumos-gate kernel build/installs, but the >> typical response from a new build is some kind of a hang or lockup >> that is unresponsive to the F1-A kernel debugger. However, I am >> definitely stumbling my way through this, so I may not have run the >> kernel build or install correctly. >> >> OmniOS dies pretty quickly, whether under PV or HVM. >> >> I am beginning to get the impression that there was an active PV and >> functional driver under Xen 3, but that the illumos PV drivers did not >> keep up with various changes required to interoperate with Xen 4 (or >> at least the more recent Xen releases). > > There was someone from the Illumos community working on getting back the > full Xen PV support to Illumos, both as Dom0/DomU, but I think the work > is stalled right now. > >> Even if I were to consider >> KVM, although virtio-blk looks like it may be OK, a proposed >> virtio-net driver has not been accepted into illumos-gate, and is of >> unknown quality (it appears to be a slightly tweaked version of a >> prototype driver that was admitted to be incomplete by its original >> author). There appear to be suggestions that PVHVM has been >> maintained and works in Solaris 11, but I would much more strongly >> prefer using one of the illumos-based distributions. >> >> >> If there is anyone running opensolaris outside of PV (in other words, >> under HVM) under Xen 4.x.y, what is your Xen guest config, and which >> distribution are you using? >> >> >> Also, in sorting out how I might boot a plain non-HVM kernel (see use >> of the kernel debugger under (3) above), it looks like the >> "xen_platform_pci" parameter in xl.cfg-type files does nothing as the >> code presently stands - defeinitely when using qemu-upstream, and I >> think also under qemu-traditional. The xenpci device continues to >> show up on the virtual PCI bus under "xen_platform_pci=3D0". However, >> even if the xenpci device was toggled on/off, it turns out illumos >> would still boot an HVM kernel, as it uses the availability of the >> 0x40000000 cpuid info to identify when it is running under Xen (hence >> the debugger procedure set out in (3) above). If xen_platform_pci is >> set to 0, is this Xen cpuid functionality supposed to be diabled? >> >> _______________________________________________ >> 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 Mar 19 22:23:46 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 22:23: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 1UI4vq-00056v-1s; Tue, 19 Mar 2013 22:22:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI4vo-00056p-T3 for xen-users@lists.xen.org; Tue, 19 Mar 2013 22:22:57 +0000 Received: from [85.158.139.83:44186] by server-12.bemta-5.messagelabs.com id 30/D1-11486-045E8415; Tue, 19 Mar 2013 22:22:56 +0000 X-Env-Sender: knockknock@gmail.com X-Msg-Ref: server-7.tower-182.messagelabs.com!1363731775!23494994!1 X-Originating-IP: [74.125.82.42] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11157 invoked from network); 19 Mar 2013 22:22:55 -0000 Received: from mail-wg0-f42.google.com (HELO mail-wg0-f42.google.com) (74.125.82.42) by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 19 Mar 2013 22:22:55 -0000 Received: by mail-wg0-f42.google.com with SMTP id 12so3863260wgh.5 for ; Tue, 19 Mar 2013 15:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Sk1e+fiHwiohEybCmeqbiZIR1GXCq6DLbWanaMOWWMY=; b=rCpyOPcCZhOuIJvps5W0o1p/MqKekl7LQ4YjadaKrPkamuNXGxEXhm1y7o3AowTypZ 9hQLtY2RE38TS1X/v28+wGNNKuBl3zZzAo3BzXO6+g2nzu4+hkN9CmnJtS7pkFIEzJ7v T7WHWFyKZKS8OUDYy6kbyHIH2K9X92/lTlTACPAltZJWmBjYaqHwqFBZuNhIxDilzjkp e2nQ+kya28kG7IV0+lj0Xqb9toawiRs2okg8V9mmeB5N6gLaOkQd4tjfEJTnKrvE5DkN kHdfwutEDYUnqMT4O5t/YBchtXtK0QYUhdLcMGQRawn6zzjkxAaU5uAhYKwINqmmDbM8 4SNQ== X-Received: by 10.180.11.194 with SMTP id s2mr6413961wib.5.1363731774781; Tue, 19 Mar 2013 15:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.26.166 with HTTP; Tue, 19 Mar 2013 15:22:34 -0700 (PDT) In-Reply-To: <5146DC57.4050102@citrix.com> References: <5146DC57.4050102@citrix.com> From: Eric Shelton Date: Tue, 19 Mar 2013 18:22:34 -0400 X-Google-Sender-Auth: ggb5OtTw8Ets15ci6WsrkU8iBZA Message-ID: To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] opensolaris/illumos on PVHVM under 4.x.y? X-BeenThere: xen-users@lists.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 [I will inline just your comments, given the length of the original email..= .] > PVHVM is not just getting a PV guest booting under a HVM container. > There are some differences in the way PV or PVHVM perform certain > operations, so it's not just a matter of putting the PV drivers, for > example the event channel callback used in PVHVM is different from the > one used in PV, and also the way to map grant frames. Although distinguishing the various flavors, including the upcoming PVH, may not be easy, I think my post was consistent with this. Just to be clea= r, I am looking for something like running Windows under Xen: running the OS in an HVM DomU, and using at least netfront and blkfront PV drivers to improve I/O performance. Any discussion of PV in my earlier post was merely to document where I had succeeded or failed to get Illumos running under Xen 4.3 unstable. > AFAIK Illumos > doesn't have PVHVM support, so it will take some work to get it running. I do not think that is correct, or at least not too long ago it would seem = that PVHVM was working under Illumos. For example, in October 2010, someone commented: "Are you looking for Solaris as a dom0? If not then why not just run it in an HVM container as a domU. The PV drivers should 'just work'." (http://comments.gmane.org/gmane.os.solaris.opensolaris.xen/5890) In my attempts to run Illumos under HVM, it is clear that the kernel has and executes code to identify whether it is running under PV, under HVM, or natively. Based on which of these three platforms it decides it is running= on, it appears to load in modules/drivers from the respective i86xpv, i86hvm, and i86pc subdirectories of /platform. More recently, it would seem that someone is running Illumos in HVM with XenServer 6.1 (which I think is based on Xen 4.1.x): "Xen HVM hangs during boot on Citrix XenServer 6.1 (probably older versions have the same problem) if apix is enabled. . . . Workaround is to enable_apix=3D0." (https://www.illumos.org/issues/3605) https://illumos.org/issues/3551 also reflects recent use under HVM. I do n= ot know if XenServer might have some "secret sauce" responsible for improved compatability with HVM Illumos. Anyways, I figured my XL config file might just need a tweak, and that someone who is getting Illumos to work under a recent version of Xen would have a working config to share. > If you are interested in running ZFS backends why don't you take a look > at FreeBSD PVHVM? It comes with ZFS, frontends and backends, and runs in > PVHVM mode without problems. It appears that is the only option, absent trying out the efforts at a native Linux port. I was hoping to have more than one option to choose from, particularly as the ZFS codebase is more "dialed in" to Opensolaris. Stability and speed seem to be fairly recent features for ZFS under FreeBSD, although a working blkback implementation is helpful. > There was someone from the Illumos community working on getting back the > full Xen PV support to Illumos, both as Dom0/DomU, but I think the work > is stalled right now. Those efforts seem to have been directed primarily at reincorporating older= Dom0 code that was ripped out, and getting Dom0 support up and running on Illumo= s. However, they seem beyond stalled. From what I gather from the Illumnos IRC logs, that person switched employers and abandoned their efforts on this project, and may have all but given up on even more general development work on Illu= mos. It also appears that the most recent Xen 4.3 development update dropped this from the list of possible upcoming features. Thank you, Eric On Mon, Mar 18, 2013 at 5:20 AM, Roger Pau Monn=E9 w= rote: > On 14/03/13 23:30, Eric Shelton wrote: >> [sorry for the dupe, the previous message was sent out prematurely...] >> >> I was hoping to implement a storage domain using blkback to serve up >> ZFS zvols, to see how it works out. Is anyone successfully running >> opensolaris with PV drivers under HVM on Xen 4.x.y? > > PVHVM is not just getting a PV guest booting under a HVM container. > There are some differences in the way PV or PVHVM perform certain > operations, so it's not just a matter of putting the PV drivers, for > example the event channel callback used in PVHVM is different from the > one used in PV, and also the way to map grant frames. AFAIK Illumos > doesn't have PVHVM support, so it will take some work to get it running. > > If you are interested in running ZFS backends why don't you take a look > at FreeBSD PVHVM? It comes with ZFS, frontends and backends, and runs in > PVHVM mode without problems. > >> I am running on an >> AMD IOMMU capable computer. The closest I have gotten is: >> (1) coaxing openindiana into booting up as a PV guest (not a smooth >> out-of-the-box type of install) >> (2) with acpi=3D0, an HVM boot will go pretty far, but there is a bug >> present in 151a7, in which the hvm_sd and sd modules fail to load due >> to being improperly built and take down the boot. A patch for this >> issue was entered into the illumos-gate repository, but does not >> appear to have been used for any current distribution. >> (3) with acpi=3D0 and use of the kernel bugger (::bp get_hwenv, :c, >> platform_type/W 0, ::delete 1, :c), I can get openindiana to boot up a >> plain PC kernel. I think I recall network and/or PV driver issues >> being a problem. >> (4) I tried out some illumos-gate kernel build/installs, but the >> typical response from a new build is some kind of a hang or lockup >> that is unresponsive to the F1-A kernel debugger. However, I am >> definitely stumbling my way through this, so I may not have run the >> kernel build or install correctly. >> >> OmniOS dies pretty quickly, whether under PV or HVM. >> >> I am beginning to get the impression that there was an active PV and >> functional driver under Xen 3, but that the illumos PV drivers did not >> keep up with various changes required to interoperate with Xen 4 (or >> at least the more recent Xen releases). > > There was someone from the Illumos community working on getting back the > full Xen PV support to Illumos, both as Dom0/DomU, but I think the work > is stalled right now. > >> Even if I were to consider >> KVM, although virtio-blk looks like it may be OK, a proposed >> virtio-net driver has not been accepted into illumos-gate, and is of >> unknown quality (it appears to be a slightly tweaked version of a >> prototype driver that was admitted to be incomplete by its original >> author). There appear to be suggestions that PVHVM has been >> maintained and works in Solaris 11, but I would much more strongly >> prefer using one of the illumos-based distributions. >> >> >> If there is anyone running opensolaris outside of PV (in other words, >> under HVM) under Xen 4.x.y, what is your Xen guest config, and which >> distribution are you using? >> >> >> Also, in sorting out how I might boot a plain non-HVM kernel (see use >> of the kernel debugger under (3) above), it looks like the >> "xen_platform_pci" parameter in xl.cfg-type files does nothing as the >> code presently stands - defeinitely when using qemu-upstream, and I >> think also under qemu-traditional. The xenpci device continues to >> show up on the virtual PCI bus under "xen_platform_pci=3D0". However, >> even if the xenpci device was toggled on/off, it turns out illumos >> would still boot an HVM kernel, as it uses the availability of the >> 0x40000000 cpuid info to identify when it is running under Xen (hence >> the debugger procedure set out in (3) above). If xen_platform_pci is >> set to 0, is this Xen cpuid functionality supposed to be diabled? >> >> _______________________________________________ >> 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 Mar 19 23:20:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 23:20: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 1UI5oZ-0000b4-Mn; Tue, 19 Mar 2013 23:19:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI5oY-0000as-LR for xen-users@lists.xen.org; Tue, 19 Mar 2013 23:19:31 +0000 Received: from [193.109.254.147:24454] by server-11.bemta-14.messagelabs.com id 28/31-24840-B72F8415; Tue, 19 Mar 2013 23:19:23 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1363735162!8671506!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3448 invoked from network); 19 Mar 2013 23:19:23 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2013 23:19:23 -0000 Received: from [201.122.115.101] (port=45345 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UI5oM-0007M6-SZ for xen-users@lists.xen.org; Tue, 19 Mar 2013 18:19:19 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id CBD8BA209 for ; Tue, 19 Mar 2013 17:14:08 -0600 (CST) Message-ID: <5148F275.6090003@ondore.com> Date: Tue, 19 Mar 2013 17:19:17 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> In-Reply-To: <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 Hello. El 18/03/13 18:35, Jing Chen escribi=F3: > Hi Alexandre. > I post a new topic in xen forum. Please see below email and link. I = got the reply that Frank Zhang is out of office for long time. I am wonderi= ng if I put to the wrong place? > > Could you help to answer this question? Sorry, I am not familiar with autoyast at all. Consider treating this as separate topics. First, you need to get your VM to start and boot from proper media for a = automated installation. I would go for a network boot, but probably you = will find better reference for a CD/DVD based installation. Second, you will have to deal with autoyast directly, Xen mailing list = is probably not the right place to start with. Suse Linux support forums = might be more helpful. > This Communication is Confidential. Beware, you have been sending confidential communications to a public list. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 23:20:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 23:20: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 1UI5oZ-0000b4-Mn; Tue, 19 Mar 2013 23:19:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI5oY-0000as-LR for xen-users@lists.xen.org; Tue, 19 Mar 2013 23:19:31 +0000 Received: from [193.109.254.147:24454] by server-11.bemta-14.messagelabs.com id 28/31-24840-B72F8415; Tue, 19 Mar 2013 23:19:23 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1363735162!8671506!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3448 invoked from network); 19 Mar 2013 23:19:23 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2013 23:19:23 -0000 Received: from [201.122.115.101] (port=45345 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UI5oM-0007M6-SZ for xen-users@lists.xen.org; Tue, 19 Mar 2013 18:19:19 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id CBD8BA209 for ; Tue, 19 Mar 2013 17:14:08 -0600 (CST) Message-ID: <5148F275.6090003@ondore.com> Date: Tue, 19 Mar 2013 17:19:17 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> In-Reply-To: <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 Hello. El 18/03/13 18:35, Jing Chen escribi=F3: > Hi Alexandre. > I post a new topic in xen forum. Please see below email and link. I = got the reply that Frank Zhang is out of office for long time. I am wonderi= ng if I put to the wrong place? > > Could you help to answer this question? Sorry, I am not familiar with autoyast at all. Consider treating this as separate topics. First, you need to get your VM to start and boot from proper media for a = automated installation. I would go for a network boot, but probably you = will find better reference for a CD/DVD based installation. Second, you will have to deal with autoyast directly, Xen mailing list = is probably not the right place to start with. Suse Linux support forums = might be more helpful. > This Communication is Confidential. Beware, you have been sending confidential communications to a public list. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 23:28:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 23:28: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 1UI5wV-0000yW-C2; Tue, 19 Mar 2013 23:27:43 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI5wT-0000yL-MB for xen-users@lists.xen.org; Tue, 19 Mar 2013 23:27:41 +0000 Received: from [85.158.137.99:42249] by server-13.bemta-3.messagelabs.com id 29/A6-25744-C64F8415; Tue, 19 Mar 2013 23:27:40 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-11.tower-217.messagelabs.com!1363735657!17008876!1 X-Originating-IP: [203.16.207.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18324 invoked from network); 19 Mar 2013 23:27:39 -0000 Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-11.tower-217.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 19 Mar 2013 23:27:39 -0000 Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d] (helo=BITCOM1.int.sbss.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.80) (envelope-from ) id 1UI5wJ-0007Zm-Kl; Wed, 20 Mar 2013 10:27:31 +1100 Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id 14.01.0438.000; Wed, 20 Mar 2013 10:27:31 +1100 From: James Harper To: Eugene Istomin , "xen-users@lists.xen.org" Thread-Topic: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl Thread-Index: AQHOJEXVZYQjV1/XEUOeu78m0nN+jZisSLlwgAAd2oCAAUNbIA== Date: Tue, 19 Mar 2013 23:27:30 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B387F4ED5@BITCOM1.int.sbss.com.au> References: <14060997.pf0ahXB1Me@eistomin.users.edss.local> <6035A0D088A63A46850C3988ED045A4B387F13E3@BITCOM1.int.sbss.com.au> <2765182.d5BzhGrGb7@eistomin> In-Reply-To: <2765182.d5BzhGrGb7@eistomin> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.71] x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19732.002 x-tm-as-result: No--37.110000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No MIME-Version: 1.0 X-Really-From-Bendigo-IT: magichashvalue Subject: Re: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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 > in qemu-xen-traditional model everything is working fine, in qemu-xen > (upstream qemu) BSOD appears only after xennet install. I tried Win2k8 > Std/Ent/DC Win2k13 Std/DC, only Win2k8 Ent/DC not worked properly. > > James, > > how i can get debug logs in qemu-upstream mode? > > May be this is xen issue? > > # kernel 3.4.35-1-xen > > # xen-4.2.1_06 > What files are in /var/log/xen? For my install each HVM domu creates a logfile /var/log/xen/qemu-dm-.log James _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 19 23:28:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 19 Mar 2013 23:28: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 1UI5wV-0000yW-C2; Tue, 19 Mar 2013 23:27:43 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI5wT-0000yL-MB for xen-users@lists.xen.org; Tue, 19 Mar 2013 23:27:41 +0000 Received: from [85.158.137.99:42249] by server-13.bemta-3.messagelabs.com id 29/A6-25744-C64F8415; Tue, 19 Mar 2013 23:27:40 +0000 X-Env-Sender: james.harper@bendigoit.com.au X-Msg-Ref: server-11.tower-217.messagelabs.com!1363735657!17008876!1 X-Originating-IP: [203.16.207.99] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18324 invoked from network); 19 Mar 2013 23:27:39 -0000 Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au) (203.16.207.99) by server-11.tower-217.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 19 Mar 2013 23:27:39 -0000 Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d] (helo=BITCOM1.int.sbss.com.au) by smtp2.bendigoit.com.au with esmtp (Exim 4.80) (envelope-from ) id 1UI5wJ-0007Zm-Kl; Wed, 20 Mar 2013 10:27:31 +1100 Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id 14.01.0438.000; Wed, 20 Mar 2013 10:27:31 +1100 From: James Harper To: Eugene Istomin , "xen-users@lists.xen.org" Thread-Topic: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl Thread-Index: AQHOJEXVZYQjV1/XEUOeu78m0nN+jZisSLlwgAAd2oCAAUNbIA== Date: Tue, 19 Mar 2013 23:27:30 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B387F4ED5@BITCOM1.int.sbss.com.au> References: <14060997.pf0ahXB1Me@eistomin.users.edss.local> <6035A0D088A63A46850C3988ED045A4B387F13E3@BITCOM1.int.sbss.com.au> <2765182.d5BzhGrGb7@eistomin> In-Reply-To: <2765182.d5BzhGrGb7@eistomin> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.71] x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-19732.002 x-tm-as-result: No--37.110000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No MIME-Version: 1.0 X-Really-From-Bendigo-IT: magichashvalue Subject: Re: [Xen-users] BSOD on Windows 2008 R2 Enterprise in qemu-xen mode, lastest gplpl X-BeenThere: xen-users@lists.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 > in qemu-xen-traditional model everything is working fine, in qemu-xen > (upstream qemu) BSOD appears only after xennet install. I tried Win2k8 > Std/Ent/DC Win2k13 Std/DC, only Win2k8 Ent/DC not worked properly. > > James, > > how i can get debug logs in qemu-upstream mode? > > May be this is xen issue? > > # kernel 3.4.35-1-xen > > # xen-4.2.1_06 > What files are in /var/log/xen? For my install each HVM domu creates a logfile /var/log/xen/qemu-dm-.log James _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 20 01:01:38 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 01:01: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 1UI7OM-0006X2-7H; Wed, 20 Mar 2013 01:00:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI7OL-0006DS-1u for xen-users@lists.xensource.com; Wed, 20 Mar 2013 01:00:33 +0000 Received: from [85.158.139.83:37909] by server-15.bemta-5.messagelabs.com id E3/AF-22815-03A09415; Wed, 20 Mar 2013 01:00:32 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1363741229!27777619!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12372 invoked from network); 20 Mar 2013 01:00:30 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 20 Mar 2013 01:00:30 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UI7OG-0007KH-Fu for xen-users@lists.xensource.com; Tue, 19 Mar 2013 18:00:28 -0700 Date: Tue, 19 Mar 2013 18:00:28 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363741228450-5714935.post@n5.nabble.com> In-Reply-To: <5148F275.6090003@ondore.com> References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> <5148F275.6090003@ondore.com> MIME-Version: 1.0 Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 Alexandre. one thing i am wondering is that Para-virtualization VM support specifing the autoyast xml for installation. the configuration file is as builder="linux" kernel="/opt/ericsson/HA/boot/vmlinuz-xenpae.sles11.sp2" ramdisk="/opt/ericsson/HA/boot/inst-initrd.sles11.sp2" extra=" install=hd:/dev/xvdb autoyast=device://xvdp/autoinst.xml " disk=[ 'phy:/dev/sda3,xvda,w', 'file:/var/nsmbuild/linux/3_19089-CNA10802_2_Ux_C.iso,xvdb,r', 'file:/opt/ericsson/HA/tmp/autoyast.sles11_sp2,xvdp,r', 'file:/opt/ericsson/HA/patch/fixorg,xvdc,r', ] kernel can take the parameter in extra for autoyast. while full virtualzation kerner can not take extra parameter. builder="hvm" device_model="/usr/lib/xen/bin/qemu-dm" kernel="/usr/lib/xen/boot/hvmloader" boot="d" disk=[ 'phy:/dev/sda3,hda,w', 'file:/var/nsmbuild/linux/3_19089-CNA10802_2_Ux_C.iso,hdb:cdrom,r', 'file:/opt/ericsson/HA/tmp/autoyast.sles11_sp2,hdp,r'] Can you help to clarify what is difference between vmlinuz-xenpae.sles11.sp2 and hvmloader? can full-virtualization VM be create using vmlinuz-xenpae.sles11.sp2 and initrd like Para-virtualization VM. Thanks. Jing -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901p5714935.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 Mar 20 01:01:38 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 01:01: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 1UI7OM-0006X2-7H; Wed, 20 Mar 2013 01:00:34 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI7OL-0006DS-1u for xen-users@lists.xensource.com; Wed, 20 Mar 2013 01:00:33 +0000 Received: from [85.158.139.83:37909] by server-15.bemta-5.messagelabs.com id E3/AF-22815-03A09415; Wed, 20 Mar 2013 01:00:32 +0000 X-Env-Sender: jing.chen@ericsson.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1363741229!27777619!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12372 invoked from network); 20 Mar 2013 01:00:30 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 20 Mar 2013 01:00:30 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UI7OG-0007KH-Fu for xen-users@lists.xensource.com; Tue, 19 Mar 2013 18:00:28 -0700 Date: Tue, 19 Mar 2013 18:00:28 -0700 (PDT) From: Jing Chen To: xen-users@lists.xensource.com Message-ID: <1363741228450-5714935.post@n5.nabble.com> In-Reply-To: <5148F275.6090003@ondore.com> References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> <5148F275.6090003@ondore.com> MIME-Version: 1.0 Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 Alexandre. one thing i am wondering is that Para-virtualization VM support specifing the autoyast xml for installation. the configuration file is as builder="linux" kernel="/opt/ericsson/HA/boot/vmlinuz-xenpae.sles11.sp2" ramdisk="/opt/ericsson/HA/boot/inst-initrd.sles11.sp2" extra=" install=hd:/dev/xvdb autoyast=device://xvdp/autoinst.xml " disk=[ 'phy:/dev/sda3,xvda,w', 'file:/var/nsmbuild/linux/3_19089-CNA10802_2_Ux_C.iso,xvdb,r', 'file:/opt/ericsson/HA/tmp/autoyast.sles11_sp2,xvdp,r', 'file:/opt/ericsson/HA/patch/fixorg,xvdc,r', ] kernel can take the parameter in extra for autoyast. while full virtualzation kerner can not take extra parameter. builder="hvm" device_model="/usr/lib/xen/bin/qemu-dm" kernel="/usr/lib/xen/boot/hvmloader" boot="d" disk=[ 'phy:/dev/sda3,hda,w', 'file:/var/nsmbuild/linux/3_19089-CNA10802_2_Ux_C.iso,hdb:cdrom,r', 'file:/opt/ericsson/HA/tmp/autoyast.sles11_sp2,hdp,r'] Can you help to clarify what is difference between vmlinuz-xenpae.sles11.sp2 and hvmloader? can full-virtualization VM be create using vmlinuz-xenpae.sles11.sp2 and initrd like Para-virtualization VM. Thanks. Jing -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-create-a-full-virtualization-xen-VM-with-autoyast-tp5714901p5714935.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 Mar 20 01:19:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 01:19: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 1UI7fr-0006Ul-Sl; Wed, 20 Mar 2013 01:18:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI7fp-0006Uf-EH for xen-users@lists.xensource.com; Wed, 20 Mar 2013 01:18:37 +0000 Received: from [85.158.139.211:23296] by server-1.bemta-5.messagelabs.com id D5/4B-14063-C6E09415; Wed, 20 Mar 2013 01:18:36 +0000 X-Env-Sender: duanshuidao@hotmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1363742315!19119309!1 X-Originating-IP: [65.55.111.112] X-SpamReason: No, hits=-1.6 required=7.0 tests=FORGED_HOTMAIL_RCVD, MIME_BASE64_TEXT,ML_RADAR_FP_R_14,ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_2,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11883 invoked from network); 20 Mar 2013 01:18:35 -0000 Received: from blu0-omc2-s37.blu0.hotmail.com (HELO blu0-omc2-s37.blu0.hotmail.com) (65.55.111.112) by server-11.tower-206.messagelabs.com with SMTP; 20 Mar 2013 01:18:35 -0000 Received: from BLU402-EAS401 ([65.55.111.73]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Mar 2013 18:18:35 -0700 X-EIP: [U1uMN6uspULV/7bHLRHAcJ7h1YVfpck6] X-Originating-Email: [duanshuidao@hotmail.com] Message-ID: References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> <5148F275.6090003@ondore.com> <1363741228450-5714935.post@n5.nabble.com> From: Jun Hu MIME-Version: 1.0 (1.0) In-Reply-To: <1363741228450-5714935.post@n5.nabble.com> Date: Wed, 20 Mar 2013 09:18:29 +0800 To: Jing Chen X-OriginalArrivalTime: 20 Mar 2013 01:18:35.0714 (UTC) FILETIME=[D82D5A20:01CE2508] Cc: "xen-users@lists.xensource.com" Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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="gb2312" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org aGkgamluZywNCg0KaWYgeW91IHVzZSBvcGVuc3VzZSCjrGkgY2FuIHN1cHBvcnQgeW91IGZyZWVs eSxvdGhlcndpc2UgZm9yIHNsZXMgLHlvdSBtdXN0IHBheSBmb3IgaXQuDQoNCg0KDQpmcm9tIGh1 anVuJ3MgaXBob25lDQoNCk9uIDIwMTMtMy0yMCwgYXQgOTowNCwgIkppbmcgQ2hlbiIgPGppbmcu Y2hlbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+IFRoYW5rcyBBbGV4YW5kcmUuDQo+ICAgICBv bmUgdGhpbmcgaSBhbSB3b25kZXJpbmcgaXMgdGhhdCBQYXJhLXZpcnR1YWxpemF0aW9uIFZNIHN1 cHBvcnQNCj4gc3BlY2lmaW5nIHRoZSBhdXRveWFzdCB4bWwgZm9yIGluc3RhbGxhdGlvbi4gdGhl IGNvbmZpZ3VyYXRpb24gZmlsZSBpcyBhcyANCj4gDQo+IGJ1aWxkZXI9ImxpbnV4Ig0KPiBrZXJu ZWw9Ii9vcHQvZXJpY3Nzb24vSEEvYm9vdC92bWxpbnV6LXhlbnBhZS5zbGVzMTEuc3AyIg0KPiBy YW1kaXNrPSIvb3B0L2VyaWNzc29uL0hBL2Jvb3QvaW5zdC1pbml0cmQuc2xlczExLnNwMiINCj4g ZXh0cmE9IiBpbnN0YWxsPWhkOi9kZXYveHZkYiBhdXRveWFzdD1kZXZpY2U6Ly94dmRwL2F1dG9p bnN0LnhtbCAiDQo+IGRpc2s9WyAncGh5Oi9kZXYvc2RhMyx4dmRhLHcnLA0KPiAnZmlsZTovdmFy L25zbWJ1aWxkL2xpbnV4LzNfMTkwODktQ05BMTA4MDJfMl9VeF9DLmlzbyx4dmRiLHInLA0KPiAn ZmlsZTovb3B0L2VyaWNzc29uL0hBL3RtcC9hdXRveWFzdC5zbGVzMTFfc3AyLHh2ZHAscicsDQo+ ICdmaWxlOi9vcHQvZXJpY3Nzb24vSEEvcGF0Y2gvZml4b3JnLHh2ZGMscicsIF0NCj4gDQo+IGtl cm5lbCBjYW4gdGFrZSB0aGUgcGFyYW1ldGVyIGluIGV4dHJhIGZvciBhdXRveWFzdC4gd2hpbGUg ZnVsbA0KPiB2aXJ0dWFsemF0aW9uIGtlcm5lciBjYW4gbm90IHRha2UgZXh0cmEgcGFyYW1ldGVy Lg0KPiANCj4gYnVpbGRlcj0iaHZtIg0KPiBkZXZpY2VfbW9kZWw9Ii91c3IvbGliL3hlbi9iaW4v cWVtdS1kbSINCj4ga2VybmVsPSIvdXNyL2xpYi94ZW4vYm9vdC9odm1sb2FkZXIiDQo+IGJvb3Q9 ImQiDQo+IGRpc2s9WyAncGh5Oi9kZXYvc2RhMyxoZGEsdycsDQo+ICdmaWxlOi92YXIvbnNtYnVp bGQvbGludXgvM18xOTA4OS1DTkExMDgwMl8yX1V4X0MuaXNvLGhkYjpjZHJvbSxyJywNCj4gJ2Zp bGU6L29wdC9lcmljc3Nvbi9IQS90bXAvYXV0b3lhc3Quc2xlczExX3NwMixoZHAsciddDQo+IA0K PiBDYW4geW91IGhlbHAgdG8gY2xhcmlmeSB3aGF0IGlzIGRpZmZlcmVuY2UgYmV0d2VlbiB2bWxp bnV6LXhlbnBhZS5zbGVzMTEuc3AyDQo+IGFuZCBodm1sb2FkZXI/IGNhbiBmdWxsLXZpcnR1YWxp emF0aW9uIFZNIGJlIGNyZWF0ZSB1c2luZw0KPiB2bWxpbnV6LXhlbnBhZS5zbGVzMTEuc3AyICBh bmQgaW5pdHJkIGxpa2UgUGFyYS12aXJ0dWFsaXphdGlvbiBWTS4NCj4gDQo+IFRoYW5rcy4NCj4g DQo+IEppbmcNCj4gDQo+IA0KPiANCj4gLS0NCj4gVmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4 dDogaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20vaG93LXRvLWNyZWF0ZS1hLWZ1bGwt dmlydHVhbGl6YXRpb24teGVuLVZNLXdpdGgtYXV0b3lhc3QtdHA1NzE0OTAxcDU3MTQ5MzUuaHRt bA0KPiBTZW50IGZyb20gdGhlIFhlbiAtIFVzZXIgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQgTmFi YmxlLmNvbS4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IFhlbi11c2VycyBtYWlsaW5nIGxpc3QNCj4gWGVuLXVzZXJzQGxpc3RzLnhlbi5v cmcNCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJzDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tdXNlcnMgbWFpbGluZyBsaXN0Clhlbi11 c2Vyc0BsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi11c2Vycw== From xen-users-bounces@lists.xen.org Wed Mar 20 01:19:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 01:19: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 1UI7fr-0006Ul-Sl; Wed, 20 Mar 2013 01:18:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI7fp-0006Uf-EH for xen-users@lists.xensource.com; Wed, 20 Mar 2013 01:18:37 +0000 Received: from [85.158.139.211:23296] by server-1.bemta-5.messagelabs.com id D5/4B-14063-C6E09415; Wed, 20 Mar 2013 01:18:36 +0000 X-Env-Sender: duanshuidao@hotmail.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1363742315!19119309!1 X-Originating-IP: [65.55.111.112] X-SpamReason: No, hits=-1.6 required=7.0 tests=FORGED_HOTMAIL_RCVD, MIME_BASE64_TEXT,ML_RADAR_FP_R_14,ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_2,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11883 invoked from network); 20 Mar 2013 01:18:35 -0000 Received: from blu0-omc2-s37.blu0.hotmail.com (HELO blu0-omc2-s37.blu0.hotmail.com) (65.55.111.112) by server-11.tower-206.messagelabs.com with SMTP; 20 Mar 2013 01:18:35 -0000 Received: from BLU402-EAS401 ([65.55.111.73]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Mar 2013 18:18:35 -0700 X-EIP: [U1uMN6uspULV/7bHLRHAcJ7h1YVfpck6] X-Originating-Email: [duanshuidao@hotmail.com] Message-ID: References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> <5148F275.6090003@ondore.com> <1363741228450-5714935.post@n5.nabble.com> From: Jun Hu MIME-Version: 1.0 (1.0) In-Reply-To: <1363741228450-5714935.post@n5.nabble.com> Date: Wed, 20 Mar 2013 09:18:29 +0800 To: Jing Chen X-OriginalArrivalTime: 20 Mar 2013 01:18:35.0714 (UTC) FILETIME=[D82D5A20:01CE2508] Cc: "xen-users@lists.xensource.com" Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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="gb2312" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org aGkgamluZywNCg0KaWYgeW91IHVzZSBvcGVuc3VzZSCjrGkgY2FuIHN1cHBvcnQgeW91IGZyZWVs eSxvdGhlcndpc2UgZm9yIHNsZXMgLHlvdSBtdXN0IHBheSBmb3IgaXQuDQoNCg0KDQpmcm9tIGh1 anVuJ3MgaXBob25lDQoNCk9uIDIwMTMtMy0yMCwgYXQgOTowNCwgIkppbmcgQ2hlbiIgPGppbmcu Y2hlbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+IFRoYW5rcyBBbGV4YW5kcmUuDQo+ICAgICBv bmUgdGhpbmcgaSBhbSB3b25kZXJpbmcgaXMgdGhhdCBQYXJhLXZpcnR1YWxpemF0aW9uIFZNIHN1 cHBvcnQNCj4gc3BlY2lmaW5nIHRoZSBhdXRveWFzdCB4bWwgZm9yIGluc3RhbGxhdGlvbi4gdGhl IGNvbmZpZ3VyYXRpb24gZmlsZSBpcyBhcyANCj4gDQo+IGJ1aWxkZXI9ImxpbnV4Ig0KPiBrZXJu ZWw9Ii9vcHQvZXJpY3Nzb24vSEEvYm9vdC92bWxpbnV6LXhlbnBhZS5zbGVzMTEuc3AyIg0KPiBy YW1kaXNrPSIvb3B0L2VyaWNzc29uL0hBL2Jvb3QvaW5zdC1pbml0cmQuc2xlczExLnNwMiINCj4g ZXh0cmE9IiBpbnN0YWxsPWhkOi9kZXYveHZkYiBhdXRveWFzdD1kZXZpY2U6Ly94dmRwL2F1dG9p bnN0LnhtbCAiDQo+IGRpc2s9WyAncGh5Oi9kZXYvc2RhMyx4dmRhLHcnLA0KPiAnZmlsZTovdmFy L25zbWJ1aWxkL2xpbnV4LzNfMTkwODktQ05BMTA4MDJfMl9VeF9DLmlzbyx4dmRiLHInLA0KPiAn ZmlsZTovb3B0L2VyaWNzc29uL0hBL3RtcC9hdXRveWFzdC5zbGVzMTFfc3AyLHh2ZHAscicsDQo+ ICdmaWxlOi9vcHQvZXJpY3Nzb24vSEEvcGF0Y2gvZml4b3JnLHh2ZGMscicsIF0NCj4gDQo+IGtl cm5lbCBjYW4gdGFrZSB0aGUgcGFyYW1ldGVyIGluIGV4dHJhIGZvciBhdXRveWFzdC4gd2hpbGUg ZnVsbA0KPiB2aXJ0dWFsemF0aW9uIGtlcm5lciBjYW4gbm90IHRha2UgZXh0cmEgcGFyYW1ldGVy Lg0KPiANCj4gYnVpbGRlcj0iaHZtIg0KPiBkZXZpY2VfbW9kZWw9Ii91c3IvbGliL3hlbi9iaW4v cWVtdS1kbSINCj4ga2VybmVsPSIvdXNyL2xpYi94ZW4vYm9vdC9odm1sb2FkZXIiDQo+IGJvb3Q9 ImQiDQo+IGRpc2s9WyAncGh5Oi9kZXYvc2RhMyxoZGEsdycsDQo+ICdmaWxlOi92YXIvbnNtYnVp bGQvbGludXgvM18xOTA4OS1DTkExMDgwMl8yX1V4X0MuaXNvLGhkYjpjZHJvbSxyJywNCj4gJ2Zp bGU6L29wdC9lcmljc3Nvbi9IQS90bXAvYXV0b3lhc3Quc2xlczExX3NwMixoZHAsciddDQo+IA0K PiBDYW4geW91IGhlbHAgdG8gY2xhcmlmeSB3aGF0IGlzIGRpZmZlcmVuY2UgYmV0d2VlbiB2bWxp bnV6LXhlbnBhZS5zbGVzMTEuc3AyDQo+IGFuZCBodm1sb2FkZXI/IGNhbiBmdWxsLXZpcnR1YWxp emF0aW9uIFZNIGJlIGNyZWF0ZSB1c2luZw0KPiB2bWxpbnV6LXhlbnBhZS5zbGVzMTEuc3AyICBh bmQgaW5pdHJkIGxpa2UgUGFyYS12aXJ0dWFsaXphdGlvbiBWTS4NCj4gDQo+IFRoYW5rcy4NCj4g DQo+IEppbmcNCj4gDQo+IA0KPiANCj4gLS0NCj4gVmlldyB0aGlzIG1lc3NhZ2UgaW4gY29udGV4 dDogaHR0cDovL3hlbi4xMDQ1NzEyLm41Lm5hYmJsZS5jb20vaG93LXRvLWNyZWF0ZS1hLWZ1bGwt dmlydHVhbGl6YXRpb24teGVuLVZNLXdpdGgtYXV0b3lhc3QtdHA1NzE0OTAxcDU3MTQ5MzUuaHRt bA0KPiBTZW50IGZyb20gdGhlIFhlbiAtIFVzZXIgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQgTmFi YmxlLmNvbS4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IFhlbi11c2VycyBtYWlsaW5nIGxpc3QNCj4gWGVuLXVzZXJzQGxpc3RzLnhlbi5v cmcNCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJzDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tdXNlcnMgbWFpbGluZyBsaXN0Clhlbi11 c2Vyc0BsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi11c2Vycw== From xen-users-bounces@lists.xen.org Wed Mar 20 01:42:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 01:42: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 1UI82N-00071Y-Na; Wed, 20 Mar 2013 01:41:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI82M-00071T-4t for xen-users@lists.xen.org; Wed, 20 Mar 2013 01:41:54 +0000 Received: from [85.158.139.83:56107] by server-11.bemta-5.messagelabs.com id 57/3F-27486-1E319415; Wed, 20 Mar 2013 01:41:53 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1363743711!28330829!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31735 invoked from network); 20 Mar 2013 01:41:52 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Mar 2013 01:41:52 -0000 Received: from [201.122.115.101] (port=39820 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UI82J-0005Dj-02 for xen-users@lists.xen.org; Tue, 19 Mar 2013 20:41:51 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id EDD9CA209 for ; Tue, 19 Mar 2013 19:36:40 -0600 (CST) Message-ID: <514913DD.1010002@ondore.com> Date: Tue, 19 Mar 2013 19:41:49 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> <5148F275.6090003@ondore.com> <1363741228450-5714935.post@n5.nabble.com> In-Reply-To: <1363741228450-5714935.post@n5.nabble.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 Hello. El 19/03/13 19:00, Jing Chen escribi=F3: > Can you help to clarify what is difference between vmlinuz-xenpae.sles11.= sp2 > and hvmloader? can full-virtualization VM be create using > vmlinuz-xenpae.sles11.sp2 and initrd like Para-virtualization VM. A fully virtualized DomU does not care about guest system's kernel or = initrd. It does not even provide a boot loader for it. It attempts to = emulate a whole computer, and the guest system is booted as if it where = on a normal host. So, a fully virtualized DomU can not be created using = a kernel and initrd files, as PV DomU. In case of a PV DomU, the guest kernel interacts directly with Xen's low = level hypervisor. In case of HVM DomU, there is an additional layer between guest kernel = and the hypervisor: qemu. Hvmloader's job is "to load all the necessary = information that qemu will use to build the necessary environment that = will "fool" an unmodified guest that he is in fact on a physical machine = is needed by qemu". http://wiki.xen.org/wiki/Hvmloader As you may see, PV and HVM guests works in a quite different manner. If, = by chance, they are configured and run in a similar way, that is because = there is wrapper for that. (If I'm wrong, please somebody correct me.) Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 20 01:42:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 01:42: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 1UI82N-00071Y-Na; Wed, 20 Mar 2013 01:41:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UI82M-00071T-4t for xen-users@lists.xen.org; Wed, 20 Mar 2013 01:41:54 +0000 Received: from [85.158.139.83:56107] by server-11.bemta-5.messagelabs.com id 57/3F-27486-1E319415; Wed, 20 Mar 2013 01:41:53 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-5.tower-182.messagelabs.com!1363743711!28330829!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31735 invoked from network); 20 Mar 2013 01:41:52 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Mar 2013 01:41:52 -0000 Received: from [201.122.115.101] (port=39820 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UI82J-0005Dj-02 for xen-users@lists.xen.org; Tue, 19 Mar 2013 20:41:51 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id EDD9CA209 for ; Tue, 19 Mar 2013 19:36:40 -0600 (CST) Message-ID: <514913DD.1010002@ondore.com> Date: Tue, 19 Mar 2013 19:41:49 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <1363602301181-5714901.post@n5.nabble.com> <9DB1A345BDFDC74E88407C319EDB4C930531A2@ESGSCMB105.ericsson.se> <5148F275.6090003@ondore.com> <1363741228450-5714935.post@n5.nabble.com> In-Reply-To: <1363741228450-5714935.post@n5.nabble.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] how to create a full-virtualization xen VM with autoyast X-BeenThere: xen-users@lists.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 Hello. El 19/03/13 19:00, Jing Chen escribi=F3: > Can you help to clarify what is difference between vmlinuz-xenpae.sles11.= sp2 > and hvmloader? can full-virtualization VM be create using > vmlinuz-xenpae.sles11.sp2 and initrd like Para-virtualization VM. A fully virtualized DomU does not care about guest system's kernel or = initrd. It does not even provide a boot loader for it. It attempts to = emulate a whole computer, and the guest system is booted as if it where = on a normal host. So, a fully virtualized DomU can not be created using = a kernel and initrd files, as PV DomU. In case of a PV DomU, the guest kernel interacts directly with Xen's low = level hypervisor. In case of HVM DomU, there is an additional layer between guest kernel = and the hypervisor: qemu. Hvmloader's job is "to load all the necessary = information that qemu will use to build the necessary environment that = will "fool" an unmodified guest that he is in fact on a physical machine = is needed by qemu". http://wiki.xen.org/wiki/Hvmloader As you may see, PV and HVM guests works in a quite different manner. If, = by chance, they are configured and run in a similar way, that is because = there is wrapper for that. (If I'm wrong, please somebody correct me.) Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 20 11:22:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 11:22: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 1UIH59-0007UQ-L0; Wed, 20 Mar 2013 11:21:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIH58-0007UG-B4 for xen-users@lists.xen.org; Wed, 20 Mar 2013 11:21:22 +0000 Received: from [85.158.143.99:7022] by server-1.bemta-4.messagelabs.com id 8F/46-06203-1BB99415; Wed, 20 Mar 2013 11:21:21 +0000 X-Env-Sender: janno@kodu.ee X-Msg-Ref: server-10.tower-216.messagelabs.com!1363778480!21054091!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29469 invoked from network); 20 Mar 2013 11:21:20 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-10.tower-216.messagelabs.com with SMTP; 20 Mar 2013 11:21:20 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id F267E62E5F for ; Wed, 20 Mar 2013 13:21:18 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id iwrODOUYlexr for ; Wed, 20 Mar 2013 13:21:16 +0200 (EET) Received: from [192.168.45.25] (km.kernel.ee [80.250.116.5]) by asum.kodu.ee (Postfix) with ESMTPSA id DCC1F62CA8 for ; Wed, 20 Mar 2013 13:21:16 +0200 (EET) Message-ID: <51499BAC.7060900@kodu.ee> Date: Wed, 20 Mar 2013 13:21:16 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5148589D.4020307@kernel.ee> <5148A957.6010204@kodu.ee> In-Reply-To: Subject: Re: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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, > Based on what you've said, the KDM login is not frozen (cursor is > actively blinking?), but the input is not in the right place somehow. > > If I am understanding this right, the Java applet sits between the > real VGA output and the Matrox adapter, as a layer? If so maybe some > connection is belong list in transit when Xen hands VGA over to the Dom0. Probably. Though I guess the problem isn't related to that applet, as the kernel without xen comes up with fully functional console. The problem is probably Xen not supporting EFI -- at least on this hardware :( Actually, I was dumb enough not to look at 'xm dmesg' output before (thanks to Casey for bringing it up). Surprisingly, while Xen succeeds on detecting RAM, it fails reading full ACPI data structure: -- (XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126] (XEN) System RAM: 98237MB (100595124kB) (XEN) Domain heap initialised (XEN) Table is not found! (XEN) Found and enabled local APIC! -- As Xen does not detect root pointer it fails of course on everything else depending on it, including detecting the cpu: -- (XEN) Detected 2000.055 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) I/O virtualisation disabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) Platform timer is 1.193MHz PIT (XEN) Allocated console ring of 16 KiB. (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, 1GB (XEN) Brought up 1 CPUs -- Finally, it just finds one cpu instead of six hyperthreaded cores! Amazing. Compared to that, my trouble with console is just nothing. The console problem is very likely caused by this acpi detection failure also. Tried Opensuse 12.3 with Xen 4.2.1 this morning. Got the same result (the dmesg output above is actually from Xen 4.2.1 also). The OS 12.3 kernel (3.7.10-1.1) without xen continues to detect ACPI data correctly (as 3.4.33-2.24 on 12.2 did), giving no errors, finding all cores etc... I'll probably re-check the IBM firmware updates and then submit a bug report. Regards, Janno _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 20 11:22:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 11:22: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 1UIH59-0007UQ-L0; Wed, 20 Mar 2013 11:21:23 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIH58-0007UG-B4 for xen-users@lists.xen.org; Wed, 20 Mar 2013 11:21:22 +0000 Received: from [85.158.143.99:7022] by server-1.bemta-4.messagelabs.com id 8F/46-06203-1BB99415; Wed, 20 Mar 2013 11:21:21 +0000 X-Env-Sender: janno@kodu.ee X-Msg-Ref: server-10.tower-216.messagelabs.com!1363778480!21054091!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29469 invoked from network); 20 Mar 2013 11:21:20 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-10.tower-216.messagelabs.com with SMTP; 20 Mar 2013 11:21:20 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id F267E62E5F for ; Wed, 20 Mar 2013 13:21:18 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id iwrODOUYlexr for ; Wed, 20 Mar 2013 13:21:16 +0200 (EET) Received: from [192.168.45.25] (km.kernel.ee [80.250.116.5]) by asum.kodu.ee (Postfix) with ESMTPSA id DCC1F62CA8 for ; Wed, 20 Mar 2013 13:21:16 +0200 (EET) Message-ID: <51499BAC.7060900@kodu.ee> Date: Wed, 20 Mar 2013 13:21:16 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5148589D.4020307@kernel.ee> <5148A957.6010204@kodu.ee> In-Reply-To: Subject: Re: [Xen-users] xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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, > Based on what you've said, the KDM login is not frozen (cursor is > actively blinking?), but the input is not in the right place somehow. > > If I am understanding this right, the Java applet sits between the > real VGA output and the Matrox adapter, as a layer? If so maybe some > connection is belong list in transit when Xen hands VGA over to the Dom0. Probably. Though I guess the problem isn't related to that applet, as the kernel without xen comes up with fully functional console. The problem is probably Xen not supporting EFI -- at least on this hardware :( Actually, I was dumb enough not to look at 'xm dmesg' output before (thanks to Casey for bringing it up). Surprisingly, while Xen succeeds on detecting RAM, it fails reading full ACPI data structure: -- (XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126] (XEN) System RAM: 98237MB (100595124kB) (XEN) Domain heap initialised (XEN) Table is not found! (XEN) Found and enabled local APIC! -- As Xen does not detect root pointer it fails of course on everything else depending on it, including detecting the cpu: -- (XEN) Detected 2000.055 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) I/O virtualisation disabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) Platform timer is 1.193MHz PIT (XEN) Allocated console ring of 16 KiB. (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, 1GB (XEN) Brought up 1 CPUs -- Finally, it just finds one cpu instead of six hyperthreaded cores! Amazing. Compared to that, my trouble with console is just nothing. The console problem is very likely caused by this acpi detection failure also. Tried Opensuse 12.3 with Xen 4.2.1 this morning. Got the same result (the dmesg output above is actually from Xen 4.2.1 also). The OS 12.3 kernel (3.7.10-1.1) without xen continues to detect ACPI data correctly (as 3.4.33-2.24 on 12.2 did), giving no errors, finding all cores etc... I'll probably re-check the IBM firmware updates and then submit a bug report. Regards, Janno _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 20 11:25:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 11:25:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIH7z-0007m6-7D; Wed, 20 Mar 2013 11:24:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIH7x-0007lW-RJ; Wed, 20 Mar 2013 11:24:17 +0000 Received: from [85.158.143.99:3350] by server-1.bemta-4.messagelabs.com id E1/E9-06203-06C99415; Wed, 20 Mar 2013 11:24:16 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1363778653!17990871!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5333 invoked from network); 20 Mar 2013 11:24:15 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 20 Mar 2013 11:24:15 -0000 X-IronPort-AV: E=Sophos;i="4.84,877,1355097600"; d="scan'208";a="14344377" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 20 Mar 2013 11:24:13 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.3; Wed, 20 Mar 2013 07:24:12 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UIH7s-0003dp-A8; Wed, 20 Mar 2013 11:24:12 +0000 Message-ID: <1363778652.3088.11.camel@zion.uk.xensource.com> From: Wei Liu To: xen-devel , xen-api , "xen-users@lists.xen.org" , xen-arm Date: Wed, 20 Mar 2013 11:24:12 +0000 X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) MIME-Version: 1.0 Cc: wei.liu2@citrix.com Subject: [Xen-users] Next Xen Document Day: Monday, March 25 X-BeenThere: xen-users@lists.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, a quick reminder that the next Xen Document Day is happening next Monday. As usual, more info on document days at http://wiki.xen.org/wiki/Xen_Document_Days TODO LIST ========= Feel free to add stuff to the TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO) or put your name besides an item if you intend to work on it. How do I participate? ===================== - Join us on IRC: freenode channel #xendocs - Tell people what you intend to work on (to avoid doing something somebody else is already working on) - Fix some documentation - Help others - And above all: have fun! See you on IRC! Best Regards Wei _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 20 11:25:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 11:25:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIH7z-0007m6-7D; Wed, 20 Mar 2013 11:24:19 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIH7x-0007lW-RJ; Wed, 20 Mar 2013 11:24:17 +0000 Received: from [85.158.143.99:3350] by server-1.bemta-4.messagelabs.com id E1/E9-06203-06C99415; Wed, 20 Mar 2013 11:24:16 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-8.tower-216.messagelabs.com!1363778653!17990871!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5333 invoked from network); 20 Mar 2013 11:24:15 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 20 Mar 2013 11:24:15 -0000 X-IronPort-AV: E=Sophos;i="4.84,877,1355097600"; d="scan'208";a="14344377" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 20 Mar 2013 11:24:13 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.3; Wed, 20 Mar 2013 07:24:12 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UIH7s-0003dp-A8; Wed, 20 Mar 2013 11:24:12 +0000 Message-ID: <1363778652.3088.11.camel@zion.uk.xensource.com> From: Wei Liu To: xen-devel , xen-api , "xen-users@lists.xen.org" , xen-arm Date: Wed, 20 Mar 2013 11:24:12 +0000 X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) MIME-Version: 1.0 Cc: wei.liu2@citrix.com Subject: [Xen-users] Next Xen Document Day: Monday, March 25 X-BeenThere: xen-users@lists.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, a quick reminder that the next Xen Document Day is happening next Monday. As usual, more info on document days at http://wiki.xen.org/wiki/Xen_Document_Days TODO LIST ========= Feel free to add stuff to the TODO list (http://wiki.xen.org/wiki/Xen_Document_Days/TODO) or put your name besides an item if you intend to work on it. How do I participate? ===================== - Join us on IRC: freenode channel #xendocs - Tell people what you intend to work on (to avoid doing something somebody else is already working on) - Fix some documentation - Help others - And above all: have fun! See you on IRC! Best Regards Wei _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 20 17:38:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 17:38: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 1UIMx8-00017E-Ut; Wed, 20 Mar 2013 17:37:30 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIMWl-0000ZC-0U for xen-users@lists.xen.org; Wed, 20 Mar 2013 17:10:15 +0000 Received: from [193.109.254.147:45055] by server-6.bemta-14.messagelabs.com id 31/FF-31180-67DE9415; Wed, 20 Mar 2013 17:10:14 +0000 X-Env-Sender: ydev@cs.utah.edu X-Msg-Ref: server-10.tower-27.messagelabs.com!1363799411!3526127!1 X-Originating-IP: [155.98.64.241] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9611 invoked from network); 20 Mar 2013 17:10:12 -0000 Received: from mail-svr1.cs.utah.edu (HELO mail-svr1.cs.utah.edu) (155.98.64.241) by server-10.tower-27.messagelabs.com with SMTP; 20 Mar 2013 17:10:12 -0000 Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 6D42A6500C9 for ; Wed, 20 Mar 2013 11:10:11 -0600 (MDT) X-Virus-Scanned: amavisd-new at cs.utah.edu Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWuCRrEMhxad; Wed, 20 Mar 2013 11:10:11 -0600 (MDT) Received: from [192.168.1.6] (c-76-23-15-81.hsd1.ut.comcast.net [76.23.15.81]) by smtps.cs.utah.edu (Postfix) with ESMTPSA id 289746500AC; Wed, 20 Mar 2013 11:10:11 -0600 (MDT) Message-ID: <5149ED6F.6050802@cs.utah.edu> Date: Wed, 20 Mar 2013 11:10:07 -0600 From: Yathindra User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Mailman-Approved-At: Wed, 20 Mar 2013 17:37:30 +0000 Cc: Yathindra Naik Subject: [Xen-users] Tracking NFS Request X-BeenThere: xen-users@lists.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, I want to start a NFS client in one domain and NFS server in another. And I'm trying to map NFS requests to their client domain ids. I wanted to know if there are any known ways to do this already. Thanks, Yathi _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 20 17:38:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 17:38: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 1UIMx8-00017E-Ut; Wed, 20 Mar 2013 17:37:30 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIMWl-0000ZC-0U for xen-users@lists.xen.org; Wed, 20 Mar 2013 17:10:15 +0000 Received: from [193.109.254.147:45055] by server-6.bemta-14.messagelabs.com id 31/FF-31180-67DE9415; Wed, 20 Mar 2013 17:10:14 +0000 X-Env-Sender: ydev@cs.utah.edu X-Msg-Ref: server-10.tower-27.messagelabs.com!1363799411!3526127!1 X-Originating-IP: [155.98.64.241] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9611 invoked from network); 20 Mar 2013 17:10:12 -0000 Received: from mail-svr1.cs.utah.edu (HELO mail-svr1.cs.utah.edu) (155.98.64.241) by server-10.tower-27.messagelabs.com with SMTP; 20 Mar 2013 17:10:12 -0000 Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 6D42A6500C9 for ; Wed, 20 Mar 2013 11:10:11 -0600 (MDT) X-Virus-Scanned: amavisd-new at cs.utah.edu Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWuCRrEMhxad; Wed, 20 Mar 2013 11:10:11 -0600 (MDT) Received: from [192.168.1.6] (c-76-23-15-81.hsd1.ut.comcast.net [76.23.15.81]) by smtps.cs.utah.edu (Postfix) with ESMTPSA id 289746500AC; Wed, 20 Mar 2013 11:10:11 -0600 (MDT) Message-ID: <5149ED6F.6050802@cs.utah.edu> Date: Wed, 20 Mar 2013 11:10:07 -0600 From: Yathindra User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Mailman-Approved-At: Wed, 20 Mar 2013 17:37:30 +0000 Cc: Yathindra Naik Subject: [Xen-users] Tracking NFS Request X-BeenThere: xen-users@lists.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, I want to start a NFS client in one domain and NFS server in another. And I'm trying to map NFS requests to their client domain ids. I wanted to know if there are any known ways to do this already. Thanks, Yathi _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 20 22:35:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 22: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 1UIRaJ-0005UH-SE; Wed, 20 Mar 2013 22:34:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIRaI-0005U8-Hb for xen-users@lists.xen.org; Wed, 20 Mar 2013 22:34:14 +0000 Received: from [85.158.137.99:56562] by server-6.bemta-3.messagelabs.com id 56/EC-11048-5693A415; Wed, 20 Mar 2013 22:34:13 +0000 X-Env-Sender: janno@kodu.ee X-Msg-Ref: server-7.tower-217.messagelabs.com!1363818851!12278485!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12044 invoked from network); 20 Mar 2013 22:34:11 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-7.tower-217.messagelabs.com with SMTP; 20 Mar 2013 22:34:11 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id 6208AA4C64 for ; Thu, 21 Mar 2013 00:33:10 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id HnG7Zx0NHsuA for ; Thu, 21 Mar 2013 00:33:07 +0200 (EET) Received: from [192.168.5.10] (a31a16.trt.kodu.ee [80.250.120.5]) by asum.kodu.ee (Postfix) with ESMTPSA id 618BBA4BBE for ; Thu, 21 Mar 2013 00:33:07 +0200 (EET) Message-ID: <514A3925.8090702@kodu.ee> Date: Thu, 21 Mar 2013 00:33:09 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5148589D.4020307@kernel.ee> <5148A957.6010204@kodu.ee> <51499BAC.7060900@kodu.ee> In-Reply-To: <51499BAC.7060900@kodu.ee> Subject: Re: [Xen-users] SOLVED: xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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 Just to conclude this topic: Xen 4.1.3 with OpenSUSE 12.2 (and 4.2.1 = with OS12.3 also) works well with UEFI on IBM x35*0 hardware. The machine has to be booted with xen.efi loader, any other loader = before xen won't do, probably. I just had to - create an additional directory on efi partition; - copy xen.efi into that directory; - copy initrd and vmlinuz kernel images into that directory; - create simple xen.cfg file in the same directory containing just a = few lines -- for example: options=3Ddom0_mem=3D2048M,max:2048M dom0_max_vcpus=3D1 = dom0_vcpus_pin loglvl=3Dall noreboot kernel=3Dvmlinuz-3.7.10-1.1-xen ignore_loglevel #earlyprintk=3Dxen ramdisk=3Dinitrd-3.7.10-1.1-xen root=3D/dev/disk/by-id/scsi-3500a07510364d950-part3 - create additional boot entry in system firmware pointing to the xen.efi. And voil=E0 -- everything works like a charm :) RAM and cores are counted = correctly, console acts normally, vm-s run as expected. Concerning my initial question about that strange "no console will be = available to OS" message I suspected to be some meaningful indication to = my problem -- I'm not sure if it's related to any problem at all. I = can't notice it on boot anymore. Though I'm still wondering what it = actually means... With best regards, Janno > Hi, > >> Based on what you've said, the KDM login is not frozen (cursor is = >> actively blinking?), but the input is not in the right place somehow. >> >> If I am understanding this right, the Java applet sits between the = >> real VGA output and the Matrox adapter, as a layer? If so maybe some = >> connection is belong list in transit when Xen hands VGA over to the = >> Dom0. > Probably. Though I guess the problem isn't related to that applet, as = > the kernel without xen comes up with fully functional console. > > The problem is probably Xen not supporting EFI -- at least on this = > hardware :( > Actually, I was dumb enough not to look at 'xm dmesg' output before = > (thanks to Casey for bringing it up). Surprisingly, while Xen succeeds = > on detecting RAM, it fails reading full ACPI data structure: > -- = > (XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126] > (XEN) System RAM: 98237MB (100595124kB) > (XEN) Domain heap initialised > (XEN) Table is not found! > (XEN) Found and enabled local APIC! > -- = > > As Xen does not detect root pointer it fails of course on everything = > else depending on it, including detecting the cpu: > -- = > (XEN) Detected 2000.055 MHz processor. > (XEN) Initing memory sharing. > (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 > (XEN) I/O virtualisation disabled > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) Platform timer is 1.193MHz PIT > (XEN) Allocated console ring of 16 KiB. > (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, 1GB > (XEN) Brought up 1 CPUs > -- = > Finally, it just finds one cpu instead of six hyperthreaded cores! = > Amazing. > Compared to that, my trouble with console is just nothing. > The console problem is very likely caused by this acpi detection = > failure also. > > > Tried Opensuse 12.3 with Xen 4.2.1 this morning. Got the same result = > (the dmesg output above is actually from Xen 4.2.1 also). > > The OS 12.3 kernel (3.7.10-1.1) without xen continues to detect ACPI = > data correctly (as 3.4.33-2.24 on 12.2 did), giving no errors, finding = > all cores etc... > > > I'll probably re-check the IBM firmware updates and then submit a bug = > report. > > > Regards, > Janno > > > _______________________________________________ > 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 Mar 20 22:35:40 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 20 Mar 2013 22: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 1UIRaJ-0005UH-SE; Wed, 20 Mar 2013 22:34:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIRaI-0005U8-Hb for xen-users@lists.xen.org; Wed, 20 Mar 2013 22:34:14 +0000 Received: from [85.158.137.99:56562] by server-6.bemta-3.messagelabs.com id 56/EC-11048-5693A415; Wed, 20 Mar 2013 22:34:13 +0000 X-Env-Sender: janno@kodu.ee X-Msg-Ref: server-7.tower-217.messagelabs.com!1363818851!12278485!1 X-Originating-IP: [80.250.113.236] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12044 invoked from network); 20 Mar 2013 22:34:11 -0000 Received: from asum.kodu.ee (HELO asum.kodu.ee) (80.250.113.236) by server-7.tower-217.messagelabs.com with SMTP; 20 Mar 2013 22:34:11 -0000 Received: from asum.kodu.ee (asum.kodu.ee [80.250.113.236]) by asum.kodu.ee (Postfix) with ESMTP id 6208AA4C64 for ; Thu, 21 Mar 2013 00:33:10 +0200 (EET) X-Virus-Scanned: amavisd-new at kodu.ee Received: from asum.kodu.ee ([80.250.113.236]) by asum.kodu.ee (asum.kodu.ee [80.250.113.236]) (amavisd-new, port 10024) with ESMTP id HnG7Zx0NHsuA for ; Thu, 21 Mar 2013 00:33:07 +0200 (EET) Received: from [192.168.5.10] (a31a16.trt.kodu.ee [80.250.120.5]) by asum.kodu.ee (Postfix) with ESMTPSA id 618BBA4BBE for ; Thu, 21 Mar 2013 00:33:07 +0200 (EET) Message-ID: <514A3925.8090702@kodu.ee> Date: Thu, 21 Mar 2013 00:33:09 +0200 From: Janno Loide User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5148589D.4020307@kernel.ee> <5148A957.6010204@kodu.ee> <51499BAC.7060900@kodu.ee> In-Reply-To: <51499BAC.7060900@kodu.ee> Subject: Re: [Xen-users] SOLVED: xen 4.1.3, EFI boot and "no console to OS" problem X-BeenThere: xen-users@lists.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 Just to conclude this topic: Xen 4.1.3 with OpenSUSE 12.2 (and 4.2.1 = with OS12.3 also) works well with UEFI on IBM x35*0 hardware. The machine has to be booted with xen.efi loader, any other loader = before xen won't do, probably. I just had to - create an additional directory on efi partition; - copy xen.efi into that directory; - copy initrd and vmlinuz kernel images into that directory; - create simple xen.cfg file in the same directory containing just a = few lines -- for example: options=3Ddom0_mem=3D2048M,max:2048M dom0_max_vcpus=3D1 = dom0_vcpus_pin loglvl=3Dall noreboot kernel=3Dvmlinuz-3.7.10-1.1-xen ignore_loglevel #earlyprintk=3Dxen ramdisk=3Dinitrd-3.7.10-1.1-xen root=3D/dev/disk/by-id/scsi-3500a07510364d950-part3 - create additional boot entry in system firmware pointing to the xen.efi. And voil=E0 -- everything works like a charm :) RAM and cores are counted = correctly, console acts normally, vm-s run as expected. Concerning my initial question about that strange "no console will be = available to OS" message I suspected to be some meaningful indication to = my problem -- I'm not sure if it's related to any problem at all. I = can't notice it on boot anymore. Though I'm still wondering what it = actually means... With best regards, Janno > Hi, > >> Based on what you've said, the KDM login is not frozen (cursor is = >> actively blinking?), but the input is not in the right place somehow. >> >> If I am understanding this right, the Java applet sits between the = >> real VGA output and the Matrox adapter, as a layer? If so maybe some = >> connection is belong list in transit when Xen hands VGA over to the = >> Dom0. > Probably. Though I guess the problem isn't related to that applet, as = > the kernel without xen comes up with fully functional console. > > The problem is probably Xen not supporting EFI -- at least on this = > hardware :( > Actually, I was dumb enough not to look at 'xm dmesg' output before = > (thanks to Casey for bringing it up). Surprisingly, while Xen succeeds = > on detecting RAM, it fails reading full ACPI data structure: > -- = > (XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126] > (XEN) System RAM: 98237MB (100595124kB) > (XEN) Domain heap initialised > (XEN) Table is not found! > (XEN) Found and enabled local APIC! > -- = > > As Xen does not detect root pointer it fails of course on everything = > else depending on it, including detecting the cpu: > -- = > (XEN) Detected 2000.055 MHz processor. > (XEN) Initing memory sharing. > (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 > (XEN) I/O virtualisation disabled > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) Platform timer is 1.193MHz PIT > (XEN) Allocated console ring of 16 KiB. > (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, 1GB > (XEN) Brought up 1 CPUs > -- = > Finally, it just finds one cpu instead of six hyperthreaded cores! = > Amazing. > Compared to that, my trouble with console is just nothing. > The console problem is very likely caused by this acpi detection = > failure also. > > > Tried Opensuse 12.3 with Xen 4.2.1 this morning. Got the same result = > (the dmesg output above is actually from Xen 4.2.1 also). > > The OS 12.3 kernel (3.7.10-1.1) without xen continues to detect ACPI = > data correctly (as 3.4.33-2.24 on 12.2 did), giving no errors, finding = > all cores etc... > > > I'll probably re-check the IBM firmware updates and then submit a bug = > report. > > > Regards, > Janno > > > _______________________________________________ > 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 Mar 21 01:50:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 01:50: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 1UIUdD-0003Ki-5L; Thu, 21 Mar 2013 01:49:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIUdB-0003Kd-DF for xen-users@lists.xen.org; Thu, 21 Mar 2013 01:49:25 +0000 Received: from [85.158.139.83:36544] by server-12.bemta-5.messagelabs.com id 77/E7-11486-4276A415; Thu, 21 Mar 2013 01:49:24 +0000 X-Env-Sender: almir@kadric.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1363830562!16800406!1 X-Originating-IP: [67.23.45.131] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10569 invoked from network); 21 Mar 2013 01:49:23 -0000 Received: from kadricenterprises.com (HELO kadricenterprises.com) (67.23.45.131) by server-8.tower-182.messagelabs.com with SMTP; 21 Mar 2013 01:49:23 -0000 Received: from [192.168.2.234] (113x33x180x18.ap113.ftth.ucom.ne.jp [113.33.180.18]) by kadricenterprises.com (Postfix) with ESMTP id D659D438033; Thu, 21 Mar 2013 01:41:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1283) From: Almir Kadric In-Reply-To: Date: Thu, 21 Mar 2013 10:49:13 +0900 Message-Id: References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> <5147AB67.9050705@yahoo.co.uk> To: Casey DeLorme , Paul Stimpson , Andreas Falck , jacek burghardt X-Mailer: Apple Mail (2.1283) Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============4043732118543321042==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4043732118543321042== Content-Type: multipart/alternative; boundary="Apple-Mail=_5D11F277-727F-4DF9-A004-521C44ED870E" --Apple-Mail=_5D11F277-727F-4DF9-A004-521C44ED870E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sorry for the late response, @Andreas > One piece of information that might be useful for further debugging is = whether the error occurs when the VM kernel boots or already when the = HVM bios boots. You can try this by starting a HVM vm without any = virtual disk, thus booting only the HVM bios. Also, it would probably be = of interest to know if a PV guest works (you can probably do this easily = by starting only a PV kernel, no need to install a full PV system). = However, I am not sure on what to do with that information, but someone = else might have a clue. I have tried booting without a virtual disk in the past, that didn't = work. However I have not tried a PV guest yet. @Paul, that's most interested I will give that a go and see what = happens. @Casey, I will take a look at the guide and thank you for the = information. It does make me feel a little better ^_^ @Jacek, haven't tried that yet, will give it a go as well. Also an update: Which might interest all with a GA-970A or similar chipset motherboard. = I got a speedy response from gigabyte as follows: > If you need to enable IOMMU, please update motherboard BIOS to the = latest version F12c and then reset "IOMMU support" this BIOS item to = Enabled and save BIOS change to test again.=20 So it seems that my current BIOS is also a bit dodgy and could be = causing me the headache. So my plans for the weekend are as follows to help shine some light on = this: Will re-create Squeeze environment Try a PV guest Will try turning off ballooning Turn off IOMMU support and try HVM / PVM Possibly test the above in Wheezy and Ubuntu 12.10 Update BIOS to latest mentioned version as above (F12c is actually a = beta candidate, soooo.....) Give it all another whirl If all else fails will try to compile before mentioned versions from = source Will update everyone with findings after I have completed my tests over = the weekend. If anyone is really interested in the results (has a GA-970 = or similar chipset setup) and I happen to forget, feel free to give me a = direct ping and I will try to respond in a timely manner. Best Regards, Almir kadric Website: www.almirkadric.com Mobile: +81 90 8008 1578 Office: +81 03 4550 1448 Email: almir@kadric.com On Mar 19, 2013, at 10:48 AM, jacek burghardt wrote: >=20 > Maybe problem is caused by domO ballooning I have this line in grub = dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall and I am = using 3.8.3 kernel with opensuse patches and seems to be very stable = with 4.3 unstable =20 >=20 > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --Apple-Mail=_5D11F277-727F-4DF9-A004-521C44ED870E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Sorry = for the late = response,


@Andreas
One piece of information that might be useful for = further debugging is whether the error occurs when the VM kernel boots = or already when the HVM bios boots. You can try this by starting a HVM = vm without any virtual disk, thus booting only the HVM bios. Also, it = would probably be of interest to know if a PV guest works (you can = probably do this easily by starting only a PV kernel, no need to install = a full PV system). However, I am not sure on what to do with that = information, but someone else might have a = clue.
I have tried booting without a virtual disk = in the past, that didn't work. However I have not tried a PV guest = yet.

@Paul, that's most interested I = will give that a go and see what = happens.

@Casey, I will take a look at = the guide and thank you for the information. It does make me feel a = little better ^_^

@Jacek, haven't = tried that yet, will give it a go as = well.


Also an = update:
Which might interest all with a GA-970A or similar = chipset motherboard. I got a speedy response from gigabyte as = follows:
If you need to enable IOMMU, please update motherboard BIOS to = the latest version F12c and then reset "IOMMU support" this BIOS item to = Enabled and save BIOS change to test = again. 

So it seems = that my current BIOS is also a bit dodgy and could be causing me the = headache.


So my plans for the = weekend are as follows to help shine some light on = this:
  • Will re-create Squeeze = environment
  • Try a PV guest
  • Will try turning off = ballooning
  • Turn off IOMMU support and try HVM / = PVM
  • Possibly test the above in Wheezy and Ubuntu = 12.10
  • Update BIOS to latest mentioned version as above (F12c is = actually a beta candidate, soooo.....)
  • Give it all another = whirl
  • If all else fails will try to compile before mentioned = versions from = source


Will update = everyone with findings after I have completed my tests over the weekend. = If anyone is really interested in the results (has a GA-970 or similar = chipset setup) and I happen to forget, feel free to give me a direct = ping and I will try to respond in a timely = manner.


Best Regards,
Almir kadric

Website: www.almirkadric.com
Mobile:     +81 90 8008 = 1578
Office:      +81 03 = 4550 1448
Email: almir@kadric.com

On Mar 19, 2013, at 10:48 AM, jacek burghardt = wrote:


Maybe problem is caused by domO ballooning I have this = line in grub dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall = and I am using 3.8.3 kernel with opensuse patches and seems to be very = stable with 4.3 unstable 

_______________________________________________
Xen-users mailing = list
Xen-users@lists.xen.org
htt= p://lists.xen.org/xen-users

= --Apple-Mail=_5D11F277-727F-4DF9-A004-521C44ED870E-- --===============4043732118543321042== 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 --===============4043732118543321042==-- From xen-users-bounces@lists.xen.org Thu Mar 21 01:50:47 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 01:50: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 1UIUdD-0003Ki-5L; Thu, 21 Mar 2013 01:49:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIUdB-0003Kd-DF for xen-users@lists.xen.org; Thu, 21 Mar 2013 01:49:25 +0000 Received: from [85.158.139.83:36544] by server-12.bemta-5.messagelabs.com id 77/E7-11486-4276A415; Thu, 21 Mar 2013 01:49:24 +0000 X-Env-Sender: almir@kadric.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1363830562!16800406!1 X-Originating-IP: [67.23.45.131] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10569 invoked from network); 21 Mar 2013 01:49:23 -0000 Received: from kadricenterprises.com (HELO kadricenterprises.com) (67.23.45.131) by server-8.tower-182.messagelabs.com with SMTP; 21 Mar 2013 01:49:23 -0000 Received: from [192.168.2.234] (113x33x180x18.ap113.ftth.ucom.ne.jp [113.33.180.18]) by kadricenterprises.com (Postfix) with ESMTP id D659D438033; Thu, 21 Mar 2013 01:41:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1283) From: Almir Kadric In-Reply-To: Date: Thu, 21 Mar 2013 10:49:13 +0900 Message-Id: References: <4F8A1DC5-827A-4F3F-B64A-EE432C5E07B1@kadric.com> <5147AB67.9050705@yahoo.co.uk> To: Casey DeLorme , Paul Stimpson , Andreas Falck , jacek burghardt X-Mailer: Apple Mail (2.1283) Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Can't get XEN to work at all on Debian 6, 7 and Ubuntu 12.10 X-BeenThere: xen-users@lists.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="===============4043732118543321042==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4043732118543321042== Content-Type: multipart/alternative; boundary="Apple-Mail=_5D11F277-727F-4DF9-A004-521C44ED870E" --Apple-Mail=_5D11F277-727F-4DF9-A004-521C44ED870E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sorry for the late response, @Andreas > One piece of information that might be useful for further debugging is = whether the error occurs when the VM kernel boots or already when the = HVM bios boots. You can try this by starting a HVM vm without any = virtual disk, thus booting only the HVM bios. Also, it would probably be = of interest to know if a PV guest works (you can probably do this easily = by starting only a PV kernel, no need to install a full PV system). = However, I am not sure on what to do with that information, but someone = else might have a clue. I have tried booting without a virtual disk in the past, that didn't = work. However I have not tried a PV guest yet. @Paul, that's most interested I will give that a go and see what = happens. @Casey, I will take a look at the guide and thank you for the = information. It does make me feel a little better ^_^ @Jacek, haven't tried that yet, will give it a go as well. Also an update: Which might interest all with a GA-970A or similar chipset motherboard. = I got a speedy response from gigabyte as follows: > If you need to enable IOMMU, please update motherboard BIOS to the = latest version F12c and then reset "IOMMU support" this BIOS item to = Enabled and save BIOS change to test again.=20 So it seems that my current BIOS is also a bit dodgy and could be = causing me the headache. So my plans for the weekend are as follows to help shine some light on = this: Will re-create Squeeze environment Try a PV guest Will try turning off ballooning Turn off IOMMU support and try HVM / PVM Possibly test the above in Wheezy and Ubuntu 12.10 Update BIOS to latest mentioned version as above (F12c is actually a = beta candidate, soooo.....) Give it all another whirl If all else fails will try to compile before mentioned versions from = source Will update everyone with findings after I have completed my tests over = the weekend. If anyone is really interested in the results (has a GA-970 = or similar chipset setup) and I happen to forget, feel free to give me a = direct ping and I will try to respond in a timely manner. Best Regards, Almir kadric Website: www.almirkadric.com Mobile: +81 90 8008 1578 Office: +81 03 4550 1448 Email: almir@kadric.com On Mar 19, 2013, at 10:48 AM, jacek burghardt wrote: >=20 > Maybe problem is caused by domO ballooning I have this line in grub = dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall and I am = using 3.8.3 kernel with opensuse patches and seems to be very stable = with 4.3 unstable =20 >=20 > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --Apple-Mail=_5D11F277-727F-4DF9-A004-521C44ED870E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Sorry = for the late = response,


@Andreas
One piece of information that might be useful for = further debugging is whether the error occurs when the VM kernel boots = or already when the HVM bios boots. You can try this by starting a HVM = vm without any virtual disk, thus booting only the HVM bios. Also, it = would probably be of interest to know if a PV guest works (you can = probably do this easily by starting only a PV kernel, no need to install = a full PV system). However, I am not sure on what to do with that = information, but someone else might have a = clue.
I have tried booting without a virtual disk = in the past, that didn't work. However I have not tried a PV guest = yet.

@Paul, that's most interested I = will give that a go and see what = happens.

@Casey, I will take a look at = the guide and thank you for the information. It does make me feel a = little better ^_^

@Jacek, haven't = tried that yet, will give it a go as = well.


Also an = update:
Which might interest all with a GA-970A or similar = chipset motherboard. I got a speedy response from gigabyte as = follows:
If you need to enable IOMMU, please update motherboard BIOS to = the latest version F12c and then reset "IOMMU support" this BIOS item to = Enabled and save BIOS change to test = again. 

So it seems = that my current BIOS is also a bit dodgy and could be causing me the = headache.


So my plans for the = weekend are as follows to help shine some light on = this:
  • Will re-create Squeeze = environment
  • Try a PV guest
  • Will try turning off = ballooning
  • Turn off IOMMU support and try HVM / = PVM
  • Possibly test the above in Wheezy and Ubuntu = 12.10
  • Update BIOS to latest mentioned version as above (F12c is = actually a beta candidate, soooo.....)
  • Give it all another = whirl
  • If all else fails will try to compile before mentioned = versions from = source


Will update = everyone with findings after I have completed my tests over the weekend. = If anyone is really interested in the results (has a GA-970 or similar = chipset setup) and I happen to forget, feel free to give me a direct = ping and I will try to respond in a timely = manner.


Best Regards,
Almir kadric

Website: www.almirkadric.com
Mobile:     +81 90 8008 = 1578
Office:      +81 03 = 4550 1448
Email: almir@kadric.com

On Mar 19, 2013, at 10:48 AM, jacek burghardt = wrote:


Maybe problem is caused by domO ballooning I have this = line in grub dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall = and I am using 3.8.3 kernel with opensuse patches and seems to be very = stable with 4.3 unstable 

_______________________________________________
Xen-users mailing = list
Xen-users@lists.xen.org
htt= p://lists.xen.org/xen-users

= --Apple-Mail=_5D11F277-727F-4DF9-A004-521C44ED870E-- --===============4043732118543321042== 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 --===============4043732118543321042==-- From xen-users-bounces@lists.xen.org Thu Mar 21 07:19:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 07:19: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 1UIZlL-000720-KQ; Thu, 21 Mar 2013 07:18:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIZlK-00071v-KY for xen-users@lists.xensource.com; Thu, 21 Mar 2013 07:18:10 +0000 Received: from [85.158.143.99:43815] by server-3.bemta-4.messagelabs.com id 23/58-02186-134BA415; Thu, 21 Mar 2013 07:18:09 +0000 X-Env-Sender: lemoned2@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363850285!22654190!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1508 invoked from network); 21 Mar 2013 07:18:08 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 21 Mar 2013 07:18:08 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UIZlF-0001Hs-AE for xen-users@lists.xensource.com; Thu, 21 Mar 2013 00:18:05 -0700 Date: Thu, 21 Mar 2013 00:18:05 -0700 (PDT) From: "kay. kim." To: xen-users@lists.xensource.com Message-ID: <1363850285276-5714943.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-users] how to use GPLPV DRIVER? X-BeenThere: xen-users@lists.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. i'm new to xen and pv driver. i googled the definition of GPLPV driver, i couldn't fine information what i want. i'm curious about what does GPLPV driver and how to use it. please let me know well-made tutorial and docs for beginner. regards. kim. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-use-GPLPV-DRIVER-tp5714943.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 Thu Mar 21 07:19:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 07:19: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 1UIZlL-000720-KQ; Thu, 21 Mar 2013 07:18:11 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIZlK-00071v-KY for xen-users@lists.xensource.com; Thu, 21 Mar 2013 07:18:10 +0000 Received: from [85.158.143.99:43815] by server-3.bemta-4.messagelabs.com id 23/58-02186-134BA415; Thu, 21 Mar 2013 07:18:09 +0000 X-Env-Sender: lemoned2@gmail.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1363850285!22654190!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1508 invoked from network); 21 Mar 2013 07:18:08 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP; 21 Mar 2013 07:18:08 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UIZlF-0001Hs-AE for xen-users@lists.xensource.com; Thu, 21 Mar 2013 00:18:05 -0700 Date: Thu, 21 Mar 2013 00:18:05 -0700 (PDT) From: "kay. kim." To: xen-users@lists.xensource.com Message-ID: <1363850285276-5714943.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-users] how to use GPLPV DRIVER? X-BeenThere: xen-users@lists.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. i'm new to xen and pv driver. i googled the definition of GPLPV driver, i couldn't fine information what i want. i'm curious about what does GPLPV driver and how to use it. please let me know well-made tutorial and docs for beginner. regards. kim. -- View this message in context: http://xen.1045712.n5.nabble.com/how-to-use-GPLPV-DRIVER-tp5714943.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 Thu Mar 21 12:59:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 12:59: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 1UIf4g-0003su-RE; Thu, 21 Mar 2013 12:58:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIUaK-0003K7-6z for xen-users@lists.xen.org; Thu, 21 Mar 2013 01:46:28 +0000 Received: from [85.158.139.211:30359] by server-9.bemta-5.messagelabs.com id C4/C6-08547-3766A415; Thu, 21 Mar 2013 01:46:27 +0000 X-Env-Sender: todd.wardzinski@progeny.net X-Msg-Ref: server-7.tower-206.messagelabs.com!1363830386!17925072!1 X-Originating-IP: [69.17.18.222] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25224 invoked from network); 21 Mar 2013 01:46:26 -0000 Received: from mail.progeny.net (HELO mail.progeny.net) (69.17.18.222) by server-7.tower-206.messagelabs.com with SMTP; 21 Mar 2013 01:46:26 -0000 Received: from ES2K7-HUB.progeny.net (Not Verified[192.168.22.23]) by mail.progeny.net with MailMarshal (v6, 8, 3, 9481) id ; Wed, 20 Mar 2013 21:46:25 -0400 Received: from ES2K7-MBX-1.progeny.net ([::1]) by ES2K7-HUB.progeny.net ([fe80::f09d:66d9:40a5:c66f%10]) with mapi; Wed, 20 Mar 2013 21:46:21 -0400 From: "Wardzinski, Todd" To: "xen-users@lists.xen.org" Date: Wed, 20 Mar 2013 21:46:20 -0400 Thread-Topic: Building Xen in network devoid areas Thread-Index: Ac4lvBNg3vaL+eRsSiWV+gLjuMqFMgAGUHvw Message-ID: <3A4BA757D72EC4419FA31D91DC15363C06E70E645E@ES2K7-MBX-1.progeny.net> References: <5148589D.4020307@kernel.ee> <5148A957.6010204@kodu.ee> <51499BAC.7060900@kodu.ee> <514A3925.8090702@kodu.ee> In-Reply-To: <514A3925.8090702@kodu.ee> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 21 Mar 2013 12:58:29 +0000 Subject: [Xen-users] Building Xen in network devoid areas X-BeenThere: xen-users@lists.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 All, I'm currently working on an issue where I need to build Xen in areas where I may not have any networking at all. I have searched the Internet for possible remedies, but, so far, have not come up with any good solutions. My goal is to take a build of Xen 4.2.1, put it on a server (Intel or AMD) that already has the Xen 4.2.1 required packages installed, and be able to build (make world) and install (make install) without having to access any git repositories. Any ideas on how best to solve this issue? Kind regards, Todd Wardzinski _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 21 12:59:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 12:59: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 1UIf4g-0003su-RE; Thu, 21 Mar 2013 12:58:30 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIUaK-0003K7-6z for xen-users@lists.xen.org; Thu, 21 Mar 2013 01:46:28 +0000 Received: from [85.158.139.211:30359] by server-9.bemta-5.messagelabs.com id C4/C6-08547-3766A415; Thu, 21 Mar 2013 01:46:27 +0000 X-Env-Sender: todd.wardzinski@progeny.net X-Msg-Ref: server-7.tower-206.messagelabs.com!1363830386!17925072!1 X-Originating-IP: [69.17.18.222] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25224 invoked from network); 21 Mar 2013 01:46:26 -0000 Received: from mail.progeny.net (HELO mail.progeny.net) (69.17.18.222) by server-7.tower-206.messagelabs.com with SMTP; 21 Mar 2013 01:46:26 -0000 Received: from ES2K7-HUB.progeny.net (Not Verified[192.168.22.23]) by mail.progeny.net with MailMarshal (v6, 8, 3, 9481) id ; Wed, 20 Mar 2013 21:46:25 -0400 Received: from ES2K7-MBX-1.progeny.net ([::1]) by ES2K7-HUB.progeny.net ([fe80::f09d:66d9:40a5:c66f%10]) with mapi; Wed, 20 Mar 2013 21:46:21 -0400 From: "Wardzinski, Todd" To: "xen-users@lists.xen.org" Date: Wed, 20 Mar 2013 21:46:20 -0400 Thread-Topic: Building Xen in network devoid areas Thread-Index: Ac4lvBNg3vaL+eRsSiWV+gLjuMqFMgAGUHvw Message-ID: <3A4BA757D72EC4419FA31D91DC15363C06E70E645E@ES2K7-MBX-1.progeny.net> References: <5148589D.4020307@kernel.ee> <5148A957.6010204@kodu.ee> <51499BAC.7060900@kodu.ee> <514A3925.8090702@kodu.ee> In-Reply-To: <514A3925.8090702@kodu.ee> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 21 Mar 2013 12:58:29 +0000 Subject: [Xen-users] Building Xen in network devoid areas X-BeenThere: xen-users@lists.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 All, I'm currently working on an issue where I need to build Xen in areas where I may not have any networking at all. I have searched the Internet for possible remedies, but, so far, have not come up with any good solutions. My goal is to take a build of Xen 4.2.1, put it on a server (Intel or AMD) that already has the Xen 4.2.1 required packages installed, and be able to build (make world) and install (make install) without having to access any git repositories. Any ideas on how best to solve this issue? Kind regards, Todd Wardzinski _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 21 16:29:38 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 16:29: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 1UIiLg-00008K-Az; Thu, 21 Mar 2013 16:28:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIiLe-00008F-GH for xen-users@lists.xen.org; Thu, 21 Mar 2013 16:28:14 +0000 Received: from [193.109.254.147:16299] by server-7.bemta-14.messagelabs.com id 4A/52-19255-D153B415; Thu, 21 Mar 2013 16:28:13 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1363883289!1785718!1 X-Originating-IP: [209.85.223.180] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9225 invoked from network); 21 Mar 2013 16:28:10 -0000 Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com) (209.85.223.180) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Mar 2013 16:28:10 -0000 Received: by mail-ie0-f180.google.com with SMTP id a11so3436356iee.25 for ; Thu, 21 Mar 2013 09:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=+L4pKVl9vDXZtSk53bEgcCsxRiQZEZB0XZkGTz1CiiE=; b=LVjLYy1/Lq+p232KfqqACP3kpZyVMLY69+cfS9bLfh13IbMSvtx1kD0OJjM+q/sQiA oH+W7eCb0DMpH0JfKszTAvUti4FbWkRR/v77lHv7UXPe8X8yYVR3NekfAkIbRj9TeaqO XkoBHLrs/iY3lDKXKSG/VAZ7vn36Odh+4tWPaQYkdW+l4a1KQ7kU+hIMU3E9/aYO6bxt dt8Djf+wE57b4230NLkPjj4IFsv1e0gMoRRQFY5vVekEpZoXoCTOGRaCjK8MXJMARnOo se5MbPLBQWoVf+117LIBqccqEx3UlWZh9f240od4lGSZkHVoC4dkr5/5DyV7qGMNLT/K Sk5A== MIME-Version: 1.0 X-Received: by 10.50.77.230 with SMTP id v6mr2679400igw.29.1363883288778; Thu, 21 Mar 2013 09:28:08 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Thu, 21 Mar 2013 09:28:08 -0700 (PDT) Date: Thu, 21 Mar 2013 10:28:08 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] xen 4.3 unstable custom network scripts X-BeenThere: xen-users@lists.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="===============8856791958056448002==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8856791958056448002== Content-Type: multipart/alternative; boundary=e89a8f3ba87ff161cc04d871d274 --e89a8f3ba87ff161cc04d871d274 Content-Type: text/plain; charset=ISO-8859-1 I am attempting to use openvswitch with xen unstable and there some scripts floating around. Is xl.conf being ignored there option for default vif script . I changed vif-bridge to vif-openvswitch but vif-vbridge is being executed. Does xl.con gets read when xl is being used or when services are started? What is best way of using openvswitch with xen. Adding interfaces to bridge first ? --e89a8f3ba87ff161cc04d871d274 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am attempting to use openvswitch with xen unstable and there some scripts= floating=A0around. Is xl.conf being ignored there option for default vif s= cript . I changed vif-bridge to vif-openvswitch but vif-vbridge is being ex= ecuted. Does xl.con gets read when xl is being used or when services are=A0= started? What is best way of=A0using=A0openvswitch with xen. Adding interfa= ces to bridge first ?=A0 --e89a8f3ba87ff161cc04d871d274-- --===============8856791958056448002== 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 --===============8856791958056448002==-- From xen-users-bounces@lists.xen.org Thu Mar 21 16:29:38 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 16:29: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 1UIiLg-00008K-Az; Thu, 21 Mar 2013 16:28:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIiLe-00008F-GH for xen-users@lists.xen.org; Thu, 21 Mar 2013 16:28:14 +0000 Received: from [193.109.254.147:16299] by server-7.bemta-14.messagelabs.com id 4A/52-19255-D153B415; Thu, 21 Mar 2013 16:28:13 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1363883289!1785718!1 X-Originating-IP: [209.85.223.180] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9225 invoked from network); 21 Mar 2013 16:28:10 -0000 Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com) (209.85.223.180) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Mar 2013 16:28:10 -0000 Received: by mail-ie0-f180.google.com with SMTP id a11so3436356iee.25 for ; Thu, 21 Mar 2013 09:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=+L4pKVl9vDXZtSk53bEgcCsxRiQZEZB0XZkGTz1CiiE=; b=LVjLYy1/Lq+p232KfqqACP3kpZyVMLY69+cfS9bLfh13IbMSvtx1kD0OJjM+q/sQiA oH+W7eCb0DMpH0JfKszTAvUti4FbWkRR/v77lHv7UXPe8X8yYVR3NekfAkIbRj9TeaqO XkoBHLrs/iY3lDKXKSG/VAZ7vn36Odh+4tWPaQYkdW+l4a1KQ7kU+hIMU3E9/aYO6bxt dt8Djf+wE57b4230NLkPjj4IFsv1e0gMoRRQFY5vVekEpZoXoCTOGRaCjK8MXJMARnOo se5MbPLBQWoVf+117LIBqccqEx3UlWZh9f240od4lGSZkHVoC4dkr5/5DyV7qGMNLT/K Sk5A== MIME-Version: 1.0 X-Received: by 10.50.77.230 with SMTP id v6mr2679400igw.29.1363883288778; Thu, 21 Mar 2013 09:28:08 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Thu, 21 Mar 2013 09:28:08 -0700 (PDT) Date: Thu, 21 Mar 2013 10:28:08 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] xen 4.3 unstable custom network scripts X-BeenThere: xen-users@lists.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="===============8856791958056448002==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8856791958056448002== Content-Type: multipart/alternative; boundary=e89a8f3ba87ff161cc04d871d274 --e89a8f3ba87ff161cc04d871d274 Content-Type: text/plain; charset=ISO-8859-1 I am attempting to use openvswitch with xen unstable and there some scripts floating around. Is xl.conf being ignored there option for default vif script . I changed vif-bridge to vif-openvswitch but vif-vbridge is being executed. Does xl.con gets read when xl is being used or when services are started? What is best way of using openvswitch with xen. Adding interfaces to bridge first ? --e89a8f3ba87ff161cc04d871d274 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am attempting to use openvswitch with xen unstable and there some scripts= floating=A0around. Is xl.conf being ignored there option for default vif s= cript . I changed vif-bridge to vif-openvswitch but vif-vbridge is being ex= ecuted. Does xl.con gets read when xl is being used or when services are=A0= started? What is best way of=A0using=A0openvswitch with xen. Adding interfa= ces to bridge first ?=A0 --e89a8f3ba87ff161cc04d871d274-- --===============8856791958056448002== 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 --===============8856791958056448002==-- From xen-users-bounces@lists.xen.org Thu Mar 21 17:10:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 17:10: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 1UIiz3-0000rT-C9; Thu, 21 Mar 2013 17:08:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIiz1-0000rD-2P for xen-users@lists.xen.org; Thu, 21 Mar 2013 17:08:55 +0000 Received: from [85.158.139.211:59325] by server-2.bemta-5.messagelabs.com id AC/D2-23989-6AE3B415; Thu, 21 Mar 2013 17:08:54 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1363885732!19375418!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8602 invoked from network); 21 Mar 2013 17:08:53 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Mar 2013 17:08:53 -0000 Received: from [200.52.43.60] (port=59895 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UIiyy-0001aw-6Q for xen-users@lists.xen.org; Thu, 21 Mar 2013 12:08:52 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id 55AB6A209 for ; Thu, 21 Mar 2013 11:03:39 -0600 (CST) Message-ID: <514B3EA3.10401@ondore.com> Date: Thu, 21 Mar 2013 11:08:51 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <1363850285276-5714943.post@n5.nabble.com> In-Reply-To: <1363850285276-5714943.post@n5.nabble.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] how to use GPLPV DRIVER? X-BeenThere: xen-users@lists.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 Hello. El 21/03/13 01:18, kay. kim. escribi=F3: > i googled the definition of GPLPV driver, i couldn't fine information wha= t i > want. > i'm curious about what does GPLPV driver and how to use it. > > please let me know well-made tutorial and docs for beginner. I'm not sure if there is such. http://wiki.xen.org/wiki/Xen_Windows_GplPv and = http://wiki.xensource.com/xenwiki/XenWindowsGplPv/ assumes you are = familiar with the concept of the device drivers. A HVM guest system can see devices, that are presented to it by the = hypervisor (Xen) and emulation layer (qemu). Some of those devices are = fully emulated and usually need very standard drivers, very compatible = but not too efficient, they are usually provided by the emulation layer. = Others are backed up directly by the hypervisor and real hardware, that = makes them much more efficient, but usually need a driver in the OS, = just as any other not-so-common hardware. So, GPLPV driver is just a driver form user's point of view, it allows = the OS to communicate and use a hardware device for the meant purpose. = It does not make much difference it the device is a real hardware on a = baremetal system, or a virtualized abstraction that just looks like a = PCI card to the guest system. About the usage, GPLPV driver is distributed as .msi package, basically = it installs itself. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 21 17:10:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 21 Mar 2013 17:10: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 1UIiz3-0000rT-C9; Thu, 21 Mar 2013 17:08:57 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIiz1-0000rD-2P for xen-users@lists.xen.org; Thu, 21 Mar 2013 17:08:55 +0000 Received: from [85.158.139.211:59325] by server-2.bemta-5.messagelabs.com id AC/D2-23989-6AE3B415; Thu, 21 Mar 2013 17:08:54 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1363885732!19375418!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8602 invoked from network); 21 Mar 2013 17:08:53 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Mar 2013 17:08:53 -0000 Received: from [200.52.43.60] (port=59895 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UIiyy-0001aw-6Q for xen-users@lists.xen.org; Thu, 21 Mar 2013 12:08:52 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id 55AB6A209 for ; Thu, 21 Mar 2013 11:03:39 -0600 (CST) Message-ID: <514B3EA3.10401@ondore.com> Date: Thu, 21 Mar 2013 11:08:51 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <1363850285276-5714943.post@n5.nabble.com> In-Reply-To: <1363850285276-5714943.post@n5.nabble.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] how to use GPLPV DRIVER? X-BeenThere: xen-users@lists.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 Hello. El 21/03/13 01:18, kay. kim. escribi=F3: > i googled the definition of GPLPV driver, i couldn't fine information wha= t i > want. > i'm curious about what does GPLPV driver and how to use it. > > please let me know well-made tutorial and docs for beginner. I'm not sure if there is such. http://wiki.xen.org/wiki/Xen_Windows_GplPv and = http://wiki.xensource.com/xenwiki/XenWindowsGplPv/ assumes you are = familiar with the concept of the device drivers. A HVM guest system can see devices, that are presented to it by the = hypervisor (Xen) and emulation layer (qemu). Some of those devices are = fully emulated and usually need very standard drivers, very compatible = but not too efficient, they are usually provided by the emulation layer. = Others are backed up directly by the hypervisor and real hardware, that = makes them much more efficient, but usually need a driver in the OS, = just as any other not-so-common hardware. So, GPLPV driver is just a driver form user's point of view, it allows = the OS to communicate and use a hardware device for the meant purpose. = It does not make much difference it the device is a real hardware on a = baremetal system, or a virtualized abstraction that just looks like a = PCI card to the guest system. About the usage, GPLPV driver is distributed as .msi package, basically = it installs itself. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 22 00:46:10 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 00:46: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 1UIq5v-0007tV-78; Fri, 22 Mar 2013 00:44:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIpms-0007qJ-4e for xen-users@lists.xen.org; Fri, 22 Mar 2013 00:24:50 +0000 Received: from [85.158.139.211:37052] by server-1.bemta-5.messagelabs.com id E8/52-14063-1D4AB415; Fri, 22 Mar 2013 00:24:49 +0000 X-Env-Sender: peter@selby.ca X-Msg-Ref: server-3.tower-206.messagelabs.com!1363911885!17989972!1 X-Originating-IP: [208.81.1.133] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, REPLY_TO_EMPTY X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18471 invoked from network); 22 Mar 2013 00:24:47 -0000 Received: from tyr.fudo.org (HELO tyr.fudo.org) (208.81.1.133) by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Mar 2013 00:24:47 -0000 Received: from localhost (localhost [127.0.0.1]) by tyr.fudo.org (Postfix) with ESMTP id E705CC0B03 for ; Thu, 21 Mar 2013 19:24:41 -0500 (CDT) X-Virus-Scanned: Debian amavisd-new at fudo.org Received: from tyr.fudo.org ([127.0.0.1]) by localhost (tyr.fudo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+5FTd3JUaZa for ; Thu, 21 Mar 2013 19:24:40 -0500 (CDT) Received: from webmail.selby.ca (unknown [208.81.1.133]) by tyr.fudo.org (Postfix) with ESMTP id 12D0FC9397 for ; Thu, 21 Mar 2013 19:24:40 -0500 (CDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_e662c4489f1b20e46011ef7551c3c240" Date: Thu, 21 Mar 2013 17:24:39 -0700 From: Peter Selby To: Message-ID: <50fa9f80810dccb5d751504117688c15@selby.ca> X-Sender: peter@selby.ca User-Agent: Fudo Roundcube Webmail/0.5.1 X-Mailman-Approved-At: Fri, 22 Mar 2013 00:44:30 +0000 Subject: [Xen-users] Experiencing kernel panic with SSH + LVM + Xen + significant amounts of data X-BeenThere: xen-users@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 --=_e662c4489f1b20e46011ef7551c3c240 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Hi all, I'm running into a kernel panic with Xen, under fairly specific circumstances. I'll post it here first, and follow up on xen-devel if it looks like it's a Xen bug. After some experimentation, it seems like the panic occurs under the following circumstances: 1) A significant amount of data is being moved 2) ...Onto (or off of?) an LVM partition 3) ...With SSH being involved somehow? 4) ...On Xen. Originally, I was trying to move a filesystem over the network via "dd if=... | ssh dd of=...", onto an LVM partition. The filesystem was 20G, and it repeatably crashed, usually after >25% transferred. I've also tried scp'ing files, using dd to transfer files, transferring the 20G FS to /dev/null, moving data OFF the host in question, etc. None of these triggered a panic. Moving large files on the host itself doesn't trigger a crash. However, piping data to an LVM partition (and in one case, piping from LVM to /dev/null) has triggered a crash, though the panic seems to occur simultaneously with an SSH login when it's happened. Minus an SSH login, I've successfully and repeatably moved data from LVM => LVM, LVM => null, yes => LVM, without a crash (logged in via SSH the whole time, I should add...there seems to be something about logins specifically) The system has ended up in a bad state more than once, too, which complicates things. It's possible that the crash triggered by moving OFF of LVM to /dev/null was the result of a bad state triggered earlier, because I wasn't able to reproduce it. No such issues occur if I'm not running Xen, which seems to rule out HW failure. To be clear, the host in question is the hypervisor, and the panics occur regardless of whether VMs are running. Version info: Essentially, it's a fully up-to-date Ubuntu 12.04 system. HW - HP ProLiant DL145 G2/K85NL (rackmount) Xen - 4.1.2-2ubuntu2.6 LVM: LVM version: 2.02.66(2) (2010-05-20) Library version: 1.02.48 (2010-05-20) Driver version: 4.22.0 SSH: OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012 Kernel - 3.2.0-39-generic I can provide more info on request. I've also attached a sample kernel panic. This one's a little old, but the crashes don't always dump to syslog, and the symptoms haven't changed. Thanks! Peter --=_e662c4489f1b20e46011ef7551c3c240 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=kernelpanic.txt Content-Disposition: attachment; filename=kernelpanic.txt RmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA1NzgyXSBCVUc6IHVu YWJsZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IDAwMDAwMDAxMDAwMDU0MDEK RmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA1ODExXSBJUDogWzxm ZmZmZmZmZjgxMTY0M2JiPl0gX19rbWFsbG9jKzB4N2IvMHgxOTAKRmViIDIyIDAxOjE4OjEyIG15 aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA1ODI4XSBQR0QgMWRjYTYxMDY3IFBVRCAwIApGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDU4MzddIE9vcHM6IDAwMDAg WyMxXSBTTVAgCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNTg0 NV0gQ1BVIDEgCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNTg0 OV0gTW9kdWxlcyBsaW5rZWQgaW46IGlwNnRhYmxlX2ZpbHRlciBpcDZfdGFibGVzIGVidGFibGVf bmF0IGVidGFibGVzIGlwdF9NQVNRVUVSQURFIGlwdGFibGVfbmF0IG5mX25hdCBuZl9jb25udHJh Y2tfaXB2NCBuZl9kZWZyYWdfaXB2NCB4dF9zdGF0ZSBuZl9jb25udHJhY2sgeGVuX2dudGRldiB4 ZW5fbmV0YmFjayBpcHRfUkVKRUNUIHhlbl9ibGtiYWNrIHhlbl9ldnRjaG4geHRfQ0hFQ0tTVU0g eGVuZnMgaXB0YWJsZV9tYW5nbGUgeHRfdGNwdWRwIGlwdGFibGVfZmlsdGVyIGlwX3RhYmxlcyB4 X3RhYmxlcyBicmlkZ2Ugc3RwIG5vdXZlYXUgdHRtIGRybV9rbXNfaGVscGVyIGRybSBhbWQ2NF9l ZGFjX21vZCBlZGFjX2NvcmUgazh0ZW1wIGVkYWNfbWNlX2FtZCBpMmNfbmZvcmNlMiBpMmNfYWxn b19iaXQgc2hwY2hwIG14bV93bWkgd21pIG1hY19oaWQgdmlkZW8gcHNtb3VzZSBzZXJpb19yYXcg bHAgcGFycG9ydCB1c2JoaWQgaGlkIHNhdGFfbnYgdGczIHBhdGFfYW1kCkZlYiAyMiAwMToxODox MiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNTk2MV0gCkZlYiAyMiAwMToxODoxMiBteWhv c3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNTk2Nl0gUGlkOiAxNzk4LCBjb21tOiBiYXNoIE5vdCB0 YWludGVkIDMuMi4wLTM4LWdlbmVyaWMgIzYxLVVidW50dSBIUCBQcm9MaWFudCBETDE0NSBHMi9L ODVOTApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDU5ODBdIFJJ UDogZTAzMDpbPGZmZmZmZmZmODExNjQzYmI+XSAgWzxmZmZmZmZmZjgxMTY0M2JiPl0gX19rbWFs bG9jKzB4N2IvMHgxOTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUu ODA1OTkyXSBSU1A6IGUwMmI6ZmZmZjg4MDE4ZjY2N2NlMCAgRUZMQUdTOiAwMDAxMDIwMgpGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDU5OTldIFJBWDogMDAwMDAw MDAwMDAwMDAwMCBSQlg6IDAwMDAwMDAwMDAwMDA4MDAgUkNYOiAwMDAwMDAwMDAwNWExN2ViCkZl YiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjAwN10gUkRYOiAwMDAw MDAwMDAwNWExN2VhIFJTSTogMDAwMDAwMDAwMDAxNjcwMCBSREk6IDAwMDAwMDAwMDAwMDA3ZmYK RmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MDE1XSBSQlA6IGZm ZmY4ODAxOGY2NjdkMzAgUjA4OiBmZmZmODgwMWYxZTk2NzAwIFIwOTogZmZmZjg4MDFkYzA1M2Ni MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYwMjNdIFIxMDog MDAwMDAwMDAwMDAwMDAwMCBSMTE6IDAwMDAwMDAwMDAwMTZjMTggUjEyOiBmZmZmODgwMWU1NDAy YzAwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjAzMV0gUjEz OiAwMDAwMDAwMTAwMDA1NDAxIFIxNDogMDAwMDAwMDAwMDAwMDJkMCBSMTU6IGZmZmZmZmZmODEx OTVlNjUKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MDQyXSBG UzogIDAwMDA3ZmEzYTk2NzU3MDAoMDAwMCkgR1M6ZmZmZjg4MDFmMWU4MDAwMCgwMDAwKSBrbmxH UzowMDAwMDAwMDAwMDAwMDAwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAg ODQ1LjgwNjA1Ml0gQ1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1 MDAzYgpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYwNTldIENS MjogMDAwMDAwMDEwMDAwNTQwMSBDUjM6IDAwMDAwMDAxOGYwMTEwMDAgQ1I0OiAwMDAwMDAwMDAw MDAwNjYwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjA2N10g RFIwOiAwMDAwMDAwMDAwMDAwMDAwIERSMTogMDAwMDAwMDAwMDAwMDAwMCBEUjI6IDAwMDAwMDAw MDAwMDAwMDAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MDc2 XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMGZmZmYwZmYwIERSNzogMDAwMDAw MDAwMDAwMDQwMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYw ODRdIFByb2Nlc3MgYmFzaCAocGlkOiAxNzk4LCB0aHJlYWRpbmZvIGZmZmY4ODAxOGY2NjYwMDAs IHRhc2sgZmZmZjg4MDFkZjBmODAwMCkKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA2MDkzXSBTdGFjazoKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA2MDk3XSAgZmZmZjg4MDE4ZjY2N2NmMCBmZmZmZmZmZjgxMDFiZTU5IDAwMDAw MDAwMDAwMDAyODIgMDAwMDAwMDAwMDAwMDgwMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBr ZXJuZWw6IFsgIDg0NS44MDYxMTFdICBmZmZmODgwMThmNjY3ZDYwIDAwMDAwMDAwMDAwMDA4MDAg ZmZmZjg4MDFkYWU4MTU0MCBmZmZmODgwMWRjNzA5MDkwCkZlYiAyMiAwMToxODoxMiBteWhvc3Ru YW1lIGtlcm5lbDogWyAgODQ1LjgwNjEyNF0gIGZmZmY4ODAxOGY2NjdlM2MgMDAwMDAwMDAwMDAw MDEwMCBmZmZmODgwMThmNjY3ZDUwIGZmZmZmZmZmODExOTVlNjUKRmViIDIyIDAxOjE4OjEyIG15 aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MTM4XSBDYWxsIFRyYWNlOgpGZWIgMjIgMDE6MTg6 MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYxNDZdICBbPGZmZmZmZmZmODEwMWJlNTk+ XSA/IHNjaGVkX2Nsb2NrKzB4OS8weDEwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5l bDogWyAgODQ1LjgwNjE1NV0gIFs8ZmZmZmZmZmY4MTE5NWU2NT5dIGFsbG9jX2ZkbWVtKzB4MjUv MHg1MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYxNjNdICBb PGZmZmZmZmZmODExOTVmMDA+XSBhbGxvY19mZHRhYmxlKzB4NzAvMHgxMDAKRmViIDIyIDAxOjE4 OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MTcxXSAgWzxmZmZmZmZmZjgxMTk2M2U0 Pl0gZHVwX2ZkKzB4MjQ0LzB4MmYwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDog WyAgODQ1LjgwNjE4MF0gIFs8ZmZmZmZmZmY4MTA2NjZlYj5dIGNvcHlfcHJvY2Vzcy5wYXJ0LjE4 KzB4NjRiLzB4ZTMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1Ljgw NjE5Ml0gIFs8ZmZmZmZmZmY4MTY2MGY1MD5dID8gZG9fcGFnZV9mYXVsdCsweDIxMC8weDUyMApG ZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYyMDBdICBbPGZmZmZm ZmZmODEwNjZmNDc+XSBjb3B5X3Byb2Nlc3MrMHg3Ny8weDgwCkZlYiAyMiAwMToxODoxMiBteWhv c3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjIwN10gIFs8ZmZmZmZmZmY4MTA2NzA5YT5dIGRvX2Zv cmsrMHhmYS8weDJmMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44 MDYyMTddICBbPGZmZmZmZmZmODEwN2IyMmI+XSA/IHJlY2FsY19zaWdwZW5kaW5nKzB4MWIvMHg1 MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYyMjVdICBbPGZm ZmZmZmZmODEwN2JhYjc+XSA/IF9fc2V0X3Rhc2tfYmxvY2tlZCsweDM3LzB4ODAKRmViIDIyIDAx OjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MjM5XSAgWzxmZmZmZmZmZjgxMDdk ZWRiPl0gPyBzZXRfY3VycmVudF9ibG9ja2VkKzB4NWIvMHg3MApGZWIgMjIgMDE6MTg6MTIgbXlo b3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYyNDhdICBbPGZmZmZmZmZmODEwMWQ2NTg+XSBzeXNf Y2xvbmUrMHgyOC8weDMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1 LjgwNjI1Nl0gIFs8ZmZmZmZmZmY4MTY2NWNhMz5dIHN0dWJfY2xvbmUrMHgxMy8weDIwCkZlYiAy MiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjI2NF0gIFs8ZmZmZmZmZmY4 MTY2NTk4Mj5dID8gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFiCkZlYiAyMiAwMToxODox MiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjI3MV0gQ29kZTogMDAgNGQgOGIgMDQgMjQg NjUgNGMgMDMgMDQgMjUgNTAgZGEgMDAgMDAgNDkgOGIgNTAgMDggNGQgOGIgMjggNGQgODUgZWQg MGYgODQgZDcgMDAgMDAgMDAgNDkgNjMgNDQgMjQgMjAgNDkgOGIgMzQgMjQgNDggOGQgNGEgMDEg PDQ5PiA4YiA1YyAwNSAwMCA0YyA4OSBlOCBlOCA3OCA0ZSAxYiAwMCA2NiA2NiA5MCA4NCBjMCA3 NCBjMiA0ZCAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2Mzc0 XSBSSVAgIFs8ZmZmZmZmZmY4MTE2NDNiYj5dIF9fa21hbGxvYysweDdiLzB4MTkwCkZlYiAyMiAw MToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjM4M10gIFJTUCA8ZmZmZjg4MDE4 ZjY2N2NlMD4KRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2Mzg4 XSBDUjI6IDAwMDAwMDAxMDAwMDU0MDEKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA4MjEyXSBCVUc6IHVuYWJsZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1 ZXN0IGF0IDAwMDAwMDAxMDAwMDU0MDEKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA4MjEyXSBJUDogWzxmZmZmZmZmZjgxMTY0M2JiPl0gX19rbWFsbG9jKzB4N2Iv MHgxOTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSBQ R0QgMWRjYTYxMDY3IFBVRCAwIApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsg IDg0NS44MDgyMTJdIE9vcHM6IDAwMDAgWyMyXSBTTVAgCkZlYiAyMiAwMToxODoxMiBteWhvc3Ru YW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gQ1BVIDEgCkZlYiAyMiAwMToxODoxMiBteWhvc3Ru YW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gTW9kdWxlcyBsaW5rZWQgaW46IGlwNnRhYmxlX2Zp bHRlciBpcDZfdGFibGVzIGVidGFibGVfbmF0IGVidGFibGVzIGlwdF9NQVNRVUVSQURFIGlwdGFi bGVfbmF0IG5mX25hdCBuZl9jb25udHJhY2tfaXB2NCBuZl9kZWZyYWdfaXB2NCB4dF9zdGF0ZSBu Zl9jb25udHJhY2sgeGVuX2dudGRldiB4ZW5fbmV0YmFjayBpcHRfUkVKRUNUIHhlbl9ibGtiYWNr IHhlbl9ldnRjaG4geHRfQ0hFQ0tTVU0geGVuZnMgaXB0YWJsZV9tYW5nbGUgeHRfdGNwdWRwIGlw dGFibGVfZmlsdGVyIGlwX3RhYmxlcyB4X3RhYmxlcyBicmlkZ2Ugc3RwIG5vdXZlYXUgdHRtIGRy bV9rbXNfaGVscGVyIGRybSBhbWQ2NF9lZGFjX21vZCBlZGFjX2NvcmUgazh0ZW1wIGVkYWNfbWNl X2FtZCBpMmNfbmZvcmNlMiBpMmNfYWxnb19iaXQgc2hwY2hwIG14bV93bWkgd21pIG1hY19oaWQg dmlkZW8gcHNtb3VzZSBzZXJpb19yYXcgbHAgcGFycG9ydCB1c2JoaWQgaGlkIHNhdGFfbnYgdGcz IHBhdGFfYW1kCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIx Ml0gCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gUGlk OiAxNzk4LCBjb21tOiBiYXNoIE5vdCB0YWludGVkIDMuMi4wLTM4LWdlbmVyaWMgIzYxLVVidW50 dSBIUCBQcm9MaWFudCBETDE0NSBHMi9LODVOTApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBr ZXJuZWw6IFsgIDg0NS44MDgyMTJdIFJJUDogZTAzMDpbPGZmZmZmZmZmODExNjQzYmI+XSAgWzxm ZmZmZmZmZjgxMTY0M2JiPl0gX19rbWFsbG9jKzB4N2IvMHgxOTAKRmViIDIyIDAxOjE4OjEyIG15 aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSBSU1A6IGUwMmI6ZmZmZjg4MDE4ZjY2NzVj OCAgRUZMQUdTOiAwMDAxMDAwMgpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsg IDg0NS44MDgyMTJdIFJBWDogMDAwMDAwMDAwMDAwMDAwMCBSQlg6IGZmZmY4ODAxZGU0ODM2Mzgg UkNYOiAwMDAwMDAwMDAwNWExN2ViCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDog WyAgODQ1LjgwODIxMl0gUkRYOiAwMDAwMDAwMDAwNWExN2VhIFJTSTogMDAwMDAwMDAwMDAxNjcw MCBSREk6IDAwMDAwMDAwMDAwMDA0NWYKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA4MjEyXSBSQlA6IGZmZmY4ODAxOGY2Njc2MTggUjA4OiBmZmZmODgwMWYxZTk2 NzAwIFIwOTogMDAwMDAwMDAwMDAwMDAxZgpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJu ZWw6IFsgIDg0NS44MDgyMTJdIFIxMDogMDAwMDAwMDAwMDAwMDAwMCBSMTE6IDAwMDAwMDAwMDAw MDAwMDAgUjEyOiBmZmZmODgwMWU1NDAyYzAwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtl cm5lbDogWyAgODQ1LjgwODIxMl0gUjEzOiAwMDAwMDAwMTAwMDA1NDAxIFIxNDogMDAwMDAwMDAw MDAwODBkMCBSMTU6IGZmZmZmZmZmYTAwZjQ5M2MKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUg a2VybmVsOiBbICA4NDUuODA4MjEyXSBbZHJtXSBub3V2ZWF1IDAwMDA6MDE6MDUuMDogR1BVIGxv Y2t1cCAtIHN3aXRjaGluZyB0byBzb2Z0d2FyZSBmYmNvbgpGZWIgMjIgMDE6MTg6MTIgbXlob3N0 bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdIEZTOiAgMDAwMDdmYTNhOTY3NTcwMCgwMDAwKSBH UzpmZmZmODgwMWYxZTgwMDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDAKRmViIDIyIDAx OjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSBDUzogIGUwMzMgRFM6IDAw MDAgRVM6IDAwMDAgQ1IwOiAwMDAwMDAwMDgwMDUwMDNiCkZlYiAyMiAwMToxODoxMiBteWhvc3Ru YW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gQ1IyOiAwMDAwMDAwMTAwMDA1NDAxIENSMzogMDAw MDAwMDE4ZjAxMTAwMCBDUjQ6IDAwMDAwMDAwMDAwMDA2NjAKRmViIDIyIDAxOjE4OjEyIG15aG9z dG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSBEUjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAw MDAwMDAwMDAwMDAwMDAwIERSMjogMDAwMDAwMDAwMDAwMDAwMApGZWIgMjIgMDE6MTg6MTIgbXlo b3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdIERSMzogMDAwMDAwMDAwMDAwMDAwMCBEUjY6 IDAwMDAwMDAwZmZmZjBmZjAgRFI3OiAwMDAwMDAwMDAwMDAwNDAwCkZlYiAyMiAwMToxODoxMiBt eWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gUHJvY2VzcyBiYXNoIChwaWQ6IDE3OTgs IHRocmVhZGluZm8gZmZmZjg4MDE4ZjY2NjAwMCwgdGFzayBmZmZmODgwMWRmMGY4MDAwKQpGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdIFN0YWNrOgpGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBmZmZmODgwMWRj YjgxMDAwIDAwMDAwMDAwMDAwMDAwMTAgZmZmZjg4MDE4ZjY2NzYyOCAwMDAwMDAwMDAwMDAwNDYw CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIGZmZmY4 ODAxMDAwMDAxMjAgZmZmZjg4MDFkZTQ4MzYzOCBmZmZmODgwMWRjMTk1YzA4IGZmZmY4ODAxZGU0 ODM4MDAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAg ZmZmZjg4MDFkY2I4MjgwMCBmZmZmODgwMWRjYjg2YmEwIGZmZmY4ODAxOGY2Njc2ZTggZmZmZmZm ZmZhMDBmNDkzYwpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgy MTJdIENhbGwgVHJhY2U6CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1 LjgwODIxMl0gIFs8ZmZmZmZmZmZhMDBmNDkzYz5dIGRybV9jcnRjX2hlbHBlcl9zZXRfY29uZmln KzB4ZWMvMHhhZjAgW2RybV9rbXNfaGVscGVyXQpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBr ZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEzNTc0MzE+XSA/IGZiX3NldF92YXIr MHgxYTEvMHgzMTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4 MjEyXSAgWzxmZmZmZmZmZmEwMThlMGIyPl0gPyBub3V2ZWF1X2ZiY29uX2ltYWdlYmxpdCsweGMy LzB4MTEwIFtub3V2ZWF1XQpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0 NS44MDgyMTJdICBbPGZmZmZmZmZmYTAwZjE3ODY+XSBkcm1fZmJfaGVscGVyX3Bhbl9kaXNwbGF5 KzB4ODYvMHhkMCBbZHJtX2ttc19oZWxwZXJdCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtl cm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTM1NmFmZD5dIGZiX3Bhbl9kaXNwbGF5 KzB4YmQvMHgxNzAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4 MjEyXSAgWzxmZmZmZmZmZjgxMzY3OTY5Pl0gYml0X3VwZGF0ZV9zdGFydCsweDI5LzB4NjAKRmVi IDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZm ZjgxMzY2MjYyPl0gZmJjb25fc3dpdGNoKzB4M2IyLzB4NTYwCkZlYiAyMiAwMToxODoxMiBteWhv c3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTNkMWZlOT5dIHJlZHJh d19zY3JlZW4rMHgxODkvMHgyYTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBb ICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxMzY0OTRhPl0gZmJjb25fYmxhbmsrMHgyMWEvMHgy ZDAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxm ZmZmZmZmZjgxNjVkNWFlPl0gPyBfcmF3X3NwaW5fdW5sb2NrX2lycXJlc3RvcmUrMHgxZS8weDMw CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZm ZmZmZmY4MTA5MTNjMj5dID8gdXArMHgzMi8weDUwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1l IGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTY1ZDYyZT5dID8gX3Jhd19zcGlu X2xvY2tfaXJxc2F2ZSsweDJlLzB4NDAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxMDc3Zjg4Pl0gPyBsb2NrX3RpbWVyX2Jhc2Uu aXNyYS4yOSsweDM4LzB4NzAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4 NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxNjVkNWFlPl0gPyBfcmF3X3NwaW5fdW5sb2NrX2lycXJl c3RvcmUrMHgxZS8weDMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1 LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTA3OTM0Mz5dID8gbW9kX3RpbWVyKzB4MTQzLzB4MmYwCkZl YiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZm ZmY4MTNkMmNlYz5dIGRvX3VuYmxhbmtfc2NyZWVuLnBhcnQuMTkrMHg5Yy8weDE3MApGZWIgMjIg MDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEz ZDJlMDg+XSBkb191bmJsYW5rX3NjcmVlbisweDQ4LzB4ODAKRmViIDIyIDAxOjE4OjEyIG15aG9z dG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxM2QyZTUwPl0gdW5ibGFu a19zY3JlZW4rMHgxMC8weDIwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAg ODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTMxYmI0ZD5dIGJ1c3Rfc3BpbmxvY2tzKzB4MWQvMHg0 MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZm ZmZmZmZmODE2NWU0YWY+XSBvb3BzX2VuZCsweDNmLzB4ZjAKRmViIDIyIDAxOjE4OjEyIG15aG9z dG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxNjQzN2ZlPl0gbm9fY29u dGV4dCsweDE1MC8weDE1ZApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0 NS44MDgyMTJdICBbPGZmZmZmZmZmODE2NDM5ZDQ+XSBfX2JhZF9hcmVhX25vc2VtYXBob3JlKzB4 MWM5LzB4MWU4CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIx Ml0gIFs8ZmZmZmZmZmY4MTY0M2E0ZD5dIGJhZF9hcmVhKzB4NDUvMHg0ZQpGZWIgMjIgMDE6MTg6 MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODE2NjEyNTU+ XSBkb19wYWdlX2ZhdWx0KzB4NTE1LzB4NTIwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtl cm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTEyMTQzZj5dID8gZ2V0X3BhZ2VfZnJv bV9mcmVlbGlzdCsweDFjZi8weDU0MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6 IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEwMDRkNjI+XSA/IHhlbl9tY19mbHVzaCsweGIy LzB4MWMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0g IFs8ZmZmZmZmZmY4MTE5NWU2NT5dID8gYWxsb2NfZmRtZW0rMHgyNS8weDUwCkZlYiAyMiAwMTox ODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTY1ZGFm NT5dIHBhZ2VfZmF1bHQrMHgyNS8weDMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5l bDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTE5NWU2NT5dID8gYWxsb2NfZmRtZW0rMHgy NS8weDUwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0g IFs8ZmZmZmZmZmY4MTE2NDNiYj5dID8gX19rbWFsbG9jKzB4N2IvMHgxOTAKRmViIDIyIDAxOjE4 OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxMDFiZTU5 Pl0gPyBzY2hlZF9jbG9jaysweDkvMHgxMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJu ZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODExOTVlNjU+XSBhbGxvY19mZG1lbSsweDI1 LzB4NTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAg WzxmZmZmZmZmZjgxMTk1ZjAwPl0gYWxsb2NfZmR0YWJsZSsweDcwLzB4MTAwCkZlYiAyMiAwMTox ODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTE5NjNl ND5dIGR1cF9mZCsweDI0NC8weDJmMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6 IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEwNjY2ZWI+XSBjb3B5X3Byb2Nlc3MucGFydC4x OCsweDY0Yi8weGUzMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44 MDgyMTJdICBbPGZmZmZmZmZmODE2NjBmNTA+XSA/IGRvX3BhZ2VfZmF1bHQrMHgyMTAvMHg1MjAK RmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZm ZmZmZjgxMDY2ZjQ3Pl0gY29weV9wcm9jZXNzKzB4NzcvMHg4MApGZWIgMjIgMDE6MTg6MTIgbXlo b3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEwNjcwOWE+XSBkb19m b3JrKzB4ZmEvMHgyZjAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUu ODA4MjEyXSAgWzxmZmZmZmZmZjgxMDdiMjJiPl0gPyByZWNhbGNfc2lncGVuZGluZysweDFiLzB4 NTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxm ZmZmZmZmZjgxMDdiYWI3Pl0gPyBfX3NldF90YXNrX2Jsb2NrZWQrMHgzNy8weDgwCkZlYiAyMiAw MToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTA3 ZGVkYj5dID8gc2V0X2N1cnJlbnRfYmxvY2tlZCsweDViLzB4NzAKRmViIDIyIDAxOjE4OjEyIG15 aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxMDFkNjU4Pl0gc3lz X2Nsb25lKzB4MjgvMHgzMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0 NS44MDgyMTJdICBbPGZmZmZmZmZmODE2NjVjYTM+XSBzdHViX2Nsb25lKzB4MTMvMHgyMApGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZm ODE2NjU5ODI+XSA/IHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYgpGZWIgMjIgMDE6MTg6 MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdIENvZGU6IDAwIDRkIDhiIDA0IDI0 IDY1IDRjIDAzIDA0IDI1IDUwIGRhIDAwIDAwIDQ5IDhiIDUwIDA4IDRkIDhiIDI4IDRkIDg1IGVk IDBmIDg0IGQ3IDAwIDAwIDAwIDQ5IDYzIDQ0IDI0IDIwIDQ5IDhiIDM0IDI0IDQ4IDhkIDRhIDAx IDw0OT4gOGIgNWMgMDUgMDAgNGMgODkgZTggZTggNzggNGUgMWIgMDAgNjYgNjYgOTAgODQgYzAg NzQgYzIgNGQgCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIx Ml0gUklQICBbPGZmZmZmZmZmODExNjQzYmI+XSBfX2ttYWxsb2MrMHg3Yi8weDE5MApGZWIgMjIg MDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBSU1AgPGZmZmY4ODAx OGY2Njc1Yzg+CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIx Ml0gQ1IyOiAwMDAwMDAwMTAwMDA1NDAxCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5l bDogWyAgODQ1LjgwODIxMl0gLS0tWyBlbmQgdHJhY2UgYmZhMzIxYTNmNmRjNjk5NyBdLS0tCkZl YiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gW2RybV0gbm91 dmVhdSAwMDAwOjAxOjA1LjA6IFBGSUZPX0RNQV9QVVNIRVIgLSBDaCAwIEdldCAweDAwMDExMDA0 IFB1dCAweDAwMDBjZTY4IFN0YXRlIDB4ODAwMDAwMDAgKGVycjogSU5WQUxJRF9DTUQpIFB1c2gg MHgwMDAwMDAwMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0Ni4xNzMx MzRdIFdhcm5pbmc6IGRldiAocHRzMSkgdHR5LT5jb3VudCgyKSAhPSAjZmQncygxKSBpbiB0dHlf cmVsZWFzZV9kZXYKRmViIDIyIDAxOjE5OjIyIG15aG9zdG5hbWUga2VybmVsOiBbICA5MDYuMTg0 MDU5XSBJTkZPOiByY3Vfc2NoZWQgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHsgMH0g KGRldGVjdGVkIGJ5IDIsIHQ9MTUwMDIgamlmZmllcykKRmViIDIyIDAxOjE5OjIyIG15aG9zdG5h bWUga2VybmVsOiBbICA5MDYuMTg4MDUyXSBzZW5kaW5nIE5NSSB0byBhbGwgQ1BVczoKRmViIDIy IDAxOjE5OjMyIG15aG9zdG5hbWUga2VybmVsOiBbICA5MTYuMTE2MDU3XSBJTkZPOiByY3VfYmgg ZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHsgMH0gKGRldGVjdGVkIGJ5IDEsIHQ9MTc0 ODQgamlmZmllcykKRmViIDIyIDAxOjE5OjMyIG15aG9zdG5hbWUga2VybmVsOiBbICA5MTYuMTIw MDUyXSBzZW5kaW5nIE5NSSB0byBhbGwgQ1BVczoKRmViIDIyIDAxOjIyOjIyIG15aG9zdG5hbWUg a2VybmVsOiBbIDEwODYuMzEyMDU4XSBJTkZPOiByY3Vfc2NoZWQgZGV0ZWN0ZWQgc3RhbGxzIG9u IENQVXMvdGFza3M6IHsgMH0gKGRldGVjdGVkIGJ5IDIsIHQ9NjAwMzQgamlmZmllcykKRmViIDIy IDAxOjIyOjIyIG15aG9zdG5hbWUga2VybmVsOiBbIDEwODYuMzE2MDUyXSBzZW5kaW5nIE5NSSB0 byBhbGwgQ1BVczoKRmViIDIyIDAxOjIyOjMyIG15aG9zdG5hbWUga2VybmVsOiBbIDEwOTYuMjQ0 MDU4XSBJTkZPOiByY3VfYmggZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHsgMH0gKGRl dGVjdGVkIGJ5IDEsIHQ9NjI1MTYgamlmZmllcykKRmViIDIyIDAxOjIyOjMyIG15aG9zdG5hbWUg a2VybmVsOiBbIDEwOTYuMjQ4MDUyXSBzZW5kaW5nIE5NSSB0byBhbGwgQ1BVczoK --=_e662c4489f1b20e46011ef7551c3c240 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 --=_e662c4489f1b20e46011ef7551c3c240-- From xen-users-bounces@lists.xen.org Fri Mar 22 00:46:10 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 00:46: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 1UIq5v-0007tV-78; Fri, 22 Mar 2013 00:44:31 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIpms-0007qJ-4e for xen-users@lists.xen.org; Fri, 22 Mar 2013 00:24:50 +0000 Received: from [85.158.139.211:37052] by server-1.bemta-5.messagelabs.com id E8/52-14063-1D4AB415; Fri, 22 Mar 2013 00:24:49 +0000 X-Env-Sender: peter@selby.ca X-Msg-Ref: server-3.tower-206.messagelabs.com!1363911885!17989972!1 X-Originating-IP: [208.81.1.133] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, REPLY_TO_EMPTY X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18471 invoked from network); 22 Mar 2013 00:24:47 -0000 Received: from tyr.fudo.org (HELO tyr.fudo.org) (208.81.1.133) by server-3.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Mar 2013 00:24:47 -0000 Received: from localhost (localhost [127.0.0.1]) by tyr.fudo.org (Postfix) with ESMTP id E705CC0B03 for ; Thu, 21 Mar 2013 19:24:41 -0500 (CDT) X-Virus-Scanned: Debian amavisd-new at fudo.org Received: from tyr.fudo.org ([127.0.0.1]) by localhost (tyr.fudo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+5FTd3JUaZa for ; Thu, 21 Mar 2013 19:24:40 -0500 (CDT) Received: from webmail.selby.ca (unknown [208.81.1.133]) by tyr.fudo.org (Postfix) with ESMTP id 12D0FC9397 for ; Thu, 21 Mar 2013 19:24:40 -0500 (CDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_e662c4489f1b20e46011ef7551c3c240" Date: Thu, 21 Mar 2013 17:24:39 -0700 From: Peter Selby To: Message-ID: <50fa9f80810dccb5d751504117688c15@selby.ca> X-Sender: peter@selby.ca User-Agent: Fudo Roundcube Webmail/0.5.1 X-Mailman-Approved-At: Fri, 22 Mar 2013 00:44:30 +0000 Subject: [Xen-users] Experiencing kernel panic with SSH + LVM + Xen + significant amounts of data X-BeenThere: xen-users@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 --=_e662c4489f1b20e46011ef7551c3c240 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Hi all, I'm running into a kernel panic with Xen, under fairly specific circumstances. I'll post it here first, and follow up on xen-devel if it looks like it's a Xen bug. After some experimentation, it seems like the panic occurs under the following circumstances: 1) A significant amount of data is being moved 2) ...Onto (or off of?) an LVM partition 3) ...With SSH being involved somehow? 4) ...On Xen. Originally, I was trying to move a filesystem over the network via "dd if=... | ssh dd of=...", onto an LVM partition. The filesystem was 20G, and it repeatably crashed, usually after >25% transferred. I've also tried scp'ing files, using dd to transfer files, transferring the 20G FS to /dev/null, moving data OFF the host in question, etc. None of these triggered a panic. Moving large files on the host itself doesn't trigger a crash. However, piping data to an LVM partition (and in one case, piping from LVM to /dev/null) has triggered a crash, though the panic seems to occur simultaneously with an SSH login when it's happened. Minus an SSH login, I've successfully and repeatably moved data from LVM => LVM, LVM => null, yes => LVM, without a crash (logged in via SSH the whole time, I should add...there seems to be something about logins specifically) The system has ended up in a bad state more than once, too, which complicates things. It's possible that the crash triggered by moving OFF of LVM to /dev/null was the result of a bad state triggered earlier, because I wasn't able to reproduce it. No such issues occur if I'm not running Xen, which seems to rule out HW failure. To be clear, the host in question is the hypervisor, and the panics occur regardless of whether VMs are running. Version info: Essentially, it's a fully up-to-date Ubuntu 12.04 system. HW - HP ProLiant DL145 G2/K85NL (rackmount) Xen - 4.1.2-2ubuntu2.6 LVM: LVM version: 2.02.66(2) (2010-05-20) Library version: 1.02.48 (2010-05-20) Driver version: 4.22.0 SSH: OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012 Kernel - 3.2.0-39-generic I can provide more info on request. I've also attached a sample kernel panic. This one's a little old, but the crashes don't always dump to syslog, and the symptoms haven't changed. Thanks! Peter --=_e662c4489f1b20e46011ef7551c3c240 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=kernelpanic.txt Content-Disposition: attachment; filename=kernelpanic.txt RmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA1NzgyXSBCVUc6IHVu YWJsZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IDAwMDAwMDAxMDAwMDU0MDEK RmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA1ODExXSBJUDogWzxm ZmZmZmZmZjgxMTY0M2JiPl0gX19rbWFsbG9jKzB4N2IvMHgxOTAKRmViIDIyIDAxOjE4OjEyIG15 aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA1ODI4XSBQR0QgMWRjYTYxMDY3IFBVRCAwIApGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDU4MzddIE9vcHM6IDAwMDAg WyMxXSBTTVAgCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNTg0 NV0gQ1BVIDEgCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNTg0 OV0gTW9kdWxlcyBsaW5rZWQgaW46IGlwNnRhYmxlX2ZpbHRlciBpcDZfdGFibGVzIGVidGFibGVf bmF0IGVidGFibGVzIGlwdF9NQVNRVUVSQURFIGlwdGFibGVfbmF0IG5mX25hdCBuZl9jb25udHJh Y2tfaXB2NCBuZl9kZWZyYWdfaXB2NCB4dF9zdGF0ZSBuZl9jb25udHJhY2sgeGVuX2dudGRldiB4 ZW5fbmV0YmFjayBpcHRfUkVKRUNUIHhlbl9ibGtiYWNrIHhlbl9ldnRjaG4geHRfQ0hFQ0tTVU0g eGVuZnMgaXB0YWJsZV9tYW5nbGUgeHRfdGNwdWRwIGlwdGFibGVfZmlsdGVyIGlwX3RhYmxlcyB4 X3RhYmxlcyBicmlkZ2Ugc3RwIG5vdXZlYXUgdHRtIGRybV9rbXNfaGVscGVyIGRybSBhbWQ2NF9l ZGFjX21vZCBlZGFjX2NvcmUgazh0ZW1wIGVkYWNfbWNlX2FtZCBpMmNfbmZvcmNlMiBpMmNfYWxn b19iaXQgc2hwY2hwIG14bV93bWkgd21pIG1hY19oaWQgdmlkZW8gcHNtb3VzZSBzZXJpb19yYXcg bHAgcGFycG9ydCB1c2JoaWQgaGlkIHNhdGFfbnYgdGczIHBhdGFfYW1kCkZlYiAyMiAwMToxODox MiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNTk2MV0gCkZlYiAyMiAwMToxODoxMiBteWhv c3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNTk2Nl0gUGlkOiAxNzk4LCBjb21tOiBiYXNoIE5vdCB0 YWludGVkIDMuMi4wLTM4LWdlbmVyaWMgIzYxLVVidW50dSBIUCBQcm9MaWFudCBETDE0NSBHMi9L ODVOTApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDU5ODBdIFJJ UDogZTAzMDpbPGZmZmZmZmZmODExNjQzYmI+XSAgWzxmZmZmZmZmZjgxMTY0M2JiPl0gX19rbWFs bG9jKzB4N2IvMHgxOTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUu ODA1OTkyXSBSU1A6IGUwMmI6ZmZmZjg4MDE4ZjY2N2NlMCAgRUZMQUdTOiAwMDAxMDIwMgpGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDU5OTldIFJBWDogMDAwMDAw MDAwMDAwMDAwMCBSQlg6IDAwMDAwMDAwMDAwMDA4MDAgUkNYOiAwMDAwMDAwMDAwNWExN2ViCkZl YiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjAwN10gUkRYOiAwMDAw MDAwMDAwNWExN2VhIFJTSTogMDAwMDAwMDAwMDAxNjcwMCBSREk6IDAwMDAwMDAwMDAwMDA3ZmYK RmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MDE1XSBSQlA6IGZm ZmY4ODAxOGY2NjdkMzAgUjA4OiBmZmZmODgwMWYxZTk2NzAwIFIwOTogZmZmZjg4MDFkYzA1M2Ni MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYwMjNdIFIxMDog MDAwMDAwMDAwMDAwMDAwMCBSMTE6IDAwMDAwMDAwMDAwMTZjMTggUjEyOiBmZmZmODgwMWU1NDAy YzAwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjAzMV0gUjEz OiAwMDAwMDAwMTAwMDA1NDAxIFIxNDogMDAwMDAwMDAwMDAwMDJkMCBSMTU6IGZmZmZmZmZmODEx OTVlNjUKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MDQyXSBG UzogIDAwMDA3ZmEzYTk2NzU3MDAoMDAwMCkgR1M6ZmZmZjg4MDFmMWU4MDAwMCgwMDAwKSBrbmxH UzowMDAwMDAwMDAwMDAwMDAwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAg ODQ1LjgwNjA1Ml0gQ1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1 MDAzYgpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYwNTldIENS MjogMDAwMDAwMDEwMDAwNTQwMSBDUjM6IDAwMDAwMDAxOGYwMTEwMDAgQ1I0OiAwMDAwMDAwMDAw MDAwNjYwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjA2N10g RFIwOiAwMDAwMDAwMDAwMDAwMDAwIERSMTogMDAwMDAwMDAwMDAwMDAwMCBEUjI6IDAwMDAwMDAw MDAwMDAwMDAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MDc2 XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMGZmZmYwZmYwIERSNzogMDAwMDAw MDAwMDAwMDQwMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYw ODRdIFByb2Nlc3MgYmFzaCAocGlkOiAxNzk4LCB0aHJlYWRpbmZvIGZmZmY4ODAxOGY2NjYwMDAs IHRhc2sgZmZmZjg4MDFkZjBmODAwMCkKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA2MDkzXSBTdGFjazoKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA2MDk3XSAgZmZmZjg4MDE4ZjY2N2NmMCBmZmZmZmZmZjgxMDFiZTU5IDAwMDAw MDAwMDAwMDAyODIgMDAwMDAwMDAwMDAwMDgwMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBr ZXJuZWw6IFsgIDg0NS44MDYxMTFdICBmZmZmODgwMThmNjY3ZDYwIDAwMDAwMDAwMDAwMDA4MDAg ZmZmZjg4MDFkYWU4MTU0MCBmZmZmODgwMWRjNzA5MDkwCkZlYiAyMiAwMToxODoxMiBteWhvc3Ru YW1lIGtlcm5lbDogWyAgODQ1LjgwNjEyNF0gIGZmZmY4ODAxOGY2NjdlM2MgMDAwMDAwMDAwMDAw MDEwMCBmZmZmODgwMThmNjY3ZDUwIGZmZmZmZmZmODExOTVlNjUKRmViIDIyIDAxOjE4OjEyIG15 aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MTM4XSBDYWxsIFRyYWNlOgpGZWIgMjIgMDE6MTg6 MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYxNDZdICBbPGZmZmZmZmZmODEwMWJlNTk+ XSA/IHNjaGVkX2Nsb2NrKzB4OS8weDEwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5l bDogWyAgODQ1LjgwNjE1NV0gIFs8ZmZmZmZmZmY4MTE5NWU2NT5dIGFsbG9jX2ZkbWVtKzB4MjUv MHg1MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYxNjNdICBb PGZmZmZmZmZmODExOTVmMDA+XSBhbGxvY19mZHRhYmxlKzB4NzAvMHgxMDAKRmViIDIyIDAxOjE4 OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MTcxXSAgWzxmZmZmZmZmZjgxMTk2M2U0 Pl0gZHVwX2ZkKzB4MjQ0LzB4MmYwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDog WyAgODQ1LjgwNjE4MF0gIFs8ZmZmZmZmZmY4MTA2NjZlYj5dIGNvcHlfcHJvY2Vzcy5wYXJ0LjE4 KzB4NjRiLzB4ZTMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1Ljgw NjE5Ml0gIFs8ZmZmZmZmZmY4MTY2MGY1MD5dID8gZG9fcGFnZV9mYXVsdCsweDIxMC8weDUyMApG ZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYyMDBdICBbPGZmZmZm ZmZmODEwNjZmNDc+XSBjb3B5X3Byb2Nlc3MrMHg3Ny8weDgwCkZlYiAyMiAwMToxODoxMiBteWhv c3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjIwN10gIFs8ZmZmZmZmZmY4MTA2NzA5YT5dIGRvX2Zv cmsrMHhmYS8weDJmMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44 MDYyMTddICBbPGZmZmZmZmZmODEwN2IyMmI+XSA/IHJlY2FsY19zaWdwZW5kaW5nKzB4MWIvMHg1 MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYyMjVdICBbPGZm ZmZmZmZmODEwN2JhYjc+XSA/IF9fc2V0X3Rhc2tfYmxvY2tlZCsweDM3LzB4ODAKRmViIDIyIDAx OjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2MjM5XSAgWzxmZmZmZmZmZjgxMDdk ZWRiPl0gPyBzZXRfY3VycmVudF9ibG9ja2VkKzB4NWIvMHg3MApGZWIgMjIgMDE6MTg6MTIgbXlo b3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDYyNDhdICBbPGZmZmZmZmZmODEwMWQ2NTg+XSBzeXNf Y2xvbmUrMHgyOC8weDMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1 LjgwNjI1Nl0gIFs8ZmZmZmZmZmY4MTY2NWNhMz5dIHN0dWJfY2xvbmUrMHgxMy8weDIwCkZlYiAy MiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjI2NF0gIFs8ZmZmZmZmZmY4 MTY2NTk4Mj5dID8gc3lzdGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFiCkZlYiAyMiAwMToxODox MiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjI3MV0gQ29kZTogMDAgNGQgOGIgMDQgMjQg NjUgNGMgMDMgMDQgMjUgNTAgZGEgMDAgMDAgNDkgOGIgNTAgMDggNGQgOGIgMjggNGQgODUgZWQg MGYgODQgZDcgMDAgMDAgMDAgNDkgNjMgNDQgMjQgMjAgNDkgOGIgMzQgMjQgNDggOGQgNGEgMDEg PDQ5PiA4YiA1YyAwNSAwMCA0YyA4OSBlOCBlOCA3OCA0ZSAxYiAwMCA2NiA2NiA5MCA4NCBjMCA3 NCBjMiA0ZCAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2Mzc0 XSBSSVAgIFs8ZmZmZmZmZmY4MTE2NDNiYj5dIF9fa21hbGxvYysweDdiLzB4MTkwCkZlYiAyMiAw MToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwNjM4M10gIFJTUCA8ZmZmZjg4MDE4 ZjY2N2NlMD4KRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA2Mzg4 XSBDUjI6IDAwMDAwMDAxMDAwMDU0MDEKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA4MjEyXSBCVUc6IHVuYWJsZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1 ZXN0IGF0IDAwMDAwMDAxMDAwMDU0MDEKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA4MjEyXSBJUDogWzxmZmZmZmZmZjgxMTY0M2JiPl0gX19rbWFsbG9jKzB4N2Iv MHgxOTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSBQ R0QgMWRjYTYxMDY3IFBVRCAwIApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsg IDg0NS44MDgyMTJdIE9vcHM6IDAwMDAgWyMyXSBTTVAgCkZlYiAyMiAwMToxODoxMiBteWhvc3Ru YW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gQ1BVIDEgCkZlYiAyMiAwMToxODoxMiBteWhvc3Ru YW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gTW9kdWxlcyBsaW5rZWQgaW46IGlwNnRhYmxlX2Zp bHRlciBpcDZfdGFibGVzIGVidGFibGVfbmF0IGVidGFibGVzIGlwdF9NQVNRVUVSQURFIGlwdGFi bGVfbmF0IG5mX25hdCBuZl9jb25udHJhY2tfaXB2NCBuZl9kZWZyYWdfaXB2NCB4dF9zdGF0ZSBu Zl9jb25udHJhY2sgeGVuX2dudGRldiB4ZW5fbmV0YmFjayBpcHRfUkVKRUNUIHhlbl9ibGtiYWNr IHhlbl9ldnRjaG4geHRfQ0hFQ0tTVU0geGVuZnMgaXB0YWJsZV9tYW5nbGUgeHRfdGNwdWRwIGlw dGFibGVfZmlsdGVyIGlwX3RhYmxlcyB4X3RhYmxlcyBicmlkZ2Ugc3RwIG5vdXZlYXUgdHRtIGRy bV9rbXNfaGVscGVyIGRybSBhbWQ2NF9lZGFjX21vZCBlZGFjX2NvcmUgazh0ZW1wIGVkYWNfbWNl X2FtZCBpMmNfbmZvcmNlMiBpMmNfYWxnb19iaXQgc2hwY2hwIG14bV93bWkgd21pIG1hY19oaWQg dmlkZW8gcHNtb3VzZSBzZXJpb19yYXcgbHAgcGFycG9ydCB1c2JoaWQgaGlkIHNhdGFfbnYgdGcz IHBhdGFfYW1kCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIx Ml0gCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gUGlk OiAxNzk4LCBjb21tOiBiYXNoIE5vdCB0YWludGVkIDMuMi4wLTM4LWdlbmVyaWMgIzYxLVVidW50 dSBIUCBQcm9MaWFudCBETDE0NSBHMi9LODVOTApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBr ZXJuZWw6IFsgIDg0NS44MDgyMTJdIFJJUDogZTAzMDpbPGZmZmZmZmZmODExNjQzYmI+XSAgWzxm ZmZmZmZmZjgxMTY0M2JiPl0gX19rbWFsbG9jKzB4N2IvMHgxOTAKRmViIDIyIDAxOjE4OjEyIG15 aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSBSU1A6IGUwMmI6ZmZmZjg4MDE4ZjY2NzVj OCAgRUZMQUdTOiAwMDAxMDAwMgpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsg IDg0NS44MDgyMTJdIFJBWDogMDAwMDAwMDAwMDAwMDAwMCBSQlg6IGZmZmY4ODAxZGU0ODM2Mzgg UkNYOiAwMDAwMDAwMDAwNWExN2ViCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDog WyAgODQ1LjgwODIxMl0gUkRYOiAwMDAwMDAwMDAwNWExN2VhIFJTSTogMDAwMDAwMDAwMDAxNjcw MCBSREk6IDAwMDAwMDAwMDAwMDA0NWYKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA4MjEyXSBSQlA6IGZmZmY4ODAxOGY2Njc2MTggUjA4OiBmZmZmODgwMWYxZTk2 NzAwIFIwOTogMDAwMDAwMDAwMDAwMDAxZgpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJu ZWw6IFsgIDg0NS44MDgyMTJdIFIxMDogMDAwMDAwMDAwMDAwMDAwMCBSMTE6IDAwMDAwMDAwMDAw MDAwMDAgUjEyOiBmZmZmODgwMWU1NDAyYzAwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtl cm5lbDogWyAgODQ1LjgwODIxMl0gUjEzOiAwMDAwMDAwMTAwMDA1NDAxIFIxNDogMDAwMDAwMDAw MDAwODBkMCBSMTU6IGZmZmZmZmZmYTAwZjQ5M2MKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUg a2VybmVsOiBbICA4NDUuODA4MjEyXSBbZHJtXSBub3V2ZWF1IDAwMDA6MDE6MDUuMDogR1BVIGxv Y2t1cCAtIHN3aXRjaGluZyB0byBzb2Z0d2FyZSBmYmNvbgpGZWIgMjIgMDE6MTg6MTIgbXlob3N0 bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdIEZTOiAgMDAwMDdmYTNhOTY3NTcwMCgwMDAwKSBH UzpmZmZmODgwMWYxZTgwMDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDAKRmViIDIyIDAx OjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSBDUzogIGUwMzMgRFM6IDAw MDAgRVM6IDAwMDAgQ1IwOiAwMDAwMDAwMDgwMDUwMDNiCkZlYiAyMiAwMToxODoxMiBteWhvc3Ru YW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gQ1IyOiAwMDAwMDAwMTAwMDA1NDAxIENSMzogMDAw MDAwMDE4ZjAxMTAwMCBDUjQ6IDAwMDAwMDAwMDAwMDA2NjAKRmViIDIyIDAxOjE4OjEyIG15aG9z dG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSBEUjA6IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAw MDAwMDAwMDAwMDAwMDAwIERSMjogMDAwMDAwMDAwMDAwMDAwMApGZWIgMjIgMDE6MTg6MTIgbXlo b3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdIERSMzogMDAwMDAwMDAwMDAwMDAwMCBEUjY6 IDAwMDAwMDAwZmZmZjBmZjAgRFI3OiAwMDAwMDAwMDAwMDAwNDAwCkZlYiAyMiAwMToxODoxMiBt eWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gUHJvY2VzcyBiYXNoIChwaWQ6IDE3OTgs IHRocmVhZGluZm8gZmZmZjg4MDE4ZjY2NjAwMCwgdGFzayBmZmZmODgwMWRmMGY4MDAwKQpGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdIFN0YWNrOgpGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBmZmZmODgwMWRj YjgxMDAwIDAwMDAwMDAwMDAwMDAwMTAgZmZmZjg4MDE4ZjY2NzYyOCAwMDAwMDAwMDAwMDAwNDYw CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIGZmZmY4 ODAxMDAwMDAxMjAgZmZmZjg4MDFkZTQ4MzYzOCBmZmZmODgwMWRjMTk1YzA4IGZmZmY4ODAxZGU0 ODM4MDAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAg ZmZmZjg4MDFkY2I4MjgwMCBmZmZmODgwMWRjYjg2YmEwIGZmZmY4ODAxOGY2Njc2ZTggZmZmZmZm ZmZhMDBmNDkzYwpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgy MTJdIENhbGwgVHJhY2U6CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1 LjgwODIxMl0gIFs8ZmZmZmZmZmZhMDBmNDkzYz5dIGRybV9jcnRjX2hlbHBlcl9zZXRfY29uZmln KzB4ZWMvMHhhZjAgW2RybV9rbXNfaGVscGVyXQpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBr ZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEzNTc0MzE+XSA/IGZiX3NldF92YXIr MHgxYTEvMHgzMTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4 MjEyXSAgWzxmZmZmZmZmZmEwMThlMGIyPl0gPyBub3V2ZWF1X2ZiY29uX2ltYWdlYmxpdCsweGMy LzB4MTEwIFtub3V2ZWF1XQpGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0 NS44MDgyMTJdICBbPGZmZmZmZmZmYTAwZjE3ODY+XSBkcm1fZmJfaGVscGVyX3Bhbl9kaXNwbGF5 KzB4ODYvMHhkMCBbZHJtX2ttc19oZWxwZXJdCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtl cm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTM1NmFmZD5dIGZiX3Bhbl9kaXNwbGF5 KzB4YmQvMHgxNzAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4 MjEyXSAgWzxmZmZmZmZmZjgxMzY3OTY5Pl0gYml0X3VwZGF0ZV9zdGFydCsweDI5LzB4NjAKRmVi IDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZm ZjgxMzY2MjYyPl0gZmJjb25fc3dpdGNoKzB4M2IyLzB4NTYwCkZlYiAyMiAwMToxODoxMiBteWhv c3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTNkMWZlOT5dIHJlZHJh d19zY3JlZW4rMHgxODkvMHgyYTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBb ICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxMzY0OTRhPl0gZmJjb25fYmxhbmsrMHgyMWEvMHgy ZDAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxm ZmZmZmZmZjgxNjVkNWFlPl0gPyBfcmF3X3NwaW5fdW5sb2NrX2lycXJlc3RvcmUrMHgxZS8weDMw CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZm ZmZmZmY4MTA5MTNjMj5dID8gdXArMHgzMi8weDUwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1l IGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTY1ZDYyZT5dID8gX3Jhd19zcGlu X2xvY2tfaXJxc2F2ZSsweDJlLzB4NDAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVs OiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxMDc3Zjg4Pl0gPyBsb2NrX3RpbWVyX2Jhc2Uu aXNyYS4yOSsweDM4LzB4NzAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4 NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxNjVkNWFlPl0gPyBfcmF3X3NwaW5fdW5sb2NrX2lycXJl c3RvcmUrMHgxZS8weDMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1 LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTA3OTM0Mz5dID8gbW9kX3RpbWVyKzB4MTQzLzB4MmYwCkZl YiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZm ZmY4MTNkMmNlYz5dIGRvX3VuYmxhbmtfc2NyZWVuLnBhcnQuMTkrMHg5Yy8weDE3MApGZWIgMjIg MDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEz ZDJlMDg+XSBkb191bmJsYW5rX3NjcmVlbisweDQ4LzB4ODAKRmViIDIyIDAxOjE4OjEyIG15aG9z dG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxM2QyZTUwPl0gdW5ibGFu a19zY3JlZW4rMHgxMC8weDIwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAg ODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTMxYmI0ZD5dIGJ1c3Rfc3BpbmxvY2tzKzB4MWQvMHg0 MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZm ZmZmZmZmODE2NWU0YWY+XSBvb3BzX2VuZCsweDNmLzB4ZjAKRmViIDIyIDAxOjE4OjEyIG15aG9z dG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxNjQzN2ZlPl0gbm9fY29u dGV4dCsweDE1MC8weDE1ZApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0 NS44MDgyMTJdICBbPGZmZmZmZmZmODE2NDM5ZDQ+XSBfX2JhZF9hcmVhX25vc2VtYXBob3JlKzB4 MWM5LzB4MWU4CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIx Ml0gIFs8ZmZmZmZmZmY4MTY0M2E0ZD5dIGJhZF9hcmVhKzB4NDUvMHg0ZQpGZWIgMjIgMDE6MTg6 MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODE2NjEyNTU+ XSBkb19wYWdlX2ZhdWx0KzB4NTE1LzB4NTIwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtl cm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTEyMTQzZj5dID8gZ2V0X3BhZ2VfZnJv bV9mcmVlbGlzdCsweDFjZi8weDU0MApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6 IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEwMDRkNjI+XSA/IHhlbl9tY19mbHVzaCsweGIy LzB4MWMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0g IFs8ZmZmZmZmZmY4MTE5NWU2NT5dID8gYWxsb2NfZmRtZW0rMHgyNS8weDUwCkZlYiAyMiAwMTox ODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTY1ZGFm NT5dIHBhZ2VfZmF1bHQrMHgyNS8weDMwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5l bDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTE5NWU2NT5dID8gYWxsb2NfZmRtZW0rMHgy NS8weDUwCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0g IFs8ZmZmZmZmZmY4MTE2NDNiYj5dID8gX19rbWFsbG9jKzB4N2IvMHgxOTAKRmViIDIyIDAxOjE4 OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxMDFiZTU5 Pl0gPyBzY2hlZF9jbG9jaysweDkvMHgxMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJu ZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODExOTVlNjU+XSBhbGxvY19mZG1lbSsweDI1 LzB4NTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAg WzxmZmZmZmZmZjgxMTk1ZjAwPl0gYWxsb2NfZmR0YWJsZSsweDcwLzB4MTAwCkZlYiAyMiAwMTox ODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTE5NjNl ND5dIGR1cF9mZCsweDI0NC8weDJmMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6 IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEwNjY2ZWI+XSBjb3B5X3Byb2Nlc3MucGFydC4x OCsweDY0Yi8weGUzMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44 MDgyMTJdICBbPGZmZmZmZmZmODE2NjBmNTA+XSA/IGRvX3BhZ2VfZmF1bHQrMHgyMTAvMHg1MjAK RmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZm ZmZmZjgxMDY2ZjQ3Pl0gY29weV9wcm9jZXNzKzB4NzcvMHg4MApGZWIgMjIgMDE6MTg6MTIgbXlo b3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZmODEwNjcwOWE+XSBkb19m b3JrKzB4ZmEvMHgyZjAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUu ODA4MjEyXSAgWzxmZmZmZmZmZjgxMDdiMjJiPl0gPyByZWNhbGNfc2lncGVuZGluZysweDFiLzB4 NTAKRmViIDIyIDAxOjE4OjEyIG15aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxm ZmZmZmZmZjgxMDdiYWI3Pl0gPyBfX3NldF90YXNrX2Jsb2NrZWQrMHgzNy8weDgwCkZlYiAyMiAw MToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gIFs8ZmZmZmZmZmY4MTA3 ZGVkYj5dID8gc2V0X2N1cnJlbnRfYmxvY2tlZCsweDViLzB4NzAKRmViIDIyIDAxOjE4OjEyIG15 aG9zdG5hbWUga2VybmVsOiBbICA4NDUuODA4MjEyXSAgWzxmZmZmZmZmZjgxMDFkNjU4Pl0gc3lz X2Nsb25lKzB4MjgvMHgzMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0 NS44MDgyMTJdICBbPGZmZmZmZmZmODE2NjVjYTM+XSBzdHViX2Nsb25lKzB4MTMvMHgyMApGZWIg MjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBbPGZmZmZmZmZm ODE2NjU5ODI+XSA/IHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYgpGZWIgMjIgMDE6MTg6 MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdIENvZGU6IDAwIDRkIDhiIDA0IDI0 IDY1IDRjIDAzIDA0IDI1IDUwIGRhIDAwIDAwIDQ5IDhiIDUwIDA4IDRkIDhiIDI4IDRkIDg1IGVk IDBmIDg0IGQ3IDAwIDAwIDAwIDQ5IDYzIDQ0IDI0IDIwIDQ5IDhiIDM0IDI0IDQ4IDhkIDRhIDAx IDw0OT4gOGIgNWMgMDUgMDAgNGMgODkgZTggZTggNzggNGUgMWIgMDAgNjYgNjYgOTAgODQgYzAg NzQgYzIgNGQgCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIx Ml0gUklQICBbPGZmZmZmZmZmODExNjQzYmI+XSBfX2ttYWxsb2MrMHg3Yi8weDE5MApGZWIgMjIg MDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0NS44MDgyMTJdICBSU1AgPGZmZmY4ODAx OGY2Njc1Yzg+CkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIx Ml0gQ1IyOiAwMDAwMDAwMTAwMDA1NDAxCkZlYiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5l bDogWyAgODQ1LjgwODIxMl0gLS0tWyBlbmQgdHJhY2UgYmZhMzIxYTNmNmRjNjk5NyBdLS0tCkZl YiAyMiAwMToxODoxMiBteWhvc3RuYW1lIGtlcm5lbDogWyAgODQ1LjgwODIxMl0gW2RybV0gbm91 dmVhdSAwMDAwOjAxOjA1LjA6IFBGSUZPX0RNQV9QVVNIRVIgLSBDaCAwIEdldCAweDAwMDExMDA0 IFB1dCAweDAwMDBjZTY4IFN0YXRlIDB4ODAwMDAwMDAgKGVycjogSU5WQUxJRF9DTUQpIFB1c2gg MHgwMDAwMDAwMApGZWIgMjIgMDE6MTg6MTIgbXlob3N0bmFtZSBrZXJuZWw6IFsgIDg0Ni4xNzMx MzRdIFdhcm5pbmc6IGRldiAocHRzMSkgdHR5LT5jb3VudCgyKSAhPSAjZmQncygxKSBpbiB0dHlf cmVsZWFzZV9kZXYKRmViIDIyIDAxOjE5OjIyIG15aG9zdG5hbWUga2VybmVsOiBbICA5MDYuMTg0 MDU5XSBJTkZPOiByY3Vfc2NoZWQgZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHsgMH0g KGRldGVjdGVkIGJ5IDIsIHQ9MTUwMDIgamlmZmllcykKRmViIDIyIDAxOjE5OjIyIG15aG9zdG5h bWUga2VybmVsOiBbICA5MDYuMTg4MDUyXSBzZW5kaW5nIE5NSSB0byBhbGwgQ1BVczoKRmViIDIy IDAxOjE5OjMyIG15aG9zdG5hbWUga2VybmVsOiBbICA5MTYuMTE2MDU3XSBJTkZPOiByY3VfYmgg ZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHsgMH0gKGRldGVjdGVkIGJ5IDEsIHQ9MTc0 ODQgamlmZmllcykKRmViIDIyIDAxOjE5OjMyIG15aG9zdG5hbWUga2VybmVsOiBbICA5MTYuMTIw MDUyXSBzZW5kaW5nIE5NSSB0byBhbGwgQ1BVczoKRmViIDIyIDAxOjIyOjIyIG15aG9zdG5hbWUg a2VybmVsOiBbIDEwODYuMzEyMDU4XSBJTkZPOiByY3Vfc2NoZWQgZGV0ZWN0ZWQgc3RhbGxzIG9u IENQVXMvdGFza3M6IHsgMH0gKGRldGVjdGVkIGJ5IDIsIHQ9NjAwMzQgamlmZmllcykKRmViIDIy IDAxOjIyOjIyIG15aG9zdG5hbWUga2VybmVsOiBbIDEwODYuMzE2MDUyXSBzZW5kaW5nIE5NSSB0 byBhbGwgQ1BVczoKRmViIDIyIDAxOjIyOjMyIG15aG9zdG5hbWUga2VybmVsOiBbIDEwOTYuMjQ0 MDU4XSBJTkZPOiByY3VfYmggZGV0ZWN0ZWQgc3RhbGxzIG9uIENQVXMvdGFza3M6IHsgMH0gKGRl dGVjdGVkIGJ5IDEsIHQ9NjI1MTYgamlmZmllcykKRmViIDIyIDAxOjIyOjMyIG15aG9zdG5hbWUg a2VybmVsOiBbIDEwOTYuMjQ4MDUyXSBzZW5kaW5nIE5NSSB0byBhbGwgQ1BVczoK --=_e662c4489f1b20e46011ef7551c3c240 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 --=_e662c4489f1b20e46011ef7551c3c240-- From xen-users-bounces@lists.xen.org Fri Mar 22 08:16:10 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 08:16: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 1UIx7Y-0006xd-KZ; Fri, 22 Mar 2013 08:14:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIx7X-0006xY-0r for xen-users@lists.xen.org; Fri, 22 Mar 2013 08:14:39 +0000 Received: from [85.158.139.83:9987] by server-1.bemta-5.messagelabs.com id 51/D3-14063-EE21C415; Fri, 22 Mar 2013 08:14:38 +0000 X-Env-Sender: aaron.cossey@gmail.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1363940072!27522517!1 X-Originating-IP: [74.125.82.46] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1210 invoked from network); 22 Mar 2013 08:14:32 -0000 Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com) (74.125.82.46) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Mar 2013 08:14:32 -0000 Received: by mail-wg0-f46.google.com with SMTP id fg15so2858716wgb.25 for ; Fri, 22 Mar 2013 01:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bwMKL0VONXK1CxboJuMLpqqkDdjT0RZnYsdeK0yhsJI=; b=qWWaDGzV57KYS9c4a7zykH/5on6zVO5bHfzbp5nno4jKWYNt5Csw2Pb0R7IoVxq1Hv xO71boiK5EMpva7Ld1Q7Jba8dqIEBdmnLyyhn9eJCqM4Ctth1H7+ZCtwX9IwYSmBz4oM Yu3968Fgrm8NzKLRKVFXkvPk4aqPKfeCzbpgMytyY2qAeYtmMTbGlxRQOpnFgNfx8nPX TQ+ZDdG30FFt2TCP2k6ewupvmSwCz3P3+Z5IXwHNiUbbPXmqBFLPtaYschyUvydFTUAV 4NuTq3frmhzseu7+chDzZowIi0DaEZnI/9xAHdQZXcq2jvki5ESkpHhmAg1cUvkuhz61 Vg2A== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr9595469wic.29.1363940072106; Fri, 22 Mar 2013 01:14:32 -0700 (PDT) Received: by 10.194.138.40 with HTTP; Fri, 22 Mar 2013 01:14:32 -0700 (PDT) In-Reply-To: <50fa9f80810dccb5d751504117688c15@selby.ca> References: <50fa9f80810dccb5d751504117688c15@selby.ca> Date: Fri, 22 Mar 2013 09:14:32 +0100 Message-ID: From: Aaron Cossey To: Peter Selby Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Experiencing kernel panic with SSH + LVM + Xen + significant amounts of data X-BeenThere: xen-users@lists.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="===============2562068599568155037==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2562068599568155037== Content-Type: multipart/alternative; boundary=001a11c2a85a7e306f04d87f0b5d --001a11c2a85a7e306f04d87f0b5d Content-Type: text/plain; charset=ISO-8859-1 I can't help with the Kernel Panic but I can say that I too used to copy LV's around with "dd if=... | ssh dd of=...", a much more elegeant and fault tolerant way to do these copies is to export an LV as an iSCSI Target, attach the Target on the remote machine and then dd locally. Aaron Cossey aaron.cossey@gmail.com On Fri, Mar 22, 2013 at 1:24 AM, Peter Selby wrote: > Hi all, > > I'm running into a kernel panic with Xen, under fairly specific > circumstances. I'll post it here first, and follow up on xen-devel if > it looks like it's a Xen bug. > > After some experimentation, it seems like the panic occurs under the > following circumstances: > > 1) A significant amount of data is being moved > > 2) ...Onto (or off of?) an LVM partition > > 3) ...With SSH being involved somehow? > > 4) ...On Xen. > > Originally, I was trying to move a filesystem over the network via "dd > if=... | ssh dd of=...", onto an LVM partition. The filesystem was > 20G, and it repeatably crashed, usually after >25% transferred. > > I've also tried scp'ing files, using dd to transfer files, > transferring the 20G FS to /dev/null, moving data OFF the host in > question, etc. None of these triggered a panic. > > Moving large files on the host itself doesn't trigger a > crash. However, piping data to an LVM partition (and in one case, > piping from LVM to /dev/null) has triggered a crash, though the panic > seems to occur simultaneously with an SSH login when it's > happened. Minus an SSH login, I've successfully and repeatably moved > data from LVM => LVM, LVM => null, yes => LVM, without a crash (logged > in via SSH the whole time, I should add...there seems to be something > about logins specifically) > > The system has ended up in a bad state more than once, too, which > complicates things. It's possible that the crash triggered by moving > OFF of LVM to /dev/null was the result of a bad state triggered > earlier, because I wasn't able to reproduce it. > > No such issues occur if I'm not running Xen, which seems to rule out > HW failure. To be clear, the host in question is the hypervisor, and > the panics occur regardless of whether VMs are running. > > Version info: > > Essentially, it's a fully up-to-date Ubuntu 12.04 system. > > HW - HP ProLiant DL145 G2/K85NL (rackmount) > > Xen - 4.1.2-2ubuntu2.6 > > LVM: > LVM version: 2.02.66(2) (2010-05-20) > Library version: 1.02.48 (2010-05-20) > Driver version: 4.22.0 > > SSH: > OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012 > > Kernel - 3.2.0-39-generic > > I can provide more info on request. > > I've also attached a sample kernel panic. This one's a little old, but > the crashes don't always dump to syslog, and the symptoms haven't > changed. > > Thanks! > > Peter > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --001a11c2a85a7e306f04d87f0b5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I can't help with the Kernel Panic but I can say that = I too used to copy LV's around with =A0"dd=A0if=3D... |= ssh dd of=3D...", a much more elegeant and fault tolerant way to do t= hese copies is to export an LV as an iSCSI Target, attach the Target on the= remote machine and then dd locally.



On Fri, Mar 22, 2013 at 1:24 AM, Peter S= elby <peter@selby.ca> wrote:
Hi all,

I'm running into a kernel panic with Xen, under fairly specific
circumstances. I'll post it here first, and follow up on xen-devel if it looks like it's a Xen bug.

After some experimentation, it seems like the panic occurs under the
following circumstances:

1) A significant amount of data is being moved

2) ...Onto (or off of?) an LVM partition

3) ...With SSH being involved somehow?

4) ...On Xen.

Originally, I was trying to move a filesystem over the network via "dd=
if=3D... | ssh dd of=3D...", onto an LVM partition. The filesystem was=
20G, and it repeatably crashed, usually after >25% transferred.

I've also tried scp'ing files, using dd to transfer files,
transferring the 20G FS to /dev/null, moving data OFF the host in
question, etc. None of these triggered a panic.

Moving large files on the host itself doesn't trigger a
crash. However, piping data to an LVM partition (and in one case,
piping from LVM to /dev/null) has triggered a crash, though the panic
seems to occur simultaneously with an SSH login when it's
happened. Minus an SSH login, I've successfully and repeatably moved data from LVM =3D> LVM, LVM =3D> null, yes =3D> LVM, without a cra= sh (logged
in via SSH the whole time, I should add...there seems to be something
about logins specifically)

The system has ended up in a bad state more than once, too, which
complicates things. It's possible that the crash triggered by moving OFF of LVM to /dev/null was the result of a bad state triggered
earlier, because I wasn't able to reproduce it.

No such issues occur if I'm not running Xen, which seems to rule out HW failure. To be clear, the host in question is the hypervisor, and
the panics occur regardless of whether VMs are running.

Version info:

Essentially, it's a fully up-to-date Ubuntu 12.04 system.

HW - HP ProLiant DL145 G2/K85NL (rackmount)

Xen - 4.1.2-2ubuntu2.6

LVM:
=A0 LVM version: =A0 =A0 2.02.66(2) (2010-05-20)
=A0 Library version: 1.02.48 (2010-05-20)
=A0 Driver version: =A04.22.0

SSH:
=A0 OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012

Kernel - 3.2.0-39-generic

I can provide more info on request.

I've also attached a sample kernel panic. This one's a little old, = but
the crashes don't always dump to syslog, and the symptoms haven't changed.

Thanks!

Peter
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--001a11c2a85a7e306f04d87f0b5d-- --===============2562068599568155037== 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 --===============2562068599568155037==-- From xen-users-bounces@lists.xen.org Fri Mar 22 08:16:10 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 08:16: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 1UIx7Y-0006xd-KZ; Fri, 22 Mar 2013 08:14:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIx7X-0006xY-0r for xen-users@lists.xen.org; Fri, 22 Mar 2013 08:14:39 +0000 Received: from [85.158.139.83:9987] by server-1.bemta-5.messagelabs.com id 51/D3-14063-EE21C415; Fri, 22 Mar 2013 08:14:38 +0000 X-Env-Sender: aaron.cossey@gmail.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1363940072!27522517!1 X-Originating-IP: [74.125.82.46] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1210 invoked from network); 22 Mar 2013 08:14:32 -0000 Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com) (74.125.82.46) by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Mar 2013 08:14:32 -0000 Received: by mail-wg0-f46.google.com with SMTP id fg15so2858716wgb.25 for ; Fri, 22 Mar 2013 01:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bwMKL0VONXK1CxboJuMLpqqkDdjT0RZnYsdeK0yhsJI=; b=qWWaDGzV57KYS9c4a7zykH/5on6zVO5bHfzbp5nno4jKWYNt5Csw2Pb0R7IoVxq1Hv xO71boiK5EMpva7Ld1Q7Jba8dqIEBdmnLyyhn9eJCqM4Ctth1H7+ZCtwX9IwYSmBz4oM Yu3968Fgrm8NzKLRKVFXkvPk4aqPKfeCzbpgMytyY2qAeYtmMTbGlxRQOpnFgNfx8nPX TQ+ZDdG30FFt2TCP2k6ewupvmSwCz3P3+Z5IXwHNiUbbPXmqBFLPtaYschyUvydFTUAV 4NuTq3frmhzseu7+chDzZowIi0DaEZnI/9xAHdQZXcq2jvki5ESkpHhmAg1cUvkuhz61 Vg2A== MIME-Version: 1.0 X-Received: by 10.180.13.34 with SMTP id e2mr9595469wic.29.1363940072106; Fri, 22 Mar 2013 01:14:32 -0700 (PDT) Received: by 10.194.138.40 with HTTP; Fri, 22 Mar 2013 01:14:32 -0700 (PDT) In-Reply-To: <50fa9f80810dccb5d751504117688c15@selby.ca> References: <50fa9f80810dccb5d751504117688c15@selby.ca> Date: Fri, 22 Mar 2013 09:14:32 +0100 Message-ID: From: Aaron Cossey To: Peter Selby Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Experiencing kernel panic with SSH + LVM + Xen + significant amounts of data X-BeenThere: xen-users@lists.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="===============2562068599568155037==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2562068599568155037== Content-Type: multipart/alternative; boundary=001a11c2a85a7e306f04d87f0b5d --001a11c2a85a7e306f04d87f0b5d Content-Type: text/plain; charset=ISO-8859-1 I can't help with the Kernel Panic but I can say that I too used to copy LV's around with "dd if=... | ssh dd of=...", a much more elegeant and fault tolerant way to do these copies is to export an LV as an iSCSI Target, attach the Target on the remote machine and then dd locally. Aaron Cossey aaron.cossey@gmail.com On Fri, Mar 22, 2013 at 1:24 AM, Peter Selby wrote: > Hi all, > > I'm running into a kernel panic with Xen, under fairly specific > circumstances. I'll post it here first, and follow up on xen-devel if > it looks like it's a Xen bug. > > After some experimentation, it seems like the panic occurs under the > following circumstances: > > 1) A significant amount of data is being moved > > 2) ...Onto (or off of?) an LVM partition > > 3) ...With SSH being involved somehow? > > 4) ...On Xen. > > Originally, I was trying to move a filesystem over the network via "dd > if=... | ssh dd of=...", onto an LVM partition. The filesystem was > 20G, and it repeatably crashed, usually after >25% transferred. > > I've also tried scp'ing files, using dd to transfer files, > transferring the 20G FS to /dev/null, moving data OFF the host in > question, etc. None of these triggered a panic. > > Moving large files on the host itself doesn't trigger a > crash. However, piping data to an LVM partition (and in one case, > piping from LVM to /dev/null) has triggered a crash, though the panic > seems to occur simultaneously with an SSH login when it's > happened. Minus an SSH login, I've successfully and repeatably moved > data from LVM => LVM, LVM => null, yes => LVM, without a crash (logged > in via SSH the whole time, I should add...there seems to be something > about logins specifically) > > The system has ended up in a bad state more than once, too, which > complicates things. It's possible that the crash triggered by moving > OFF of LVM to /dev/null was the result of a bad state triggered > earlier, because I wasn't able to reproduce it. > > No such issues occur if I'm not running Xen, which seems to rule out > HW failure. To be clear, the host in question is the hypervisor, and > the panics occur regardless of whether VMs are running. > > Version info: > > Essentially, it's a fully up-to-date Ubuntu 12.04 system. > > HW - HP ProLiant DL145 G2/K85NL (rackmount) > > Xen - 4.1.2-2ubuntu2.6 > > LVM: > LVM version: 2.02.66(2) (2010-05-20) > Library version: 1.02.48 (2010-05-20) > Driver version: 4.22.0 > > SSH: > OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012 > > Kernel - 3.2.0-39-generic > > I can provide more info on request. > > I've also attached a sample kernel panic. This one's a little old, but > the crashes don't always dump to syslog, and the symptoms haven't > changed. > > Thanks! > > Peter > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --001a11c2a85a7e306f04d87f0b5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I can't help with the Kernel Panic but I can say that = I too used to copy LV's around with =A0"dd=A0if=3D... |= ssh dd of=3D...", a much more elegeant and fault tolerant way to do t= hese copies is to export an LV as an iSCSI Target, attach the Target on the= remote machine and then dd locally.



On Fri, Mar 22, 2013 at 1:24 AM, Peter S= elby <peter@selby.ca> wrote:
Hi all,

I'm running into a kernel panic with Xen, under fairly specific
circumstances. I'll post it here first, and follow up on xen-devel if it looks like it's a Xen bug.

After some experimentation, it seems like the panic occurs under the
following circumstances:

1) A significant amount of data is being moved

2) ...Onto (or off of?) an LVM partition

3) ...With SSH being involved somehow?

4) ...On Xen.

Originally, I was trying to move a filesystem over the network via "dd=
if=3D... | ssh dd of=3D...", onto an LVM partition. The filesystem was=
20G, and it repeatably crashed, usually after >25% transferred.

I've also tried scp'ing files, using dd to transfer files,
transferring the 20G FS to /dev/null, moving data OFF the host in
question, etc. None of these triggered a panic.

Moving large files on the host itself doesn't trigger a
crash. However, piping data to an LVM partition (and in one case,
piping from LVM to /dev/null) has triggered a crash, though the panic
seems to occur simultaneously with an SSH login when it's
happened. Minus an SSH login, I've successfully and repeatably moved data from LVM =3D> LVM, LVM =3D> null, yes =3D> LVM, without a cra= sh (logged
in via SSH the whole time, I should add...there seems to be something
about logins specifically)

The system has ended up in a bad state more than once, too, which
complicates things. It's possible that the crash triggered by moving OFF of LVM to /dev/null was the result of a bad state triggered
earlier, because I wasn't able to reproduce it.

No such issues occur if I'm not running Xen, which seems to rule out HW failure. To be clear, the host in question is the hypervisor, and
the panics occur regardless of whether VMs are running.

Version info:

Essentially, it's a fully up-to-date Ubuntu 12.04 system.

HW - HP ProLiant DL145 G2/K85NL (rackmount)

Xen - 4.1.2-2ubuntu2.6

LVM:
=A0 LVM version: =A0 =A0 2.02.66(2) (2010-05-20)
=A0 Library version: 1.02.48 (2010-05-20)
=A0 Driver version: =A04.22.0

SSH:
=A0 OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012

Kernel - 3.2.0-39-generic

I can provide more info on request.

I've also attached a sample kernel panic. This one's a little old, = but
the crashes don't always dump to syslog, and the symptoms haven't changed.

Thanks!

Peter
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--001a11c2a85a7e306f04d87f0b5d-- --===============2562068599568155037== 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 --===============2562068599568155037==-- From xen-users-bounces@lists.xen.org Fri Mar 22 09:46:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 09:46: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 1UIyWh-000055-SK; Fri, 22 Mar 2013 09:44:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIyWf-000050-Jk for xen-users@lists.xen.org; Fri, 22 Mar 2013 09:44:41 +0000 Received: from [85.158.139.211:3125] by server-3.bemta-5.messagelabs.com id EC/7B-17256-8082C415; Fri, 22 Mar 2013 09:44:40 +0000 X-Env-Sender: matthew.pideil@teledetection.fr X-Msg-Ref: server-4.tower-206.messagelabs.com!1363945471!18062053!1 X-Originating-IP: [193.48.189.9] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9386 invoked from network); 22 Mar 2013 09:44:31 -0000 Received: from komper2.teledetection.fr (HELO komper.teledetection.fr) (193.48.189.9) by server-4.tower-206.messagelabs.com with SMTP; 22 Mar 2013 09:44:31 -0000 Received: from [193.48.189.109] (unknown [193.48.189.109]) by komper.teledetection.fr (Serveur mel de la MTD) with ESMTPSA id 0225C264AD76 for ; Fri, 22 Mar 2013 10:44:30 +0100 (CET) Message-ID: <514C27FE.1060600@teledetection.fr> Date: Fri, 22 Mar 2013 10:44:30 +0100 From: matthew pideil User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] 3D Accell issue with Wheezy PVHVM DomU (VGA Passthrough) on Xen 4.1 X-BeenThere: xen-users@lists.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="===============1356092479356470483==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============1356092479356470483== Content-Type: multipart/alternative; boundary="------------010406070105050704020008" This is a multi-part message in MIME format. --------------010406070105050704020008 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, I run wheezy dom0 on "xen-hypervisor-4.1-amd64". I have successfully set up a pvhvm wheezy domu (vga passthrough) on wheezy hypervisor with hd4000 igd. All seems working perfect since gnome-session starts (gdm3) after logging in, gnome-shell no render anything (only cursor and background). In 'GNOME Classic' mode, which works like a charm, i run "glxinfo" without any problems and "glxgears" which show a dark window (no gears) whithout any errors. Do you also have this issue ? Sincerely, --- Matt --------------010406070105050704020008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello,

I run wheezy dom0 on "xen-hypervisor-4.1-amd64".
I have successfully set up a pvhvm wheezy domu (vga passthrough) on wheezy hypervisor with hd4000 igd.
All seems working perfect since gnome-session starts (gdm3) after logging in, gnome-shell no render anything (only cursor and background).
In 'GNOME Classic' mode, which works like a charm, i run "glxinfo" without any problems and "glxgears" which show a dark window (no gears) whithout any errors.

Do you also have this issue ?

Sincerely,
---
Matt
--------------010406070105050704020008-- --===============1356092479356470483== 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 --===============1356092479356470483==-- From xen-users-bounces@lists.xen.org Fri Mar 22 09:46:04 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 09:46: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 1UIyWh-000055-SK; Fri, 22 Mar 2013 09:44:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIyWf-000050-Jk for xen-users@lists.xen.org; Fri, 22 Mar 2013 09:44:41 +0000 Received: from [85.158.139.211:3125] by server-3.bemta-5.messagelabs.com id EC/7B-17256-8082C415; Fri, 22 Mar 2013 09:44:40 +0000 X-Env-Sender: matthew.pideil@teledetection.fr X-Msg-Ref: server-4.tower-206.messagelabs.com!1363945471!18062053!1 X-Originating-IP: [193.48.189.9] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9386 invoked from network); 22 Mar 2013 09:44:31 -0000 Received: from komper2.teledetection.fr (HELO komper.teledetection.fr) (193.48.189.9) by server-4.tower-206.messagelabs.com with SMTP; 22 Mar 2013 09:44:31 -0000 Received: from [193.48.189.109] (unknown [193.48.189.109]) by komper.teledetection.fr (Serveur mel de la MTD) with ESMTPSA id 0225C264AD76 for ; Fri, 22 Mar 2013 10:44:30 +0100 (CET) Message-ID: <514C27FE.1060600@teledetection.fr> Date: Fri, 22 Mar 2013 10:44:30 +0100 From: matthew pideil User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] 3D Accell issue with Wheezy PVHVM DomU (VGA Passthrough) on Xen 4.1 X-BeenThere: xen-users@lists.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="===============1356092479356470483==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============1356092479356470483== Content-Type: multipart/alternative; boundary="------------010406070105050704020008" This is a multi-part message in MIME format. --------------010406070105050704020008 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, I run wheezy dom0 on "xen-hypervisor-4.1-amd64". I have successfully set up a pvhvm wheezy domu (vga passthrough) on wheezy hypervisor with hd4000 igd. All seems working perfect since gnome-session starts (gdm3) after logging in, gnome-shell no render anything (only cursor and background). In 'GNOME Classic' mode, which works like a charm, i run "glxinfo" without any problems and "glxgears" which show a dark window (no gears) whithout any errors. Do you also have this issue ? Sincerely, --- Matt --------------010406070105050704020008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello,

I run wheezy dom0 on "xen-hypervisor-4.1-amd64".
I have successfully set up a pvhvm wheezy domu (vga passthrough) on wheezy hypervisor with hd4000 igd.
All seems working perfect since gnome-session starts (gdm3) after logging in, gnome-shell no render anything (only cursor and background).
In 'GNOME Classic' mode, which works like a charm, i run "glxinfo" without any problems and "glxgears" which show a dark window (no gears) whithout any errors.

Do you also have this issue ?

Sincerely,
---
Matt
--------------010406070105050704020008-- --===============1356092479356470483== 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 --===============1356092479356470483==-- From xen-users-bounces@lists.xen.org Fri Mar 22 17:04:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 17:04: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 1UJ5Mz-0006k1-Gg; Fri, 22 Mar 2013 17:03:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ5Mx-0006jr-Mi for xen-users@lists.xen.org; Fri, 22 Mar 2013 17:03:08 +0000 Received: from [85.158.137.99:9882] by server-16.bemta-3.messagelabs.com id EB/5A-20692-ACE8C415; Fri, 22 Mar 2013 17:03:06 +0000 X-Env-Sender: paul@stimpsonfamily.co.uk X-Msg-Ref: server-4.tower-217.messagelabs.com!1363971785!16973200!1 X-Originating-IP: [94.136.40.61] X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n,sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n,HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11196 invoked from network); 22 Mar 2013 17:03:05 -0000 Received: from mailex.mailcore.me (HELO mailex.mailcore.me) (94.136.40.61) by server-4.tower-217.messagelabs.com with SMTP; 22 Mar 2013 17:03:05 -0000 Received: from [192.165.210.4] (helo=[192.168.225.223]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UJ5Mu-0002c8-T0 for xen-users@lists.xen.org; Fri, 22 Mar 2013 17:03:05 +0000 Message-ID: <514C8EC9.9050000@stimpsonfamily.co.uk> Date: Fri, 22 Mar 2013 17:03:05 +0000 From: Paul Stimpson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Mailcore-Auth: 8324857 X-Mailcore-Domain: 844183 Subject: [Xen-users] Making VGA passthrough work X-BeenThere: xen-users@lists.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="===============5894534865469846689==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5894534865469846689== Content-Type: multipart/alternative; boundary="------------040107000100050707000603" This is a multi-part message in MIME format. --------------040107000100050707000603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm using Xen 4.2.0 built against a stock Ubuntu 12.04 (3.2.0-29-generic kernel) with a Windows Server 2008 R2 guest. PCI passthrough works flawlessly with a regular(non-GPU) card. The machine has 2 AMD/ATI FirePro V5900 cards and I now need to attach one of them to the Windows guest as its main monitor. I'm finding getting this working a challenge and conscious the instructions I've got from the wiki all mention Xen 4.0.0 so I don't know if they're still accurate. Each card presents itself as 2 PCI devices: a VGA controller and a sound card that provides the audio output on the HDMI sockets. I therefore have 4 devices: 04:00.0 : VGA device 04:00.1 : Sound card 05:00.0 : VGA device 05:00.1 : Sound card Firstly, I'm not sure how to tell which is the primary and which is secondary card as I swapped which was the primary in the BIOS to make the layout of the back panel and the cabling more logical. So far, I've discovered: I appear (according to the wiki) to be running the wrong PCI backend as kern.log contains a number of lines that say "xen-pciback: backend is vpci" That there is no entry in /boot/config-3.2.0-29-generic for either "CONFIG_XEN_PCIDEV_BACKEND_PASS" or "CONFIG_XEN_PCIDEV_BACKEND_VPCI"- Do these mean I need to roll my own kernel? I added the 04:00.0 and 04:00.1 to the options in /etc/modprobe.d/pciback.conf but they are still visible if I do an lspci on the host. Does this mean I've done something wrong? I added the following to the guest .conf file: gfx_passthru=1 pci=['0000:04:00.0'] (it already has a pci line in it for the other cards, so I added the non-GPU part of the card there) pci=['0000:06:00.0','0000:04:00.1'] The Windows guest is definitely booting. There is loads of HD activity and the web services it provides are visible across xenbr0. Both monitors start up. One displays the host's desktop 9as expected) but the other shows a black text-mode screen containing what looks like startup messages from the host. Note that I haven't installed the catalyst drivers in Windows yet (I'd assumed it would default to using the Firepro as a standard VGA and I could load the real drivers later. What do I need to do to get the right backend in and make the passthrough work please? Thanks, Paul. --------------040107000100050707000603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I'm using Xen 4.2.0 built against a stock Ubuntu 12.04 (3.2.0-29-generic kernel) with a Windows Server 2008 R2 guest. PCI passthrough works flawlessly with a regular(non-GPU) card. The machine has 2 AMD/ATI FirePro V5900 cards and I now need to attach one of them to the Windows guest as its main monitor.

I'm finding getting this working a challenge and conscious the instructions I've got from the wiki all mention Xen 4.0.0 so I don't know if they're still accurate.

Each card presents itself as 2 PCI devices: a VGA controller and a sound card that provides the audio output on the HDMI sockets. I therefore have 4 devices:
04:00.0 : VGA device
04:00.1 : Sound card
05:00.0 : VGA device
05:00.1 : Sound card
Firstly, I'm not sure how to tell which is the primary and which is secondary card as I swapped which was the primary in the BIOS to make the layout of the back panel and the cabling more logical.

So far, I've discovered:
I appear (according to the wiki) to be running the wrong PCI backend as kern.log contains a number of lines that say "xen-pciback: backend is vpci"

That there is no entry in /boot/config-3.2.0-29-generic for either "CONFIG_XEN_PCIDEV_BACKEND_PASS" or "CONFIG_XEN_PCIDEV_BACKEND_VPCI"- Do these mean I need to roll my own kernel?

I added the 04:00.0 and 04:00.1 to the options in /etc/modprobe.d/pciback.conf but they are still visible if I do an lspci on the host. Does this mean I've done something wrong?

I added the following to the guest .conf file:
gfx_passthru=1
pci=['0000:04:00.0']

(it already has a pci line in it for the other cards, so I added the non-GPU part of the card there)

pci=['0000:06:00.0','0000:04:00.1']

The Windows guest is definitely booting. There is loads of HD activity and the web services it provides are visible across xenbr0.

Both monitors start up. One displays the host's desktop 9as expected) but the other shows a black text-mode screen containing what looks like startup messages from the host. Note that I haven't installed the catalyst drivers in Windows yet (I'd assumed it would default to using the Firepro as a standard VGA and I could load the real drivers later.

What do I need to do to get the right backend in and make the passthrough work please?

Thanks,
Paul.

--------------040107000100050707000603-- --===============5894534865469846689== 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 --===============5894534865469846689==-- From xen-users-bounces@lists.xen.org Fri Mar 22 17:04:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 17:04: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 1UJ5Mz-0006k1-Gg; Fri, 22 Mar 2013 17:03:09 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ5Mx-0006jr-Mi for xen-users@lists.xen.org; Fri, 22 Mar 2013 17:03:08 +0000 Received: from [85.158.137.99:9882] by server-16.bemta-3.messagelabs.com id EB/5A-20692-ACE8C415; Fri, 22 Mar 2013 17:03:06 +0000 X-Env-Sender: paul@stimpsonfamily.co.uk X-Msg-Ref: server-4.tower-217.messagelabs.com!1363971785!16973200!1 X-Originating-IP: [94.136.40.61] X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n,sa_preprocessor: QmFkIElQOiA5NC4xMzYuNDAuNjEgPT4gNTQwMTg=\n,HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11196 invoked from network); 22 Mar 2013 17:03:05 -0000 Received: from mailex.mailcore.me (HELO mailex.mailcore.me) (94.136.40.61) by server-4.tower-217.messagelabs.com with SMTP; 22 Mar 2013 17:03:05 -0000 Received: from [192.165.210.4] (helo=[192.168.225.223]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UJ5Mu-0002c8-T0 for xen-users@lists.xen.org; Fri, 22 Mar 2013 17:03:05 +0000 Message-ID: <514C8EC9.9050000@stimpsonfamily.co.uk> Date: Fri, 22 Mar 2013 17:03:05 +0000 From: Paul Stimpson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "xen-users@lists.xen.org" X-Mailcore-Auth: 8324857 X-Mailcore-Domain: 844183 Subject: [Xen-users] Making VGA passthrough work X-BeenThere: xen-users@lists.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="===============5894534865469846689==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5894534865469846689== Content-Type: multipart/alternative; boundary="------------040107000100050707000603" This is a multi-part message in MIME format. --------------040107000100050707000603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm using Xen 4.2.0 built against a stock Ubuntu 12.04 (3.2.0-29-generic kernel) with a Windows Server 2008 R2 guest. PCI passthrough works flawlessly with a regular(non-GPU) card. The machine has 2 AMD/ATI FirePro V5900 cards and I now need to attach one of them to the Windows guest as its main monitor. I'm finding getting this working a challenge and conscious the instructions I've got from the wiki all mention Xen 4.0.0 so I don't know if they're still accurate. Each card presents itself as 2 PCI devices: a VGA controller and a sound card that provides the audio output on the HDMI sockets. I therefore have 4 devices: 04:00.0 : VGA device 04:00.1 : Sound card 05:00.0 : VGA device 05:00.1 : Sound card Firstly, I'm not sure how to tell which is the primary and which is secondary card as I swapped which was the primary in the BIOS to make the layout of the back panel and the cabling more logical. So far, I've discovered: I appear (according to the wiki) to be running the wrong PCI backend as kern.log contains a number of lines that say "xen-pciback: backend is vpci" That there is no entry in /boot/config-3.2.0-29-generic for either "CONFIG_XEN_PCIDEV_BACKEND_PASS" or "CONFIG_XEN_PCIDEV_BACKEND_VPCI"- Do these mean I need to roll my own kernel? I added the 04:00.0 and 04:00.1 to the options in /etc/modprobe.d/pciback.conf but they are still visible if I do an lspci on the host. Does this mean I've done something wrong? I added the following to the guest .conf file: gfx_passthru=1 pci=['0000:04:00.0'] (it already has a pci line in it for the other cards, so I added the non-GPU part of the card there) pci=['0000:06:00.0','0000:04:00.1'] The Windows guest is definitely booting. There is loads of HD activity and the web services it provides are visible across xenbr0. Both monitors start up. One displays the host's desktop 9as expected) but the other shows a black text-mode screen containing what looks like startup messages from the host. Note that I haven't installed the catalyst drivers in Windows yet (I'd assumed it would default to using the Firepro as a standard VGA and I could load the real drivers later. What do I need to do to get the right backend in and make the passthrough work please? Thanks, Paul. --------------040107000100050707000603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I'm using Xen 4.2.0 built against a stock Ubuntu 12.04 (3.2.0-29-generic kernel) with a Windows Server 2008 R2 guest. PCI passthrough works flawlessly with a regular(non-GPU) card. The machine has 2 AMD/ATI FirePro V5900 cards and I now need to attach one of them to the Windows guest as its main monitor.

I'm finding getting this working a challenge and conscious the instructions I've got from the wiki all mention Xen 4.0.0 so I don't know if they're still accurate.

Each card presents itself as 2 PCI devices: a VGA controller and a sound card that provides the audio output on the HDMI sockets. I therefore have 4 devices:
04:00.0 : VGA device
04:00.1 : Sound card
05:00.0 : VGA device
05:00.1 : Sound card
Firstly, I'm not sure how to tell which is the primary and which is secondary card as I swapped which was the primary in the BIOS to make the layout of the back panel and the cabling more logical.

So far, I've discovered:
I appear (according to the wiki) to be running the wrong PCI backend as kern.log contains a number of lines that say "xen-pciback: backend is vpci"

That there is no entry in /boot/config-3.2.0-29-generic for either "CONFIG_XEN_PCIDEV_BACKEND_PASS" or "CONFIG_XEN_PCIDEV_BACKEND_VPCI"- Do these mean I need to roll my own kernel?

I added the 04:00.0 and 04:00.1 to the options in /etc/modprobe.d/pciback.conf but they are still visible if I do an lspci on the host. Does this mean I've done something wrong?

I added the following to the guest .conf file:
gfx_passthru=1
pci=['0000:04:00.0']

(it already has a pci line in it for the other cards, so I added the non-GPU part of the card there)

pci=['0000:06:00.0','0000:04:00.1']

The Windows guest is definitely booting. There is loads of HD activity and the web services it provides are visible across xenbr0.

Both monitors start up. One displays the host's desktop 9as expected) but the other shows a black text-mode screen containing what looks like startup messages from the host. Note that I haven't installed the catalyst drivers in Windows yet (I'd assumed it would default to using the Firepro as a standard VGA and I could load the real drivers later.

What do I need to do to get the right backend in and make the passthrough work please?

Thanks,
Paul.

--------------040107000100050707000603-- --===============5894534865469846689== 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 --===============5894534865469846689==-- From xen-users-bounces@lists.xen.org Fri Mar 22 17:22:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 17:22: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 1UJ5eg-00075j-Ll; Fri, 22 Mar 2013 17:21:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ5ee-00075e-Sp for xen-users@lists.xen.org; Fri, 22 Mar 2013 17:21:25 +0000 Received: from [85.158.137.99:43692] by server-16.bemta-3.messagelabs.com id 96/39-20692-F039C415; Fri, 22 Mar 2013 17:21:19 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1363972871!14940860!1 X-Originating-IP: [209.85.212.47] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28882 invoked from network); 22 Mar 2013 17:21:13 -0000 Received: from mail-vb0-f47.google.com (HELO mail-vb0-f47.google.com) (209.85.212.47) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 22 Mar 2013 17:21:13 -0000 Received: by mail-vb0-f47.google.com with SMTP id e21so2658996vbm.6 for ; Fri, 22 Mar 2013 10:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OPveSOImhSei1mnKSD4BbljNbKA5lTZLcKSeGn5pi3Y=; b=VBBX0PUWSxNR37YJtfia6mNP0UMaRIUYwJd/+AClrZX4Cx/s+dgEEkXeIDayTJdgnZ L5u4UoJbXPGobFxhrpG2jsmFQSDzgELW3KCKDq6YGLAMhu10oDg7XTsyEDdesh3u6Lhr M40HK5In977K7bV6wBJviRgU+/w0sC0Dx4ljyUkJugssDfYgt0NpMqtiS6wTl1/UTj9m X3br4Aybhl1v3KZXSN6XuzOQdBB7iqcWTJsKR3QKTd7x+1MC+bAoKnspaly1T3UHcl0s 5dCHgdzfggXQ80xRHxM0XcbM1L2Zg+XtpTjODTnd+GMeCJOV0p9EfjTiacZlRXNT9pWb InZQ== MIME-Version: 1.0 X-Received: by 10.58.50.7 with SMTP id y7mr3334447ven.24.1363972871450; Fri, 22 Mar 2013 10:21:11 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Fri, 22 Mar 2013 10:21:11 -0700 (PDT) In-Reply-To: <514C8EC9.9050000@stimpsonfamily.co.uk> References: <514C8EC9.9050000@stimpsonfamily.co.uk> Date: Fri, 22 Mar 2013 13:21:11 -0400 Message-ID: From: Casey DeLorme To: Paul Stimpson Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Making VGA passthrough work X-BeenThere: xen-users@lists.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="===============6852683438816399850==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6852683438816399850== Content-Type: multipart/alternative; boundary=089e0112c63a7caae404d886ae5f --089e0112c63a7caae404d886ae5f Content-Type: text/plain; charset=UTF-8 Hi Paul, The lspci will always list the hardware even once passed to pciback, it still exists in Dom0 but its drivers should no longer be loaded. Assuming you are using the xl toolstack with 4.2, have you tried running `xl pci-assignable-list`? Does it print the devices you passed to pciback? If not then your pciback module is not working at boot time. If you want it working at boot time you can roll your own kernel or rebuild the initramfs with the modules xen installed. Alternatively Xen 4.2 offers xl commands `xl pci-assignable-add` and `xl pci-assignable-remove`, which should attempt to automatically dislodge the card from Dom0 at run-time. If that works you could just add a script at boot time instead of rebuilding either initramfs or the kernel. You may still need to connect to Windows via SDL or VNC to install the drivers before you get video output, unless Windows automatically installs them, but I don't know how Windows Server will react to being passed a device at run-time. If you want a mostly up to date reference you should try my comprehensive xen tutorial, it was written for Debian and Xen 4.2 unstable, but the kernel building instructions and a few others are still mostly accurate for the stable revisions. However, I have never tried simply rebuilding the initramfs, so I don't have instructions for that. Also, if you haven't yet you should read the xen 4.2 man pages, they are very helpful for configuring machines. Hope that helps, ~Casey On Fri, Mar 22, 2013 at 1:03 PM, Paul Stimpson wrote: > Hi, > > I'm using Xen 4.2.0 built against a stock Ubuntu 12.04 (3.2.0-29-generic > kernel) with a Windows Server 2008 R2 guest. PCI passthrough works > flawlessly with a regular(non-GPU) card. The machine has 2 AMD/ATI FirePro > V5900 cards and I now need to attach one of them to the Windows guest as > its main monitor. > > I'm finding getting this working a challenge and conscious the > instructions I've got from the wiki all mention Xen 4.0.0 so I don't know > if they're still accurate. > > Each card presents itself as 2 PCI devices: a VGA controller and a sound > card that provides the audio output on the HDMI sockets. I therefore have 4 > devices: > > 04:00.0 : VGA device > 04:00.1 : Sound card > 05:00.0 : VGA device > 05:00.1 : Sound card > > Firstly, I'm not sure how to tell which is the primary and which is > secondary card as I swapped which was the primary in the BIOS to make the > layout of the back panel and the cabling more logical. > > So far, I've discovered: > > I appear (according to the wiki) to be running the wrong PCI backend as > kern.log contains a number of lines that say "xen-pciback: backend is vpci" > > That there is no entry in /boot/config-3.2.0-29-generic for either > "CONFIG_XEN_PCIDEV_BACKEND_PASS" or "CONFIG_XEN_PCIDEV_BACKEND_VPCI"- Do > these mean I need to roll my own kernel? > > I added the 04:00.0 and 04:00.1 to the options in > /etc/modprobe.d/pciback.conf but they are still visible if I do an lspci on > the host. Does this mean I've done something wrong? > > I added the following to the guest .conf file: > > gfx_passthru=1 > pci=['0000:04:00.0'] > > (it already has a pci line in it for the other cards, so I added the > non-GPU part of the card there) > > pci=['0000:06:00.0','0000:04:00.1'] > > The Windows guest is definitely booting. There is loads of HD activity > and the web services it provides are visible across xenbr0. > > Both monitors start up. One displays the host's desktop 9as expected) but > the other shows a black text-mode screen containing what looks like startup > messages from the host. Note that I haven't installed the catalyst drivers > in Windows yet (I'd assumed it would default to using the Firepro as a > standard VGA and I could load the real drivers later. > > What do I need to do to get the right backend in and make the passthrough > work please? > > Thanks, > Paul. > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --089e0112c63a7caae404d886ae5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

The lspci will alwa= ys list the hardware even once passed to pciback, it still exists in Dom0 b= ut its drivers should no longer be loaded.

Assumin= g you are using the xl toolstack with 4.2, have you tried running `xl pci-a= ssignable-list`? =C2=A0Does it print the devices you passed to pciback?

If not then your pciback module is not working at boot = time. =C2=A0If you want it working at boot time you can roll your own kerne= l or rebuild the initramfs with the modules xen installed.

Alternatively Xen 4.2 offers xl commands `xl pci-assignable-add` and `= xl pci-assignable-remove`, which should attempt to automatically dislodge t= he card from Dom0 at run-time. =C2=A0If that works you could just add a scr= ipt at boot time instead of rebuilding either initramfs or the kernel.

You may still need to connect to Windows via SDL or VNC= to install the drivers before you get video output, unless Windows automat= ically installs them, but I don't know how Windows Server will react to= being passed a device at run-time.

If you want a mostly up to date reference you should tr= y my comprehensive xen tutorial, it was written for = Debian and Xen 4.2 unstable, but the kernel building instructions and a few= others are still mostly accurate for the stable revisions. =C2=A0However, = I have never tried simply rebuilding the initramfs, so I don't have ins= tructions for that.

Also, if you haven't yet you should read the xen 4.2 man pages, the= y are very helpful for configuring machines.

Hope = that helps,

~Casey


On Fri, Mar 22, 2013 at 1:03 PM, Paul Stimpson <paul@stimpsonfamily.co.uk> wrote:
=20 =20 =20
Hi,

I'm using Xen 4.2.0 built against a stock Ubuntu 12.04 (3.2.0-29-generic kernel) with a Windows Server 2008 R2 guest. PCI passthrough works flawlessly with a regular(non-GPU) card. The machine has 2 AMD/ATI FirePro V5900 cards and I now need to attach one of them to the Windows guest as its main monitor.

I'm finding getting this working a challenge and conscious the instructions I've got from the wiki all mention Xen 4.0.0 so I don&= #39;t know if they're still accurate.

Each card presents itself as 2 PCI devices: a VGA controller and a sound card that provides the audio output on the HDMI sockets. I therefore have 4 devices:
04:00.0 : VGA device
04:00.1 : Sound card
05:00.0 : VGA device
05:00.1 : Sound card
Firstly, I'm not sure how to tell which is the primary and which is secondary card as I swapped which was the primary in the BIOS to make the layout of the back panel and the cabling more logical.

So far, I've discovered:
I appear (according to the wiki) to be running the wrong PCI backend as kern.log contains a number of lines that say "xen-pciback: backend is vpci"

That there is no entry in /boot/config-3.2.0-29-generic for either "CONFIG_XEN_PCIDEV_BACKEND_PASS" or "CONFIG_XEN_PCIDEV_BACKEND_VPCI"- Do these mean I need to r= oll my own kernel?

I added the 04:00.0 and 04:00.1 to the options in /etc/modprobe.d/pciback.conf but they are still visible if I do an lspci on the host. Does this mean I've done something wrong?

I added the following to the guest .conf file:
gfx_passthru=3D1
pci=3D['0000:04:00.0']

(it already has a pci line in it for the other cards, so I added the non-GPU part of the card there)

pci=3D['0000:06:00.0','0000:04:00.1']

The Windows guest is definitely booting. There is loads of HD activity and the web services it provides are visible across xenbr0.

Both monitors start up. One displays the host's desktop 9as expected) but the other shows a black text-mode screen containing what looks like startup messages from the host. Note that I haven't installed the catalyst drivers in Windows yet (I'd as= sumed it would default to using the Firepro as a standard VGA and I could load the real drivers later.

What do I need to do to get the right backend in and make the passthrough work please?

Thanks,
Paul.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--089e0112c63a7caae404d886ae5f-- --===============6852683438816399850== 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 --===============6852683438816399850==-- From xen-users-bounces@lists.xen.org Fri Mar 22 17:22:33 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 17:22: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 1UJ5eg-00075j-Ll; Fri, 22 Mar 2013 17:21:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ5ee-00075e-Sp for xen-users@lists.xen.org; Fri, 22 Mar 2013 17:21:25 +0000 Received: from [85.158.137.99:43692] by server-16.bemta-3.messagelabs.com id 96/39-20692-F039C415; Fri, 22 Mar 2013 17:21:19 +0000 X-Env-Sender: cdelorme@gmail.com X-Msg-Ref: server-9.tower-217.messagelabs.com!1363972871!14940860!1 X-Originating-IP: [209.85.212.47] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28882 invoked from network); 22 Mar 2013 17:21:13 -0000 Received: from mail-vb0-f47.google.com (HELO mail-vb0-f47.google.com) (209.85.212.47) by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 22 Mar 2013 17:21:13 -0000 Received: by mail-vb0-f47.google.com with SMTP id e21so2658996vbm.6 for ; Fri, 22 Mar 2013 10:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OPveSOImhSei1mnKSD4BbljNbKA5lTZLcKSeGn5pi3Y=; b=VBBX0PUWSxNR37YJtfia6mNP0UMaRIUYwJd/+AClrZX4Cx/s+dgEEkXeIDayTJdgnZ L5u4UoJbXPGobFxhrpG2jsmFQSDzgELW3KCKDq6YGLAMhu10oDg7XTsyEDdesh3u6Lhr M40HK5In977K7bV6wBJviRgU+/w0sC0Dx4ljyUkJugssDfYgt0NpMqtiS6wTl1/UTj9m X3br4Aybhl1v3KZXSN6XuzOQdBB7iqcWTJsKR3QKTd7x+1MC+bAoKnspaly1T3UHcl0s 5dCHgdzfggXQ80xRHxM0XcbM1L2Zg+XtpTjODTnd+GMeCJOV0p9EfjTiacZlRXNT9pWb InZQ== MIME-Version: 1.0 X-Received: by 10.58.50.7 with SMTP id y7mr3334447ven.24.1363972871450; Fri, 22 Mar 2013 10:21:11 -0700 (PDT) Received: by 10.58.106.230 with HTTP; Fri, 22 Mar 2013 10:21:11 -0700 (PDT) In-Reply-To: <514C8EC9.9050000@stimpsonfamily.co.uk> References: <514C8EC9.9050000@stimpsonfamily.co.uk> Date: Fri, 22 Mar 2013 13:21:11 -0400 Message-ID: From: Casey DeLorme To: Paul Stimpson Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Making VGA passthrough work X-BeenThere: xen-users@lists.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="===============6852683438816399850==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6852683438816399850== Content-Type: multipart/alternative; boundary=089e0112c63a7caae404d886ae5f --089e0112c63a7caae404d886ae5f Content-Type: text/plain; charset=UTF-8 Hi Paul, The lspci will always list the hardware even once passed to pciback, it still exists in Dom0 but its drivers should no longer be loaded. Assuming you are using the xl toolstack with 4.2, have you tried running `xl pci-assignable-list`? Does it print the devices you passed to pciback? If not then your pciback module is not working at boot time. If you want it working at boot time you can roll your own kernel or rebuild the initramfs with the modules xen installed. Alternatively Xen 4.2 offers xl commands `xl pci-assignable-add` and `xl pci-assignable-remove`, which should attempt to automatically dislodge the card from Dom0 at run-time. If that works you could just add a script at boot time instead of rebuilding either initramfs or the kernel. You may still need to connect to Windows via SDL or VNC to install the drivers before you get video output, unless Windows automatically installs them, but I don't know how Windows Server will react to being passed a device at run-time. If you want a mostly up to date reference you should try my comprehensive xen tutorial, it was written for Debian and Xen 4.2 unstable, but the kernel building instructions and a few others are still mostly accurate for the stable revisions. However, I have never tried simply rebuilding the initramfs, so I don't have instructions for that. Also, if you haven't yet you should read the xen 4.2 man pages, they are very helpful for configuring machines. Hope that helps, ~Casey On Fri, Mar 22, 2013 at 1:03 PM, Paul Stimpson wrote: > Hi, > > I'm using Xen 4.2.0 built against a stock Ubuntu 12.04 (3.2.0-29-generic > kernel) with a Windows Server 2008 R2 guest. PCI passthrough works > flawlessly with a regular(non-GPU) card. The machine has 2 AMD/ATI FirePro > V5900 cards and I now need to attach one of them to the Windows guest as > its main monitor. > > I'm finding getting this working a challenge and conscious the > instructions I've got from the wiki all mention Xen 4.0.0 so I don't know > if they're still accurate. > > Each card presents itself as 2 PCI devices: a VGA controller and a sound > card that provides the audio output on the HDMI sockets. I therefore have 4 > devices: > > 04:00.0 : VGA device > 04:00.1 : Sound card > 05:00.0 : VGA device > 05:00.1 : Sound card > > Firstly, I'm not sure how to tell which is the primary and which is > secondary card as I swapped which was the primary in the BIOS to make the > layout of the back panel and the cabling more logical. > > So far, I've discovered: > > I appear (according to the wiki) to be running the wrong PCI backend as > kern.log contains a number of lines that say "xen-pciback: backend is vpci" > > That there is no entry in /boot/config-3.2.0-29-generic for either > "CONFIG_XEN_PCIDEV_BACKEND_PASS" or "CONFIG_XEN_PCIDEV_BACKEND_VPCI"- Do > these mean I need to roll my own kernel? > > I added the 04:00.0 and 04:00.1 to the options in > /etc/modprobe.d/pciback.conf but they are still visible if I do an lspci on > the host. Does this mean I've done something wrong? > > I added the following to the guest .conf file: > > gfx_passthru=1 > pci=['0000:04:00.0'] > > (it already has a pci line in it for the other cards, so I added the > non-GPU part of the card there) > > pci=['0000:06:00.0','0000:04:00.1'] > > The Windows guest is definitely booting. There is loads of HD activity > and the web services it provides are visible across xenbr0. > > Both monitors start up. One displays the host's desktop 9as expected) but > the other shows a black text-mode screen containing what looks like startup > messages from the host. Note that I haven't installed the catalyst drivers > in Windows yet (I'd assumed it would default to using the Firepro as a > standard VGA and I could load the real drivers later. > > What do I need to do to get the right backend in and make the passthrough > work please? > > Thanks, > Paul. > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --089e0112c63a7caae404d886ae5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

The lspci will alwa= ys list the hardware even once passed to pciback, it still exists in Dom0 b= ut its drivers should no longer be loaded.

Assumin= g you are using the xl toolstack with 4.2, have you tried running `xl pci-a= ssignable-list`? =C2=A0Does it print the devices you passed to pciback?

If not then your pciback module is not working at boot = time. =C2=A0If you want it working at boot time you can roll your own kerne= l or rebuild the initramfs with the modules xen installed.

Alternatively Xen 4.2 offers xl commands `xl pci-assignable-add` and `= xl pci-assignable-remove`, which should attempt to automatically dislodge t= he card from Dom0 at run-time. =C2=A0If that works you could just add a scr= ipt at boot time instead of rebuilding either initramfs or the kernel.

You may still need to connect to Windows via SDL or VNC= to install the drivers before you get video output, unless Windows automat= ically installs them, but I don't know how Windows Server will react to= being passed a device at run-time.

If you want a mostly up to date reference you should tr= y my comprehensive xen tutorial, it was written for = Debian and Xen 4.2 unstable, but the kernel building instructions and a few= others are still mostly accurate for the stable revisions. =C2=A0However, = I have never tried simply rebuilding the initramfs, so I don't have ins= tructions for that.

Also, if you haven't yet you should read the xen 4.2 man pages, the= y are very helpful for configuring machines.

Hope = that helps,

~Casey


On Fri, Mar 22, 2013 at 1:03 PM, Paul Stimpson <paul@stimpsonfamily.co.uk> wrote:
=20 =20 =20
Hi,

I'm using Xen 4.2.0 built against a stock Ubuntu 12.04 (3.2.0-29-generic kernel) with a Windows Server 2008 R2 guest. PCI passthrough works flawlessly with a regular(non-GPU) card. The machine has 2 AMD/ATI FirePro V5900 cards and I now need to attach one of them to the Windows guest as its main monitor.

I'm finding getting this working a challenge and conscious the instructions I've got from the wiki all mention Xen 4.0.0 so I don&= #39;t know if they're still accurate.

Each card presents itself as 2 PCI devices: a VGA controller and a sound card that provides the audio output on the HDMI sockets. I therefore have 4 devices:
04:00.0 : VGA device
04:00.1 : Sound card
05:00.0 : VGA device
05:00.1 : Sound card
Firstly, I'm not sure how to tell which is the primary and which is secondary card as I swapped which was the primary in the BIOS to make the layout of the back panel and the cabling more logical.

So far, I've discovered:
I appear (according to the wiki) to be running the wrong PCI backend as kern.log contains a number of lines that say "xen-pciback: backend is vpci"

That there is no entry in /boot/config-3.2.0-29-generic for either "CONFIG_XEN_PCIDEV_BACKEND_PASS" or "CONFIG_XEN_PCIDEV_BACKEND_VPCI"- Do these mean I need to r= oll my own kernel?

I added the 04:00.0 and 04:00.1 to the options in /etc/modprobe.d/pciback.conf but they are still visible if I do an lspci on the host. Does this mean I've done something wrong?

I added the following to the guest .conf file:
gfx_passthru=3D1
pci=3D['0000:04:00.0']

(it already has a pci line in it for the other cards, so I added the non-GPU part of the card there)

pci=3D['0000:06:00.0','0000:04:00.1']

The Windows guest is definitely booting. There is loads of HD activity and the web services it provides are visible across xenbr0.

Both monitors start up. One displays the host's desktop 9as expected) but the other shows a black text-mode screen containing what looks like startup messages from the host. Note that I haven't installed the catalyst drivers in Windows yet (I'd as= sumed it would default to using the Firepro as a standard VGA and I could load the real drivers later.

What do I need to do to get the right backend in and make the passthrough work please?

Thanks,
Paul.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.x= en.org/xen-users

--089e0112c63a7caae404d886ae5f-- --===============6852683438816399850== 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 --===============6852683438816399850==-- From xen-users-bounces@lists.xen.org Fri Mar 22 19:46:15 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 19:46: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 1UJ7tf-0008Mw-Gw; Fri, 22 Mar 2013 19:45:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ7td-0008Mr-GB for xen-users@lists.xen.org; Fri, 22 Mar 2013 19:45:02 +0000 Received: from [85.158.139.83:24173] by server-9.bemta-5.messagelabs.com id F6/E7-08547-CB4BC415; Fri, 22 Mar 2013 19:45:00 +0000 X-Env-Sender: eross@corp.locatrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1363981497!23557559!1 X-Originating-IP: [209.85.223.179] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1414 invoked from network); 22 Mar 2013 19:44:58 -0000 Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com) (209.85.223.179) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Mar 2013 19:44:58 -0000 Received: by mail-ie0-f179.google.com with SMTP id k11so5319430iea.10 for ; Fri, 22 Mar 2013 12:44:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=ZWJVruRTL1lHXq4TinEOOruWRgCF3OzwTRnVtuNk18k=; b=ICHETUcx8GlAjXpF8OkrdKEAY4Va1Yodi0LgPr5RefpUoZqTsC1+uT+WsFRObbPCWL L7WOPffowVj0h2VQWq7WrSE1g2gfWYqdMZxFlnTueGpk3xvXriUl9Q31p/RebWkC4xGI 0L0/D88+IQSKA8c92G0SH32w2LVvTUyjvjKS2cUmC9r+H6Y8hffnlU1+I2ZSXLgYCfCg lLObFk0zhLAId4nTDgpTEGh5cxen22FDc0Kw7Z9pI9b9xl1kXVofvYjCHBz3g5ok6I4L ERy8VWkTJiKShHddVxa2vVwPc36NB9KyGpTm9lQ/IQRTdzk4lerP41Cu5hZcgxUXL9Jm OEcQ== X-Received: by 10.50.203.72 with SMTP id ko8mr2021180igc.93.1363981496546; Fri, 22 Mar 2013 12:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.53.234 with HTTP; Fri, 22 Mar 2013 12:44:36 -0700 (PDT) In-Reply-To: References: From: Andrew Eross Date: Fri, 22 Mar 2013 15:44:36 -0400 Message-ID: To: "R. Jeremy" X-Gm-Message-State: ALoCoQnzj2xc2TX2OmnmE7nWh5yw4IvSX3RQwtzHYF0PpV4bnETSd64TtFP8j9wfrn+H6moRAFM/ Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Xen 3 High Availability ways X-BeenThere: xen-users@lists.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="===============4787319418910876022==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4787319418910876022== Content-Type: multipart/alternative; boundary=14dae934123d9519bc04d888b079 --14dae934123d9519bc04d888b079 Content-Type: text/plain; charset=ISO-8859-1 Hi, I've been working on this issue myself in my spare time for a while now, testing all the various systems and methods of creating a simple HA cluster (or at least machine pairs) using Xen or other virtualization methods with commodity hardware. It depends a lot on what type of hardware setup you're going to use.. and if you're looking for a "cluster" vs. something like 2-node HA. Myself, I've been mostly interested in simple 2-node setups using heterogeneous hardware, so I've not been much interested in using XenServer/XCP pools, which require very similar hardware. I also don't have SAN hardware, so I've preferred solutions that use the local server disks instead of shared storage. End of the day my number one goal has just been to find the best way to have a stable HA setup for database server VMs. Here's all the ways I've looked into, and my notes Please note, it's all just my own opinion here... - XCP HA - Does not support native HA from version 1.6 (I seem to recall it was working back in 1.1 or so, I think? - might've been disabled at some point by Citrix, which would be perfectly fair really since you should pay for the feature) - Does support pooling, but you need "identical" servers - Some support for differing CPU types, but still needs to be close - http://support.citrix.com/article/CTX127059 - VMs using local disk storage require a home server (where it starts from) - Pools support live migration even with local storage - Can move running VM from one machine to another fairly seamlessly - Note, again, as above, does not natively support HA - XenServer HA - $1500/server license for Advanced required for HA - Pretty much everything is the same as for XCP but also supports HA - You need shared storage for this (can be DRBD or an expensive SAN type device) - Also requires a shared heartbeat SR for HA (e.g. on a NAS or something) - If you can afford it, then certainly I do recommend this option, Citrix offers a generous trial period as well to give it a shot - XenServer with DRBD and Pacemaker - 2-node HA setup - It's possible to use DRBD with Primary/Primary to support live migration, but I don't trust it since I've had too many finicky issues, there's more split brain problems, etc, so I use Primary/Secondary - Linbit provides some docs about DRBD + XenServer if you google it - HA in this case means that Pacemaker automatically moves DRBD to Primary on the secondary node in case of failure, attaches the SR, and restarts the VMs.. this does not save the running machine state / memory state, and takes, say, maybe 45 seconds for the switch-over - This is what I actually have running in some production environments, and to me is the easy "that'll work and be reliable" answer - I wrote some Pacemaker plugins to help manage the VMs and the PBD/SR for automatic fail-over: https://github.com/locatrix/xs-pacemaker - The admin for this type of setup should be fairly DRBD and XenServer savvy in case of problems, but overall it does work, and DRBD is a rock - Xen with Remus - Works by using Xen's existing live migration system, so you have to do everything to get live migration working first, and then you can use Remus to automate fail-over - Has a number of guest and performance limitations; I wrote up some more information here on the updated page: http://wiki.xen.org/wiki/Remus - Once it's running it's really cool since it does literally allow a VM to fail-over to a secondary machine with practically no interruption, migrates memory, network connections, etc - However, to be honest, I've found from a practical perspective, that Remus isn't production ready, and is more interesting as an academic project - I had too many weird problems, crashes, guest incompatibilities, and theoretical performance problems, etc, to count on it - e.g. immediate killer for me is that Ubuntu guests basically don't work without some serious kernel hacking - CloudStack - Citrix CloudStack (now Apache CloudStack) is a mature java based solution for cloud management. It supports KVM, XenServer, and VMWare hosts in a unified cloud platform. - It's free - CS has a really nice web UI interface that is impressive at a first glance. - Respects HA built-in to XenServer, but basically doesn't add anything new there, so for simple HA purposes you don't really gain much by using CloudStack, just additional complexity with a nice UI - In general it's very much oriented towards bigger installations, and there are those who are successfully using it for large scale projects - My opinion for our smaller setup (we have 1 rack in a colo) is that it's overkill and I've had a lot of trouble getting it to work in a basic lab environment... I've often had the experience I've heard from many others about "getting stuck on a spinner and having to dig down through a bunch of obscure log files with java exception errors to try to figure out what went wrong" - OpenStack - TBD; I've haven't done much with it yet; it's on my list - Also a big installation oriented project, and obviously interesting in terms of the volume of industry support, etc - Proxmox - Not Xen based, but a really cool and interesting project for smaller installations, worth mentioning to check it out - I haven't done quite enough experimenting with it yet, but it does have some native clustering and HA support, although it requires a DRBD primary/primary setup to work with it's built-in HA - Google Ganeti, which uses KVM and Xen - Next up on my list of things to play with when I get a chance Cheers, Andrew On Tue, Mar 12, 2013 at 10:29 AM, R. Jeremy wrote: > Hi, > > I'm new in Xensource World. I have to work on Xen 3.1.2 hypervisor, I've > done some searches on how to make Xen HA (not FT for the moment). > The way that is come again and again is to make a cluster with Corosync, > pacemaker, DRDB. I just want to now if there are others way to do Xen HA, > and which is the best way in your opinion? > I need something very stable and sustainable. > > I've seen many others mails of this subject, but we never know what is the > best way. And this is often for Xen 4. > > I'm french, so I hope you'll understand my english... > > Thanks! > > BR > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --14dae934123d9519bc04d888b079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I've been working on this issue myself in = my spare time for a while now, testing all the various systems and methods = of creating a simple HA cluster (or at least machine pairs) using Xen or ot= her virtualization methods with commodity hardware.

It depends a lot on what type of hardware setup you're g= oing to use.. and if you're looking for a "cluster" vs. somet= hing like 2-node HA.

Myself, I've been mostly = interested in simple 2-node setups using heterogeneous hardware, so I'v= e not been much interested in using XenServer/XCP pools, which require very= similar hardware. I also don't have SAN hardware, so I've preferre= d solutions that use the local server disks instead of shared storage.

End of the day my number one goal has just been to find= the best way to have a stable HA setup for database server VMs.

Here's all the ways I've looked into, and my notes

Please note, it's all just my own opinion here.= ..
  • XCP HA
    • Does not support native HA from versio= n 1.6 (I seem to recall it was working back in 1.1 or so, I think? - might&= #39;ve been disabled at some point by Citrix, which would be perfectly fair= really since you should pay for the feature)
    • Does support pooling, but you need "identical" servers
    • Some support for differing CPU types, but still needs to be close
    • http://support.citrix.com/article/CTX127059
  • VMs using local disk storage require a home server (where it start= s from)
  • Pools support live migration even with local storage
    • Can move running VM from one machine to another fairly seamlessly
  • Note, again, as above, does not natively support HA
  • XenServer HA
    • $1500/server license for Advanced require= d for HA
    • Pretty much everything is the same as for XCP but also sup= ports HA
    • You need shared storage for this (can be DRBD or an expens= ive SAN type device)
    • Also requires a shared heartbeat SR for HA (e.g. on a NAS or something)=
    • If you can afford it, then certainly I do recommend this option, C= itrix offers a generous trial period as well to give it a shot
  • XenServer with DRBD and Pacemaker
    • 2-node HA setup
    • I= t's possible to use DRBD with Primary/Primary to support live migration= , but I don't trust it since I've had too many finicky issues, ther= e's more split brain problems, etc, so I use Primary/Secondary
    • Linbit provides some docs about DRBD + XenServer if you google it
      • <= li>HA in this case means that Pacemaker automatically moves DRBD to Primary= on the secondary node in case of failure, attaches the SR, and restarts th= e VMs.. this does not save the running machine state / memory state, and ta= kes, say, maybe 45 seconds for the switch-over
    • This is what I actually have running in some production environments, a= nd to me is the easy "that'll work and be reliable" answer
    • I wrote some Pacemaker plugins to help manage the VMs and the PBD/SR fo= r automatic fail-over:=A0https://github.com/locatrix/xs-pacemaker
    • T= he admin for this type of setup should be fairly DRBD and XenServer savvy i= n case of problems, but overall it does work, and DRBD is a rock
  • Xen with Remus
    • Works by using Xen's existing live = migration system, so you have to do everything to get live migration workin= g first, and then you can use Remus to automate fail-over
    • Has a number of guest and performance limitations; I wrote up some more= information here on the updated page: http://wiki.xen.org/wiki/Remus
    • Once it= 's running it's really cool since it does literally allow a VM to f= ail-over to a secondary machine with practically no interruption, migrates = memory, network connections, etc
    • However, to be honest, I've found from a practical perspective, tha= t Remus isn't production ready, and is more interesting as an academic = project
    • I had too many weird problems, crashes, guest incompatibili= ties, and theoretical performance problems, etc, to count on it
    • e.g. immediate killer for me is that Ubuntu guests basically don't = work without some serious kernel hacking
  • CloudStack
    • Citrix CloudStack (now Apache CloudStack) = is a mature java based solution for cloud management. It supports KVM, XenS= erver, and VMWare hosts in a unified cloud platform.
    • It's free
    • CS has a really nice web UI interface th= at is impressive at a first glance.
    • Respects HA built-in to XenServer, but = basically doesn't add anything new there, so for simple HA purposes you= don't really gain much by using CloudStack, just additional complexity= with a nice UI
    • In general it's very much oriented = towards bigger installations, and there are those who are successfully usin= g it for large scale projects
    • My opinion for our smaller setup (we ha= ve 1 rack in a colo) is that it's overkill and I've had a lot of tr= ouble getting it to work in a basic lab environment... I've often had t= he experience I've heard from many others about "getting stuck on = a spinner and having to dig down through a bunch of obscure log files with = java exception errors to try to figure out what went wrong"
  • OpenStack
    • TBD; I've haven't done much with it = yet; it's on my list
    • Also a big installation oriented project, = and obviously interesting in terms of the volume of industry support, etc
  • Proxmox
    • Not Xen based, but a really cool and interesti= ng project for smaller installations, worth mentioning to check it out
      • =
    • I haven't done quite enough experimenting with it yet, but it does = have some native clustering and HA support, although it requires a DRBD pri= mary/primary setup to work with it's built-in HA
  • Google Ganeti, which uses KVM and Xen
    • Next up on my li= st of things to play with when I get a chance
    Chee= rs,
    Andrew


    On Tue, Mar 12, 2013 at 10:29 AM, R. Jer= emy <sgrunt91@hotmail.com> wrote:
    Hi,

    I'm new in Xensource World= . I have to work on Xen 3.1.2 hypervisor, I've done some searches on ho= w to make Xen HA (not FT for the moment).
    The way that is come ag= ain and again is to make a cluster with Corosync, pacemaker, DRDB. I just w= ant to now if there are others way to do Xen HA, and which is the best way = in your opinion?
    I need something very stable and sustainable.

    I've seen many others mails of this subject, but we never know what is= the best way. And this is often for Xen 4.

    I'= m french, so I hope you'll understand my english...

    Thanks!

    BR

    _______________________________________________
    Xen-users mailing list
    Xen-users@list= s.xen.org
    http://lists.x= en.org/xen-users

    --14dae934123d9519bc04d888b079-- --===============4787319418910876022== 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 --===============4787319418910876022==-- From xen-users-bounces@lists.xen.org Fri Mar 22 19:46:15 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 22 Mar 2013 19:46: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 1UJ7tf-0008Mw-Gw; Fri, 22 Mar 2013 19:45:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJ7td-0008Mr-GB for xen-users@lists.xen.org; Fri, 22 Mar 2013 19:45:02 +0000 Received: from [85.158.139.83:24173] by server-9.bemta-5.messagelabs.com id F6/E7-08547-CB4BC415; Fri, 22 Mar 2013 19:45:00 +0000 X-Env-Sender: eross@corp.locatrix.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1363981497!23557559!1 X-Originating-IP: [209.85.223.179] X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1414 invoked from network); 22 Mar 2013 19:44:58 -0000 Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com) (209.85.223.179) by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 22 Mar 2013 19:44:58 -0000 Received: by mail-ie0-f179.google.com with SMTP id k11so5319430iea.10 for ; Fri, 22 Mar 2013 12:44:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=ZWJVruRTL1lHXq4TinEOOruWRgCF3OzwTRnVtuNk18k=; b=ICHETUcx8GlAjXpF8OkrdKEAY4Va1Yodi0LgPr5RefpUoZqTsC1+uT+WsFRObbPCWL L7WOPffowVj0h2VQWq7WrSE1g2gfWYqdMZxFlnTueGpk3xvXriUl9Q31p/RebWkC4xGI 0L0/D88+IQSKA8c92G0SH32w2LVvTUyjvjKS2cUmC9r+H6Y8hffnlU1+I2ZSXLgYCfCg lLObFk0zhLAId4nTDgpTEGh5cxen22FDc0Kw7Z9pI9b9xl1kXVofvYjCHBz3g5ok6I4L ERy8VWkTJiKShHddVxa2vVwPc36NB9KyGpTm9lQ/IQRTdzk4lerP41Cu5hZcgxUXL9Jm OEcQ== X-Received: by 10.50.203.72 with SMTP id ko8mr2021180igc.93.1363981496546; Fri, 22 Mar 2013 12:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.53.234 with HTTP; Fri, 22 Mar 2013 12:44:36 -0700 (PDT) In-Reply-To: References: From: Andrew Eross Date: Fri, 22 Mar 2013 15:44:36 -0400 Message-ID: To: "R. Jeremy" X-Gm-Message-State: ALoCoQnzj2xc2TX2OmnmE7nWh5yw4IvSX3RQwtzHYF0PpV4bnETSd64TtFP8j9wfrn+H6moRAFM/ Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Xen 3 High Availability ways X-BeenThere: xen-users@lists.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="===============4787319418910876022==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4787319418910876022== Content-Type: multipart/alternative; boundary=14dae934123d9519bc04d888b079 --14dae934123d9519bc04d888b079 Content-Type: text/plain; charset=ISO-8859-1 Hi, I've been working on this issue myself in my spare time for a while now, testing all the various systems and methods of creating a simple HA cluster (or at least machine pairs) using Xen or other virtualization methods with commodity hardware. It depends a lot on what type of hardware setup you're going to use.. and if you're looking for a "cluster" vs. something like 2-node HA. Myself, I've been mostly interested in simple 2-node setups using heterogeneous hardware, so I've not been much interested in using XenServer/XCP pools, which require very similar hardware. I also don't have SAN hardware, so I've preferred solutions that use the local server disks instead of shared storage. End of the day my number one goal has just been to find the best way to have a stable HA setup for database server VMs. Here's all the ways I've looked into, and my notes Please note, it's all just my own opinion here... - XCP HA - Does not support native HA from version 1.6 (I seem to recall it was working back in 1.1 or so, I think? - might've been disabled at some point by Citrix, which would be perfectly fair really since you should pay for the feature) - Does support pooling, but you need "identical" servers - Some support for differing CPU types, but still needs to be close - http://support.citrix.com/article/CTX127059 - VMs using local disk storage require a home server (where it starts from) - Pools support live migration even with local storage - Can move running VM from one machine to another fairly seamlessly - Note, again, as above, does not natively support HA - XenServer HA - $1500/server license for Advanced required for HA - Pretty much everything is the same as for XCP but also supports HA - You need shared storage for this (can be DRBD or an expensive SAN type device) - Also requires a shared heartbeat SR for HA (e.g. on a NAS or something) - If you can afford it, then certainly I do recommend this option, Citrix offers a generous trial period as well to give it a shot - XenServer with DRBD and Pacemaker - 2-node HA setup - It's possible to use DRBD with Primary/Primary to support live migration, but I don't trust it since I've had too many finicky issues, there's more split brain problems, etc, so I use Primary/Secondary - Linbit provides some docs about DRBD + XenServer if you google it - HA in this case means that Pacemaker automatically moves DRBD to Primary on the secondary node in case of failure, attaches the SR, and restarts the VMs.. this does not save the running machine state / memory state, and takes, say, maybe 45 seconds for the switch-over - This is what I actually have running in some production environments, and to me is the easy "that'll work and be reliable" answer - I wrote some Pacemaker plugins to help manage the VMs and the PBD/SR for automatic fail-over: https://github.com/locatrix/xs-pacemaker - The admin for this type of setup should be fairly DRBD and XenServer savvy in case of problems, but overall it does work, and DRBD is a rock - Xen with Remus - Works by using Xen's existing live migration system, so you have to do everything to get live migration working first, and then you can use Remus to automate fail-over - Has a number of guest and performance limitations; I wrote up some more information here on the updated page: http://wiki.xen.org/wiki/Remus - Once it's running it's really cool since it does literally allow a VM to fail-over to a secondary machine with practically no interruption, migrates memory, network connections, etc - However, to be honest, I've found from a practical perspective, that Remus isn't production ready, and is more interesting as an academic project - I had too many weird problems, crashes, guest incompatibilities, and theoretical performance problems, etc, to count on it - e.g. immediate killer for me is that Ubuntu guests basically don't work without some serious kernel hacking - CloudStack - Citrix CloudStack (now Apache CloudStack) is a mature java based solution for cloud management. It supports KVM, XenServer, and VMWare hosts in a unified cloud platform. - It's free - CS has a really nice web UI interface that is impressive at a first glance. - Respects HA built-in to XenServer, but basically doesn't add anything new there, so for simple HA purposes you don't really gain much by using CloudStack, just additional complexity with a nice UI - In general it's very much oriented towards bigger installations, and there are those who are successfully using it for large scale projects - My opinion for our smaller setup (we have 1 rack in a colo) is that it's overkill and I've had a lot of trouble getting it to work in a basic lab environment... I've often had the experience I've heard from many others about "getting stuck on a spinner and having to dig down through a bunch of obscure log files with java exception errors to try to figure out what went wrong" - OpenStack - TBD; I've haven't done much with it yet; it's on my list - Also a big installation oriented project, and obviously interesting in terms of the volume of industry support, etc - Proxmox - Not Xen based, but a really cool and interesting project for smaller installations, worth mentioning to check it out - I haven't done quite enough experimenting with it yet, but it does have some native clustering and HA support, although it requires a DRBD primary/primary setup to work with it's built-in HA - Google Ganeti, which uses KVM and Xen - Next up on my list of things to play with when I get a chance Cheers, Andrew On Tue, Mar 12, 2013 at 10:29 AM, R. Jeremy wrote: > Hi, > > I'm new in Xensource World. I have to work on Xen 3.1.2 hypervisor, I've > done some searches on how to make Xen HA (not FT for the moment). > The way that is come again and again is to make a cluster with Corosync, > pacemaker, DRDB. I just want to now if there are others way to do Xen HA, > and which is the best way in your opinion? > I need something very stable and sustainable. > > I've seen many others mails of this subject, but we never know what is the > best way. And this is often for Xen 4. > > I'm french, so I hope you'll understand my english... > > Thanks! > > BR > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --14dae934123d9519bc04d888b079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    I've been working on this issue myself in = my spare time for a while now, testing all the various systems and methods = of creating a simple HA cluster (or at least machine pairs) using Xen or ot= her virtualization methods with commodity hardware.

    It depends a lot on what type of hardware setup you're g= oing to use.. and if you're looking for a "cluster" vs. somet= hing like 2-node HA.

    Myself, I've been mostly = interested in simple 2-node setups using heterogeneous hardware, so I'v= e not been much interested in using XenServer/XCP pools, which require very= similar hardware. I also don't have SAN hardware, so I've preferre= d solutions that use the local server disks instead of shared storage.

    End of the day my number one goal has just been to find= the best way to have a stable HA setup for database server VMs.

    Here's all the ways I've looked into, and my notes

    Please note, it's all just my own opinion here.= ..
    • XCP HA
      • Does not support native HA from versio= n 1.6 (I seem to recall it was working back in 1.1 or so, I think? - might&= #39;ve been disabled at some point by Citrix, which would be perfectly fair= really since you should pay for the feature)
      • Does support pooling, but you need "identical" servers
      • Some support for differing CPU types, but still needs to be close
      • http://support.citrix.com/article/CTX127059
    • VMs using local disk storage require a home server (where it start= s from)
    • Pools support live migration even with local storage
      • Can move running VM from one machine to another fairly seamlessly
    • Note, again, as above, does not natively support HA
  • XenServer HA
    • $1500/server license for Advanced require= d for HA
    • Pretty much everything is the same as for XCP but also sup= ports HA
    • You need shared storage for this (can be DRBD or an expens= ive SAN type device)
    • Also requires a shared heartbeat SR for HA (e.g. on a NAS or something)=
    • If you can afford it, then certainly I do recommend this option, C= itrix offers a generous trial period as well to give it a shot
  • XenServer with DRBD and Pacemaker
    • 2-node HA setup
    • I= t's possible to use DRBD with Primary/Primary to support live migration= , but I don't trust it since I've had too many finicky issues, ther= e's more split brain problems, etc, so I use Primary/Secondary
    • Linbit provides some docs about DRBD + XenServer if you google it
      • <= li>HA in this case means that Pacemaker automatically moves DRBD to Primary= on the secondary node in case of failure, attaches the SR, and restarts th= e VMs.. this does not save the running machine state / memory state, and ta= kes, say, maybe 45 seconds for the switch-over
    • This is what I actually have running in some production environments, a= nd to me is the easy "that'll work and be reliable" answer
    • I wrote some Pacemaker plugins to help manage the VMs and the PBD/SR fo= r automatic fail-over:=A0https://github.com/locatrix/xs-pacemaker
    • T= he admin for this type of setup should be fairly DRBD and XenServer savvy i= n case of problems, but overall it does work, and DRBD is a rock
  • Xen with Remus
    • Works by using Xen's existing live = migration system, so you have to do everything to get live migration workin= g first, and then you can use Remus to automate fail-over
    • Has a number of guest and performance limitations; I wrote up some more= information here on the updated page: http://wiki.xen.org/wiki/Remus
    • Once it= 's running it's really cool since it does literally allow a VM to f= ail-over to a secondary machine with practically no interruption, migrates = memory, network connections, etc
    • However, to be honest, I've found from a practical perspective, tha= t Remus isn't production ready, and is more interesting as an academic = project
    • I had too many weird problems, crashes, guest incompatibili= ties, and theoretical performance problems, etc, to count on it
    • e.g. immediate killer for me is that Ubuntu guests basically don't = work without some serious kernel hacking
  • CloudStack
    • Citrix CloudStack (now Apache CloudStack) = is a mature java based solution for cloud management. It supports KVM, XenS= erver, and VMWare hosts in a unified cloud platform.
    • It's free
    • CS has a really nice web UI interface th= at is impressive at a first glance.
    • Respects HA built-in to XenServer, but = basically doesn't add anything new there, so for simple HA purposes you= don't really gain much by using CloudStack, just additional complexity= with a nice UI
    • In general it's very much oriented = towards bigger installations, and there are those who are successfully usin= g it for large scale projects
    • My opinion for our smaller setup (we ha= ve 1 rack in a colo) is that it's overkill and I've had a lot of tr= ouble getting it to work in a basic lab environment... I've often had t= he experience I've heard from many others about "getting stuck on = a spinner and having to dig down through a bunch of obscure log files with = java exception errors to try to figure out what went wrong"
  • OpenStack
    • TBD; I've haven't done much with it = yet; it's on my list
    • Also a big installation oriented project, = and obviously interesting in terms of the volume of industry support, etc
  • Proxmox
    • Not Xen based, but a really cool and interesti= ng project for smaller installations, worth mentioning to check it out
      • =
    • I haven't done quite enough experimenting with it yet, but it does = have some native clustering and HA support, although it requires a DRBD pri= mary/primary setup to work with it's built-in HA
  • Google Ganeti, which uses KVM and Xen
    • Next up on my li= st of things to play with when I get a chance
    Chee= rs,
    Andrew


    On Tue, Mar 12, 2013 at 10:29 AM, R. Jer= emy <sgrunt91@hotmail.com> wrote:
    Hi,

    I'm new in Xensource World= . I have to work on Xen 3.1.2 hypervisor, I've done some searches on ho= w to make Xen HA (not FT for the moment).
    The way that is come ag= ain and again is to make a cluster with Corosync, pacemaker, DRDB. I just w= ant to now if there are others way to do Xen HA, and which is the best way = in your opinion?
    I need something very stable and sustainable.

    I've seen many others mails of this subject, but we never know what is= the best way. And this is often for Xen 4.

    I'= m french, so I hope you'll understand my english...

    Thanks!

    BR

    _______________________________________________
    Xen-users mailing list
    Xen-users@list= s.xen.org
    http://lists.x= en.org/xen-users

    --14dae934123d9519bc04d888b079-- --===============4787319418910876022== 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 --===============4787319418910876022==-- From xen-users-bounces@lists.xen.org Sat Mar 23 01:19:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 23 Mar 2013 01:19: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 1UJD6D-0007U8-Ov; Sat, 23 Mar 2013 01:18:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJD6C-0007U3-RU for xen-users@lists.xen.org; Sat, 23 Mar 2013 01:18:20 +0000 Received: from [85.158.139.83:60654] by server-9.bemta-5.messagelabs.com id 99/A1-08547-CD20D415; Sat, 23 Mar 2013 01:18:20 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1364001497!20373090!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29803 invoked from network); 23 Mar 2013 01:18:19 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 23 Mar 2013 01:18:19 -0000 Date: Sat, 23 Mar 2013 01:18:16 +0000 From: Mike To: xen-users@lists.xen.org Message-ID: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> MIME-Version: 1.0 Content-Disposition: inline Subject: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586 Ideas how to move this forward? Debugging techniques? I'm guessing that it's specific to my hardware, since I'm not seeing anyone else complaining. Anyone else succeed in doing this on an EliteBook? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 23 01:19:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 23 Mar 2013 01:19: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 1UJD6D-0007U8-Ov; Sat, 23 Mar 2013 01:18:21 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJD6C-0007U3-RU for xen-users@lists.xen.org; Sat, 23 Mar 2013 01:18:20 +0000 Received: from [85.158.139.83:60654] by server-9.bemta-5.messagelabs.com id 99/A1-08547-CD20D415; Sat, 23 Mar 2013 01:18:20 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1364001497!20373090!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29803 invoked from network); 23 Mar 2013 01:18:19 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 23 Mar 2013 01:18:19 -0000 Date: Sat, 23 Mar 2013 01:18:16 +0000 From: Mike To: xen-users@lists.xen.org Message-ID: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> MIME-Version: 1.0 Content-Disposition: inline Subject: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586 Ideas how to move this forward? Debugging techniques? I'm guessing that it's specific to my hardware, since I'm not seeing anyone else complaining. Anyone else succeed in doing this on an EliteBook? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 23 12:22:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 23 Mar 2013 12:22: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 1UJNRr-0003DR-24; Sat, 23 Mar 2013 12:21:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIsCj-0004gv-CW for xen-users@lists.xensource.com; Fri, 22 Mar 2013 02:59:41 +0000 Received: from [193.109.254.147:59903] by server-12.bemta-14.messagelabs.com id D1/D6-05449-C19CB415; Fri, 22 Mar 2013 02:59:40 +0000 X-Env-Sender: liuhuan123123123@yahoo.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1363921171!3731202!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=2.5 required=7.0 tests=FORGED_YAHOO_RCVD, FROM_ENDS_IN_NUMS,ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16334 invoked from network); 22 Mar 2013 02:59:32 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 22 Mar 2013 02:59:32 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UIsCW-00052m-Rl for xen-users@lists.xensource.com; Thu, 21 Mar 2013 19:59:28 -0700 Date: Thu, 21 Mar 2013 19:59:28 -0700 (PDT) From: liuhuan To: xen-users@lists.xensource.com Message-ID: <1363921168848-5714948.post@n5.nabble.com> In-Reply-To: <1361600217703-5714393.post@n5.nabble.com> References: <1351069976947-5712103.post@n5.nabble.com> <1361600217703-5714393.post@n5.nabble.com> MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 23 Mar 2013 12:21:21 +0000 Subject: Re: [Xen-users] Xwindows or Freenx in a guest domain X-BeenThere: xen-users@lists.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 The basic abnormality you will again see amidst the archetypal cardy ugg boots and the beautification aerial boots is that the UGG archetypal Cardy comes with three abounding lath buttons down the side. http://fashionshop-online.net/goods-213-Ugg-Boots-Tall-Sheepskin-Cuff-Boot-3166-Black-Black-woman.html ugg boots in This not abandoned helps to advanced what is already a abounding analytic cossack but aswell helps you to be a little added aesthetic in the way that they are worn. -- View this message in context: http://xen.1045712.n5.nabble.com/Xwindows-or-Freenx-in-a-guest-domain-tp2556589p5714948.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 Sat Mar 23 12:22:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 23 Mar 2013 12:22: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 1UJNRr-0003DR-24; Sat, 23 Mar 2013 12:21:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UIsCj-0004gv-CW for xen-users@lists.xensource.com; Fri, 22 Mar 2013 02:59:41 +0000 Received: from [193.109.254.147:59903] by server-12.bemta-14.messagelabs.com id D1/D6-05449-C19CB415; Fri, 22 Mar 2013 02:59:40 +0000 X-Env-Sender: liuhuan123123123@yahoo.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1363921171!3731202!1 X-Originating-IP: [216.139.236.26] X-SpamReason: No, hits=2.5 required=7.0 tests=FORGED_YAHOO_RCVD, FROM_ENDS_IN_NUMS,ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16334 invoked from network); 22 Mar 2013 02:59:32 -0000 Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 22 Mar 2013 02:59:32 -0000 Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UIsCW-00052m-Rl for xen-users@lists.xensource.com; Thu, 21 Mar 2013 19:59:28 -0700 Date: Thu, 21 Mar 2013 19:59:28 -0700 (PDT) From: liuhuan To: xen-users@lists.xensource.com Message-ID: <1363921168848-5714948.post@n5.nabble.com> In-Reply-To: <1361600217703-5714393.post@n5.nabble.com> References: <1351069976947-5712103.post@n5.nabble.com> <1361600217703-5714393.post@n5.nabble.com> MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 23 Mar 2013 12:21:21 +0000 Subject: Re: [Xen-users] Xwindows or Freenx in a guest domain X-BeenThere: xen-users@lists.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 The basic abnormality you will again see amidst the archetypal cardy ugg boots and the beautification aerial boots is that the UGG archetypal Cardy comes with three abounding lath buttons down the side. http://fashionshop-online.net/goods-213-Ugg-Boots-Tall-Sheepskin-Cuff-Boot-3166-Black-Black-woman.html ugg boots in This not abandoned helps to advanced what is already a abounding analytic cossack but aswell helps you to be a little added aesthetic in the way that they are worn. -- View this message in context: http://xen.1045712.n5.nabble.com/Xwindows-or-Freenx-in-a-guest-domain-tp2556589p5714948.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 Sat Mar 23 20:16:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 23 Mar 2013 20:16: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 1UJUq7-0007B6-5d; Sat, 23 Mar 2013 20:14:55 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJUq6-0007B1-7q for xen-users@lists.xen.org; Sat, 23 Mar 2013 20:14:54 +0000 Received: from [85.158.137.99:24382] by server-4.bemta-3.messagelabs.com id C4/33-21470-D3D0E415; Sat, 23 Mar 2013 20:14:53 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1364069691!11693336!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30120 invoked from network); 23 Mar 2013 20:14:52 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 23 Mar 2013 20:14:52 -0000 X-IronPort-AV: E=Sophos;i="4.84,897,1355097600"; d="scan'208";a="14462383" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 23 Mar 2013 20:14:50 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.3; Sat, 23 Mar 2013 16:14:50 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UJUq1-0004hT-Sv; Sat, 23 Mar 2013 20:14:49 +0000 Message-ID: <1364069689.3919.2.camel@zion.uk.xensource.com> From: Wei Liu To: Mike Date: Sat, 23 Mar 2013 20:14:49 +0000 In-Reply-To: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> X-Mailer: Evolution 3.6.4 (3.6.4-2.fc18) MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , wei.liu2@citrix.com Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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, 2013-03-23 at 01:18 +0000, Mike wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586 > > Ideas how to move this forward? Debugging techniques? > You can probably set up serial console to get output from Xen. http://wiki.xen.org/wiki/Xen_Serial_Console Wei. > I'm guessing that it's specific to my hardware, since I'm not seeing > anyone else complaining. Anyone else succeed in doing this on an > EliteBook? > > _______________________________________________ > 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 Sat Mar 23 20:16:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 23 Mar 2013 20:16: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 1UJUq7-0007B6-5d; Sat, 23 Mar 2013 20:14:55 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJUq6-0007B1-7q for xen-users@lists.xen.org; Sat, 23 Mar 2013 20:14:54 +0000 Received: from [85.158.137.99:24382] by server-4.bemta-3.messagelabs.com id C4/33-21470-D3D0E415; Sat, 23 Mar 2013 20:14:53 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-8.tower-217.messagelabs.com!1364069691!11693336!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30120 invoked from network); 23 Mar 2013 20:14:52 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 23 Mar 2013 20:14:52 -0000 X-IronPort-AV: E=Sophos;i="4.84,897,1355097600"; d="scan'208";a="14462383" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 23 Mar 2013 20:14:50 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.3; Sat, 23 Mar 2013 16:14:50 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UJUq1-0004hT-Sv; Sat, 23 Mar 2013 20:14:49 +0000 Message-ID: <1364069689.3919.2.camel@zion.uk.xensource.com> From: Wei Liu To: Mike Date: Sat, 23 Mar 2013 20:14:49 +0000 In-Reply-To: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> X-Mailer: Evolution 3.6.4 (3.6.4-2.fc18) MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" , wei.liu2@citrix.com Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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, 2013-03-23 at 01:18 +0000, Mike wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586 > > Ideas how to move this forward? Debugging techniques? > You can probably set up serial console to get output from Xen. http://wiki.xen.org/wiki/Xen_Serial_Console Wei. > I'm guessing that it's specific to my hardware, since I'm not seeing > anyone else complaining. Anyone else succeed in doing this on an > EliteBook? > > _______________________________________________ > 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 Mar 25 04:35:09 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 04:35: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 1UJz6F-0002a4-KQ; Mon, 25 Mar 2013 04:33:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJz6D-0002Zz-7x for xen-users@lists.xen.org; Mon, 25 Mar 2013 04:33:33 +0000 Received: from [85.158.139.211:58825] by server-8.bemta-5.messagelabs.com id B6/BD-05790-C93DF415; Mon, 25 Mar 2013 04:33:32 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1364186010!19811798!1 X-Originating-IP: [209.85.210.176] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18354 invoked from network); 25 Mar 2013 04:33:32 -0000 Received: from mail-ia0-f176.google.com (HELO mail-ia0-f176.google.com) (209.85.210.176) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 04:33:32 -0000 Received: by mail-ia0-f176.google.com with SMTP id i1so5140742iaa.35 for ; Sun, 24 Mar 2013 21:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=VouzosOtfEbBpD+0k6H2hncEgQuACNGCqLFP6PwUw6s=; b=Y8pSOM0nRo/maZvuJ1g4if7F6lW7ijIbfBST5kSXDaPE/G4EmFf5a692kPr3OL5vNU MasKbclTTY3yO7pXppGx+Yke+n8fn3xYf06s07qRQgymxj7fkBPxzicaSFLlJUTKjExH UJPfe31szWNXvsT0P7ix22SMzqrvy+LyYnS3l+PNQWy0ztz0GQiZog1dGGSLR3kAxLXQ 6TDJ4oSauYrsYr1DRQK0s26DiOxpaHB2uxYjWj7IUi8wBACwMivRGM0FmERRKzY5lo+h perZTVg2RJwcyWoalZp68hs7D5nJkH87x+tqkFzK7rii1MT920Gi7O64j2EhyMC+4tXl k8ww== MIME-Version: 1.0 X-Received: by 10.50.202.6 with SMTP id ke6mr6929843igc.30.1364186010579; Sun, 24 Mar 2013 21:33:30 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Sun, 24 Mar 2013 21:33:30 -0700 (PDT) Date: Sun, 24 Mar 2013 22:33:30 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] xen tap 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="===============4268543086576370090==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4268543086576370090== Content-Type: multipart/alternative; boundary=f46d0447a291917a7404d8b84e4f --f46d0447a291917a7404d8b84e4f Content-Type: text/plain; charset=ISO-8859-1 I hope someone can point me in right direction. hvm uses tap devices to emulate network. Is there a way for openvswitch detect that it is starting under hvm and tap interface needs to be added ? Right know i have pvm working fine with openvswitch. --f46d0447a291917a7404d8b84e4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I hope someone can point me in right direction. hvm uses tap devices to emu= late network. Is there a way for openvswitch detect that it is starting und= er hvm=A0 and tap interface needs to be added ? Right know i have pvm worki= ng fine with openvswitch.
    --f46d0447a291917a7404d8b84e4f-- --===============4268543086576370090== 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 --===============4268543086576370090==-- From xen-users-bounces@lists.xen.org Mon Mar 25 04:35:09 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 04:35: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 1UJz6F-0002a4-KQ; Mon, 25 Mar 2013 04:33:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJz6D-0002Zz-7x for xen-users@lists.xen.org; Mon, 25 Mar 2013 04:33:33 +0000 Received: from [85.158.139.211:58825] by server-8.bemta-5.messagelabs.com id B6/BD-05790-C93DF415; Mon, 25 Mar 2013 04:33:32 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1364186010!19811798!1 X-Originating-IP: [209.85.210.176] X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18354 invoked from network); 25 Mar 2013 04:33:32 -0000 Received: from mail-ia0-f176.google.com (HELO mail-ia0-f176.google.com) (209.85.210.176) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 04:33:32 -0000 Received: by mail-ia0-f176.google.com with SMTP id i1so5140742iaa.35 for ; Sun, 24 Mar 2013 21:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=VouzosOtfEbBpD+0k6H2hncEgQuACNGCqLFP6PwUw6s=; b=Y8pSOM0nRo/maZvuJ1g4if7F6lW7ijIbfBST5kSXDaPE/G4EmFf5a692kPr3OL5vNU MasKbclTTY3yO7pXppGx+Yke+n8fn3xYf06s07qRQgymxj7fkBPxzicaSFLlJUTKjExH UJPfe31szWNXvsT0P7ix22SMzqrvy+LyYnS3l+PNQWy0ztz0GQiZog1dGGSLR3kAxLXQ 6TDJ4oSauYrsYr1DRQK0s26DiOxpaHB2uxYjWj7IUi8wBACwMivRGM0FmERRKzY5lo+h perZTVg2RJwcyWoalZp68hs7D5nJkH87x+tqkFzK7rii1MT920Gi7O64j2EhyMC+4tXl k8ww== MIME-Version: 1.0 X-Received: by 10.50.202.6 with SMTP id ke6mr6929843igc.30.1364186010579; Sun, 24 Mar 2013 21:33:30 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Sun, 24 Mar 2013 21:33:30 -0700 (PDT) Date: Sun, 24 Mar 2013 22:33:30 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] xen tap 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="===============4268543086576370090==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4268543086576370090== Content-Type: multipart/alternative; boundary=f46d0447a291917a7404d8b84e4f --f46d0447a291917a7404d8b84e4f Content-Type: text/plain; charset=ISO-8859-1 I hope someone can point me in right direction. hvm uses tap devices to emulate network. Is there a way for openvswitch detect that it is starting under hvm and tap interface needs to be added ? Right know i have pvm working fine with openvswitch. --f46d0447a291917a7404d8b84e4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I hope someone can point me in right direction. hvm uses tap devices to emu= late network. Is there a way for openvswitch detect that it is starting und= er hvm=A0 and tap interface needs to be added ? Right know i have pvm worki= ng fine with openvswitch.
    --f46d0447a291917a7404d8b84e4f-- --===============4268543086576370090== 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 --===============4268543086576370090==-- From xen-users-bounces@lists.xen.org Mon Mar 25 08:30:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 08:30:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK2m6-0005SP-Nl; Mon, 25 Mar 2013 08:29:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK2m5-0005SJ-62 for xen-users@lists.xen.org; Mon, 25 Mar 2013 08:29:01 +0000 Received: from [85.158.143.99:31718] by server-2.bemta-4.messagelabs.com id 50/FE-12656-CCA00515; Mon, 25 Mar 2013 08:29:00 +0000 X-Env-Sender: verybigbadboy@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1364200138!21809493!1 X-Originating-IP: [209.85.219.51] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14636 invoked from network); 25 Mar 2013 08:28:59 -0000 Received: from mail-oa0-f51.google.com (HELO mail-oa0-f51.google.com) (209.85.219.51) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 08:28:59 -0000 Received: by mail-oa0-f51.google.com with SMTP id g12so2762666oah.10 for ; Mon, 25 Mar 2013 01:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=FreLOPaaM/WUM/NIiI6Rgl2fCO8EAi6gBmKYIo4Loe0=; b=nS8v1AdhMS6dtZvVdJaBT3SbQ5VvcVZUv7hd2R/zy8kMDVHsZ3Tjx7x26IjzKIIZB6 /IBexMXV/88RR1n0yZ1ldHFy0ihCHjuxNp5amOZBzwcqmv3xamXM2CRy/RUozqcF2v9B EzelJrP9MEcKPz3/rdSmrQrGf5OnhgSj3bevjBSn2PUzWen94cgRi+icMHOXP72NHyxb /+0JGNTwl8Rf5cZIL2BDzCzrVpeE+pJ3cs1vIReiaCf3RtpB8JL9gAqDdYtO/35gm5cR 629ZL5jtsi8jAklP9/lw7wAlWlvd3lgxW29x/J276v2f2VFg5LX3XoIdlArXid9gdZVI drIA== MIME-Version: 1.0 X-Received: by 10.60.19.101 with SMTP id d5mr9960192oee.115.1364200137989; Mon, 25 Mar 2013 01:28:57 -0700 (PDT) Received: by 10.182.185.8 with HTTP; Mon, 25 Mar 2013 01:28:57 -0700 (PDT) Date: Mon, 25 Mar 2013 12:28:57 +0400 Message-ID: From: =?KOI8-R?B?4czFy9PBzsTSIPPJzsTJw8vJyg==?= To: xen-users@lists.xen.org Subject: [Xen-users] NVIDIA GeForce GTX 680 passthough success X-BeenThere: xen-users@lists.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="===============7822472224132635086==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7822472224132635086== Content-Type: multipart/alternative; boundary=e89a8fb1ff18a0a91604d8bb98a1 --e89a8fb1ff18a0a91604d8bb98a1 Content-Type: text/plain; charset=ISO-8859-1 Hello, I have success with passthough nvidia gtx 680 with hardware modification to nvidia grid k2 with using kvm, but i think it will works with xen too. This is is message about hardware modification http://www.eevblog.com/forum/projects/hacking-nvidia-cards-into-their-professional-counterparts/msg207550/#msg207550 Thank you. --e89a8fb1ff18a0a91604d8bb98a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

    I have success with passthough nvidia gtx 680 with hardware = modification to nvidia grid k2 with using kvm, but i think it will works wi= th xen too.

    This is is message about hardware modification http://www.eevblog.com/forum= /projects/hacking-nvidia-cards-into-their-professional-counterparts/msg2075= 50/#msg207550

    Thank you.
    --e89a8fb1ff18a0a91604d8bb98a1-- --===============7822472224132635086== 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 --===============7822472224132635086==-- From xen-users-bounces@lists.xen.org Mon Mar 25 08:30:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 08:30:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK2m6-0005SP-Nl; Mon, 25 Mar 2013 08:29:02 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK2m5-0005SJ-62 for xen-users@lists.xen.org; Mon, 25 Mar 2013 08:29:01 +0000 Received: from [85.158.143.99:31718] by server-2.bemta-4.messagelabs.com id 50/FE-12656-CCA00515; Mon, 25 Mar 2013 08:29:00 +0000 X-Env-Sender: verybigbadboy@gmail.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1364200138!21809493!1 X-Originating-IP: [209.85.219.51] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14636 invoked from network); 25 Mar 2013 08:28:59 -0000 Received: from mail-oa0-f51.google.com (HELO mail-oa0-f51.google.com) (209.85.219.51) by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 08:28:59 -0000 Received: by mail-oa0-f51.google.com with SMTP id g12so2762666oah.10 for ; Mon, 25 Mar 2013 01:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=FreLOPaaM/WUM/NIiI6Rgl2fCO8EAi6gBmKYIo4Loe0=; b=nS8v1AdhMS6dtZvVdJaBT3SbQ5VvcVZUv7hd2R/zy8kMDVHsZ3Tjx7x26IjzKIIZB6 /IBexMXV/88RR1n0yZ1ldHFy0ihCHjuxNp5amOZBzwcqmv3xamXM2CRy/RUozqcF2v9B EzelJrP9MEcKPz3/rdSmrQrGf5OnhgSj3bevjBSn2PUzWen94cgRi+icMHOXP72NHyxb /+0JGNTwl8Rf5cZIL2BDzCzrVpeE+pJ3cs1vIReiaCf3RtpB8JL9gAqDdYtO/35gm5cR 629ZL5jtsi8jAklP9/lw7wAlWlvd3lgxW29x/J276v2f2VFg5LX3XoIdlArXid9gdZVI drIA== MIME-Version: 1.0 X-Received: by 10.60.19.101 with SMTP id d5mr9960192oee.115.1364200137989; Mon, 25 Mar 2013 01:28:57 -0700 (PDT) Received: by 10.182.185.8 with HTTP; Mon, 25 Mar 2013 01:28:57 -0700 (PDT) Date: Mon, 25 Mar 2013 12:28:57 +0400 Message-ID: From: =?KOI8-R?B?4czFy9PBzsTSIPPJzsTJw8vJyg==?= To: xen-users@lists.xen.org Subject: [Xen-users] NVIDIA GeForce GTX 680 passthough success X-BeenThere: xen-users@lists.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="===============7822472224132635086==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7822472224132635086== Content-Type: multipart/alternative; boundary=e89a8fb1ff18a0a91604d8bb98a1 --e89a8fb1ff18a0a91604d8bb98a1 Content-Type: text/plain; charset=ISO-8859-1 Hello, I have success with passthough nvidia gtx 680 with hardware modification to nvidia grid k2 with using kvm, but i think it will works with xen too. This is is message about hardware modification http://www.eevblog.com/forum/projects/hacking-nvidia-cards-into-their-professional-counterparts/msg207550/#msg207550 Thank you. --e89a8fb1ff18a0a91604d8bb98a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

    I have success with passthough nvidia gtx 680 with hardware = modification to nvidia grid k2 with using kvm, but i think it will works wi= th xen too.

    This is is message about hardware modification http://www.eevblog.com/forum= /projects/hacking-nvidia-cards-into-their-professional-counterparts/msg2075= 50/#msg207550

    Thank you.
    --e89a8fb1ff18a0a91604d8bb98a1-- --===============7822472224132635086== 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 --===============7822472224132635086==-- From xen-users-bounces@lists.xen.org Mon Mar 25 09:31:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 09:31: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 1UK3jr-0006kg-HK; Mon, 25 Mar 2013 09:30:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK3jp-0006k5-2v; Mon, 25 Mar 2013 09:30:45 +0000 Received: from [85.158.143.99:9109] by server-2.bemta-4.messagelabs.com id 62/3F-12656-44910515; Mon, 25 Mar 2013 09:30:44 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1364203837!18571164!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22688 invoked from network); 25 Mar 2013 09:30:39 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 09:30:39 -0000 X-IronPort-AV: E=Sophos;i="4.84,904,1355097600"; d="scan'208";a="14586701" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 25 Mar 2013 09:30:36 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.3; Mon, 25 Mar 2013 05:30:36 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UK3jf-00015d-Qm; Mon, 25 Mar 2013 09:30:35 +0000 Date: Mon, 25 Mar 2013 09:30:35 +0000 From: Wei Liu To: , , , Message-ID: <20130325093035.GA13815@zion.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: wei.liu2@citrix.com Subject: [Xen-users] Xen Document Day is on 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Good morning everybody, A quick reminder that the Xen Document Day is on today! Please see: - http://wiki.xen.org/wiki/Xen_Document_Days - http://wiki.xen.org/wiki/Xen_Document_Days/TODO See you on IRC #xendocs @ freenode ! Wei. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 25 09:31:59 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 09:31: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 1UK3jr-0006kg-HK; Mon, 25 Mar 2013 09:30:47 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK3jp-0006k5-2v; Mon, 25 Mar 2013 09:30:45 +0000 Received: from [85.158.143.99:9109] by server-2.bemta-4.messagelabs.com id 62/3F-12656-44910515; Mon, 25 Mar 2013 09:30:44 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1364203837!18571164!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22688 invoked from network); 25 Mar 2013 09:30:39 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 09:30:39 -0000 X-IronPort-AV: E=Sophos;i="4.84,904,1355097600"; d="scan'208";a="14586701" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/AES128-SHA; 25 Mar 2013 09:30:36 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.3; Mon, 25 Mar 2013 05:30:36 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UK3jf-00015d-Qm; Mon, 25 Mar 2013 09:30:35 +0000 Date: Mon, 25 Mar 2013 09:30:35 +0000 From: Wei Liu To: , , , Message-ID: <20130325093035.GA13815@zion.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: wei.liu2@citrix.com Subject: [Xen-users] Xen Document Day is on 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Good morning everybody, A quick reminder that the Xen Document Day is on today! Please see: - http://wiki.xen.org/wiki/Xen_Document_Days - http://wiki.xen.org/wiki/Xen_Document_Days/TODO See you on IRC #xendocs @ freenode ! Wei. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 25 10:17:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 10:17: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 1UK4S8-0008L4-9z; Mon, 25 Mar 2013 10:16:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK4S7-0008Kz-GL for xen-users@lists.xen.org; Mon, 25 Mar 2013 10:16:31 +0000 Received: from [85.158.139.211:29704] by server-11.bemta-5.messagelabs.com id 5D/B9-27486-EF320515; Mon, 25 Mar 2013 10:16:30 +0000 X-Env-Sender: matthew.pideil@teledetection.fr X-Msg-Ref: server-7.tower-206.messagelabs.com!1364206589!17570082!1 X-Originating-IP: [193.48.189.9] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11492 invoked from network); 25 Mar 2013 10:16:29 -0000 Received: from komper2.teledetection.fr (HELO komper.teledetection.fr) (193.48.189.9) by server-7.tower-206.messagelabs.com with SMTP; 25 Mar 2013 10:16:29 -0000 Received: from [193.48.189.109] (unknown [193.48.189.109]) by komper.teledetection.fr (Serveur mel de la MTD) with ESMTPSA id 33162264AD66 for ; Mon, 25 Mar 2013 11:16:28 +0100 (CET) Message-ID: <515023FC.9010208@teledetection.fr> Date: Mon, 25 Mar 2013 11:16:28 +0100 From: matthew pideil User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <514C27FE.1060600@teledetection.fr> In-Reply-To: <514C27FE.1060600@teledetection.fr> Subject: Re: [Xen-users] 3D Accell issue with Wheezy PVHVM DomU (VGA Passthrough) on Xen 4.1 X-BeenThere: xen-users@lists.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="===============5828508834994012459==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5828508834994012459== Content-Type: multipart/alternative; boundary="------------070200030009030309040305" This is a multi-part message in MIME format. --------------070200030009030309040305 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 22/03/2013 10:44, matthew pideil a écrit : > Hello, > > I run wheezy dom0 on "xen-hypervisor-4.1-amd64". > I have successfully set up a pvhvm wheezy domu (vga passthrough) on > wheezy hypervisor with hd4000 igd. > All seems working perfect since gnome-session starts (gdm3) after > logging in, gnome-shell no render anything (only cursor and background). > In 'GNOME Classic' mode, which works like a charm, i run "glxinfo" > without any problems and "glxgears" which show a dark window (no > gears) whithout any errors. > > Do you also have this issue ? > > Sincerely, > --- > Matt Ok, sorry i solve my problem by reinstalling my dom0. Now it works perfectly with the use of pcistub module. Regards, --- Matt --------------070200030009030309040305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Le 22/03/2013 10:44, matthew pideil a écrit :
    Hello,

    I run wheezy dom0 on "xen-hypervisor-4.1-amd64".
    I have successfully set up a pvhvm wheezy domu (vga passthrough) on wheezy hypervisor with hd4000 igd.
    All seems working perfect since gnome-session starts (gdm3) after logging in, gnome-shell no render anything (only cursor and background).
    In 'GNOME Classic' mode, which works like a charm, i run "glxinfo" without any problems and "glxgears" which show a dark window (no gears) whithout any errors.

    Do you also have this issue ?

    Sincerely,
    ---
    Matt
    Ok, sorry i solve my problem by reinstalling my dom0. Now it works perfectly with the use of pcistub module.

     Regards,
    ---
    Matt
    --------------070200030009030309040305-- --===============5828508834994012459== 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 --===============5828508834994012459==-- From xen-users-bounces@lists.xen.org Mon Mar 25 10:17:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 10:17: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 1UK4S8-0008L4-9z; Mon, 25 Mar 2013 10:16:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK4S7-0008Kz-GL for xen-users@lists.xen.org; Mon, 25 Mar 2013 10:16:31 +0000 Received: from [85.158.139.211:29704] by server-11.bemta-5.messagelabs.com id 5D/B9-27486-EF320515; Mon, 25 Mar 2013 10:16:30 +0000 X-Env-Sender: matthew.pideil@teledetection.fr X-Msg-Ref: server-7.tower-206.messagelabs.com!1364206589!17570082!1 X-Originating-IP: [193.48.189.9] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11492 invoked from network); 25 Mar 2013 10:16:29 -0000 Received: from komper2.teledetection.fr (HELO komper.teledetection.fr) (193.48.189.9) by server-7.tower-206.messagelabs.com with SMTP; 25 Mar 2013 10:16:29 -0000 Received: from [193.48.189.109] (unknown [193.48.189.109]) by komper.teledetection.fr (Serveur mel de la MTD) with ESMTPSA id 33162264AD66 for ; Mon, 25 Mar 2013 11:16:28 +0100 (CET) Message-ID: <515023FC.9010208@teledetection.fr> Date: Mon, 25 Mar 2013 11:16:28 +0100 From: matthew pideil User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121215 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <514C27FE.1060600@teledetection.fr> In-Reply-To: <514C27FE.1060600@teledetection.fr> Subject: Re: [Xen-users] 3D Accell issue with Wheezy PVHVM DomU (VGA Passthrough) on Xen 4.1 X-BeenThere: xen-users@lists.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="===============5828508834994012459==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============5828508834994012459== Content-Type: multipart/alternative; boundary="------------070200030009030309040305" This is a multi-part message in MIME format. --------------070200030009030309040305 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 22/03/2013 10:44, matthew pideil a écrit : > Hello, > > I run wheezy dom0 on "xen-hypervisor-4.1-amd64". > I have successfully set up a pvhvm wheezy domu (vga passthrough) on > wheezy hypervisor with hd4000 igd. > All seems working perfect since gnome-session starts (gdm3) after > logging in, gnome-shell no render anything (only cursor and background). > In 'GNOME Classic' mode, which works like a charm, i run "glxinfo" > without any problems and "glxgears" which show a dark window (no > gears) whithout any errors. > > Do you also have this issue ? > > Sincerely, > --- > Matt Ok, sorry i solve my problem by reinstalling my dom0. Now it works perfectly with the use of pcistub module. Regards, --- Matt --------------070200030009030309040305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Le 22/03/2013 10:44, matthew pideil a écrit :
    Hello,

    I run wheezy dom0 on "xen-hypervisor-4.1-amd64".
    I have successfully set up a pvhvm wheezy domu (vga passthrough) on wheezy hypervisor with hd4000 igd.
    All seems working perfect since gnome-session starts (gdm3) after logging in, gnome-shell no render anything (only cursor and background).
    In 'GNOME Classic' mode, which works like a charm, i run "glxinfo" without any problems and "glxgears" which show a dark window (no gears) whithout any errors.

    Do you also have this issue ?

    Sincerely,
    ---
    Matt
    Ok, sorry i solve my problem by reinstalling my dom0. Now it works perfectly with the use of pcistub module.

     Regards,
    ---
    Matt
    --------------070200030009030309040305-- --===============5828508834994012459== 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 --===============5828508834994012459==-- From xen-users-bounces@lists.xen.org Mon Mar 25 10:57:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 10:57: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 1UK55H-0000iP-6A; Mon, 25 Mar 2013 10:56:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJnnl-0003W7-Qu for xen-users@lists.xen.org; Sun, 24 Mar 2013 16:29:45 +0000 Received: from [85.158.143.99:30413] by server-1.bemta-4.messagelabs.com id E9/37-06203-9F92F415; Sun, 24 Mar 2013 16:29:45 +0000 X-Env-Sender: hallcarrjames@hotmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1364142581!21353506!1 X-Originating-IP: [65.55.111.91] X-SpamReason: No, hits=0.7 required=7.0 tests=FORGED_HOTMAIL_RCVD, HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31541 invoked from network); 24 Mar 2013 16:29:42 -0000 Received: from blu0-omc2-s16.blu0.hotmail.com (HELO blu0-omc2-s16.blu0.hotmail.com) (65.55.111.91) by server-6.tower-216.messagelabs.com with SMTP; 24 Mar 2013 16:29:42 -0000 Received: from BLU152-W23 ([65.55.111.71]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Mar 2013 09:29:41 -0700 X-EIP: [pDqO7TwjzVRbuV8RJQCqqBiVZ2yigFeG] X-Originating-Email: [hallcarrjames@hotmail.com] Message-ID: From: Jim Hall To: "xen-users@lists.xen.org" Date: Sun, 24 Mar 2013 11:29:41 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Mar 2013 16:29:41.0670 (UTC) FILETIME=[C9474460:01CE28AC] X-Mailman-Approved-At: Mon, 25 Mar 2013 10:56:58 +0000 Subject: [Xen-users] Cannot Get Windows 12 To Install X-BeenThere: xen-users@lists.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="===============1062123039778218594==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1062123039778218594== Content-Type: multipart/alternative; boundary="_df8ab347-935a-4dd0-a529-38c78ad0d384_" --_df8ab347-935a-4dd0-a529-38c78ad0d384_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had my Windows 12 working fine and decided to start all over. I insert = the cd and start the install I get an error about unable to find device dri= vers. I have tried a few templates with the same results. I dont think I g= ot this last time. I need to get this re-installed today = --_df8ab347-935a-4dd0-a529-38c78ad0d384_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    I had my Windows 12 working fine= and decided to start all over.  =3B I insert the cd and start the inst= all I get an error about unable to find device drivers.  =3BI have trie= d a few templates with the same results. I dont think I got this last time.=  =3B I need to get this re-installed today
    = --_df8ab347-935a-4dd0-a529-38c78ad0d384_-- --===============1062123039778218594== 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 --===============1062123039778218594==-- From xen-users-bounces@lists.xen.org Mon Mar 25 10:57:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 10:57: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 1UK55H-0000iP-6A; Mon, 25 Mar 2013 10:56:59 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJnnl-0003W7-Qu for xen-users@lists.xen.org; Sun, 24 Mar 2013 16:29:45 +0000 Received: from [85.158.143.99:30413] by server-1.bemta-4.messagelabs.com id E9/37-06203-9F92F415; Sun, 24 Mar 2013 16:29:45 +0000 X-Env-Sender: hallcarrjames@hotmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1364142581!21353506!1 X-Originating-IP: [65.55.111.91] X-SpamReason: No, hits=0.7 required=7.0 tests=FORGED_HOTMAIL_RCVD, HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31541 invoked from network); 24 Mar 2013 16:29:42 -0000 Received: from blu0-omc2-s16.blu0.hotmail.com (HELO blu0-omc2-s16.blu0.hotmail.com) (65.55.111.91) by server-6.tower-216.messagelabs.com with SMTP; 24 Mar 2013 16:29:42 -0000 Received: from BLU152-W23 ([65.55.111.71]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Mar 2013 09:29:41 -0700 X-EIP: [pDqO7TwjzVRbuV8RJQCqqBiVZ2yigFeG] X-Originating-Email: [hallcarrjames@hotmail.com] Message-ID: From: Jim Hall To: "xen-users@lists.xen.org" Date: Sun, 24 Mar 2013 11:29:41 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Mar 2013 16:29:41.0670 (UTC) FILETIME=[C9474460:01CE28AC] X-Mailman-Approved-At: Mon, 25 Mar 2013 10:56:58 +0000 Subject: [Xen-users] Cannot Get Windows 12 To Install X-BeenThere: xen-users@lists.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="===============1062123039778218594==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1062123039778218594== Content-Type: multipart/alternative; boundary="_df8ab347-935a-4dd0-a529-38c78ad0d384_" --_df8ab347-935a-4dd0-a529-38c78ad0d384_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I had my Windows 12 working fine and decided to start all over. I insert = the cd and start the install I get an error about unable to find device dri= vers. I have tried a few templates with the same results. I dont think I g= ot this last time. I need to get this re-installed today = --_df8ab347-935a-4dd0-a529-38c78ad0d384_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    I had my Windows 12 working fine= and decided to start all over.  =3B I insert the cd and start the inst= all I get an error about unable to find device drivers.  =3BI have trie= d a few templates with the same results. I dont think I got this last time.=  =3B I need to get this re-installed today
    = --_df8ab347-935a-4dd0-a529-38c78ad0d384_-- --===============1062123039778218594== 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 --===============1062123039778218594==-- From xen-users-bounces@lists.xen.org Mon Mar 25 11:00:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 11:00: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 1UK57T-0000rv-0G; Mon, 25 Mar 2013 10:59:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJzcY-00038q-2O for xen-users@lists.xen.org; Mon, 25 Mar 2013 05:06:58 +0000 Received: from [85.158.143.99:9912] by server-2.bemta-4.messagelabs.com id 2F/2C-12656-17BDF415; Mon, 25 Mar 2013 05:06:57 +0000 X-Env-Sender: linuxhack2012@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1364188015!25111240!1 X-Originating-IP: [209.85.216.172] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4107 invoked from network); 25 Mar 2013 05:06:56 -0000 Received: from mail-qc0-f172.google.com (HELO mail-qc0-f172.google.com) (209.85.216.172) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 05:06:56 -0000 Received: by mail-qc0-f172.google.com with SMTP id b25so2571903qca.31 for ; Sun, 24 Mar 2013 22:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=TA9k1xsFi7VqOkKB2dj6ixNTJDlP+T8jlC72+Wa/6Uc=; b=qUt09sp1MPtFqmoCwocwO4GXWNsisJd7pTumX8WTuA95hal+bZnfrMa5XyFjqbDv8k qTjTNRwp4v64SOEr9BdER4hOWa08k6SuXFTrnAJ4Hyy5TtNeZNME2YMVNxvwJpxUmle9 4PxCUIBDjHewzYmEpjbflZDsCq0I1SfneD+LxcCH1UYEHt6PPsAEue+sYXqfCAfZvObi Qenw93qc8WJEfTJbUJeDnLbXcDeNOCGePkn3X9/5Fk+jHHDY7XXMy0YhOCsKJCF4hM2s dzLW75AeM5WlHGleMou92Y8d0QWJuQRDqxHTq+v0VdTvyNsg04NsH6WDaRnp3r4DJgcc xACQ== MIME-Version: 1.0 X-Received: by 10.229.197.193 with SMTP id el1mr1514186qcb.86.1364188015369; Sun, 24 Mar 2013 22:06:55 -0700 (PDT) Received: by 10.49.98.234 with HTTP; Sun, 24 Mar 2013 22:06:55 -0700 (PDT) Date: Mon, 25 Mar 2013 10:36:55 +0530 Message-ID: From: Linux Hack To: "xen-users@lists.xen.org" X-Mailman-Approved-At: Mon, 25 Mar 2013 10:59:13 +0000 Subject: [Xen-users] IO-APIC issue X-BeenThere: xen-users@lists.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="===============7368201490345757828==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7368201490345757828== Content-Type: multipart/alternative; boundary=001a11c2bf261027db04d8b8c6ce --001a11c2bf261027db04d8b8c6ce Content-Type: text/plain; charset=ISO-8859-1 Hi, I have installed Xen-4.1.4 on existing server where the VM's are running. After I have installed this Xen version the Xen HVM VM's with Ubuntu are not booting well and its throwing the below error message while booting up, IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the "noapic" option If I boot with noapic then its booting fine. May I know what could be causing the issue to refuse boot as normal? Also does the VM will get any issues if we boot with noapic? --001a11c2bf261027db04d8b8c6ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    I have installed Xen-4.1.4 on= existing server where the VM's are running. After I have installed thi= s Xen version the Xen HVM VM's with Ubuntu are not booting well and its= throwing the below error message while booting up,

    IO-APIC + timer doesn't work! Boot= with apic=3Ddebug and send a report.
    Then try booting with the &= quot;noapic" option

    If I boot with noap= ic then its booting fine. May I know what could be causing the issue to ref= use boot as normal? Also does the VM will get any issues if we boot with no= apic?


    --001a11c2bf261027db04d8b8c6ce-- --===============7368201490345757828== 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 --===============7368201490345757828==-- From xen-users-bounces@lists.xen.org Mon Mar 25 11:00:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 11:00: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 1UK57T-0000rv-0G; Mon, 25 Mar 2013 10:59:15 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UJzcY-00038q-2O for xen-users@lists.xen.org; Mon, 25 Mar 2013 05:06:58 +0000 Received: from [85.158.143.99:9912] by server-2.bemta-4.messagelabs.com id 2F/2C-12656-17BDF415; Mon, 25 Mar 2013 05:06:57 +0000 X-Env-Sender: linuxhack2012@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1364188015!25111240!1 X-Originating-IP: [209.85.216.172] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4107 invoked from network); 25 Mar 2013 05:06:56 -0000 Received: from mail-qc0-f172.google.com (HELO mail-qc0-f172.google.com) (209.85.216.172) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 05:06:56 -0000 Received: by mail-qc0-f172.google.com with SMTP id b25so2571903qca.31 for ; Sun, 24 Mar 2013 22:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=TA9k1xsFi7VqOkKB2dj6ixNTJDlP+T8jlC72+Wa/6Uc=; b=qUt09sp1MPtFqmoCwocwO4GXWNsisJd7pTumX8WTuA95hal+bZnfrMa5XyFjqbDv8k qTjTNRwp4v64SOEr9BdER4hOWa08k6SuXFTrnAJ4Hyy5TtNeZNME2YMVNxvwJpxUmle9 4PxCUIBDjHewzYmEpjbflZDsCq0I1SfneD+LxcCH1UYEHt6PPsAEue+sYXqfCAfZvObi Qenw93qc8WJEfTJbUJeDnLbXcDeNOCGePkn3X9/5Fk+jHHDY7XXMy0YhOCsKJCF4hM2s dzLW75AeM5WlHGleMou92Y8d0QWJuQRDqxHTq+v0VdTvyNsg04NsH6WDaRnp3r4DJgcc xACQ== MIME-Version: 1.0 X-Received: by 10.229.197.193 with SMTP id el1mr1514186qcb.86.1364188015369; Sun, 24 Mar 2013 22:06:55 -0700 (PDT) Received: by 10.49.98.234 with HTTP; Sun, 24 Mar 2013 22:06:55 -0700 (PDT) Date: Mon, 25 Mar 2013 10:36:55 +0530 Message-ID: From: Linux Hack To: "xen-users@lists.xen.org" X-Mailman-Approved-At: Mon, 25 Mar 2013 10:59:13 +0000 Subject: [Xen-users] IO-APIC issue X-BeenThere: xen-users@lists.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="===============7368201490345757828==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7368201490345757828== Content-Type: multipart/alternative; boundary=001a11c2bf261027db04d8b8c6ce --001a11c2bf261027db04d8b8c6ce Content-Type: text/plain; charset=ISO-8859-1 Hi, I have installed Xen-4.1.4 on existing server where the VM's are running. After I have installed this Xen version the Xen HVM VM's with Ubuntu are not booting well and its throwing the below error message while booting up, IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the "noapic" option If I boot with noapic then its booting fine. May I know what could be causing the issue to refuse boot as normal? Also does the VM will get any issues if we boot with noapic? --001a11c2bf261027db04d8b8c6ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    I have installed Xen-4.1.4 on= existing server where the VM's are running. After I have installed thi= s Xen version the Xen HVM VM's with Ubuntu are not booting well and its= throwing the below error message while booting up,

    IO-APIC + timer doesn't work! Boot= with apic=3Ddebug and send a report.
    Then try booting with the &= quot;noapic" option

    If I boot with noap= ic then its booting fine. May I know what could be causing the issue to ref= use boot as normal? Also does the VM will get any issues if we boot with no= apic?


    --001a11c2bf261027db04d8b8c6ce-- --===============7368201490345757828== 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 --===============7368201490345757828==-- From xen-users-bounces@lists.xen.org Mon Mar 25 14:32:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 14:32: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 1UK8Qh-0000Ww-4a; Mon, 25 Mar 2013 14:31:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK8Qf-0000Wd-L6; Mon, 25 Mar 2013 14:31:17 +0000 Received: from [85.158.139.211:42749] by server-3.bemta-5.messagelabs.com id 33/0C-17256-4BF50515; Mon, 25 Mar 2013 14:31:16 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1364221874!19619717!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14166 invoked from network); 25 Mar 2013 14:31:15 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Mar 2013 14:31:15 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2PEVAQO009849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Mar 2013 14:31:11 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2PEVAsf002375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2013 14:31:10 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2PEV9u2008975; Mon, 25 Mar 2013 09:31:09 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Mar 2013 07:31:09 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 9C0411C3D2D; Mon, 25 Mar 2013 10:31:08 -0400 (EDT) Date: Mon, 25 Mar 2013 10:31:08 -0400 From: Konrad Rzeszutek Wilk To: Ian Jackson Message-ID: <20130325143108.GA14681@phenom.dumpdata.com> References: <20121022135023.GU8912@reaktio.net> <20762.25864.314580.353107@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20762.25864.314580.353107@mariner.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-users@lists.xen.org" , "Fan, Huaxiang" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] e820_host problems X-BeenThere: xen-users@lists.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, Feb 12, 2013 at 03:51:36PM +0000, Ian Jackson wrote: > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] e820_host problems"): > > On Wed, Oct 24, 2012 at 06:02:11AM +0000, Fan, Huaxiang wrote: > > > Hi Pasi, > > > > > > Thanks for your reply. I've tried the latest table kernel 3.6.3. The situation is better, but still not perfect. > > > When I assign 6144M to domu wcg ,the output of 'xl list' only indicates 5110M allocated for domu wcg. > > > When I logon domu wcg, the totol memory is *limited within 3G*. I suspect the e820-map was wrong. > > > > It looks like there is a bug in the libxl when assembling the e820 map. > > This would be in e820_sanitize in libxl_x86.c I guess ? > Konrad, are you looking into a fix ? Hey Ian, That is the right place. It is on my TODO list. > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 25 14:32:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 14:32: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 1UK8Qh-0000Ww-4a; Mon, 25 Mar 2013 14:31:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UK8Qf-0000Wd-L6; Mon, 25 Mar 2013 14:31:17 +0000 Received: from [85.158.139.211:42749] by server-3.bemta-5.messagelabs.com id 33/0C-17256-4BF50515; Mon, 25 Mar 2013 14:31:16 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1364221874!19619717!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14166 invoked from network); 25 Mar 2013 14:31:15 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Mar 2013 14:31:15 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2PEVAQO009849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Mar 2013 14:31:11 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2PEVAsf002375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2013 14:31:10 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2PEV9u2008975; Mon, 25 Mar 2013 09:31:09 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Mar 2013 07:31:09 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 9C0411C3D2D; Mon, 25 Mar 2013 10:31:08 -0400 (EDT) Date: Mon, 25 Mar 2013 10:31:08 -0400 From: Konrad Rzeszutek Wilk To: Ian Jackson Message-ID: <20130325143108.GA14681@phenom.dumpdata.com> References: <20121022135023.GU8912@reaktio.net> <20762.25864.314580.353107@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20762.25864.314580.353107@mariner.uk.xensource.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-users@lists.xen.org" , "Fan, Huaxiang" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] e820_host problems X-BeenThere: xen-users@lists.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, Feb 12, 2013 at 03:51:36PM +0000, Ian Jackson wrote: > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] e820_host problems"): > > On Wed, Oct 24, 2012 at 06:02:11AM +0000, Fan, Huaxiang wrote: > > > Hi Pasi, > > > > > > Thanks for your reply. I've tried the latest table kernel 3.6.3. The situation is better, but still not perfect. > > > When I assign 6144M to domu wcg ,the output of 'xl list' only indicates 5110M allocated for domu wcg. > > > When I logon domu wcg, the totol memory is *limited within 3G*. I suspect the e820-map was wrong. > > > > It looks like there is a bug in the libxl when assembling the e820 map. > > This would be in e820_sanitize in libxl_x86.c I guess ? > Konrad, are you looking into a fix ? Hey Ian, That is the right place. It is on my TODO list. > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 25 16:20:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 16:20: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 1UKA7D-0002UA-Pg; Mon, 25 Mar 2013 16:19:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKA7C-0002Tv-JI for xen-users@lists.xen.org; Mon, 25 Mar 2013 16:19:18 +0000 Received: from [193.109.254.147:63659] by server-1.bemta-14.messagelabs.com id 28/6F-22449-50970515; Mon, 25 Mar 2013 16:19:17 +0000 X-Env-Sender: thore@datensumpf.de X-Msg-Ref: server-16.tower-27.messagelabs.com!1364228357!8384150!1 X-Originating-IP: [212.12.52.213] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 371 invoked from network); 25 Mar 2013 16:19:17 -0000 Received: from mail-2.ramdrive.org (HELO mail-2.ramdrive.org) (212.12.52.213) by server-16.tower-27.messagelabs.com with SMTP; 25 Mar 2013 16:19:17 -0000 Received: from localhost (localhost [127.0.0.1]) by mail-2.ramdrive.org (Postfix) with ESMTP id DD80F7801F08 for ; Mon, 25 Mar 2013 16:33:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail-2.ramdrive.org Received: from mail-2.ramdrive.org ([127.0.0.1]) by localhost (mail-2.ramdrive.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-Sqz2RJaQWY for ; Mon, 25 Mar 2013 16:33:37 +0000 (UTC) Received: from [127.0.0.1] (p4FCD5EE5.dip.t-dialin.net [79.205.94.229]) by mail-2.ramdrive.org (Postfix) with ESMTPSA id 754C17801F02 for ; Mon, 25 Mar 2013 16:33:37 +0000 (UTC) Message-ID: <51507903.7020209@datensumpf.de> Date: Mon, 25 Mar 2013 17:19:15 +0100 From: Thore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "xen-users@lists.xen.org" Subject: [Xen-users] How to migrate image files in lvm X-BeenThere: xen-users@lists.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 have problem with my xen installation on my wheezy server. I haven't really an idea hown to. So I'm using xen image files. Now one VPS reached the limit of free space and killed more or less itself. I needet some hours to find out. Now my Idea to solve is to migrate the files in an lvm version. I never used it before, but I have no problem to configure. Now I ask how to migrate the files and how to install it in a lvm partition. Anyone here who could help? Regards Thore _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 25 16:20:24 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 16:20: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 1UKA7D-0002UA-Pg; Mon, 25 Mar 2013 16:19:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKA7C-0002Tv-JI for xen-users@lists.xen.org; Mon, 25 Mar 2013 16:19:18 +0000 Received: from [193.109.254.147:63659] by server-1.bemta-14.messagelabs.com id 28/6F-22449-50970515; Mon, 25 Mar 2013 16:19:17 +0000 X-Env-Sender: thore@datensumpf.de X-Msg-Ref: server-16.tower-27.messagelabs.com!1364228357!8384150!1 X-Originating-IP: [212.12.52.213] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 371 invoked from network); 25 Mar 2013 16:19:17 -0000 Received: from mail-2.ramdrive.org (HELO mail-2.ramdrive.org) (212.12.52.213) by server-16.tower-27.messagelabs.com with SMTP; 25 Mar 2013 16:19:17 -0000 Received: from localhost (localhost [127.0.0.1]) by mail-2.ramdrive.org (Postfix) with ESMTP id DD80F7801F08 for ; Mon, 25 Mar 2013 16:33:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail-2.ramdrive.org Received: from mail-2.ramdrive.org ([127.0.0.1]) by localhost (mail-2.ramdrive.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-Sqz2RJaQWY for ; Mon, 25 Mar 2013 16:33:37 +0000 (UTC) Received: from [127.0.0.1] (p4FCD5EE5.dip.t-dialin.net [79.205.94.229]) by mail-2.ramdrive.org (Postfix) with ESMTPSA id 754C17801F02 for ; Mon, 25 Mar 2013 16:33:37 +0000 (UTC) Message-ID: <51507903.7020209@datensumpf.de> Date: Mon, 25 Mar 2013 17:19:15 +0100 From: Thore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "xen-users@lists.xen.org" Subject: [Xen-users] How to migrate image files in lvm X-BeenThere: xen-users@lists.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 have problem with my xen installation on my wheezy server. I haven't really an idea hown to. So I'm using xen image files. Now one VPS reached the limit of free space and killed more or less itself. I needet some hours to find out. Now my Idea to solve is to migrate the files in an lvm version. I never used it before, but I have no problem to configure. Now I ask how to migrate the files and how to install it in a lvm partition. Anyone here who could help? Regards Thore _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Mar 25 17:12:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 17:12: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 1UKAvy-0005ae-EW; Mon, 25 Mar 2013 17:11:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKAvw-0005aX-Pd for xen-users@lists.xen.org; Mon, 25 Mar 2013 17:11:45 +0000 Received: from [85.158.138.51:28550] by server-16.bemta-3.messagelabs.com id 8F/0B-20692-F4580515; Mon, 25 Mar 2013 17:11:43 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1364231476!23945289!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13341 invoked from network); 25 Mar 2013 17:11:16 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 17:11:16 -0000 Received: by mail-wg0-f48.google.com with SMTP id 16so3424543wgi.27 for ; Mon, 25 Mar 2013 10:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=i0DsDc/dqBUiwfoS6hHuFTk0LdZ0bigJiGMQGiukhYw=; b=fPQAYSAyQZllWyGykB6Aau88c4v5bn4tDd4fV0kfqAtR2hB2cfqRbLEWeWfC3AkCR0 XWI6QntB8amxorm6ryb3i11qHMXJehZJNDt0qv9MLQTMqx4Cu2o+4FivuEDpHKD/oBlv mJIR3T90WLtChE9koc+A+yPxJFoEZChm0PxAsODlZhGwHYr9t1YZOYC3MCzaJGc+ikQ8 JT1xuVxmG0RkVLJE3Tg7gku5BUwbRtzne2n+i/0B6JZHYQdepIuh0hUi7vSTq9jQmWrm /JUW5sigyqi78LpRFvSm1p5as5nt67nGPHVpHrG4f0SMe7NkRZ/rl9O9Ek1c4Idz+v56 4Hkg== MIME-Version: 1.0 X-Received: by 10.194.21.233 with SMTP id y9mr19526813wje.47.1364231124699; Mon, 25 Mar 2013 10:05:24 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Mon, 25 Mar 2013 10:05:24 -0700 (PDT) Date: Mon, 25 Mar 2013 18:05:24 +0100 Message-ID: From: Fabrice Delente To: "xen-users@lists.xen.org" Subject: [Xen-users] Domain not restarting + ssh connection to Xen server delay on restarting a domain? X-BeenThere: xen-users@lists.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="===============3640346365501075637==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3640346365501075637== Content-Type: multipart/alternative; boundary=047d7b5d2774945a4404d8c2cff9 --047d7b5d2774945a4404d8c2cff9 Content-Type: text/plain; charset=UTF-8 Hello. I don't know if these two problems are connected, however this is what I observe: I have a Windows XP guest that was stuck on shutting down (Windows must have had to reboot after an update, but it got stuck). I shut down the domain with 'xm destroy', but now I can't restart it. I manage my domains by ssh-ing into the Xen server. When I use 'xm create domain.cfg', I can't type anything anymore in the ssh; after a while (about 1 minute), I can use the console again, but the domain I restarted isn't started. Any hint? Thanks. -- F. Delente --047d7b5d2774945a4404d8c2cff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello.

    I don= 9;t know if these two problems are connected, however this is what I observ= e:

    I have a Windows XP guest that was stuck on shutting down (= Windows must have had to reboot after an update, but it got stuck).

    I shut down the domain with 'xm destroy', but now I can&#= 39;t restart it.

    I manage my domains by ssh-ing into the Xen server.= When I use 'xm create domain.cfg', I can't type anything anymo= re in the ssh; after a while (about 1 minute), I can use the console again,= but the domain I restarted isn't started.

    Any hint?

    Thanks.

    --
    F. Delente
    =
    --047d7b5d2774945a4404d8c2cff9-- --===============3640346365501075637== 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 --===============3640346365501075637==-- From xen-users-bounces@lists.xen.org Mon Mar 25 17:12:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 17:12: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 1UKAvy-0005ae-EW; Mon, 25 Mar 2013 17:11:46 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKAvw-0005aX-Pd for xen-users@lists.xen.org; Mon, 25 Mar 2013 17:11:45 +0000 Received: from [85.158.138.51:28550] by server-16.bemta-3.messagelabs.com id 8F/0B-20692-F4580515; Mon, 25 Mar 2013 17:11:43 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1364231476!23945289!1 X-Originating-IP: [74.125.82.48] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13341 invoked from network); 25 Mar 2013 17:11:16 -0000 Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 17:11:16 -0000 Received: by mail-wg0-f48.google.com with SMTP id 16so3424543wgi.27 for ; Mon, 25 Mar 2013 10:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=i0DsDc/dqBUiwfoS6hHuFTk0LdZ0bigJiGMQGiukhYw=; b=fPQAYSAyQZllWyGykB6Aau88c4v5bn4tDd4fV0kfqAtR2hB2cfqRbLEWeWfC3AkCR0 XWI6QntB8amxorm6ryb3i11qHMXJehZJNDt0qv9MLQTMqx4Cu2o+4FivuEDpHKD/oBlv mJIR3T90WLtChE9koc+A+yPxJFoEZChm0PxAsODlZhGwHYr9t1YZOYC3MCzaJGc+ikQ8 JT1xuVxmG0RkVLJE3Tg7gku5BUwbRtzne2n+i/0B6JZHYQdepIuh0hUi7vSTq9jQmWrm /JUW5sigyqi78LpRFvSm1p5as5nt67nGPHVpHrG4f0SMe7NkRZ/rl9O9Ek1c4Idz+v56 4Hkg== MIME-Version: 1.0 X-Received: by 10.194.21.233 with SMTP id y9mr19526813wje.47.1364231124699; Mon, 25 Mar 2013 10:05:24 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Mon, 25 Mar 2013 10:05:24 -0700 (PDT) Date: Mon, 25 Mar 2013 18:05:24 +0100 Message-ID: From: Fabrice Delente To: "xen-users@lists.xen.org" Subject: [Xen-users] Domain not restarting + ssh connection to Xen server delay on restarting a domain? X-BeenThere: xen-users@lists.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="===============3640346365501075637==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3640346365501075637== Content-Type: multipart/alternative; boundary=047d7b5d2774945a4404d8c2cff9 --047d7b5d2774945a4404d8c2cff9 Content-Type: text/plain; charset=UTF-8 Hello. I don't know if these two problems are connected, however this is what I observe: I have a Windows XP guest that was stuck on shutting down (Windows must have had to reboot after an update, but it got stuck). I shut down the domain with 'xm destroy', but now I can't restart it. I manage my domains by ssh-ing into the Xen server. When I use 'xm create domain.cfg', I can't type anything anymore in the ssh; after a while (about 1 minute), I can use the console again, but the domain I restarted isn't started. Any hint? Thanks. -- F. Delente --047d7b5d2774945a4404d8c2cff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello.

    I don= 9;t know if these two problems are connected, however this is what I observ= e:

    I have a Windows XP guest that was stuck on shutting down (= Windows must have had to reboot after an update, but it got stuck).

    I shut down the domain with 'xm destroy', but now I can&#= 39;t restart it.

    I manage my domains by ssh-ing into the Xen server.= When I use 'xm create domain.cfg', I can't type anything anymo= re in the ssh; after a while (about 1 minute), I can use the console again,= but the domain I restarted isn't started.

    Any hint?

    Thanks.

    --
    F. Delente
    =
    --047d7b5d2774945a4404d8c2cff9-- --===============3640346365501075637== 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 --===============3640346365501075637==-- From xen-users-bounces@lists.xen.org Mon Mar 25 18:26:46 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 18:26: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 1UKC5R-0006WU-Sf; Mon, 25 Mar 2013 18:25:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKC5Q-0006WP-A2 for xen-users@lists.xen.org; Mon, 25 Mar 2013 18:25:36 +0000 Received: from [85.158.139.211:18449] by server-7.bemta-5.messagelabs.com id BA/7E-12441-F9690515; Mon, 25 Mar 2013 18:25:35 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1364235932!19041174!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16127 invoked from network); 25 Mar 2013 18:25:34 -0000 Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 18:25:34 -0000 X-IronPort-AV: E=Sophos;i="4.84,905,1355097600"; d="scan'208";a="15436445" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 25 Mar 2013 18:24:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.3; Mon, 25 Mar 2013 14:24:26 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UKBvX-0000py-UF; Mon, 25 Mar 2013 18:15:23 +0000 Date: Mon, 25 Mar 2013 18:15:23 +0000 From: Wei Liu To: Thore Message-ID: <20130325181523.GA3825@zion.uk.xensource.com> References: <51507903.7020209@datensumpf.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51507903.7020209@datensumpf.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] How to migrate image files in lvm X-BeenThere: xen-users@lists.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, Mar 25, 2013 at 04:19:15PM +0000, Thore wrote: > Hello, > I have problem with my xen installation on my wheezy server. > I haven't really an idea hown to. > So I'm using xen image files. > Now one VPS reached the limit of free space and killed more or less itself. > I needet some hours to find out. > Now my Idea to solve is to migrate the files in an lvm version. > I never used it before, but I have no problem to configure. > Now I ask how to migrate the files and how to install it in a lvm partition. > Anyone here who could help? > If it is a raw file, dd alone should do the job, if it is in some format like QCOW, you should need tools to export it as a block device then dd. Free advice: always backup your image before doing anything to it. :-) Wei. > Regards > Thore > > > _______________________________________________ > 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 Mar 25 18:26:46 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 18:26: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 1UKC5R-0006WU-Sf; Mon, 25 Mar 2013 18:25:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKC5Q-0006WP-A2 for xen-users@lists.xen.org; Mon, 25 Mar 2013 18:25:36 +0000 Received: from [85.158.139.211:18449] by server-7.bemta-5.messagelabs.com id BA/7E-12441-F9690515; Mon, 25 Mar 2013 18:25:35 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1364235932!19041174!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16127 invoked from network); 25 Mar 2013 18:25:34 -0000 Received: from unknown (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 25 Mar 2013 18:25:34 -0000 X-IronPort-AV: E=Sophos;i="4.84,905,1355097600"; d="scan'208";a="15436445" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 25 Mar 2013 18:24:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.3; Mon, 25 Mar 2013 14:24:26 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UKBvX-0000py-UF; Mon, 25 Mar 2013 18:15:23 +0000 Date: Mon, 25 Mar 2013 18:15:23 +0000 From: Wei Liu To: Thore Message-ID: <20130325181523.GA3825@zion.uk.xensource.com> References: <51507903.7020209@datensumpf.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51507903.7020209@datensumpf.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] How to migrate image files in lvm X-BeenThere: xen-users@lists.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, Mar 25, 2013 at 04:19:15PM +0000, Thore wrote: > Hello, > I have problem with my xen installation on my wheezy server. > I haven't really an idea hown to. > So I'm using xen image files. > Now one VPS reached the limit of free space and killed more or less itself. > I needet some hours to find out. > Now my Idea to solve is to migrate the files in an lvm version. > I never used it before, but I have no problem to configure. > Now I ask how to migrate the files and how to install it in a lvm partition. > Anyone here who could help? > If it is a raw file, dd alone should do the job, if it is in some format like QCOW, you should need tools to export it as a block device then dd. Free advice: always backup your image before doing anything to it. :-) Wei. > Regards > Thore > > > _______________________________________________ > 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 Mar 25 19:15:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 19:15:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKCqa-0007uw-6H; Mon, 25 Mar 2013 19:14:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKCqZ-0007ui-5M for xen-users@lists.xen.org; Mon, 25 Mar 2013 19:14:19 +0000 Received: from [85.158.139.211:48546] by server-2.bemta-5.messagelabs.com id E4/7F-23989-A02A0515; Mon, 25 Mar 2013 19:14:18 +0000 X-Env-Sender: jpp@jppozzi.dyndns.org X-Msg-Ref: server-3.tower-206.messagelabs.com!1364238857!18199609!1 X-Originating-IP: [194.158.122.58] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk0LjE1OC4xMjIuNTggPT4gODQzNzU=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2445 invoked from network); 25 Mar 2013 19:14:17 -0000 Received: from mail-3d.bbox.fr (HELO mail-3d.bbox.fr) (194.158.122.58) by server-3.tower-206.messagelabs.com with SMTP; 25 Mar 2013 19:14:17 -0000 Received: from kmail.jpp.fr (89-93-163-242.hfc.dyn.abo.bbox.fr [89.93.163.242]) by mail-3d.bbox.fr (Postfix) with ESMTP id 66DB85D; Mon, 25 Mar 2013 20:14:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by kmail.jpp.fr (Postfix) with ESMTP id 1B7D11C006B; Mon, 25 Mar 2013 20:14:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jppozzi.dyndns.org Received: from kmail.jpp.fr ([127.0.0.1]) by localhost (kmail.jpp.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pl9kze9yCZD; Mon, 25 Mar 2013 20:14:16 +0100 (CET) Received: from [192.168.2.8] (k2000.jpp.fr [192.168.2.8]) by kmail.jpp.fr (Postfix) with ESMTPSA id 893AF1C0066; Mon, 25 Mar 2013 20:14:16 +0100 (CET) Message-ID: <1364238856.7855.5.camel@k2000.jpp.fr> From: "jpp@jppozzi.dyndns.org" To: Thore Date: Mon, 25 Mar 2013 20:14:16 +0100 In-Reply-To: <51507903.7020209@datensumpf.de> References: <51507903.7020209@datensumpf.de> X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] How to migrate image files in lvm X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: jp.pozzi@izzop.net 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 TGUgbHVuZGkgMjUgbWFycyAyMDEzIMOgIDE3OjE5ICswMTAwLCBUaG9yZSBhIMOpY3JpdCA6Cj4g SGVsbG8sCj4gSSBoYXZlIHByb2JsZW0gd2l0aCBteSB4ZW4gaW5zdGFsbGF0aW9uIG9uIG15IHdo ZWV6eSBzZXJ2ZXIuCj4gSSBoYXZlbid0IHJlYWxseSBhbiBpZGVhIGhvd24gdG8uCj4gU28gSSdt IHVzaW5nIHhlbiBpbWFnZSBmaWxlcy4KPiBOb3cgb25lIFZQUyByZWFjaGVkIHRoZSBsaW1pdCBv ZiBmcmVlIHNwYWNlIGFuZCBraWxsZWQgbW9yZSBvciBsZXNzIGl0c2VsZi4KPiBJIG5lZWRldCBz b21lIGhvdXJzIHRvIGZpbmQgb3V0Lgo+IE5vdyBteSBJZGVhIHRvIHNvbHZlIGlzIHRvIG1pZ3Jh dGUgdGhlIGZpbGVzIGluIGFuIGx2bSB2ZXJzaW9uLgo+IEkgbmV2ZXIgdXNlZCBpdCBiZWZvcmUs IGJ1dCBJIGhhdmUgbm8gcHJvYmxlbSB0byBjb25maWd1cmUuCj4gTm93IEkgYXNrIGhvdyB0byBt aWdyYXRlIHRoZSBmaWxlcyBhbmQgaG93IHRvIGluc3RhbGwgaXQgaW4gYSBsdm0gcGFydGl0aW9u Lgo+IEFueW9uZSBoZXJlIHdobyBjb3VsZCBoZWxwPwo+IAo+IFJlZ2FyZHMKPiBUaG9yZQoKSGVs bG8sCgpUaGUgcHJvY2VzcyB0byBjb3B5IHlvdXIgaW1hZ2UgdG8gYSBMVk0gcGFydGl0aW9uIGlz IG5vdCB0b28KY29tcGxpY2F0ZWQgOgoKSWYgeW91ciBpbWFnZSBpcyBpbiAicmF3IiBmb3JtYXQg Z28gdG8gU3RlcCAyLgoKU3RlcCAxIDogY29udmVydCBpbWFnZSBpbiAicmF3IiBmb3JtYXQuCgpx ZW11LWltZyBjb252ZXJ0IC1mIHZtZGsgb3JpZ2luYWxfaW1hZ2Uudm1kayAtTyByYXcgeGVuX2Nv bXBhdGlibGUuaW1nCgpWTURLIG9yIGFub3RoZXIgZm9ybWF0IGxpa2UgUUNPVywgUUNPVzIgLi4u CgoKU3RlcCAyIDogY3JlYXRlIHlvdXIgTFZNIHBhcnRpdGlvbgpNYWtlIGl0IGJpZ2dlciB0aGFu ICJ4ZW5fY29tcGF0aWJsZS5pbWciICEKClN0ZXAgMyA6IGNvcHkgdGhlIGRhdGEKImRkIiBpcyB5 b3VyIGZyaWVuZAoKZGQgaWY9eGVuX2NvbXBhdGlibGUuaW1nIG9mPS9kZXYveW91cl9sdm1fcGFy dGl0aW9uIGJzPTMyawoKU3RlcCA0IDogcmVzaXplIHRoZSBGUwoKTW91bnQgdGhlIHBhcnRpdGlv biBvbiBhbm90aGVyIG1hY2hpbmUgKGNvdWxkIGJlIGFub3RoZXIgVk0pIGFuZAoicmVzaXplIiB0 aGUgZmlsZXN5c3RlbSB0byAiZmlsbCIgdGhlIExWTSBwYXJ0aXRpb24uIChJdCBpcyBub3QgcG9z c2libGUKdG8gZG8gYSAibGl2ZSIgZmlsZXN5c3RlbSByZXNpemUgKS4KClN0ZXAgNSA6IGFsbCBz aG91bGQgYmUgT0sKbGluayB0aGUgbmV3IGZpbGVzeXN0ZW0gdG8geW91ciBWTSBpbnN0ZWFkIG9m IHRoZSAib2xkIiBpbWFnZSBmaWxlIGFuZAp0cnkgdG8gc3RhcnQgeW91ciBWTQoKVGhlIHByb2Nl c3MgaXMgc2FmZSBhcyB5b3VyIG9yaWdpbmFsIGltYWdlIGlzIG5vdCBkZXN0cm95ZWQsIHlvdSBj YW4Kd2FpdCBhIGxpdHRsZSBiZWZvcmUgc2NyYXRjaGluZyBpdC4KClBTOgpJIG5ldmVyIHVzZSBp bWFnZSBmaWxlcywgTFZNIGlzIGVhc2llciB0byBhZGFwdCB0byB0aGUgbmVlZHMuCgoKUmVnYXJk cwoKSlAgUAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Clhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp c3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Mon Mar 25 19:15:14 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 19:15:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKCqa-0007uw-6H; Mon, 25 Mar 2013 19:14:20 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKCqZ-0007ui-5M for xen-users@lists.xen.org; Mon, 25 Mar 2013 19:14:19 +0000 Received: from [85.158.139.211:48546] by server-2.bemta-5.messagelabs.com id E4/7F-23989-A02A0515; Mon, 25 Mar 2013 19:14:18 +0000 X-Env-Sender: jpp@jppozzi.dyndns.org X-Msg-Ref: server-3.tower-206.messagelabs.com!1364238857!18199609!1 X-Originating-IP: [194.158.122.58] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk0LjE1OC4xMjIuNTggPT4gODQzNzU=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2445 invoked from network); 25 Mar 2013 19:14:17 -0000 Received: from mail-3d.bbox.fr (HELO mail-3d.bbox.fr) (194.158.122.58) by server-3.tower-206.messagelabs.com with SMTP; 25 Mar 2013 19:14:17 -0000 Received: from kmail.jpp.fr (89-93-163-242.hfc.dyn.abo.bbox.fr [89.93.163.242]) by mail-3d.bbox.fr (Postfix) with ESMTP id 66DB85D; Mon, 25 Mar 2013 20:14:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by kmail.jpp.fr (Postfix) with ESMTP id 1B7D11C006B; Mon, 25 Mar 2013 20:14:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jppozzi.dyndns.org Received: from kmail.jpp.fr ([127.0.0.1]) by localhost (kmail.jpp.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pl9kze9yCZD; Mon, 25 Mar 2013 20:14:16 +0100 (CET) Received: from [192.168.2.8] (k2000.jpp.fr [192.168.2.8]) by kmail.jpp.fr (Postfix) with ESMTPSA id 893AF1C0066; Mon, 25 Mar 2013 20:14:16 +0100 (CET) Message-ID: <1364238856.7855.5.camel@k2000.jpp.fr> From: "jpp@jppozzi.dyndns.org" To: Thore Date: Mon, 25 Mar 2013 20:14:16 +0100 In-Reply-To: <51507903.7020209@datensumpf.de> References: <51507903.7020209@datensumpf.de> X-Mailer: Evolution 3.4.4-2 Mime-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] How to migrate image files in lvm X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: jp.pozzi@izzop.net 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 TGUgbHVuZGkgMjUgbWFycyAyMDEzIMOgIDE3OjE5ICswMTAwLCBUaG9yZSBhIMOpY3JpdCA6Cj4g SGVsbG8sCj4gSSBoYXZlIHByb2JsZW0gd2l0aCBteSB4ZW4gaW5zdGFsbGF0aW9uIG9uIG15IHdo ZWV6eSBzZXJ2ZXIuCj4gSSBoYXZlbid0IHJlYWxseSBhbiBpZGVhIGhvd24gdG8uCj4gU28gSSdt IHVzaW5nIHhlbiBpbWFnZSBmaWxlcy4KPiBOb3cgb25lIFZQUyByZWFjaGVkIHRoZSBsaW1pdCBv ZiBmcmVlIHNwYWNlIGFuZCBraWxsZWQgbW9yZSBvciBsZXNzIGl0c2VsZi4KPiBJIG5lZWRldCBz b21lIGhvdXJzIHRvIGZpbmQgb3V0Lgo+IE5vdyBteSBJZGVhIHRvIHNvbHZlIGlzIHRvIG1pZ3Jh dGUgdGhlIGZpbGVzIGluIGFuIGx2bSB2ZXJzaW9uLgo+IEkgbmV2ZXIgdXNlZCBpdCBiZWZvcmUs IGJ1dCBJIGhhdmUgbm8gcHJvYmxlbSB0byBjb25maWd1cmUuCj4gTm93IEkgYXNrIGhvdyB0byBt aWdyYXRlIHRoZSBmaWxlcyBhbmQgaG93IHRvIGluc3RhbGwgaXQgaW4gYSBsdm0gcGFydGl0aW9u Lgo+IEFueW9uZSBoZXJlIHdobyBjb3VsZCBoZWxwPwo+IAo+IFJlZ2FyZHMKPiBUaG9yZQoKSGVs bG8sCgpUaGUgcHJvY2VzcyB0byBjb3B5IHlvdXIgaW1hZ2UgdG8gYSBMVk0gcGFydGl0aW9uIGlz IG5vdCB0b28KY29tcGxpY2F0ZWQgOgoKSWYgeW91ciBpbWFnZSBpcyBpbiAicmF3IiBmb3JtYXQg Z28gdG8gU3RlcCAyLgoKU3RlcCAxIDogY29udmVydCBpbWFnZSBpbiAicmF3IiBmb3JtYXQuCgpx ZW11LWltZyBjb252ZXJ0IC1mIHZtZGsgb3JpZ2luYWxfaW1hZ2Uudm1kayAtTyByYXcgeGVuX2Nv bXBhdGlibGUuaW1nCgpWTURLIG9yIGFub3RoZXIgZm9ybWF0IGxpa2UgUUNPVywgUUNPVzIgLi4u CgoKU3RlcCAyIDogY3JlYXRlIHlvdXIgTFZNIHBhcnRpdGlvbgpNYWtlIGl0IGJpZ2dlciB0aGFu ICJ4ZW5fY29tcGF0aWJsZS5pbWciICEKClN0ZXAgMyA6IGNvcHkgdGhlIGRhdGEKImRkIiBpcyB5 b3VyIGZyaWVuZAoKZGQgaWY9eGVuX2NvbXBhdGlibGUuaW1nIG9mPS9kZXYveW91cl9sdm1fcGFy dGl0aW9uIGJzPTMyawoKU3RlcCA0IDogcmVzaXplIHRoZSBGUwoKTW91bnQgdGhlIHBhcnRpdGlv biBvbiBhbm90aGVyIG1hY2hpbmUgKGNvdWxkIGJlIGFub3RoZXIgVk0pIGFuZAoicmVzaXplIiB0 aGUgZmlsZXN5c3RlbSB0byAiZmlsbCIgdGhlIExWTSBwYXJ0aXRpb24uIChJdCBpcyBub3QgcG9z c2libGUKdG8gZG8gYSAibGl2ZSIgZmlsZXN5c3RlbSByZXNpemUgKS4KClN0ZXAgNSA6IGFsbCBz aG91bGQgYmUgT0sKbGluayB0aGUgbmV3IGZpbGVzeXN0ZW0gdG8geW91ciBWTSBpbnN0ZWFkIG9m IHRoZSAib2xkIiBpbWFnZSBmaWxlIGFuZAp0cnkgdG8gc3RhcnQgeW91ciBWTQoKVGhlIHByb2Nl c3MgaXMgc2FmZSBhcyB5b3VyIG9yaWdpbmFsIGltYWdlIGlzIG5vdCBkZXN0cm95ZWQsIHlvdSBj YW4Kd2FpdCBhIGxpdHRsZSBiZWZvcmUgc2NyYXRjaGluZyBpdC4KClBTOgpJIG5ldmVyIHVzZSBp bWFnZSBmaWxlcywgTFZNIGlzIGVhc2llciB0byBhZGFwdCB0byB0aGUgbmVlZHMuCgoKUmVnYXJk cwoKSlAgUAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Clhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp c3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Mon Mar 25 19:32:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 19: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 1UKD7V-0008L6-Fy; Mon, 25 Mar 2013 19:31:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKD7U-0008Kz-OL for xen-users@lists.xen.org; Mon, 25 Mar 2013 19:31:48 +0000 Received: from [85.158.139.83:23251] by server-6.bemta-5.messagelabs.com id 63/C4-21466-326A0515; Mon, 25 Mar 2013 19:31:47 +0000 X-Env-Sender: thore@datensumpf.de X-Msg-Ref: server-16.tower-182.messagelabs.com!1364239907!20715320!1 X-Originating-IP: [212.12.52.213] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30902 invoked from network); 25 Mar 2013 19:31:47 -0000 Received: from mail-2.ramdrive.org (HELO mail-2.ramdrive.org) (212.12.52.213) by server-16.tower-182.messagelabs.com with SMTP; 25 Mar 2013 19:31:47 -0000 Received: from localhost (localhost [127.0.0.1]) by mail-2.ramdrive.org (Postfix) with ESMTP id B7D297801F08 for ; Mon, 25 Mar 2013 19:46:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail-2.ramdrive.org Received: from mail-2.ramdrive.org ([127.0.0.1]) by localhost (mail-2.ramdrive.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXS2hnkZkba9 for ; Mon, 25 Mar 2013 19:46:06 +0000 (UTC) Received: from [127.0.0.1] (p4FCD5EE5.dip.t-dialin.net [79.205.94.229]) by mail-2.ramdrive.org (Postfix) with ESMTPSA id 9ED1C7801F02 for ; Mon, 25 Mar 2013 19:46:06 +0000 (UTC) Message-ID: <5150A621.5070408@datensumpf.de> Date: Mon, 25 Mar 2013 20:31:45 +0100 From: Thore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <51507903.7020209@datensumpf.de> <1364238856.7855.5.camel@k2000.jpp.fr> In-Reply-To: <1364238856.7855.5.camel@k2000.jpp.fr> Subject: Re: [Xen-users] How to migrate image files in lvm X-BeenThere: xen-users@lists.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 CkFtIDI1LjAzLjIwMTMgMjA6MTQsIHNjaHJpZWIganBwQGpwcG96emkuZHluZG5zLm9yZzoKPiBM ZSBsdW5kaSAyNSBtYXJzIDIwMTMgw6AgMTc6MTkgKzAxMDAsIFRob3JlIGEgw6ljcml0IDoKPj4g SGVsbG8sCj4+IEkgaGF2ZSBwcm9ibGVtIHdpdGggbXkgeGVuIGluc3RhbGxhdGlvbiBvbiBteSB3 aGVlenkgc2VydmVyLgo+PiBJIGhhdmVuJ3QgcmVhbGx5IGFuIGlkZWEgaG93biB0by4KPj4gU28g SSdtIHVzaW5nIHhlbiBpbWFnZSBmaWxlcy4KPj4gTm93IG9uZSBWUFMgcmVhY2hlZCB0aGUgbGlt aXQgb2YgZnJlZSBzcGFjZSBhbmQga2lsbGVkIG1vcmUgb3IgbGVzcyBpdHNlbGYuCj4+IEkgbmVl ZGV0IHNvbWUgaG91cnMgdG8gZmluZCBvdXQuCj4+IE5vdyBteSBJZGVhIHRvIHNvbHZlIGlzIHRv IG1pZ3JhdGUgdGhlIGZpbGVzIGluIGFuIGx2bSB2ZXJzaW9uLgo+PiBJIG5ldmVyIHVzZWQgaXQg YmVmb3JlLCBidXQgSSBoYXZlIG5vIHByb2JsZW0gdG8gY29uZmlndXJlLgo+PiBOb3cgSSBhc2sg aG93IHRvIG1pZ3JhdGUgdGhlIGZpbGVzIGFuZCBob3cgdG8gaW5zdGFsbCBpdCBpbiBhIGx2bSBw YXJ0aXRpb24uCj4+IEFueW9uZSBoZXJlIHdobyBjb3VsZCBoZWxwPwo+Pgo+PiBSZWdhcmRzCj4+ IFRob3JlCj4gSGVsbG8sCj4KPiBUaGUgcHJvY2VzcyB0byBjb3B5IHlvdXIgaW1hZ2UgdG8gYSBM Vk0gcGFydGl0aW9uIGlzIG5vdCB0b28KPiBjb21wbGljYXRlZCA6Cj4KPiBJZiB5b3VyIGltYWdl IGlzIGluICJyYXciIGZvcm1hdCBnbyB0byBTdGVwIDIuCj4KPiBTdGVwIDEgOiBjb252ZXJ0IGlt YWdlIGluICJyYXciIGZvcm1hdC4KPgo+IHFlbXUtaW1nIGNvbnZlcnQgLWYgdm1kayBvcmlnaW5h bF9pbWFnZS52bWRrIC1PIHJhdyB4ZW5fY29tcGF0aWJsZS5pbWcKPgo+IFZNREsgb3IgYW5vdGhl ciBmb3JtYXQgbGlrZSBRQ09XLCBRQ09XMiAuLi4KPgo+Cj4gU3RlcCAyIDogY3JlYXRlIHlvdXIg TFZNIHBhcnRpdGlvbgo+IE1ha2UgaXQgYmlnZ2VyIHRoYW4gInhlbl9jb21wYXRpYmxlLmltZyIg IQo+Cj4gU3RlcCAzIDogY29weSB0aGUgZGF0YQo+ICJkZCIgaXMgeW91ciBmcmllbmQKPgo+IGRk IGlmPXhlbl9jb21wYXRpYmxlLmltZyBvZj0vZGV2L3lvdXJfbHZtX3BhcnRpdGlvbiBicz0zMmsK Pgo+IFN0ZXAgNCA6IHJlc2l6ZSB0aGUgRlMKPgo+IE1vdW50IHRoZSBwYXJ0aXRpb24gb24gYW5v dGhlciBtYWNoaW5lIChjb3VsZCBiZSBhbm90aGVyIFZNKSBhbmQKPiAicmVzaXplIiB0aGUgZmls ZXN5c3RlbSB0byAiZmlsbCIgdGhlIExWTSBwYXJ0aXRpb24uIChJdCBpcyBub3QgcG9zc2libGUK PiB0byBkbyBhICJsaXZlIiBmaWxlc3lzdGVtIHJlc2l6ZSApLgo+Cj4gU3RlcCA1IDogYWxsIHNo b3VsZCBiZSBPSwo+IGxpbmsgdGhlIG5ldyBmaWxlc3lzdGVtIHRvIHlvdXIgVk0gaW5zdGVhZCBv ZiB0aGUgIm9sZCIgaW1hZ2UgZmlsZSBhbmQKPiB0cnkgdG8gc3RhcnQgeW91ciBWTQo+Cj4gVGhl IHByb2Nlc3MgaXMgc2FmZSBhcyB5b3VyIG9yaWdpbmFsIGltYWdlIGlzIG5vdCBkZXN0cm95ZWQs IHlvdSBjYW4KPiB3YWl0IGEgbGl0dGxlIGJlZm9yZSBzY3JhdGNoaW5nIGl0Lgo+Cj4gUFM6Cj4g SSBuZXZlciB1c2UgaW1hZ2UgZmlsZXMsIExWTSBpcyBlYXNpZXIgdG8gYWRhcHQgdG8gdGhlIG5l ZWRzLgo+Cj4KPiBSZWdhcmRzCj4KPiBKUCBQClRoYW5rIHlvdSBmb3IgdGhlIGhlbHAsIGkgd2ls bCB0cnkuCkFzIEkgY29uZmlndXJlZCBpdCBJIGhhZCBubyBpZGVhIGFib3V0IGl0LgpOb3cgSSBo YWQgdG8gY2hhbmdlLi4uCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gWGVuLXVzZXJzIG1haWxpbmcgbGlzdAo+IFhlbi11c2Vyc0BsaXN0cy54 ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJzCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLXVzZXJzIG1haWxpbmcgbGlzdApY ZW4tdXNlcnNAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tdXNlcnM= From xen-users-bounces@lists.xen.org Mon Mar 25 19:32:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 25 Mar 2013 19: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 1UKD7V-0008L6-Fy; Mon, 25 Mar 2013 19:31:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKD7U-0008Kz-OL for xen-users@lists.xen.org; Mon, 25 Mar 2013 19:31:48 +0000 Received: from [85.158.139.83:23251] by server-6.bemta-5.messagelabs.com id 63/C4-21466-326A0515; Mon, 25 Mar 2013 19:31:47 +0000 X-Env-Sender: thore@datensumpf.de X-Msg-Ref: server-16.tower-182.messagelabs.com!1364239907!20715320!1 X-Originating-IP: [212.12.52.213] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30902 invoked from network); 25 Mar 2013 19:31:47 -0000 Received: from mail-2.ramdrive.org (HELO mail-2.ramdrive.org) (212.12.52.213) by server-16.tower-182.messagelabs.com with SMTP; 25 Mar 2013 19:31:47 -0000 Received: from localhost (localhost [127.0.0.1]) by mail-2.ramdrive.org (Postfix) with ESMTP id B7D297801F08 for ; Mon, 25 Mar 2013 19:46:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail-2.ramdrive.org Received: from mail-2.ramdrive.org ([127.0.0.1]) by localhost (mail-2.ramdrive.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXS2hnkZkba9 for ; Mon, 25 Mar 2013 19:46:06 +0000 (UTC) Received: from [127.0.0.1] (p4FCD5EE5.dip.t-dialin.net [79.205.94.229]) by mail-2.ramdrive.org (Postfix) with ESMTPSA id 9ED1C7801F02 for ; Mon, 25 Mar 2013 19:46:06 +0000 (UTC) Message-ID: <5150A621.5070408@datensumpf.de> Date: Mon, 25 Mar 2013 20:31:45 +0100 From: Thore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <51507903.7020209@datensumpf.de> <1364238856.7855.5.camel@k2000.jpp.fr> In-Reply-To: <1364238856.7855.5.camel@k2000.jpp.fr> Subject: Re: [Xen-users] How to migrate image files in lvm X-BeenThere: xen-users@lists.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 CkFtIDI1LjAzLjIwMTMgMjA6MTQsIHNjaHJpZWIganBwQGpwcG96emkuZHluZG5zLm9yZzoKPiBM ZSBsdW5kaSAyNSBtYXJzIDIwMTMgw6AgMTc6MTkgKzAxMDAsIFRob3JlIGEgw6ljcml0IDoKPj4g SGVsbG8sCj4+IEkgaGF2ZSBwcm9ibGVtIHdpdGggbXkgeGVuIGluc3RhbGxhdGlvbiBvbiBteSB3 aGVlenkgc2VydmVyLgo+PiBJIGhhdmVuJ3QgcmVhbGx5IGFuIGlkZWEgaG93biB0by4KPj4gU28g SSdtIHVzaW5nIHhlbiBpbWFnZSBmaWxlcy4KPj4gTm93IG9uZSBWUFMgcmVhY2hlZCB0aGUgbGlt aXQgb2YgZnJlZSBzcGFjZSBhbmQga2lsbGVkIG1vcmUgb3IgbGVzcyBpdHNlbGYuCj4+IEkgbmVl ZGV0IHNvbWUgaG91cnMgdG8gZmluZCBvdXQuCj4+IE5vdyBteSBJZGVhIHRvIHNvbHZlIGlzIHRv IG1pZ3JhdGUgdGhlIGZpbGVzIGluIGFuIGx2bSB2ZXJzaW9uLgo+PiBJIG5ldmVyIHVzZWQgaXQg YmVmb3JlLCBidXQgSSBoYXZlIG5vIHByb2JsZW0gdG8gY29uZmlndXJlLgo+PiBOb3cgSSBhc2sg aG93IHRvIG1pZ3JhdGUgdGhlIGZpbGVzIGFuZCBob3cgdG8gaW5zdGFsbCBpdCBpbiBhIGx2bSBw YXJ0aXRpb24uCj4+IEFueW9uZSBoZXJlIHdobyBjb3VsZCBoZWxwPwo+Pgo+PiBSZWdhcmRzCj4+ IFRob3JlCj4gSGVsbG8sCj4KPiBUaGUgcHJvY2VzcyB0byBjb3B5IHlvdXIgaW1hZ2UgdG8gYSBM Vk0gcGFydGl0aW9uIGlzIG5vdCB0b28KPiBjb21wbGljYXRlZCA6Cj4KPiBJZiB5b3VyIGltYWdl IGlzIGluICJyYXciIGZvcm1hdCBnbyB0byBTdGVwIDIuCj4KPiBTdGVwIDEgOiBjb252ZXJ0IGlt YWdlIGluICJyYXciIGZvcm1hdC4KPgo+IHFlbXUtaW1nIGNvbnZlcnQgLWYgdm1kayBvcmlnaW5h bF9pbWFnZS52bWRrIC1PIHJhdyB4ZW5fY29tcGF0aWJsZS5pbWcKPgo+IFZNREsgb3IgYW5vdGhl ciBmb3JtYXQgbGlrZSBRQ09XLCBRQ09XMiAuLi4KPgo+Cj4gU3RlcCAyIDogY3JlYXRlIHlvdXIg TFZNIHBhcnRpdGlvbgo+IE1ha2UgaXQgYmlnZ2VyIHRoYW4gInhlbl9jb21wYXRpYmxlLmltZyIg IQo+Cj4gU3RlcCAzIDogY29weSB0aGUgZGF0YQo+ICJkZCIgaXMgeW91ciBmcmllbmQKPgo+IGRk IGlmPXhlbl9jb21wYXRpYmxlLmltZyBvZj0vZGV2L3lvdXJfbHZtX3BhcnRpdGlvbiBicz0zMmsK Pgo+IFN0ZXAgNCA6IHJlc2l6ZSB0aGUgRlMKPgo+IE1vdW50IHRoZSBwYXJ0aXRpb24gb24gYW5v dGhlciBtYWNoaW5lIChjb3VsZCBiZSBhbm90aGVyIFZNKSBhbmQKPiAicmVzaXplIiB0aGUgZmls ZXN5c3RlbSB0byAiZmlsbCIgdGhlIExWTSBwYXJ0aXRpb24uIChJdCBpcyBub3QgcG9zc2libGUK PiB0byBkbyBhICJsaXZlIiBmaWxlc3lzdGVtIHJlc2l6ZSApLgo+Cj4gU3RlcCA1IDogYWxsIHNo b3VsZCBiZSBPSwo+IGxpbmsgdGhlIG5ldyBmaWxlc3lzdGVtIHRvIHlvdXIgVk0gaW5zdGVhZCBv ZiB0aGUgIm9sZCIgaW1hZ2UgZmlsZSBhbmQKPiB0cnkgdG8gc3RhcnQgeW91ciBWTQo+Cj4gVGhl IHByb2Nlc3MgaXMgc2FmZSBhcyB5b3VyIG9yaWdpbmFsIGltYWdlIGlzIG5vdCBkZXN0cm95ZWQs IHlvdSBjYW4KPiB3YWl0IGEgbGl0dGxlIGJlZm9yZSBzY3JhdGNoaW5nIGl0Lgo+Cj4gUFM6Cj4g SSBuZXZlciB1c2UgaW1hZ2UgZmlsZXMsIExWTSBpcyBlYXNpZXIgdG8gYWRhcHQgdG8gdGhlIG5l ZWRzLgo+Cj4KPiBSZWdhcmRzCj4KPiBKUCBQClRoYW5rIHlvdSBmb3IgdGhlIGhlbHAsIGkgd2ls bCB0cnkuCkFzIEkgY29uZmlndXJlZCBpdCBJIGhhZCBubyBpZGVhIGFib3V0IGl0LgpOb3cgSSBo YWQgdG8gY2hhbmdlLi4uCj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gWGVuLXVzZXJzIG1haWxpbmcgbGlzdAo+IFhlbi11c2Vyc0BsaXN0cy54 ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJzCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLXVzZXJzIG1haWxpbmcgbGlzdApY ZW4tdXNlcnNAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tdXNlcnM= From xen-users-bounces@lists.xen.org Tue Mar 26 02:52:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 02: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 1UKJyv-00071f-4L; Tue, 26 Mar 2013 02:51:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKJyt-00071a-Cg for xen-users@lists.xen.org; Tue, 26 Mar 2013 02:51:23 +0000 Received: from [85.158.137.99:7671] by server-16.bemta-3.messagelabs.com id CF/54-20692-A2D01515; Tue, 26 Mar 2013 02:51:22 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1364266280!14950730!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12919 invoked from network); 26 Mar 2013 02:51:21 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-15.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 26 Mar 2013 02:51:21 -0000 Date: Tue, 26 Mar 2013 02:51:17 +0000 From: Mike To: Wei Liu Message-ID: <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1364069689.3919.2.camel@zion.uk.xensource.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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, Mar 23, Wei Liu wrote: > You can probably set up serial console to get output from Xen. > > http://wiki.xen.org/wiki/Xen_Serial_Console Thanks. No dice. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#10 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 02:52:45 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 02: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 1UKJyv-00071f-4L; Tue, 26 Mar 2013 02:51:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKJyt-00071a-Cg for xen-users@lists.xen.org; Tue, 26 Mar 2013 02:51:23 +0000 Received: from [85.158.137.99:7671] by server-16.bemta-3.messagelabs.com id CF/54-20692-A2D01515; Tue, 26 Mar 2013 02:51:22 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-15.tower-217.messagelabs.com!1364266280!14950730!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12919 invoked from network); 26 Mar 2013 02:51:21 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-15.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 26 Mar 2013 02:51:21 -0000 Date: Tue, 26 Mar 2013 02:51:17 +0000 From: Mike To: Wei Liu Message-ID: <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1364069689.3919.2.camel@zion.uk.xensource.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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, Mar 23, Wei Liu wrote: > You can probably set up serial console to get output from Xen. > > http://wiki.xen.org/wiki/Xen_Serial_Console Thanks. No dice. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#10 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 07:49:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 07:49: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 1UKOcb-000219-In; Tue, 26 Mar 2013 07:48:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKOca-000214-PB for xen-users@lists.xen.org; Tue, 26 Mar 2013 07:48:41 +0000 Received: from [85.158.138.51:14933] by server-2.bemta-3.messagelabs.com id 0C/77-05208-7D251515; Tue, 26 Mar 2013 07:48:39 +0000 X-Env-Sender: aaron.cossey@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1364284118!28119285!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4196 invoked from network); 26 Mar 2013 07:48:39 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 07:48:39 -0000 Received: by mail-wi0-f179.google.com with SMTP id hn17so316154wib.6 for ; Tue, 26 Mar 2013 00:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=To44grZ87woahveYVE+VEgtRux1leVY87kFRf4rCcNQ=; b=hI3XTRNOWL+zPXus2EEDs7S8q3GCDxcVVY0NM7sqg+MSOTSaxDBQYqOr+TeVl7Ozsp p2QNJn00Z2e/fv7QOZlT54mAK+vWJVEuKlE36Z2Tr0gWTbxcbAVBddsdtsga63ejnK7V 0+Lk87RO7E4uZ3I5NFKvbUQVJqVOKL1GJzk5HRihKrIyLYAwYBtNNmNu0nrvGdNI/5H4 50y+1UC8BW4z5XfrcQ05AEu39Edu1hxRZm08PNdYmb2COP9M7DCrBttZyIQo/wP6LU6G LwvHeqxpI/Yg4cWuddnJOLeMZ3vvQyKjRyI5UsGniQB2KKpkTuVMvByebNA98CZlvG1c 4J8w== MIME-Version: 1.0 X-Received: by 10.194.82.34 with SMTP id f2mr22783047wjy.25.1364284118817; Tue, 26 Mar 2013 00:48:38 -0700 (PDT) Received: by 10.194.138.40 with HTTP; Tue, 26 Mar 2013 00:48:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 08:48:38 +0100 Message-ID: From: Aaron Cossey To: Fabrice Delente Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Domain not restarting + ssh connection to Xen server delay on restarting a domain? X-BeenThere: xen-users@lists.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="===============0430525023248507578==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0430525023248507578== Content-Type: multipart/alternative; boundary=047d7beb95c0465ff704d8cf2687 --047d7beb95c0465ff704d8cf2687 Content-Type: text/plain; charset=ISO-8859-1 and when you connect to the console as the domain starts with 'xm create -c domain.cfg' Aaron Cossey aaron.cossey@gmail.com On Mon, Mar 25, 2013 at 6:05 PM, Fabrice Delente wrote: > Hello. > > I don't know if these two problems are connected, however this is what I > observe: > > I have a Windows XP guest that was stuck on shutting down (Windows must > have had to reboot after an update, but it got stuck). > > I shut down the domain with 'xm destroy', but now I can't restart it. > > I manage my domains by ssh-ing into the Xen server. When I use 'xm create > domain.cfg', I can't type anything anymore in the ssh; after a while (about > 1 minute), I can use the console again, but the domain I restarted isn't > started. > > Any hint? > > Thanks. > > -- > F. Delente > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --047d7beb95c0465ff704d8cf2687 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    and when you connect to the console as the domain starts w= ith=A0'xm create -c domain.cfg'



    On Mon, Mar 25, 2013 at 6:05 PM, Fabrice= Delente <delentef@gmail.com> wrote:
    Hello.

    I don= 9;t know if these two problems are connected, however this is what I observ= e:

    I have a Windows XP guest that was stuck on shutting down (= Windows must have had to reboot after an update, but it got stuck).

    I shut down the domain with 'xm destroy', but now I can&#= 39;t restart it.

    I manage my domains by ssh-ing into the Xen server.= When I use 'xm create domain.cfg', I can't type anything anymo= re in the ssh; after a while (about 1 minute), I can use the console again,= but the domain I restarted isn't started.

    Any hint?

    Thanks.

    --
    F. Delente

    _______________________________________________
    Xen-users mailing list
    Xen-users@lists.xen.org
    http://lists.x= en.org/xen-users

    --047d7beb95c0465ff704d8cf2687-- --===============0430525023248507578== 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 --===============0430525023248507578==-- From xen-users-bounces@lists.xen.org Tue Mar 26 07:49:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 07:49: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 1UKOcb-000219-In; Tue, 26 Mar 2013 07:48:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKOca-000214-PB for xen-users@lists.xen.org; Tue, 26 Mar 2013 07:48:41 +0000 Received: from [85.158.138.51:14933] by server-2.bemta-3.messagelabs.com id 0C/77-05208-7D251515; Tue, 26 Mar 2013 07:48:39 +0000 X-Env-Sender: aaron.cossey@gmail.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1364284118!28119285!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4196 invoked from network); 26 Mar 2013 07:48:39 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 07:48:39 -0000 Received: by mail-wi0-f179.google.com with SMTP id hn17so316154wib.6 for ; Tue, 26 Mar 2013 00:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=To44grZ87woahveYVE+VEgtRux1leVY87kFRf4rCcNQ=; b=hI3XTRNOWL+zPXus2EEDs7S8q3GCDxcVVY0NM7sqg+MSOTSaxDBQYqOr+TeVl7Ozsp p2QNJn00Z2e/fv7QOZlT54mAK+vWJVEuKlE36Z2Tr0gWTbxcbAVBddsdtsga63ejnK7V 0+Lk87RO7E4uZ3I5NFKvbUQVJqVOKL1GJzk5HRihKrIyLYAwYBtNNmNu0nrvGdNI/5H4 50y+1UC8BW4z5XfrcQ05AEu39Edu1hxRZm08PNdYmb2COP9M7DCrBttZyIQo/wP6LU6G LwvHeqxpI/Yg4cWuddnJOLeMZ3vvQyKjRyI5UsGniQB2KKpkTuVMvByebNA98CZlvG1c 4J8w== MIME-Version: 1.0 X-Received: by 10.194.82.34 with SMTP id f2mr22783047wjy.25.1364284118817; Tue, 26 Mar 2013 00:48:38 -0700 (PDT) Received: by 10.194.138.40 with HTTP; Tue, 26 Mar 2013 00:48:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 08:48:38 +0100 Message-ID: From: Aaron Cossey To: Fabrice Delente Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Domain not restarting + ssh connection to Xen server delay on restarting a domain? X-BeenThere: xen-users@lists.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="===============0430525023248507578==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0430525023248507578== Content-Type: multipart/alternative; boundary=047d7beb95c0465ff704d8cf2687 --047d7beb95c0465ff704d8cf2687 Content-Type: text/plain; charset=ISO-8859-1 and when you connect to the console as the domain starts with 'xm create -c domain.cfg' Aaron Cossey aaron.cossey@gmail.com On Mon, Mar 25, 2013 at 6:05 PM, Fabrice Delente wrote: > Hello. > > I don't know if these two problems are connected, however this is what I > observe: > > I have a Windows XP guest that was stuck on shutting down (Windows must > have had to reboot after an update, but it got stuck). > > I shut down the domain with 'xm destroy', but now I can't restart it. > > I manage my domains by ssh-ing into the Xen server. When I use 'xm create > domain.cfg', I can't type anything anymore in the ssh; after a while (about > 1 minute), I can use the console again, but the domain I restarted isn't > started. > > Any hint? > > Thanks. > > -- > F. Delente > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --047d7beb95c0465ff704d8cf2687 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    and when you connect to the console as the domain starts w= ith=A0'xm create -c domain.cfg'



    On Mon, Mar 25, 2013 at 6:05 PM, Fabrice= Delente <delentef@gmail.com> wrote:
    Hello.

    I don= 9;t know if these two problems are connected, however this is what I observ= e:

    I have a Windows XP guest that was stuck on shutting down (= Windows must have had to reboot after an update, but it got stuck).

    I shut down the domain with 'xm destroy', but now I can&#= 39;t restart it.

    I manage my domains by ssh-ing into the Xen server.= When I use 'xm create domain.cfg', I can't type anything anymo= re in the ssh; after a while (about 1 minute), I can use the console again,= but the domain I restarted isn't started.

    Any hint?

    Thanks.

    --
    F. Delente

    _______________________________________________
    Xen-users mailing list
    Xen-users@lists.xen.org
    http://lists.x= en.org/xen-users

    --047d7beb95c0465ff704d8cf2687-- --===============0430525023248507578== 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 --===============0430525023248507578==-- From xen-users-bounces@lists.xen.org Tue Mar 26 09:33:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 09:33: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 1UKQEc-00056i-9v; Tue, 26 Mar 2013 09:32:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKQEZ-00056Z-Of for xen-users@lists.xen.org; Tue, 26 Mar 2013 09:32:00 +0000 Received: from [85.158.139.211:4019] by server-12.bemta-5.messagelabs.com id E4/2C-11486-E0B61515; Tue, 26 Mar 2013 09:31:58 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1364290317!18816530!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21598 invoked from network); 26 Mar 2013 09:31:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 09:31:57 -0000 X-IronPort-AV: E=Sophos;i="4.84,911,1355097600"; d="scan'208";a="2907556" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Mar 2013 09:31:52 +0000 Received: from [192.168.1.30] (10.30.249.104) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 26 Mar 2013 09:31:51 +0000 Message-ID: <51516B06.8080704@citrix.com> Date: Tue, 26 Mar 2013 10:31:50 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: tech mailinglists References: In-Reply-To: Cc: xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@lists.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 21/02/13 10:18, tech mailinglists wrote: > Hello all, > > I have created a FreeBSD PV DomU image formatted with ZFS. I compiled > FreeBSD with KERNCONF=XEN for the kernel and the normal world and > distribution target. Then I transfered it to a Debian Dom0 with Xen 4.2.1. > > I tried to boot the image befor I migrate it to LVM and I now get teh > following output: > > Parsing config from freebsd-test.cfg > libxl: error: libxl_dm.c:1212:device_model_spawn_outcome: domain 12 > device model: spawn failed (rc=-3) > libxl: error: libxl_qmp.c:641:libxl__qmp_initialize: Connection error: > No such file or directory > Daemon running with PID 3451 > WARNING: loader(8) metadata is missing! > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > APIC: Using the MPTable enumerator. > SMP: Added CPU 0 (BSP) > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.1-RELEASE #0: Wed Feb 20 14:16:03 CET 2013 > root@build:/usr/obj/usr/src/sys/XEN i386 > WARNING: WITNESS option enabled, expect reduced performance. > Xen reported: 3341.754 MHz processor. > Timecounter "ixen" frequency 1953125 Hz quality 0 > CPU: Intel(R) Core(TM) i7 CPU 975 @ 3.33GHz (3341.75-MHz > 686-class CPU) > Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a > Stepping = 5 > > Features=0xbfe3fbff > > Features2=0x98e3bd > AMD Features=0x28100000 > AMD Features2=0x1 > > Data TLB: 4 KB pages, 4-way set associative, 64 entries > 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size > L2 cache: 256 kbytes, 8-way associative, 64 bytes/line > real memory = 2147483648 (2048 MB) > Physical memory chunk(s): > 0x0000000000a58000 - 0x000000007d995fff, 2096357376 bytes (511806 pages) > avail memory = 2092105728 (1995 MB) > INTR: Adding local APIC 0 as a target > ULE: setup cpu 0 > [XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0) > [XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1) > Event-channel device installed. > io: > random: > mem: > Pentium Pro MTRR support enabled > null: > nfslock: pseudo-device > [XEN] xen_rtc_probe: probing Hypervisor RTC clock > rtc0: on motherboard > [XEN] xen_rtc_attach: attaching Hypervisor RTC clock > rtc0: registered as a time-of-day clock (resolution 1000000us, > adjustment 0.500000000s) > xenstore0: on motherboard > Grant table initialized > xc0: on motherboard > Device configuration finished. > procfs registered > Event timer "ixen" quality 600 > Timecounters tick every 10.000 msec > lo0: bpf attached > xenbusb_front0: on xenstore0 > xenbusb_add_device: Device device/suspend/event-channel ignored. State 6 > xenbusb_back0: on xenstore0 > xctrl0: on xenstore0 > [XEN] hypervisor wallclock nudged; nudging TOD. > run_interrupt_driven_hooks: still waiting after 60 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 120 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 180 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 240 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 300 seconds for > xenbus_free_evtchn > panic: run_interrupt_driven_config_hooks: waited too long > cpuid = 0 > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> Hello, I've been trying to get a FreeBSD PV guest, I've installed FreeBSD i386 HEAD and then tried to recompile the kernel using KERNCONF=XEN, but Xen refuses to load the resulting kernel: root@loki:~# xl -vvv create -c freebsd32pv.cfg Parsing config from freebsd32pv.cfg libxl: debug: libxl_create.c:1174:do_domain_create: ao 0x22e5a20: create: how=(nil) callback=(nil) poller=0x22e5a80 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x22e60c0: deregister unregistered libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=15, free_memkb=4353 libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 8 cpus and 4353 KB free selected domainbuilder: detail: xc_dom_allocate: cmdline="boot_verbose=1,vfs.root.mountfrom=ufs:/dev/ad0s1a,kern.hz=100", features="(null)" libxl: debug: libxl_dom.c:380:libxl__build_pv: pv kernel mapped 0 path /root/kernel.freebsd domainbuilder: detail: xc_dom_kernel_file: filename="/root/kernel.freebsd" domainbuilder: detail: xc_dom_malloc_filemap : 5235 kB domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0xc0000000 memsz=0x439eb8 xc: detail: elf_parse_binary: phdr: paddr=0xc043a000 memsz=0x23a578 xc: detail: elf_parse_binary: memory: 0xc0000000 -> 0xc0674578 xc: detail: elf_xen_parse: __xen_guest: "LOADER=generic,GUEST_OS=freebsd,GUEST_VER=7.0,XEN_VER=xen-3.0,BSD_SYMTAB,VIRT_BASE=0xc0000000" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="freebsd" xc: detail: elf_xen_parse_guest_info: GUEST_VER="7.0" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: BSD_SYMTAB="" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0xc0000000" xc: detail: elf_xen_addr_calc_check: ELF_PADDR_OFFSET unset, using 0xc0000000 xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0xc0000000 xc: detail: elf_paddr_offset = 0xc0000000 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0xc0000000 xc: detail: virt_kend = 0xc07439d0 xc: detail: virt_entry = 0xc0046000 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_load_elf_symtab/parse: bsd_symtab_start=c07439d0, kernel.end=0xc07439d0 -- symtab=0xc07439d4, maxaddr=0xc0743e40 domainbuilder: detail: xc_dom_load_elf_symtab: h=25 symtab, size=0x4a310, maxaddr=0xc078e150 domainbuilder: detail: xc_dom_load_elf_symtab: h=26 strtab, size=0x69500, maxaddr=0xc07f7650 domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32: 0xc0000000 -> 0xc07f7650 domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x20000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: xc_dom_malloc : 1024 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0xc0000000 -> 0xc07f8000 (pfn 0x0 + 0x7f8 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x7f8 at 0x7f88fc22c000 xc: detail: elf_load_binary: phdr 2 at 0x0x7f88fc22c000 -> 0x0x7f88fc665eb8 xc: detail: elf_load_binary: phdr 3 at 0x0x7f88fc666000 -> 0x0x7f88fc694c9c xc: detail: elf_load_bsdsyms: shdr 4 at 0x0x7f88fca4bd84 -> 0x0x7f88fc8a09e8 xc: detail: elf_load_bsdsyms: shdr 24 at 0x0x7f88fce8cec4 -> 0x0x7f88fc8bc0a4 xc: detail: elf_load_bsdsyms: shdr 25 at 0x0x7f88fce8d418 -> 0x0x7f88fc8bc1c0 xc: detail: elf_load_bsdsyms: shdr 26 at 0x0x7f88fced7728 -> 0x0x7f88fc9064d0 domainbuilder: detail: xc_dom_load_elf_symtab/load: bsd_symtab_start=c07439d0, kernel.end=0xc07f8000 -- symtab=0xc07439d4, maxaddr=0xc0743e40 domainbuilder: detail: xc_dom_load_elf_symtab: h=25 symtab, size=0x4a310, maxaddr=0xc078e150 domainbuilder: detail: xc_dom_load_elf_symtab: h=26 strtab, size=0x69500, maxaddr=0xc07f7650 domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0xc07f8000 -> 0xc0878000 (pfn 0x7f8 + 0x80 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x7f8+0x80 at 0x7f88fec35000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xc0878000 (pfn 0x878) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xc0879000 (pfn 0x879) domainbuilder: detail: xc_dom_alloc_page : console : 0xc087a000 (pfn 0x87a) domainbuilder: detail: nr_page_tables: 0x00000000ffffffff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000003fffff/22: 0x00000000c0000000 -> 0x00000000c0bfffff, 3 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xc087b000 -> 0xc087f000 (pfn 0x87b + 0x4 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x87b+0x4 at 0x7f88fedbe000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xc087f000 (pfn 0x87f) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xc0880000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc0c00000 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64 xc: error: panic: xc_dom_boot.c:127: xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry: Invalid kernel It refuses to boot because it detects the kernel doesn't support PAE. I've hacked sys/i386/xen/locore.s in order to add the PAE flag: .ascii "LOADER=generic,GUEST_OS=freebsd,GUEST_VER=7.0,XEN_VER=xen-3.0,BSD_SYMTAB,VIRT_BASE=0xc0000000,PAE=yes[extended-cr3]" I know there's an elfnote that should tell Xen if kernel support PAE or not, but it seems to be ignored: ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz, "yes") Anyway, I've recompiled the kernel with the PAE flag hack, but then when trying to load the resulting kernel it crashes very early: (XEN) d12:v0: unhandled page fault (ec=0002) (XEN) Pagetable walk from 0000000000000100: (XEN) L4[0x000] = 0000000141710027 000000000000087b (XEN) L3[0x000] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S (XEN) Domain 12 (vcpu#0) crashed on cpu#7: (XEN) ----[ Xen-4.2.1 x86_64 debug=n Not tainted ]---- (XEN) CPU: 7 (XEN) RIP: e019:[<00000000c00452a0>] (XEN) RFLAGS: 0000000000000246 EM: 1 CONTEXT: pv guest (XEN) rax: 0000000000000100 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) rdx: 00000000c0878000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) rbp: 00000000c043e12c rsp: 00000000c043e07c r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 000000013fb58000 cr2: 0000000000000100 (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019 (XEN) Guest stack trace from esp=c043e07c: (XEN) 00000002 c00452a0 0001e019 00010046 c03adc1f 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 c0878000 00000000 c0884000 00000000 c0046015 c0878000 c043e138 (XEN) 0000e021 00000040 00000020 c0468d0c 01800000 00000001 c014ffe0 c043e2c4 (XEN) 01800000 0fffffff c01500b0 c043e2c4 01b00000 01000000 c016ef90 c043e2d4 (XEN) 01b00000 01000000 c016f0b0 c0647994 c0647a3c 00000000 ffffffff c0000001 (XEN) c0469810 00000000 c03db795 00000000 c03ecf36 00000000 00000000 c03db81e (XEN) c0469810 00000000 ffffffff 80040006 c0469804 00000000 c03db7f3 c0172990 (XEN) c03db706 00000000 00000000 c03db7fa c0469810 00000000 ffffffff 80040006 (XEN) c043e2c0 00000000 c03db786 c0172990 c03db706 00000000 00000000 c03db7c7 (XEN) c0469810 00000000 ffffffff 80040002 c04697fc 00000000 c03db79d c0172990 (XEN) c03de14d 00000000 00000000 c03db7a8 02380000 0fffffff c004a6b0 00000000 (XEN) c0469810 00000000 ffffffff c0000006 00000000 00000000 c03db643 c004a520 (XEN) c03db706 00000000 00000000 c03db709 c0469810 00000000 ffffffff 80000003 (XEN) 00000000 00000000 c03fb8f6 c004a470 c0433acf 00000000 00000000 c03db6d7 (XEN) 0000c000 00500000 00000000 3454f8e9 c03db791 00000000 c0647994 c03db832 (XEN) 00000000 c0436966 c004baa0 00000000 00000000 00000000 00000000 c0408707 Is Xen i386 PV broken? Or I'm being incredebly stupid and missing something obvious? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 09:33:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 09:33: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 1UKQEc-00056i-9v; Tue, 26 Mar 2013 09:32:02 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKQEZ-00056Z-Of for xen-users@lists.xen.org; Tue, 26 Mar 2013 09:32:00 +0000 Received: from [85.158.139.211:4019] by server-12.bemta-5.messagelabs.com id E4/2C-11486-E0B61515; Tue, 26 Mar 2013 09:31:58 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1364290317!18816530!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21598 invoked from network); 26 Mar 2013 09:31:57 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 09:31:57 -0000 X-IronPort-AV: E=Sophos;i="4.84,911,1355097600"; d="scan'208";a="2907556" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Mar 2013 09:31:52 +0000 Received: from [192.168.1.30] (10.30.249.104) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 26 Mar 2013 09:31:51 +0000 Message-ID: <51516B06.8080704@citrix.com> Date: Tue, 26 Mar 2013 10:31:50 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: tech mailinglists References: In-Reply-To: Cc: xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@lists.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 21/02/13 10:18, tech mailinglists wrote: > Hello all, > > I have created a FreeBSD PV DomU image formatted with ZFS. I compiled > FreeBSD with KERNCONF=XEN for the kernel and the normal world and > distribution target. Then I transfered it to a Debian Dom0 with Xen 4.2.1. > > I tried to boot the image befor I migrate it to LVM and I now get teh > following output: > > Parsing config from freebsd-test.cfg > libxl: error: libxl_dm.c:1212:device_model_spawn_outcome: domain 12 > device model: spawn failed (rc=-3) > libxl: error: libxl_qmp.c:641:libxl__qmp_initialize: Connection error: > No such file or directory > Daemon running with PID 3451 > WARNING: loader(8) metadata is missing! > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > APIC: Using the MPTable enumerator. > SMP: Added CPU 0 (BSP) > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.1-RELEASE #0: Wed Feb 20 14:16:03 CET 2013 > root@build:/usr/obj/usr/src/sys/XEN i386 > WARNING: WITNESS option enabled, expect reduced performance. > Xen reported: 3341.754 MHz processor. > Timecounter "ixen" frequency 1953125 Hz quality 0 > CPU: Intel(R) Core(TM) i7 CPU 975 @ 3.33GHz (3341.75-MHz > 686-class CPU) > Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a > Stepping = 5 > > Features=0xbfe3fbff > > Features2=0x98e3bd > AMD Features=0x28100000 > AMD Features2=0x1 > > Data TLB: 4 KB pages, 4-way set associative, 64 entries > 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size > L2 cache: 256 kbytes, 8-way associative, 64 bytes/line > real memory = 2147483648 (2048 MB) > Physical memory chunk(s): > 0x0000000000a58000 - 0x000000007d995fff, 2096357376 bytes (511806 pages) > avail memory = 2092105728 (1995 MB) > INTR: Adding local APIC 0 as a target > ULE: setup cpu 0 > [XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0) > [XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1) > Event-channel device installed. > io: > random: > mem: > Pentium Pro MTRR support enabled > null: > nfslock: pseudo-device > [XEN] xen_rtc_probe: probing Hypervisor RTC clock > rtc0: on motherboard > [XEN] xen_rtc_attach: attaching Hypervisor RTC clock > rtc0: registered as a time-of-day clock (resolution 1000000us, > adjustment 0.500000000s) > xenstore0: on motherboard > Grant table initialized > xc0: on motherboard > Device configuration finished. > procfs registered > Event timer "ixen" quality 600 > Timecounters tick every 10.000 msec > lo0: bpf attached > xenbusb_front0: on xenstore0 > xenbusb_add_device: Device device/suspend/event-channel ignored. State 6 > xenbusb_back0: on xenstore0 > xctrl0: on xenstore0 > [XEN] hypervisor wallclock nudged; nudging TOD. > run_interrupt_driven_hooks: still waiting after 60 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 120 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 180 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 240 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 300 seconds for > xenbus_free_evtchn > panic: run_interrupt_driven_config_hooks: waited too long > cpuid = 0 > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> Hello, I've been trying to get a FreeBSD PV guest, I've installed FreeBSD i386 HEAD and then tried to recompile the kernel using KERNCONF=XEN, but Xen refuses to load the resulting kernel: root@loki:~# xl -vvv create -c freebsd32pv.cfg Parsing config from freebsd32pv.cfg libxl: debug: libxl_create.c:1174:do_domain_create: ao 0x22e5a20: create: how=(nil) callback=(nil) poller=0x22e5a80 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x22e60c0: deregister unregistered libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=15, free_memkb=4353 libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 8 cpus and 4353 KB free selected domainbuilder: detail: xc_dom_allocate: cmdline="boot_verbose=1,vfs.root.mountfrom=ufs:/dev/ad0s1a,kern.hz=100", features="(null)" libxl: debug: libxl_dom.c:380:libxl__build_pv: pv kernel mapped 0 path /root/kernel.freebsd domainbuilder: detail: xc_dom_kernel_file: filename="/root/kernel.freebsd" domainbuilder: detail: xc_dom_malloc_filemap : 5235 kB domainbuilder: detail: xc_dom_boot_xen_init: ver 4.2, 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 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe OK xc: detail: elf_parse_binary: phdr: paddr=0xc0000000 memsz=0x439eb8 xc: detail: elf_parse_binary: phdr: paddr=0xc043a000 memsz=0x23a578 xc: detail: elf_parse_binary: memory: 0xc0000000 -> 0xc0674578 xc: detail: elf_xen_parse: __xen_guest: "LOADER=generic,GUEST_OS=freebsd,GUEST_VER=7.0,XEN_VER=xen-3.0,BSD_SYMTAB,VIRT_BASE=0xc0000000" xc: detail: elf_xen_parse_guest_info: LOADER="generic" xc: detail: elf_xen_parse_guest_info: GUEST_OS="freebsd" xc: detail: elf_xen_parse_guest_info: GUEST_VER="7.0" xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0" xc: detail: elf_xen_parse_guest_info: BSD_SYMTAB="" xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0xc0000000" xc: detail: elf_xen_addr_calc_check: ELF_PADDR_OFFSET unset, using 0xc0000000 xc: detail: elf_xen_addr_calc_check: addresses: xc: detail: virt_base = 0xc0000000 xc: detail: elf_paddr_offset = 0xc0000000 xc: detail: virt_offset = 0x0 xc: detail: virt_kstart = 0xc0000000 xc: detail: virt_kend = 0xc07439d0 xc: detail: virt_entry = 0xc0046000 xc: detail: p2m_base = 0xffffffffffffffff domainbuilder: detail: xc_dom_load_elf_symtab/parse: bsd_symtab_start=c07439d0, kernel.end=0xc07439d0 -- symtab=0xc07439d4, maxaddr=0xc0743e40 domainbuilder: detail: xc_dom_load_elf_symtab: h=25 symtab, size=0x4a310, maxaddr=0xc078e150 domainbuilder: detail: xc_dom_load_elf_symtab: h=26 strtab, size=0x69500, maxaddr=0xc07f7650 domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_32: 0xc0000000 -> 0xc07f7650 domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x20000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x20000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: xc_dom_malloc : 1024 kB domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0xc0000000 -> 0xc07f8000 (pfn 0x0 + 0x7f8 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x0+0x7f8 at 0x7f88fc22c000 xc: detail: elf_load_binary: phdr 2 at 0x0x7f88fc22c000 -> 0x0x7f88fc665eb8 xc: detail: elf_load_binary: phdr 3 at 0x0x7f88fc666000 -> 0x0x7f88fc694c9c xc: detail: elf_load_bsdsyms: shdr 4 at 0x0x7f88fca4bd84 -> 0x0x7f88fc8a09e8 xc: detail: elf_load_bsdsyms: shdr 24 at 0x0x7f88fce8cec4 -> 0x0x7f88fc8bc0a4 xc: detail: elf_load_bsdsyms: shdr 25 at 0x0x7f88fce8d418 -> 0x0x7f88fc8bc1c0 xc: detail: elf_load_bsdsyms: shdr 26 at 0x0x7f88fced7728 -> 0x0x7f88fc9064d0 domainbuilder: detail: xc_dom_load_elf_symtab/load: bsd_symtab_start=c07439d0, kernel.end=0xc07f8000 -- symtab=0xc07439d4, maxaddr=0xc0743e40 domainbuilder: detail: xc_dom_load_elf_symtab: h=25 symtab, size=0x4a310, maxaddr=0xc078e150 domainbuilder: detail: xc_dom_load_elf_symtab: h=26 strtab, size=0x69500, maxaddr=0xc07f7650 domainbuilder: detail: xc_dom_alloc_segment: phys2mach : 0xc07f8000 -> 0xc0878000 (pfn 0x7f8 + 0x80 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x7f8+0x80 at 0x7f88fec35000 domainbuilder: detail: xc_dom_alloc_page : start info : 0xc0878000 (pfn 0x878) domainbuilder: detail: xc_dom_alloc_page : xenstore : 0xc0879000 (pfn 0x879) domainbuilder: detail: xc_dom_alloc_page : console : 0xc087a000 (pfn 0x87a) domainbuilder: detail: nr_page_tables: 0x00000000ffffffff/32: 0x0000000000000000 -> 0x00000000ffffffff, 1 table(s) domainbuilder: detail: nr_page_tables: 0x00000000003fffff/22: 0x00000000c0000000 -> 0x00000000c0bfffff, 3 table(s) domainbuilder: detail: xc_dom_alloc_segment: page tables : 0xc087b000 -> 0xc087f000 (pfn 0x87b + 0x4 pages) domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x87b+0x4 at 0x7f88fedbe000 domainbuilder: detail: xc_dom_alloc_page : boot stack : 0xc087f000 (pfn 0x87f) domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0xc0880000 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0xc0c00000 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64 domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64 xc: error: panic: xc_dom_boot.c:127: xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry: Invalid kernel It refuses to boot because it detects the kernel doesn't support PAE. I've hacked sys/i386/xen/locore.s in order to add the PAE flag: .ascii "LOADER=generic,GUEST_OS=freebsd,GUEST_VER=7.0,XEN_VER=xen-3.0,BSD_SYMTAB,VIRT_BASE=0xc0000000,PAE=yes[extended-cr3]" I know there's an elfnote that should tell Xen if kernel support PAE or not, but it seems to be ignored: ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz, "yes") Anyway, I've recompiled the kernel with the PAE flag hack, but then when trying to load the resulting kernel it crashes very early: (XEN) d12:v0: unhandled page fault (ec=0002) (XEN) Pagetable walk from 0000000000000100: (XEN) L4[0x000] = 0000000141710027 000000000000087b (XEN) L3[0x000] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S (XEN) Domain 12 (vcpu#0) crashed on cpu#7: (XEN) ----[ Xen-4.2.1 x86_64 debug=n Not tainted ]---- (XEN) CPU: 7 (XEN) RIP: e019:[<00000000c00452a0>] (XEN) RFLAGS: 0000000000000246 EM: 1 CONTEXT: pv guest (XEN) rax: 0000000000000100 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) rdx: 00000000c0878000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) rbp: 00000000c043e12c rsp: 00000000c043e07c r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 000000013fb58000 cr2: 0000000000000100 (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019 (XEN) Guest stack trace from esp=c043e07c: (XEN) 00000002 c00452a0 0001e019 00010046 c03adc1f 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 c0878000 00000000 c0884000 00000000 c0046015 c0878000 c043e138 (XEN) 0000e021 00000040 00000020 c0468d0c 01800000 00000001 c014ffe0 c043e2c4 (XEN) 01800000 0fffffff c01500b0 c043e2c4 01b00000 01000000 c016ef90 c043e2d4 (XEN) 01b00000 01000000 c016f0b0 c0647994 c0647a3c 00000000 ffffffff c0000001 (XEN) c0469810 00000000 c03db795 00000000 c03ecf36 00000000 00000000 c03db81e (XEN) c0469810 00000000 ffffffff 80040006 c0469804 00000000 c03db7f3 c0172990 (XEN) c03db706 00000000 00000000 c03db7fa c0469810 00000000 ffffffff 80040006 (XEN) c043e2c0 00000000 c03db786 c0172990 c03db706 00000000 00000000 c03db7c7 (XEN) c0469810 00000000 ffffffff 80040002 c04697fc 00000000 c03db79d c0172990 (XEN) c03de14d 00000000 00000000 c03db7a8 02380000 0fffffff c004a6b0 00000000 (XEN) c0469810 00000000 ffffffff c0000006 00000000 00000000 c03db643 c004a520 (XEN) c03db706 00000000 00000000 c03db709 c0469810 00000000 ffffffff 80000003 (XEN) 00000000 00000000 c03fb8f6 c004a470 c0433acf 00000000 00000000 c03db6d7 (XEN) 0000c000 00500000 00000000 3454f8e9 c03db791 00000000 c0647994 c03db832 (XEN) 00000000 c0436966 c004baa0 00000000 00000000 00000000 00000000 c0408707 Is Xen i386 PV broken? Or I'm being incredebly stupid and missing something obvious? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 10:12:05 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 10:12:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKQqS-00060f-9t; Tue, 26 Mar 2013 10:11:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKQqR-00060X-6M for xen-users@lists.xen.org; Tue, 26 Mar 2013 10:11:07 +0000 Received: from [193.109.254.147:29307] by server-12.bemta-14.messagelabs.com id 26/26-05449-A3471515; Tue, 26 Mar 2013 10:11:06 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1364292616!8777564!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10105 invoked from network); 26 Mar 2013 10:10:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 10:10:17 -0000 X-IronPort-AV: E=Sophos;i="4.84,911,1355097600"; d="scan'208";a="2909776" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Mar 2013 10:10:17 +0000 Received: from [192.168.1.30] (10.30.249.104) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 26 Mar 2013 10:10:16 +0000 Message-ID: <51517407.8040406@citrix.com> Date: Tue, 26 Mar 2013 11:10:15 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Colin Percival References: <51516B06.8080704@citrix.com> <51516CAA.3040802@freebsd.org> In-Reply-To: <51516CAA.3040802@freebsd.org> Cc: tech mailinglists , xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@lists.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 On 26/03/13 10:38, Colin Percival wrote: > On 03/26/13 02:31, Roger Pau Monn=E9 wrote: >> Is Xen i386 PV broken? > = > Not completely broken, but it's certainly not in a good state. I believe > it's broken with SMP, for example -- if the "crashed on cpu#7" in your > output means cpu#7 from the guest, it would certainly explain things. My guest only has one vcpu (vcpu#0): Domain 12 (vcpu#0) crashed on cpu#7 That is running on physical CPU 7 > HVM is the way to go with FreeBSD/Xen. Yes, I'm already working on that, and got vector callbacks working on both i386 and amd64 HVM guests, thanks to Justin T. Gibbs patch. Now I was trying to boot a PV guest to see how much breakage this change introduced to PV, but I'm not able to make it work, even without my patches. I've replied to this xen-users thread because the author seem to have a working FreeBSD DomU PV guest, and I was wondering how he did it. From my POV it seems like PV guests hasn't been working for a long time, since Xen 3.3 dropped support for non-PAE guests, and the FreeBSD kernel is detected as non-PAE. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 10:12:05 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 10:12:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKQqS-00060f-9t; Tue, 26 Mar 2013 10:11:08 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKQqR-00060X-6M for xen-users@lists.xen.org; Tue, 26 Mar 2013 10:11:07 +0000 Received: from [193.109.254.147:29307] by server-12.bemta-14.messagelabs.com id 26/26-05449-A3471515; Tue, 26 Mar 2013 10:11:06 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1364292616!8777564!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10105 invoked from network); 26 Mar 2013 10:10:17 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 10:10:17 -0000 X-IronPort-AV: E=Sophos;i="4.84,911,1355097600"; d="scan'208";a="2909776" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Mar 2013 10:10:17 +0000 Received: from [192.168.1.30] (10.30.249.104) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 26 Mar 2013 10:10:16 +0000 Message-ID: <51517407.8040406@citrix.com> Date: Tue, 26 Mar 2013 11:10:15 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Colin Percival References: <51516B06.8080704@citrix.com> <51516CAA.3040802@freebsd.org> In-Reply-To: <51516CAA.3040802@freebsd.org> Cc: tech mailinglists , xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@lists.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 On 26/03/13 10:38, Colin Percival wrote: > On 03/26/13 02:31, Roger Pau Monn=E9 wrote: >> Is Xen i386 PV broken? > = > Not completely broken, but it's certainly not in a good state. I believe > it's broken with SMP, for example -- if the "crashed on cpu#7" in your > output means cpu#7 from the guest, it would certainly explain things. My guest only has one vcpu (vcpu#0): Domain 12 (vcpu#0) crashed on cpu#7 That is running on physical CPU 7 > HVM is the way to go with FreeBSD/Xen. Yes, I'm already working on that, and got vector callbacks working on both i386 and amd64 HVM guests, thanks to Justin T. Gibbs patch. Now I was trying to boot a PV guest to see how much breakage this change introduced to PV, but I'm not able to make it work, even without my patches. I've replied to this xen-users thread because the author seem to have a working FreeBSD DomU PV guest, and I was wondering how he did it. From my POV it seems like PV guests hasn't been working for a long time, since Xen 3.3 dropped support for non-PAE guests, and the FreeBSD kernel is detected as non-PAE. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 11:30:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11:30: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 1UKS4F-0007mO-Uj; Tue, 26 Mar 2013 11:29:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKPbb-0003WC-Uq for xen-users@lists.xen.org; Tue, 26 Mar 2013 08:51:44 +0000 Received: from [85.158.143.99:46408] by server-1.bemta-4.messagelabs.com id 83/95-06203-F9161515; Tue, 26 Mar 2013 08:51:43 +0000 X-Env-Sender: kmoravec@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1364287902!18760494!1 X-Originating-IP: [209.85.215.49] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32228 invoked from network); 26 Mar 2013 08:51:42 -0000 Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com) (209.85.215.49) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 08:51:42 -0000 Received: by mail-la0-f49.google.com with SMTP id fs13so12818875lab.8 for ; Tue, 26 Mar 2013 01:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=iSVb/WBJNNnjN0Ihr/+T0UqQgOlVRlHxrabdEiC9LKs=; b=GDgfhw9wdiEWkRqdbdn9lRhyLlEpYM8RP9/2GsCN9Bputogff0lYXT6fVeZg25VxBE oqq4Hrp01wIPxkXGS95Y0mXzYCZ4XW6HOdZRxWIQGrVQkHQFKNw/4VldJPE0LHW4uf69 7uyMpuIA4kRWE75GIkqnwkvV9r8QxL00lxhJ/zj/kTTaS3JwhrB+QnHyyNTqMnfpWIOt QF24RhmHe/g1IwIuef19LvVdK4gnZrZHMP8u1Oa94AA2iSmXmzXhP9o7y45HEVsncsTT tPTZGao7alLMFrEcBbv0xtcfyIa8svaLOzZdXwx2mUfn07CMxpYt0PcEGtPcp61El34w 4ffA== X-Received: by 10.112.125.129 with SMTP id mq1mr1526522lbb.116.1364287901681; Tue, 26 Mar 2013 01:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.150.163 with HTTP; Tue, 26 Mar 2013 01:51:10 -0700 (PDT) From: Karel Moravec Date: Tue, 26 Mar 2013 16:51:10 +0800 Message-ID: To: xen-users@lists.xen.org X-Mailman-Approved-At: Tue, 26 Mar 2013 11:29:27 +0000 Subject: [Xen-users] setup issue / "did you run git update-server-info on the server?" X-BeenThere: xen-users@lists.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 Hello, I'm having problem with getting Xen 4.1 set up on Fedora 12 x64. Here's what I've done so far: export GIT_HTTP=3Dy hg clone http://xenbits.xensource.com/xen-4.1-testing.hg cd /root/xen-4.1-testing.hg make -j8 world make =96j8 install And when trying to get the menuconfig option: make linux-2.6-pvops-config CONFIGMODE=3Dmenuconfig It would proceed but eventually stop showing following error message: ... + git clone -o xen -n http://www.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-pvops.git.tmp Cloning into linux-2.6-pvops.git.tmp... fatal: http://www.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git/info/r= efs not found: did you run git update-server-info on the server? make[1]: *** [linux-2.6-pvops.git/.valid-src] Error 128 make[1]: Leaving directory `/root/xen-4.1-testing.hg' make: *** [linux-2.6-pvops-config] Error 2 [root@localhost xen-4.1-testing.hg]# When checked manually for that link (http://www.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git/info/refs) there is no 'refs' folder indeed (only a file named exclude). Where's the catch? Thank you, Karel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 11:30:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11:30: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 1UKS4F-0007mO-Uj; Tue, 26 Mar 2013 11:29:27 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKPbb-0003WC-Uq for xen-users@lists.xen.org; Tue, 26 Mar 2013 08:51:44 +0000 Received: from [85.158.143.99:46408] by server-1.bemta-4.messagelabs.com id 83/95-06203-F9161515; Tue, 26 Mar 2013 08:51:43 +0000 X-Env-Sender: kmoravec@gmail.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1364287902!18760494!1 X-Originating-IP: [209.85.215.49] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32228 invoked from network); 26 Mar 2013 08:51:42 -0000 Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com) (209.85.215.49) by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 08:51:42 -0000 Received: by mail-la0-f49.google.com with SMTP id fs13so12818875lab.8 for ; Tue, 26 Mar 2013 01:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=iSVb/WBJNNnjN0Ihr/+T0UqQgOlVRlHxrabdEiC9LKs=; b=GDgfhw9wdiEWkRqdbdn9lRhyLlEpYM8RP9/2GsCN9Bputogff0lYXT6fVeZg25VxBE oqq4Hrp01wIPxkXGS95Y0mXzYCZ4XW6HOdZRxWIQGrVQkHQFKNw/4VldJPE0LHW4uf69 7uyMpuIA4kRWE75GIkqnwkvV9r8QxL00lxhJ/zj/kTTaS3JwhrB+QnHyyNTqMnfpWIOt QF24RhmHe/g1IwIuef19LvVdK4gnZrZHMP8u1Oa94AA2iSmXmzXhP9o7y45HEVsncsTT tPTZGao7alLMFrEcBbv0xtcfyIa8svaLOzZdXwx2mUfn07CMxpYt0PcEGtPcp61El34w 4ffA== X-Received: by 10.112.125.129 with SMTP id mq1mr1526522lbb.116.1364287901681; Tue, 26 Mar 2013 01:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.150.163 with HTTP; Tue, 26 Mar 2013 01:51:10 -0700 (PDT) From: Karel Moravec Date: Tue, 26 Mar 2013 16:51:10 +0800 Message-ID: To: xen-users@lists.xen.org X-Mailman-Approved-At: Tue, 26 Mar 2013 11:29:27 +0000 Subject: [Xen-users] setup issue / "did you run git update-server-info on the server?" X-BeenThere: xen-users@lists.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 Hello, I'm having problem with getting Xen 4.1 set up on Fedora 12 x64. Here's what I've done so far: export GIT_HTTP=3Dy hg clone http://xenbits.xensource.com/xen-4.1-testing.hg cd /root/xen-4.1-testing.hg make -j8 world make =96j8 install And when trying to get the menuconfig option: make linux-2.6-pvops-config CONFIGMODE=3Dmenuconfig It would proceed but eventually stop showing following error message: ... + git clone -o xen -n http://www.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-pvops.git.tmp Cloning into linux-2.6-pvops.git.tmp... fatal: http://www.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git/info/r= efs not found: did you run git update-server-info on the server? make[1]: *** [linux-2.6-pvops.git/.valid-src] Error 128 make[1]: Leaving directory `/root/xen-4.1-testing.hg' make: *** [linux-2.6-pvops-config] Error 2 [root@localhost xen-4.1-testing.hg]# When checked manually for that link (http://www.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git/info/refs) there is no 'refs' folder indeed (only a file named exclude). Where's the catch? Thank you, Karel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 11:30:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11:30: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 1UKS4H-0007mg-5w; Tue, 26 Mar 2013 11:29:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKQvj-0006D1-PZ for xen-users@lists.xen.org; Tue, 26 Mar 2013 10:16:35 +0000 Received: from [85.158.139.211:48747] by server-12.bemta-5.messagelabs.com id 72/B4-11486-28571515; Tue, 26 Mar 2013 10:16:34 +0000 X-Env-Sender: bounces+73574-00ed-xen-users=lists.xen.org@sendgrid.me X-Msg-Ref: server-11.tower-206.messagelabs.com!1364292981!20111542!1 X-Originating-IP: [208.117.48.85] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA4LjExNy40OC44NSA9PiAyMTkxNDY=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22519 invoked from network); 26 Mar 2013 10:16:29 -0000 Received: from o3.shared.sendgrid.net (HELO o3.shared.sendgrid.net) (208.117.48.85) by server-11.tower-206.messagelabs.com with SMTP; 26 Mar 2013 10:16:29 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpapi; bh=AjflC5imm8BgNiwaeOdCPt e38+E=; b=t+Efrf2uV+ioavsFMsrm/lXAVLM4zZVxHwjSn/qm01/TmjdF8k+M7m Y33/5uHJt2FY9JpGCRm/L0uBZLsZNxjGeqw6JFsMJ3PpOcIwb4tg7BySNkv9MIny +Gk1Lmz/NQ16NoLwfJ+Cnn7fppVfAkuksR4qfi26yPlEV2G4Nj3t4= Received: by 10.42.80.122 with SMTP id filter-056.23878.515175722 Tue, 26 Mar 2013 10:16:18 +0000 (UTC) Received: from mail.tarsnap.com (unknown [10.60.208.17]) by mi1 (SG) with ESMTP id 51517571.636e.25ed79d for ; Tue, 26 Mar 2013 05:16:17 -0500 (CST) Received: (qmail 68784 invoked from network); 26 Mar 2013 10:16:16 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 26 Mar 2013 10:16:16 -0000 Received: (qmail 16918 invoked from network); 26 Mar 2013 10:14:52 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 26 Mar 2013 10:14:52 -0000 Message-ID: <5151751C.5080501@freebsd.org> Date: Tue, 26 Mar 2013 03:14:52 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= References: <51516B06.8080704@citrix.com> <51516CAA.3040802@freebsd.org> <51517407.8040406@citrix.com> In-Reply-To: <51517407.8040406@citrix.com> X-Enigmail-Version: 1.5.1 X-SG-EID: Vb8kriuyQVhcmJ+HDj1oWfT4X8H6UKbkd/KpA+t5+nT6huxAdKvFD4YQj6Sh7NzyPmasUuLpVzRbQCrSdwAeXbQiAFYj48iPoozw9xDNWhA52+0dzscuivanXRL9WUkBgzOh8HEjN8/ZInFCexuFYw== X-Mailman-Approved-At: Tue, 26 Mar 2013 11:29:27 +0000 Cc: tech mailinglists , xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@lists.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 On 03/26/13 03:10, Roger Pau Monn=E9 wrote: > On 26/03/13 10:38, Colin Percival wrote: >> On 03/26/13 02:31, Roger Pau Monn=E9 wrote: >>> Is Xen i386 PV broken? >> >> Not completely broken, but it's certainly not in a good state. I believe >> it's broken with SMP, for example -- if the "crashed on cpu#7" in your >> output means cpu#7 from the guest, it would certainly explain things. > = > My guest only has one vcpu (vcpu#0): Ok, I wasn't sure how to parse that output. >> HVM is the way to go with FreeBSD/Xen. > = > Yes, I'm already working on that, and got vector callbacks working on > both i386 and amd64 HVM guests, thanks to Justin T. Gibbs patch. Now I > was trying to boot a PV guest to see how much breakage this change > introduced to PV, but I'm not able to make it work, even without my patch= es. > = > I've replied to this xen-users thread because the author seem to have a > working FreeBSD DomU PV guest, and I was wondering how he did it. From > my POV it seems like PV guests hasn't been working for a long time, > since Xen 3.3 dropped support for non-PAE guests, and the FreeBSD kernel > is detected as non-PAE. I had FreeBSD 8.2-RELEASE and a 9.0-CURRENT @ January 2011 running with PV in EC2 (http://www.daemonology.net/freebsd-on-ec2/, look for "t1.micro instances only") and that used PAE. But it's entirely likely that something got broken in the past two years and nobody noticed because nobody ever uses PV... -- = Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 11:30:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11:30: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 1UKS4H-0007mg-5w; Tue, 26 Mar 2013 11:29:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKQvj-0006D1-PZ for xen-users@lists.xen.org; Tue, 26 Mar 2013 10:16:35 +0000 Received: from [85.158.139.211:48747] by server-12.bemta-5.messagelabs.com id 72/B4-11486-28571515; Tue, 26 Mar 2013 10:16:34 +0000 X-Env-Sender: bounces+73574-00ed-xen-users=lists.xen.org@sendgrid.me X-Msg-Ref: server-11.tower-206.messagelabs.com!1364292981!20111542!1 X-Originating-IP: [208.117.48.85] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA4LjExNy40OC44NSA9PiAyMTkxNDY=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22519 invoked from network); 26 Mar 2013 10:16:29 -0000 Received: from o3.shared.sendgrid.net (HELO o3.shared.sendgrid.net) (208.117.48.85) by server-11.tower-206.messagelabs.com with SMTP; 26 Mar 2013 10:16:29 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpapi; bh=AjflC5imm8BgNiwaeOdCPt e38+E=; b=t+Efrf2uV+ioavsFMsrm/lXAVLM4zZVxHwjSn/qm01/TmjdF8k+M7m Y33/5uHJt2FY9JpGCRm/L0uBZLsZNxjGeqw6JFsMJ3PpOcIwb4tg7BySNkv9MIny +Gk1Lmz/NQ16NoLwfJ+Cnn7fppVfAkuksR4qfi26yPlEV2G4Nj3t4= Received: by 10.42.80.122 with SMTP id filter-056.23878.515175722 Tue, 26 Mar 2013 10:16:18 +0000 (UTC) Received: from mail.tarsnap.com (unknown [10.60.208.17]) by mi1 (SG) with ESMTP id 51517571.636e.25ed79d for ; Tue, 26 Mar 2013 05:16:17 -0500 (CST) Received: (qmail 68784 invoked from network); 26 Mar 2013 10:16:16 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 26 Mar 2013 10:16:16 -0000 Received: (qmail 16918 invoked from network); 26 Mar 2013 10:14:52 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 26 Mar 2013 10:14:52 -0000 Message-ID: <5151751C.5080501@freebsd.org> Date: Tue, 26 Mar 2013 03:14:52 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= References: <51516B06.8080704@citrix.com> <51516CAA.3040802@freebsd.org> <51517407.8040406@citrix.com> In-Reply-To: <51517407.8040406@citrix.com> X-Enigmail-Version: 1.5.1 X-SG-EID: Vb8kriuyQVhcmJ+HDj1oWfT4X8H6UKbkd/KpA+t5+nT6huxAdKvFD4YQj6Sh7NzyPmasUuLpVzRbQCrSdwAeXbQiAFYj48iPoozw9xDNWhA52+0dzscuivanXRL9WUkBgzOh8HEjN8/ZInFCexuFYw== X-Mailman-Approved-At: Tue, 26 Mar 2013 11:29:27 +0000 Cc: tech mailinglists , xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@lists.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 On 03/26/13 03:10, Roger Pau Monn=E9 wrote: > On 26/03/13 10:38, Colin Percival wrote: >> On 03/26/13 02:31, Roger Pau Monn=E9 wrote: >>> Is Xen i386 PV broken? >> >> Not completely broken, but it's certainly not in a good state. I believe >> it's broken with SMP, for example -- if the "crashed on cpu#7" in your >> output means cpu#7 from the guest, it would certainly explain things. > = > My guest only has one vcpu (vcpu#0): Ok, I wasn't sure how to parse that output. >> HVM is the way to go with FreeBSD/Xen. > = > Yes, I'm already working on that, and got vector callbacks working on > both i386 and amd64 HVM guests, thanks to Justin T. Gibbs patch. Now I > was trying to boot a PV guest to see how much breakage this change > introduced to PV, but I'm not able to make it work, even without my patch= es. > = > I've replied to this xen-users thread because the author seem to have a > working FreeBSD DomU PV guest, and I was wondering how he did it. From > my POV it seems like PV guests hasn't been working for a long time, > since Xen 3.3 dropped support for non-PAE guests, and the FreeBSD kernel > is detected as non-PAE. I had FreeBSD 8.2-RELEASE and a 9.0-CURRENT @ January 2011 running with PV in EC2 (http://www.daemonology.net/freebsd-on-ec2/, look for "t1.micro instances only") and that used PAE. But it's entirely likely that something got broken in the past two years and nobody noticed because nobody ever uses PV... -- = Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 11:30:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11: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 1UKS4G-0007mX-IU; Tue, 26 Mar 2013 11: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 1UKQQf-0005hN-2C for xen-users@lists.xen.org; Tue, 26 Mar 2013 09:44:29 +0000 Received: from [193.109.254.147:41482] by server-9.bemta-14.messagelabs.com id FD/7F-04223-CFD61515; Tue, 26 Mar 2013 09:44:28 +0000 X-Env-Sender: bounces+73574-00ed-xen-users=lists.xen.org@sendgrid.me X-Msg-Ref: server-7.tower-27.messagelabs.com!1364290813!1328606!1 X-Originating-IP: [208.117.48.85] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA4LjExNy40OC44NSA9PiAyMTkxNDY=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26037 invoked from network); 26 Mar 2013 09:40:14 -0000 Received: from o3.shared.sendgrid.net (HELO o3.shared.sendgrid.net) (208.117.48.85) by server-7.tower-27.messagelabs.com with SMTP; 26 Mar 2013 09:40:14 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpapi; bh=//OO+ditsMwTtqdJKZ/21S GLTAU=; b=JAT+DQ43//tRrayog2P2D172lrNA5ZrOAjuNJMNstimGMBn81fPYQZ Q5+mpNaI/E9DkoVr4mLGnNpOX2yq4PO+hpb2OEK+LIz2KBLNZjUooBzcrhYo4A/z VOAtmztRmceVGSTX0RMyUiTiBOdTzs6eRv1/KwpWl6I/H8gbOHwM8= Received: by 10.42.80.136 with SMTP id filter-070.13759.51516CFD3 Tue, 26 Mar 2013 09:40:13 +0000 (UTC) Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi4 (SG) with ESMTP id 51516cfd.7f3.22c650b for ; Tue, 26 Mar 2013 04:40:13 -0500 (CST) Received: (qmail 67644 invoked from network); 26 Mar 2013 09:40:12 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 26 Mar 2013 09:40:12 -0000 Received: (qmail 16134 invoked from network); 26 Mar 2013 09:38:50 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 26 Mar 2013 09:38:50 -0000 Message-ID: <51516CAA.3040802@freebsd.org> Date: Tue, 26 Mar 2013 02:38:50 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= References: <51516B06.8080704@citrix.com> In-Reply-To: <51516B06.8080704@citrix.com> X-Enigmail-Version: 1.5.1 X-SG-EID: Vb8kriuyQVhcmJ+HDj1oWfT4X8H6UKbkd/KpA+t5+nT6huxAdKvFD4YQj6Sh7Nzyh9pzsiYuQrhPV3o1OU4IZF43kcz8fbl11HvG6Ru72G6V9ZUoyampD5EY+TViua9/+iFvokAWizWmH8IZ+byAOA== X-Mailman-Approved-At: Tue, 26 Mar 2013 11:29:27 +0000 Cc: tech mailinglists , xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@lists.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 On 03/26/13 02:31, Roger Pau Monn=E9 wrote: > Is Xen i386 PV broken? Not completely broken, but it's certainly not in a good state. I believe it's broken with SMP, for example -- if the "crashed on cpu#7" in your output means cpu#7 from the guest, it would certainly explain things. HVM is the way to go with FreeBSD/Xen. -- = Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 11:30:20 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11: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 1UKS4G-0007mX-IU; Tue, 26 Mar 2013 11: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 1UKQQf-0005hN-2C for xen-users@lists.xen.org; Tue, 26 Mar 2013 09:44:29 +0000 Received: from [193.109.254.147:41482] by server-9.bemta-14.messagelabs.com id FD/7F-04223-CFD61515; Tue, 26 Mar 2013 09:44:28 +0000 X-Env-Sender: bounces+73574-00ed-xen-users=lists.xen.org@sendgrid.me X-Msg-Ref: server-7.tower-27.messagelabs.com!1364290813!1328606!1 X-Originating-IP: [208.117.48.85] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA4LjExNy40OC44NSA9PiAyMTkxNDY=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26037 invoked from network); 26 Mar 2013 09:40:14 -0000 Received: from o3.shared.sendgrid.net (HELO o3.shared.sendgrid.net) (208.117.48.85) by server-7.tower-27.messagelabs.com with SMTP; 26 Mar 2013 09:40:14 -0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpapi; bh=//OO+ditsMwTtqdJKZ/21S GLTAU=; b=JAT+DQ43//tRrayog2P2D172lrNA5ZrOAjuNJMNstimGMBn81fPYQZ Q5+mpNaI/E9DkoVr4mLGnNpOX2yq4PO+hpb2OEK+LIz2KBLNZjUooBzcrhYo4A/z VOAtmztRmceVGSTX0RMyUiTiBOdTzs6eRv1/KwpWl6I/H8gbOHwM8= Received: by 10.42.80.136 with SMTP id filter-070.13759.51516CFD3 Tue, 26 Mar 2013 09:40:13 +0000 (UTC) Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi4 (SG) with ESMTP id 51516cfd.7f3.22c650b for ; Tue, 26 Mar 2013 04:40:13 -0500 (CST) Received: (qmail 67644 invoked from network); 26 Mar 2013 09:40:12 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 26 Mar 2013 09:40:12 -0000 Received: (qmail 16134 invoked from network); 26 Mar 2013 09:38:50 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 26 Mar 2013 09:38:50 -0000 Message-ID: <51516CAA.3040802@freebsd.org> Date: Tue, 26 Mar 2013 02:38:50 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= References: <51516B06.8080704@citrix.com> In-Reply-To: <51516B06.8080704@citrix.com> X-Enigmail-Version: 1.5.1 X-SG-EID: Vb8kriuyQVhcmJ+HDj1oWfT4X8H6UKbkd/KpA+t5+nT6huxAdKvFD4YQj6Sh7Nzyh9pzsiYuQrhPV3o1OU4IZF43kcz8fbl11HvG6Ru72G6V9ZUoyampD5EY+TViua9/+iFvokAWizWmH8IZ+byAOA== X-Mailman-Approved-At: Tue, 26 Mar 2013 11:29:27 +0000 Cc: tech mailinglists , xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@lists.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 On 03/26/13 02:31, Roger Pau Monn=E9 wrote: > Is Xen i386 PV broken? Not completely broken, but it's certainly not in a good state. I believe it's broken with SMP, for example -- if the "crashed on cpu#7" in your output means cpu#7 from the guest, it would certainly explain things. HVM is the way to go with FreeBSD/Xen. -- = Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 11:30:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11:30: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 1UKS4F-0007mE-BN; Tue, 26 Mar 2013 11:29:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKOy3-0003NN-Ax; Tue, 26 Mar 2013 08:10:51 +0000 Received: from [85.158.139.211:50869] by server-11.bemta-5.messagelabs.com id 8A/18-27486-A0851515; Tue, 26 Mar 2013 08:10:50 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1364285446!19670380!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23481 invoked from network); 26 Mar 2013 08:10:46 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-15.tower-206.messagelabs.com with SMTP; 26 Mar 2013 08:10:46 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r2Q8Ac8I011582; Tue, 26 Mar 2013 03:10:38 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r2Q8AbAm011581; Tue, 26 Mar 2013 03:10:37 -0500 Date: Tue, 26 Mar 2013 03:10:37 -0500 From: "Dr. Greg Wettstein" Message-Id: <201303260810.r2Q8AbAm011581@wind.enjellic.com> X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: xen-devel@lists.xen.org, xen-users@lists.xen.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Tue, 26 Mar 2013 03:10:38 -0500 (CDT) X-Mailman-Approved-At: Tue, 26 Mar 2013 11:29:27 +0000 Cc: scst-devel@lists.sourceforge.net Subject: [Xen-users] Release 0.2.0 of Xen-SAN. X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: xen@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Good morning, Izzy and I hope the week is going well for everyone. He is curled up on the couch right now recovering from about 22 miles of cross-country skiing in West-Central Minnesota over the weekend. Izzy asked me to let everyone know that a new release of the Xen-SAN package is available. It can be downloaded from the following URL: ftp://ftp.enjellic.com/pub/xen/Xen-SAN-0.2.0.tar.gz This package implements functionality which allows Xen domU guests to be first class entities in an iSCSI based SAN. The major change in this version is that the block-iscsi hotplug script should drop directly into a 4.2.x implementation of a Linux based Xen implementation without any other changes. The previous version required support from the 'block' hotplug script. This implementation has been extensively tested with a Linux based SCST storage target stack in a Linux dom0 environment with iSCSI client support. There is extensive documentation in the README file included in the package. Best wishes for a productive week to everyone. Greg and Izzy As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "We came, we saw, we fought, we conquered the multi-headed beast which is storage for isochronous video delivery." Any questions on the project summary? -- Dr. Greg Wettstein Resurrection _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 11:30:21 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11:30: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 1UKS4F-0007mE-BN; Tue, 26 Mar 2013 11:29:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKOy3-0003NN-Ax; Tue, 26 Mar 2013 08:10:51 +0000 Received: from [85.158.139.211:50869] by server-11.bemta-5.messagelabs.com id 8A/18-27486-A0851515; Tue, 26 Mar 2013 08:10:50 +0000 X-Env-Sender: greg@wind.enjellic.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1364285446!19670380!1 X-Originating-IP: [76.10.64.91] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23481 invoked from network); 26 Mar 2013 08:10:46 -0000 Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91) by server-15.tower-206.messagelabs.com with SMTP; 26 Mar 2013 08:10:46 -0000 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id r2Q8Ac8I011582; Tue, 26 Mar 2013 03:10:38 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.14.3/8.14.3/Submit) id r2Q8AbAm011581; Tue, 26 Mar 2013 03:10:37 -0500 Date: Tue, 26 Mar 2013 03:10:37 -0500 From: "Dr. Greg Wettstein" Message-Id: <201303260810.r2Q8AbAm011581@wind.enjellic.com> X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012) To: xen-devel@lists.xen.org, xen-users@lists.xen.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Tue, 26 Mar 2013 03:10:38 -0500 (CDT) X-Mailman-Approved-At: Tue, 26 Mar 2013 11:29:27 +0000 Cc: scst-devel@lists.sourceforge.net Subject: [Xen-users] Release 0.2.0 of Xen-SAN. X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: xen@enjellic.com List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 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 Good morning, Izzy and I hope the week is going well for everyone. He is curled up on the couch right now recovering from about 22 miles of cross-country skiing in West-Central Minnesota over the weekend. Izzy asked me to let everyone know that a new release of the Xen-SAN package is available. It can be downloaded from the following URL: ftp://ftp.enjellic.com/pub/xen/Xen-SAN-0.2.0.tar.gz This package implements functionality which allows Xen domU guests to be first class entities in an iSCSI based SAN. The major change in this version is that the block-iscsi hotplug script should drop directly into a 4.2.x implementation of a Linux based Xen implementation without any other changes. The previous version required support from the 'block' hotplug script. This implementation has been extensively tested with a Linux based SCST storage target stack in a Linux dom0 environment with iSCSI client support. There is extensive documentation in the README file included in the package. Best wishes for a productive week to everyone. Greg and Izzy As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "We came, we saw, we fought, we conquered the multi-headed beast which is storage for isochronous video delivery." Any questions on the project summary? -- Dr. Greg Wettstein Resurrection _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 11:40:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11:40: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 1UKSE7-0000tr-9r; Tue, 26 Mar 2013 11:39:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKSE5-0000tg-U3 for xen-users@lists.xen.org; Tue, 26 Mar 2013 11:39:38 +0000 Received: from [85.158.143.99:41533] by server-2.bemta-4.messagelabs.com id F6/C1-12656-9F881515; Tue, 26 Mar 2013 11:39:37 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1364297976!24119326!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8023 invoked from network); 26 Mar 2013 11:39:36 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 11:39:36 -0000 Received: by mail-wi0-f173.google.com with SMTP id ez12so637144wid.6 for ; Tue, 26 Mar 2013 04:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=skrrCvK4ulA3TfSvAnfPYa4x08pDXFaWuKRD+kw70UI=; b=bVBfjwPrsjyevk0Qpocww1neYqLdZB58qbUU0gZF6mizkmcfDfH2vZJ67X0/UvTLnR 80splw8JiqCBji7C3DInnRnYMFtzPCa4ulGwfcv3XLUFpKVHPhGp0unnPvSstlfZWIrl APUwBSyfae77HF9qWaBu5xeMq8qhtMQfa6XpFtx0DxHTZQcGbr7XavAVV+z7H3mamFsM 8Pz+/HEgXez6/lSvdTB0NddPAf+t6umQyApTrY/FPQvXolV0liWjEsTMCm22PfA6bPzx M7DI9aEMw5ps+o/0eyrv3diQo6bpZtx6U58Un/+U1+H1CJDEHB69o1o/1eJh1X4V7cNs 28Vw== MIME-Version: 1.0 X-Received: by 10.194.88.138 with SMTP id bg10mr17847294wjb.13.1364297976437; Tue, 26 Mar 2013 04:39:36 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Tue, 26 Mar 2013 04:39:36 -0700 (PDT) Date: Tue, 26 Mar 2013 12:39:36 +0100 Message-ID: From: Fabrice Delente To: "xen-users@lists.xen.org" Subject: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============8915459693556317087==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8915459693556317087== Content-Type: multipart/alternative; boundary=047d7bfd056240e2de04d8d260df --047d7bfd056240e2de04d8d260df Content-Type: text/plain; charset=UTF-8 Hello. I have this problem on my Xen server: I have 4 domains running; each of them has its own static IP adress. I can VNC onto these domains with their IP adress; but I can't use xen-server:5900 or 5901 etc. to VNC into them. In fact, I can't even ping the server. I can log onto the physical keyboard of the server, but I can't ssh into the server, even though sshd is running. What can explain this? Thanks. -- F. Delente --047d7bfd056240e2de04d8d260df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello.

    I have t= his problem on my Xen server: I have 4 domains running; each of them has it= s own static IP adress.

    I can VNC onto these domains with thei= r IP adress; but I can't use xen-server:5900 or 5901 etc. to VNC into t= hem.

    In fact, I can't even ping the server. I can log onto the phy= sical keyboard of the server, but I can't ssh into the server, even tho= ugh sshd is running.

    What can explain this?

    Thank= s.

    --
    F. Delente
    --047d7bfd056240e2de04d8d260df-- --===============8915459693556317087== 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 --===============8915459693556317087==-- From xen-users-bounces@lists.xen.org Tue Mar 26 11:40:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 11:40: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 1UKSE7-0000tr-9r; Tue, 26 Mar 2013 11:39:39 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKSE5-0000tg-U3 for xen-users@lists.xen.org; Tue, 26 Mar 2013 11:39:38 +0000 Received: from [85.158.143.99:41533] by server-2.bemta-4.messagelabs.com id F6/C1-12656-9F881515; Tue, 26 Mar 2013 11:39:37 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1364297976!24119326!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8023 invoked from network); 26 Mar 2013 11:39:36 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 11:39:36 -0000 Received: by mail-wi0-f173.google.com with SMTP id ez12so637144wid.6 for ; Tue, 26 Mar 2013 04:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=skrrCvK4ulA3TfSvAnfPYa4x08pDXFaWuKRD+kw70UI=; b=bVBfjwPrsjyevk0Qpocww1neYqLdZB58qbUU0gZF6mizkmcfDfH2vZJ67X0/UvTLnR 80splw8JiqCBji7C3DInnRnYMFtzPCa4ulGwfcv3XLUFpKVHPhGp0unnPvSstlfZWIrl APUwBSyfae77HF9qWaBu5xeMq8qhtMQfa6XpFtx0DxHTZQcGbr7XavAVV+z7H3mamFsM 8Pz+/HEgXez6/lSvdTB0NddPAf+t6umQyApTrY/FPQvXolV0liWjEsTMCm22PfA6bPzx M7DI9aEMw5ps+o/0eyrv3diQo6bpZtx6U58Un/+U1+H1CJDEHB69o1o/1eJh1X4V7cNs 28Vw== MIME-Version: 1.0 X-Received: by 10.194.88.138 with SMTP id bg10mr17847294wjb.13.1364297976437; Tue, 26 Mar 2013 04:39:36 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Tue, 26 Mar 2013 04:39:36 -0700 (PDT) Date: Tue, 26 Mar 2013 12:39:36 +0100 Message-ID: From: Fabrice Delente To: "xen-users@lists.xen.org" Subject: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============8915459693556317087==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8915459693556317087== Content-Type: multipart/alternative; boundary=047d7bfd056240e2de04d8d260df --047d7bfd056240e2de04d8d260df Content-Type: text/plain; charset=UTF-8 Hello. I have this problem on my Xen server: I have 4 domains running; each of them has its own static IP adress. I can VNC onto these domains with their IP adress; but I can't use xen-server:5900 or 5901 etc. to VNC into them. In fact, I can't even ping the server. I can log onto the physical keyboard of the server, but I can't ssh into the server, even though sshd is running. What can explain this? Thanks. -- F. Delente --047d7bfd056240e2de04d8d260df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hello.

    I have t= his problem on my Xen server: I have 4 domains running; each of them has it= s own static IP adress.

    I can VNC onto these domains with thei= r IP adress; but I can't use xen-server:5900 or 5901 etc. to VNC into t= hem.

    In fact, I can't even ping the server. I can log onto the phy= sical keyboard of the server, but I can't ssh into the server, even tho= ugh sshd is running.

    What can explain this?

    Thank= s.

    --
    F. Delente
    --047d7bfd056240e2de04d8d260df-- --===============8915459693556317087== 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 --===============8915459693556317087==-- From xen-users-bounces@lists.xen.org Tue Mar 26 12:20:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 12:20: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 1UKSqd-0002vJ-Ix; Tue, 26 Mar 2013 12:19:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKSqc-0002vB-J7 for xen-users@lists.xen.org; Tue, 26 Mar 2013 12:19:26 +0000 Received: from [85.158.138.51:56875] by server-6.bemta-3.messagelabs.com id 40/91-11048-D4291515; Tue, 26 Mar 2013 12:19:25 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1364300365!8823621!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32364 invoked from network); 26 Mar 2013 12:19:25 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 12:19:25 -0000 Received: by mail-wi0-f177.google.com with SMTP id hm14so695343wib.10 for ; Tue, 26 Mar 2013 05:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9lv8nIImiS0qceAUrpuwGKmnNTboiL8OU5Eipz8wuDY=; b=tAujesXNy19vF4KCTsBx4AZtM1nKCGZsLNT3u3AAyl0eEww3doxeBGOmdt0/0QpsGf whxbgnO+A7Uu28ROy2gFVJpyYkjyj27+IN0q5jYv5k0jEAyQSniDeDHanPineOF7AE4A NqZlWvbTVCxfhYdzwsVn6yGZ4BgSKc+QAkPaku18YCkOXU69Ff0ChxKqWeD6rtLE1m64 HoakQNOEwFQHJYw6AqHYyGvCKOyMBEofESYWbDm9ek9Eh+/nbDX0AtLvAIAAnVVh3AaZ HlXApQtvgwZrq6C+SyfBSJ2B0S/X2GaNCoKEofvoL5KyRvOgmIyIXX+Pcp8+EPZE6R2T 5MLw== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr24198369wjr.33.1364300364905; Tue, 26 Mar 2013 05:19:24 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Tue, 26 Mar 2013 05:19:24 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Tue, 26 Mar 2013 05:19:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 08:19:24 -0400 Message-ID: From: Sean Greenslade To: Fabrice Delente Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============2640342940218706529==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2640342940218706529== Content-Type: multipart/alternative; boundary=047d7b86e2f89e09c904d8d2eeae --047d7b86e2f89e09c904d8d2eeae Content-Type: text/plain; charset=UTF-8 On Mar 26, 2013 7:42 AM, "Fabrice Delente" wrote: > > Hello. > > I have this problem on my Xen server: I have 4 domains running; each of them has its own static IP adress. > > I can VNC onto these domains with their IP adress; but I can't use xen-server:5900 or 5901 etc. to VNC into them. > > In fact, I can't even ping the server. I can log onto the physical keyboard of the server, but I can't ssh into the server, even though sshd is running. > > What can explain this? > > Thanks. > > -- > F. Delente > > First blush would have me assume you either have networking misconfigured on dom0 or a fascist firewall on dom0. Can you confirm that dom0 has an ip address? --047d7b86e2f89e09c904d8d2eeae Content-Type: text/html; charset=UTF-8


    On Mar 26, 2013 7:42 AM, "Fabrice Delente" <delentef@gmail.com> wrote:
    >
    > Hello.
    >
    > I have this problem on my Xen server: I have 4 domains running; each of them has its own static IP adress.
    >
    > I can VNC onto these domains with their IP adress; but I can't use xen-server:5900 or 5901 etc. to VNC into them.
    >
    > In fact, I can't even ping the server. I can log onto the physical keyboard of the server, but I can't ssh into the server, even though sshd is running.
    >
    > What can explain this?
    >
    > Thanks.
    >
    > --
    > F. Delente
    >
    >

    First blush would have me assume you either have networking misconfigured on dom0 or a fascist firewall on dom0. Can you confirm that dom0 has an ip address?

    --047d7b86e2f89e09c904d8d2eeae-- --===============2640342940218706529== 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 --===============2640342940218706529==-- From xen-users-bounces@lists.xen.org Tue Mar 26 12:20:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 12:20: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 1UKSqd-0002vJ-Ix; Tue, 26 Mar 2013 12:19:27 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKSqc-0002vB-J7 for xen-users@lists.xen.org; Tue, 26 Mar 2013 12:19:26 +0000 Received: from [85.158.138.51:56875] by server-6.bemta-3.messagelabs.com id 40/91-11048-D4291515; Tue, 26 Mar 2013 12:19:25 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1364300365!8823621!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32364 invoked from network); 26 Mar 2013 12:19:25 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 12:19:25 -0000 Received: by mail-wi0-f177.google.com with SMTP id hm14so695343wib.10 for ; Tue, 26 Mar 2013 05:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9lv8nIImiS0qceAUrpuwGKmnNTboiL8OU5Eipz8wuDY=; b=tAujesXNy19vF4KCTsBx4AZtM1nKCGZsLNT3u3AAyl0eEww3doxeBGOmdt0/0QpsGf whxbgnO+A7Uu28ROy2gFVJpyYkjyj27+IN0q5jYv5k0jEAyQSniDeDHanPineOF7AE4A NqZlWvbTVCxfhYdzwsVn6yGZ4BgSKc+QAkPaku18YCkOXU69Ff0ChxKqWeD6rtLE1m64 HoakQNOEwFQHJYw6AqHYyGvCKOyMBEofESYWbDm9ek9Eh+/nbDX0AtLvAIAAnVVh3AaZ HlXApQtvgwZrq6C+SyfBSJ2B0S/X2GaNCoKEofvoL5KyRvOgmIyIXX+Pcp8+EPZE6R2T 5MLw== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr24198369wjr.33.1364300364905; Tue, 26 Mar 2013 05:19:24 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Tue, 26 Mar 2013 05:19:24 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Tue, 26 Mar 2013 05:19:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 08:19:24 -0400 Message-ID: From: Sean Greenslade To: Fabrice Delente Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============2640342940218706529==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2640342940218706529== Content-Type: multipart/alternative; boundary=047d7b86e2f89e09c904d8d2eeae --047d7b86e2f89e09c904d8d2eeae Content-Type: text/plain; charset=UTF-8 On Mar 26, 2013 7:42 AM, "Fabrice Delente" wrote: > > Hello. > > I have this problem on my Xen server: I have 4 domains running; each of them has its own static IP adress. > > I can VNC onto these domains with their IP adress; but I can't use xen-server:5900 or 5901 etc. to VNC into them. > > In fact, I can't even ping the server. I can log onto the physical keyboard of the server, but I can't ssh into the server, even though sshd is running. > > What can explain this? > > Thanks. > > -- > F. Delente > > First blush would have me assume you either have networking misconfigured on dom0 or a fascist firewall on dom0. Can you confirm that dom0 has an ip address? --047d7b86e2f89e09c904d8d2eeae Content-Type: text/html; charset=UTF-8


    On Mar 26, 2013 7:42 AM, "Fabrice Delente" <delentef@gmail.com> wrote:
    >
    > Hello.
    >
    > I have this problem on my Xen server: I have 4 domains running; each of them has its own static IP adress.
    >
    > I can VNC onto these domains with their IP adress; but I can't use xen-server:5900 or 5901 etc. to VNC into them.
    >
    > In fact, I can't even ping the server. I can log onto the physical keyboard of the server, but I can't ssh into the server, even though sshd is running.
    >
    > What can explain this?
    >
    > Thanks.
    >
    > --
    > F. Delente
    >
    >

    First blush would have me assume you either have networking misconfigured on dom0 or a fascist firewall on dom0. Can you confirm that dom0 has an ip address?

    --047d7b86e2f89e09c904d8d2eeae-- --===============2640342940218706529== 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 --===============2640342940218706529==-- From xen-users-bounces@lists.xen.org Tue Mar 26 12:20:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 12:20: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 1UKSr6-0002y0-8D; Tue, 26 Mar 2013 12:19:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKSam-0002cE-CN for xen-users@lists.xensource.com; Tue, 26 Mar 2013 12:03:04 +0000 Received: from [85.158.143.99:40301] by server-1.bemta-4.messagelabs.com id 82/C6-06203-77E81515; Tue, 26 Mar 2013 12:03:03 +0000 X-Env-Sender: hex445@gmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1364299353!20456240!1 X-Originating-IP: [209.85.220.194] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25816 invoked from network); 26 Mar 2013 12:02:35 -0000 Received: from mail-vc0-f194.google.com (HELO mail-vc0-f194.google.com) (209.85.220.194) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 12:02:35 -0000 Received: by mail-vc0-f194.google.com with SMTP id gf12so1888405vcb.9 for ; Tue, 26 Mar 2013 05:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=rXQn0r8o59J/e9Niw+iVxz5UA+GM3Xurt4THAOjVMlA=; b=wAoqSJKD9Lm4n2gJ/L1DZh1i0MVY3rtZoS0oZ9uZxQU4iATGXcY6kxJ3bEfsr6Pc8u vvdP4BCSDsmXZsTWHQWzRd+Ij3kh/Boa3Fzeth6u4wWUnEPHcHCOwRLdGY0kIxYJ8IjT Vv9c7TnwwzLFJTn0a2j+4oZcnxJ0i875dZTc4lQDLWtiqNVl19sgcPlg0WJw5gZhds4I FDPE/wDwEoIu5WKOv3pDw32BZhw4ozlz1T4/cvY9Ue/qjeoZ6ik9tX8I35pzxsirznzf eEn4nZAjpXwfCTgyKu/QZTJUrMFANLOoYPOz/xh+VtEvrYCUUk9DrENBSUmqD/egADWd GP7w== MIME-Version: 1.0 X-Received: by 10.52.108.10 with SMTP id hg10mr16081451vdb.34.1364299353677; Tue, 26 Mar 2013 05:02:33 -0700 (PDT) Received: by 10.58.189.162 with HTTP; Tue, 26 Mar 2013 05:02:33 -0700 (PDT) Date: Tue, 26 Mar 2013 13:02:33 +0100 Message-ID: From: T To: xen-users@lists.xensource.com X-Mailman-Approved-At: Tue, 26 Mar 2013 12:19:54 +0000 Subject: [Xen-users] Possible memory leak in qemu-dm when Xen USB Passthrough is used X-BeenThere: xen-users@lists.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, [please CC me] Recently I have reported a Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703430 Possible memory leak in qemu-dm when Xen USB Passthrough is used I wonder if somebody encountered such behaviour or how can I debug it farther ? Best Regards, T _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 12:20:32 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 12:20: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 1UKSr6-0002y0-8D; Tue, 26 Mar 2013 12:19:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKSam-0002cE-CN for xen-users@lists.xensource.com; Tue, 26 Mar 2013 12:03:04 +0000 Received: from [85.158.143.99:40301] by server-1.bemta-4.messagelabs.com id 82/C6-06203-77E81515; Tue, 26 Mar 2013 12:03:03 +0000 X-Env-Sender: hex445@gmail.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1364299353!20456240!1 X-Originating-IP: [209.85.220.194] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25816 invoked from network); 26 Mar 2013 12:02:35 -0000 Received: from mail-vc0-f194.google.com (HELO mail-vc0-f194.google.com) (209.85.220.194) by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 12:02:35 -0000 Received: by mail-vc0-f194.google.com with SMTP id gf12so1888405vcb.9 for ; Tue, 26 Mar 2013 05:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=rXQn0r8o59J/e9Niw+iVxz5UA+GM3Xurt4THAOjVMlA=; b=wAoqSJKD9Lm4n2gJ/L1DZh1i0MVY3rtZoS0oZ9uZxQU4iATGXcY6kxJ3bEfsr6Pc8u vvdP4BCSDsmXZsTWHQWzRd+Ij3kh/Boa3Fzeth6u4wWUnEPHcHCOwRLdGY0kIxYJ8IjT Vv9c7TnwwzLFJTn0a2j+4oZcnxJ0i875dZTc4lQDLWtiqNVl19sgcPlg0WJw5gZhds4I FDPE/wDwEoIu5WKOv3pDw32BZhw4ozlz1T4/cvY9Ue/qjeoZ6ik9tX8I35pzxsirznzf eEn4nZAjpXwfCTgyKu/QZTJUrMFANLOoYPOz/xh+VtEvrYCUUk9DrENBSUmqD/egADWd GP7w== MIME-Version: 1.0 X-Received: by 10.52.108.10 with SMTP id hg10mr16081451vdb.34.1364299353677; Tue, 26 Mar 2013 05:02:33 -0700 (PDT) Received: by 10.58.189.162 with HTTP; Tue, 26 Mar 2013 05:02:33 -0700 (PDT) Date: Tue, 26 Mar 2013 13:02:33 +0100 Message-ID: From: T To: xen-users@lists.xensource.com X-Mailman-Approved-At: Tue, 26 Mar 2013 12:19:54 +0000 Subject: [Xen-users] Possible memory leak in qemu-dm when Xen USB Passthrough is used X-BeenThere: xen-users@lists.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, [please CC me] Recently I have reported a Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703430 Possible memory leak in qemu-dm when Xen USB Passthrough is used I wonder if somebody encountered such behaviour or how can I debug it farther ? Best Regards, T _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 12:37:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 12:37: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 1UKT70-0003em-Am; Tue, 26 Mar 2013 12:36:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKT6y-0003eg-QM for xen-users@lists.xen.org; Tue, 26 Mar 2013 12:36:21 +0000 Received: from [85.158.139.83:16717] by server-15.bemta-5.messagelabs.com id 3E/FF-22815-44691515; Tue, 26 Mar 2013 12:36:20 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1364301379!26963090!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=2.8 required=7.0 tests=HTML_10_20,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26159 invoked from network); 26 Mar 2013 12:36:19 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 12:36:19 -0000 Received: by mail-wi0-f177.google.com with SMTP id hm14so725168wib.10 for ; Tue, 26 Mar 2013 05:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3XcGtQkyP/9oLeBbknqjBd5lg3EHeZmbt1u2SI4mYOM=; b=m7Utz/BDXGFrjoQXVpIcos4fZhspRJQvl9+G38hzgbSDRJp5hiN0dQczonFg0rSzgV bd+cTixi3iKUQ5Ya9hzDHeCNCNa98awTtrU+uadAzvSwZ2QWB/d/RSukZL6xlspRMMLm THOilIkFzHg2xWvbrnDj+hbQ2ogaHlyH1APatodZlZFaAL6d/P/6MrP2kXIDwKausi5j 74EdPXSyQmAbGizlmPf42hwLC1KmLk9oTl5LwoPUNJCLrH3jffhlVvN6q6kfkBhdkzTd prLSubgFXvoblsbkrsvTvASukZvRcGo8hZUbF9qbJAC5e401L6eTbtu80F2xCsdpPKDp U8mA== MIME-Version: 1.0 X-Received: by 10.194.21.233 with SMTP id y9mr24483954wje.47.1364301378797; Tue, 26 Mar 2013 05:36:18 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Tue, 26 Mar 2013 05:36:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 13:36:18 +0100 Message-ID: From: Fabrice Delente To: Sean Greenslade Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============6650043342600026461==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6650043342600026461== Content-Type: multipart/alternative; boundary=047d7b5d27740ccb1304d8d32b58 --047d7b5d27740ccb1304d8d32b58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes it has; I can usually ssh into it, but after having destroyed an unresponsive domain it stopped responding to net connections on its IP.=E2= =80=8B --047d7b5d27740ccb1304d8d32b58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Yes it has; I can usually ssh into it, but after having de= stroyed an unresponsive domain it stopped responding to net connections on = its IP.=E2=80=8B
    --047d7b5d27740ccb1304d8d32b58-- --===============6650043342600026461== 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 --===============6650043342600026461==-- From xen-users-bounces@lists.xen.org Tue Mar 26 12:37:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 12:37: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 1UKT70-0003em-Am; Tue, 26 Mar 2013 12:36:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKT6y-0003eg-QM for xen-users@lists.xen.org; Tue, 26 Mar 2013 12:36:21 +0000 Received: from [85.158.139.83:16717] by server-15.bemta-5.messagelabs.com id 3E/FF-22815-44691515; Tue, 26 Mar 2013 12:36:20 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1364301379!26963090!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=2.8 required=7.0 tests=HTML_10_20,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26159 invoked from network); 26 Mar 2013 12:36:19 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 12:36:19 -0000 Received: by mail-wi0-f177.google.com with SMTP id hm14so725168wib.10 for ; Tue, 26 Mar 2013 05:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3XcGtQkyP/9oLeBbknqjBd5lg3EHeZmbt1u2SI4mYOM=; b=m7Utz/BDXGFrjoQXVpIcos4fZhspRJQvl9+G38hzgbSDRJp5hiN0dQczonFg0rSzgV bd+cTixi3iKUQ5Ya9hzDHeCNCNa98awTtrU+uadAzvSwZ2QWB/d/RSukZL6xlspRMMLm THOilIkFzHg2xWvbrnDj+hbQ2ogaHlyH1APatodZlZFaAL6d/P/6MrP2kXIDwKausi5j 74EdPXSyQmAbGizlmPf42hwLC1KmLk9oTl5LwoPUNJCLrH3jffhlVvN6q6kfkBhdkzTd prLSubgFXvoblsbkrsvTvASukZvRcGo8hZUbF9qbJAC5e401L6eTbtu80F2xCsdpPKDp U8mA== MIME-Version: 1.0 X-Received: by 10.194.21.233 with SMTP id y9mr24483954wje.47.1364301378797; Tue, 26 Mar 2013 05:36:18 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Tue, 26 Mar 2013 05:36:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 13:36:18 +0100 Message-ID: From: Fabrice Delente To: Sean Greenslade Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============6650043342600026461==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6650043342600026461== Content-Type: multipart/alternative; boundary=047d7b5d27740ccb1304d8d32b58 --047d7b5d27740ccb1304d8d32b58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes it has; I can usually ssh into it, but after having destroyed an unresponsive domain it stopped responding to net connections on its IP.=E2= =80=8B --047d7b5d27740ccb1304d8d32b58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Yes it has; I can usually ssh into it, but after having de= stroyed an unresponsive domain it stopped responding to net connections on = its IP.=E2=80=8B
    --047d7b5d27740ccb1304d8d32b58-- --===============6650043342600026461== 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 --===============6650043342600026461==-- From xen-users-bounces@lists.xen.org Tue Mar 26 12:45:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 12:45: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 1UKTFI-0003uQ-KC; Tue, 26 Mar 2013 12:44:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKTFG-0003uL-Ov for xen-users@lists.xen.org; Tue, 26 Mar 2013 12:44:54 +0000 Received: from [85.158.137.99:50009] by server-14.bemta-3.messagelabs.com id B3/21-27076-14891515; Tue, 26 Mar 2013 12:44:49 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1364301782!17754911!1 X-Originating-IP: [209.85.212.194] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5622 invoked from network); 26 Mar 2013 12:43:03 -0000 Received: from mail-wi0-f194.google.com (HELO mail-wi0-f194.google.com) (209.85.212.194) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 12:43:03 -0000 Received: by mail-wi0-f194.google.com with SMTP id hm11so240365wib.9 for ; Tue, 26 Mar 2013 05:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=gnYwMSNX8GmPdITtpgQl9exwjQg3SCMvPw8+pYl1rV8=; b=nmhfs2Pg41e5+Vle0yt0utDHsWN8BYOY8tMeJCpEdl8sLp4DuzMWfS7qA1tXTMRhBd hjkLmYyJFw7lP1KbNLDjSO+0HOMl43PsEYXrVSCXPkaSOQztny1f4KTBer2ImnwFO2K6 T9sWf1wN7h8+UezWp1MZ9Etl4vEKJOKiHDJ5NuL5Q9gIVnuXp6JZbgcyewxDI6UhFLHX h3WdtsoJJ2I0jZORhhxZkFK+mUFFvRwdlSkvTg6bxN5EZq2ZNGy7uGBWSVgCTsX5Phcs bivFw8HX4wN1hnf/vmtBIlMa0dtLeTymE+K9gP6W/KRsGwdkPF4lLrpeme7lg5AdkTqZ CevQ== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr2898755wiv.27.1364301782525; Tue, 26 Mar 2013 05:43:02 -0700 (PDT) Received: by 10.194.91.238 with HTTP; Tue, 26 Mar 2013 05:43:02 -0700 (PDT) Date: Tue, 26 Mar 2013 20:43:02 +0800 Message-ID: From: Cao Wenz To: xen-users@lists.xen.org Subject: [Xen-users] VM hangs during bootup when use Tap2 disk type X-BeenThere: xen-users@lists.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 When I use "tap" config, the VM is OK. Than I replace disk config "tap" with "tap2", And VM hangs during bootup. I use "xm list" to list vm and find the time of hanged VM is growing fast. After VM hangs, we can not create other VMs. It prints "Error: Device 0 (vif) could not be connected. Hotplug scripts not working" . How can I fix it? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 12:45:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 12:45: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 1UKTFI-0003uQ-KC; Tue, 26 Mar 2013 12:44:56 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKTFG-0003uL-Ov for xen-users@lists.xen.org; Tue, 26 Mar 2013 12:44:54 +0000 Received: from [85.158.137.99:50009] by server-14.bemta-3.messagelabs.com id B3/21-27076-14891515; Tue, 26 Mar 2013 12:44:49 +0000 X-Env-Sender: wenzcao@gmail.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1364301782!17754911!1 X-Originating-IP: [209.85.212.194] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5622 invoked from network); 26 Mar 2013 12:43:03 -0000 Received: from mail-wi0-f194.google.com (HELO mail-wi0-f194.google.com) (209.85.212.194) by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 12:43:03 -0000 Received: by mail-wi0-f194.google.com with SMTP id hm11so240365wib.9 for ; Tue, 26 Mar 2013 05:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=gnYwMSNX8GmPdITtpgQl9exwjQg3SCMvPw8+pYl1rV8=; b=nmhfs2Pg41e5+Vle0yt0utDHsWN8BYOY8tMeJCpEdl8sLp4DuzMWfS7qA1tXTMRhBd hjkLmYyJFw7lP1KbNLDjSO+0HOMl43PsEYXrVSCXPkaSOQztny1f4KTBer2ImnwFO2K6 T9sWf1wN7h8+UezWp1MZ9Etl4vEKJOKiHDJ5NuL5Q9gIVnuXp6JZbgcyewxDI6UhFLHX h3WdtsoJJ2I0jZORhhxZkFK+mUFFvRwdlSkvTg6bxN5EZq2ZNGy7uGBWSVgCTsX5Phcs bivFw8HX4wN1hnf/vmtBIlMa0dtLeTymE+K9gP6W/KRsGwdkPF4lLrpeme7lg5AdkTqZ CevQ== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr2898755wiv.27.1364301782525; Tue, 26 Mar 2013 05:43:02 -0700 (PDT) Received: by 10.194.91.238 with HTTP; Tue, 26 Mar 2013 05:43:02 -0700 (PDT) Date: Tue, 26 Mar 2013 20:43:02 +0800 Message-ID: From: Cao Wenz To: xen-users@lists.xen.org Subject: [Xen-users] VM hangs during bootup when use Tap2 disk type X-BeenThere: xen-users@lists.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 When I use "tap" config, the VM is OK. Than I replace disk config "tap" with "tap2", And VM hangs during bootup. I use "xm list" to list vm and find the time of hanged VM is growing fast. After VM hangs, we can not create other VMs. It prints "Error: Device 0 (vif) could not be connected. Hotplug scripts not working" . How can I fix it? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 15:30:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 15:30: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 1UKVoG-0001ao-TW; Tue, 26 Mar 2013 15:29:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKVoF-0001af-MF for xen-users@lists.xen.org; Tue, 26 Mar 2013 15:29:11 +0000 Received: from [85.158.139.211:25474] by server-3.bemta-5.messagelabs.com id FE/0D-17256-6CEB1515; Tue, 26 Mar 2013 15:29:10 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1364311749!18348033!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8026 invoked from network); 26 Mar 2013 15:29:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 15:29:09 -0000 X-IronPort-AV: E=Sophos;i="4.84,913,1355097600"; d="scan'208,223";a="2925604" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Mar 2013 15:29:10 +0000 Received: from [192.168.1.30] (10.30.249.104) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 26 Mar 2013 15:29:08 +0000 Message-ID: <5151BEC3.3030809@citrix.com> Date: Tue, 26 Mar 2013 16:29:07 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Colin Percival References: <51516B06.8080704@citrix.com> <51516CAA.3040802@freebsd.org> <51517407.8040406@citrix.com> <5151751C.5080501@freebsd.org> In-Reply-To: <5151751C.5080501@freebsd.org> Content-Type: multipart/mixed; boundary="------------050003050001070201070206" Cc: tech mailinglists , xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@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 --------------050003050001070201070206 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On 26/03/13 11:14, Colin Percival wrote: > On 03/26/13 03:10, Roger Pau Monné wrote: >> On 26/03/13 10:38, Colin Percival wrote: >>> On 03/26/13 02:31, Roger Pau Monné wrote: >>>> Is Xen i386 PV broken? >>> >>> Not completely broken, but it's certainly not in a good state. I believe >>> it's broken with SMP, for example -- if the "crashed on cpu#7" in your >>> output means cpu#7 from the guest, it would certainly explain things. >> >> My guest only has one vcpu (vcpu#0): > > Ok, I wasn't sure how to parse that output. > >>> HVM is the way to go with FreeBSD/Xen. >> >> Yes, I'm already working on that, and got vector callbacks working on >> both i386 and amd64 HVM guests, thanks to Justin T. Gibbs patch. Now I >> was trying to boot a PV guest to see how much breakage this change >> introduced to PV, but I'm not able to make it work, even without my patches. >> >> I've replied to this xen-users thread because the author seem to have a >> working FreeBSD DomU PV guest, and I was wondering how he did it. From >> my POV it seems like PV guests hasn't been working for a long time, >> since Xen 3.3 dropped support for non-PAE guests, and the FreeBSD kernel >> is detected as non-PAE. > > I had FreeBSD 8.2-RELEASE and a 9.0-CURRENT @ January 2011 running with PV > in EC2 (http://www.daemonology.net/freebsd-on-ec2/, look for "t1.micro > instances only") and that used PAE. But it's entirely likely that something > got broken in the past two years and nobody noticed because nobody ever uses > PV... I've checked and 9.1 is working OK (at least boots and seems to be functional). I've also found the reason why HEAD doesn't work, and it's probably caused by the switch to clang, which seems to have problems with the ELFNOTE macro, here is a patch that makes i386 PV boot again: --- diff --git a/sys/i386/include/asmacros.h b/sys/i386/include/asmacros.h index c1c3f64..474dfe1 100644 --- a/sys/i386/include/asmacros.h +++ b/sys/i386/include/asmacros.h @@ -211,7 +211,7 @@ #ifdef __STDC__ #define ELFNOTE(name, type, desctype, descdata...) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ @@ -223,7 +223,7 @@ .popsection #else /* !__STDC__, i.e. -traditional */ #define ELFNOTE(name, type, desctype, descdata) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ --- But there's even more problems... rtc0: [XEN] xen_rtc_gettime rtc0: [XEN] xen_rtc_gettime: wallclock 1364233979 sec; 999999989 nsec rtc0: [XEN] xen_rtc_gettime: uptime 76890 sec; 166126554 nsec rtc0: [XEN] xen_rtc_gettime: TOD 1364310870 sec; 166126543 nsec start_init: trying /sbin/init pid 26 (sh), uid 0: exited on signal 4 panic: removing pages from non-current pmap cpuid = 0 KDB: enter: panic [ thread pid 26 tid 100037 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 26 tid 100037 td 0xc25e4900 kdb_enter(c03f8ad8,c03f8ad8,c04321de,ccf7699c,c04321de,...) at kdb_enter+0x3d/frame 0xccf76930 kassert_panic(c047c478,100,c04321de,ccf7699c,ccf7699c,...) at kassert_panic+0x232/frame 0xccf7696c kassert_panic(c04321de,c0431504,e0a,7bc,c044fe94,...) at kassert_panic+0xea/frame 0xccf76990 pmap_remove_pages(c2427638,c064bd74,8,c2427638,c248c8b8,...) at pmap_remove_pages+0xb3/frame 0xccf76a00 vmspace_exit(c25e4900,0,c03f2588,140,4,...) at vmspace_exit+0xb1/frame 0xccf76a28 exit1(c25e4900,4,1a,c248cacc,0,...) at exit1+0x654/frame 0xccf76a88 sigexit(c25e4900,4,c03f8b70,b0a,c0153a4f,...) at sigexit+0xc7f/frame 0xccf76c20 postsig(4,0,c03fee92,10d,0,...) at postsig+0x3b2/frame 0xccf76cdc ast(ccf76d18) at ast+0x388/frame 0xccf76d0c vm86_biosret() at vm86_biosret+0x9c/frame 0xbf7fcba8 --------------050003050001070201070206 Content-Type: text/plain; charset="UTF-8"; x-mac-type=0; x-mac-creator=0; name="0001-xen-fix-ELFNOTE-macro.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-xen-fix-ELFNOTE-macro.patch" >From ef73078b37f283401159119538b8ac85bbd512d6 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Tue, 26 Mar 2013 12:39:58 +0100 Subject: [PATCH] xen: fix ELFNOTE macro Add an empty flag and the corresponding type of section to pushsection. --- sys/i386/include/asmacros.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sys/i386/include/asmacros.h b/sys/i386/include/asmacros.h index c1c3f64..474dfe1 100644 --- a/sys/i386/include/asmacros.h +++ b/sys/i386/include/asmacros.h @@ -211,7 +211,7 @@ #ifdef __STDC__ #define ELFNOTE(name, type, desctype, descdata...) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ @@ -223,7 +223,7 @@ .popsection #else /* !__STDC__, i.e. -traditional */ #define ELFNOTE(name, type, desctype, descdata) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ -- 1.7.7.5 (Apple Git-26) --------------050003050001070201070206 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 --------------050003050001070201070206-- From xen-users-bounces@lists.xen.org Tue Mar 26 15:30:08 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 15:30: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 1UKVoG-0001ao-TW; Tue, 26 Mar 2013 15:29:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKVoF-0001af-MF for xen-users@lists.xen.org; Tue, 26 Mar 2013 15:29:11 +0000 Received: from [85.158.139.211:25474] by server-3.bemta-5.messagelabs.com id FE/0D-17256-6CEB1515; Tue, 26 Mar 2013 15:29:10 +0000 X-Env-Sender: roger.pau@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1364311749!18348033!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8026 invoked from network); 26 Mar 2013 15:29:09 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2013 15:29:09 -0000 X-IronPort-AV: E=Sophos;i="4.84,913,1355097600"; d="scan'208,223";a="2925604" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 26 Mar 2013 15:29:10 +0000 Received: from [192.168.1.30] (10.30.249.104) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 26 Mar 2013 15:29:08 +0000 Message-ID: <5151BEC3.3030809@citrix.com> Date: Tue, 26 Mar 2013 16:29:07 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Colin Percival References: <51516B06.8080704@citrix.com> <51516CAA.3040802@freebsd.org> <51517407.8040406@citrix.com> <5151751C.5080501@freebsd.org> In-Reply-To: <5151751C.5080501@freebsd.org> Content-Type: multipart/mixed; boundary="------------050003050001070201070206" Cc: tech mailinglists , xen-users , "freebsd-xen@freebsd.org" Subject: Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU X-BeenThere: xen-users@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 --------------050003050001070201070206 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On 26/03/13 11:14, Colin Percival wrote: > On 03/26/13 03:10, Roger Pau Monné wrote: >> On 26/03/13 10:38, Colin Percival wrote: >>> On 03/26/13 02:31, Roger Pau Monné wrote: >>>> Is Xen i386 PV broken? >>> >>> Not completely broken, but it's certainly not in a good state. I believe >>> it's broken with SMP, for example -- if the "crashed on cpu#7" in your >>> output means cpu#7 from the guest, it would certainly explain things. >> >> My guest only has one vcpu (vcpu#0): > > Ok, I wasn't sure how to parse that output. > >>> HVM is the way to go with FreeBSD/Xen. >> >> Yes, I'm already working on that, and got vector callbacks working on >> both i386 and amd64 HVM guests, thanks to Justin T. Gibbs patch. Now I >> was trying to boot a PV guest to see how much breakage this change >> introduced to PV, but I'm not able to make it work, even without my patches. >> >> I've replied to this xen-users thread because the author seem to have a >> working FreeBSD DomU PV guest, and I was wondering how he did it. From >> my POV it seems like PV guests hasn't been working for a long time, >> since Xen 3.3 dropped support for non-PAE guests, and the FreeBSD kernel >> is detected as non-PAE. > > I had FreeBSD 8.2-RELEASE and a 9.0-CURRENT @ January 2011 running with PV > in EC2 (http://www.daemonology.net/freebsd-on-ec2/, look for "t1.micro > instances only") and that used PAE. But it's entirely likely that something > got broken in the past two years and nobody noticed because nobody ever uses > PV... I've checked and 9.1 is working OK (at least boots and seems to be functional). I've also found the reason why HEAD doesn't work, and it's probably caused by the switch to clang, which seems to have problems with the ELFNOTE macro, here is a patch that makes i386 PV boot again: --- diff --git a/sys/i386/include/asmacros.h b/sys/i386/include/asmacros.h index c1c3f64..474dfe1 100644 --- a/sys/i386/include/asmacros.h +++ b/sys/i386/include/asmacros.h @@ -211,7 +211,7 @@ #ifdef __STDC__ #define ELFNOTE(name, type, desctype, descdata...) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ @@ -223,7 +223,7 @@ .popsection #else /* !__STDC__, i.e. -traditional */ #define ELFNOTE(name, type, desctype, descdata) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ --- But there's even more problems... rtc0: [XEN] xen_rtc_gettime rtc0: [XEN] xen_rtc_gettime: wallclock 1364233979 sec; 999999989 nsec rtc0: [XEN] xen_rtc_gettime: uptime 76890 sec; 166126554 nsec rtc0: [XEN] xen_rtc_gettime: TOD 1364310870 sec; 166126543 nsec start_init: trying /sbin/init pid 26 (sh), uid 0: exited on signal 4 panic: removing pages from non-current pmap cpuid = 0 KDB: enter: panic [ thread pid 26 tid 100037 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 26 tid 100037 td 0xc25e4900 kdb_enter(c03f8ad8,c03f8ad8,c04321de,ccf7699c,c04321de,...) at kdb_enter+0x3d/frame 0xccf76930 kassert_panic(c047c478,100,c04321de,ccf7699c,ccf7699c,...) at kassert_panic+0x232/frame 0xccf7696c kassert_panic(c04321de,c0431504,e0a,7bc,c044fe94,...) at kassert_panic+0xea/frame 0xccf76990 pmap_remove_pages(c2427638,c064bd74,8,c2427638,c248c8b8,...) at pmap_remove_pages+0xb3/frame 0xccf76a00 vmspace_exit(c25e4900,0,c03f2588,140,4,...) at vmspace_exit+0xb1/frame 0xccf76a28 exit1(c25e4900,4,1a,c248cacc,0,...) at exit1+0x654/frame 0xccf76a88 sigexit(c25e4900,4,c03f8b70,b0a,c0153a4f,...) at sigexit+0xc7f/frame 0xccf76c20 postsig(4,0,c03fee92,10d,0,...) at postsig+0x3b2/frame 0xccf76cdc ast(ccf76d18) at ast+0x388/frame 0xccf76d0c vm86_biosret() at vm86_biosret+0x9c/frame 0xbf7fcba8 --------------050003050001070201070206 Content-Type: text/plain; charset="UTF-8"; x-mac-type=0; x-mac-creator=0; name="0001-xen-fix-ELFNOTE-macro.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-xen-fix-ELFNOTE-macro.patch" >From ef73078b37f283401159119538b8ac85bbd512d6 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Tue, 26 Mar 2013 12:39:58 +0100 Subject: [PATCH] xen: fix ELFNOTE macro Add an empty flag and the corresponding type of section to pushsection. --- sys/i386/include/asmacros.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sys/i386/include/asmacros.h b/sys/i386/include/asmacros.h index c1c3f64..474dfe1 100644 --- a/sys/i386/include/asmacros.h +++ b/sys/i386/include/asmacros.h @@ -211,7 +211,7 @@ #ifdef __STDC__ #define ELFNOTE(name, type, desctype, descdata...) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ @@ -223,7 +223,7 @@ .popsection #else /* !__STDC__, i.e. -traditional */ #define ELFNOTE(name, type, desctype, descdata) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note ; \ .align 4 ; \ .long 2f - 1f /* namesz */ ; \ .long 4f - 3f /* descsz */ ; \ -- 1.7.7.5 (Apple Git-26) --------------050003050001070201070206 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 --------------050003050001070201070206-- From xen-users-bounces@lists.xen.org Tue Mar 26 22:08:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 22:08: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 1UKc1L-0002nm-BW; Tue, 26 Mar 2013 22:07:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKc1K-0002nh-2Q for xen-users@lists.xen.org; Tue, 26 Mar 2013 22:07:06 +0000 Received: from [85.158.139.83:61265] by server-11.bemta-5.messagelabs.com id B2/B6-27486-80C12515; Tue, 26 Mar 2013 22:07:04 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1364335622!27528877!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14371 invoked from network); 26 Mar 2013 22:07:03 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Mar 2013 22:07:03 -0000 Received: from [200.52.43.60] (port=58672 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UKc1G-0003vk-3O; Tue, 26 Mar 2013 17:07:02 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id 07677A209; Tue, 26 Mar 2013 16:01:39 -0600 (CST) Message-ID: <51521C05.6050404@ondore.com> Date: Tue, 26 Mar 2013 16:07:01 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Cc: T Subject: Re: [Xen-users] Possible memory leak in qemu-dm when Xen USB Passthrough is used X-BeenThere: xen-users@lists.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 Hello. El 26/03/13 06:02, T escribi=F3: > Recently I have reported a Debian bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D703430 > Possible memory leak in qemu-dm when Xen USB Passthrough is used > > I wonder if somebody encountered such behaviour or how can I debug it far= ther ? I have got a issue using USB Passthrough to a HVM Dom0 under Xen 4.0 on = Debian Squeeze. The guest system is Windows XP Pro i386 and the USB = device is a Panasonic PBX KX-TES824, identified by lsusb as "04da:1683 = Panasonic (Matsushita)". The USB is used to set up and configure the = phone switching system, it is supposed to be normally idle. After a few days connected, the USB stops to respond within the guest = system. Need to physically unplug the device and plug it back to = recover, once the condition is triggered. I have made no farther = diagnostics, it was easer to use a dump workaround: since the USB link = is used few times in a year, I do a "xm usb-add" before I use it and a = "xm usb-del" once I finished. Never needed to touch it again. I have not monitored the memory consumption, son I can't tell if this is = about the same memory leak you report. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Mar 26 22:08:17 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 26 Mar 2013 22:08: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 1UKc1L-0002nm-BW; Tue, 26 Mar 2013 22:07:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKc1K-0002nh-2Q for xen-users@lists.xen.org; Tue, 26 Mar 2013 22:07:06 +0000 Received: from [85.158.139.83:61265] by server-11.bemta-5.messagelabs.com id B2/B6-27486-80C12515; Tue, 26 Mar 2013 22:07:04 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1364335622!27528877!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14371 invoked from network); 26 Mar 2013 22:07:03 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Mar 2013 22:07:03 -0000 Received: from [200.52.43.60] (port=58672 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UKc1G-0003vk-3O; Tue, 26 Mar 2013 17:07:02 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id 07677A209; Tue, 26 Mar 2013 16:01:39 -0600 (CST) Message-ID: <51521C05.6050404@ondore.com> Date: Tue, 26 Mar 2013 16:07:01 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Cc: T Subject: Re: [Xen-users] Possible memory leak in qemu-dm when Xen USB Passthrough is used X-BeenThere: xen-users@lists.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 Hello. El 26/03/13 06:02, T escribi=F3: > Recently I have reported a Debian bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D703430 > Possible memory leak in qemu-dm when Xen USB Passthrough is used > > I wonder if somebody encountered such behaviour or how can I debug it far= ther ? I have got a issue using USB Passthrough to a HVM Dom0 under Xen 4.0 on = Debian Squeeze. The guest system is Windows XP Pro i386 and the USB = device is a Panasonic PBX KX-TES824, identified by lsusb as "04da:1683 = Panasonic (Matsushita)". The USB is used to set up and configure the = phone switching system, it is supposed to be normally idle. After a few days connected, the USB stops to respond within the guest = system. Need to physically unplug the device and plug it back to = recover, once the condition is triggered. I have made no farther = diagnostics, it was easer to use a dump workaround: since the USB link = is used few times in a year, I do a "xm usb-add" before I use it and a = "xm usb-del" once I finished. Never needed to touch it again. I have not monitored the memory consumption, son I can't tell if this is = about the same memory leak you report. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 02:33:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 02:33: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 1UKg9r-0000ob-R7; Wed, 27 Mar 2013 02:32:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKg9q-0000oW-Gu for xen-users@lists.xen.org; Wed, 27 Mar 2013 02:32:10 +0000 Received: from [85.158.139.83:49179] by server-12.bemta-5.messagelabs.com id C1/40-11486-92A52515; Wed, 27 Mar 2013 02:32:09 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1364351527!27070433!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4215 invoked from network); 27 Mar 2013 02:32:09 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2013 02:32:09 -0000 Date: Wed, 27 Mar 2013 02:32:06 +0000 From: Mike To: xen-users@lists.xen.org Message-ID: <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 out of debugging ideas. Let me know if you have any. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#20 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 02:33:27 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 02:33: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 1UKg9r-0000ob-R7; Wed, 27 Mar 2013 02:32:11 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKg9q-0000oW-Gu for xen-users@lists.xen.org; Wed, 27 Mar 2013 02:32:10 +0000 Received: from [85.158.139.83:49179] by server-12.bemta-5.messagelabs.com id C1/40-11486-92A52515; Wed, 27 Mar 2013 02:32:09 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1364351527!27070433!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4215 invoked from network); 27 Mar 2013 02:32:09 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2013 02:32:09 -0000 Date: Wed, 27 Mar 2013 02:32:06 +0000 From: Mike To: xen-users@lists.xen.org Message-ID: <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 out of debugging ideas. Let me know if you have any. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#20 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 02:49:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 02:49: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 1UKgPc-00019E-L8; Wed, 27 Mar 2013 02:48:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKgPc-000199-0Y for xen-users@lists.xen.org; Wed, 27 Mar 2013 02:48:28 +0000 Received: from [85.158.138.51:53071] by server-2.bemta-3.messagelabs.com id 93/35-05208-BFD52515; Wed, 27 Mar 2013 02:48:27 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1364352506!20193098!1 X-Originating-IP: [74.125.82.46] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23953 invoked from network); 27 Mar 2013 02:48:26 -0000 Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com) (74.125.82.46) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 02:48:26 -0000 Received: by mail-wg0-f46.google.com with SMTP id l18so70254wgh.25 for ; Tue, 26 Mar 2013 19:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1mt9F4uv3TDNp8LOrZJamXtvSPSXbX+3LKMUhzNg0uw=; b=kHthd4nWMn88bqcuenuvg0jVxzqTZnq8VsuzHMPDSm5qH6mkdKe1gmuIr7zZ+KYZ+m sY8bMyOOHbpYLdYFjn9enGqGk6wA5BpnYEBnZuKAEqP164ZBc6libBfzl1E+oSTZgk2q r41AQJqCTxrVdDTo1Cp5F0Ij9oJBcHb1KyGWN/NB1o74gfhpznByeED+rAA/cpHqYEjt H75+1DATnU9RyeosUPXOtBpvYshtDv6Wv6I5cMG2uwXnsDU4yOE4Kb4h44ufIi9C3rp6 DTNhZy/TyvxeuT8sxxiowXl51RqTEeFXgQzWrEBRNz/T2YXSyYi3NPyWBkp5uZEuO+dz Jjiw== X-Received: by 10.180.78.168 with SMTP id c8mr6763584wix.27.1364352506406; Tue, 26 Mar 2013 19:48:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.139.72 with HTTP; Tue, 26 Mar 2013 19:48:06 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Tue, 26 Mar 2013 22:48:06 -0400 Message-ID: To: Fabrice Delente Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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, Mar 26, 2013 at 8:36 AM, Fabrice Delente wrote: > Yes it has; I can usually ssh into it, but after having destroyed an > unresponsive domain it stopped responding to net connections on its IP. Can you SSH into it from itself (e.g. ssh 127.0.0.1)? Can you ping the domUs from dom0? -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 02:49:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 02:49: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 1UKgPc-00019E-L8; Wed, 27 Mar 2013 02:48:28 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKgPc-000199-0Y for xen-users@lists.xen.org; Wed, 27 Mar 2013 02:48:28 +0000 Received: from [85.158.138.51:53071] by server-2.bemta-3.messagelabs.com id 93/35-05208-BFD52515; Wed, 27 Mar 2013 02:48:27 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-6.tower-174.messagelabs.com!1364352506!20193098!1 X-Originating-IP: [74.125.82.46] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23953 invoked from network); 27 Mar 2013 02:48:26 -0000 Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com) (74.125.82.46) by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 02:48:26 -0000 Received: by mail-wg0-f46.google.com with SMTP id l18so70254wgh.25 for ; Tue, 26 Mar 2013 19:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1mt9F4uv3TDNp8LOrZJamXtvSPSXbX+3LKMUhzNg0uw=; b=kHthd4nWMn88bqcuenuvg0jVxzqTZnq8VsuzHMPDSm5qH6mkdKe1gmuIr7zZ+KYZ+m sY8bMyOOHbpYLdYFjn9enGqGk6wA5BpnYEBnZuKAEqP164ZBc6libBfzl1E+oSTZgk2q r41AQJqCTxrVdDTo1Cp5F0Ij9oJBcHb1KyGWN/NB1o74gfhpznByeED+rAA/cpHqYEjt H75+1DATnU9RyeosUPXOtBpvYshtDv6Wv6I5cMG2uwXnsDU4yOE4Kb4h44ufIi9C3rp6 DTNhZy/TyvxeuT8sxxiowXl51RqTEeFXgQzWrEBRNz/T2YXSyYi3NPyWBkp5uZEuO+dz Jjiw== X-Received: by 10.180.78.168 with SMTP id c8mr6763584wix.27.1364352506406; Tue, 26 Mar 2013 19:48:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.139.72 with HTTP; Tue, 26 Mar 2013 19:48:06 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Tue, 26 Mar 2013 22:48:06 -0400 Message-ID: To: Fabrice Delente Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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, Mar 26, 2013 at 8:36 AM, Fabrice Delente wrote: > Yes it has; I can usually ssh into it, but after having destroyed an > unresponsive domain it stopped responding to net connections on its IP. Can you SSH into it from itself (e.g. ssh 127.0.0.1)? Can you ping the domUs from dom0? -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 11:24:34 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 11:24: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 1UKoRz-0008TW-Dn; Wed, 27 Mar 2013 11:23:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKoRy-0008TD-5n; Wed, 27 Mar 2013 11:23:26 +0000 Received: from [85.158.139.211:8611] by server-2.bemta-5.messagelabs.com id 4E/4B-23989-DA6D2515; Wed, 27 Mar 2013 11:23:25 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1364383404!18489314!1 X-Originating-IP: [74.125.82.46] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14919 invoked from network); 27 Mar 2013 11:23:24 -0000 Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com) (74.125.82.46) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 11:23:24 -0000 Received: by mail-wg0-f46.google.com with SMTP id l18so357907wgh.1 for ; Wed, 27 Mar 2013 04:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=Jj1wFmLB4Nsm8cW1VK5Odqsj5k1szdPDLYM7WwZOhv0=; b=pkadQdmQ3A3ri/3w4nEu0sVo3M117FZBleXTs2k3lZQ8iLYU/Zk/DthXr6j2qkkR/X A2Cy2P/aL52+8cvBFmWgrieB+nNt1z47m5LRwSHXP4UHeBHmj+SPZT46h2oVfn+ePhUE jVGbL8zYEc46/lJy2n698S7ikfQdJcq7VCntoqdKN7xyZ7QpN0ZbQQQH9XeR+CLdgkdb QdKk3jPJp+fWAfS9rnFtB+POQUFmHnzDdEFEZNdhWJM3YiD21nKYmgGn8s9IpO4nlGuV 0mjk3SQWwUCLa5/E496kyH54GWYYHgryJq6wXy0tmKWkmIStRPSWObqXg8BC2tRP1y8O eYAg== MIME-Version: 1.0 X-Received: by 10.180.183.197 with SMTP id eo5mr9002495wic.28.1364383404013; Wed, 27 Mar 2013 04:23:24 -0700 (PDT) Received: by 10.194.20.163 with HTTP; Wed, 27 Mar 2013 04:23:23 -0700 (PDT) Date: Wed, 27 Mar 2013 11:23:23 +0000 X-Google-Sender-Auth: -ZozYM-QBnnVjwD3BikN-79lZJI Message-ID: From: George Dunlap To: "xen-devel@lists.xen.org" , "xen-users@lists.xen.org" Subject: [Xen-users] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 * Executive summary The number of event channels available for dom0 is currently one of the biggest limitations on scaling up the number of VMs which can be created on a single system. There are two alternative implementations we could choose, one of which is ready now, the other of which is potentially technically superior, but will not be ready for the 4.3 release. The core question we need to ask the community: How important is lifting the event channel scalability limit to 4.3? Will waiting until 4.4 cause a limit in the uptake of the Xen platform? * The issue The existing event channel implementation for PV guests is implemented as 2-level bit array. This limits the total number of event channels to word_size ^ 2, which is 1024 for 32-bit guests and 4096 for 64-bit guests. This sounds like a lot, until you consider that in a typical system, each VM needs 4 or more event channels in domain 0. This means that for a 32-bit dom0, there is a theoretical maximum of 256 guests -- and in practice it's more like 180 or so, because of event channels required for other things. XenServer already has customers using VDI that require more VMs than this. * The dilemma When we began the 4.3 release cycle, this was one of the items we identified as a key feature we needed to get for 4.3. Wei Liu started work on an extension of the existing implmentation, allowing 3 levels of event channels. The draft of this is ready, and just needs the last bit of polishing and bug-chasing before it can be accepted. However, several months ago, David Vrabel came up with an alternate design which in theory was more scalable, based on queues of linked lists (which we have internally been calling "FIFO" for short). David has been working on the implementation since, and has a draft protoype; but it's in no shape to be included in 4.3. There are some things that are attractive about the second solution, including the flexible assignment of interrupt priorities, ease of scalability, and potentially even the FIFO nature of the interrupt delivery. The question at hand then, is whether to take what we have in the 3-level implementation for 4.3, or wait to see how the FIFO implementation turns out (taking either it or the 3-level implementation in 4.4). * The solution in hand: 3-level event channels The basic idea behind 3-level event channels is to extend the existing 2-level implementation to 3 levels. Going to 3 levels would give us 32k event channels for 32-bit, and 256k for 64-bit. One of the advantages of this method is that since it is similar to the existing method, the general concepts and race conditions are fairly well understood and tested. One of the disadvantages that this method inherits from the 2-level event channels is the lack of priority. In the initial implementation of event channels, priority was handled by event channel order: scans for events always started at 0 and went upwards. However, this was not very scalable, as lower-numbered events could easily completely lock out higher-numbered events; and frequently "lower-numbered" simply meant "created earlier". Event channels were forced into a priority even if one was not wanted. So the implementation was tweaked, so that scans don't start at 0, but continue where the last event left off. This made it so that earlier events were not prioritized and removed the starvation issue, but at the cost of removing all event priorities. Certain events, like the timer event, are special-cased to be always checked, but this is rather a bit of a hack and not very scalable or flexible. One thing that should be noted is that adding the extra level is envisoned only to be used by guests that need the extended event channel space, such as dom0 and driver domains; domUs will continue to use the 2-level version. * The solution close at hand: FIFO event channels The FIFO solution makes event delivery a matter of adding items to a highly structured linked list. The number of event channels for the interface design has a theoretical maximum of 2^28; the current implementation is limimited at 2^17, which is over 100,000. The number is the same for both 32-bit and 64-bit kernels. One of the key design advantages of the FIFO is the ability to assign an arbitrary priority to any event. There are 16 priorities available; one queue for each priority. Higher-priority queues are handled below lower-priority queues, but events within a queue are handled in FIFO order. Another potential advantage is the FIFO ordering. With the current event channel implementation, one can construct scenarios where even with events of the same priority, clusters of events can lock out others based on where they are or the number of them. FIFO solves this by handling events within the same priority strictly in the order in which they were raised. It's not clear yet, however, whether this has a measurable impact on performance. One of the potential disadvantages of the FIFO solution is the amount of memory that it requires to be mapped into the Xen address space. The FIFO solution requires an entire word per event channel; a reasonably configured system might have up to 128 Xen-mapped pages per dom0 or domU. On the other hand, this number can be scaled at a fine-grained level, and limited by the toolstack; a typical domU would require only one page mapped in the hypervisor. By comparison, the 3-level solution requires only two bits per event channel. Any domain using the extra level would require exactly 16 pages for 64-bit domains, and 2 pages for 32-bit domains. We would expect this to include dom0 and any driver domains, but that domUs would continue using 2-level event channels (and thus require no extra pages to be mapped). * Considerations There are a number of additional considerations to take into account. The first is that the hypervisor maintainers have made it clear that once 3-level event channels is accepted, FIFO will have a higher bar to clear for acceptance. That is, if we wait for the 4.4 timeframe before choosing one to accept, then FIFO will only need to be marginally preferrable to 3-level to be accepted. However, if we accept the 3-level implimentation for 4.3, then FIFO will need to demonstrate that it is significantly better for 4.3 in order to be accepted. We are not yet aware of any companies that are blocked on this feature. Citrix XenServer clients using Citrix's VDI solution need to be able to run more than 200 guests; however, because XenServer control both the kernel and hypervisor side, they can introduce temporary, non-backwards or forwards-compatible changes to work around the limitation, and so are not blocked. Oracle and SuSE have not indicated that this a feature they are in dire need of. Most cloud deployments that we know of -- even extremely large ones like Amazon or Rackspace -- use large numbers of relatively inexpensive computers, and so typically do not need to run more than 200 VMs per physical host. Another factor to consider is that we are considering attempting a shorter release cadence for 4.4 -- 6 months or possibly less. That means that the impact of delaying the event channel scalability feature will be reduced. * What we need to know What we're missing in order to make an informed decision is voices from the community: If we delay the event channel scalability feature until 4.4, how likely is this to be an issue? Are there current users or potential users of Xen who need to be able to scale past 200 VMs on a single host, and who would end up choosing another hypervisor if this feature were delayed? Thank you for your time and input. -George Dunlap, 4.3 Release manager _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 11:24:34 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 11:24: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 1UKoRz-0008TW-Dn; Wed, 27 Mar 2013 11:23:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKoRy-0008TD-5n; Wed, 27 Mar 2013 11:23:26 +0000 Received: from [85.158.139.211:8611] by server-2.bemta-5.messagelabs.com id 4E/4B-23989-DA6D2515; Wed, 27 Mar 2013 11:23:25 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1364383404!18489314!1 X-Originating-IP: [74.125.82.46] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14919 invoked from network); 27 Mar 2013 11:23:24 -0000 Received: from mail-wg0-f46.google.com (HELO mail-wg0-f46.google.com) (74.125.82.46) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 11:23:24 -0000 Received: by mail-wg0-f46.google.com with SMTP id l18so357907wgh.1 for ; Wed, 27 Mar 2013 04:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=Jj1wFmLB4Nsm8cW1VK5Odqsj5k1szdPDLYM7WwZOhv0=; b=pkadQdmQ3A3ri/3w4nEu0sVo3M117FZBleXTs2k3lZQ8iLYU/Zk/DthXr6j2qkkR/X A2Cy2P/aL52+8cvBFmWgrieB+nNt1z47m5LRwSHXP4UHeBHmj+SPZT46h2oVfn+ePhUE jVGbL8zYEc46/lJy2n698S7ikfQdJcq7VCntoqdKN7xyZ7QpN0ZbQQQH9XeR+CLdgkdb QdKk3jPJp+fWAfS9rnFtB+POQUFmHnzDdEFEZNdhWJM3YiD21nKYmgGn8s9IpO4nlGuV 0mjk3SQWwUCLa5/E496kyH54GWYYHgryJq6wXy0tmKWkmIStRPSWObqXg8BC2tRP1y8O eYAg== MIME-Version: 1.0 X-Received: by 10.180.183.197 with SMTP id eo5mr9002495wic.28.1364383404013; Wed, 27 Mar 2013 04:23:24 -0700 (PDT) Received: by 10.194.20.163 with HTTP; Wed, 27 Mar 2013 04:23:23 -0700 (PDT) Date: Wed, 27 Mar 2013 11:23:23 +0000 X-Google-Sender-Auth: -ZozYM-QBnnVjwD3BikN-79lZJI Message-ID: From: George Dunlap To: "xen-devel@lists.xen.org" , "xen-users@lists.xen.org" Subject: [Xen-users] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 * Executive summary The number of event channels available for dom0 is currently one of the biggest limitations on scaling up the number of VMs which can be created on a single system. There are two alternative implementations we could choose, one of which is ready now, the other of which is potentially technically superior, but will not be ready for the 4.3 release. The core question we need to ask the community: How important is lifting the event channel scalability limit to 4.3? Will waiting until 4.4 cause a limit in the uptake of the Xen platform? * The issue The existing event channel implementation for PV guests is implemented as 2-level bit array. This limits the total number of event channels to word_size ^ 2, which is 1024 for 32-bit guests and 4096 for 64-bit guests. This sounds like a lot, until you consider that in a typical system, each VM needs 4 or more event channels in domain 0. This means that for a 32-bit dom0, there is a theoretical maximum of 256 guests -- and in practice it's more like 180 or so, because of event channels required for other things. XenServer already has customers using VDI that require more VMs than this. * The dilemma When we began the 4.3 release cycle, this was one of the items we identified as a key feature we needed to get for 4.3. Wei Liu started work on an extension of the existing implmentation, allowing 3 levels of event channels. The draft of this is ready, and just needs the last bit of polishing and bug-chasing before it can be accepted. However, several months ago, David Vrabel came up with an alternate design which in theory was more scalable, based on queues of linked lists (which we have internally been calling "FIFO" for short). David has been working on the implementation since, and has a draft protoype; but it's in no shape to be included in 4.3. There are some things that are attractive about the second solution, including the flexible assignment of interrupt priorities, ease of scalability, and potentially even the FIFO nature of the interrupt delivery. The question at hand then, is whether to take what we have in the 3-level implementation for 4.3, or wait to see how the FIFO implementation turns out (taking either it or the 3-level implementation in 4.4). * The solution in hand: 3-level event channels The basic idea behind 3-level event channels is to extend the existing 2-level implementation to 3 levels. Going to 3 levels would give us 32k event channels for 32-bit, and 256k for 64-bit. One of the advantages of this method is that since it is similar to the existing method, the general concepts and race conditions are fairly well understood and tested. One of the disadvantages that this method inherits from the 2-level event channels is the lack of priority. In the initial implementation of event channels, priority was handled by event channel order: scans for events always started at 0 and went upwards. However, this was not very scalable, as lower-numbered events could easily completely lock out higher-numbered events; and frequently "lower-numbered" simply meant "created earlier". Event channels were forced into a priority even if one was not wanted. So the implementation was tweaked, so that scans don't start at 0, but continue where the last event left off. This made it so that earlier events were not prioritized and removed the starvation issue, but at the cost of removing all event priorities. Certain events, like the timer event, are special-cased to be always checked, but this is rather a bit of a hack and not very scalable or flexible. One thing that should be noted is that adding the extra level is envisoned only to be used by guests that need the extended event channel space, such as dom0 and driver domains; domUs will continue to use the 2-level version. * The solution close at hand: FIFO event channels The FIFO solution makes event delivery a matter of adding items to a highly structured linked list. The number of event channels for the interface design has a theoretical maximum of 2^28; the current implementation is limimited at 2^17, which is over 100,000. The number is the same for both 32-bit and 64-bit kernels. One of the key design advantages of the FIFO is the ability to assign an arbitrary priority to any event. There are 16 priorities available; one queue for each priority. Higher-priority queues are handled below lower-priority queues, but events within a queue are handled in FIFO order. Another potential advantage is the FIFO ordering. With the current event channel implementation, one can construct scenarios where even with events of the same priority, clusters of events can lock out others based on where they are or the number of them. FIFO solves this by handling events within the same priority strictly in the order in which they were raised. It's not clear yet, however, whether this has a measurable impact on performance. One of the potential disadvantages of the FIFO solution is the amount of memory that it requires to be mapped into the Xen address space. The FIFO solution requires an entire word per event channel; a reasonably configured system might have up to 128 Xen-mapped pages per dom0 or domU. On the other hand, this number can be scaled at a fine-grained level, and limited by the toolstack; a typical domU would require only one page mapped in the hypervisor. By comparison, the 3-level solution requires only two bits per event channel. Any domain using the extra level would require exactly 16 pages for 64-bit domains, and 2 pages for 32-bit domains. We would expect this to include dom0 and any driver domains, but that domUs would continue using 2-level event channels (and thus require no extra pages to be mapped). * Considerations There are a number of additional considerations to take into account. The first is that the hypervisor maintainers have made it clear that once 3-level event channels is accepted, FIFO will have a higher bar to clear for acceptance. That is, if we wait for the 4.4 timeframe before choosing one to accept, then FIFO will only need to be marginally preferrable to 3-level to be accepted. However, if we accept the 3-level implimentation for 4.3, then FIFO will need to demonstrate that it is significantly better for 4.3 in order to be accepted. We are not yet aware of any companies that are blocked on this feature. Citrix XenServer clients using Citrix's VDI solution need to be able to run more than 200 guests; however, because XenServer control both the kernel and hypervisor side, they can introduce temporary, non-backwards or forwards-compatible changes to work around the limitation, and so are not blocked. Oracle and SuSE have not indicated that this a feature they are in dire need of. Most cloud deployments that we know of -- even extremely large ones like Amazon or Rackspace -- use large numbers of relatively inexpensive computers, and so typically do not need to run more than 200 VMs per physical host. Another factor to consider is that we are considering attempting a shorter release cadence for 4.4 -- 6 months or possibly less. That means that the impact of delaying the event channel scalability feature will be reduced. * What we need to know What we're missing in order to make an informed decision is voices from the community: If we delay the event channel scalability feature until 4.4, how likely is this to be an issue? Are there current users or potential users of Xen who need to be able to scale past 200 VMs on a single host, and who would end up choosing another hypervisor if this feature were delayed? Thank you for your time and input. -George Dunlap, 4.3 Release manager _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 12:49:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 12:49: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 1UKpmU-0002QQ-05; Wed, 27 Mar 2013 12:48:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKpmS-0002QL-Ro for xen-users@lists.xen.org; Wed, 27 Mar 2013 12:48:40 +0000 Received: from [85.158.139.211:44688] by server-16.bemta-5.messagelabs.com id E5/CC-02543-8AAE2515; Wed, 27 Mar 2013 12:48:40 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1364388518!18506220!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15407 invoked from network); 27 Mar 2013 12:48:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 12:48:39 -0000 X-IronPort-AV: E=Sophos;i="4.84,919,1355097600"; d="scan'208";a="15850845" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 27 Mar 2013 12:48:37 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.3; Wed, 27 Mar 2013 08:48:37 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UKpmP-00071y-21; Wed, 27 Mar 2013 12:48:37 +0000 Date: Wed, 27 Mar 2013 12:48:37 +0000 From: Wei Liu To: Mike Message-ID: <20130327124836.GA22389@zion.uk.xensource.com> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 02:32:06AM +0000, Mike wrote: > I'm out of debugging ideas. Let me know if you have any. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#20 > Do you not have any serial output to attach? I would suggest add noreboot on Xen command line to stop Xen from automatically rebooting when Dom0 crash. Wei. > _______________________________________________ > 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 Mar 27 12:49:53 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 12:49: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 1UKpmU-0002QQ-05; Wed, 27 Mar 2013 12:48:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKpmS-0002QL-Ro for xen-users@lists.xen.org; Wed, 27 Mar 2013 12:48:40 +0000 Received: from [85.158.139.211:44688] by server-16.bemta-5.messagelabs.com id E5/CC-02543-8AAE2515; Wed, 27 Mar 2013 12:48:40 +0000 X-Env-Sender: wei.liu2@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1364388518!18506220!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15407 invoked from network); 27 Mar 2013 12:48:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 12:48:39 -0000 X-IronPort-AV: E=Sophos;i="4.84,919,1355097600"; d="scan'208";a="15850845" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/AES128-SHA; 27 Mar 2013 12:48:37 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.3; Wed, 27 Mar 2013 08:48:37 -0400 Received: from zion.uk.xensource.com ([10.80.2.73]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1UKpmP-00071y-21; Wed, 27 Mar 2013 12:48:37 +0000 Date: Wed, 27 Mar 2013 12:48:37 +0000 From: Wei Liu To: Mike Message-ID: <20130327124836.GA22389@zion.uk.xensource.com> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 02:32:06AM +0000, Mike wrote: > I'm out of debugging ideas. Let me know if you have any. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#20 > Do you not have any serial output to attach? I would suggest add noreboot on Xen command line to stop Xen from automatically rebooting when Dom0 crash. Wei. > _______________________________________________ > 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 Mar 27 16:22:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 16:22: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 1UKt6n-0000cT-P1; Wed, 27 Mar 2013 16:21:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKt6m-0000cF-DW for xen-users@lists.xen.org; Wed, 27 Mar 2013 16:21:52 +0000 Received: from [85.158.139.211:26137] by server-2.bemta-5.messagelabs.com id 7C/94-23989-F9C13515; Wed, 27 Mar 2013 16:21:51 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1364401309!19979345!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4123 invoked from network); 27 Mar 2013 16:21:50 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-15.tower-206.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2013 16:21:50 -0000 Date: Wed, 27 Mar 2013 16:21:47 +0000 From: Mike To: Wei Liu Message-ID: <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130327124836.GA22389@zion.uk.xensource.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Wei Liu wrote: > > I'm out of debugging ideas. Let me know if you have any. > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#20 > > Do you not have any serial output to attach? Correct. As I (try to) say in the bug, the serial connection works fine when I test it with minicom on both ends, but I get no output from the Xen boot process. Clearly the ideal would be to get this functioning. > I would suggest add noreboot on Xen command line to stop Xen from > automatically rebooting when Dom0 crash. That was one of the first things I tried. It stops at a blank screen. Not useful. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 16:22:58 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 16:22: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 1UKt6n-0000cT-P1; Wed, 27 Mar 2013 16:21:53 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKt6m-0000cF-DW for xen-users@lists.xen.org; Wed, 27 Mar 2013 16:21:52 +0000 Received: from [85.158.139.211:26137] by server-2.bemta-5.messagelabs.com id 7C/94-23989-F9C13515; Wed, 27 Mar 2013 16:21:51 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1364401309!19979345!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4123 invoked from network); 27 Mar 2013 16:21:50 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-15.tower-206.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2013 16:21:50 -0000 Date: Wed, 27 Mar 2013 16:21:47 +0000 From: Mike To: Wei Liu Message-ID: <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130327124836.GA22389@zion.uk.xensource.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Wei Liu wrote: > > I'm out of debugging ideas. Let me know if you have any. > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#20 > > Do you not have any serial output to attach? Correct. As I (try to) say in the bug, the serial connection works fine when I test it with minicom on both ends, but I get no output from the Xen boot process. Clearly the ideal would be to get this functioning. > I would suggest add noreboot on Xen command line to stop Xen from > automatically rebooting when Dom0 crash. That was one of the first things I tried. It stops at a blank screen. Not useful. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 17:17:55 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 17:17: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 1UKty3-0003bP-TX; Wed, 27 Mar 2013 17:16:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKty2-0003bD-CK for xen-users@lists.xen.org; Wed, 27 Mar 2013 17:16:54 +0000 Received: from [85.158.139.211:59552] by server-10.bemta-5.messagelabs.com id AB/BA-23714-58923515; Wed, 27 Mar 2013 17:16:53 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1364404612!18973984!1 X-Originating-IP: [74.125.82.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23569 invoked from network); 27 Mar 2013 17:16:52 -0000 Received: from mail-we0-f169.google.com (HELO mail-we0-f169.google.com) (74.125.82.169) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 17:16:52 -0000 Received: by mail-we0-f169.google.com with SMTP id x43so3150714wey.28 for ; Wed, 27 Mar 2013 10:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ooOQnpmT/Ox0B666MX71+Nm5sdzIgiREDyA/UNBLKxk=; b=cNODOPDUEsk7C3epVESUy+N/yIMadUycdjMi7NA0WQyu1BagEevgtl1XHPguE5EVbh 7RLc+O64R/lTYABzIVVPN29iX2DI8g0I/y0o+ZFxmdm8s6AWPGiHKufjmHPStzoHleGR hdAcTlAxZAhOrwgr8gKjCqcv7F8HPNHhEBmt9JLR+6x8At6dRgG0h2JMaoXOfGfwTgt2 oYBsRiMHOHO2w5yogtJZe7mZqXOz/3s/uevSMzMPJzBB5wEpWnlTkIEKSrfPkuHZEv1y QVDKp5yoWrg0pk1EUkhhhxlOlR5hmHEC3YHXbjQQVqT7h9x1bspyweZQG3lIewWMzR2j tJkw== MIME-Version: 1.0 X-Received: by 10.194.89.234 with SMTP id br10mr6223043wjb.43.1364404611161; Wed, 27 Mar 2013 10:16:51 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Wed, 27 Mar 2013 10:16:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 18:16:50 +0100 Message-ID: From: Fabrice Delente To: Sean Greenslade Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============8071762143457258844==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8071762143457258844== Content-Type: multipart/alternative; boundary=047d7bf1983e2da43f04d8eb34ae --047d7bf1983e2da43f04d8eb34ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Today it has started respnding again to ssh, even though I didn't do anything. In dmesg I have scores of lines like these: [5800201.055609] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [5800201.904358] device tap55.0 entered promiscuous mode [5800201.904384] xen-bridge: port 3(tap55.0) entering learning state [5800211.377315] vif55.0: no IPv6 routers present [5800212.181315] tap55.0: no IPv6 routers present [5800216.021324] xen-bridge: port 2(vif55.0) entering forwarding state [5800216.901315] xen-bridge: port 3(tap55.0) entering forwarding state =E2=80=8BI don't know if it's relevant. I'll post an update if the problem arises again. --047d7bf1983e2da43f04d8eb34ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Today it has started respnding again to ssh= , even though I didn't do anything.

    In dmesg I have scores= of lines like these:

    [5800201.055609] physdev match: using --physde= v-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic= is not supported anymore.
    [5800201.904358] device tap55.0 entered promiscuous mode
    [5800201.904384= ] xen-bridge: port 3(tap55.0) entering learning state
    [5800211.377315] v= if55.0: no IPv6 routers present
    [5800212.181315] tap55.0: no IPv6 router= s present
    [5800216.021324] xen-bridge: port 2(vif55.0) entering forwarding state
    [= 5800216.901315] xen-bridge: port 3(tap55.0) entering forwarding state
    =E2=80=8BI don't know if it's relevant.

    I'= ll post an update if the problem arises again.
    --047d7bf1983e2da43f04d8eb34ae-- --===============8071762143457258844== 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 --===============8071762143457258844==-- From xen-users-bounces@lists.xen.org Wed Mar 27 17:17:55 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 17:17: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 1UKty3-0003bP-TX; Wed, 27 Mar 2013 17:16:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKty2-0003bD-CK for xen-users@lists.xen.org; Wed, 27 Mar 2013 17:16:54 +0000 Received: from [85.158.139.211:59552] by server-10.bemta-5.messagelabs.com id AB/BA-23714-58923515; Wed, 27 Mar 2013 17:16:53 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1364404612!18973984!1 X-Originating-IP: [74.125.82.169] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23569 invoked from network); 27 Mar 2013 17:16:52 -0000 Received: from mail-we0-f169.google.com (HELO mail-we0-f169.google.com) (74.125.82.169) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 17:16:52 -0000 Received: by mail-we0-f169.google.com with SMTP id x43so3150714wey.28 for ; Wed, 27 Mar 2013 10:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ooOQnpmT/Ox0B666MX71+Nm5sdzIgiREDyA/UNBLKxk=; b=cNODOPDUEsk7C3epVESUy+N/yIMadUycdjMi7NA0WQyu1BagEevgtl1XHPguE5EVbh 7RLc+O64R/lTYABzIVVPN29iX2DI8g0I/y0o+ZFxmdm8s6AWPGiHKufjmHPStzoHleGR hdAcTlAxZAhOrwgr8gKjCqcv7F8HPNHhEBmt9JLR+6x8At6dRgG0h2JMaoXOfGfwTgt2 oYBsRiMHOHO2w5yogtJZe7mZqXOz/3s/uevSMzMPJzBB5wEpWnlTkIEKSrfPkuHZEv1y QVDKp5yoWrg0pk1EUkhhhxlOlR5hmHEC3YHXbjQQVqT7h9x1bspyweZQG3lIewWMzR2j tJkw== MIME-Version: 1.0 X-Received: by 10.194.89.234 with SMTP id br10mr6223043wjb.43.1364404611161; Wed, 27 Mar 2013 10:16:51 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Wed, 27 Mar 2013 10:16:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 18:16:50 +0100 Message-ID: From: Fabrice Delente To: Sean Greenslade Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============8071762143457258844==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8071762143457258844== Content-Type: multipart/alternative; boundary=047d7bf1983e2da43f04d8eb34ae --047d7bf1983e2da43f04d8eb34ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Today it has started respnding again to ssh, even though I didn't do anything. In dmesg I have scores of lines like these: [5800201.055609] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [5800201.904358] device tap55.0 entered promiscuous mode [5800201.904384] xen-bridge: port 3(tap55.0) entering learning state [5800211.377315] vif55.0: no IPv6 routers present [5800212.181315] tap55.0: no IPv6 routers present [5800216.021324] xen-bridge: port 2(vif55.0) entering forwarding state [5800216.901315] xen-bridge: port 3(tap55.0) entering forwarding state =E2=80=8BI don't know if it's relevant. I'll post an update if the problem arises again. --047d7bf1983e2da43f04d8eb34ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Today it has started respnding again to ssh= , even though I didn't do anything.

    In dmesg I have scores= of lines like these:

    [5800201.055609] physdev match: using --physde= v-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic= is not supported anymore.
    [5800201.904358] device tap55.0 entered promiscuous mode
    [5800201.904384= ] xen-bridge: port 3(tap55.0) entering learning state
    [5800211.377315] v= if55.0: no IPv6 routers present
    [5800212.181315] tap55.0: no IPv6 router= s present
    [5800216.021324] xen-bridge: port 2(vif55.0) entering forwarding state
    [= 5800216.901315] xen-bridge: port 3(tap55.0) entering forwarding state
    =E2=80=8BI don't know if it's relevant.

    I'= ll post an update if the problem arises again.
    --047d7bf1983e2da43f04d8eb34ae-- --===============8071762143457258844== 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 --===============8071762143457258844==-- From xen-users-bounces@lists.xen.org Wed Mar 27 18:03:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:03: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 1UKug8-0006WO-SH; Wed, 27 Mar 2013 18:02:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKug7-0006WF-77 for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:02:27 +0000 Received: from [85.158.143.99:62710] by server-1.bemta-4.messagelabs.com id 09/12-06203-23433515; Wed, 27 Mar 2013 18:02:26 +0000 X-Env-Sender: fabian@koeslin.info X-Msg-Ref: server-14.tower-216.messagelabs.com!1364407345!17698781!1 X-Originating-IP: [194.25.134.83] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiAxOTQuMjUuMTM0LjgzID0+IDM1MjU2\n,sa_preprocessor: QmFkIElQOiAxOTQuMjUuMTM0LjgzID0+IDM1MjU2\n,UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29742 invoked from network); 27 Mar 2013 18:02:25 -0000 Received: from mailout07.t-online.de (HELO mailout07.t-online.de) (194.25.134.83) by server-14.tower-216.messagelabs.com with SMTP; 27 Mar 2013 18:02:25 -0000 Received: from fwd55.aul.t-online.de (fwd55.aul.t-online.de ) by mailout07.t-online.de with smtp id 1UKug5-0003bA-Eb; Wed, 27 Mar 2013 19:02:25 +0100 Received: from fabian-koslins-macbook-pro.fritz.box (S+rIH-ZAZtdLpNmpAXwVNMJDqwgvCQQcwE7E2BYJmUQS3mrWIH+5pks7jZz9ghO4nZ5xGv1wEv@[79.213.70.51]) by fwd55.t-online.de with esmtp id 1UKug4-14ymbA0; Wed, 27 Mar 2013 19:02:24 +0100 From: =?iso-8859-1?Q?Fabian_K=F6slin?= Date: Wed, 27 Mar 2013 19:02:23 +0100 Message-Id: <24D0470F-86A3-4EB2-8E72-4CEBF06CFE41@koeslin.info> To: xen-users@lists.xen.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-ID: S+rIH-ZAZtdLpNmpAXwVNMJDqwgvCQQcwE7E2BYJmUQS3mrWIH+5pks7jZz9ghO4nZ5xGv1wEv X-TOI-MSGID: 6aca40d3-f289-47e2-918b-5730be3d81a5 Subject: [Xen-users] using xen with sdl and custom vga resolution X-BeenThere: xen-users@lists.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 Hallo everybody, I'm trying to use a Xen HVM Windows 7 Guest on a Debian Wheezy dom0. I connect to the DomU via SDL. Quite everything is working like I want. The only Problem left is that I cannot select the vga resolution inside the DomU. My monitor required a resolution of 1440x768. The only available mode with a width of 1440 is 1440x900. Is there any way to make this mode available? I tried the stdvga=0 and the stdvga=1 option and set the video memory to 16. I don't want to use vga passthrough because I use a ps/2 keyboard an mouse and have no way to connect this direct to the DomU. I would be happy If anybody have a solution for me. cheers, Fabian Koeslin _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 18:03:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:03: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 1UKug8-0006WO-SH; Wed, 27 Mar 2013 18:02:28 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKug7-0006WF-77 for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:02:27 +0000 Received: from [85.158.143.99:62710] by server-1.bemta-4.messagelabs.com id 09/12-06203-23433515; Wed, 27 Mar 2013 18:02:26 +0000 X-Env-Sender: fabian@koeslin.info X-Msg-Ref: server-14.tower-216.messagelabs.com!1364407345!17698781!1 X-Originating-IP: [194.25.134.83] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiAxOTQuMjUuMTM0LjgzID0+IDM1MjU2\n,sa_preprocessor: QmFkIElQOiAxOTQuMjUuMTM0LjgzID0+IDM1MjU2\n,UNPARSEABLE_RELAY X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29742 invoked from network); 27 Mar 2013 18:02:25 -0000 Received: from mailout07.t-online.de (HELO mailout07.t-online.de) (194.25.134.83) by server-14.tower-216.messagelabs.com with SMTP; 27 Mar 2013 18:02:25 -0000 Received: from fwd55.aul.t-online.de (fwd55.aul.t-online.de ) by mailout07.t-online.de with smtp id 1UKug5-0003bA-Eb; Wed, 27 Mar 2013 19:02:25 +0100 Received: from fabian-koslins-macbook-pro.fritz.box (S+rIH-ZAZtdLpNmpAXwVNMJDqwgvCQQcwE7E2BYJmUQS3mrWIH+5pks7jZz9ghO4nZ5xGv1wEv@[79.213.70.51]) by fwd55.t-online.de with esmtp id 1UKug4-14ymbA0; Wed, 27 Mar 2013 19:02:24 +0100 From: =?iso-8859-1?Q?Fabian_K=F6slin?= Date: Wed, 27 Mar 2013 19:02:23 +0100 Message-Id: <24D0470F-86A3-4EB2-8E72-4CEBF06CFE41@koeslin.info> To: xen-users@lists.xen.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-ID: S+rIH-ZAZtdLpNmpAXwVNMJDqwgvCQQcwE7E2BYJmUQS3mrWIH+5pks7jZz9ghO4nZ5xGv1wEv X-TOI-MSGID: 6aca40d3-f289-47e2-918b-5730be3d81a5 Subject: [Xen-users] using xen with sdl and custom vga resolution X-BeenThere: xen-users@lists.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 Hallo everybody, I'm trying to use a Xen HVM Windows 7 Guest on a Debian Wheezy dom0. I connect to the DomU via SDL. Quite everything is working like I want. The only Problem left is that I cannot select the vga resolution inside the DomU. My monitor required a resolution of 1440x768. The only available mode with a width of 1440 is 1440x900. Is there any way to make this mode available? I tried the stdvga=0 and the stdvga=1 option and set the video memory to 16. I don't want to use vga passthrough because I use a ps/2 keyboard an mouse and have no way to connect this direct to the DomU. I would be happy If anybody have a solution for me. cheers, Fabian Koeslin _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 18:22:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:22:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKuxw-0007Y8-Es; Wed, 27 Mar 2013 18:20:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKuxv-0007Y0-3F for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:20:51 +0000 Received: from [85.158.139.83:14753] by server-10.bemta-5.messagelabs.com id 0F/78-23714-28833515; Wed, 27 Mar 2013 18:20:50 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1364408448!24287035!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7398 invoked from network); 27 Mar 2013 18:20:49 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Mar 2013 18:20:49 -0000 Received: from [200.52.43.60] (port=46599 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UKuxr-0005ki-T6 for xen-users@lists.xen.org; Wed, 27 Mar 2013 13:20:47 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id 55EADA209 for ; Wed, 27 Mar 2013 12:15:23 -0600 (CST) Message-ID: <5153387F.5020106@ondore.com> Date: Wed, 27 Mar 2013 12:20:47 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> In-Reply-To: <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Hello. El 27/03/13 10:21, Mike escribi=F3: > Wei Liu wrote: >>> I'm out of debugging ideas. Let me know if you have any. >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D703586#20 >> >> Do you not have any serial output to attach? > > Correct. As I (try to) say in the bug, the serial connection works fine > when I test it with minicom on both ends, but I get no output from the > Xen boot process. Please post your boot loader configuration. The next thing to try would be hardware debugging. Memtest, set BIOS = into fail-safe settings. Another idea is googling around about you Motherboard model and/or video = controller and north bridge model. A good reference would be to test Squeeze's Xen and kernel, if they show = the same behavior. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 18:22:00 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:22:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKuxw-0007Y8-Es; Wed, 27 Mar 2013 18:20:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKuxv-0007Y0-3F for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:20:51 +0000 Received: from [85.158.139.83:14753] by server-10.bemta-5.messagelabs.com id 0F/78-23714-28833515; Wed, 27 Mar 2013 18:20:50 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-14.tower-182.messagelabs.com!1364408448!24287035!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7398 invoked from network); 27 Mar 2013 18:20:49 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Mar 2013 18:20:49 -0000 Received: from [200.52.43.60] (port=46599 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UKuxr-0005ki-T6 for xen-users@lists.xen.org; Wed, 27 Mar 2013 13:20:47 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id 55EADA209 for ; Wed, 27 Mar 2013 12:15:23 -0600 (CST) Message-ID: <5153387F.5020106@ondore.com> Date: Wed, 27 Mar 2013 12:20:47 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> In-Reply-To: <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Hello. El 27/03/13 10:21, Mike escribi=F3: > Wei Liu wrote: >>> I'm out of debugging ideas. Let me know if you have any. >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D703586#20 >> >> Do you not have any serial output to attach? > > Correct. As I (try to) say in the bug, the serial connection works fine > when I test it with minicom on both ends, but I get no output from the > Xen boot process. Please post your boot loader configuration. The next thing to try would be hardware debugging. Memtest, set BIOS = into fail-safe settings. Another idea is googling around about you Motherboard model and/or video = controller and north bridge model. A good reference would be to test Squeeze's Xen and kernel, if they show = the same behavior. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 18:22:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:22: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 1UKuyt-0007dj-53; Wed, 27 Mar 2013 18:21:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKuyr-0007db-Pe for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:21:49 +0000 Received: from [85.158.139.83:21759] by server-11.bemta-5.messagelabs.com id 7B/90-27486-DB833515; Wed, 27 Mar 2013 18:21:49 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1364408508!28572811!1 X-Originating-IP: [74.125.82.172] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13234 invoked from network); 27 Mar 2013 18:21:48 -0000 Received: from mail-we0-f172.google.com (HELO mail-we0-f172.google.com) (74.125.82.172) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 18:21:48 -0000 Received: by mail-we0-f172.google.com with SMTP id r3so3661233wey.31 for ; Wed, 27 Mar 2013 11:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=seiRlovU5E0oZJfwCzFH11Xcp/out2Uwi6VCiQ06UFs=; b=bbshKqZvGCQSODhOvwn78ZwgiKhU4Wy+7b2HmerBf5myF9gLiMFju8OlZpfxe1zSt1 chjlJeRahuyYt3HyW/RUzEsahT55AzPkX34WeHz7T+QL3Ao8zMBwxaXpNMMKJH6W9IA0 kALKx72bEzUnnRuf1+/mjlQiGVF3q3hnQrj2I3jiZIpoCPEefJvSvso9GujsISRv0BOZ yDLGsLq/8BUGpkGWXHcYkRsRpS/mRwwSqhnVYh2HV5fgvMtDCsSNWnx0QKUr5BdM2AnY gZ0P6LcLPJryHO1PdvB1nyUMrS5EyphnnfKUoNWgLg0v8rJxngHzAEY455+qCGwARq0g 05TA== X-Received: by 10.194.60.195 with SMTP id j3mr33215682wjr.33.1364408508295; Wed, 27 Mar 2013 11:21:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.139.72 with HTTP; Wed, 27 Mar 2013 11:21:28 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Wed, 27 Mar 2013 14:21:28 -0400 Message-ID: To: Fabrice Delente Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 1:16 PM, Fabrice Delente wrote: > Today it has started respnding again to ssh, even though I didn't do > anything. > > In dmesg I have scores of lines like these: > > [5800201.055609] physdev match: using --physdev-out in the OUTPUT, FORWARD > and POSTROUTING chains for non-bridged traffic is not supported anymore. This means you have some rules in your iptables that aren't supported. If this is any indication of what yous issues are, it's that iptables is misconfigured. You may want to check over your rules table and make sure they're all sane. > [5800201.904358] device tap55.0 entered promiscuous mode > [5800201.904384] xen-bridge: port 3(tap55.0) entering learning state Just general Xen networking chatter. Nothing to worry about here. > [5800211.377315] vif55.0: no IPv6 routers present > [5800212.181315] tap55.0: no IPv6 routers present IPv6 stuff, obviously makes no difference if you're not on a v6 network. > [5800216.021324] xen-bridge: port 2(vif55.0) entering forwarding state > [5800216.901315] xen-bridge: port 3(tap55.0) entering forwarding state More chatter. All normal. > > I don't know if it's relevant. > > I'll post an update if the problem arises again. You may want to take a look at whatever writes your iptables. If you're using a script to set up networking, it may be out of date. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 18:22:37 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:22: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 1UKuyt-0007dj-53; Wed, 27 Mar 2013 18:21:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKuyr-0007db-Pe for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:21:49 +0000 Received: from [85.158.139.83:21759] by server-11.bemta-5.messagelabs.com id 7B/90-27486-DB833515; Wed, 27 Mar 2013 18:21:49 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-3.tower-182.messagelabs.com!1364408508!28572811!1 X-Originating-IP: [74.125.82.172] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13234 invoked from network); 27 Mar 2013 18:21:48 -0000 Received: from mail-we0-f172.google.com (HELO mail-we0-f172.google.com) (74.125.82.172) by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 18:21:48 -0000 Received: by mail-we0-f172.google.com with SMTP id r3so3661233wey.31 for ; Wed, 27 Mar 2013 11:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=seiRlovU5E0oZJfwCzFH11Xcp/out2Uwi6VCiQ06UFs=; b=bbshKqZvGCQSODhOvwn78ZwgiKhU4Wy+7b2HmerBf5myF9gLiMFju8OlZpfxe1zSt1 chjlJeRahuyYt3HyW/RUzEsahT55AzPkX34WeHz7T+QL3Ao8zMBwxaXpNMMKJH6W9IA0 kALKx72bEzUnnRuf1+/mjlQiGVF3q3hnQrj2I3jiZIpoCPEefJvSvso9GujsISRv0BOZ yDLGsLq/8BUGpkGWXHcYkRsRpS/mRwwSqhnVYh2HV5fgvMtDCsSNWnx0QKUr5BdM2AnY gZ0P6LcLPJryHO1PdvB1nyUMrS5EyphnnfKUoNWgLg0v8rJxngHzAEY455+qCGwARq0g 05TA== X-Received: by 10.194.60.195 with SMTP id j3mr33215682wjr.33.1364408508295; Wed, 27 Mar 2013 11:21:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.139.72 with HTTP; Wed, 27 Mar 2013 11:21:28 -0700 (PDT) In-Reply-To: References: From: Sean Greenslade Date: Wed, 27 Mar 2013 14:21:28 -0400 Message-ID: To: Fabrice Delente Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 1:16 PM, Fabrice Delente wrote: > Today it has started respnding again to ssh, even though I didn't do > anything. > > In dmesg I have scores of lines like these: > > [5800201.055609] physdev match: using --physdev-out in the OUTPUT, FORWARD > and POSTROUTING chains for non-bridged traffic is not supported anymore. This means you have some rules in your iptables that aren't supported. If this is any indication of what yous issues are, it's that iptables is misconfigured. You may want to check over your rules table and make sure they're all sane. > [5800201.904358] device tap55.0 entered promiscuous mode > [5800201.904384] xen-bridge: port 3(tap55.0) entering learning state Just general Xen networking chatter. Nothing to worry about here. > [5800211.377315] vif55.0: no IPv6 routers present > [5800212.181315] tap55.0: no IPv6 routers present IPv6 stuff, obviously makes no difference if you're not on a v6 network. > [5800216.021324] xen-bridge: port 2(vif55.0) entering forwarding state > [5800216.901315] xen-bridge: port 3(tap55.0) entering forwarding state More chatter. All normal. > > I don't know if it's relevant. > > I'll post an update if the problem arises again. You may want to take a look at whatever writes your iptables. If you're using a script to set up networking, it may be out of date. -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 18:36:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:36: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 1UKvCY-000062-Ga; Wed, 27 Mar 2013 18:35:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKvCX-00005w-Vj for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:35:58 +0000 Received: from [85.158.138.51:11508] by server-13.bemta-3.messagelabs.com id 51/18-25744-D0C33515; Wed, 27 Mar 2013 18:35:57 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1364409356!26597299!1 X-Originating-IP: [74.125.82.182] X-SpamReason: No, hits=2.0 required=7.0 tests=HTML_30_40,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18465 invoked from network); 27 Mar 2013 18:35:56 -0000 Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 18:35:56 -0000 Received: by mail-we0-f182.google.com with SMTP id k14so4719035wer.13 for ; Wed, 27 Mar 2013 11:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=P9TKbsSiDiR780GUo7LuYRToeUTaz31QT+BCcxXx8tQ=; b=UPlLtpUTqmoDgpJGEz76KKMIz/jToI5lDUBoPmvT2/gBhgGn1fLZHyym+lkwf89tAm +FGVfPaPLCLXxdK9jleJsDSIwUtNXoFB/V2SZGoJqWELDyaNJlfJnCVH6sNfO5wUJC5D /rK1vS+lqdB9S6JR1hzyC3jAvHpV2huuHxV+JhL1bafmn0yGA9FQ8oo/81n1eQuunHtn DHXOgyFL7Z7h4zYTS5gK6j5jAAOB3S1zu4IqQyoLwBTPE9Ki9WhWtG8O7g6dEmOQvUoM gQ4xHJobWxKgkepaD7jEPZXk/l9eMs07w9y8BFU2HEYd4u910R/6hjPH6YOvUGZT8CGO byBA== MIME-Version: 1.0 X-Received: by 10.180.77.9 with SMTP id o9mr11691657wiw.16.1364409356321; Wed, 27 Mar 2013 11:35:56 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Wed, 27 Mar 2013 11:35:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 19:35:56 +0100 Message-ID: From: Fabrice Delente To: Sean Greenslade Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============7506172127131680336==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7506172127131680336== Content-Type: multipart/alternative; boundary=f46d043d66c3030b2504d8ec4fa3 --f46d043d66c3030b2504d8ec4fa3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, thanks for the hint, I'll look into that. =E2=80=8B --f46d043d66c3030b2504d8ec4fa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Ok, thanks for the hint, I'll look into that.
    =E2= =80=8B
    --f46d043d66c3030b2504d8ec4fa3-- --===============7506172127131680336== 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 --===============7506172127131680336==-- From xen-users-bounces@lists.xen.org Wed Mar 27 18:36:41 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:36: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 1UKvCY-000062-Ga; Wed, 27 Mar 2013 18:35:58 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKvCX-00005w-Vj for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:35:58 +0000 Received: from [85.158.138.51:11508] by server-13.bemta-3.messagelabs.com id 51/18-25744-D0C33515; Wed, 27 Mar 2013 18:35:57 +0000 X-Env-Sender: delentef@gmail.com X-Msg-Ref: server-15.tower-174.messagelabs.com!1364409356!26597299!1 X-Originating-IP: [74.125.82.182] X-SpamReason: No, hits=2.0 required=7.0 tests=HTML_30_40,HTML_MESSAGE, HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18465 invoked from network); 27 Mar 2013 18:35:56 -0000 Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 18:35:56 -0000 Received: by mail-we0-f182.google.com with SMTP id k14so4719035wer.13 for ; Wed, 27 Mar 2013 11:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=P9TKbsSiDiR780GUo7LuYRToeUTaz31QT+BCcxXx8tQ=; b=UPlLtpUTqmoDgpJGEz76KKMIz/jToI5lDUBoPmvT2/gBhgGn1fLZHyym+lkwf89tAm +FGVfPaPLCLXxdK9jleJsDSIwUtNXoFB/V2SZGoJqWELDyaNJlfJnCVH6sNfO5wUJC5D /rK1vS+lqdB9S6JR1hzyC3jAvHpV2huuHxV+JhL1bafmn0yGA9FQ8oo/81n1eQuunHtn DHXOgyFL7Z7h4zYTS5gK6j5jAAOB3S1zu4IqQyoLwBTPE9Ki9WhWtG8O7g6dEmOQvUoM gQ4xHJobWxKgkepaD7jEPZXk/l9eMs07w9y8BFU2HEYd4u910R/6hjPH6YOvUGZT8CGO byBA== MIME-Version: 1.0 X-Received: by 10.180.77.9 with SMTP id o9mr11691657wiw.16.1364409356321; Wed, 27 Mar 2013 11:35:56 -0700 (PDT) Received: by 10.194.39.167 with HTTP; Wed, 27 Mar 2013 11:35:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 19:35:56 +0100 Message-ID: From: Fabrice Delente To: Sean Greenslade Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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="===============7506172127131680336==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7506172127131680336== Content-Type: multipart/alternative; boundary=f46d043d66c3030b2504d8ec4fa3 --f46d043d66c3030b2504d8ec4fa3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, thanks for the hint, I'll look into that. =E2=80=8B --f46d043d66c3030b2504d8ec4fa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Ok, thanks for the hint, I'll look into that.
    =E2= =80=8B
    --f46d043d66c3030b2504d8ec4fa3-- --===============7506172127131680336== 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 --===============7506172127131680336==-- From xen-users-bounces@lists.xen.org Wed Mar 27 18:51:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:51: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 1UKvQg-0000Yc-Gd; Wed, 27 Mar 2013 18:50:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKvQe-0000YO-MD for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:50:32 +0000 Received: from [85.158.137.99:56270] by server-13.bemta-3.messagelabs.com id FA/C3-25744-77F33515; Wed, 27 Mar 2013 18:50:31 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1364410229!17079055!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4360 invoked from network); 27 Mar 2013 18:50:31 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-11.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2013 18:50:31 -0000 Date: Wed, 27 Mar 2013 18:50:28 +0000 From: Mike To: Sean Greenslade Message-ID: <20130327185028.GA26867@64-142-29-25.dsl.static.sonic.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: xen-users@lists.xen.org, Fabrice Delente Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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 Sean Greenslade wrote: > Fabrice Delente wrote: >> physdev match: using --physdev-out in the OUTPUT, FORWARD and >> POSTROUTING chains for non-bridged traffic is not supported anymore. > > This means you have some rules in your iptables that aren't supported. > If this is any indication of what yous issues are, it's that iptables > is misconfigured. You may want to check over your rules table and make > sure they're all sane. No, this only means that you're using --physdev-out somewhere in the rules. Even if you're only using it in a sane fashion--for bridged traffic--the message still appears. When you modify the rules, it appears once for every usage. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 18:51:30 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:51: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 1UKvQg-0000Yc-Gd; Wed, 27 Mar 2013 18:50:34 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKvQe-0000YO-MD for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:50:32 +0000 Received: from [85.158.137.99:56270] by server-13.bemta-3.messagelabs.com id FA/C3-25744-77F33515; Wed, 27 Mar 2013 18:50:31 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-11.tower-217.messagelabs.com!1364410229!17079055!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4360 invoked from network); 27 Mar 2013 18:50:31 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-11.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2013 18:50:31 -0000 Date: Wed, 27 Mar 2013 18:50:28 +0000 From: Mike To: Sean Greenslade Message-ID: <20130327185028.GA26867@64-142-29-25.dsl.static.sonic.net> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: xen-users@lists.xen.org, Fabrice Delente Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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 Sean Greenslade wrote: > Fabrice Delente wrote: >> physdev match: using --physdev-out in the OUTPUT, FORWARD and >> POSTROUTING chains for non-bridged traffic is not supported anymore. > > This means you have some rules in your iptables that aren't supported. > If this is any indication of what yous issues are, it's that iptables > is misconfigured. You may want to check over your rules table and make > sure they're all sane. No, this only means that you're using --physdev-out somewhere in the rules. Even if you're only using it in a sane fashion--for bridged traffic--the message still appears. When you modify the rules, it appears once for every usage. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 18:57:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:57: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 1UKvWe-0000wD-2T; Wed, 27 Mar 2013 18:56:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKvWc-0000vz-Jf for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:56:42 +0000 Received: from [193.109.254.147:15675] by server-12.bemta-14.messagelabs.com id AF/48-05449-9E043515; Wed, 27 Mar 2013 18:56:41 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1364410533!8690600!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6897 invoked from network); 27 Mar 2013 18:55:46 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 18:55:46 -0000 Received: by mail-wi0-f179.google.com with SMTP id hn17so2546756wib.12 for ; Wed, 27 Mar 2013 11:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gW3JCdjZ5fC6CWtKu2dyi5dvPmW5wbvBvBjIEf6UbDs=; b=kmz0OZzTECMK7a8nZw7AEu9apDrkEgeboaa224NUPA3GZ6/7Wg5vHYu37zNC8XvI2i 1Zxlrl7OTDqGqRPBAGTxyDesbN42Mx8yqZlZn2tRbsyvuCrdlYtu+EsC74R9T5Ax5gKG pol2OdQ3oZ/CvzDkzystYTS8YTIJSclxXjIt0SvJkLThfE5n6mR6kX4SxXNHRgoSngqo WUxWmPAsUp2pMORfpx0//agz1iUd1xeN+uaV5sgqhFpmeAFQgTxLM3VIFrQOaNm45TIy 1oBNrcSako/SOEk3xaKPBXfNmWlswBLtkILQpIMTpOWvz/P0GNXrGLR4ry0EQgMf5zWs 9aQA== X-Received: by 10.194.103.72 with SMTP id fu8mr33480027wjb.42.1364410533844; Wed, 27 Mar 2013 11:55:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.139.72 with HTTP; Wed, 27 Mar 2013 11:55:13 -0700 (PDT) In-Reply-To: <20130327185028.GA26867@64-142-29-25.dsl.static.sonic.net> References: <20130327185028.GA26867@64-142-29-25.dsl.static.sonic.net> From: Sean Greenslade Date: Wed, 27 Mar 2013 14:55:13 -0400 Message-ID: To: Mike Cc: xen-users@lists.xen.org, Fabrice Delente Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 2:50 PM, Mike wrote: > Sean Greenslade wrote: >> Fabrice Delente wrote: >>> physdev match: using --physdev-out in the OUTPUT, FORWARD and >>> POSTROUTING chains for non-bridged traffic is not supported anymore. >> >> This means you have some rules in your iptables that aren't supported. >> If this is any indication of what yous issues are, it's that iptables >> is misconfigured. You may want to check over your rules table and make >> sure they're all sane. > > No, this only means that you're using --physdev-out somewhere in the > rules. Even if you're only using it in a sane fashion--for bridged > traffic--the message still appears. When you modify the rules, it > appears once for every usage. Oops, didn't know that. Thanks for the correction, -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 18:57:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 18:57: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 1UKvWe-0000wD-2T; Wed, 27 Mar 2013 18:56:44 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKvWc-0000vz-Jf for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:56:42 +0000 Received: from [193.109.254.147:15675] by server-12.bemta-14.messagelabs.com id AF/48-05449-9E043515; Wed, 27 Mar 2013 18:56:41 +0000 X-Env-Sender: zootboysean@gmail.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1364410533!8690600!1 X-Originating-IP: [209.85.212.179] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6897 invoked from network); 27 Mar 2013 18:55:46 -0000 Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 18:55:46 -0000 Received: by mail-wi0-f179.google.com with SMTP id hn17so2546756wib.12 for ; Wed, 27 Mar 2013 11:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gW3JCdjZ5fC6CWtKu2dyi5dvPmW5wbvBvBjIEf6UbDs=; b=kmz0OZzTECMK7a8nZw7AEu9apDrkEgeboaa224NUPA3GZ6/7Wg5vHYu37zNC8XvI2i 1Zxlrl7OTDqGqRPBAGTxyDesbN42Mx8yqZlZn2tRbsyvuCrdlYtu+EsC74R9T5Ax5gKG pol2OdQ3oZ/CvzDkzystYTS8YTIJSclxXjIt0SvJkLThfE5n6mR6kX4SxXNHRgoSngqo WUxWmPAsUp2pMORfpx0//agz1iUd1xeN+uaV5sgqhFpmeAFQgTxLM3VIFrQOaNm45TIy 1oBNrcSako/SOEk3xaKPBXfNmWlswBLtkILQpIMTpOWvz/P0GNXrGLR4ry0EQgMf5zWs 9aQA== X-Received: by 10.194.103.72 with SMTP id fu8mr33480027wjb.42.1364410533844; Wed, 27 Mar 2013 11:55:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.139.72 with HTTP; Wed, 27 Mar 2013 11:55:13 -0700 (PDT) In-Reply-To: <20130327185028.GA26867@64-142-29-25.dsl.static.sonic.net> References: <20130327185028.GA26867@64-142-29-25.dsl.static.sonic.net> From: Sean Greenslade Date: Wed, 27 Mar 2013 14:55:13 -0400 Message-ID: To: Mike Cc: xen-users@lists.xen.org, Fabrice Delente Subject: Re: [Xen-users] Can't contact dom0 but can contact dom1, dom2, etc. X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 2:50 PM, Mike wrote: > Sean Greenslade wrote: >> Fabrice Delente wrote: >>> physdev match: using --physdev-out in the OUTPUT, FORWARD and >>> POSTROUTING chains for non-bridged traffic is not supported anymore. >> >> This means you have some rules in your iptables that aren't supported. >> If this is any indication of what yous issues are, it's that iptables >> is misconfigured. You may want to check over your rules table and make >> sure they're all sane. > > No, this only means that you're using --physdev-out somewhere in the > rules. Even if you're only using it in a sane fashion--for bridged > traffic--the message still appears. When you modify the rules, it > appears once for every usage. Oops, didn't know that. Thanks for the correction, -- --Zootboy Sent from some sort of computing device. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 19:21:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 19:21: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 1UKvtz-00021J-Sl; Wed, 27 Mar 2013 19:20:51 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKue8-0006P4-Fo for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:00:24 +0000 Received: from [85.158.137.99:38859] by server-11.bemta-3.messagelabs.com id BE/F3-01263-7B333515; Wed, 27 Mar 2013 18:00:23 +0000 X-Env-Sender: fabian.koeslin@tu-harburg.de X-Msg-Ref: server-5.tower-217.messagelabs.com!1364407217!13763670!1 X-Originating-IP: [134.28.202.138] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12930 invoked from network); 27 Mar 2013 18:00:17 -0000 Received: from smtp3.rz.tu-harburg.de (HELO smtp3.rz.tu-harburg.de) (134.28.202.138) by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Mar 2013 18:00:17 -0000 Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r2RI0Gil012905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Mar 2013 19:00:16 +0100 Received: from fabian-koslins-macbook-pro.fritz.box (p4FD54633.dip.t-dialin.net [79.213.70.51]) (user=smfk2074 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r2RI0Dx3007292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Mar 2013 19:00:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2013-13; t=1364407216; bh=FSopzsg0b/5iyJUIcA1fC1daDeX/gnXumKDtB3oDMtA=; h=Subject:Mime-Version:Content-Type:From:Resent-From:Date: Resent-Date:Resent-To:Message-Id:To; b=QRRTiz4PMLai864wiXgny4uk9q4SI3o1yFpJnf0DtodUf9W2qkrAJ24ugLDu8sOOz dlLF7TkFevtdlRM33TVSaiCGkQrF8mxrzWjqjpE5J7VV3rMNCq/veQ55ShwHsbSaJS h+YmHQGAwlYfQWqF/vmqGN2Zpc7EOiJLKg2FHwUE= Resent-Message-Id: <201303271800.r2RI0Dx3007292@mail.tu-harburg.de> Mime-Version: 1.0 (Apple Message framework v1283) From: =?iso-8859-1?Q?Fabian_K=F6slin?= Resent-From: =?iso-8859-1?Q?Fabian_K=F6slin?= Date: Wed, 27 Mar 2013 17:30:40 +0100 Resent-Date: Wed, 27 Mar 2013 19:00:13 +0100 Resent-To: xen-users@lists.xen.org Message-Id: To: xen-users@lists.xen.org X-Mailer: Apple Mail (2.1283) X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 X-Mailman-Approved-At: Wed, 27 Mar 2013 19:20:49 +0000 Subject: [Xen-users] using xen with sdl and custom vga resolution X-BeenThere: xen-users@lists.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="===============0967724630719325969==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0967724630719325969== Content-Type: multipart/signed; boundary="Apple-Mail=_27A89CDC-A67E-4E7E-A22B-D6F600C01BAE"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_27A89CDC-A67E-4E7E-A22B-D6F600C01BAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hallo everybody, I'm trying to use a Xen HVM Windows 7 Guest on a Debian Wheezy dom0. I = connect to the DomU via SDL. Quite everything is working like I want.=20 The only Problem left is that I cannot select the vga resolution inside = the DomU. My monitor required a resolution of 1440x768. The only = available mode with a width of 1440 is 1440x900. Is there any way to make this mode available?=20 I tried the stdvga=3D0 and the stdvga=3D1 option and set the video = memory to 16. =20 I don't want to use vga passthrough because I use a ps/2 keyboard an = mouse and have no way to connect this direct to the DomU. I would be happy If anybody have a solution for me. cheers, Fabian Koeslin=20 --Apple-Mail=_27A89CDC-A67E-4E7E-A22B-D6F600C01BAE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICDwD1bgABAAKSIw8vIARIdzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQGEwJERTEc MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWDAeFw0x MjExMjExMjA5MjhaFw0xMzExMjIxMjA5MjhaMCYxCzAJBgNVBAYTAkRFMRcwFQYDVQQDDA5GYWJp YW4gS8O2c2xpbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN+mXwujYQN92tCsU51y w/986emql/+lcpYwFhRy8IyVKhSTup+dKpzoXnI9HPOMHCKO1Bc4VOr4A54AKDNyi5C0HDkweLUq kI3VnheaMnE27cP5IOltYO9x843zkydqnl0FotdToWyUWU84oJvpgSzuNSDU/9YKZniaOTfoErbj OdyD1Tkwkykuw9+25cpsOgkBddFuLiMpoDCThKKacTwNL/6IoSpsxsNOD+b7irdv5hbmSAQjCW9/ R5zCJ16R+agLrnK82cgOWaLS7pFMHCBtIu+7Ub4IfJs+fY7HEsKS4JqooO5xkQU06flEowWDOx91 bA1Xokxv4S59y9YW1fUCAwEAAaOCAhgwggIUMIGlBggrBgEFBQcBAQSBmDCBlTBRBggrBgEFBQcw AoZFaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFz czFfTDFfQ0FfSVguY3J0MEAGCCsGAQUFBzABhjRodHRwOi8vb2NzcC5peC50Y2NsYXNzMS50Y3Vu aXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlMB8GA1UdIwQYMBaAFOm4KB1Gz/zN+E6bxe5LYOvYOz/R MAwGA1UdEwEB/wQCMAAwSgYDVR0gBEMwQTA/BgkqghQALAEBAQEwMjAwBggrBgEFBQcCARYkaHR0 cDovL3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4GA1UdDwEB/wQEAwIE8DAdBgNVHQ4E FgQUoH8kRy02TS8gXOtce956tBpC6jcwYgYDVR0fBFswWTBXoFWgU4ZRaHR0cDovL2NybC5peC50 Y2NsYXNzMS50Y3VuaXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y19DbGFzczFfTDFf Q0FfSVguY3JsMDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQB gjcUAgIwJwYDVR0RBCAwHoEcZmFiaWFuLmtvZXNsaW5AdHUtaGFyYnVyZy5kZTANBgkqhkiG9w0B AQUFAAOCAQEAHApYgKRpYo0irwU+N/zPMC1Xrc7JWqvUV1KvPIBrIg2I8qxobA4HlwVt43UNBerV v1R3YPscj0hcFJxstk2261em7tDLJRpt2UWrQMauJtGWOq4f5/Jizox0O7d2I10nqRvD7biRpnP+ lWS/f0q7QZ3zI+SODMOpQBJ4foCF+0b/hsau2qezUzJgGbpGmIOj79iaJvhUw258hV+gw4TwNiA+ eFTtbG594sRrsCdE5TiV+XfxKmnDB9atSeDYEpZHPpEIvfF5Xq+khWTyD5tMSSAn9SwvsWcoDsMd mkghf5uaVnZKUdVmVgK+4ZrqBL/2soRIw/Akk4pr9fVeGbaxiTGCA2AwggNcAgEBMIGPMHwxCzAJ BgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxUQyBUcnVz dENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBDbGFzcyAxIEwx IENBIElYAg8A9W4AAQACkiMPLyAESHcwCQYFKw4DAhoFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzI3MTgwMDE0WjAjBgkqhkiG9w0BCQQxFgQU5okd 7FastCl8AT58yjGKuvoSg+UwgaAGCSsGAQQBgjcQBDGBkjCBjzB8MQswCQYDVQQGEwJERTEcMBoG A1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg MSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIPAPVuAAEA ApIjDy8gBEh3MIGiBgsqhkiG9w0BCRACCzGBkqCBjzB8MQswCQYDVQQGEwJERTEcMBoGA1UEChMT VEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBD QTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIPAPVuAAEAApIjDy8g BEh3MA0GCSqGSIb3DQEBAQUABIIBACChiM1Y+ZL8gzh1V/6CyMLdBpJiKEvvxTUmLYHCV2j38gpY wle+QnrkFjFHms31RE/xAb7b2oK8Awz5WHLg/XETl/mmMoqFjT8Pi3PKHfdYfrze6p3iRomwCOR0 gv7V3V9mQ/XCqrTfhWlT7cT8Tr86bVm7w2jTvUM+Ctxt6URXLiJN7+0ZWrSeJbyFGjrLvxU3cfND fBVxE691hsJVRE6kjhbWb4HkiJ24J3dwbj3ZSx7p5wzsnYfzYKO1dxzaoRwVnEzVrjp8TX1SVdkS R6/Oh5gVQLhWo6CtvqhQKDuKnwcSHkF8FYKCK/hzed5S2m49G1C2Zs88ktFXE0Z/TY8AAAAAAAA= --Apple-Mail=_27A89CDC-A67E-4E7E-A22B-D6F600C01BAE-- --===============0967724630719325969== 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 --===============0967724630719325969==-- From xen-users-bounces@lists.xen.org Wed Mar 27 19:21:43 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 19:21: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 1UKvtz-00021J-Sl; Wed, 27 Mar 2013 19:20:51 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKue8-0006P4-Fo for xen-users@lists.xen.org; Wed, 27 Mar 2013 18:00:24 +0000 Received: from [85.158.137.99:38859] by server-11.bemta-3.messagelabs.com id BE/F3-01263-7B333515; Wed, 27 Mar 2013 18:00:23 +0000 X-Env-Sender: fabian.koeslin@tu-harburg.de X-Msg-Ref: server-5.tower-217.messagelabs.com!1364407217!13763670!1 X-Originating-IP: [134.28.202.138] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12930 invoked from network); 27 Mar 2013 18:00:17 -0000 Received: from smtp3.rz.tu-harburg.de (HELO smtp3.rz.tu-harburg.de) (134.28.202.138) by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Mar 2013 18:00:17 -0000 Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r2RI0Gil012905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Mar 2013 19:00:16 +0100 Received: from fabian-koslins-macbook-pro.fritz.box (p4FD54633.dip.t-dialin.net [79.213.70.51]) (user=smfk2074 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r2RI0Dx3007292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Mar 2013 19:00:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2013-13; t=1364407216; bh=FSopzsg0b/5iyJUIcA1fC1daDeX/gnXumKDtB3oDMtA=; h=Subject:Mime-Version:Content-Type:From:Resent-From:Date: Resent-Date:Resent-To:Message-Id:To; b=QRRTiz4PMLai864wiXgny4uk9q4SI3o1yFpJnf0DtodUf9W2qkrAJ24ugLDu8sOOz dlLF7TkFevtdlRM33TVSaiCGkQrF8mxrzWjqjpE5J7VV3rMNCq/veQ55ShwHsbSaJS h+YmHQGAwlYfQWqF/vmqGN2Zpc7EOiJLKg2FHwUE= Resent-Message-Id: <201303271800.r2RI0Dx3007292@mail.tu-harburg.de> Mime-Version: 1.0 (Apple Message framework v1283) From: =?iso-8859-1?Q?Fabian_K=F6slin?= Resent-From: =?iso-8859-1?Q?Fabian_K=F6slin?= Date: Wed, 27 Mar 2013 17:30:40 +0100 Resent-Date: Wed, 27 Mar 2013 19:00:13 +0100 Resent-To: xen-users@lists.xen.org Message-Id: To: xen-users@lists.xen.org X-Mailer: Apple Mail (2.1283) X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 X-Mailman-Approved-At: Wed, 27 Mar 2013 19:20:49 +0000 Subject: [Xen-users] using xen with sdl and custom vga resolution X-BeenThere: xen-users@lists.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="===============0967724630719325969==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============0967724630719325969== Content-Type: multipart/signed; boundary="Apple-Mail=_27A89CDC-A67E-4E7E-A22B-D6F600C01BAE"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_27A89CDC-A67E-4E7E-A22B-D6F600C01BAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hallo everybody, I'm trying to use a Xen HVM Windows 7 Guest on a Debian Wheezy dom0. I = connect to the DomU via SDL. Quite everything is working like I want.=20 The only Problem left is that I cannot select the vga resolution inside = the DomU. My monitor required a resolution of 1440x768. The only = available mode with a width of 1440 is 1440x900. Is there any way to make this mode available?=20 I tried the stdvga=3D0 and the stdvga=3D1 option and set the video = memory to 16. =20 I don't want to use vga passthrough because I use a ps/2 keyboard an = mouse and have no way to connect this direct to the DomU. I would be happy If anybody have a solution for me. cheers, Fabian Koeslin=20 --Apple-Mail=_27A89CDC-A67E-4E7E-A22B-D6F600C01BAE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICDwD1bgABAAKSIw8vIARIdzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQGEwJERTEc MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWDAeFw0x MjExMjExMjA5MjhaFw0xMzExMjIxMjA5MjhaMCYxCzAJBgNVBAYTAkRFMRcwFQYDVQQDDA5GYWJp YW4gS8O2c2xpbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN+mXwujYQN92tCsU51y w/986emql/+lcpYwFhRy8IyVKhSTup+dKpzoXnI9HPOMHCKO1Bc4VOr4A54AKDNyi5C0HDkweLUq kI3VnheaMnE27cP5IOltYO9x843zkydqnl0FotdToWyUWU84oJvpgSzuNSDU/9YKZniaOTfoErbj OdyD1Tkwkykuw9+25cpsOgkBddFuLiMpoDCThKKacTwNL/6IoSpsxsNOD+b7irdv5hbmSAQjCW9/ R5zCJ16R+agLrnK82cgOWaLS7pFMHCBtIu+7Ub4IfJs+fY7HEsKS4JqooO5xkQU06flEowWDOx91 bA1Xokxv4S59y9YW1fUCAwEAAaOCAhgwggIUMIGlBggrBgEFBQcBAQSBmDCBlTBRBggrBgEFBQcw AoZFaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFz czFfTDFfQ0FfSVguY3J0MEAGCCsGAQUFBzABhjRodHRwOi8vb2NzcC5peC50Y2NsYXNzMS50Y3Vu aXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlMB8GA1UdIwQYMBaAFOm4KB1Gz/zN+E6bxe5LYOvYOz/R MAwGA1UdEwEB/wQCMAAwSgYDVR0gBEMwQTA/BgkqghQALAEBAQEwMjAwBggrBgEFBQcCARYkaHR0 cDovL3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4GA1UdDwEB/wQEAwIE8DAdBgNVHQ4E FgQUoH8kRy02TS8gXOtce956tBpC6jcwYgYDVR0fBFswWTBXoFWgU4ZRaHR0cDovL2NybC5peC50 Y2NsYXNzMS50Y3VuaXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y19DbGFzczFfTDFf Q0FfSVguY3JsMDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQB gjcUAgIwJwYDVR0RBCAwHoEcZmFiaWFuLmtvZXNsaW5AdHUtaGFyYnVyZy5kZTANBgkqhkiG9w0B AQUFAAOCAQEAHApYgKRpYo0irwU+N/zPMC1Xrc7JWqvUV1KvPIBrIg2I8qxobA4HlwVt43UNBerV v1R3YPscj0hcFJxstk2261em7tDLJRpt2UWrQMauJtGWOq4f5/Jizox0O7d2I10nqRvD7biRpnP+ lWS/f0q7QZ3zI+SODMOpQBJ4foCF+0b/hsau2qezUzJgGbpGmIOj79iaJvhUw258hV+gw4TwNiA+ eFTtbG594sRrsCdE5TiV+XfxKmnDB9atSeDYEpZHPpEIvfF5Xq+khWTyD5tMSSAn9SwvsWcoDsMd mkghf5uaVnZKUdVmVgK+4ZrqBL/2soRIw/Akk4pr9fVeGbaxiTGCA2AwggNcAgEBMIGPMHwxCzAJ BgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxUQyBUcnVz dENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBDbGFzcyAxIEwx IENBIElYAg8A9W4AAQACkiMPLyAESHcwCQYFKw4DAhoFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzI3MTgwMDE0WjAjBgkqhkiG9w0BCQQxFgQU5okd 7FastCl8AT58yjGKuvoSg+UwgaAGCSsGAQQBgjcQBDGBkjCBjzB8MQswCQYDVQQGEwJERTEcMBoG A1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg MSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIPAPVuAAEA ApIjDy8gBEh3MIGiBgsqhkiG9w0BCRACCzGBkqCBjzB8MQswCQYDVQQGEwJERTEcMBoGA1UEChMT VEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBD QTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIPAPVuAAEAApIjDy8g BEh3MA0GCSqGSIb3DQEBAQUABIIBACChiM1Y+ZL8gzh1V/6CyMLdBpJiKEvvxTUmLYHCV2j38gpY wle+QnrkFjFHms31RE/xAb7b2oK8Awz5WHLg/XETl/mmMoqFjT8Pi3PKHfdYfrze6p3iRomwCOR0 gv7V3V9mQ/XCqrTfhWlT7cT8Tr86bVm7w2jTvUM+Ctxt6URXLiJN7+0ZWrSeJbyFGjrLvxU3cfND fBVxE691hsJVRE6kjhbWb4HkiJ24J3dwbj3ZSx7p5wzsnYfzYKO1dxzaoRwVnEzVrjp8TX1SVdkS R6/Oh5gVQLhWo6CtvqhQKDuKnwcSHkF8FYKCK/hzed5S2m49G1C2Zs88ktFXE0Z/TY8AAAAAAAA= --Apple-Mail=_27A89CDC-A67E-4E7E-A22B-D6F600C01BAE-- --===============0967724630719325969== 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 --===============0967724630719325969==-- From xen-users-bounces@lists.xen.org Wed Mar 27 19:21:46 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 19:21: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 1UKvtz-00021A-9b; Wed, 27 Mar 2013 19:20:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKuYt-0006J1-IQ for xen-users@lists.xen.org; Wed, 27 Mar 2013 17:54:59 +0000 Received: from [85.158.139.83:31592] by server-16.bemta-5.messagelabs.com id F4/C0-02543-27233515; Wed, 27 Mar 2013 17:54:58 +0000 X-Env-Sender: fabian.koeslin@tu-harburg.de X-Msg-Ref: server-9.tower-182.messagelabs.com!1364406897!27217292!1 X-Originating-IP: [134.28.202.138] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28632 invoked from network); 27 Mar 2013 17:54:58 -0000 Received: from smtp3.rz.tu-harburg.de (HELO smtp3.rz.tu-harburg.de) (134.28.202.138) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Mar 2013 17:54:58 -0000 Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r2RHsvDK012365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Mar 2013 18:54:57 +0100 Received: from [192.168.0.20] (p4FD54633.dip.t-dialin.net [79.213.70.51]) (user=smfk2074 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r2RHsrpT032744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Mar 2013 18:54:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2013-13; t=1364406897; bh=kBqBsWEABDHaHxqDr0rHky24Jg+Bpwl5wXX2BV7I6hc=; h=From:Content-Type:Subject:Date:Message-Id:To:Mime-Version; b=Dfd/eBIwrqWQImSCY21LnsEI92VroR3V2+0LkXv2QM0hP5YtMVgzHBcAG3tXd26SB mijasR8Svnc7m/wXDgObo0SZCBXPSSYAxryoGaoX63vs98S9QcA8KLGS1kcg61cTK8 dVMbF3YRopu+lUsGb+P6LfnTK2CafO/cro9cYfMg= From: =?iso-8859-1?Q?Fabian_K=F6slin?= Date: Wed, 27 Mar 2013 17:30:40 +0100 Message-Id: To: xen-users@lists.xen.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 X-Mailman-Approved-At: Wed, 27 Mar 2013 19:20:49 +0000 Subject: [Xen-users] using xen with sdl and custom vga resolution X-BeenThere: xen-users@lists.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="===============4883444058297878812==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4883444058297878812== Content-Type: multipart/signed; boundary="Apple-Mail=_2A5D5FDC-0567-4174-AC0C-2F1410BA3738"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_2A5D5FDC-0567-4174-AC0C-2F1410BA3738 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hallo everybody, I'm trying to use a Xen HVM Windows 7 Guest on a Debian Wheezy dom0. I = connect to the DomU via SDL. Quite everything is working like I want.=20 The only Problem left is that I cannot select the vga resolution inside = the DomU. My monitor required a resolution of 1440x768. The only = available mode with a width of 1440 is 1440x900. Is there any way to make this mode available?=20 I don't want to use vga passthrough because I use a ps/2 keyboard an = mouse and have no way to connect this direct to the DomU. I would be happy If anybody have a solution for me. cheers, Fabian Koeslin=20 --Apple-Mail=_2A5D5FDC-0567-4174-AC0C-2F1410BA3738 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICDwD1bgABAAKSIw8vIARIdzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQGEwJERTEc MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWDAeFw0x MjExMjExMjA5MjhaFw0xMzExMjIxMjA5MjhaMCYxCzAJBgNVBAYTAkRFMRcwFQYDVQQDDA5GYWJp YW4gS8O2c2xpbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN+mXwujYQN92tCsU51y w/986emql/+lcpYwFhRy8IyVKhSTup+dKpzoXnI9HPOMHCKO1Bc4VOr4A54AKDNyi5C0HDkweLUq kI3VnheaMnE27cP5IOltYO9x843zkydqnl0FotdToWyUWU84oJvpgSzuNSDU/9YKZniaOTfoErbj OdyD1Tkwkykuw9+25cpsOgkBddFuLiMpoDCThKKacTwNL/6IoSpsxsNOD+b7irdv5hbmSAQjCW9/ R5zCJ16R+agLrnK82cgOWaLS7pFMHCBtIu+7Ub4IfJs+fY7HEsKS4JqooO5xkQU06flEowWDOx91 bA1Xokxv4S59y9YW1fUCAwEAAaOCAhgwggIUMIGlBggrBgEFBQcBAQSBmDCBlTBRBggrBgEFBQcw AoZFaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFz czFfTDFfQ0FfSVguY3J0MEAGCCsGAQUFBzABhjRodHRwOi8vb2NzcC5peC50Y2NsYXNzMS50Y3Vu aXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlMB8GA1UdIwQYMBaAFOm4KB1Gz/zN+E6bxe5LYOvYOz/R MAwGA1UdEwEB/wQCMAAwSgYDVR0gBEMwQTA/BgkqghQALAEBAQEwMjAwBggrBgEFBQcCARYkaHR0 cDovL3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4GA1UdDwEB/wQEAwIE8DAdBgNVHQ4E FgQUoH8kRy02TS8gXOtce956tBpC6jcwYgYDVR0fBFswWTBXoFWgU4ZRaHR0cDovL2NybC5peC50 Y2NsYXNzMS50Y3VuaXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y19DbGFzczFfTDFf Q0FfSVguY3JsMDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQB gjcUAgIwJwYDVR0RBCAwHoEcZmFiaWFuLmtvZXNsaW5AdHUtaGFyYnVyZy5kZTANBgkqhkiG9w0B AQUFAAOCAQEAHApYgKRpYo0irwU+N/zPMC1Xrc7JWqvUV1KvPIBrIg2I8qxobA4HlwVt43UNBerV v1R3YPscj0hcFJxstk2261em7tDLJRpt2UWrQMauJtGWOq4f5/Jizox0O7d2I10nqRvD7biRpnP+ lWS/f0q7QZ3zI+SODMOpQBJ4foCF+0b/hsau2qezUzJgGbpGmIOj79iaJvhUw258hV+gw4TwNiA+ eFTtbG594sRrsCdE5TiV+XfxKmnDB9atSeDYEpZHPpEIvfF5Xq+khWTyD5tMSSAn9SwvsWcoDsMd mkghf5uaVnZKUdVmVgK+4ZrqBL/2soRIw/Akk4pr9fVeGbaxiTGCA2AwggNcAgEBMIGPMHwxCzAJ BgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxUQyBUcnVz dENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBDbGFzcyAxIEwx IENBIElYAg8A9W4AAQACkiMPLyAESHcwCQYFKw4DAhoFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzI3MTYzMDQxWjAjBgkqhkiG9w0BCQQxFgQUFOX4 u2rbM9lFBhlXI/MWg+57uwcwgaAGCSsGAQQBgjcQBDGBkjCBjzB8MQswCQYDVQQGEwJERTEcMBoG A1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg MSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIPAPVuAAEA ApIjDy8gBEh3MIGiBgsqhkiG9w0BCRACCzGBkqCBjzB8MQswCQYDVQQGEwJERTEcMBoGA1UEChMT VEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBD QTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIPAPVuAAEAApIjDy8g BEh3MA0GCSqGSIb3DQEBAQUABIIBAJ46abeGv3P8FdD8i0htx0YdPlqcXjiIRkF5xlPqsB0MYvHv 5FjxM2LACc21gSTJ5CThGqfwsXZJYs4P14t1pQM/20UYURZVhqsyaB+lkQDRw5I++3Y8OHS28TH4 Mh+p4AB0nfXw5AC5uz5vSfB798T3MP1YtcIVBoLpsz/hhJeHcTXult1SRKf4CZ40ocF0ZjPVWSYE rKBdlkWdn1GarkCryJOJ1zu+FtKFHw2HaJYMUmJqH+FvLRhOLYajDpGfqYQqi9ASS4gE8YzEgICE VezFj2qjE3NSsnQsU5s6wfB8Ykp0TsT+y7qvukiQdwc4t2PBBaY/FDIexmmvTyqQ8N8AAAAAAAA= --Apple-Mail=_2A5D5FDC-0567-4174-AC0C-2F1410BA3738-- --===============4883444058297878812== 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 --===============4883444058297878812==-- From xen-users-bounces@lists.xen.org Wed Mar 27 19:21:46 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 19:21: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 1UKvtz-00021A-9b; Wed, 27 Mar 2013 19:20:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKuYt-0006J1-IQ for xen-users@lists.xen.org; Wed, 27 Mar 2013 17:54:59 +0000 Received: from [85.158.139.83:31592] by server-16.bemta-5.messagelabs.com id F4/C0-02543-27233515; Wed, 27 Mar 2013 17:54:58 +0000 X-Env-Sender: fabian.koeslin@tu-harburg.de X-Msg-Ref: server-9.tower-182.messagelabs.com!1364406897!27217292!1 X-Originating-IP: [134.28.202.138] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28632 invoked from network); 27 Mar 2013 17:54:58 -0000 Received: from smtp3.rz.tu-harburg.de (HELO smtp3.rz.tu-harburg.de) (134.28.202.138) by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Mar 2013 17:54:58 -0000 Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r2RHsvDK012365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Mar 2013 18:54:57 +0100 Received: from [192.168.0.20] (p4FD54633.dip.t-dialin.net [79.213.70.51]) (user=smfk2074 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id r2RHsrpT032744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Mar 2013 18:54:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2013-13; t=1364406897; bh=kBqBsWEABDHaHxqDr0rHky24Jg+Bpwl5wXX2BV7I6hc=; h=From:Content-Type:Subject:Date:Message-Id:To:Mime-Version; b=Dfd/eBIwrqWQImSCY21LnsEI92VroR3V2+0LkXv2QM0hP5YtMVgzHBcAG3tXd26SB mijasR8Svnc7m/wXDgObo0SZCBXPSSYAxryoGaoX63vs98S9QcA8KLGS1kcg61cTK8 dVMbF3YRopu+lUsGb+P6LfnTK2CafO/cro9cYfMg= From: =?iso-8859-1?Q?Fabian_K=F6slin?= Date: Wed, 27 Mar 2013 17:30:40 +0100 Message-Id: To: xen-users@lists.xen.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 X-Mailman-Approved-At: Wed, 27 Mar 2013 19:20:49 +0000 Subject: [Xen-users] using xen with sdl and custom vga resolution X-BeenThere: xen-users@lists.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="===============4883444058297878812==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4883444058297878812== Content-Type: multipart/signed; boundary="Apple-Mail=_2A5D5FDC-0567-4174-AC0C-2F1410BA3738"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_2A5D5FDC-0567-4174-AC0C-2F1410BA3738 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hallo everybody, I'm trying to use a Xen HVM Windows 7 Guest on a Debian Wheezy dom0. I = connect to the DomU via SDL. Quite everything is working like I want.=20 The only Problem left is that I cannot select the vga resolution inside = the DomU. My monitor required a resolution of 1440x768. The only = available mode with a width of 1440 is 1440x900. Is there any way to make this mode available?=20 I don't want to use vga passthrough because I use a ps/2 keyboard an = mouse and have no way to connect this direct to the DomU. I would be happy If anybody have a solution for me. cheers, Fabian Koeslin=20 --Apple-Mail=_2A5D5FDC-0567-4174-AC0C-2F1410BA3738 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSTCCBUUw ggQtoAMCAQICDwD1bgABAAKSIw8vIARIdzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQGEwJERTEc MBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xh c3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWDAeFw0x MjExMjExMjA5MjhaFw0xMzExMjIxMjA5MjhaMCYxCzAJBgNVBAYTAkRFMRcwFQYDVQQDDA5GYWJp YW4gS8O2c2xpbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN+mXwujYQN92tCsU51y w/986emql/+lcpYwFhRy8IyVKhSTup+dKpzoXnI9HPOMHCKO1Bc4VOr4A54AKDNyi5C0HDkweLUq kI3VnheaMnE27cP5IOltYO9x843zkydqnl0FotdToWyUWU84oJvpgSzuNSDU/9YKZniaOTfoErbj OdyD1Tkwkykuw9+25cpsOgkBddFuLiMpoDCThKKacTwNL/6IoSpsxsNOD+b7irdv5hbmSAQjCW9/ R5zCJ16R+agLrnK82cgOWaLS7pFMHCBtIu+7Ub4IfJs+fY7HEsKS4JqooO5xkQU06flEowWDOx91 bA1Xokxv4S59y9YW1fUCAwEAAaOCAhgwggIUMIGlBggrBgEFBQcBAQSBmDCBlTBRBggrBgEFBQcw AoZFaHR0cDovL3d3dy50cnVzdGNlbnRlci5kZS9jZXJ0c2VydmljZXMvY2FjZXJ0cy90Y19jbGFz czFfTDFfQ0FfSVguY3J0MEAGCCsGAQUFBzABhjRodHRwOi8vb2NzcC5peC50Y2NsYXNzMS50Y3Vu aXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlMB8GA1UdIwQYMBaAFOm4KB1Gz/zN+E6bxe5LYOvYOz/R MAwGA1UdEwEB/wQCMAAwSgYDVR0gBEMwQTA/BgkqghQALAEBAQEwMjAwBggrBgEFBQcCARYkaHR0 cDovL3d3dy50cnVzdGNlbnRlci5kZS9ndWlkZWxpbmVzMA4GA1UdDwEB/wQEAwIE8DAdBgNVHQ4E FgQUoH8kRy02TS8gXOtce956tBpC6jcwYgYDVR0fBFswWTBXoFWgU4ZRaHR0cDovL2NybC5peC50 Y2NsYXNzMS50Y3VuaXZlcnNhbC1pLnRydXN0Y2VudGVyLmRlL2NybC92Mi90Y19DbGFzczFfTDFf Q0FfSVguY3JsMDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQB gjcUAgIwJwYDVR0RBCAwHoEcZmFiaWFuLmtvZXNsaW5AdHUtaGFyYnVyZy5kZTANBgkqhkiG9w0B AQUFAAOCAQEAHApYgKRpYo0irwU+N/zPMC1Xrc7JWqvUV1KvPIBrIg2I8qxobA4HlwVt43UNBerV v1R3YPscj0hcFJxstk2261em7tDLJRpt2UWrQMauJtGWOq4f5/Jizox0O7d2I10nqRvD7biRpnP+ lWS/f0q7QZ3zI+SODMOpQBJ4foCF+0b/hsau2qezUzJgGbpGmIOj79iaJvhUw258hV+gw4TwNiA+ eFTtbG594sRrsCdE5TiV+XfxKmnDB9atSeDYEpZHPpEIvfF5Xq+khWTyD5tMSSAn9SwvsWcoDsMd mkghf5uaVnZKUdVmVgK+4ZrqBL/2soRIw/Akk4pr9fVeGbaxiTGCA2AwggNcAgEBMIGPMHwxCzAJ BgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxUQyBUcnVz dENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBDbGFzcyAxIEwx IENBIElYAg8A9W4AAQACkiMPLyAESHcwCQYFKw4DAhoFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzI3MTYzMDQxWjAjBgkqhkiG9w0BCQQxFgQUFOX4 u2rbM9lFBhlXI/MWg+57uwcwgaAGCSsGAQQBgjcQBDGBkjCBjzB8MQswCQYDVQQGEwJERTEcMBoG A1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3Mg MSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIPAPVuAAEA ApIjDy8gBEh3MIGiBgsqhkiG9w0BCRACCzGBkqCBjzB8MQswCQYDVQQGEwJERTEcMBoGA1UEChMT VEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBD QTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBMMSBDQSBJWAIPAPVuAAEAApIjDy8g BEh3MA0GCSqGSIb3DQEBAQUABIIBAJ46abeGv3P8FdD8i0htx0YdPlqcXjiIRkF5xlPqsB0MYvHv 5FjxM2LACc21gSTJ5CThGqfwsXZJYs4P14t1pQM/20UYURZVhqsyaB+lkQDRw5I++3Y8OHS28TH4 Mh+p4AB0nfXw5AC5uz5vSfB798T3MP1YtcIVBoLpsz/hhJeHcTXult1SRKf4CZ40ocF0ZjPVWSYE rKBdlkWdn1GarkCryJOJ1zu+FtKFHw2HaJYMUmJqH+FvLRhOLYajDpGfqYQqi9ASS4gE8YzEgICE VezFj2qjE3NSsnQsU5s6wfB8Ykp0TsT+y7qvukiQdwc4t2PBBaY/FDIexmmvTyqQ8N8AAAAAAAA= --Apple-Mail=_2A5D5FDC-0567-4174-AC0C-2F1410BA3738-- --===============4883444058297878812== 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 --===============4883444058297878812==-- From xen-users-bounces@lists.xen.org Wed Mar 27 19:37:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 19:37: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 1UKw9W-0002oa-Py; Wed, 27 Mar 2013 19:36:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKw9U-0002oR-OA for xen-users@lists.xen.org; Wed, 27 Mar 2013 19:36:52 +0000 Received: from [85.158.138.51:33548] by server-10.bemta-3.messagelabs.com id 1C/9C-19664-F4A43515; Wed, 27 Mar 2013 19:36:47 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-174.messagelabs.com!1364413006!27354505!1 X-Originating-IP: [89.16.177.154] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31808 invoked from network); 27 Mar 2013 19:36:46 -0000 Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154) by server-8.tower-174.messagelabs.com with SMTP; 27 Mar 2013 19:36:46 -0000 Received: (qmail 23923 invoked by uid 634); 27 Mar 2013 19:36:46 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from no-dns-yet.demon.co.uk (HELO [192.168.14.198]) (62.49.66.12) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Wed, 27 Mar 2013 19:36:45 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 27 Mar 2013 19:36:43 +0000 Message-Id: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> References: To: George Dunlap X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: xen-users@lists.xen.org, "cl-mirage@lists.cam.ac.uk List" , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 27 Mar 2013, at 11:23, George Dunlap wrote: > > The FIFO solution makes event delivery a matter of adding items to a > highly structured linked list. The number of event channels for the > interface design has a theoretical maximum of 2^28; the current > implementation is limimited at 2^17, which is over 100,000. The > number is the same for both 32-bit and 64-bit kernels. Is there any reason for such a low default? If I'm not mistaken, every guest needs at least 2 event channels (console, xenstore) and probably has two more for a net and disk device. With stub-domains in the mix, we could easily imagine running 25,000 VMs with a couple of megabytes of RAM each using Mirage (which can boot very low memory guests without too much trouble). This does run into other problems with CPU scheduling and device scalability, but it would be nice if any proposed event channel upgrade went well above this level rather than scrape it. I personally prefer the 4.3 solution (despite the priority hack for the timers) just because the existing limitation is so very trivial to hit. However, I have no view on the level of technical debt that would incur if it subsequently required switching to the FIFO solution in 4.4 and causing yet another round of upgrades. That's your problem; I just want the extra domains :-) -anil _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 19:37:44 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 19:37: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 1UKw9W-0002oa-Py; Wed, 27 Mar 2013 19:36:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKw9U-0002oR-OA for xen-users@lists.xen.org; Wed, 27 Mar 2013 19:36:52 +0000 Received: from [85.158.138.51:33548] by server-10.bemta-3.messagelabs.com id 1C/9C-19664-F4A43515; Wed, 27 Mar 2013 19:36:47 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-174.messagelabs.com!1364413006!27354505!1 X-Originating-IP: [89.16.177.154] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31808 invoked from network); 27 Mar 2013 19:36:46 -0000 Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154) by server-8.tower-174.messagelabs.com with SMTP; 27 Mar 2013 19:36:46 -0000 Received: (qmail 23923 invoked by uid 634); 27 Mar 2013 19:36:46 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from no-dns-yet.demon.co.uk (HELO [192.168.14.198]) (62.49.66.12) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Wed, 27 Mar 2013 19:36:45 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Anil Madhavapeddy In-Reply-To: Date: Wed, 27 Mar 2013 19:36:43 +0000 Message-Id: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> References: To: George Dunlap X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: xen-users@lists.xen.org, "cl-mirage@lists.cam.ac.uk List" , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 27 Mar 2013, at 11:23, George Dunlap wrote: > > The FIFO solution makes event delivery a matter of adding items to a > highly structured linked list. The number of event channels for the > interface design has a theoretical maximum of 2^28; the current > implementation is limimited at 2^17, which is over 100,000. The > number is the same for both 32-bit and 64-bit kernels. Is there any reason for such a low default? If I'm not mistaken, every guest needs at least 2 event channels (console, xenstore) and probably has two more for a net and disk device. With stub-domains in the mix, we could easily imagine running 25,000 VMs with a couple of megabytes of RAM each using Mirage (which can boot very low memory guests without too much trouble). This does run into other problems with CPU scheduling and device scalability, but it would be nice if any proposed event channel upgrade went well above this level rather than scrape it. I personally prefer the 4.3 solution (despite the priority hack for the timers) just because the existing limitation is so very trivial to hit. However, I have no view on the level of technical debt that would incur if it subsequently required switching to the FIFO solution in 4.4 and causing yet another round of upgrades. That's your problem; I just want the extra domains :-) -anil _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 20:10:29 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 20:10: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 1UKwf7-0003lT-Nj; Wed, 27 Mar 2013 20:09:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKwf5-0003lO-QR for Xen-users@lists.xen.org; Wed, 27 Mar 2013 20:09:32 +0000 Received: from [85.158.139.211:52492] by server-1.bemta-5.messagelabs.com id DF/87-14063-AF153515; Wed, 27 Mar 2013 20:09:30 +0000 X-Env-Sender: dreadpiratejeff@gmail.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1364414968!20322185!1 X-Originating-IP: [209.85.219.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21658 invoked from network); 27 Mar 2013 20:09:30 -0000 Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com) (209.85.219.45) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 20:09:30 -0000 Received: by mail-oa0-f45.google.com with SMTP id o6so9347571oag.32 for ; Wed, 27 Mar 2013 13:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=Q60Xnv5EvqGBQz6RQUt7D3STsOaFJoWinmFzZME4cYM=; b=eEgUzil0mSSt68LXT/oLdIOLGNOH5roG4ae3LUSIslMXs9a47UnJ3/G6LZzwbdjTbT B6g+8aHTyrKTKrfBWsvfXj/zlxIlrTKmbnqHnDRlhz1J7oEZth8voNG0QaucYgtcU4yw SZRq/HJmld5maZ+yVElylVrQ4Rse4zFs45664ag+kdsCbWDl/Oi+HpWCh6KayEMH3c3F AN4XQ8BN08CI6pU16Heo3QFQfv8iJDPcyJkAddkeQ32jE6RobATGhM/FUz2aGAh+ZoN9 axOUwUK/6/9s/ATxCmtaG4Z4BYaFiPFMUqbZKzHVLi2ESo90VQHCacUjEnOCsAItWghU 940A== X-Received: by 10.182.66.41 with SMTP id c9mr4359205obt.76.1364414909355; Wed, 27 Mar 2013 13:08:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.154.69 with HTTP; Wed, 27 Mar 2013 13:08:08 -0700 (PDT) From: J Date: Wed, 27 Mar 2013 16:08:08 -0400 Message-ID: To: Xen-users@lists.xen.org Subject: [Xen-users] Where did I go wrong (creating an HVM guest)? X-BeenThere: xen-users@lists.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 OK, I'm not "new" to Xen, but it's been a few years (Xen 3.x) since I last really messed with it. I'm now stuck trying to get back into my recently installed new guest. My host is running Ubuntu 12.04.1 and Xen 4.1 with the xl toolstack. I originally created/installed the guest using virt-manager. The install went well and the guest rebooted successfully and I was able to access it via xl vncviewer guest-name Now, the first problem, where's the config file? Xen 3.x used fairly straight forward config files that were stored in /etc/xen/. virt-install doesn't create that file. I found an sxp format config file in /var/lib/xend/domains/UUID/ that matches my guest. But I'm unable to boot from that. When I try, I get a lot of parser errors and finally complaints about it looking like Python code. So this: sudo xl create /var/lib/xend/domains/UUID/config.sxp doesn't allow me to reboot the guest. I then tried creating a basic old-style config file: builder='hvm' name='precise-hvm' memory=1024 maxmemory=1024 uuid='18069c40-e01f-ddf8-5932-bc6bb6b5bba1' vif='xenbr0' disk=[ 'file:/vms/precise-hvm.img,qcow2,hda' ] I then tried starting the guest there. That also fails because despite what I read here: http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt None of these disk lines are accepted by xl: disk=[ '/vms/precise-hvm.img,,hda' ] disk=[ '/vms/precise-hvm.img,qcow,hda' ] disk=[ '/vms/precise-hvm.img,qcow2,hda' ] disk=[ 'file:/vms/precise-hvm.img,qcow2,hda' ] For each disk line where I specify a format (qcow or qcow2) I get the following output: Parsing config file /etc/xen/precise-hvm.cfg /etc/xen/precise-hvm.cfg:10: warning: parameter `vif' is a single value but should be a list xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000017c510 TOTAL: 0000000000000000->000000003f800000 ENTRY ADDRESS: 00000000001015a0 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000001fb 1GB PAGES: 0x0000000000000000 libxl: error: libxl.c:938:libxl_device_disk_add Invalid or unsupported virtual disk identifier qcow2 cannot add disk 0 to domain: -6 libxl: error: libxl_dm.c:747:libxl__destroy_device_model Couldn't find device model's pid: No such file or directory libxl: error: libxl.c:730:libxl_domain_destroy libxl__destroy_device_model failed for 6 and if I DON'T specify a format, I get this: Parsing config file /etc/xen/precise-hvm.cfg parse error in disk config near ',hda' So I have a file backed guest that "should" be perfectly usable, only I can't figure out how to boot the thing... Can someone point me to a clue to help me catch up to the state of Xen today? Cheers Jeff _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 20:10:29 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 20:10: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 1UKwf7-0003lT-Nj; Wed, 27 Mar 2013 20:09:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKwf5-0003lO-QR for Xen-users@lists.xen.org; Wed, 27 Mar 2013 20:09:32 +0000 Received: from [85.158.139.211:52492] by server-1.bemta-5.messagelabs.com id DF/87-14063-AF153515; Wed, 27 Mar 2013 20:09:30 +0000 X-Env-Sender: dreadpiratejeff@gmail.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1364414968!20322185!1 X-Originating-IP: [209.85.219.45] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21658 invoked from network); 27 Mar 2013 20:09:30 -0000 Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com) (209.85.219.45) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 20:09:30 -0000 Received: by mail-oa0-f45.google.com with SMTP id o6so9347571oag.32 for ; Wed, 27 Mar 2013 13:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=Q60Xnv5EvqGBQz6RQUt7D3STsOaFJoWinmFzZME4cYM=; b=eEgUzil0mSSt68LXT/oLdIOLGNOH5roG4ae3LUSIslMXs9a47UnJ3/G6LZzwbdjTbT B6g+8aHTyrKTKrfBWsvfXj/zlxIlrTKmbnqHnDRlhz1J7oEZth8voNG0QaucYgtcU4yw SZRq/HJmld5maZ+yVElylVrQ4Rse4zFs45664ag+kdsCbWDl/Oi+HpWCh6KayEMH3c3F AN4XQ8BN08CI6pU16Heo3QFQfv8iJDPcyJkAddkeQ32jE6RobATGhM/FUz2aGAh+ZoN9 axOUwUK/6/9s/ATxCmtaG4Z4BYaFiPFMUqbZKzHVLi2ESo90VQHCacUjEnOCsAItWghU 940A== X-Received: by 10.182.66.41 with SMTP id c9mr4359205obt.76.1364414909355; Wed, 27 Mar 2013 13:08:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.154.69 with HTTP; Wed, 27 Mar 2013 13:08:08 -0700 (PDT) From: J Date: Wed, 27 Mar 2013 16:08:08 -0400 Message-ID: To: Xen-users@lists.xen.org Subject: [Xen-users] Where did I go wrong (creating an HVM guest)? X-BeenThere: xen-users@lists.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 OK, I'm not "new" to Xen, but it's been a few years (Xen 3.x) since I last really messed with it. I'm now stuck trying to get back into my recently installed new guest. My host is running Ubuntu 12.04.1 and Xen 4.1 with the xl toolstack. I originally created/installed the guest using virt-manager. The install went well and the guest rebooted successfully and I was able to access it via xl vncviewer guest-name Now, the first problem, where's the config file? Xen 3.x used fairly straight forward config files that were stored in /etc/xen/. virt-install doesn't create that file. I found an sxp format config file in /var/lib/xend/domains/UUID/ that matches my guest. But I'm unable to boot from that. When I try, I get a lot of parser errors and finally complaints about it looking like Python code. So this: sudo xl create /var/lib/xend/domains/UUID/config.sxp doesn't allow me to reboot the guest. I then tried creating a basic old-style config file: builder='hvm' name='precise-hvm' memory=1024 maxmemory=1024 uuid='18069c40-e01f-ddf8-5932-bc6bb6b5bba1' vif='xenbr0' disk=[ 'file:/vms/precise-hvm.img,qcow2,hda' ] I then tried starting the guest there. That also fails because despite what I read here: http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt None of these disk lines are accepted by xl: disk=[ '/vms/precise-hvm.img,,hda' ] disk=[ '/vms/precise-hvm.img,qcow,hda' ] disk=[ '/vms/precise-hvm.img,qcow2,hda' ] disk=[ 'file:/vms/precise-hvm.img,qcow2,hda' ] For each disk line where I specify a format (qcow or qcow2) I get the following output: Parsing config file /etc/xen/precise-hvm.cfg /etc/xen/precise-hvm.cfg:10: warning: parameter `vif' is a single value but should be a list xc: info: VIRTUAL MEMORY ARRANGEMENT: Loader: 0000000000100000->000000000017c510 TOTAL: 0000000000000000->000000003f800000 ENTRY ADDRESS: 00000000001015a0 xc: info: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0000000000000200 2MB PAGES: 0x00000000000001fb 1GB PAGES: 0x0000000000000000 libxl: error: libxl.c:938:libxl_device_disk_add Invalid or unsupported virtual disk identifier qcow2 cannot add disk 0 to domain: -6 libxl: error: libxl_dm.c:747:libxl__destroy_device_model Couldn't find device model's pid: No such file or directory libxl: error: libxl.c:730:libxl_domain_destroy libxl__destroy_device_model failed for 6 and if I DON'T specify a format, I get this: Parsing config file /etc/xen/precise-hvm.cfg parse error in disk config near ',hda' So I have a file backed guest that "should" be perfectly usable, only I can't figure out how to boot the thing... Can someone point me to a clue to help me catch up to the state of Xen today? Cheers Jeff _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 20:11:55 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 20:11: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 1UKwgm-0003tY-Fg; Wed, 27 Mar 2013 20:11:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKwgl-0003sV-4D for xen-users@lists.xen.org; Wed, 27 Mar 2013 20:11:15 +0000 Received: from [85.158.137.99:32295] by server-5.bemta-3.messagelabs.com id F6/ED-30636-26253515; Wed, 27 Mar 2013 20:11:14 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1364415071!17028032!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 517 invoked from network); 27 Mar 2013 20:11:13 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-10.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2013 20:11:13 -0000 Date: Wed, 27 Mar 2013 20:11:10 +0000 From: Mike To: Alexandre Kouznetsov Message-ID: <20130327201110.GA27122@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> <5153387F.5020106@ondore.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5153387F.5020106@ondore.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Alexandre Kouznetsov wrote: > Please post your boot loader configuration. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#25 > The next thing to try would be hardware debugging. Memtest For the record, memtest86+ (Debian 4.20-1.1) doesn't work with UEFI: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695246 Looks like memtest86 has the same issue, since it also uses linux16. I'd have to prepare a BIOS-bootable USB stick to use this. It's not clear how to do this. Simply copying the included ISO to a USB stick doesn't boot. I also question the value of running a BIOS-booted test to solve a UEFI-booted software problem. Perhaps you can explain your logic. This is a new machine, and I ran the HP ROM-based memory test when I got it. > set BIOS into fail-safe settings. I don't know what you mean. Reset the BIOS settings to the factory defaults? I have no reason to do that. In fact, I already did that once, because I lost track of the settings that I had changed. But now I know precisely what changes I've made, so resetting and rechanging the settings would simply put me where I am now. >[...] > A good reference would be to test Squeeze's Xen and kernel, if they > show the same behavior. Yeah, that's the fallback. I've have Xen on squeeze on another system, but I'm not confident that it will work here: I suspect that Xen is having an issue with my dm-crypt root. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 20:11:55 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 20:11: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 1UKwgm-0003tY-Fg; Wed, 27 Mar 2013 20:11:16 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKwgl-0003sV-4D for xen-users@lists.xen.org; Wed, 27 Mar 2013 20:11:15 +0000 Received: from [85.158.137.99:32295] by server-5.bemta-3.messagelabs.com id F6/ED-30636-26253515; Wed, 27 Mar 2013 20:11:14 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-10.tower-217.messagelabs.com!1364415071!17028032!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 517 invoked from network); 27 Mar 2013 20:11:13 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-10.tower-217.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2013 20:11:13 -0000 Date: Wed, 27 Mar 2013 20:11:10 +0000 From: Mike To: Alexandre Kouznetsov Message-ID: <20130327201110.GA27122@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> <5153387F.5020106@ondore.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5153387F.5020106@ondore.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Alexandre Kouznetsov wrote: > Please post your boot loader configuration. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703586#25 > The next thing to try would be hardware debugging. Memtest For the record, memtest86+ (Debian 4.20-1.1) doesn't work with UEFI: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695246 Looks like memtest86 has the same issue, since it also uses linux16. I'd have to prepare a BIOS-bootable USB stick to use this. It's not clear how to do this. Simply copying the included ISO to a USB stick doesn't boot. I also question the value of running a BIOS-booted test to solve a UEFI-booted software problem. Perhaps you can explain your logic. This is a new machine, and I ran the HP ROM-based memory test when I got it. > set BIOS into fail-safe settings. I don't know what you mean. Reset the BIOS settings to the factory defaults? I have no reason to do that. In fact, I already did that once, because I lost track of the settings that I had changed. But now I know precisely what changes I've made, so resetting and rechanging the settings would simply put me where I am now. >[...] > A good reference would be to test Squeeze's Xen and kernel, if they > show the same behavior. Yeah, that's the fallback. I've have Xen on squeeze on another system, but I'm not confident that it will work here: I suspect that Xen is having an issue with my dm-crypt root. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 21:40:55 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 21:40: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 1UKy4W-0006rV-Hx; Wed, 27 Mar 2013 21:39:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKy4U-0006rQ-Sv for xen-users@lists.xen.org; Wed, 27 Mar 2013 21:39:51 +0000 Received: from [85.158.139.211:42841] by server-14.bemta-5.messagelabs.com id DB/B4-13158-62763515; Wed, 27 Mar 2013 21:39:50 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1364420388!17739106!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 384 invoked from network); 27 Mar 2013 21:39:49 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Mar 2013 21:39:49 -0000 Received: from [200.52.43.60] (port=52866 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UKy4R-0000K2-TC for xen-users@lists.xen.org; Wed, 27 Mar 2013 16:39:48 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id DAF00A209 for ; Wed, 27 Mar 2013 15:34:22 -0600 (CST) Message-ID: <51536722.6030101@ondore.com> Date: Wed, 27 Mar 2013 15:39:46 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> <5153387F.5020106@ondore.com> <20130327201110.GA27122@64-142-29-25.dsl.static.sonic.net> In-Reply-To: <20130327201110.GA27122@64-142-29-25.dsl.static.sonic.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Hello. El 27/03/13 14:11, Mike escribi=F3: >> Please post your boot loader configuration. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D703586#25 Looks good. My own serial console's setup for Xen omits the IO address and IRQ, but = if the numbers are correct, should not harm. I usually remove "quite" = option from kernel boot line. Although, in this case your system clearly = don't reach the kernel booting. When you say "no output from the Xen boot process", do you mean no = output at all? Even "Loading Xen 4.1-amd64 ..." legend? While debugging this stage, maybe Grub's output give some clue: cat >> /etc/default/grub << EOF GRUB_TERMINAL=3D"console serial" GRUB_SERIAL_COMMAND=3D"serial --unit=3D0 --speed=3D115200 --word=3D8" EOF update-grub >> The next thing to try would be hardware debugging. Memtest > > For the record, memtest86+ (Debian 4.20-1.1) doesn't work with UEFI: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D695246 > Looks like memtest86 has the same issue, since it also uses linux16. Oh, that's new for me. > I'd have to prepare a BIOS-bootable USB stick to use this. It's not > clear how to do this. Simply copying the included ISO to a USB stick > doesn't boot. No need for that. Memtest86 can be launched from any boot loader, even = Grub. "apt-get install memtest86+" would create the needed Grub menu entry. > I also question the value of running a BIOS-booted test > to solve a UEFI-booted software problem. Perhaps you can explain your > logic. I'm not familiar with UEFI. My logic is very primitive. If some piece of = software generally works, but under some system it does not, the key for = solution is to find out what makes this system different. Hardware = defect, for example. Or incompatible characteristic (google:"model+xen" = often throws something useful). > This is a new machine, and I ran the HP ROM-based memory test when I got > it. I guess that is as good as Memtest to make sure the RAM is fine. >> set BIOS into fail-safe settings. > > I don't know what you mean. Reset the BIOS settings to the factory > defaults? I have no reason to do that. In fact, I already did that > once, because I lost track of the settings that I had changed. But now > I know precisely what changes I've made, so resetting and rechanging the > settings would simply put me where I am now. You where out of debugging ideas, wasn't you? Some BIOSes have a literal option "fail-safe settings". Some does not, = but using common sense it's possible to disable most of "fancy" and = "exotic" options. They still might be needed in production, but it's = useful to make sure it's not BIOS configuration what triggers the failure. BTW, have you tried to remove part of RAM? How much RAM does the machine = have? >> [...] >> A good reference would be to test Squeeze's Xen and kernel, if they >> show the same behavior. > > Yeah, that's the fallback. You can just give it a try without making a full installation: Copy xen, kernel and initrd images to your testing system and make Grub = to boot them. It's unlikely it would finish booting (mainly because of = the kernel modules), but that could be a good proof of concept test. If = it behaves in the same way, than probably the problem is not about Xen = or OS version. > I've have Xen on squeeze on another system, > but I'm not confident that it will work here: I suspect that Xen is > having an issue with my dm-crypt root. AFAIK, it just works. I have a production system since a couple of years = ago, with Squeeze, Xen 4.0 and crypted root. It is not rebooted often = and not under heavy use, but so far I had no issues related to dm-crypt. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 21:40:55 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 21:40: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 1UKy4W-0006rV-Hx; Wed, 27 Mar 2013 21:39:52 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKy4U-0006rQ-Sv for xen-users@lists.xen.org; Wed, 27 Mar 2013 21:39:51 +0000 Received: from [85.158.139.211:42841] by server-14.bemta-5.messagelabs.com id DB/B4-13158-62763515; Wed, 27 Mar 2013 21:39:50 +0000 X-Env-Sender: alk@ondore.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1364420388!17739106!1 X-Originating-IP: [184.172.38.139] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 384 invoked from network); 27 Mar 2013 21:39:49 -0000 Received: from host1a.ondore-systems.com (HELO host1a.ondore-systems.com) (184.172.38.139) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Mar 2013 21:39:49 -0000 Received: from [200.52.43.60] (port=52866 helo=mail.ondore.i) by host1a.ondore-systems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UKy4R-0000K2-TC for xen-users@lists.xen.org; Wed, 27 Mar 2013 16:39:48 -0500 Received: from [10.13.34.96] (alk-desktop.sys.ondore.i [10.13.34.96]) by mail.ondore.i (Postfix) with ESMTPSA id DAF00A209 for ; Wed, 27 Mar 2013 15:34:22 -0600 (CST) Message-ID: <51536722.6030101@ondore.com> Date: Wed, 27 Mar 2013 15:39:46 -0600 From: Alexandre Kouznetsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> <5153387F.5020106@ondore.com> <20130327201110.GA27122@64-142-29-25.dsl.static.sonic.net> In-Reply-To: <20130327201110.GA27122@64-142-29-25.dsl.static.sonic.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host1a.ondore-systems.com X-AntiAbuse: Original Domain - lists.xen.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ondore.com X-Get-Message-Sender-Via: host1a.ondore-systems.com: authenticated_id: sys.intranet@ondore.com Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Hello. El 27/03/13 14:11, Mike escribi=F3: >> Please post your boot loader configuration. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D703586#25 Looks good. My own serial console's setup for Xen omits the IO address and IRQ, but = if the numbers are correct, should not harm. I usually remove "quite" = option from kernel boot line. Although, in this case your system clearly = don't reach the kernel booting. When you say "no output from the Xen boot process", do you mean no = output at all? Even "Loading Xen 4.1-amd64 ..." legend? While debugging this stage, maybe Grub's output give some clue: cat >> /etc/default/grub << EOF GRUB_TERMINAL=3D"console serial" GRUB_SERIAL_COMMAND=3D"serial --unit=3D0 --speed=3D115200 --word=3D8" EOF update-grub >> The next thing to try would be hardware debugging. Memtest > > For the record, memtest86+ (Debian 4.20-1.1) doesn't work with UEFI: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D695246 > Looks like memtest86 has the same issue, since it also uses linux16. Oh, that's new for me. > I'd have to prepare a BIOS-bootable USB stick to use this. It's not > clear how to do this. Simply copying the included ISO to a USB stick > doesn't boot. No need for that. Memtest86 can be launched from any boot loader, even = Grub. "apt-get install memtest86+" would create the needed Grub menu entry. > I also question the value of running a BIOS-booted test > to solve a UEFI-booted software problem. Perhaps you can explain your > logic. I'm not familiar with UEFI. My logic is very primitive. If some piece of = software generally works, but under some system it does not, the key for = solution is to find out what makes this system different. Hardware = defect, for example. Or incompatible characteristic (google:"model+xen" = often throws something useful). > This is a new machine, and I ran the HP ROM-based memory test when I got > it. I guess that is as good as Memtest to make sure the RAM is fine. >> set BIOS into fail-safe settings. > > I don't know what you mean. Reset the BIOS settings to the factory > defaults? I have no reason to do that. In fact, I already did that > once, because I lost track of the settings that I had changed. But now > I know precisely what changes I've made, so resetting and rechanging the > settings would simply put me where I am now. You where out of debugging ideas, wasn't you? Some BIOSes have a literal option "fail-safe settings". Some does not, = but using common sense it's possible to disable most of "fancy" and = "exotic" options. They still might be needed in production, but it's = useful to make sure it's not BIOS configuration what triggers the failure. BTW, have you tried to remove part of RAM? How much RAM does the machine = have? >> [...] >> A good reference would be to test Squeeze's Xen and kernel, if they >> show the same behavior. > > Yeah, that's the fallback. You can just give it a try without making a full installation: Copy xen, kernel and initrd images to your testing system and make Grub = to boot them. It's unlikely it would finish booting (mainly because of = the kernel modules), but that could be a good proof of concept test. If = it behaves in the same way, than probably the problem is not about Xen = or OS version. > I've have Xen on squeeze on another system, > but I'm not confident that it will work here: I suspect that Xen is > having an issue with my dm-crypt root. AFAIK, it just works. I have a production system since a couple of years = ago, with Squeeze, Xen 4.0 and crypted root. It is not rebooted often = and not under heavy use, but so far I had no issues related to dm-crypt. Greetings. -- = Alexandre Kouznetsov _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 22:29:34 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 22:29: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 1UKypd-0007x2-NN; Wed, 27 Mar 2013 22:28:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKypc-0007wu-OC for xen-users@lists.xen.org; Wed, 27 Mar 2013 22:28:32 +0000 Received: from [85.158.137.99:54478] by server-13.bemta-3.messagelabs.com id 79/BC-25744-B8273515; Wed, 27 Mar 2013 22:28:27 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-217.messagelabs.com!1364423302!12231727!1 X-Originating-IP: [89.16.177.154] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8004 invoked from network); 27 Mar 2013 22:28:22 -0000 Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154) by server-8.tower-217.messagelabs.com with SMTP; 27 Mar 2013 22:28:22 -0000 Received: (qmail 23008 invoked by uid 634); 27 Mar 2013 22:28:21 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from no-dns-yet.demon.co.uk (HELO [192.168.14.198]) (62.49.66.12) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Wed, 27 Mar 2013 22:28:21 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Anil Madhavapeddy In-Reply-To: <51536A3E.2020302@cantab.net> Date: Wed, 27 Mar 2013 22:28:18 +0000 Message-Id: <31D0119A-0154-4454-94E0-0F9D15DC103F@recoil.org> References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> <51536A3E.2020302@cantab.net> To: David Vrabel X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: xen-users@lists.xen.org, George Dunlap , "cl-mirage@lists.cam.ac.uk List" , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 27 Mar 2013, at 21:53, David Vrabel wrote: > On 27/03/2013 19:36, Anil Madhavapeddy wrote: >> On 27 Mar 2013, at 11:23, George Dunlap wrote: >>> >>> The FIFO solution makes event delivery a matter of adding items to a >>> highly structured linked list. The number of event channels for the >>> interface design has a theoretical maximum of 2^28; the current >>> implementation is limimited at 2^17, which is over 100,000. The >>> number is the same for both 32-bit and 64-bit kernels. >> >> Is there any reason for such a low default? If I'm not mistaken, >> every guest needs at least 2 event channels (console, xenstore) and >> probably has two more for a net and disk device. > > 131,072 seemed high enough to me but I'd forgotten about the Mirage use > case. > > This can be trivially raised to 2^19 (524,288). Beyond that, the > implementation becomes slightly more complex as the pointers to the > event array pages no longer fit in a single page. Makes sense. >> With stub-domains in the mix, we could easily imagine running 25,000 >> VMs with a couple of megabytes of RAM each using Mirage (which can >> boot very low memory guests without too much trouble). > > Having said that, with 25,000 VMs it would seem sensible to disaggregate > things like the console and xenstore (in addition to the network and > block backends). Thus reducing the need for event channels for any > single domain. Yeah indeed; this should be pretty easy to do and let the existing 2^17 be enough for a long time too. We'd need to think a bit about a distributed xenstored to avoid having one hotspot servicing so many VMs. One nice thing about the OCaml xenstored is that it should be possible to make an explicitly distributed implementation of the protocol. The data-structure is already based around immutable trees, so it's a matter of figuring out where to put the consensus logic (probably around /local/domain/*). -anil _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 22:29:34 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 22:29: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 1UKypd-0007x2-NN; Wed, 27 Mar 2013 22:28:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKypc-0007wu-OC for xen-users@lists.xen.org; Wed, 27 Mar 2013 22:28:32 +0000 Received: from [85.158.137.99:54478] by server-13.bemta-3.messagelabs.com id 79/BC-25744-B8273515; Wed, 27 Mar 2013 22:28:27 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-8.tower-217.messagelabs.com!1364423302!12231727!1 X-Originating-IP: [89.16.177.154] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8004 invoked from network); 27 Mar 2013 22:28:22 -0000 Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154) by server-8.tower-217.messagelabs.com with SMTP; 27 Mar 2013 22:28:22 -0000 Received: (qmail 23008 invoked by uid 634); 27 Mar 2013 22:28:21 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from no-dns-yet.demon.co.uk (HELO [192.168.14.198]) (62.49.66.12) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Wed, 27 Mar 2013 22:28:21 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Anil Madhavapeddy In-Reply-To: <51536A3E.2020302@cantab.net> Date: Wed, 27 Mar 2013 22:28:18 +0000 Message-Id: <31D0119A-0154-4454-94E0-0F9D15DC103F@recoil.org> References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> <51536A3E.2020302@cantab.net> To: David Vrabel X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: xen-users@lists.xen.org, George Dunlap , "cl-mirage@lists.cam.ac.uk List" , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 27 Mar 2013, at 21:53, David Vrabel wrote: > On 27/03/2013 19:36, Anil Madhavapeddy wrote: >> On 27 Mar 2013, at 11:23, George Dunlap wrote: >>> >>> The FIFO solution makes event delivery a matter of adding items to a >>> highly structured linked list. The number of event channels for the >>> interface design has a theoretical maximum of 2^28; the current >>> implementation is limimited at 2^17, which is over 100,000. The >>> number is the same for both 32-bit and 64-bit kernels. >> >> Is there any reason for such a low default? If I'm not mistaken, >> every guest needs at least 2 event channels (console, xenstore) and >> probably has two more for a net and disk device. > > 131,072 seemed high enough to me but I'd forgotten about the Mirage use > case. > > This can be trivially raised to 2^19 (524,288). Beyond that, the > implementation becomes slightly more complex as the pointers to the > event array pages no longer fit in a single page. Makes sense. >> With stub-domains in the mix, we could easily imagine running 25,000 >> VMs with a couple of megabytes of RAM each using Mirage (which can >> boot very low memory guests without too much trouble). > > Having said that, with 25,000 VMs it would seem sensible to disaggregate > things like the console and xenstore (in addition to the network and > block backends). Thus reducing the need for event channels for any > single domain. Yeah indeed; this should be pretty easy to do and let the existing 2^17 be enough for a long time too. We'd need to think a bit about a distributed xenstored to avoid having one hotspot servicing so many VMs. One nice thing about the OCaml xenstored is that it should be possible to make an explicitly distributed implementation of the protocol. The data-structure is already based around immutable trees, so it's a matter of figuring out where to put the consensus logic (probably around /local/domain/*). -anil _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 22:32:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 22:32: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 1UKyt0-0008J6-0B; Wed, 27 Mar 2013 22:32:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKysy-0008If-1f for xen-users@lists.xen.org; Wed, 27 Mar 2013 22:32:00 +0000 Received: from [193.109.254.147:62090] by server-9.bemta-14.messagelabs.com id FD/AA-04223-F5373515; Wed, 27 Mar 2013 22:31:59 +0000 X-Env-Sender: liuw@liuw.name X-Msg-Ref: server-14.tower-27.messagelabs.com!1364423517!1841275!1 X-Originating-IP: [74.125.82.179] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31918 invoked from network); 27 Mar 2013 22:31:57 -0000 Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com) (74.125.82.179) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 22:31:57 -0000 Received: by mail-we0-f179.google.com with SMTP id p43so2003982wea.24 for ; Wed, 27 Mar 2013 15:31:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=+QvVenXq6+d/eHCK6tI3pjrb9AzfpQjL+53MtE8ZtuU=; b=CHc5R63V+mw19qN7snP5L3I/Fx+xuQ6agVDuWcbOz6ZTDPhT6dnfMf1v5gHWN4MIgq scgyEoArBSiWR0ffjiU0W3xeM7Q/uUN25b+C+V6z5sEbQ2lBSkfMbALotOt4Lb+RqFZB +2KY0Yta0AjJFk+nCD7hnLnBkB91xf7ApuVUAL4vTtbHPoxmuf7388k5rljh2PF/2WF6 m2WUdAQoahsU9JpTYVrMVE7tWoYSckc/77tCM9TQITRIhMwJ1IqlUY/A2MnHRkHo+WYj ppjJAnJcZ+rCI/cMrp8FRXm+zFQ97kPTWHHh2yayft0TdYF8ort6jrc4Rk8eeqnt+c9a Ogbw== X-Received: by 10.194.77.110 with SMTP id r14mr34681771wjw.2.1364423517598; Wed, 27 Mar 2013 15:31:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.77.161 with HTTP; Wed, 27 Mar 2013 15:31:23 -0700 (PDT) In-Reply-To: <51536A3E.2020302@cantab.net> References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> <51536A3E.2020302@cantab.net> From: Wei Liu Date: Wed, 27 Mar 2013 22:31:23 +0000 Message-ID: To: David Vrabel X-Gm-Message-State: ALoCoQkjG/auwPKoqf236GUWaPAkCXUg2m8fVjctEb6bf3HKjqTVnQb6sOSM5hnBXqsU66DMVCz0 Cc: xen-users@lists.xen.org, George Dunlap , "xen-devel@lists.xen.org" , "cl-mirage@lists.cam.ac.uk List" , Anil Madhavapeddy Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 9:53 PM, David Vrabel wrote: > On 27/03/2013 19:36, Anil Madhavapeddy wrote: >> On 27 Mar 2013, at 11:23, George Dunlap wrote: >>> >>> The FIFO solution makes event delivery a matter of adding items to a >>> highly structured linked list. The number of event channels for the >>> interface design has a theoretical maximum of 2^28; the current >>> implementation is limimited at 2^17, which is over 100,000. The >>> number is the same for both 32-bit and 64-bit kernels. >> >> Is there any reason for such a low default? If I'm not mistaken, >> every guest needs at least 2 event channels (console, xenstore) and >> probably has two more for a net and disk device. > > 131,072 seemed high enough to me but I'd forgotten about the Mirage use > case. > > This can be trivially raised to 2^19 (524,288). Beyond that, the > implementation becomes slightly more complex as the pointers to the > event array pages no longer fit in a single page. > Then that would require 512 pages mapped in Xen in the worst case, plus >> With stub-domains in the mix, we could easily imagine running 25,000 >> VMs with a couple of megabytes of RAM each using Mirage (which can >> boot very low memory guests without too much trouble). > 25,000 pages for domUs if domU uses this ABI as well. This might require bumping global mapping space in Xen, or we can restrict domU to only use default 2-level ABI to solve this problem. But let's not worry about future things for now. Wei. > Having said that, with 25,000 VMs it would seem sensible to disaggregate > things like the console and xenstore (in addition to the network and > block backends). Thus reducing the need for event channels for any > single domain. > > David > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Mar 27 22:32:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 27 Mar 2013 22:32: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 1UKyt0-0008J6-0B; Wed, 27 Mar 2013 22:32:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKysy-0008If-1f for xen-users@lists.xen.org; Wed, 27 Mar 2013 22:32:00 +0000 Received: from [193.109.254.147:62090] by server-9.bemta-14.messagelabs.com id FD/AA-04223-F5373515; Wed, 27 Mar 2013 22:31:59 +0000 X-Env-Sender: liuw@liuw.name X-Msg-Ref: server-14.tower-27.messagelabs.com!1364423517!1841275!1 X-Originating-IP: [74.125.82.179] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31918 invoked from network); 27 Mar 2013 22:31:57 -0000 Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com) (74.125.82.179) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Mar 2013 22:31:57 -0000 Received: by mail-we0-f179.google.com with SMTP id p43so2003982wea.24 for ; Wed, 27 Mar 2013 15:31:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=+QvVenXq6+d/eHCK6tI3pjrb9AzfpQjL+53MtE8ZtuU=; b=CHc5R63V+mw19qN7snP5L3I/Fx+xuQ6agVDuWcbOz6ZTDPhT6dnfMf1v5gHWN4MIgq scgyEoArBSiWR0ffjiU0W3xeM7Q/uUN25b+C+V6z5sEbQ2lBSkfMbALotOt4Lb+RqFZB +2KY0Yta0AjJFk+nCD7hnLnBkB91xf7ApuVUAL4vTtbHPoxmuf7388k5rljh2PF/2WF6 m2WUdAQoahsU9JpTYVrMVE7tWoYSckc/77tCM9TQITRIhMwJ1IqlUY/A2MnHRkHo+WYj ppjJAnJcZ+rCI/cMrp8FRXm+zFQ97kPTWHHh2yayft0TdYF8ort6jrc4Rk8eeqnt+c9a Ogbw== X-Received: by 10.194.77.110 with SMTP id r14mr34681771wjw.2.1364423517598; Wed, 27 Mar 2013 15:31:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.77.161 with HTTP; Wed, 27 Mar 2013 15:31:23 -0700 (PDT) In-Reply-To: <51536A3E.2020302@cantab.net> References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> <51536A3E.2020302@cantab.net> From: Wei Liu Date: Wed, 27 Mar 2013 22:31:23 +0000 Message-ID: To: David Vrabel X-Gm-Message-State: ALoCoQkjG/auwPKoqf236GUWaPAkCXUg2m8fVjctEb6bf3HKjqTVnQb6sOSM5hnBXqsU66DMVCz0 Cc: xen-users@lists.xen.org, George Dunlap , "xen-devel@lists.xen.org" , "cl-mirage@lists.cam.ac.uk List" , Anil Madhavapeddy Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 9:53 PM, David Vrabel wrote: > On 27/03/2013 19:36, Anil Madhavapeddy wrote: >> On 27 Mar 2013, at 11:23, George Dunlap wrote: >>> >>> The FIFO solution makes event delivery a matter of adding items to a >>> highly structured linked list. The number of event channels for the >>> interface design has a theoretical maximum of 2^28; the current >>> implementation is limimited at 2^17, which is over 100,000. The >>> number is the same for both 32-bit and 64-bit kernels. >> >> Is there any reason for such a low default? If I'm not mistaken, >> every guest needs at least 2 event channels (console, xenstore) and >> probably has two more for a net and disk device. > > 131,072 seemed high enough to me but I'd forgotten about the Mirage use > case. > > This can be trivially raised to 2^19 (524,288). Beyond that, the > implementation becomes slightly more complex as the pointers to the > event array pages no longer fit in a single page. > Then that would require 512 pages mapped in Xen in the worst case, plus >> With stub-domains in the mix, we could easily imagine running 25,000 >> VMs with a couple of megabytes of RAM each using Mirage (which can >> boot very low memory guests without too much trouble). > 25,000 pages for domUs if domU uses this ABI as well. This might require bumping global mapping space in Xen, or we can restrict domU to only use default 2-level ABI to solve this problem. But let's not worry about future things for now. Wei. > Having said that, with 25,000 VMs it would seem sensible to disaggregate > things like the console and xenstore (in addition to the network and > block backends). Thus reducing the need for event channels for any > single domain. > > David > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 01:58:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 01:58: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 1UL25L-0006uE-H6; Thu, 28 Mar 2013 01:56:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UL25J-0006tz-95; Thu, 28 Mar 2013 01:56:57 +0000 Received: from [85.158.139.211:2093] by server-1.bemta-5.messagelabs.com id EF/09-14063-863A3515; Thu, 28 Mar 2013 01:56:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1364435814!20428103!1 X-Originating-IP: [156.151.31.81] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27744 invoked from network); 28 Mar 2013 01:56:55 -0000 Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Mar 2013 01:56:55 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2S1uqN9019035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Mar 2013 01:56:53 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2S1upSG004904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Mar 2013 01:56:51 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2S1up3h001909; Wed, 27 Mar 2013 20:56:51 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Mar 2013 18:56:50 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 000791C3D8A; Wed, 27 Mar 2013 21:56:49 -0400 (EDT) Date: Wed, 27 Mar 2013 21:56:49 -0400 From: Konrad Rzeszutek Wilk To: George Dunlap Message-ID: <20130328015649.GA12810@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 11:23:23AM +0000, George Dunlap wrote: > * Executive summary > > The number of event channels available for dom0 is currently one of > the biggest limitations on scaling up the number of VMs which can be > created on a single system. There are two alternative implementations > we could choose, one of which is ready now, the other of which is > potentially technically superior, but will not be ready for the 4.3 > release. > > The core question we need to ask the community: How important is > lifting the event channel scalability limit to 4.3? Will waiting > until 4.4 cause a limit in the uptake of the Xen platform? > > * The issue > > The existing event channel implementation for PV guests is implemented > as 2-level bit array. This limits the total number of event channels > to word_size ^ 2, which is 1024 for 32-bit guests and 4096 for 64-bit > guests. > > This sounds like a lot, until you consider that in a typical system, > each VM needs 4 or more event channels in domain 0. This means that > for a 32-bit dom0, there is a theoretical maximum of 256 guests -- and > in practice it's more like 180 or so, because of event channels > required for other things. XenServer already has customers using VDI > that require more VMs than this. > > * The dilemma > > When we began the 4.3 release cycle, this was one of the items we > identified as a key feature we needed to get for 4.3. Wei Liu started > work on an extension of the existing implmentation, allowing 3 levels > of event channels. The draft of this is ready, and just needs the > last bit of polishing and bug-chasing before it can be accepted. > > However, several months ago, David Vrabel came up with an alternate > design which in theory was more scalable, based on queues of linked > lists (which we have internally been calling "FIFO" for short). David > has been working on the implementation since, and has a draft > protoype; but it's in no shape to be included in 4.3. > > There are some things that are attractive about the second solution, > including the flexible assignment of interrupt priorities, ease of > scalability, and potentially even the FIFO nature of the interrupt > delivery. > > The question at hand then, is whether to take what we have in the > 3-level implementation for 4.3, or wait to see how the FIFO > implementation turns out (taking either it or the 3-level > implementation in 4.4). > > * The solution in hand: 3-level event channels > > The basic idea behind 3-level event channels is to extend the existing > 2-level implementation to 3 levels. Going to 3 levels would give us > 32k event channels for 32-bit, and 256k for 64-bit. > > One of the advantages of this method is that since it is similar to > the existing method, the general concepts and race conditions are > fairly well understood and tested. > > One of the disadvantages that this method inherits from the 2-level > event channels is the lack of priority. In the initial implementation > of event channels, priority was handled by event channel order: scans > for events always started at 0 and went upwards. However, this was > not very scalable, as lower-numbered events could easily completely > lock out higher-numbered events; and frequently "lower-numbered" > simply meant "created earlier". Event channels were forced into a > priority even if one was not wanted. > > So the implementation was tweaked, so that scans don't start at 0, but > continue where the last event left off. This made it so that earlier > events were not prioritized and removed the starvation issue, but at > the cost of removing all event priorities. Certain events, like the > timer event, are special-cased to be always checked, but this is > rather a bit of a hack and not very scalable or flexible. Hm, I actually think that is not in the upstream kernel at all. That would explain why on very heavily busy guest the hrtimer: interrupt took XXxXXXXxx ns is printed. Is this patch somewhere available? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 01:58:01 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 01:58: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 1UL25L-0006uE-H6; Thu, 28 Mar 2013 01:56:59 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UL25J-0006tz-95; Thu, 28 Mar 2013 01:56:57 +0000 Received: from [85.158.139.211:2093] by server-1.bemta-5.messagelabs.com id EF/09-14063-863A3515; Thu, 28 Mar 2013 01:56:56 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1364435814!20428103!1 X-Originating-IP: [156.151.31.81] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27744 invoked from network); 28 Mar 2013 01:56:55 -0000 Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Mar 2013 01:56:55 -0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2S1uqN9019035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Mar 2013 01:56:53 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2S1upSG004904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Mar 2013 01:56:51 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2S1up3h001909; Wed, 27 Mar 2013 20:56:51 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Mar 2013 18:56:50 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 000791C3D8A; Wed, 27 Mar 2013 21:56:49 -0400 (EDT) Date: Wed, 27 Mar 2013 21:56:49 -0400 From: Konrad Rzeszutek Wilk To: George Dunlap Message-ID: <20130328015649.GA12810@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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, Mar 27, 2013 at 11:23:23AM +0000, George Dunlap wrote: > * Executive summary > > The number of event channels available for dom0 is currently one of > the biggest limitations on scaling up the number of VMs which can be > created on a single system. There are two alternative implementations > we could choose, one of which is ready now, the other of which is > potentially technically superior, but will not be ready for the 4.3 > release. > > The core question we need to ask the community: How important is > lifting the event channel scalability limit to 4.3? Will waiting > until 4.4 cause a limit in the uptake of the Xen platform? > > * The issue > > The existing event channel implementation for PV guests is implemented > as 2-level bit array. This limits the total number of event channels > to word_size ^ 2, which is 1024 for 32-bit guests and 4096 for 64-bit > guests. > > This sounds like a lot, until you consider that in a typical system, > each VM needs 4 or more event channels in domain 0. This means that > for a 32-bit dom0, there is a theoretical maximum of 256 guests -- and > in practice it's more like 180 or so, because of event channels > required for other things. XenServer already has customers using VDI > that require more VMs than this. > > * The dilemma > > When we began the 4.3 release cycle, this was one of the items we > identified as a key feature we needed to get for 4.3. Wei Liu started > work on an extension of the existing implmentation, allowing 3 levels > of event channels. The draft of this is ready, and just needs the > last bit of polishing and bug-chasing before it can be accepted. > > However, several months ago, David Vrabel came up with an alternate > design which in theory was more scalable, based on queues of linked > lists (which we have internally been calling "FIFO" for short). David > has been working on the implementation since, and has a draft > protoype; but it's in no shape to be included in 4.3. > > There are some things that are attractive about the second solution, > including the flexible assignment of interrupt priorities, ease of > scalability, and potentially even the FIFO nature of the interrupt > delivery. > > The question at hand then, is whether to take what we have in the > 3-level implementation for 4.3, or wait to see how the FIFO > implementation turns out (taking either it or the 3-level > implementation in 4.4). > > * The solution in hand: 3-level event channels > > The basic idea behind 3-level event channels is to extend the existing > 2-level implementation to 3 levels. Going to 3 levels would give us > 32k event channels for 32-bit, and 256k for 64-bit. > > One of the advantages of this method is that since it is similar to > the existing method, the general concepts and race conditions are > fairly well understood and tested. > > One of the disadvantages that this method inherits from the 2-level > event channels is the lack of priority. In the initial implementation > of event channels, priority was handled by event channel order: scans > for events always started at 0 and went upwards. However, this was > not very scalable, as lower-numbered events could easily completely > lock out higher-numbered events; and frequently "lower-numbered" > simply meant "created earlier". Event channels were forced into a > priority even if one was not wanted. > > So the implementation was tweaked, so that scans don't start at 0, but > continue where the last event left off. This made it so that earlier > events were not prioritized and removed the starvation issue, but at > the cost of removing all event priorities. Certain events, like the > timer event, are special-cased to be always checked, but this is > rather a bit of a hack and not very scalable or flexible. Hm, I actually think that is not in the upstream kernel at all. That would explain why on very heavily busy guest the hrtimer: interrupt took XXxXXXXxx ns is printed. Is this patch somewhere available? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 10:57:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 10:57: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 1ULAUr-0000nF-Cz; Thu, 28 Mar 2013 10:55:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULAUp-0000n9-Vp for xen-users@lists.xen.org; Thu, 28 Mar 2013 10:55:52 +0000 Received: from [85.158.138.51:48273] by server-14.bemta-3.messagelabs.com id 81/F1-27076-7B124515; Thu, 28 Mar 2013 10:55:51 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1364468131!27540816!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP, spamassassin: , async_handler: YXN5bmNfZGVsYXk6IDcwNDc1OTQgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1587 invoked from network); 28 Mar 2013 10:55:33 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Mar 2013 10:55:33 -0000 Received: by mail-ie0-f175.google.com with SMTP id c12so11228984ieb.20 for ; Thu, 28 Mar 2013 03:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=akxiS0lcaWgNA02Kwe3rMWiVX/XIqBzApUIGgZGJYVg=; b=tmMqYzINBk7wwP8Hw4pKpAcoq5jkIzxt4Rx6soWN6u/dooH+zP1iQC7X2n5Fa0KzU3 zpLvpaLjLk/k+Cx9JRFwu5T3WuG9bnQWoiV8XWq3RdJNDifnQ5ADHhnqZJIMGhWJuwPJ w0vPUhxRYGqPnbSz4lhb8kHnTRnKTqofHd3BUzF91L0pmljnhvf8oy6jZtRnJao97DNP Zv+PJb4dQektJnMtebXP3STHQSw9g0G3iMIFh4TwW1BlcKgeXMQkPAilsVZpbvURM6nh oAT3rJhuIzeYk2AE8sl7dz+oE3tJW0Q/FIMywzG8Gz2DaEMaKJ6lBw0QPxvzXXvwNonR Pj3w== MIME-Version: 1.0 X-Received: by 10.50.152.169 with SMTP id uz9mr7160513igb.15.1364468131499; Thu, 28 Mar 2013 03:55:31 -0700 (PDT) Received: by 10.42.54.8 with HTTP; Thu, 28 Mar 2013 03:55:31 -0700 (PDT) Date: Thu, 28 Mar 2013 11:55:31 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org, drbd-dev@lists.linbit.com Subject: [Xen-users] Xen Remus DRBD dual primary frozen X-BeenThere: xen-users@lists.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="===============7180022455631787470==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7180022455631787470== Content-Type: multipart/alternative; boundary=e89a8f23597f49147704d8f9fe23 --e89a8f23597f49147704d8f9fe23 Content-Type: text/plain; charset=ISO-8859-1 Dear all, I have sent this problem earlier but maybe its not detail, here I try to write more detail. I hope anybody can help me to point out the problem. First of all I used Ubuntu 12.04 x64 both for domain0 and domainU with modification to run under xen hypervisor and work with remus. I follow and configured the remus with this notes http://wiki.xen.org/wiki/Install_Xen_4.1.4_with_Remus_and_DRBD_on_Ubuntu_12.10but I used xen 4.2.2 as my hypervisor with DRBD 3.8.11 remus support from this link http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz . If DRBD run with Primary - secondary mode, there is no problem. However remus run with dual primary mode. If I try to run remus the drbd will freeze and cause my domainU to freeze. With dmesg error message is below : [242525.600067] block drbd1: Local backing block device frozen? [242537.632070] block drbd1: Local backing block device frozen? [242549.664075] block drbd1: Local backing block device frozen? [242561.696083] block drbd1: Local backing block device frozen? [242573.728079] block drbd1: Local backing block device frozen? [242585.760069] block drbd1: Local backing block device frozen? [242597.792079] block drbd1: Local backing block device frozen? [242609.824069] block drbd1: Local backing block device frozen? [242621.856083] block drbd1: Local backing block device frozen? [242633.888068] block drbd1: Local backing block device frozen? [242640.332124] INFO: task blkback.2.xvda:5779 blocked for more than 120 seconds. [242640.332130] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [242640.332134] blkback.2.xvda D ffff88003fc13780 0 5779 2 0x00000000 [242640.332142] ffff880026743940 0000000000000246 000000000000000b ffff8800267402d0 [242640.332150] ffff880026743fd8 ffff880026743fd8 ffff880026743fd8 0000000000013780 [242640.332157] ffff880032944500 ffff88003368c500 ffff8800357d6000 ffff8800357d69d8 [242640.332164] Call Trace: [242640.332178] [] schedule+0x3f/0x60 [242640.332200] [] drbd_al_begin_io+0x205/0x270 [drbd] [242640.332207] [] ? bvec_alloc_bs+0x68/0x100 [242640.332212] [] ? bio_alloc_bioset+0xb2/0xf0 [242640.332219] [] ? add_wait_queue+0x60/0x60 [242640.332231] [] drbd_make_request_common+0xc4d/0x1430 [drbd] [242640.332239] [] ? xen_blkbk_map+0x24e/0x2f0 [xen_blkback] [242640.332245] [] ? throtl_find_tg+0x46/0x60 [242640.332257] [] drbd_make_request+0x464/0x7e0 [drbd] [242640.332264] [] ? generic_make_request_checks+0x1eb/0x370 [242640.332269] [] generic_make_request.part.50+0x74/0xb0 [242640.332274] [] generic_make_request+0x68/0x70 [242640.332278] [] submit_bio+0x85/0x110 [242640.332284] [] dispatch_rw_block_io+0x44f/0x700 [xen_blkback] [242640.332292] [] ? xen_end_context_switch+0x1e/0x30 [242640.332298] [] __do_block_io_op+0x21f/0x360 [xen_blkback] [242640.332304] [] xen_blkif_schedule+0xb8/0x320 [xen_blkback] [242640.332309] [] ? add_wait_queue+0x60/0x60 [242640.332314] [] ? xen_blkif_be_int+0x30/0x30 [xen_blkback] [242640.332319] [] kthread+0x8c/0xa0 [242640.332326] [] kernel_thread_helper+0x4/0x10 [242640.332330] [] ? int_ret_from_sys_call+0x7/0x1b [242640.332336] [] ? retint_restore_args+0x5/0x6 [242640.332340] [] ? gs_change+0x13/0x13 [242645.920070] block drbd1: Local backing block device frozen? [242657.952074] block drbd1: Local backing block device frozen? [242669.984072] block drbd1: Local backing block device frozen? [242682.016071] block drbd1: Local backing block device frozen? [242694.048071] block drbd1: Local backing block device frozen? [242706.080071] block drbd1: Local backing block device frozen? [242718.112077] block drbd1: Local backing block device frozen? sb-voip2@sbvoip2:~$ sudo cat /proc/drbd version: 8.3.11 (api:88/proto:86-96) GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@sbvoip2, 2013-02-19 08:30:51 1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate D r----- ns:14732 nr:1784712 dw:1799444 dr:579340 al:31 bm:44 lo:1 pe:0 ua:0 ap:1 ep:1 wo:b def:0 chkpt:662 oos:0 As we can read after drbd block device frozen then blkback also not working [242640.332124] INFO: task blkback.2.xvda:5779 blocked for more than 120 seconds. Some one told me its because high load of IO but I alwasy monitor my server with xm top and the serer load always under 50% I hope anybody can help me, if you need some more log I will try to post it. Many thanks, Agya --e89a8f23597f49147704d8f9fe23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

    I have sent this problem earlier but maybe its= not detail, here I try to write more detail. I hope anybody can help me to= point out the problem.
    First of all I used Ubuntu 12.04 x64 both= for domain0 and domainU with modification to run under xen hypervisor and = work with remus.
    I follow and configured the remus with this notes=A0ht= tp://wiki.xen.org/wiki/Install_Xen_4.1.4_with_Remus_and_DRBD_on_Ubuntu_12.1= 0 but I used xen 4.2.2 as my hypervisor with DRBD 3.8.11 remus support = from this link=A0http://remusha.wikidot.com/loc= al--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz.
    If DRBD run wit= h Primary - secondary mode, there is no problem. However remus run with dua= l primary mode. If I try to run remus the drbd will freeze and cause my dom= ainU to freeze. With dmesg error message is below :

    [242525.600067] block drbd1: Local bac= king block device frozen?
    [242537.632070] block drbd1: Local backing block device frozen?
    [242549.664075] block drbd1: L= ocal backing block device frozen?
    [242561.696083] block drbd1: Local backing block device fro= zen?
    [242573.728079] block drbd1: L= ocal backing block device frozen?
    [242585.760069] block drbd1: Local backing block device fro= zen?
    [242597.792079] block drbd1: L= ocal backing block device frozen?
    [242609.824069] block drbd1: Local backing block device fro= zen?
    [242621.856083] block drbd1: L= ocal backing block device frozen?
    [242633.888068] block drbd1: Local backing block device fro= zen?
    [242640.332124] INFO: task blk= back.2.xvda:5779 blocked for more than 120 seconds.
    [242640.332130] "echo 0 > /proc/s= ys/kernel/hung_task_timeout_secs" disables this message.
    [242640.332134] blkback.2.xvda= =A0D ffff88003fc13780 =A0 =A0 0 =A05779 =A0 =A0 =A02 0x00000000
    [242640.332142] =A0ffff88002= 6743940 0000000000000246 000000000000000b ffff8800267402d0
    [242640.332150] =A0ffff8800267= 43fd8 ffff880026743fd8 ffff880026743fd8 0000000000013780
    <= span style=3D"line-height:16.890625px">[242640.332157] =A0ffff880032944500 = ffff88003368c500 ffff8800357d6000 ffff8800357d69d8
    [242640.332164] Call Trace:
    [242640.332178] =A0[= <ffffffff816579cf>] schedule+0x3f/0x60
    [242640.332200] =A0[<ffffffffa00e68d5>] = drbd_al_begin_io+0x205/0x270 [drbd]
    [242640.332207] =A0[<ffffff= ff811adde8>] ? bvec_alloc_bs+0x68/0x100
    [242640.332212] =A0[<ffffffff811adf32>] ? bi= o_alloc_bioset+0xb2/0xf0
    [242640.332219] =A0[<ffffff= ff8108aa50>] ? add_wait_queue+0x60/0x60
    [242640.332231] =A0[<ffffffffa00e41bd>] drbd= _make_request_common+0xc4d/0x1430 [drbd]
    [242640.332239] =A0[<ffffff= ffa01b83ce>] ? xen_blkbk_map+0x24e/0x2f0 [xen_blkback]
    = [242640.332245] =A0[<ffffffff813= 01006>] ? throtl_find_tg+0x46/0x60
    [242640.332257] =A0[<ffffff= ffa00e4e04>] drbd_make_request+0x464/0x7e0 [drbd]
    [242640.332264] =A0[<ffffffff812f03bb= >] ? generic_make_request_checks+0x1eb/0x370
    [242640.332269] =A0[<ffffff= ff812f0194>] generic_make_request.part.50+0x74/0xb0
    [242640.332274] =A0[<ffffffff812f05= a8>] generic_make_request+0x68/0x70
    [242640.332278] =A0[<ffffff= ff812f0635>] submit_bio+0x85/0x110
    [242640.332284] =A0[<ffffffffa01b8f0f>] dispatch_= rw_block_io+0x44f/0x700 [xen_blkback]
    [242640.332292] =A0[<ffffff= ff8100330e>] ? xen_end_context_switch+0x1e/0x30
    [242640.332298] =A0[<ffffffffa01b93df&g= t;] __do_block_io_op+0x21f/0x360 [xen_blkback]
    [242640.332304] =A0[<ffffff= ffa01b9608>] xen_blkif_schedule+0xb8/0x320 [xen_blkback]
    [242640.332309] =A0[<ffffffff8= 108aa50>] ? add_wait_queue+0x60/0x60
    [242640.332314] =A0[<ffffff= ffa01b9550>] ? xen_blkif_be_int+0x30/0x30 [xen_blkback]
    [242640.332319] =A0[<ffffffff81= 089fbc>] kthread+0x8c/0xa0
    [242640.332326] =A0[<ffffff= ff81664034>] kernel_thread_helper+0x4/0x10
    [242640.332330] =A0[<ffffffff816620e3>] = ? int_ret_from_sys_call+0x7/0x1b
    [242640.332336] =A0[<ffffff= ff81659dbc>] ? retint_restore_args+0x5/0x6
    [242640.332340] =A0[<ffffffff81664030>] = ? gs_change+0x13/0x13
    [242645.920070] block drbd1: L= ocal backing block device frozen?
    [242657.952074] block drbd1: Local backing block device fro= zen?
    [242669.984072] block drbd1: L= ocal backing block device frozen?
    [242682.016071] block drbd1: Local backing block device fro= zen?
    [242694.048071] block drbd1: L= ocal backing block device frozen?
    [242706.080071] block drbd1: Local backing block device fro= zen?
    [242718.112077] block drbd1: L= ocal backing block device frozen?
    sb-voip2@sbvoip2:~$ sudo cat /proc/drbd
    version: 8.3.11 (api:88/proto:86-96)<= /span>
    GIT-hash: 0de839cee13a4160eed6= 037c4bddd066645e23c5 build by root@sbvoip2, 2013-02-19 08:30:51

    =A01: cs:Connected ro:Primary/Primary ds:U= pToDate/UpToDate D r-----
    =A0 =A0 ns:14732 nr:1784712 dw= :1799444 dr:579340 al:31 bm:44 lo:1 pe:0 ua:0 ap:1 ep:1 wo:b def:0 chkpt:66= 2 oos:0

    =
    As we can read after drbd block device frozen then blkback also not working= =A0

    [242640.332124] INFO: task blkback.2.xvda:5779 blocke= d for more than 120 seconds.

    Some one told me its because high load of IO but I alwasy moni= tor my server with xm top and the serer load always under 50%
    I hope anybody can help me, if you need some more log I will try to post it= .

    Many thanks,

    Agya
    --e89a8f23597f49147704d8f9fe23-- --===============7180022455631787470== 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 --===============7180022455631787470==-- From xen-users-bounces@lists.xen.org Thu Mar 28 10:57:02 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 10:57: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 1ULAUr-0000nF-Cz; Thu, 28 Mar 2013 10:55:53 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULAUp-0000n9-Vp for xen-users@lists.xen.org; Thu, 28 Mar 2013 10:55:52 +0000 Received: from [85.158.138.51:48273] by server-14.bemta-3.messagelabs.com id 81/F1-27076-7B124515; Thu, 28 Mar 2013 10:55:51 +0000 X-Env-Sender: agya.naila@gmail.com X-Msg-Ref: server-4.tower-174.messagelabs.com!1364468131!27540816!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP, spamassassin: , async_handler: YXN5bmNfZGVsYXk6IDcwNDc1OTQgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1587 invoked from network); 28 Mar 2013 10:55:33 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP; 28 Mar 2013 10:55:33 -0000 Received: by mail-ie0-f175.google.com with SMTP id c12so11228984ieb.20 for ; Thu, 28 Mar 2013 03:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=akxiS0lcaWgNA02Kwe3rMWiVX/XIqBzApUIGgZGJYVg=; b=tmMqYzINBk7wwP8Hw4pKpAcoq5jkIzxt4Rx6soWN6u/dooH+zP1iQC7X2n5Fa0KzU3 zpLvpaLjLk/k+Cx9JRFwu5T3WuG9bnQWoiV8XWq3RdJNDifnQ5ADHhnqZJIMGhWJuwPJ w0vPUhxRYGqPnbSz4lhb8kHnTRnKTqofHd3BUzF91L0pmljnhvf8oy6jZtRnJao97DNP Zv+PJb4dQektJnMtebXP3STHQSw9g0G3iMIFh4TwW1BlcKgeXMQkPAilsVZpbvURM6nh oAT3rJhuIzeYk2AE8sl7dz+oE3tJW0Q/FIMywzG8Gz2DaEMaKJ6lBw0QPxvzXXvwNonR Pj3w== MIME-Version: 1.0 X-Received: by 10.50.152.169 with SMTP id uz9mr7160513igb.15.1364468131499; Thu, 28 Mar 2013 03:55:31 -0700 (PDT) Received: by 10.42.54.8 with HTTP; Thu, 28 Mar 2013 03:55:31 -0700 (PDT) Date: Thu, 28 Mar 2013 11:55:31 +0100 Message-ID: From: agya naila To: xen-users@lists.xen.org, drbd-dev@lists.linbit.com Subject: [Xen-users] Xen Remus DRBD dual primary frozen X-BeenThere: xen-users@lists.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="===============7180022455631787470==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7180022455631787470== Content-Type: multipart/alternative; boundary=e89a8f23597f49147704d8f9fe23 --e89a8f23597f49147704d8f9fe23 Content-Type: text/plain; charset=ISO-8859-1 Dear all, I have sent this problem earlier but maybe its not detail, here I try to write more detail. I hope anybody can help me to point out the problem. First of all I used Ubuntu 12.04 x64 both for domain0 and domainU with modification to run under xen hypervisor and work with remus. I follow and configured the remus with this notes http://wiki.xen.org/wiki/Install_Xen_4.1.4_with_Remus_and_DRBD_on_Ubuntu_12.10but I used xen 4.2.2 as my hypervisor with DRBD 3.8.11 remus support from this link http://remusha.wikidot.com/local--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz . If DRBD run with Primary - secondary mode, there is no problem. However remus run with dual primary mode. If I try to run remus the drbd will freeze and cause my domainU to freeze. With dmesg error message is below : [242525.600067] block drbd1: Local backing block device frozen? [242537.632070] block drbd1: Local backing block device frozen? [242549.664075] block drbd1: Local backing block device frozen? [242561.696083] block drbd1: Local backing block device frozen? [242573.728079] block drbd1: Local backing block device frozen? [242585.760069] block drbd1: Local backing block device frozen? [242597.792079] block drbd1: Local backing block device frozen? [242609.824069] block drbd1: Local backing block device frozen? [242621.856083] block drbd1: Local backing block device frozen? [242633.888068] block drbd1: Local backing block device frozen? [242640.332124] INFO: task blkback.2.xvda:5779 blocked for more than 120 seconds. [242640.332130] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [242640.332134] blkback.2.xvda D ffff88003fc13780 0 5779 2 0x00000000 [242640.332142] ffff880026743940 0000000000000246 000000000000000b ffff8800267402d0 [242640.332150] ffff880026743fd8 ffff880026743fd8 ffff880026743fd8 0000000000013780 [242640.332157] ffff880032944500 ffff88003368c500 ffff8800357d6000 ffff8800357d69d8 [242640.332164] Call Trace: [242640.332178] [] schedule+0x3f/0x60 [242640.332200] [] drbd_al_begin_io+0x205/0x270 [drbd] [242640.332207] [] ? bvec_alloc_bs+0x68/0x100 [242640.332212] [] ? bio_alloc_bioset+0xb2/0xf0 [242640.332219] [] ? add_wait_queue+0x60/0x60 [242640.332231] [] drbd_make_request_common+0xc4d/0x1430 [drbd] [242640.332239] [] ? xen_blkbk_map+0x24e/0x2f0 [xen_blkback] [242640.332245] [] ? throtl_find_tg+0x46/0x60 [242640.332257] [] drbd_make_request+0x464/0x7e0 [drbd] [242640.332264] [] ? generic_make_request_checks+0x1eb/0x370 [242640.332269] [] generic_make_request.part.50+0x74/0xb0 [242640.332274] [] generic_make_request+0x68/0x70 [242640.332278] [] submit_bio+0x85/0x110 [242640.332284] [] dispatch_rw_block_io+0x44f/0x700 [xen_blkback] [242640.332292] [] ? xen_end_context_switch+0x1e/0x30 [242640.332298] [] __do_block_io_op+0x21f/0x360 [xen_blkback] [242640.332304] [] xen_blkif_schedule+0xb8/0x320 [xen_blkback] [242640.332309] [] ? add_wait_queue+0x60/0x60 [242640.332314] [] ? xen_blkif_be_int+0x30/0x30 [xen_blkback] [242640.332319] [] kthread+0x8c/0xa0 [242640.332326] [] kernel_thread_helper+0x4/0x10 [242640.332330] [] ? int_ret_from_sys_call+0x7/0x1b [242640.332336] [] ? retint_restore_args+0x5/0x6 [242640.332340] [] ? gs_change+0x13/0x13 [242645.920070] block drbd1: Local backing block device frozen? [242657.952074] block drbd1: Local backing block device frozen? [242669.984072] block drbd1: Local backing block device frozen? [242682.016071] block drbd1: Local backing block device frozen? [242694.048071] block drbd1: Local backing block device frozen? [242706.080071] block drbd1: Local backing block device frozen? [242718.112077] block drbd1: Local backing block device frozen? sb-voip2@sbvoip2:~$ sudo cat /proc/drbd version: 8.3.11 (api:88/proto:86-96) GIT-hash: 0de839cee13a4160eed6037c4bddd066645e23c5 build by root@sbvoip2, 2013-02-19 08:30:51 1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate D r----- ns:14732 nr:1784712 dw:1799444 dr:579340 al:31 bm:44 lo:1 pe:0 ua:0 ap:1 ep:1 wo:b def:0 chkpt:662 oos:0 As we can read after drbd block device frozen then blkback also not working [242640.332124] INFO: task blkback.2.xvda:5779 blocked for more than 120 seconds. Some one told me its because high load of IO but I alwasy monitor my server with xm top and the serer load always under 50% I hope anybody can help me, if you need some more log I will try to post it. Many thanks, Agya --e89a8f23597f49147704d8f9fe23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

    I have sent this problem earlier but maybe its= not detail, here I try to write more detail. I hope anybody can help me to= point out the problem.
    First of all I used Ubuntu 12.04 x64 both= for domain0 and domainU with modification to run under xen hypervisor and = work with remus.
    I follow and configured the remus with this notes=A0ht= tp://wiki.xen.org/wiki/Install_Xen_4.1.4_with_Remus_and_DRBD_on_Ubuntu_12.1= 0 but I used xen 4.2.2 as my hypervisor with DRBD 3.8.11 remus support = from this link=A0http://remusha.wikidot.com/loc= al--files/configuring-and-installing-remus/drbd-8.3.11-remus.tar.gz.
    If DRBD run wit= h Primary - secondary mode, there is no problem. However remus run with dua= l primary mode. If I try to run remus the drbd will freeze and cause my dom= ainU to freeze. With dmesg error message is below :

    [242525.600067] block drbd1: Local bac= king block device frozen?
    [242537.632070] block drbd1: Local backing block device frozen?
    [242549.664075] block drbd1: L= ocal backing block device frozen?
    [242561.696083] block drbd1: Local backing block device fro= zen?
    [242573.728079] block drbd1: L= ocal backing block device frozen?
    [242585.760069] block drbd1: Local backing block device fro= zen?
    [242597.792079] block drbd1: L= ocal backing block device frozen?
    [242609.824069] block drbd1: Local backing block device fro= zen?
    [242621.856083] block drbd1: L= ocal backing block device frozen?
    [242633.888068] block drbd1: Local backing block device fro= zen?
    [242640.332124] INFO: task blk= back.2.xvda:5779 blocked for more than 120 seconds.
    [242640.332130] "echo 0 > /proc/s= ys/kernel/hung_task_timeout_secs" disables this message.
    [242640.332134] blkback.2.xvda= =A0D ffff88003fc13780 =A0 =A0 0 =A05779 =A0 =A0 =A02 0x00000000
    [242640.332142] =A0ffff88002= 6743940 0000000000000246 000000000000000b ffff8800267402d0
    [242640.332150] =A0ffff8800267= 43fd8 ffff880026743fd8 ffff880026743fd8 0000000000013780
    <= span style=3D"line-height:16.890625px">[242640.332157] =A0ffff880032944500 = ffff88003368c500 ffff8800357d6000 ffff8800357d69d8
    [242640.332164] Call Trace:
    [242640.332178] =A0[= <ffffffff816579cf>] schedule+0x3f/0x60
    [242640.332200] =A0[<ffffffffa00e68d5>] = drbd_al_begin_io+0x205/0x270 [drbd]
    [242640.332207] =A0[<ffffff= ff811adde8>] ? bvec_alloc_bs+0x68/0x100
    [242640.332212] =A0[<ffffffff811adf32>] ? bi= o_alloc_bioset+0xb2/0xf0
    [242640.332219] =A0[<ffffff= ff8108aa50>] ? add_wait_queue+0x60/0x60
    [242640.332231] =A0[<ffffffffa00e41bd>] drbd= _make_request_common+0xc4d/0x1430 [drbd]
    [242640.332239] =A0[<ffffff= ffa01b83ce>] ? xen_blkbk_map+0x24e/0x2f0 [xen_blkback]
    = [242640.332245] =A0[<ffffffff813= 01006>] ? throtl_find_tg+0x46/0x60
    [242640.332257] =A0[<ffffff= ffa00e4e04>] drbd_make_request+0x464/0x7e0 [drbd]
    [242640.332264] =A0[<ffffffff812f03bb= >] ? generic_make_request_checks+0x1eb/0x370
    [242640.332269] =A0[<ffffff= ff812f0194>] generic_make_request.part.50+0x74/0xb0
    [242640.332274] =A0[<ffffffff812f05= a8>] generic_make_request+0x68/0x70
    [242640.332278] =A0[<ffffff= ff812f0635>] submit_bio+0x85/0x110
    [242640.332284] =A0[<ffffffffa01b8f0f>] dispatch_= rw_block_io+0x44f/0x700 [xen_blkback]
    [242640.332292] =A0[<ffffff= ff8100330e>] ? xen_end_context_switch+0x1e/0x30
    [242640.332298] =A0[<ffffffffa01b93df&g= t;] __do_block_io_op+0x21f/0x360 [xen_blkback]
    [242640.332304] =A0[<ffffff= ffa01b9608>] xen_blkif_schedule+0xb8/0x320 [xen_blkback]
    [242640.332309] =A0[<ffffffff8= 108aa50>] ? add_wait_queue+0x60/0x60
    [242640.332314] =A0[<ffffff= ffa01b9550>] ? xen_blkif_be_int+0x30/0x30 [xen_blkback]
    [242640.332319] =A0[<ffffffff81= 089fbc>] kthread+0x8c/0xa0
    [242640.332326] =A0[<ffffff= ff81664034>] kernel_thread_helper+0x4/0x10
    [242640.332330] =A0[<ffffffff816620e3>] = ? int_ret_from_sys_call+0x7/0x1b
    [242640.332336] =A0[<ffffff= ff81659dbc>] ? retint_restore_args+0x5/0x6
    [242640.332340] =A0[<ffffffff81664030>] = ? gs_change+0x13/0x13
    [242645.920070] block drbd1: L= ocal backing block device frozen?
    [242657.952074] block drbd1: Local backing block device fro= zen?
    [242669.984072] block drbd1: L= ocal backing block device frozen?
    [242682.016071] block drbd1: Local backing block device fro= zen?
    [242694.048071] block drbd1: L= ocal backing block device frozen?
    [242706.080071] block drbd1: Local backing block device fro= zen?
    [242718.112077] block drbd1: L= ocal backing block device frozen?
    sb-voip2@sbvoip2:~$ sudo cat /proc/drbd
    version: 8.3.11 (api:88/proto:86-96)<= /span>
    GIT-hash: 0de839cee13a4160eed6= 037c4bddd066645e23c5 build by root@sbvoip2, 2013-02-19 08:30:51

    =A01: cs:Connected ro:Primary/Primary ds:U= pToDate/UpToDate D r-----
    =A0 =A0 ns:14732 nr:1784712 dw= :1799444 dr:579340 al:31 bm:44 lo:1 pe:0 ua:0 ap:1 ep:1 wo:b def:0 chkpt:66= 2 oos:0

    =
    As we can read after drbd block device frozen then blkback also not working= =A0

    [242640.332124] INFO: task blkback.2.xvda:5779 blocke= d for more than 120 seconds.

    Some one told me its because high load of IO but I alwasy moni= tor my server with xm top and the serer load always under 50%
    I hope anybody can help me, if you need some more log I will try to post it= .

    Many thanks,

    Agya
    --e89a8f23597f49147704d8f9fe23-- --===============7180022455631787470== 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 --===============7180022455631787470==-- From xen-users-bounces@lists.xen.org Thu Mar 28 12:55:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 12:55: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 1ULCLm-0004mt-J4; Thu, 28 Mar 2013 12:54:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULCLl-0004mf-Rb for xen-users@lists.xen.org; Thu, 28 Mar 2013 12:54:38 +0000 Received: from [85.158.137.99:57857] by server-3.bemta-3.messagelabs.com id CC/8B-26934-D8D34515; Thu, 28 Mar 2013 12:54:37 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-6.tower-217.messagelabs.com!1364475272!12791927!1 X-Originating-IP: [89.16.177.154] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25898 invoked from network); 28 Mar 2013 12:54:32 -0000 Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154) by server-6.tower-217.messagelabs.com with SMTP; 28 Mar 2013 12:54:32 -0000 Received: (qmail 31103 invoked by uid 634); 28 Mar 2013 12:54:31 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from no-dns-yet.demon.co.uk (HELO [192.168.14.198]) (62.49.66.12) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Thu, 28 Mar 2013 12:54:31 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Anil Madhavapeddy In-Reply-To: <9F2C4E7DFB7839489C89757A66C5AD6205F056@LONPEX01CL03.citrite.net> Date: Thu, 28 Mar 2013 12:54:28 +0000 Message-Id: References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> <9F2C4E7DFB7839489C89757A66C5AD6205F056@LONPEX01CL03.citrite.net> To: Felipe Franciosi X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: "xen-users@lists.xen.org" , George Dunlap , "cl-mirage@lists.cam.ac.uk List" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 Mar 2013, at 12:51, Felipe Franciosi wrote: > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Anil Madhavapeddy > Sent: 27 March 2013 19:37 > To: George Dunlap > Cc: xen-users@lists.xen.org; cl-mirage@lists.cam.ac.uk List; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] Request for input: Extended event channel support > > >> If I'm not mistaken, every guest needs at least 2 event channels (console, xenstore) and probably has two more for a net and disk device. > > Presumably for vCPUs as well IINM? Yes, except that in Mirage's case we're single vCPU only, and use multiple VMs to act as parallel processes with explicit message passing. But we would still need an event channel for the vchan shared ring, in this case too... -anil _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 12:55:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 12:55: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 1ULCLm-0004mt-J4; Thu, 28 Mar 2013 12:54:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULCLl-0004mf-Rb for xen-users@lists.xen.org; Thu, 28 Mar 2013 12:54:38 +0000 Received: from [85.158.137.99:57857] by server-3.bemta-3.messagelabs.com id CC/8B-26934-D8D34515; Thu, 28 Mar 2013 12:54:37 +0000 X-Env-Sender: anil@recoil.org X-Msg-Ref: server-6.tower-217.messagelabs.com!1364475272!12791927!1 X-Originating-IP: [89.16.177.154] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25898 invoked from network); 28 Mar 2013 12:54:32 -0000 Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154) by server-6.tower-217.messagelabs.com with SMTP; 28 Mar 2013 12:54:32 -0000 Received: (qmail 31103 invoked by uid 634); 28 Mar 2013 12:54:31 -0000 X-Spam-Level: * X-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: dark.recoil.org Received: from no-dns-yet.demon.co.uk (HELO [192.168.14.198]) (62.49.66.12) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Thu, 28 Mar 2013 12:54:31 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Anil Madhavapeddy In-Reply-To: <9F2C4E7DFB7839489C89757A66C5AD6205F056@LONPEX01CL03.citrite.net> Date: Thu, 28 Mar 2013 12:54:28 +0000 Message-Id: References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> <9F2C4E7DFB7839489C89757A66C5AD6205F056@LONPEX01CL03.citrite.net> To: Felipe Franciosi X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Cc: "xen-users@lists.xen.org" , George Dunlap , "cl-mirage@lists.cam.ac.uk List" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 Mar 2013, at 12:51, Felipe Franciosi wrote: > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Anil Madhavapeddy > Sent: 27 March 2013 19:37 > To: George Dunlap > Cc: xen-users@lists.xen.org; cl-mirage@lists.cam.ac.uk List; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] Request for input: Extended event channel support > > >> If I'm not mistaken, every guest needs at least 2 event channels (console, xenstore) and probably has two more for a net and disk device. > > Presumably for vCPUs as well IINM? Yes, except that in Mirage's case we're single vCPU only, and use multiple VMs to act as parallel processes with explicit message passing. But we would still need an event channel for the vchan shared ring, in this case too... -anil _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 18:02:10 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:02: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 1ULH8M-0006k0-Jd; Thu, 28 Mar 2013 18:01:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULCTF-0005Xl-Es; Thu, 28 Mar 2013 13:02:21 +0000 Received: from [85.158.139.211:42605] by server-13.bemta-5.messagelabs.com id AD/1A-20553-C5F34515; Thu, 28 Mar 2013 13:02:20 +0000 X-Env-Sender: felipe.franciosi@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1364475739!18136985!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15610 invoked from network); 28 Mar 2013 13:02:19 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 28 Mar 2013 13:02:19 -0000 X-IronPort-AV: E=Sophos;i="4.84,925,1355097600"; d="scan'208";a="3009337" Received: from lonpex01cl02.citrite.net ([10.30.203.102]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 28 Mar 2013 13:02:20 +0000 Received: from LONPEX01CL03.citrite.net ([169.254.3.114]) by LONPEX01CL02.citrite.net ([10.30.203.102]) with mapi id 14.02.0342.003; Thu, 28 Mar 2013 13:02:19 +0000 From: Felipe Franciosi To: 'Anil Madhavapeddy' Thread-Topic: [Xen-devel] Request for input: Extended event channel support Thread-Index: AQHOKt2+U4fNIrGUlk6DqMyIlegjyJi57xaAgAEgY9CAAAGPAIAAAOsQ Date: Thu, 28 Mar 2013 13:02:18 +0000 Message-ID: <9F2C4E7DFB7839489C89757A66C5AD6205F0F0@LONPEX01CL03.citrite.net> References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> <9F2C4E7DFB7839489C89757A66C5AD6205F056@LONPEX01CL03.citrite.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.203.1] MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 Mar 2013 18:01:00 +0000 Cc: "xen-users@lists.xen.org" , George Dunlap , "cl-mirage@lists.cam.ac.uk List" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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: Anil Madhavapeddy [mailto:anil@recoil.org] Sent: 28 March 2013 12:54 To: Felipe Franciosi Cc: xen-users@lists.xen.org; George Dunlap; cl-mirage@lists.cam.ac.uk List; xen-devel@lists.xen.org Subject: Re: [Xen-devel] Request for input: Extended event channel support >> Presumably for vCPUs as well IINM? >Yes, except that in Mirage's case we're single vCPU only, and use multiple VMs to act as parallel processes with explicit message passing. There's also the buffered IO event channel, but I'm pretty sure this is only for HVM so shouldn't affect the Mirage use case. Just mentioning in case there is someone out there reading this and working out numbers for HVM guests. :) http://lists.xen.org/archives/html/xen-changelog/2011-11/msg00139.html Cheers, Felipe _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 18:02:10 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:02: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 1ULH8M-0006k0-Jd; Thu, 28 Mar 2013 18:01:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULCTF-0005Xl-Es; Thu, 28 Mar 2013 13:02:21 +0000 Received: from [85.158.139.211:42605] by server-13.bemta-5.messagelabs.com id AD/1A-20553-C5F34515; Thu, 28 Mar 2013 13:02:20 +0000 X-Env-Sender: felipe.franciosi@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1364475739!18136985!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15610 invoked from network); 28 Mar 2013 13:02:19 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 28 Mar 2013 13:02:19 -0000 X-IronPort-AV: E=Sophos;i="4.84,925,1355097600"; d="scan'208";a="3009337" Received: from lonpex01cl02.citrite.net ([10.30.203.102]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 28 Mar 2013 13:02:20 +0000 Received: from LONPEX01CL03.citrite.net ([169.254.3.114]) by LONPEX01CL02.citrite.net ([10.30.203.102]) with mapi id 14.02.0342.003; Thu, 28 Mar 2013 13:02:19 +0000 From: Felipe Franciosi To: 'Anil Madhavapeddy' Thread-Topic: [Xen-devel] Request for input: Extended event channel support Thread-Index: AQHOKt2+U4fNIrGUlk6DqMyIlegjyJi57xaAgAEgY9CAAAGPAIAAAOsQ Date: Thu, 28 Mar 2013 13:02:18 +0000 Message-ID: <9F2C4E7DFB7839489C89757A66C5AD6205F0F0@LONPEX01CL03.citrite.net> References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> <9F2C4E7DFB7839489C89757A66C5AD6205F056@LONPEX01CL03.citrite.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.203.1] MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 Mar 2013 18:01:00 +0000 Cc: "xen-users@lists.xen.org" , George Dunlap , "cl-mirage@lists.cam.ac.uk List" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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: Anil Madhavapeddy [mailto:anil@recoil.org] Sent: 28 March 2013 12:54 To: Felipe Franciosi Cc: xen-users@lists.xen.org; George Dunlap; cl-mirage@lists.cam.ac.uk List; xen-devel@lists.xen.org Subject: Re: [Xen-devel] Request for input: Extended event channel support >> Presumably for vCPUs as well IINM? >Yes, except that in Mirage's case we're single vCPU only, and use multiple VMs to act as parallel processes with explicit message passing. There's also the buffered IO event channel, but I'm pretty sure this is only for HVM so shouldn't affect the Mirage use case. Just mentioning in case there is someone out there reading this and working out numbers for HVM guests. :) http://lists.xen.org/archives/html/xen-changelog/2011-11/msg00139.html Cheers, Felipe _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 18:02:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:02: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 1ULH8L-0006ji-CT; Thu, 28 Mar 2013 18:01:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKyIT-0007LB-SU; Wed, 27 Mar 2013 21:54:18 +0000 Received: from [85.158.139.83:7838] by server-16.bemta-5.messagelabs.com id EA/49-02543-78A63515; Wed, 27 Mar 2013 21:54:15 +0000 X-Env-Sender: dvrabel@cantab.net X-Msg-Ref: server-16.tower-182.messagelabs.com!1364421251!20284879!1 X-Originating-IP: [212.23.1.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjEyLjIzLjEuMSA9PiA2ODI0MQ==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6565 invoked from network); 27 Mar 2013 21:54:11 -0000 Received: from smarthost01.mail.zen.net.uk (HELO smarthost01.mail.zen.net.uk) (212.23.1.1) by server-16.tower-182.messagelabs.com with SMTP; 27 Mar 2013 21:54:11 -0000 Received: from [82.70.146.41] (helo=pear) by smarthost01.mail.zen.net.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UKyHN-0000O3-3X; Wed, 27 Mar 2013 21:53:09 +0000 Received: from apple.davidvrabel.org.uk ([82.70.146.43]) by pear with esmtp (Exim 4.72) (envelope-from ) id 1UKyHL-0001hu-4u; Wed, 27 Mar 2013 21:53:08 +0000 Message-ID: <51536A3E.2020302@cantab.net> Date: Wed, 27 Mar 2013 21:53:02 +0000 From: David Vrabel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Anil Madhavapeddy References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> In-Reply-To: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> X-SA-Exim-Connect-IP: 82.70.146.43 X-SA-Exim-Mail-From: dvrabel@cantab.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pear X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_NEUTRAL autolearn=no version=3.3.1 X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000) X-SA-Exim-Scanned: Yes (on pear) X-Originating-Smarthost01-IP: [82.70.146.41] X-Mailman-Approved-At: Thu, 28 Mar 2013 18:01:00 +0000 Cc: xen-users@lists.xen.org, George Dunlap , "cl-mirage@lists.cam.ac.uk List" , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 27/03/2013 19:36, Anil Madhavapeddy wrote: > On 27 Mar 2013, at 11:23, George Dunlap wrote: >> >> The FIFO solution makes event delivery a matter of adding items to a >> highly structured linked list. The number of event channels for the >> interface design has a theoretical maximum of 2^28; the current >> implementation is limimited at 2^17, which is over 100,000. The >> number is the same for both 32-bit and 64-bit kernels. > > Is there any reason for such a low default? If I'm not mistaken, > every guest needs at least 2 event channels (console, xenstore) and > probably has two more for a net and disk device. 131,072 seemed high enough to me but I'd forgotten about the Mirage use case. This can be trivially raised to 2^19 (524,288). Beyond that, the implementation becomes slightly more complex as the pointers to the event array pages no longer fit in a single page. > With stub-domains in the mix, we could easily imagine running 25,000 > VMs with a couple of megabytes of RAM each using Mirage (which can > boot very low memory guests without too much trouble). Having said that, with 25,000 VMs it would seem sensible to disaggregate things like the console and xenstore (in addition to the network and block backends). Thus reducing the need for event channels for any single domain. David _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 18:02:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:02: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 1ULH8L-0006ji-CT; Thu, 28 Mar 2013 18:01:05 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1UKyIT-0007LB-SU; Wed, 27 Mar 2013 21:54:18 +0000 Received: from [85.158.139.83:7838] by server-16.bemta-5.messagelabs.com id EA/49-02543-78A63515; Wed, 27 Mar 2013 21:54:15 +0000 X-Env-Sender: dvrabel@cantab.net X-Msg-Ref: server-16.tower-182.messagelabs.com!1364421251!20284879!1 X-Originating-IP: [212.23.1.1] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjEyLjIzLjEuMSA9PiA2ODI0MQ==\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6565 invoked from network); 27 Mar 2013 21:54:11 -0000 Received: from smarthost01.mail.zen.net.uk (HELO smarthost01.mail.zen.net.uk) (212.23.1.1) by server-16.tower-182.messagelabs.com with SMTP; 27 Mar 2013 21:54:11 -0000 Received: from [82.70.146.41] (helo=pear) by smarthost01.mail.zen.net.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UKyHN-0000O3-3X; Wed, 27 Mar 2013 21:53:09 +0000 Received: from apple.davidvrabel.org.uk ([82.70.146.43]) by pear with esmtp (Exim 4.72) (envelope-from ) id 1UKyHL-0001hu-4u; Wed, 27 Mar 2013 21:53:08 +0000 Message-ID: <51536A3E.2020302@cantab.net> Date: Wed, 27 Mar 2013 21:53:02 +0000 From: David Vrabel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Anil Madhavapeddy References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> In-Reply-To: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> X-SA-Exim-Connect-IP: 82.70.146.43 X-SA-Exim-Mail-From: dvrabel@cantab.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pear X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_NEUTRAL autolearn=no version=3.3.1 X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000) X-SA-Exim-Scanned: Yes (on pear) X-Originating-Smarthost01-IP: [82.70.146.41] X-Mailman-Approved-At: Thu, 28 Mar 2013 18:01:00 +0000 Cc: xen-users@lists.xen.org, George Dunlap , "cl-mirage@lists.cam.ac.uk List" , xen-devel@lists.xen.org Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 27/03/2013 19:36, Anil Madhavapeddy wrote: > On 27 Mar 2013, at 11:23, George Dunlap wrote: >> >> The FIFO solution makes event delivery a matter of adding items to a >> highly structured linked list. The number of event channels for the >> interface design has a theoretical maximum of 2^28; the current >> implementation is limimited at 2^17, which is over 100,000. The >> number is the same for both 32-bit and 64-bit kernels. > > Is there any reason for such a low default? If I'm not mistaken, > every guest needs at least 2 event channels (console, xenstore) and > probably has two more for a net and disk device. 131,072 seemed high enough to me but I'd forgotten about the Mirage use case. This can be trivially raised to 2^19 (524,288). Beyond that, the implementation becomes slightly more complex as the pointers to the event array pages no longer fit in a single page. > With stub-domains in the mix, we could easily imagine running 25,000 > VMs with a couple of megabytes of RAM each using Mirage (which can > boot very low memory guests without too much trouble). Having said that, with 25,000 VMs it would seem sensible to disaggregate things like the console and xenstore (in addition to the network and block backends). Thus reducing the need for event channels for any single domain. David _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 18:02:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:02: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 1ULH8L-0006jr-WE; Thu, 28 Mar 2013 18:01:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULCIi-0004Q8-V5; Thu, 28 Mar 2013 12:51:29 +0000 Received: from [85.158.139.83:9456] by server-1.bemta-5.messagelabs.com id 6E/8E-14063-0DC34515; Thu, 28 Mar 2013 12:51:28 +0000 X-Env-Sender: felipe.franciosi@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1364475086!27462213!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31572 invoked from network); 28 Mar 2013 12:51:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Mar 2013 12:51:27 -0000 X-IronPort-AV: E=Sophos;i="4.84,925,1355097600"; d="scan'208";a="3008947" Received: from lonpex01cl02.citrite.net ([10.30.203.102]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 28 Mar 2013 12:51:26 +0000 Received: from LONPEX01CL03.citrite.net ([169.254.3.114]) by LONPEX01CL02.citrite.net ([10.30.203.102]) with mapi id 14.02.0342.003; Thu, 28 Mar 2013 12:51:26 +0000 From: Felipe Franciosi To: 'Anil Madhavapeddy' Thread-Topic: [Xen-devel] Request for input: Extended event channel support Thread-Index: AQHOKt2+U4fNIrGUlk6DqMyIlegjyJi57xaAgAEgY9A= Date: Thu, 28 Mar 2013 12:51:25 +0000 Message-ID: <9F2C4E7DFB7839489C89757A66C5AD6205F056@LONPEX01CL03.citrite.net> References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> In-Reply-To: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.203.1] MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 Mar 2013 18:01:00 +0000 Cc: "xen-users@lists.xen.org" , George Dunlap , "cl-mirage@lists.cam.ac.uk List" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Anil Madhavapeddy Sent: 27 March 2013 19:37 To: George Dunlap Cc: xen-users@lists.xen.org; cl-mirage@lists.cam.ac.uk List; xen-devel@lists.xen.org Subject: Re: [Xen-devel] Request for input: Extended event channel support > If I'm not mistaken, every guest needs at least 2 event channels (console, xenstore) and probably has two more for a net and disk device. Presumably for vCPUs as well IINM? Felipe _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 18:02:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:02: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 1ULH8L-0006jr-WE; Thu, 28 Mar 2013 18:01:06 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULCIi-0004Q8-V5; Thu, 28 Mar 2013 12:51:29 +0000 Received: from [85.158.139.83:9456] by server-1.bemta-5.messagelabs.com id 6E/8E-14063-0DC34515; Thu, 28 Mar 2013 12:51:28 +0000 X-Env-Sender: felipe.franciosi@citrix.com X-Msg-Ref: server-15.tower-182.messagelabs.com!1364475086!27462213!1 X-Originating-IP: [46.33.159.39] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNDYuMzMuMTU5LjM5ID0+IDI2MzI1\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31572 invoked from network); 28 Mar 2013 12:51:27 -0000 Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (46.33.159.39) by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP; 28 Mar 2013 12:51:27 -0000 X-IronPort-AV: E=Sophos;i="4.84,925,1355097600"; d="scan'208";a="3008947" Received: from lonpex01cl02.citrite.net ([10.30.203.102]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 28 Mar 2013 12:51:26 +0000 Received: from LONPEX01CL03.citrite.net ([169.254.3.114]) by LONPEX01CL02.citrite.net ([10.30.203.102]) with mapi id 14.02.0342.003; Thu, 28 Mar 2013 12:51:26 +0000 From: Felipe Franciosi To: 'Anil Madhavapeddy' Thread-Topic: [Xen-devel] Request for input: Extended event channel support Thread-Index: AQHOKt2+U4fNIrGUlk6DqMyIlegjyJi57xaAgAEgY9A= Date: Thu, 28 Mar 2013 12:51:25 +0000 Message-ID: <9F2C4E7DFB7839489C89757A66C5AD6205F056@LONPEX01CL03.citrite.net> References: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> In-Reply-To: <8E3B77A0-C082-4F98-995E-CC1514631D49@recoil.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.30.203.1] MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 Mar 2013 18:01:00 +0000 Cc: "xen-users@lists.xen.org" , George Dunlap , "cl-mirage@lists.cam.ac.uk List" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Anil Madhavapeddy Sent: 27 March 2013 19:37 To: George Dunlap Cc: xen-users@lists.xen.org; cl-mirage@lists.cam.ac.uk List; xen-devel@lists.xen.org Subject: Re: [Xen-devel] Request for input: Extended event channel support > If I'm not mistaken, every guest needs at least 2 event channels (console, xenstore) and probably has two more for a net and disk device. Presumably for vCPUs as well IINM? Felipe _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 18:02:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:02: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 1ULH8N-0006k9-8I; Thu, 28 Mar 2013 18:01:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULGu6-0006Hq-04 for xen-users@lists.xen.org; Thu, 28 Mar 2013 17:46:22 +0000 Received: from [193.109.254.147:41957] by server-2.bemta-14.messagelabs.com id 3C/D2-14115-DE184515; Thu, 28 Mar 2013 17:46:21 +0000 X-Env-Sender: getchus1@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1364492780!2170551!1 X-Originating-IP: [74.125.82.52] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26656 invoked from network); 28 Mar 2013 17:46:20 -0000 Received: from unknown (HELO mail-wg0-f52.google.com) (74.125.82.52) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Mar 2013 17:46:20 -0000 Received: by mail-wg0-f52.google.com with SMTP id n12so1781895wgh.19 for ; Thu, 28 Mar 2013 10:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=SN84gUFd65oZkkUX1UyNZlX3K4Eq0bSwYmyUer1cISA=; b=rMtNkJ04xPq6+jGsisSETStoF3nuObLFgRYQvzbxdXD0ZBSrJziCSdYm4X0J1XubSo TLDz6dObKnUH59NMbnz6a1qoqsD92kf2oE0s3Ya/yhJUYsC6uGVG8zVJ4MrHb4/pyBNC OsrIWeMX3G8zST2gkomxSCXGO2fJP05Rl3o7wakD4m2TVZxaP+hTNqyGXzGKVzp4pBNA BOeh61VTP3OrpZtkC5uZzpjA9nUb6vj64vEkWW16Zr7b2khs+w7NLqiUEvvOpVBTFwiE KfJHCClknzEPYMTQLyr2kBx96TRyI9ZnmCRuqtFw6YKrU8H6BaSKkrRvOBtxS7M2ziZU 7+1w== MIME-Version: 1.0 X-Received: by 10.180.11.148 with SMTP id q20mr17842698wib.18.1364492711453; Thu, 28 Mar 2013 10:45:11 -0700 (PDT) Received: by 10.194.62.174 with HTTP; Thu, 28 Mar 2013 10:45:11 -0700 (PDT) Date: Fri, 29 Mar 2013 02:45:11 +0900 Message-ID: From: =?UTF-8?B?7J207JiB7KSA?= To: xen-users@lists.xen.org X-Mailman-Approved-At: Thu, 28 Mar 2013 18:01:00 +0000 Subject: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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="===============3834790919030623253==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3834790919030623253== Content-Type: multipart/alternative; boundary=001a11c24cda5d6a5f04d8ffb7a0 --001a11c24cda5d6a5f04d8ffb7a0 Content-Type: text/plain; charset=ISO-8859-1 I am using gentoo linux. When I input, /etc/init.d/xend start, system replies /etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied /etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied I am searching internet by google, but I can't find a method. Someone have any ideas How can I fix this problem? Thank you. --001a11c24cda5d6a5f04d8ffb7a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I am using gentoo linux.
    =A0
    When I input, /etc/i= nit.d/xend start, system replies
    /etc/init.d/xend: /usr/sbin/xen= d: /usr/lib/portage/pym: bad interpreter: Permission denied
    /etc/init.d/= xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission den= ied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: P= ermission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym= : bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: = /usr/lib/portage/pym: bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: P= ermission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym= : bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: = /usr/lib/portage/pym: bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: P= ermission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym= : bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: = /usr/lib/portage/pym: bad interpreter: Permission denied
    I am searching internet by google, but I can't find a method= .
    Someone have any ideas How can I fix this problem?
    = =A0
    Thank you.
    =A0
    =A0
    --001a11c24cda5d6a5f04d8ffb7a0-- --===============3834790919030623253== 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 --===============3834790919030623253==-- From xen-users-bounces@lists.xen.org Thu Mar 28 18:02:11 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:02: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 1ULH8N-0006k9-8I; Thu, 28 Mar 2013 18:01:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULGu6-0006Hq-04 for xen-users@lists.xen.org; Thu, 28 Mar 2013 17:46:22 +0000 Received: from [193.109.254.147:41957] by server-2.bemta-14.messagelabs.com id 3C/D2-14115-DE184515; Thu, 28 Mar 2013 17:46:21 +0000 X-Env-Sender: getchus1@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1364492780!2170551!1 X-Originating-IP: [74.125.82.52] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26656 invoked from network); 28 Mar 2013 17:46:20 -0000 Received: from unknown (HELO mail-wg0-f52.google.com) (74.125.82.52) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Mar 2013 17:46:20 -0000 Received: by mail-wg0-f52.google.com with SMTP id n12so1781895wgh.19 for ; Thu, 28 Mar 2013 10:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=SN84gUFd65oZkkUX1UyNZlX3K4Eq0bSwYmyUer1cISA=; b=rMtNkJ04xPq6+jGsisSETStoF3nuObLFgRYQvzbxdXD0ZBSrJziCSdYm4X0J1XubSo TLDz6dObKnUH59NMbnz6a1qoqsD92kf2oE0s3Ya/yhJUYsC6uGVG8zVJ4MrHb4/pyBNC OsrIWeMX3G8zST2gkomxSCXGO2fJP05Rl3o7wakD4m2TVZxaP+hTNqyGXzGKVzp4pBNA BOeh61VTP3OrpZtkC5uZzpjA9nUb6vj64vEkWW16Zr7b2khs+w7NLqiUEvvOpVBTFwiE KfJHCClknzEPYMTQLyr2kBx96TRyI9ZnmCRuqtFw6YKrU8H6BaSKkrRvOBtxS7M2ziZU 7+1w== MIME-Version: 1.0 X-Received: by 10.180.11.148 with SMTP id q20mr17842698wib.18.1364492711453; Thu, 28 Mar 2013 10:45:11 -0700 (PDT) Received: by 10.194.62.174 with HTTP; Thu, 28 Mar 2013 10:45:11 -0700 (PDT) Date: Fri, 29 Mar 2013 02:45:11 +0900 Message-ID: From: =?UTF-8?B?7J207JiB7KSA?= To: xen-users@lists.xen.org X-Mailman-Approved-At: Thu, 28 Mar 2013 18:01:00 +0000 Subject: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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="===============3834790919030623253==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3834790919030623253== Content-Type: multipart/alternative; boundary=001a11c24cda5d6a5f04d8ffb7a0 --001a11c24cda5d6a5f04d8ffb7a0 Content-Type: text/plain; charset=ISO-8859-1 I am using gentoo linux. When I input, /etc/init.d/xend start, system replies /etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied /etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied I am searching internet by google, but I can't find a method. Someone have any ideas How can I fix this problem? Thank you. --001a11c24cda5d6a5f04d8ffb7a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I am using gentoo linux.
    =A0
    When I input, /etc/i= nit.d/xend start, system replies
    /etc/init.d/xend: /usr/sbin/xen= d: /usr/lib/portage/pym: bad interpreter: Permission denied
    /etc/init.d/= xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission den= ied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: P= ermission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym= : bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: = /usr/lib/portage/pym: bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: P= ermission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym= : bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: = /usr/lib/portage/pym: bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: P= ermission denied
    ./etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym= : bad interpreter: Permission denied
    ./etc/init.d/xend: /usr/sbin/xend: = /usr/lib/portage/pym: bad interpreter: Permission denied
    I am searching internet by google, but I can't find a method= .
    Someone have any ideas How can I fix this problem?
    = =A0
    Thank you.
    =A0
    =A0
    --001a11c24cda5d6a5f04d8ffb7a0-- --===============3834790919030623253== 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 --===============3834790919030623253==-- From xen-users-bounces@lists.xen.org Thu Mar 28 18:20:03 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:20: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 1ULHQ1-0008FT-8s; Thu, 28 Mar 2013 18:19:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULHQ0-0008FO-7D for xen-users@lists.xen.org; Thu, 28 Mar 2013 18:19:20 +0000 Received: from [85.158.137.99:23812] by server-11.bemta-3.messagelabs.com id 99/09-01263-7A984515; Thu, 28 Mar 2013 18:19:19 +0000 X-Env-Sender: mihai.dontu@gmail.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1364494758!13953532!1 X-Originating-IP: [91.199.104.2] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24201 invoked from network); 28 Mar 2013 18:19:18 -0000 Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2) by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Mar 2013 18:19:18 -0000 Received: (qmail 10113 invoked from network); 28 Mar 2013 20:19:16 +0200 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.13.7.1697400, Dats: 253594, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled], APM: [Enabled, Score: 500, Flags: NN_S_ENDS_IN_FULLSTOP_BGU; NN_LEGIT_VALID_REPLY; NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, Hits: none, MD5: 1d4fe0804a1ac4d655c5b196415c28d5.fuzzy.fzrbl.org], RTDA: [Enabled, Hit: No, Details: v1.4.7; Id: 2m1g30i.17mkurpi7.4ndrh], total: 0(775) X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on elfie.dsd.hq, sigver: 7.46308 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gmail.com; b=gWFAYj75R4oY9gRDWxEDbl3WxAZ7rVQttF1y/FMPV5mx4AChRv0vo8ZqmN020iLuqfk3vOaj0NABbcEO8/GHWlJmTEpXKUplKXPwfDI/WaJv9RXWTmQ2YYN1WSd2Pq8jeL2eqkZ0YABMXyBUvq25ENTWHenX2FgeZnIm+8vA+y8= ; Received: from mdontu-l.dsd.ro (mdontu@bitdefender.com@10.10.14.115) by mail.bitdefender.com with SMTP; 28 Mar 2013 20:19:15 +0200 Date: Thu, 28 Mar 2013 20:19:16 +0200 From: Mihai =?UTF-8?B?RG9uyJt1?= To: xen-users@lists.xen.org Message-ID: <20130328201916.484058b2@mdontu-l.dsd.ro> In-Reply-To: References: Organization: Home Mime-Version: 1.0 Subject: Re: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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 T24gRnJpLCAyOSBNYXIgMjAxMyAwMjo0NToxMSArMDkwMCDsnbTsmIHspIAgd3JvdGU6Cj4gSSBh bSB1c2luZyBnZW50b28gbGludXguCj4gCj4gV2hlbiBJIGlucHV0LCAvZXRjL2luaXQuZC94ZW5k IHN0YXJ0LCBzeXN0ZW0gcmVwbGllcwo+IC9ldGMvaW5pdC5kL3hlbmQ6IC91c3Ivc2Jpbi94ZW5k OiAvdXNyL2xpYi9wb3J0YWdlL3B5bTogYmFkCj4gaW50ZXJwcmV0ZXI6IFBlcm1pc3Npb24gZGVu aWVkCj4gL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2Uv cHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQv eGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnBy ZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hl bmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBk ZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRh Z2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0 LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRl cnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmlu L3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lv biBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3Bv cnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9p bml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBp bnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9z YmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlz c2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGli L3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiBJIGFt IHNlYXJjaGluZyBpbnRlcm5ldCBieSBnb29nbGUsIGJ1dCBJIGNhbid0IGZpbmQgYSBtZXRob2Qu Cj4gU29tZW9uZSBoYXZlIGFueSBpZGVhcyBIb3cgY2FuIEkgZml4IHRoaXMgcHJvYmxlbT8KPiAK Cid4ZW5kJyBpcyBhIHB5dGhvbiBzY3JpcHQuIFRoZSBmaXJzdCBsaW5lIHNob3VsZCBiZSBzb21l dGhpbmcgbGlrZToKCiAgIyE8c2hlbGw+Cgp3aGljaCBpcyBjYWxsZWQgYSBzaGViYW5nWzFdLiBF eGFtcGxlOgoKICAjIS91c3IvYmluL3B5dGhvbgoKSXQgd291bGQgc2VlbSB0aGUgZWJ1aWxkIGhh cyByZXBsYWNlZCBpdCB3aXRoIHNvbWV0aGluZyBpbnZhbGlkLiBDYW4KeW91IGdpdmUgdXMgdGhl IG91dHB1dCBvZjoKCiAgJCBoZWFkIC1uIDUgL3Vzci9zYmluL3hlbmQKCgpbMV0gaHR0cHM6Ly9l bi53aWtpcGVkaWEub3JnL3dpa2kvU2hlYmFuZ18oVW5peCkKCi0tIApNaWhhaSBEb27Im3UKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi11c2VycyBt YWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv eGVuLXVzZXJz From xen-users-bounces@lists.xen.org Thu Mar 28 18:20:03 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18:20: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 1ULHQ1-0008FT-8s; Thu, 28 Mar 2013 18:19:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULHQ0-0008FO-7D for xen-users@lists.xen.org; Thu, 28 Mar 2013 18:19:20 +0000 Received: from [85.158.137.99:23812] by server-11.bemta-3.messagelabs.com id 99/09-01263-7A984515; Thu, 28 Mar 2013 18:19:19 +0000 X-Env-Sender: mihai.dontu@gmail.com X-Msg-Ref: server-5.tower-217.messagelabs.com!1364494758!13953532!1 X-Originating-IP: [91.199.104.2] X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14, spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24201 invoked from network); 28 Mar 2013 18:19:18 -0000 Received: from mail.bitdefender.com (HELO mail.bitdefender.com) (91.199.104.2) by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Mar 2013 18:19:18 -0000 Received: (qmail 10113 invoked from network); 28 Mar 2013 20:19:16 +0200 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.13.7.1697400, Dats: 253594, Stamp: 3], Multi: [Enabled], BW: [Enabled], RBL DNSBL: [Disabled], APM: [Enabled, Score: 500, Flags: NN_S_ENDS_IN_FULLSTOP_BGU; NN_LEGIT_VALID_REPLY; NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled], URL: [Enabled], URI DNSBL: [Disabled], SQMD: [Enabled, Hits: none, MD5: 1d4fe0804a1ac4d655c5b196415c28d5.fuzzy.fzrbl.org], RTDA: [Enabled, Hit: No, Details: v1.4.7; Id: 2m1g30i.17mkurpi7.4ndrh], total: 0(775) X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.0 on elfie.dsd.hq, sigver: 7.46308 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gmail.com; b=gWFAYj75R4oY9gRDWxEDbl3WxAZ7rVQttF1y/FMPV5mx4AChRv0vo8ZqmN020iLuqfk3vOaj0NABbcEO8/GHWlJmTEpXKUplKXPwfDI/WaJv9RXWTmQ2YYN1WSd2Pq8jeL2eqkZ0YABMXyBUvq25ENTWHenX2FgeZnIm+8vA+y8= ; Received: from mdontu-l.dsd.ro (mdontu@bitdefender.com@10.10.14.115) by mail.bitdefender.com with SMTP; 28 Mar 2013 20:19:15 +0200 Date: Thu, 28 Mar 2013 20:19:16 +0200 From: Mihai =?UTF-8?B?RG9uyJt1?= To: xen-users@lists.xen.org Message-ID: <20130328201916.484058b2@mdontu-l.dsd.ro> In-Reply-To: References: Organization: Home Mime-Version: 1.0 Subject: Re: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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 T24gRnJpLCAyOSBNYXIgMjAxMyAwMjo0NToxMSArMDkwMCDsnbTsmIHspIAgd3JvdGU6Cj4gSSBh bSB1c2luZyBnZW50b28gbGludXguCj4gCj4gV2hlbiBJIGlucHV0LCAvZXRjL2luaXQuZC94ZW5k IHN0YXJ0LCBzeXN0ZW0gcmVwbGllcwo+IC9ldGMvaW5pdC5kL3hlbmQ6IC91c3Ivc2Jpbi94ZW5k OiAvdXNyL2xpYi9wb3J0YWdlL3B5bTogYmFkCj4gaW50ZXJwcmV0ZXI6IFBlcm1pc3Npb24gZGVu aWVkCj4gL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2Uv cHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQv eGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnBy ZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hl bmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBk ZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRh Z2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0 LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRl cnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmlu L3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lv biBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3Bv cnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9p bml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBp bnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9z YmluL3hlbmQ6IC91c3IvbGliL3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlz c2lvbiBkZW5pZWQKPiAuL2V0Yy9pbml0LmQveGVuZDogL3Vzci9zYmluL3hlbmQ6IC91c3IvbGli L3BvcnRhZ2UvcHltOiBiYWQKPiBpbnRlcnByZXRlcjogUGVybWlzc2lvbiBkZW5pZWQKPiBJIGFt IHNlYXJjaGluZyBpbnRlcm5ldCBieSBnb29nbGUsIGJ1dCBJIGNhbid0IGZpbmQgYSBtZXRob2Qu Cj4gU29tZW9uZSBoYXZlIGFueSBpZGVhcyBIb3cgY2FuIEkgZml4IHRoaXMgcHJvYmxlbT8KPiAK Cid4ZW5kJyBpcyBhIHB5dGhvbiBzY3JpcHQuIFRoZSBmaXJzdCBsaW5lIHNob3VsZCBiZSBzb21l dGhpbmcgbGlrZToKCiAgIyE8c2hlbGw+Cgp3aGljaCBpcyBjYWxsZWQgYSBzaGViYW5nWzFdLiBF eGFtcGxlOgoKICAjIS91c3IvYmluL3B5dGhvbgoKSXQgd291bGQgc2VlbSB0aGUgZWJ1aWxkIGhh cyByZXBsYWNlZCBpdCB3aXRoIHNvbWV0aGluZyBpbnZhbGlkLiBDYW4KeW91IGdpdmUgdXMgdGhl IG91dHB1dCBvZjoKCiAgJCBoZWFkIC1uIDUgL3Vzci9zYmluL3hlbmQKCgpbMV0gaHR0cHM6Ly9l bi53aWtpcGVkaWEub3JnL3dpa2kvU2hlYmFuZ18oVW5peCkKCi0tIApNaWhhaSBEb27Im3UKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi11c2VycyBt YWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv eGVuLXVzZXJz From xen-users-bounces@lists.xen.org Thu Mar 28 18:47:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18: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 1ULHqR-0000qn-88; Thu, 28 Mar 2013 18:46:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULHqO-0000qQ-Rh for xen-users@lists.xen.org; Thu, 28 Mar 2013 18:46:37 +0000 Received: from [85.158.137.99:26565] by server-6.bemta-3.messagelabs.com id 9A/DF-11048-C0094515; Thu, 28 Mar 2013 18:46:36 +0000 X-Env-Sender: christian@holpert.de X-Msg-Ref: server-2.tower-217.messagelabs.com!1364496395!17460507!1 X-Originating-IP: [80.67.18.15] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogODAuNjcuMTguMTUgPT4gNjU5OTk=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27888 invoked from network); 28 Mar 2013 18:46:35 -0000 Received: from smtprelay03.ispgateway.de (HELO smtprelay03.ispgateway.de) (80.67.18.15) by server-2.tower-217.messagelabs.com with SMTP; 28 Mar 2013 18:46:35 -0000 Received: from [217.83.83.71] (helo=colin.holpert.de) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1ULHqN-0003W1-AH for xen-users@lists.xen.org; Thu, 28 Mar 2013 19:46:35 +0100 Received: from PRO43287A006.holpert.de (unknown [10.75.157.20]) by colin.holpert.de (Postfix) with ESMTP id 2E0B97FF3 for ; Thu, 28 Mar 2013 19:46:36 +0100 (CET) X-PGP-Fingerprint: D092 371C 931D 8F21 D71B 7A11 DC07 0F36 [RSA] X-PGP-Fingerprint: 8E3B 2F47 6673 B936 9EAE 52F3 4C8B C713 58C5 FFD6 [DH/DSS] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Mar 2013 19:46:30 +0100 To: xen-users@lists.xen.org From: Christian Holpert In-Reply-To: References: Mime-Version: 1.0 Message-Id: X-Df-Sender: Y2hyaXN0aWFuQGhvbHBlcnQuZGU= Subject: Re: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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 At 18:45 28.03.2013, you wrote: >I am using gentoo linux. > >When I input, /etc/init.d/xend start, system replies >/etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad = >interpreter: Permission denied like Mihai said: please post the output of # head -n 5 /usr/sbin/xend In my gentoo-system this is: xen ~ # head -n 5 /usr/sbin/xend #!/usr/bin/python2.7 # -*- mode: python; -*- #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D # Copyright (C) 2004 Mike Wray # Copyright (C) 2005-2006 XenSource Inc So please also send the output of # ll /usr/bin/python* and # eselect python list # revdep-rebuild might fix the problem. I guess, you changed your python-version recently. Christian -- = Markt-Apotheke Christian Holpert e.K., M=F6mbris http://www.marktapotheke.org - info@marktapotheke.org http://www.blue-essentials-shop.de - info@blue-essentials-shop.de Apotheker Christian Holpert Im Markthof 5 63776 M=F6mbris Tel.: 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, Registernummer 2165 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 18:47:19 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 18: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 1ULHqR-0000qn-88; Thu, 28 Mar 2013 18:46:39 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULHqO-0000qQ-Rh for xen-users@lists.xen.org; Thu, 28 Mar 2013 18:46:37 +0000 Received: from [85.158.137.99:26565] by server-6.bemta-3.messagelabs.com id 9A/DF-11048-C0094515; Thu, 28 Mar 2013 18:46:36 +0000 X-Env-Sender: christian@holpert.de X-Msg-Ref: server-2.tower-217.messagelabs.com!1364496395!17460507!1 X-Originating-IP: [80.67.18.15] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogODAuNjcuMTguMTUgPT4gNjU5OTk=\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27888 invoked from network); 28 Mar 2013 18:46:35 -0000 Received: from smtprelay03.ispgateway.de (HELO smtprelay03.ispgateway.de) (80.67.18.15) by server-2.tower-217.messagelabs.com with SMTP; 28 Mar 2013 18:46:35 -0000 Received: from [217.83.83.71] (helo=colin.holpert.de) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1ULHqN-0003W1-AH for xen-users@lists.xen.org; Thu, 28 Mar 2013 19:46:35 +0100 Received: from PRO43287A006.holpert.de (unknown [10.75.157.20]) by colin.holpert.de (Postfix) with ESMTP id 2E0B97FF3 for ; Thu, 28 Mar 2013 19:46:36 +0100 (CET) X-PGP-Fingerprint: D092 371C 931D 8F21 D71B 7A11 DC07 0F36 [RSA] X-PGP-Fingerprint: 8E3B 2F47 6673 B936 9EAE 52F3 4C8B C713 58C5 FFD6 [DH/DSS] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Mar 2013 19:46:30 +0100 To: xen-users@lists.xen.org From: Christian Holpert In-Reply-To: References: Mime-Version: 1.0 Message-Id: X-Df-Sender: Y2hyaXN0aWFuQGhvbHBlcnQuZGU= Subject: Re: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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 At 18:45 28.03.2013, you wrote: >I am using gentoo linux. > >When I input, /etc/init.d/xend start, system replies >/etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad = >interpreter: Permission denied like Mihai said: please post the output of # head -n 5 /usr/sbin/xend In my gentoo-system this is: xen ~ # head -n 5 /usr/sbin/xend #!/usr/bin/python2.7 # -*- mode: python; -*- #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D # Copyright (C) 2004 Mike Wray # Copyright (C) 2005-2006 XenSource Inc So please also send the output of # ll /usr/bin/python* and # eselect python list # revdep-rebuild might fix the problem. I guess, you changed your python-version recently. Christian -- = Markt-Apotheke Christian Holpert e.K., M=F6mbris http://www.marktapotheke.org - info@marktapotheke.org http://www.blue-essentials-shop.de - info@blue-essentials-shop.de Apotheker Christian Holpert Im Markthof 5 63776 M=F6mbris Tel.: 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, Registernummer 2165 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 20:22:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 20:22: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 1ULJKc-0003sx-7Z; Thu, 28 Mar 2013 20:21:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULJKa-0003ss-ML for xen-users@lists.xen.org; Thu, 28 Mar 2013 20:21:52 +0000 Received: from [85.158.138.51:58912] by server-4.bemta-3.messagelabs.com id 84/B0-21470-F56A4515; Thu, 28 Mar 2013 20:21:51 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1364502109!24507311!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28581 invoked from network); 28 Mar 2013 20:21:51 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2013 20:21:51 -0000 Date: Thu, 28 Mar 2013 20:21:47 +0000 From: Mike To: Alexandre Kouznetsov Message-ID: <20130328202147.GA29041@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> <5153387F.5020106@ondore.com> <20130327201110.GA27122@64-142-29-25.dsl.static.sonic.net> <51536722.6030101@ondore.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51536722.6030101@ondore.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Alexandre Kouznetsov wrote: > When you say "no output from the Xen boot process", do you mean no > output at all? yes > GRUB_TERMINAL="console serial" > GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8" That just hangs at "Welcome to GRUB!". Note the comment before GRUB_TERMINAL in /etc/default/grub, that it only applies to grub-pc. > Some BIOSes have a literal option "fail-safe settings". Some does not, > but using common sense it's possible to disable most of "fancy" and > "exotic" options. I see no such option. I disable devices and boot devices that I don't use, and all of HP's silly security tools. I enable VTx and VTd; disabled, or VTx only, the behavior is the same. > I had no issues related to dm-crypt. OK, good to know. Knowing that, I'm starting to look at this as a bug between Xen and UEFI. This issue looks similar to http://lists.xen.org/archives/html/xen-users/2012-08/msg00120.html _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Mar 28 20:22:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 28 Mar 2013 20:22: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 1ULJKc-0003sx-7Z; Thu, 28 Mar 2013 20:21:54 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULJKa-0003ss-ML for xen-users@lists.xen.org; Thu, 28 Mar 2013 20:21:52 +0000 Received: from [85.158.138.51:58912] by server-4.bemta-3.messagelabs.com id 84/B0-21470-F56A4515; Thu, 28 Mar 2013 20:21:51 +0000 X-Env-Sender: debian@good-with-numbers.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1364502109!24507311!1 X-Originating-IP: [64.142.29.24] X-SpamReason: No, hits=0.0 required=7.0 tests=received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28581 invoked from network); 28 Mar 2013 20:21:51 -0000 Received: from out.good-with-numbers.com (HELO out.good-with-numbers.com) (64.142.29.24) by server-10.tower-174.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2013 20:21:51 -0000 Date: Thu, 28 Mar 2013 20:21:47 +0000 From: Mike To: Alexandre Kouznetsov Message-ID: <20130328202147.GA29041@64-142-29-25.dsl.static.sonic.net> References: <20130323011816.GA16849@64-142-29-25.dsl.static.sonic.net> <1364069689.3919.2.camel@zion.uk.xensource.com> <20130326025117.GA22669@64-142-29-25.dsl.static.sonic.net> <20130327023206.GA25078@64-142-29-25.dsl.static.sonic.net> <20130327124836.GA22389@zion.uk.xensource.com> <20130327162147.GA26500@64-142-29-25.dsl.static.sonic.net> <5153387F.5020106@ondore.com> <20130327201110.GA27122@64-142-29-25.dsl.static.sonic.net> <51536722.6030101@ondore.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51536722.6030101@ondore.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen 4.1.4 fails to boot Linux in wheezy X-BeenThere: xen-users@lists.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 Alexandre Kouznetsov wrote: > When you say "no output from the Xen boot process", do you mean no > output at all? yes > GRUB_TERMINAL="console serial" > GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8" That just hangs at "Welcome to GRUB!". Note the comment before GRUB_TERMINAL in /etc/default/grub, that it only applies to grub-pc. > Some BIOSes have a literal option "fail-safe settings". Some does not, > but using common sense it's possible to disable most of "fancy" and > "exotic" options. I see no such option. I disable devices and boot devices that I don't use, and all of HP's silly security tools. I enable VTx and VTd; disabled, or VTx only, the behavior is the same. > I had no issues related to dm-crypt. OK, good to know. Knowing that, I'm starting to look at this as a bug between Xen and UEFI. This issue looks similar to http://lists.xen.org/archives/html/xen-users/2012-08/msg00120.html _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 29 13:06:39 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 13:06: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 1ULYzg-00060j-Qs; Fri, 29 Mar 2013 13:05:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULYze-00060U-SZ; Fri, 29 Mar 2013 13:05:19 +0000 Received: from [193.109.254.147:63222] by server-4.bemta-14.messagelabs.com id 9A/31-17387-E8195515; Fri, 29 Mar 2013 13:05:18 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1364562305!8659048!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26688 invoked from network); 29 Mar 2013 13:05:07 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Mar 2013 13:05:07 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2TD54V0004186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Mar 2013 13:05:05 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2TD53F6019635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Mar 2013 13:05:03 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2TD52AD009138; Fri, 29 Mar 2013 08:05:02 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Mar 2013 06:05:02 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 822591C3D8A; Fri, 29 Mar 2013 09:05:01 -0400 (EDT) Date: Fri, 29 Mar 2013 09:05:01 -0400 From: Konrad Rzeszutek Wilk To: George Dunlap Message-ID: <20130329130501.GA31497@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 > * What we need to know > > What we're missing in order to make an informed decision is voices > from the community: If we delay the event channel scalability feature > until 4.4, how likely is this to be an issue? Are there current users > or potential users of Xen who need to be able to scale past 200 VMs on > a single host, and who would end up choosing another hypervisor if > this feature were delayed? For this to work you also need the Linux side patches. That means that if you want to hit this in v3.10 merge window you have until April 15th to get it in. The reason is that I am out from April 20th, and the merge window will probably be open on May 1st. We need at least one week to work out any bugs when it goes in #linux-next - hence the April 15th deadline. Technically sounding, the FIFO looks more appealing than the three level events, but that is a subjective opinion. The reality is that what should be really determined is which one will give better performance. From a design perspective it looks as FIFO is the clear winner, but perhaps not - I only briefly looked over the paper? Anyhow, I am leaning towards the FIFO - but I think that if there are existing people who want this functionality _Right now_, then the 3-level event channels would offer a stop-gate option. And they can apply it to their hypervisor + Linux by hand right? > > Thank you for your time and input. > > -George Dunlap, > 4.3 Release manager > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 29 13:06:39 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 13:06: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 1ULYzg-00060j-Qs; Fri, 29 Mar 2013 13:05:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULYze-00060U-SZ; Fri, 29 Mar 2013 13:05:19 +0000 Received: from [193.109.254.147:63222] by server-4.bemta-14.messagelabs.com id 9A/31-17387-E8195515; Fri, 29 Mar 2013 13:05:18 +0000 X-Env-Sender: konrad.wilk@oracle.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1364562305!8659048!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26688 invoked from network); 29 Mar 2013 13:05:07 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Mar 2013 13:05:07 -0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2TD54V0004186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Mar 2013 13:05:05 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2TD53F6019635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Mar 2013 13:05:03 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2TD52AD009138; Fri, 29 Mar 2013 08:05:02 -0500 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Mar 2013 06:05:02 -0700 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 822591C3D8A; Fri, 29 Mar 2013 09:05:01 -0400 (EDT) Date: Fri, 29 Mar 2013 09:05:01 -0400 From: Konrad Rzeszutek Wilk To: George Dunlap Message-ID: <20130329130501.GA31497@phenom.dumpdata.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "xen-users@lists.xen.org" , "xen-devel@lists.xen.org" Subject: Re: [Xen-users] [Xen-devel] Request for input: Extended event channel support X-BeenThere: xen-users@lists.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 > * What we need to know > > What we're missing in order to make an informed decision is voices > from the community: If we delay the event channel scalability feature > until 4.4, how likely is this to be an issue? Are there current users > or potential users of Xen who need to be able to scale past 200 VMs on > a single host, and who would end up choosing another hypervisor if > this feature were delayed? For this to work you also need the Linux side patches. That means that if you want to hit this in v3.10 merge window you have until April 15th to get it in. The reason is that I am out from April 20th, and the merge window will probably be open on May 1st. We need at least one week to work out any bugs when it goes in #linux-next - hence the April 15th deadline. Technically sounding, the FIFO looks more appealing than the three level events, but that is a subjective opinion. The reality is that what should be really determined is which one will give better performance. From a design perspective it looks as FIFO is the clear winner, but perhaps not - I only briefly looked over the paper? Anyhow, I am leaning towards the FIFO - but I think that if there are existing people who want this functionality _Right now_, then the 3-level event channels would offer a stop-gate option. And they can apply it to their hypervisor + Linux by hand right? > > Thank you for your time and input. > > -George Dunlap, > 4.3 Release manager > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 29 13:09:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 13:09: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 1ULZ3F-0006NS-5S; Fri, 29 Mar 2013 13:09:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULYwy-0005zu-4X for xen-users@lists.xen.org; Fri, 29 Mar 2013 13:02:32 +0000 Received: from [193.109.254.147:48618] by server-15.bemta-14.messagelabs.com id CE/B2-14305-7E095515; Fri, 29 Mar 2013 13:02:31 +0000 X-Env-Sender: getfeus@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1364562146!1852914!1 X-Originating-IP: [209.85.160.44] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28874 invoked from network); 29 Mar 2013 13:02:27 -0000 Received: from mail-pb0-f44.google.com (HELO mail-pb0-f44.google.com) (209.85.160.44) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Mar 2013 13:02:27 -0000 Received: by mail-pb0-f44.google.com with SMTP id wz17so252219pbc.31 for ; Fri, 29 Mar 2013 06:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=Thcjaa8vawdcUt0ymoKdftLR9E6TOnChxkO/7vfLsUw=; b=M0QnsGCmstmsd3MNasdLcllQ8m66RdfHYQqQXyGxPOjQ6KqptObZzWj54+PsGpcHEC eTiuFoNimT+OyveQDC73w9KysL7M49Jvj5dJu4UsJ31tJyHX3o30y2D0U9tmJi2aIEYg FBVj7GRZ0TpP9VLIYhl/oKsgPwkBGXWI4fKs/bgoh7AqYnIom/3obAPEYxFTGvgIc4jH 2eQ8SaZHJcg91+J46OXLxoAYjsLi9dCQPSLt5t5sZY4cgOcXMKQwY190xmkKE6wQJY6+ JwP7X/g2s14gQdeX0p8fxuqeUBpMD5tYPM2uBDCeXrLmv07bec7eoRzxF2bfo7kS8vQj fhOA== X-Received: by 10.68.162.129 with SMTP id ya1mr3564596pbb.22.1364562145218; Fri, 29 Mar 2013 06:02:25 -0700 (PDT) Received: from [192.168.0.8] (pb6a9eae0.kngwnt01.ap.so-net.ne.jp. [182.169.234.224]) by mx.google.com with ESMTPS id qh4sm3405512pac.8.2013.03.29.06.02.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Mar 2013 06:02:24 -0700 (PDT) Message-ID: <515590DF.6010704@gmail.com> Date: Fri, 29 Mar 2013 22:02:23 +0900 From: =?EUC-KR?B?190gq+ir86u4q+Wr8w==?= User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <51558FF6.9090703@gmail.com> In-Reply-To: <51558FF6.9090703@gmail.com> X-Mailman-Approved-At: Fri, 29 Mar 2013 13:08:59 +0000 Subject: Re: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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="===============7300809334175434595==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7300809334175434595== Content-Type: multipart/alternative; boundary="------------020601050403080606070202" This is a multi-part message in MIME format. --------------020601050403080606070202 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit > At 18:45 28.03.2013, you wrote: > > I am using gentoo linux. > > When I input, /etc/init.d/xend start, system replies > > /etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad > interpreter: Permission denied > > like Mihai said: please post the output of # head -n 5 /usr/sbin/xend > In my gentoo-system this is: xen ~ # head -n 5 /usr/sbin/xend > #!/usr/bin/python2.7 # -*- mode: python; -*- > #============================================================================ > # Copyright (C) 2004 Mike Wray # Copyright (C) > 2005-2006 XenSource Inc So please also send the output of # ll > /usr/bin/python* and # eselect python list # revdep-rebuild might fix > the problem. I guess, you changed your python-version recently. > Christian -- Markt-Apotheke Christian Holpert e.K., Mo"mbris > http://www.marktapotheke.org - > info@xxxxxxxxxxxxxxxxx http://www.blue-essentials-shop.de > - info@xxxxxxxxxxxxxxxxxxxxxxx > Apotheker Christian Holpert Im Markthof 5 63776 Mo"mbris Tel.: > 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, > Registernummer 2165 Hello. This is my xend scripts contents. This file is built by next command. 1. ./configure 2. make world -j8 3. make install Thank you. #!/usr/lib/portage/pym # -*- mode: python; -*- #============================================================================ # Copyright (C) 2004 Mike Wray # Copyright (C) 2005-2006 XenSource Inc #============================================================================ """Xen management daemon. Provides console server and HTTP management api. Run: xend start Restart: xend restart The daemon is stopped with: xend stop The daemon should reconnect to device control interfaces and recover its state when restarted. On Solaris, the daemons are SMF managed, and you should not attempt to start xend by hand. """ import fcntl import glob import os import os.path import sys import socket import signal import time import commands from xen.xend.server import SrvDaemon class CheckError(ValueError): pass def hline(): print >>sys.stderr, "*" * 70 def msg(message): print >>sys.stderr, "*" * 3, message def check_logging(): """Check python logging is installed and raise an error if not. Logging is standard from Python 2.3 on. """ try: import logging except ImportError: hline() msg("Python logging is not installed.") msg("Use 'make install-logging' at the xen root to install.") msg("") msg("Alternatively download and install from") msg("http://www.red-dove.com/python_logging.html") hline() raise CheckError("logging is not installed") def check_user(): """Check that the effective user id is 0 (root). """ if os.geteuid() != 0: hline() msg("Xend must be run as root.") hline() raise CheckError("invalid user") def start_daemon(daemon, *args): if os.fork() == 0: os.execvp(daemon, (daemon,) + args) def start_blktapctrl(): start_daemon("blktapctrl", "") def main(): try: check_logging() check_user() except CheckError: sys.exit(1) daemon = SrvDaemon.instance() if not sys.argv[1:]: print 'usage: %s {start|stop|reload|restart}' % sys.argv[0] elif sys.argv[1] == 'start': if os.uname()[0] != "SunOS": start_blktapctrl() return daemon.start() elif sys.argv[1] == 'trace_start': start_blktapctrl() return daemon.start(trace=1) elif sys.argv[1] == 'stop': return daemon.stop() elif sys.argv[1] == 'reload': return daemon.reloadConfig() elif sys.argv[1] == 'restart': start_blktapctrl() return daemon.stop() or daemon.start() elif sys.argv[1] == 'status': return daemon.status() else: print 'not an option:', sys.argv[1] return 1 if __name__ == '__main__': sys.exit(main()) --------------020601050403080606070202 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 7bit 
    At 18:45 28.03.2013, you wrote:

    I am using gentoo linux.

When I input, /etc/init.d/xend start, system replies
    /etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied
    like Mihai said: please post the output of # head -n 5 /usr/sbin/xend In my gentoo-system this is: xen ~ # head -n 5 /usr/sbin/xend #!/usr/bin/python2.7 # -*- mode: python; -*- #============================================================================ # Copyright (C) 2004 Mike Wray <mike.wray@xxxxxx> # Copyright (C) 2005-2006 XenSource Inc So please also send the output of # ll /usr/bin/python* and # eselect python list # revdep-rebuild might fix the problem. I guess, you changed your python-version recently. Christian -- Markt-Apotheke Christian Holpert e.K., Mömbris http://www.marktapotheke.org - info@xxxxxxxxxxxxxxxxx http://www.blue-essentials-shop.de - info@xxxxxxxxxxxxxxxxxxxxxxx Apotheker Christian Holpert Im Markthof 5 63776 Mömbris Tel.: 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, Registernummer 2165


    Hello. This is my xend scripts contents.

    This file is built by next command.
    1. ./configure
    2. make world -j8
    3. make install

    Thank you.

    #!/usr/lib/portage/pym
    #  -*- mode: python; -*-
    #============================================================================
    # Copyright (C) 2004 Mike Wray <mike.wray@hp.com>
    # Copyright (C) 2005-2006 XenSource Inc
    #============================================================================

    """Xen management daemon.
       Provides console server and HTTP management api.

       Run:
       xend start

       Restart:
       xend restart

       The daemon is stopped with:
       xend stop

       The daemon should reconnect to device control interfaces
       and recover its state when restarted.

       On Solaris, the daemons are SMF managed, and you should not attempt
       to start xend by hand.
    """
    import fcntl
    import glob
    import os
    import os.path
    import sys
    import socket
    import signal
    import time
    import commands

    from xen.xend.server import SrvDaemon

    class CheckError(ValueError):
        pass

    def hline():
        print >>sys.stderr, "*" * 70

    def msg(message):
        print >>sys.stderr, "*" * 3, message

    def check_logging():
        """Check python logging is installed and raise an error if not.
        Logging is standard from Python 2.3 on.
        """
        try:
            import logging
        except ImportError:
            hline()
            msg("Python logging is not installed.")
            msg("Use 'make install-logging' at the xen root to install.")
            msg("")
            msg("Alternatively download and install from")
            msg("http://www.red-dove.com/python_logging.html")
            hline()
            raise CheckError("logging is not installed")

    def check_user():
        """Check that the effective user id is 0 (root).
        """
        if os.geteuid() != 0:
            hline()
            msg("Xend must be run as root.")
            hline()
            raise CheckError("invalid user")

    def start_daemon(daemon, *args):
        if os.fork() == 0:
            os.execvp(daemon, (daemon,) + args)

    def start_blktapctrl():
        start_daemon("blktapctrl", "")

    def main():
        try:
            check_logging()
            check_user()
        except CheckError:
            sys.exit(1)

        daemon = SrvDaemon.instance()
        if not sys.argv[1:]:
            print 'usage: %s {start|stop|reload|restart}' % sys.argv[0]
        elif sys.argv[1] == 'start':
            if os.uname()[0] != "SunOS":
                start_blktapctrl()
            return daemon.start()
        elif sys.argv[1] == 'trace_start':
            start_blktapctrl()
            return daemon.start(trace=1)
        elif sys.argv[1] == 'stop':
            return daemon.stop()
        elif sys.argv[1] == 'reload':
            return daemon.reloadConfig()
        elif sys.argv[1] == 'restart':
            start_blktapctrl()
            return daemon.stop() or daemon.start()
        elif sys.argv[1] == 'status':
            return daemon.status()
        else:
            print 'not an option:', sys.argv[1]
        return 1

    if __name__ == '__main__':
        sys.exit(main())

    --------------020601050403080606070202-- --===============7300809334175434595== 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 --===============7300809334175434595==-- From xen-users-bounces@lists.xen.org Fri Mar 29 13:09:52 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 13:09: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 1ULZ3F-0006NS-5S; Fri, 29 Mar 2013 13:09:01 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULYwy-0005zu-4X for xen-users@lists.xen.org; Fri, 29 Mar 2013 13:02:32 +0000 Received: from [193.109.254.147:48618] by server-15.bemta-14.messagelabs.com id CE/B2-14305-7E095515; Fri, 29 Mar 2013 13:02:31 +0000 X-Env-Sender: getfeus@gmail.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1364562146!1852914!1 X-Originating-IP: [209.85.160.44] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, HTML_50_60,HTML_MESSAGE,ML_RADAR_SPEW_LINKS_14,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28874 invoked from network); 29 Mar 2013 13:02:27 -0000 Received: from mail-pb0-f44.google.com (HELO mail-pb0-f44.google.com) (209.85.160.44) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Mar 2013 13:02:27 -0000 Received: by mail-pb0-f44.google.com with SMTP id wz17so252219pbc.31 for ; Fri, 29 Mar 2013 06:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=Thcjaa8vawdcUt0ymoKdftLR9E6TOnChxkO/7vfLsUw=; b=M0QnsGCmstmsd3MNasdLcllQ8m66RdfHYQqQXyGxPOjQ6KqptObZzWj54+PsGpcHEC eTiuFoNimT+OyveQDC73w9KysL7M49Jvj5dJu4UsJ31tJyHX3o30y2D0U9tmJi2aIEYg FBVj7GRZ0TpP9VLIYhl/oKsgPwkBGXWI4fKs/bgoh7AqYnIom/3obAPEYxFTGvgIc4jH 2eQ8SaZHJcg91+J46OXLxoAYjsLi9dCQPSLt5t5sZY4cgOcXMKQwY190xmkKE6wQJY6+ JwP7X/g2s14gQdeX0p8fxuqeUBpMD5tYPM2uBDCeXrLmv07bec7eoRzxF2bfo7kS8vQj fhOA== X-Received: by 10.68.162.129 with SMTP id ya1mr3564596pbb.22.1364562145218; Fri, 29 Mar 2013 06:02:25 -0700 (PDT) Received: from [192.168.0.8] (pb6a9eae0.kngwnt01.ap.so-net.ne.jp. [182.169.234.224]) by mx.google.com with ESMTPS id qh4sm3405512pac.8.2013.03.29.06.02.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Mar 2013 06:02:24 -0700 (PDT) Message-ID: <515590DF.6010704@gmail.com> Date: Fri, 29 Mar 2013 22:02:23 +0900 From: =?EUC-KR?B?190gq+ir86u4q+Wr8w==?= User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <51558FF6.9090703@gmail.com> In-Reply-To: <51558FF6.9090703@gmail.com> X-Mailman-Approved-At: Fri, 29 Mar 2013 13:08:59 +0000 Subject: Re: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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="===============7300809334175434595==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --===============7300809334175434595== Content-Type: multipart/alternative; boundary="------------020601050403080606070202" This is a multi-part message in MIME format. --------------020601050403080606070202 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit > At 18:45 28.03.2013, you wrote: > > I am using gentoo linux. > > When I input, /etc/init.d/xend start, system replies > > /etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad > interpreter: Permission denied > > like Mihai said: please post the output of # head -n 5 /usr/sbin/xend > In my gentoo-system this is: xen ~ # head -n 5 /usr/sbin/xend > #!/usr/bin/python2.7 # -*- mode: python; -*- > #============================================================================ > # Copyright (C) 2004 Mike Wray # Copyright (C) > 2005-2006 XenSource Inc So please also send the output of # ll > /usr/bin/python* and # eselect python list # revdep-rebuild might fix > the problem. I guess, you changed your python-version recently. > Christian -- Markt-Apotheke Christian Holpert e.K., Mo"mbris > http://www.marktapotheke.org - > info@xxxxxxxxxxxxxxxxx http://www.blue-essentials-shop.de > - info@xxxxxxxxxxxxxxxxxxxxxxx > Apotheker Christian Holpert Im Markthof 5 63776 Mo"mbris Tel.: > 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, > Registernummer 2165 Hello. This is my xend scripts contents. This file is built by next command. 1. ./configure 2. make world -j8 3. make install Thank you. #!/usr/lib/portage/pym # -*- mode: python; -*- #============================================================================ # Copyright (C) 2004 Mike Wray # Copyright (C) 2005-2006 XenSource Inc #============================================================================ """Xen management daemon. Provides console server and HTTP management api. Run: xend start Restart: xend restart The daemon is stopped with: xend stop The daemon should reconnect to device control interfaces and recover its state when restarted. On Solaris, the daemons are SMF managed, and you should not attempt to start xend by hand. """ import fcntl import glob import os import os.path import sys import socket import signal import time import commands from xen.xend.server import SrvDaemon class CheckError(ValueError): pass def hline(): print >>sys.stderr, "*" * 70 def msg(message): print >>sys.stderr, "*" * 3, message def check_logging(): """Check python logging is installed and raise an error if not. Logging is standard from Python 2.3 on. """ try: import logging except ImportError: hline() msg("Python logging is not installed.") msg("Use 'make install-logging' at the xen root to install.") msg("") msg("Alternatively download and install from") msg("http://www.red-dove.com/python_logging.html") hline() raise CheckError("logging is not installed") def check_user(): """Check that the effective user id is 0 (root). """ if os.geteuid() != 0: hline() msg("Xend must be run as root.") hline() raise CheckError("invalid user") def start_daemon(daemon, *args): if os.fork() == 0: os.execvp(daemon, (daemon,) + args) def start_blktapctrl(): start_daemon("blktapctrl", "") def main(): try: check_logging() check_user() except CheckError: sys.exit(1) daemon = SrvDaemon.instance() if not sys.argv[1:]: print 'usage: %s {start|stop|reload|restart}' % sys.argv[0] elif sys.argv[1] == 'start': if os.uname()[0] != "SunOS": start_blktapctrl() return daemon.start() elif sys.argv[1] == 'trace_start': start_blktapctrl() return daemon.start(trace=1) elif sys.argv[1] == 'stop': return daemon.stop() elif sys.argv[1] == 'reload': return daemon.reloadConfig() elif sys.argv[1] == 'restart': start_blktapctrl() return daemon.stop() or daemon.start() elif sys.argv[1] == 'status': return daemon.status() else: print 'not an option:', sys.argv[1] return 1 if __name__ == '__main__': sys.exit(main()) --------------020601050403080606070202 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 7bit 
    At 18:45 28.03.2013, you wrote:

    I am using gentoo linux.

When I input, /etc/init.d/xend start, system replies
    /etc/init.d/xend: /usr/sbin/xend: /usr/lib/portage/pym: bad interpreter: Permission denied
    like Mihai said: please post the output of # head -n 5 /usr/sbin/xend In my gentoo-system this is: xen ~ # head -n 5 /usr/sbin/xend #!/usr/bin/python2.7 # -*- mode: python; -*- #============================================================================ # Copyright (C) 2004 Mike Wray <mike.wray@xxxxxx> # Copyright (C) 2005-2006 XenSource Inc So please also send the output of # ll /usr/bin/python* and # eselect python list # revdep-rebuild might fix the problem. I guess, you changed your python-version recently. Christian -- Markt-Apotheke Christian Holpert e.K., Mömbris http://www.marktapotheke.org - info@xxxxxxxxxxxxxxxxx http://www.blue-essentials-shop.de - info@xxxxxxxxxxxxxxxxxxxxxxx Apotheker Christian Holpert Im Markthof 5 63776 Mömbris Tel.: 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, Registernummer 2165


    Hello. This is my xend scripts contents.

    This file is built by next command.
    1. ./configure
    2. make world -j8
    3. make install

    Thank you.

    #!/usr/lib/portage/pym
    #  -*- mode: python; -*-
    #============================================================================
    # Copyright (C) 2004 Mike Wray <mike.wray@hp.com>
    # Copyright (C) 2005-2006 XenSource Inc
    #============================================================================

    """Xen management daemon.
       Provides console server and HTTP management api.

       Run:
       xend start

       Restart:
       xend restart

       The daemon is stopped with:
       xend stop

       The daemon should reconnect to device control interfaces
       and recover its state when restarted.

       On Solaris, the daemons are SMF managed, and you should not attempt
       to start xend by hand.
    """
    import fcntl
    import glob
    import os
    import os.path
    import sys
    import socket
    import signal
    import time
    import commands

    from xen.xend.server import SrvDaemon

    class CheckError(ValueError):
        pass

    def hline():
        print >>sys.stderr, "*" * 70

    def msg(message):
        print >>sys.stderr, "*" * 3, message

    def check_logging():
        """Check python logging is installed and raise an error if not.
        Logging is standard from Python 2.3 on.
        """
        try:
            import logging
        except ImportError:
            hline()
            msg("Python logging is not installed.")
            msg("Use 'make install-logging' at the xen root to install.")
            msg("")
            msg("Alternatively download and install from")
            msg("http://www.red-dove.com/python_logging.html")
            hline()
            raise CheckError("logging is not installed")

    def check_user():
        """Check that the effective user id is 0 (root).
        """
        if os.geteuid() != 0:
            hline()
            msg("Xend must be run as root.")
            hline()
            raise CheckError("invalid user")

    def start_daemon(daemon, *args):
        if os.fork() == 0:
            os.execvp(daemon, (daemon,) + args)

    def start_blktapctrl():
        start_daemon("blktapctrl", "")

    def main():
        try:
            check_logging()
            check_user()
        except CheckError:
            sys.exit(1)

        daemon = SrvDaemon.instance()
        if not sys.argv[1:]:
            print 'usage: %s {start|stop|reload|restart}' % sys.argv[0]
        elif sys.argv[1] == 'start':
            if os.uname()[0] != "SunOS":
                start_blktapctrl()
            return daemon.start()
        elif sys.argv[1] == 'trace_start':
            start_blktapctrl()
            return daemon.start(trace=1)
        elif sys.argv[1] == 'stop':
            return daemon.stop()
        elif sys.argv[1] == 'reload':
            return daemon.reloadConfig()
        elif sys.argv[1] == 'restart':
            start_blktapctrl()
            return daemon.stop() or daemon.start()
        elif sys.argv[1] == 'status':
            return daemon.status()
        else:
            print 'not an option:', sys.argv[1]
        return 1

    if __name__ == '__main__':
        sys.exit(main())

    --------------020601050403080606070202-- --===============7300809334175434595== 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 --===============7300809334175434595==-- From xen-users-bounces@lists.xen.org Fri Mar 29 14:31:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 14:31: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 1ULaJv-0000k1-Oj; Fri, 29 Mar 2013 14:30:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULaJu-0000jw-Rx for xen-users@lists.xen.org; Fri, 29 Mar 2013 14:30:19 +0000 Received: from [85.158.139.211:53476] by server-13.bemta-5.messagelabs.com id 93/A1-20553-A75A5515; Fri, 29 Mar 2013 14:30:18 +0000 X-Env-Sender: knockknock@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1364567411!19010153!1 X-Originating-IP: [209.85.220.175] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19903 invoked from network); 29 Mar 2013 14:30:13 -0000 Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Mar 2013 14:30:13 -0000 Received: by mail-vc0-f175.google.com with SMTP id hf12so542324vcb.34 for ; Fri, 29 Mar 2013 07:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=vueMbbBSX7so/B/v71ToI1Sq9CiRLTxtOm0LSAoEY2w=; b=J4HgacgvYkkWCxwD+AyEkzw5NCloU0tes9D/8tXS63CdcXHgnE3MdyqKkvQzCkDjIs GfwdyRnRNwU0DLpTOFxO3qqSIBnWF0hWzCQLXAnOBymLze/DvrlZLHvTTkGJm9CkkP4j G1beJh2UlUpTwVNpocr255ZvbHx602XmcY3X0iA4POULqTk4GPXR61CtoHtU2/yA6pp4 pI9nLL1z3KfnDvVRBwmMoPn2LhOXrsoQzX/jhSqueFXzN4muPROrx2EyiIehQ5QjJJFR X+R9b1FdBqOvgu1sz5ZiO6p9STw+m9CP9THRyzgU1NYwYEfqlDCGSUMk2ktl7EE36exT cd+g== X-Received: by 10.52.156.41 with SMTP id wb9mr1659371vdb.65.1364567410878; Fri, 29 Mar 2013 07:30:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.122.197 with HTTP; Fri, 29 Mar 2013 07:29:46 -0700 (PDT) From: Eric Shelton Date: Fri, 29 Mar 2013 10:29:46 -0400 X-Google-Sender-Auth: ubS3_mErtA32vE74NnuWkEj-1iI Message-ID: To: "xen-users@lists.xen.org" Subject: [Xen-users] Disbale IGD IOMMU to allow DMA Pass Through on other IOMMU? X-BeenThere: xen-users@lists.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 While looking into the degree of Vt-d support provided by my CPU (i5-3317U w/ Ivy Bridge), I noticed that the two IOMMUs, one for the IGD and the other for the remaining devices, do not have the same capabilities. Xen reports an ecap value of 0xf0101a for the first and 0xf0105a for the second. The 0x000040 bit for the second IOMMU support for DMA Pass Through. The CPU datasheet also says the Snoop Control bit, 0x000080, is on after a reset, but it is disabled by the time Xen is booting on my MacBook Air. The CPU datasheet lists this bit as "RO-V" (read-only volatile), but I do not know what volatilizes it. It appears the Xen developers have expressly opted for a least common denominator approach for IOMMU capabilities, where if a feature not not supported by ALL of the IOMMUs, it is not available for any of the IOMMUs. See intel_vtd_setup() in vtd/iommu.c, for example. However, it also appears that there were enough buggy Sandy Bridge implementations that there is code in quirks.c directed to disabling the IGD IOMMU while making use of the other one. Assumedly the Intel HD 3000 and 4000 architectures are similar enough that one could similarly disable the IGD IOMMU for Ivy Bridge. I have a two questions in connection with this: 1) Assuming only dom0 is using the IGD (which means it is not being passed through to a domU), and the IGD IOMMU is left unused, does this degrade the isolation between the domU's and dom0 and/or the IGD? Does it matter if the domU is PV? 2) Does Pass Through provide a tangible improvement in performance (e.g., is it worth trying to do this)? Thank you, Eric _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 29 14:31:22 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 14:31: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 1ULaJv-0000k1-Oj; Fri, 29 Mar 2013 14:30:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULaJu-0000jw-Rx for xen-users@lists.xen.org; Fri, 29 Mar 2013 14:30:19 +0000 Received: from [85.158.139.211:53476] by server-13.bemta-5.messagelabs.com id 93/A1-20553-A75A5515; Fri, 29 Mar 2013 14:30:18 +0000 X-Env-Sender: knockknock@gmail.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1364567411!19010153!1 X-Originating-IP: [209.85.220.175] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19903 invoked from network); 29 Mar 2013 14:30:13 -0000 Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Mar 2013 14:30:13 -0000 Received: by mail-vc0-f175.google.com with SMTP id hf12so542324vcb.34 for ; Fri, 29 Mar 2013 07:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=vueMbbBSX7so/B/v71ToI1Sq9CiRLTxtOm0LSAoEY2w=; b=J4HgacgvYkkWCxwD+AyEkzw5NCloU0tes9D/8tXS63CdcXHgnE3MdyqKkvQzCkDjIs GfwdyRnRNwU0DLpTOFxO3qqSIBnWF0hWzCQLXAnOBymLze/DvrlZLHvTTkGJm9CkkP4j G1beJh2UlUpTwVNpocr255ZvbHx602XmcY3X0iA4POULqTk4GPXR61CtoHtU2/yA6pp4 pI9nLL1z3KfnDvVRBwmMoPn2LhOXrsoQzX/jhSqueFXzN4muPROrx2EyiIehQ5QjJJFR X+R9b1FdBqOvgu1sz5ZiO6p9STw+m9CP9THRyzgU1NYwYEfqlDCGSUMk2ktl7EE36exT cd+g== X-Received: by 10.52.156.41 with SMTP id wb9mr1659371vdb.65.1364567410878; Fri, 29 Mar 2013 07:30:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.122.197 with HTTP; Fri, 29 Mar 2013 07:29:46 -0700 (PDT) From: Eric Shelton Date: Fri, 29 Mar 2013 10:29:46 -0400 X-Google-Sender-Auth: ubS3_mErtA32vE74NnuWkEj-1iI Message-ID: To: "xen-users@lists.xen.org" Subject: [Xen-users] Disbale IGD IOMMU to allow DMA Pass Through on other IOMMU? X-BeenThere: xen-users@lists.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 While looking into the degree of Vt-d support provided by my CPU (i5-3317U w/ Ivy Bridge), I noticed that the two IOMMUs, one for the IGD and the other for the remaining devices, do not have the same capabilities. Xen reports an ecap value of 0xf0101a for the first and 0xf0105a for the second. The 0x000040 bit for the second IOMMU support for DMA Pass Through. The CPU datasheet also says the Snoop Control bit, 0x000080, is on after a reset, but it is disabled by the time Xen is booting on my MacBook Air. The CPU datasheet lists this bit as "RO-V" (read-only volatile), but I do not know what volatilizes it. It appears the Xen developers have expressly opted for a least common denominator approach for IOMMU capabilities, where if a feature not not supported by ALL of the IOMMUs, it is not available for any of the IOMMUs. See intel_vtd_setup() in vtd/iommu.c, for example. However, it also appears that there were enough buggy Sandy Bridge implementations that there is code in quirks.c directed to disabling the IGD IOMMU while making use of the other one. Assumedly the Intel HD 3000 and 4000 architectures are similar enough that one could similarly disable the IGD IOMMU for Ivy Bridge. I have a two questions in connection with this: 1) Assuming only dom0 is using the IGD (which means it is not being passed through to a domU), and the IGD IOMMU is left unused, does this degrade the isolation between the domU's and dom0 and/or the IGD? Does it matter if the domU is PV? 2) Does Pass Through provide a tangible improvement in performance (e.g., is it worth trying to do this)? Thank you, Eric _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Mar 29 15:03:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 15:03: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 1ULap9-0001sV-5M; Fri, 29 Mar 2013 15:02:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULap8-0001sQ-7z for xen-users@lists.xen.org; Fri, 29 Mar 2013 15:02:34 +0000 Received: from [85.158.139.211:44184] by server-2.bemta-5.messagelabs.com id 8C/41-23989-90DA5515; Fri, 29 Mar 2013 15:02:33 +0000 X-Env-Sender: klaus.mailinglists@pernau.at X-Msg-Ref: server-10.tower-206.messagelabs.com!1364569352!18339172!1 X-Originating-IP: [88.198.53.113] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24813 invoked from network); 29 Mar 2013 15:02:32 -0000 Received: from ds3000.pernau.at (HELO ds3000.pernau.at) (88.198.53.113) by server-10.tower-206.messagelabs.com with SMTP; 29 Mar 2013 15:02:32 -0000 Received: from [10.10.0.51] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTPSA id F17A71080002 for ; Fri, 29 Mar 2013 16:02:31 +0100 (CET) Message-ID: <5155AD06.5010802@pernau.at> Date: Fri, 29 Mar 2013 16:02:30 +0100 From: Klaus Darilion User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org Content-Type: multipart/mixed; boundary="------------010300040103020104090804" Subject: [Xen-users] Yet another networking script for Openvswitch and VLAN support X-BeenThere: xen-users@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. --------------010300040103020104090804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi! I had some hard times to get XEN 4.1 (Debian) working with Openvswitch (1.4.2). If found some references in the Internet, but none of them worked for me - so I hacked them myself, using the idea the of http://lists.xen.org/archives/html/xen-users/2011-08/msg00071.html. So, please find attached the network scripts. xen-network-common.sh: Originally I wanted to write a new script and configure in xend-config.sxp the new "vif-script". But this does nto work, as xen sometimes also calls the default vif-script, which of course fails (maybe because I use HVM). Thus I changed the default vif-script. qemu-ifup: This is necessary if you use HVM The scripts are capable of VLANs, this means, OVS is configured with the proper VLAN when adding an interface to the bridge. This is done by adding .vlantag to the bridge interface name, e.g.: vif = [ 'model=e1000,mac=00:16:3E:AA:BB:00,bridge=br0.627' ] This will add the interface to br0 with VLAN 627. Note: My scripts will not try to fix the network setup when it is broken. Thus, the basic network setup has to be done outside of XEN with OS means. regards Klaus --------------010300040103020104090804 Content-Type: text/plain; charset=windows-1252; name="qemu-ifup" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="qemu-ifup" #!/bin/bash echo -c 'config qemu network with xen bridge for ' echo $* logger -- "$0 $*" # Initialise a dummy MAC address. We choose the numerically # largest non-broadcast address to prevent the address getting # stolen by an Ethernet bridge for STP purposes. # (FE:FF:FF:FF:FF:FF) ip link set $1 address fe:ff:ff:ff:ff:ff || true ifconfig $1 0.0.0.0 up # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. (following code works only in BASH) vif=$1 bridge=$2 if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi if [ -z $tag ]; then ovs-vsctl -- --may-exist add-port ${bridge} ${vif} else ovs-vsctl -- --may-exist add-port ${bridge} ${vif} tag=${tag} fi --------------010300040103020104090804 Content-Type: text/plain; charset=windows-1252; name="xen-network-common.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen-network-common.sh" # # Copyright (c) 2005 XenSource Ltd. # # This library is free software; you can redistribute it and/or # modify it under the terms of version 2.1 of the GNU Lesser General Public # License as published by the Free Software Foundation. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # # Gentoo doesn't have ifup/ifdown, so we define appropriate alternatives. # Other platforms just use ifup / ifdown directly. ## # preiftransfer # # @param $1 The current name for the physical device, which is also the name # that the virtual device will take once the physical device has # been renamed. if ! which ifup >/dev/null 2>/dev/null then preiftransfer() { true } ifup() { false } ifdown() { false } else preiftransfer() { true } fi first_file() { t="$1" shift for file in $@ do if [ "$t" "$file" ] then echo "$file" return fi done } find_dhcpd_conf_file() { first_file -f /etc/dhcp3/dhcpd.conf /etc/dhcpd.conf } find_dhcpd_init_file() { first_file -x /etc/init.d/{dhcp3-server,dhcp,dhcpd} } find_dhcpd_arg_file() { first_file -f /etc/sysconfig/dhcpd /etc/defaults/dhcp /etc/default/dhcp3-server } # configure interfaces which act as pure bridge ports: _setup_bridge_port() { local dev="$1" local virtual="$2" # take interface down ... ip link set ${dev} down if [ $virtual -ne 0 ] ; then # Initialise a dummy MAC address. We choose the numerically # largest non-broadcast address to prevent the address getting # stolen by an Ethernet bridge for STP purposes. # (FE:FF:FF:FF:FF:FF) ip link set ${dev} address fe:ff:ff:ff:ff:ff || true fi # ... and configure it ip addr flush ${dev} } setup_physical_bridge_port() { _setup_bridge_port $1 0 } setup_virtual_bridge_port() { _setup_bridge_port $1 1 } # Usage: create_bridge bridge create_bridge () { local bridge=$1 ovs-vsctl -- --may-exists add-br ${bridge} } # Usage: add_to_bridge bridge dev add_to_bridge () { local bridge=$1 local dev=$2 # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi if [ -z $tag ]; then ovs-vsctl -- --may-exist add-port ${bridge} ${dev} else ovs-vsctl -- --may-exist add-port ${bridge} ${dev} tag=${tag} fi ip link set ${dev} up } # Usage: delete_from_bridge bridge dev delete_from_bridge () { local bridge=$1 local dev=$2 # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi ovs-vsctl -- --if-exists del-port ${bridge} ${dev} } --------------010300040103020104090804 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 --------------010300040103020104090804-- From xen-users-bounces@lists.xen.org Fri Mar 29 15:03:36 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 15:03: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 1ULap9-0001sV-5M; Fri, 29 Mar 2013 15:02:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULap8-0001sQ-7z for xen-users@lists.xen.org; Fri, 29 Mar 2013 15:02:34 +0000 Received: from [85.158.139.211:44184] by server-2.bemta-5.messagelabs.com id 8C/41-23989-90DA5515; Fri, 29 Mar 2013 15:02:33 +0000 X-Env-Sender: klaus.mailinglists@pernau.at X-Msg-Ref: server-10.tower-206.messagelabs.com!1364569352!18339172!1 X-Originating-IP: [88.198.53.113] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24813 invoked from network); 29 Mar 2013 15:02:32 -0000 Received: from ds3000.pernau.at (HELO ds3000.pernau.at) (88.198.53.113) by server-10.tower-206.messagelabs.com with SMTP; 29 Mar 2013 15:02:32 -0000 Received: from [10.10.0.51] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTPSA id F17A71080002 for ; Fri, 29 Mar 2013 16:02:31 +0100 (CET) Message-ID: <5155AD06.5010802@pernau.at> Date: Fri, 29 Mar 2013 16:02:30 +0100 From: Klaus Darilion User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org Content-Type: multipart/mixed; boundary="------------010300040103020104090804" Subject: [Xen-users] Yet another networking script for Openvswitch and VLAN support X-BeenThere: xen-users@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. --------------010300040103020104090804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi! I had some hard times to get XEN 4.1 (Debian) working with Openvswitch (1.4.2). If found some references in the Internet, but none of them worked for me - so I hacked them myself, using the idea the of http://lists.xen.org/archives/html/xen-users/2011-08/msg00071.html. So, please find attached the network scripts. xen-network-common.sh: Originally I wanted to write a new script and configure in xend-config.sxp the new "vif-script". But this does nto work, as xen sometimes also calls the default vif-script, which of course fails (maybe because I use HVM). Thus I changed the default vif-script. qemu-ifup: This is necessary if you use HVM The scripts are capable of VLANs, this means, OVS is configured with the proper VLAN when adding an interface to the bridge. This is done by adding .vlantag to the bridge interface name, e.g.: vif = [ 'model=e1000,mac=00:16:3E:AA:BB:00,bridge=br0.627' ] This will add the interface to br0 with VLAN 627. Note: My scripts will not try to fix the network setup when it is broken. Thus, the basic network setup has to be done outside of XEN with OS means. regards Klaus --------------010300040103020104090804 Content-Type: text/plain; charset=windows-1252; name="qemu-ifup" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="qemu-ifup" #!/bin/bash echo -c 'config qemu network with xen bridge for ' echo $* logger -- "$0 $*" # Initialise a dummy MAC address. We choose the numerically # largest non-broadcast address to prevent the address getting # stolen by an Ethernet bridge for STP purposes. # (FE:FF:FF:FF:FF:FF) ip link set $1 address fe:ff:ff:ff:ff:ff || true ifconfig $1 0.0.0.0 up # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. (following code works only in BASH) vif=$1 bridge=$2 if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi if [ -z $tag ]; then ovs-vsctl -- --may-exist add-port ${bridge} ${vif} else ovs-vsctl -- --may-exist add-port ${bridge} ${vif} tag=${tag} fi --------------010300040103020104090804 Content-Type: text/plain; charset=windows-1252; name="xen-network-common.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen-network-common.sh" # # Copyright (c) 2005 XenSource Ltd. # # This library is free software; you can redistribute it and/or # modify it under the terms of version 2.1 of the GNU Lesser General Public # License as published by the Free Software Foundation. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # # Gentoo doesn't have ifup/ifdown, so we define appropriate alternatives. # Other platforms just use ifup / ifdown directly. ## # preiftransfer # # @param $1 The current name for the physical device, which is also the name # that the virtual device will take once the physical device has # been renamed. if ! which ifup >/dev/null 2>/dev/null then preiftransfer() { true } ifup() { false } ifdown() { false } else preiftransfer() { true } fi first_file() { t="$1" shift for file in $@ do if [ "$t" "$file" ] then echo "$file" return fi done } find_dhcpd_conf_file() { first_file -f /etc/dhcp3/dhcpd.conf /etc/dhcpd.conf } find_dhcpd_init_file() { first_file -x /etc/init.d/{dhcp3-server,dhcp,dhcpd} } find_dhcpd_arg_file() { first_file -f /etc/sysconfig/dhcpd /etc/defaults/dhcp /etc/default/dhcp3-server } # configure interfaces which act as pure bridge ports: _setup_bridge_port() { local dev="$1" local virtual="$2" # take interface down ... ip link set ${dev} down if [ $virtual -ne 0 ] ; then # Initialise a dummy MAC address. We choose the numerically # largest non-broadcast address to prevent the address getting # stolen by an Ethernet bridge for STP purposes. # (FE:FF:FF:FF:FF:FF) ip link set ${dev} address fe:ff:ff:ff:ff:ff || true fi # ... and configure it ip addr flush ${dev} } setup_physical_bridge_port() { _setup_bridge_port $1 0 } setup_virtual_bridge_port() { _setup_bridge_port $1 1 } # Usage: create_bridge bridge create_bridge () { local bridge=$1 ovs-vsctl -- --may-exists add-br ${bridge} } # Usage: add_to_bridge bridge dev add_to_bridge () { local bridge=$1 local dev=$2 # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi if [ -z $tag ]; then ovs-vsctl -- --may-exist add-port ${bridge} ${dev} else ovs-vsctl -- --may-exist add-port ${bridge} ${dev} tag=${tag} fi ip link set ${dev} up } # Usage: delete_from_bridge bridge dev delete_from_bridge () { local bridge=$1 local dev=$2 # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi ovs-vsctl -- --if-exists del-port ${bridge} ${dev} } --------------010300040103020104090804 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 --------------010300040103020104090804-- From xen-users-bounces@lists.xen.org Fri Mar 29 15:42:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 15:42: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 1ULbR3-0002st-Nz; Fri, 29 Mar 2013 15:41:45 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULbR2-0002sm-71 for xen-users@lists.xen.org; Fri, 29 Mar 2013 15:41:44 +0000 Received: from [193.109.254.147:39574] by server-9.bemta-14.messagelabs.com id 90/0F-04223-736B5515; Fri, 29 Mar 2013 15:41:43 +0000 X-Env-Sender: klaus.mailinglists@pernau.at X-Msg-Ref: server-11.tower-27.messagelabs.com!1364571702!2256703!1 X-Originating-IP: [88.198.53.113] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10993 invoked from network); 29 Mar 2013 15:41:42 -0000 Received: from ds3000.pernau.at (HELO ds3000.pernau.at) (88.198.53.113) by server-11.tower-27.messagelabs.com with SMTP; 29 Mar 2013 15:41:42 -0000 Received: from [10.10.0.51] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTPSA id 796701080002 for ; Fri, 29 Mar 2013 16:41:41 +0100 (CET) Message-ID: <5155B635.4060804@pernau.at> Date: Fri, 29 Mar 2013 16:41:41 +0100 From: Klaus Darilion User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5155AD06.5010802@pernau.at> In-Reply-To: <5155AD06.5010802@pernau.at> Content-Type: multipart/mixed; boundary="------------070201050502050607030208" Subject: Re: [Xen-users] Yet another networking script for Openvswitch and VLAN support X-BeenThere: xen-users@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. --------------070201050502050607030208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ups. There was a typo in xen-network-common.sh. Please use these scripts. regards Klaus On 29.03.2013 16:02, Klaus Darilion wrote: > Hi! > > I had some hard times to get XEN 4.1 (Debian) working with Openvswitch > (1.4.2). If found some references in the Internet, but none of them > worked for me - so I hacked them myself, using the idea the of > http://lists.xen.org/archives/html/xen-users/2011-08/msg00071.html. > > So, please find attached the network scripts. > > xen-network-common.sh: Originally I wanted to write a new script and > configure in xend-config.sxp the new "vif-script". But this does nto > work, as xen sometimes also calls the default vif-script, which of > course fails (maybe because I use HVM). Thus I changed the default > vif-script. > > qemu-ifup: This is necessary if you use HVM > > The scripts are capable of VLANs, this means, OVS is configured with the > proper VLAN when adding an interface to the bridge. This is done by > adding .vlantag to the bridge interface name, e.g.: > > vif = [ 'model=e1000,mac=00:16:3E:AA:BB:00,bridge=br0.627' ] > > This will add the interface to br0 with VLAN 627. > > Note: My scripts will not try to fix the network setup when it is > broken. Thus, the basic network setup has to be done outside of XEN with > OS means. > > regards > Klaus > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --------------070201050502050607030208 Content-Type: text/plain; charset=windows-1252; name="xen-network-common.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen-network-common.sh" # # Copyright (c) 2005 XenSource Ltd. # # This library is free software; you can redistribute it and/or # modify it under the terms of version 2.1 of the GNU Lesser General Public # License as published by the Free Software Foundation. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # # Gentoo doesn't have ifup/ifdown, so we define appropriate alternatives. # Other platforms just use ifup / ifdown directly. ## # preiftransfer # # @param $1 The current name for the physical device, which is also the name # that the virtual device will take once the physical device has # been renamed. if ! which ifup >/dev/null 2>/dev/null then preiftransfer() { true } ifup() { false } ifdown() { false } else preiftransfer() { true } fi first_file() { t="$1" shift for file in $@ do if [ "$t" "$file" ] then echo "$file" return fi done } find_dhcpd_conf_file() { first_file -f /etc/dhcp3/dhcpd.conf /etc/dhcpd.conf } find_dhcpd_init_file() { first_file -x /etc/init.d/{dhcp3-server,dhcp,dhcpd} } find_dhcpd_arg_file() { first_file -f /etc/sysconfig/dhcpd /etc/defaults/dhcp /etc/default/dhcp3-server } # configure interfaces which act as pure bridge ports: _setup_bridge_port() { local dev="$1" local virtual="$2" # take interface down ... ip link set ${dev} down if [ $virtual -ne 0 ] ; then # Initialise a dummy MAC address. We choose the numerically # largest non-broadcast address to prevent the address getting # stolen by an Ethernet bridge for STP purposes. # (FE:FF:FF:FF:FF:FF) ip link set ${dev} address fe:ff:ff:ff:ff:ff || true fi # ... and configure it ip addr flush ${dev} } setup_physical_bridge_port() { _setup_bridge_port $1 0 } setup_virtual_bridge_port() { _setup_bridge_port $1 1 } # Usage: create_bridge bridge create_bridge () { local bridge=$1 ovs-vsctl -- --may-exist add-br ${bridge} } # Usage: add_to_bridge bridge dev add_to_bridge () { local bridge=$1 local dev=$2 # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi if [ -z $tag ]; then ovs-vsctl -- --may-exist add-port ${bridge} ${dev} else ovs-vsctl -- --may-exist add-port ${bridge} ${dev} tag=${tag} fi ip link set ${dev} up } # Usage: delete_from_bridge bridge dev delete_from_bridge () { local bridge=$1 local dev=$2 # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi ovs-vsctl -- --if-exists del-port ${bridge} ${dev} } --------------070201050502050607030208 Content-Type: text/plain; charset=windows-1252; name="qemu-ifup" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="qemu-ifup" #!/bin/bash echo -c 'config qemu network with xen bridge for ' echo $* logger -- "$0 $*" # Initialise a dummy MAC address. We choose the numerically # largest non-broadcast address to prevent the address getting # stolen by an Ethernet bridge for STP purposes. # (FE:FF:FF:FF:FF:FF) ip link set $1 address fe:ff:ff:ff:ff:ff || true ifconfig $1 0.0.0.0 up # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. (following code works only in BASH) vif=$1 bridge=$2 if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi if [ -z $tag ]; then ovs-vsctl -- --may-exist add-port ${bridge} ${vif} else ovs-vsctl -- --may-exist add-port ${bridge} ${vif} tag=${tag} fi --------------070201050502050607030208 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 --------------070201050502050607030208-- From xen-users-bounces@lists.xen.org Fri Mar 29 15:42:48 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 15:42: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 1ULbR3-0002st-Nz; Fri, 29 Mar 2013 15:41:45 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULbR2-0002sm-71 for xen-users@lists.xen.org; Fri, 29 Mar 2013 15:41:44 +0000 Received: from [193.109.254.147:39574] by server-9.bemta-14.messagelabs.com id 90/0F-04223-736B5515; Fri, 29 Mar 2013 15:41:43 +0000 X-Env-Sender: klaus.mailinglists@pernau.at X-Msg-Ref: server-11.tower-27.messagelabs.com!1364571702!2256703!1 X-Originating-IP: [88.198.53.113] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10993 invoked from network); 29 Mar 2013 15:41:42 -0000 Received: from ds3000.pernau.at (HELO ds3000.pernau.at) (88.198.53.113) by server-11.tower-27.messagelabs.com with SMTP; 29 Mar 2013 15:41:42 -0000 Received: from [10.10.0.51] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTPSA id 796701080002 for ; Fri, 29 Mar 2013 16:41:41 +0100 (CET) Message-ID: <5155B635.4060804@pernau.at> Date: Fri, 29 Mar 2013 16:41:41 +0100 From: Klaus Darilion User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5155AD06.5010802@pernau.at> In-Reply-To: <5155AD06.5010802@pernau.at> Content-Type: multipart/mixed; boundary="------------070201050502050607030208" Subject: Re: [Xen-users] Yet another networking script for Openvswitch and VLAN support X-BeenThere: xen-users@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. --------------070201050502050607030208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ups. There was a typo in xen-network-common.sh. Please use these scripts. regards Klaus On 29.03.2013 16:02, Klaus Darilion wrote: > Hi! > > I had some hard times to get XEN 4.1 (Debian) working with Openvswitch > (1.4.2). If found some references in the Internet, but none of them > worked for me - so I hacked them myself, using the idea the of > http://lists.xen.org/archives/html/xen-users/2011-08/msg00071.html. > > So, please find attached the network scripts. > > xen-network-common.sh: Originally I wanted to write a new script and > configure in xend-config.sxp the new "vif-script". But this does nto > work, as xen sometimes also calls the default vif-script, which of > course fails (maybe because I use HVM). Thus I changed the default > vif-script. > > qemu-ifup: This is necessary if you use HVM > > The scripts are capable of VLANs, this means, OVS is configured with the > proper VLAN when adding an interface to the bridge. This is done by > adding .vlantag to the bridge interface name, e.g.: > > vif = [ 'model=e1000,mac=00:16:3E:AA:BB:00,bridge=br0.627' ] > > This will add the interface to br0 with VLAN 627. > > Note: My scripts will not try to fix the network setup when it is > broken. Thus, the basic network setup has to be done outside of XEN with > OS means. > > regards > Klaus > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > --------------070201050502050607030208 Content-Type: text/plain; charset=windows-1252; name="xen-network-common.sh" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xen-network-common.sh" # # Copyright (c) 2005 XenSource Ltd. # # This library is free software; you can redistribute it and/or # modify it under the terms of version 2.1 of the GNU Lesser General Public # License as published by the Free Software Foundation. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # # Gentoo doesn't have ifup/ifdown, so we define appropriate alternatives. # Other platforms just use ifup / ifdown directly. ## # preiftransfer # # @param $1 The current name for the physical device, which is also the name # that the virtual device will take once the physical device has # been renamed. if ! which ifup >/dev/null 2>/dev/null then preiftransfer() { true } ifup() { false } ifdown() { false } else preiftransfer() { true } fi first_file() { t="$1" shift for file in $@ do if [ "$t" "$file" ] then echo "$file" return fi done } find_dhcpd_conf_file() { first_file -f /etc/dhcp3/dhcpd.conf /etc/dhcpd.conf } find_dhcpd_init_file() { first_file -x /etc/init.d/{dhcp3-server,dhcp,dhcpd} } find_dhcpd_arg_file() { first_file -f /etc/sysconfig/dhcpd /etc/defaults/dhcp /etc/default/dhcp3-server } # configure interfaces which act as pure bridge ports: _setup_bridge_port() { local dev="$1" local virtual="$2" # take interface down ... ip link set ${dev} down if [ $virtual -ne 0 ] ; then # Initialise a dummy MAC address. We choose the numerically # largest non-broadcast address to prevent the address getting # stolen by an Ethernet bridge for STP purposes. # (FE:FF:FF:FF:FF:FF) ip link set ${dev} address fe:ff:ff:ff:ff:ff || true fi # ... and configure it ip addr flush ${dev} } setup_physical_bridge_port() { _setup_bridge_port $1 0 } setup_virtual_bridge_port() { _setup_bridge_port $1 1 } # Usage: create_bridge bridge create_bridge () { local bridge=$1 ovs-vsctl -- --may-exist add-br ${bridge} } # Usage: add_to_bridge bridge dev add_to_bridge () { local bridge=$1 local dev=$2 # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi if [ -z $tag ]; then ovs-vsctl -- --may-exist add-port ${bridge} ${dev} else ovs-vsctl -- --may-exist add-port ${bridge} ${dev} tag=${tag} fi ip link set ${dev} up } # Usage: delete_from_bridge bridge dev delete_from_bridge () { local bridge=$1 local dev=$2 # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi ovs-vsctl -- --if-exists del-port ${bridge} ${dev} } --------------070201050502050607030208 Content-Type: text/plain; charset=windows-1252; name="qemu-ifup" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="qemu-ifup" #!/bin/bash echo -c 'config qemu network with xen bridge for ' echo $* logger -- "$0 $*" # Initialise a dummy MAC address. We choose the numerically # largest non-broadcast address to prevent the address getting # stolen by an Ethernet bridge for STP purposes. # (FE:FF:FF:FF:FF:FF) ip link set $1 address fe:ff:ff:ff:ff:ff || true ifconfig $1 0.0.0.0 up # If the bridge is in format brX.Y, strip Y from the bridge # and use it as VLAN tag. (following code works only in BASH) vif=$1 bridge=$2 if [[ $bridge =~ \.[[:digit:]]{1,4}$ ]]; then tag=$(echo ${bridge} | cut -d "." -f 2) bridge=$(echo ${bridge} | cut -d "." -f 1) fi if [ -z $tag ]; then ovs-vsctl -- --may-exist add-port ${bridge} ${vif} else ovs-vsctl -- --may-exist add-port ${bridge} ${vif} tag=${tag} fi --------------070201050502050607030208 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 --------------070201050502050607030208-- From xen-users-bounces@lists.xen.org Fri Mar 29 18:21:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 18:21: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 1ULduL-0008UZ-D0; Fri, 29 Mar 2013 18:20:09 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULduJ-0008UR-82 for xen-users@lists.xen.org; Fri, 29 Mar 2013 18:20:07 +0000 Received: from [193.109.254.147:34833] by server-11.bemta-14.messagelabs.com id 70/DC-24840-65BD5515; Fri, 29 Mar 2013 18:20:06 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1364581204!9393470!1 X-Originating-IP: [209.85.210.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9553 invoked from network); 29 Mar 2013 18:20:05 -0000 Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com) (209.85.210.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Mar 2013 18:20:05 -0000 Received: by mail-ia0-f173.google.com with SMTP id h37so595456iak.4 for ; Fri, 29 Mar 2013 11:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3lYIoU62FGbSuobmNj6Ttlzg1ENfD6vLT1fHKiV0hz4=; b=LRHv8sNltdmRsY2hMRvdzW99TjzTBJl3j0Kj9lGmdVSqN/fKU0M/AXH9MRUj0jg+zd y4/qqD8/iBEZl3wmEl9zUF4sVJV4TD6wqndZrr616COeOoV86I9r3RnBp04oVnQVG++S BsWq8EbGJs7kg8NayiCT/2itB/Wzn7AKRAGyCzNBGL8xCu/6dfH5gp8oP7n5t83MhQAI KyGPCxLLrcuFvFq1h1xZIpYd8zfrkFldnxFuBIDfEZR1J7Fut5zFt5KzcNOuiNRuZTrK MsgCOFLXYE4lk0p2i1g+NUAYvicIHTopwrcMv7GWDcgT08QdkF5UszkKSZ7279y2ulXq ambQ== MIME-Version: 1.0 X-Received: by 10.50.2.101 with SMTP id 5mr317090igt.29.1364581200953; Fri, 29 Mar 2013 11:20:00 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Fri, 29 Mar 2013 11:20:00 -0700 (PDT) In-Reply-To: <5155B635.4060804@pernau.at> References: <5155AD06.5010802@pernau.at> <5155B635.4060804@pernau.at> Date: Fri, 29 Mar 2013 12:20:00 -0600 Message-ID: From: jacek burghardt To: Klaus Darilion Cc: xen-users Subject: Re: [Xen-users] Yet another networking script for Openvswitch and VLAN support X-BeenThere: xen-users@lists.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="===============3872841936799524488==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3872841936799524488== Content-Type: multipart/alternative; boundary=089e0118235ec009e404d9145156 --089e0118235ec009e404d9145156 Content-Type: text/plain; charset=ISO-8859-1 This looks interesting. I wonder how tap interface gets attached and detached with your script? Are you using openvswich in bridged emulation mode it seems that is no longer supported by openvswitch ? what is your network configuration for hvm ? --089e0118235ec009e404d9145156 Content-Type: text/html; charset=ISO-8859-1
    This looks interesting. I wonder how tap interface gets attached and detached with your script?
    Are you using openvswich in bridged emulation mode it seems that is no longer supported by openvswitch ?
    what is your network configuration for hvm ?

    --089e0118235ec009e404d9145156-- --===============3872841936799524488== 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 --===============3872841936799524488==-- From xen-users-bounces@lists.xen.org Fri Mar 29 18:21:50 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 29 Mar 2013 18:21: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 1ULduL-0008UZ-D0; Fri, 29 Mar 2013 18:20:09 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULduJ-0008UR-82 for xen-users@lists.xen.org; Fri, 29 Mar 2013 18:20:07 +0000 Received: from [193.109.254.147:34833] by server-11.bemta-14.messagelabs.com id 70/DC-24840-65BD5515; Fri, 29 Mar 2013 18:20:06 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1364581204!9393470!1 X-Originating-IP: [209.85.210.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9553 invoked from network); 29 Mar 2013 18:20:05 -0000 Received: from mail-ia0-f173.google.com (HELO mail-ia0-f173.google.com) (209.85.210.173) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Mar 2013 18:20:05 -0000 Received: by mail-ia0-f173.google.com with SMTP id h37so595456iak.4 for ; Fri, 29 Mar 2013 11:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3lYIoU62FGbSuobmNj6Ttlzg1ENfD6vLT1fHKiV0hz4=; b=LRHv8sNltdmRsY2hMRvdzW99TjzTBJl3j0Kj9lGmdVSqN/fKU0M/AXH9MRUj0jg+zd y4/qqD8/iBEZl3wmEl9zUF4sVJV4TD6wqndZrr616COeOoV86I9r3RnBp04oVnQVG++S BsWq8EbGJs7kg8NayiCT/2itB/Wzn7AKRAGyCzNBGL8xCu/6dfH5gp8oP7n5t83MhQAI KyGPCxLLrcuFvFq1h1xZIpYd8zfrkFldnxFuBIDfEZR1J7Fut5zFt5KzcNOuiNRuZTrK MsgCOFLXYE4lk0p2i1g+NUAYvicIHTopwrcMv7GWDcgT08QdkF5UszkKSZ7279y2ulXq ambQ== MIME-Version: 1.0 X-Received: by 10.50.2.101 with SMTP id 5mr317090igt.29.1364581200953; Fri, 29 Mar 2013 11:20:00 -0700 (PDT) Received: by 10.42.41.5 with HTTP; Fri, 29 Mar 2013 11:20:00 -0700 (PDT) In-Reply-To: <5155B635.4060804@pernau.at> References: <5155AD06.5010802@pernau.at> <5155B635.4060804@pernau.at> Date: Fri, 29 Mar 2013 12:20:00 -0600 Message-ID: From: jacek burghardt To: Klaus Darilion Cc: xen-users Subject: Re: [Xen-users] Yet another networking script for Openvswitch and VLAN support X-BeenThere: xen-users@lists.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="===============3872841936799524488==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3872841936799524488== Content-Type: multipart/alternative; boundary=089e0118235ec009e404d9145156 --089e0118235ec009e404d9145156 Content-Type: text/plain; charset=ISO-8859-1 This looks interesting. I wonder how tap interface gets attached and detached with your script? Are you using openvswich in bridged emulation mode it seems that is no longer supported by openvswitch ? what is your network configuration for hvm ? --089e0118235ec009e404d9145156 Content-Type: text/html; charset=ISO-8859-1
    This looks interesting. I wonder how tap interface gets attached and detached with your script?
    Are you using openvswich in bridged emulation mode it seems that is no longer supported by openvswitch ?
    what is your network configuration for hvm ?

    --089e0118235ec009e404d9145156-- --===============3872841936799524488== 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 --===============3872841936799524488==-- From xen-users-bounces@lists.xen.org Sat Mar 30 07:03:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 30 Mar 2013 07:03: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 1ULpnO-0004Yw-N2; Sat, 30 Mar 2013 07:01:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULpnM-0004Yq-EQ for xen-users@lists.xen.org; Sat, 30 Mar 2013 07:01:44 +0000 Received: from [193.109.254.147:48646] by server-7.bemta-14.messagelabs.com id A8/88-19255-7DD86515; Sat, 30 Mar 2013 07:01:43 +0000 X-Env-Sender: christian@holpert.de X-Msg-Ref: server-8.tower-27.messagelabs.com!1364626899!9117220!1 X-Originating-IP: [80.67.31.100] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogODAuNjcuMzEuMTAwID0+IDU5NTIw\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30998 invoked from network); 30 Mar 2013 07:01:40 -0000 Received: from smtprelay05.ispgateway.de (HELO smtprelay05.ispgateway.de) (80.67.31.100) by server-8.tower-27.messagelabs.com with SMTP; 30 Mar 2013 07:01:40 -0000 Received: from [217.83.55.231] (helo=colin.holpert.de) by smtprelay05.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1ULpnH-0002X6-J2 for xen-users@lists.xen.org; Sat, 30 Mar 2013 08:01:39 +0100 Received: from PRO43287A006.holpert.de (unknown [10.75.157.20]) by colin.holpert.de (Postfix) with ESMTP id D1C097FF3 for ; Sat, 30 Mar 2013 08:01:39 +0100 (CET) X-PGP-Fingerprint: D092 371C 931D 8F21 D71B 7A11 DC07 0F36 [RSA] X-PGP-Fingerprint: 8E3B 2F47 6673 B936 9EAE 52F3 4C8B C713 58C5 FFD6 [DH/DSS] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 30 Mar 2013 08:01:38 +0100 To: xen-users@lists.xen.org From: Christian Holpert In-Reply-To: <515590DF.6010704@gmail.com> References: <51558FF6.9090703@gmail.com> <515590DF.6010704@gmail.com> Mime-Version: 1.0 Message-Id: X-Df-Sender: Y2hyaXN0aWFuQGhvbHBlcnQuZGU= Subject: Re: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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 Good Morning, At 14:02 29.03.2013, you wrote: >#!/usr/lib/portage/pym In my case this points to a directory, not a file: xen ~ # ll /usr/lib/portage/ insgesamt 32 drwxr-xr-x 4 root root 4096 10. Dez 05:43 . drwxr-xr-x 35 root root 20480 11. M=E4r 23:24 .. drwxr-xr-x 3 root root 4096 4. M=E4r 08:39 bin drwxr-xr-x 5 root root 4096 10. Dez 05:43 pym A directory is a 'bad interpreter' in my eyes. Try changing the path to >#!/usr/bin/python2.7 or whatever python interpreter exists. It seems you build your xen-system from source. Alternatively I would suggest emerging xen and xentools. This might = avoid your problem. Christian -- = Markt-Apotheke Christian Holpert e.K., M=F6mbris http://www.marktapotheke.org - info@marktapotheke.org http://www.blue-essentials-shop.de - info@blue-essentials-shop.de Apotheker Christian Holpert Im Markthof 5 63776 M=F6mbris Tel.: 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, Registernummer 2165 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Mar 30 07:03:25 2013 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 30 Mar 2013 07:03: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 1ULpnO-0004Yw-N2; Sat, 30 Mar 2013 07:01:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ULpnM-0004Yq-EQ for xen-users@lists.xen.org; Sat, 30 Mar 2013 07:01:44 +0000 Received: from [193.109.254.147:48646] by server-7.bemta-14.messagelabs.com id A8/88-19255-7DD86515; Sat, 30 Mar 2013 07:01:43 +0000 X-Env-Sender: christian@holpert.de X-Msg-Ref: server-8.tower-27.messagelabs.com!1364626899!9117220!1 X-Originating-IP: [80.67.31.100] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogODAuNjcuMzEuMTAwID0+IDU5NTIw\n X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30998 invoked from network); 30 Mar 2013 07:01:40 -0000 Received: from smtprelay05.ispgateway.de (HELO smtprelay05.ispgateway.de) (80.67.31.100) by server-8.tower-27.messagelabs.com with SMTP; 30 Mar 2013 07:01:40 -0000 Received: from [217.83.55.231] (helo=colin.holpert.de) by smtprelay05.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1ULpnH-0002X6-J2 for xen-users@lists.xen.org; Sat, 30 Mar 2013 08:01:39 +0100 Received: from PRO43287A006.holpert.de (unknown [10.75.157.20]) by colin.holpert.de (Postfix) with ESMTP id D1C097FF3 for ; Sat, 30 Mar 2013 08:01:39 +0100 (CET) X-PGP-Fingerprint: D092 371C 931D 8F21 D71B 7A11 DC07 0F36 [RSA] X-PGP-Fingerprint: 8E3B 2F47 6673 B936 9EAE 52F3 4C8B C713 58C5 FFD6 [DH/DSS] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 30 Mar 2013 08:01:38 +0100 To: xen-users@lists.xen.org From: Christian Holpert In-Reply-To: <515590DF.6010704@gmail.com> References: <51558FF6.9090703@gmail.com> <515590DF.6010704@gmail.com> Mime-Version: 1.0 Message-Id: X-Df-Sender: Y2hyaXN0aWFuQGhvbHBlcnQuZGU= Subject: Re: [Xen-users] I can't Start xend on gentoo linux. X-BeenThere: xen-users@lists.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 Good Morning, At 14:02 29.03.2013, you wrote: >#!/usr/lib/portage/pym In my case this points to a directory, not a file: xen ~ # ll /usr/lib/portage/ insgesamt 32 drwxr-xr-x 4 root root 4096 10. Dez 05:43 . drwxr-xr-x 35 root root 20480 11. M=E4r 23:24 .. drwxr-xr-x 3 root root 4096 4. M=E4r 08:39 bin drwxr-xr-x 5 root root 4096 10. Dez 05:43 pym A directory is a 'bad interpreter' in my eyes. Try changing the path to >#!/usr/bin/python2.7 or whatever python interpreter exists. It seems you build your xen-system from source. Alternatively I would suggest emerging xen and xentools. This might = avoid your problem. Christian -- = Markt-Apotheke Christian Holpert e.K., M=F6mbris http://www.marktapotheke.org - info@marktapotheke.org http://www.blue-essentials-shop.de - info@blue-essentials-shop.de Apotheker Christian Holpert Im Markthof 5 63776 M=F6mbris Tel.: 06029-1379 Fax: 9986589 Amtsgericht Aschaffenburg, HR.A, Registernummer 2165 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users