[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Xen-users Digest, Vol 92, Issue 32

Any idea when the offical release of XCP 1.6 is? Also is it possible to
get HA working in XCP 1.1?

On 10/18/12 7:00 AM, "xen-users-request@xxxxxxxxxxxxx"
<xen-users-request@xxxxxxxxxxxxx> wrote:

>Send Xen-users mailing list submissions to
>       xen-users@xxxxxxxxxxxxx
>
>To subscribe or unsubscribe via the World Wide Web, visit
>       http://lists.xen.org/cgi-bin/mailman/listinfo/xen-users
>or, via email, send a message with subject or body 'help' to
>       xen-users-request@xxxxxxxxxxxxx
>
>You can reach the person managing the list at
>       xen-users-owner@xxxxxxxxxxxxx
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Xen-users digest..."
>
>
>Today's Topics:
>
>   1. Re: pygrub: reboot causes on_poweroff instead of on_reboot
>      (Ian Campbell)
>   2. Re: [Xen-devel]  Re: Xen 4 TSC problems (Keir Fraser)
>   3. Emulex OneConnect Virtualization (Deepak)
>   4. Re: [Xen-devel]  Re: Xen 4 TSC problems (Ian Campbell)
>   5. Re: [Xen-devel]  Re: Xen 4 TSC problems (Keir Fraser)
>   6. Re: [Xen-devel]  Re: Xen 4 TSC problems (Ian Campbell)
>   7. Re: [Xen-devel] Re: Xen 4 TSC problems (Mauro)
>   8. Re: [Xen-devel] Re: Xen 4 TSC problems (Ian Campbell)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 17 Oct 2012 14:05:56 +0100
>From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
>To: T <hex445@xxxxxxxxx>
>Cc: "wesley@xxxxxxxxxxx" <wesley@xxxxxxxxxxx>,
>       "xen-users@xxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxx>
>Subject: Re: [Xen-users] pygrub: reboot causes on_poweroff instead of
>       on_reboot
>Message-ID: <1350479156.2460.64.camel@xxxxxxxxxxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="UTF-8"
>
>On Wed, 2012-10-17 at 11:41 +0100, T wrote:
>> This bug is described here:
>> http://lists.xen.org/archives/html/xen-users/2012-05/msg00285.html
>> 
>> Is it going to be resolved in 4.1 ?
>
>I'm afraid not (IIRC the fix was quite intrusive).
>
>If xl doesn't work for your use cases in4.1 then I recommend continuing
>to use xend with 4.1 and only switching to xl with 4.2.
>
>> Installing packages from Debian experimental(xen-hypervisor-4.2-amd64)
>> resolves this issue.
>
>Good!
>
>Ian.
>
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Wed, 17 Oct 2012 17:15:40 +0100
>From: Keir Fraser <keir@xxxxxxx>
>To: Mauro <mrsanna1@xxxxxxxxx>,        Jan Beulich <JBeulich@xxxxxxxx>
>Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
>       xen-devel@xxxxxxxxxxxxxxxxxxx,  Dan Magenheimer
>       <dan.magenheimer@xxxxxxxxxx>,   Olivier Hanesse
>       <olivier.hanesse@xxxxxxxxx>,    Xen Users
>       <xen-users@xxxxxxxxxxxxxxxxxxx>,        Mark Adams 
> <mark@xxxxxxxxxxxxxxxxxx>
>Subject: Re: [Xen-users] [Xen-devel]  Re: Xen 4 TSC problems
>Message-ID: <CCA4983E.4FEA0%keir@xxxxxxx>
>Content-Type: text/plain; charset="us-ascii"
>
>On 15/10/2012 15:25, "Mauro" <mrsanna1@xxxxxxxxx> wrote:
>
>> On 15 October 2012 14:49, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 15.10.12 at 13:24, Mauro <mrsanna1@xxxxxxxxx> wrote:
>>>> I have the problem on this hardware type:
>>>> 
>>>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>>>> It seem that
>>>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>>>> put in in /etc/default/grup (I use linux debian)
>>>> solves the problem for me.
>>> 
>>> Did you check whether either or both options on their own also
>>> make the problem go away?
>> 
>> Only clocksource=pit does not solve the problem, I've not tried with
>> only cpuidle=0, I will try soon.
>
>The problem here is that the platform timer has *not* wrapped. In fact it
>is
>almost certainly correct, and it is the calculation of current-system-time
>extrapolated from local CPU's TSC that has gone haywire. The
>overflow-handling logic in plt_overflow() then propagates that
>incorrectness
>into plt_stamp64 (up to a maximum of 10 times wrapping the platform
>timer's
>counter). This means that platform time is incorrect (skips forward) and
>soon after will infect the local time estimation for all CPUs.
>
>I've attached a patch which will (a) stop plt_overflow() from misguidedly
>trying to fix up apparent platform timer overflow; and (b) will print
>possibly-useful diagnostics when apparent 'timer overflow' occurs. Such
>lines will be prefixed "XXX plt_overflow:" in the hypervisor log. Patch is
>against xen-unstable but I'm sure it must backport to older trees quite
>trivially.
>
> -- Keir
>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: 00-tsc-debug
>Type: application/octet-stream
>Size: 1255 bytes
>Desc: not available
>URL: 
><http://lists.xen.org/archives/html/xen-users/attachments/20121017/3bd4afc
>7/attachment.obj>
>
>------------------------------
>
>Message: 3
>Date: Thu, 18 Oct 2012 00:56:24 +0530
>From: Deepak <ushouldmailme@xxxxxxxxx>
>To: xen-users@xxxxxxxxxxxxx
>Subject: [Xen-users] Emulex OneConnect Virtualization
>Message-ID:
>       <CAA0VTA=ihz-mTFaXExZp-CaNTpj+3jde+N+KC0DkJdqCqup3-A@xxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="iso-8859-1"
>
>I am trying to get Xen Dom0 up & running on the Emulex OneConnect NIC, but
>it seems impossible as the NIC drivers don't seem to support
>virtualization
>currently. Did anyone try & port any other drivers to get the server up?
>
>Server: IBM HS23
>NIC: Emulex OneConnect 10GB Ethernet [LAN on Motherboard]
>
>Thanks in advance
>Deepak.
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
><http://lists.xen.org/archives/html/xen-users/attachments/20121018/1f2afdc
>0/attachment.html>
>
>------------------------------
>
>Message: 4
>Date: Thu, 18 Oct 2012 08:40:21 +0100
>From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
>To: Keir Fraser <keir@xxxxxxx>
>Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
>       "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>,        
> Dan
>       Magenheimer <dan.magenheimer@xxxxxxxxxx>, Mauro <mrsanna1@xxxxxxxxx>,
>       Olivier Hanesse <olivier.hanesse@xxxxxxxxx>,    Jan Beulich
>       <JBeulich@xxxxxxxx>, Xen Users <xen-users@xxxxxxxxxxxxxxxxxxx>, Mark
>       Adams <mark@xxxxxxxxxxxxxxxxxx>
>Subject: Re: [Xen-users] [Xen-devel]  Re: Xen 4 TSC problems
>Message-ID: <1350546021.28188.20.camel@xxxxxxxxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="ISO-8859-1"
>
>On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>>              break;
>> +        rdtscll(tsc);
>> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
>> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
>> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>> +               plt_now, plt_wrap, now, old_stamp, plt_stamp,
>>plt_stamp64,
>> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>> +        break;
>
>Is the break here, making the following update to plt_stamp64 dead code
>deliberate?
>
>>          plt_stamp64 += plt_mask + 1;
>>      }
>>      if ( i != 0 )
>
>Ian.
>
>
>
>
>
>------------------------------
>
>Message: 5
>Date: Thu, 18 Oct 2012 08:55:04 +0100
>From: Keir Fraser <keir.xen@xxxxxxxxx>
>To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
>Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
>       "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>,        
> Dan
>       Magenheimer <dan.magenheimer@xxxxxxxxxx>, Mauro <mrsanna1@xxxxxxxxx>,
>       Olivier Hanesse <olivier.hanesse@xxxxxxxxx>,    Jan Beulich
>       <JBeulich@xxxxxxxx>, Xen Users <xen-users@xxxxxxxxxxxxxxxxxxx>, Mark
>       Adams <mark@xxxxxxxxxxxxxxxxxx>
>Subject: Re: [Xen-users] [Xen-devel]  Re: Xen 4 TSC problems
>Message-ID: <CCA57468.41EF3%keir.xen@xxxxxxxxx>
>Content-Type: text/plain;      charset="US-ASCII"
>
>On 18/10/2012 08:40, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
>
>> On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>>> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>>>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask + 1);
>>>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>>>              break;
>>> +        rdtscll(tsc);
>>> +        printk("XXX plt_overflow: plt_now=%"PRIx64" plt_wrap=%"PRIx64
>>> +               " now=%"PRIx64" old_stamp=%"PRIx64" new_stamp=%"PRIx64
>>> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>>> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>>> +               plt_now, plt_wrap, now, old_stamp, plt_stamp,
>>>plt_stamp64,
>>> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>>> +        break;
>> 
>> Is the break here, making the following update to plt_stamp64 dead code
>> deliberate?
>
>Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.
>
> -- Keir
>
>>>          plt_stamp64 += plt_mask + 1;
>>>      }
>>>      if ( i != 0 )
>> 
>> Ian.
>> 
>> 
>
>
>
>
>
>------------------------------
>
>Message: 6
>Date: Thu, 18 Oct 2012 09:33:52 +0100
>From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
>To: Keir Fraser <keir.xen@xxxxxxxxx>
>Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
>       "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>,        
> Dan
>       Magenheimer <dan.magenheimer@xxxxxxxxxx>, Mauro <mrsanna1@xxxxxxxxx>,
>       Olivier Hanesse <olivier.hanesse@xxxxxxxxx>,    Jan Beulich
>       <JBeulich@xxxxxxxx>, Xen Users <xen-users@xxxxxxxxxxxxxxxxxxx>, Mark
>       Adams <mark@xxxxxxxxxxxxxxxxxx>
>Subject: Re: [Xen-users] [Xen-devel]  Re: Xen 4 TSC problems
>Message-ID: <1350549232.28188.39.camel@xxxxxxxxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="ISO-8859-1"
>
>On Thu, 2012-10-18 at 08:55 +0100, Keir Fraser wrote:
>> On 18/10/2012 08:40, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
>> 
>> > On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>> >> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>> >>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask +
>>1);
>> >>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>> >>              break;
>> >> +        rdtscll(tsc);
>> >> +        printk("XXX plt_overflow: plt_now=%"PRIx64"
>>plt_wrap=%"PRIx64
>> >> +               " now=%"PRIx64" old_stamp=%"PRIx64"
>>new_stamp=%"PRIx64
>> >> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>> >> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>> >> +               plt_now, plt_wrap, now, old_stamp, plt_stamp,
>>plt_stamp64,
>> >> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>> >> +        break;
>> > 
>> > Is the break here, making the following update to plt_stamp64 dead
>>code
>> > deliberate?
>> 
>> Yes, it's a hack to disable the timer-has-apparently-wrapped workaround.
>
>OK, good.
>
>I wonder if this explains some of the issues which have been plaguing
>Debian Squeeze (4.0 based) for a while now. I'll see if I can get
>someone there to give it a go.
>
>Ian.
>
>> 
>>  -- Keir
>> 
>> >>          plt_stamp64 += plt_mask + 1;
>> >>      }
>> >>      if ( i != 0 )
>> > 
>> > Ian.
>> > 
>> > 
>> 
>> 
>
>
>
>
>
>------------------------------
>
>Message: 7
>Date: Thu, 18 Oct 2012 10:56:22 +0200
>From: Mauro <mrsanna1@xxxxxxxxx>
>To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
>Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
>       "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>,        
> Dan
>       Magenheimer <dan.magenheimer@xxxxxxxxxx>,       Olivier Hanesse
>       <olivier.hanesse@xxxxxxxxx>,    Keir Fraser <keir.xen@xxxxxxxxx>, Jan
>       Beulich <JBeulich@xxxxxxxx>,    Xen Users
>       <xen-users@xxxxxxxxxxxxxxxxxxx>,        Mark Adams 
> <mark@xxxxxxxxxxxxxxxxxx>
>Subject: Re: [Xen-users] [Xen-devel] Re: Xen 4 TSC problems
>Message-ID:
>       <CAE17a0WjOQVafkRzkRVCFV4bNowGhVJJ-t5FF9tLGWTcXygcKw@xxxxxxxxxxxxxx>
>Content-Type: text/plain; charset=UTF-8
>
>On 18 October 2012 10:33, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> On Thu, 2012-10-18 at 08:55 +0100, Keir Fraser wrote:
>>> On 18/10/2012 08:40, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
>>>
>>> > On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>>> >> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>>> >>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask +
>>>1);
>>> >>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>>> >>              break;
>>> >> +        rdtscll(tsc);
>>> >> +        printk("XXX plt_overflow: plt_now=%"PRIx64"
>>>plt_wrap=%"PRIx64
>>> >> +               " now=%"PRIx64" old_stamp=%"PRIx64"
>>>new_stamp=%"PRIx64
>>> >> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>>> >> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>>> >> +               plt_now, plt_wrap, now, old_stamp, plt_stamp,
>>>plt_stamp64,
>>> >> +               plt_mask, tsc, this_cpu(cpu_time).local_tsc_stamp);
>>> >> +        break;
>>> >
>>> > Is the break here, making the following update to plt_stamp64 dead
>>>code
>>> > deliberate?
>>>
>>> Yes, it's a hack to disable the timer-has-apparently-wrapped
>>>workaround.
>>
>> OK, good.
>>
>> I wonder if this explains some of the issues which have been plaguing
>> Debian Squeeze (4.0 based) for a while now. I'll see if I can get
>> someone there to give it a go.
>
>If that patch works debian kernel maintainers can be advised if they
>can include that patch and release a new kernel working for squeeze.
>
>
>
>------------------------------
>
>Message: 8
>Date: Thu, 18 Oct 2012 10:36:30 +0100
>From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
>To: Mauro <mrsanna1@xxxxxxxxx>
>Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
>       "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>,        
> Dan
>       Magenheimer <dan.magenheimer@xxxxxxxxxx>,       Olivier Hanesse
>       <olivier.hanesse@xxxxxxxxx>,    Keir Fraser <keir.xen@xxxxxxxxx>, Jan
>       Beulich <JBeulich@xxxxxxxx>,    Xen Users
>       <xen-users@xxxxxxxxxxxxxxxxxxx>,        Mark Adams 
> <mark@xxxxxxxxxxxxxxxxxx>
>Subject: Re: [Xen-users] [Xen-devel] Re: Xen 4 TSC problems
>Message-ID: <1350552990.2460.89.camel@xxxxxxxxxxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="UTF-8"
>
>On Thu, 2012-10-18 at 09:56 +0100, Mauro wrote:
>> On 18 October 2012 10:33, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Thu, 2012-10-18 at 08:55 +0100, Keir Fraser wrote:
>> >> On 18/10/2012 08:40, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
>> >>
>> >> > On Wed, 2012-10-17 at 17:15 +0100, Keir Fraser wrote:
>> >> >> @@ -540,6 +541,14 @@ static void plt_overflow(void *unused)
>> >> >>          plt_wrap = __read_platform_stime(plt_stamp64 + plt_mask
>>+ 1);
>> >> >>          if ( ABS(plt_wrap - now) > ABS(plt_now - now) )
>> >> >>              break;
>> >> >> +        rdtscll(tsc);
>> >> >> +        printk("XXX plt_overflow: plt_now=%"PRIx64"
>>plt_wrap=%"PRIx64
>> >> >> +               " now=%"PRIx64" old_stamp=%"PRIx64"
>>new_stamp=%"PRIx64
>> >> >> +               " plt_stamp64=%"PRIx64" plt_mask=%"PRIx64
>> >> >> +               " tsc=%"PRIx64" tsc_stamp=%"PRIx64"\n",
>> >> >> +               plt_now, plt_wrap, now, old_stamp, plt_stamp,
>>plt_stamp64,
>> >> >> +               plt_mask, tsc,
>>this_cpu(cpu_time).local_tsc_stamp);
>> >> >> +        break;
>> >> >
>> >> > Is the break here, making the following update to plt_stamp64 dead
>>code
>> >> > deliberate?
>> >>
>> >> Yes, it's a hack to disable the timer-has-apparently-wrapped
>>workaround.
>> >
>> > OK, good.
>> >
>> > I wonder if this explains some of the issues which have been plaguing
>> > Debian Squeeze (4.0 based) for a while now. I'll see if I can get
>> > someone there to give it a go.
>> 
>> If that patch works debian kernel maintainers can be advised if they
>> can include that patch and release a new kernel working for squeeze.
>
>AFAIK this is a debug patch, not something we would deploy as is but it
>should give us the information required to work out a real fix.
>
>Ian
>
>
>
>
>------------------------------
>
>_______________________________________________
>Xen-users mailing list
>Xen-users@xxxxxxxxxxxxx
>http://lists.xen.org/xen-users
>
>
>End of Xen-users Digest, Vol 92, Issue 32
>*****************************************


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

 

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.

Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.