Time Change Issue Xen 4.1

Time Change Issue Xen 4.1

[Niall Fleming]

[-- Attachment #1.1: Type: text/plain, Size: 1394 bytes --]

Hi all,

Already posted this over in xen-users and Konrad confirms it as a bug 
and suggested to repost
it over here!

Issue is that changing the time in dom0 doesn't take effect on the VMs 
until a reboot of dom0.
The testing example below illustrates what I mean....

Synopsis of testing:

Booted the physical machine, date tells me it's 17:15:45. Hwclock agrees.
Booted a VM (using xl as xm seems to be labouring under the impression 
that blockdev is missing - it isn't)
The login prompt displays the time as 17:17, which is the expected 
behaviour.
Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock.
Check that date and hwclock match - they do.
Destroy the VM and recreate.
The login prompt displays the time as 17:22. Unexpected!


Kernel: I git cloned tag v3.1 from the kernel.org linux.git, and applied 
xen-settime patches
Also tested with jeremy-git-xen-next-2.6.32 (.41/.46) without patch, 
they wouldn't apply.
Xen: 4.1.1/4.1.2
Distribution: Gentoo

It still doesn't work.

I've tested that the issue also exists in Debian Squeeze (with 
linux-image-3.0.0 from testing as 2.6.32-5 is broken
on my hardware).
-- 

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

[-- Attachment #1.2: Type: text/html, Size: 2027 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Time Change Issue Xen 4.1

[Konrad Rzeszutek Wilk]

On Fri, Nov 11, 2011 at 05:25:52PM +0000, Niall Fleming wrote:
> Hi all,
> 
> Already posted this over in xen-users and Konrad confirms it as a
> bug and suggested to repost
> it over here!

Laszlo, Paolo, Jan, you guys haven't seen domething like this? It looks
like a hypervisor issue where the wallclock time is not really dispursed
in the shared_info.

> 
> Issue is that changing the time in dom0 doesn't take effect on the
> VMs until a reboot of dom0.
> The testing example below illustrates what I mean....
> 
> Synopsis of testing:
> 
> Booted the physical machine, date tells me it's 17:15:45. Hwclock agrees.
> Booted a VM (using xl as xm seems to be labouring under the
> impression that blockdev is missing - it isn't)
> The login prompt displays the time as 17:17, which is the expected
> behaviour.
> Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock.
> Check that date and hwclock match - they do.
> Destroy the VM and recreate.
> The login prompt displays the time as 17:22. Unexpected!
> 
> 
> Kernel: I git cloned tag v3.1 from the kernel.org linux.git, and
> applied xen-settime patches
> Also tested with jeremy-git-xen-next-2.6.32 (.41/.46) without patch,
> they wouldn't apply.
> Xen: 4.1.1/4.1.2
> Distribution: Gentoo
> 
> It still doesn't work.
> 
> I've tested that the issue also exists in Debian Squeeze (with
> linux-image-3.0.0 from testing as 2.6.32-5 is broken
> on my hardware).
> -- 
> 
> *Niall Fleming BSc. (Hons)*
> Systems Administrator
> Webanywhere Limited
> 
> Phone: 0800 862 0131 Ext: 203
> Web: http://www.webanywhere.co.uk
> 
> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
> Registered in England with company number 4881346

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Time Change Issue Xen 4.1

[Jan Beulich]

>>> On 11.11.11 at 19:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 11, 2011 at 05:25:52PM +0000, Niall Fleming wrote:
>> Hi all,
>> 
>> Already posted this over in xen-users and Konrad confirms it as a
>> bug and suggested to repost
>> it over here!
> 
> Laszlo, Paolo, Jan, you guys haven't seen domething like this? It looks
> like a hypervisor issue where the wallclock time is not really dispursed
> in the shared_info.

Hypervisor? Upstream up to and including 3.1 just doesn't issue the
necessary hypercalls. This was fixed only recently through patches
from Jeremy. We had a different issue in that respect in the forward
ported Linux trees, but that got fixed a couple of months ago, too.

This not working in Jeremy's 2.6.32 tree is odd though, but I'm not
certain which branches the necessary code would on.

>> 
>> Issue is that changing the time in dom0 doesn't take effect on the
>> VMs until a reboot of dom0.
>> The testing example below illustrates what I mean....
>> 
>> Synopsis of testing:
>> 
>> Booted the physical machine, date tells me it's 17:15:45. Hwclock agrees.
>> Booted a VM (using xl as xm seems to be labouring under the
>> impression that blockdev is missing - it isn't)
>> The login prompt displays the time as 17:17, which is the expected
>> behaviour.
>> Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock.
>> Check that date and hwclock match - they do.
>> Destroy the VM and recreate.
>> The login prompt displays the time as 17:22. Unexpected!
>> 
>> 
>> Kernel: I git cloned tag v3.1 from the kernel.org linux.git, and
>> applied xen-settime patches
>> Also tested with jeremy-git-xen-next-2.6.32 (.41/.46) without patch,
>> they wouldn't apply.
>> Xen: 4.1.1/4.1.2
>> Distribution: Gentoo
>> 
>> It still doesn't work.
>> 
>> I've tested that the issue also exists in Debian Squeeze (with
>> linux-image-3.0.0 from testing as 2.6.32-5 is broken
>> on my hardware).
>> -- 
>> 
>> *Niall Fleming BSc. (Hons)*
>> Systems Administrator
>> Webanywhere Limited
>> 
>> Phone: 0800 862 0131 Ext: 203
>> Web: http://www.webanywhere.co.uk 
>> 
>> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
>> Registered in England with company number 4881346
> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 

Re: Time Change Issue Xen 4.1

[Laszlo Ersek]

On 11/11/11 19:39, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 11, 2011 at 05:25:52PM +0000, Niall Fleming wrote:

>> Booted the physical machine, date tells me it's 17:15:45. Hwclock agrees.
>> Booted a VM (using xl as xm seems to be labouring under the
>> impression that blockdev is missing - it isn't)
>> The login prompt displays the time as 17:17, which is the expected
>> behaviour.
>> Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock.
>> Check that date and hwclock match - they do.
>> Destroy the VM and recreate.
>> The login prompt displays the time as 17:22. Unexpected!

I shut the VM down (2.6.32-131.0.15.el6) before the systime/hwclock 
change in dom0 (2.6.18-286.el5xen), and restarted it afterwards. The 
guest entered an infinite loop during this boot :(

Thanks
Laszlo

Re: Time Change Issue Xen 4.1

[Konrad Rzeszutek Wilk]

On Mon, Nov 14, 2011 at 09:48:45AM +0000, Jan Beulich wrote:
> >>> On 11.11.11 at 19:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Fri, Nov 11, 2011 at 05:25:52PM +0000, Niall Fleming wrote:
> >> Hi all,
> >> 
> >> Already posted this over in xen-users and Konrad confirms it as a
> >> bug and suggested to repost
> >> it over here!
> > 
> > Laszlo, Paolo, Jan, you guys haven't seen domething like this? It looks
> > like a hypervisor issue where the wallclock time is not really dispursed
> > in the shared_info.
> 
> Hypervisor? Upstream up to and including 3.1 just doesn't issue the
> necessary hypercalls. This was fixed only recently through patches
> from Jeremy. We had a different issue in that respect in the forward
> ported Linux trees, but that got fixed a couple of months ago, too.

Right. With those patches too (he used the xen-settime patch set which has it).
The hypercall is done (and the do_settime gets called) and the results are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.

The problem is that wc_sec and wc_nsec are only propagated to the
existing guests.

If you launch a new guest after the 'hwclock', the new guests
retains the old wallclock time.

> 
> This not working in Jeremy's 2.6.32 tree is odd though, but I'm not
> certain which branches the necessary code would on.
> 
> >> 
> >> Issue is that changing the time in dom0 doesn't take effect on the
> >> VMs until a reboot of dom0.
> >> The testing example below illustrates what I mean....
> >> 
> >> Synopsis of testing:
> >> 
> >> Booted the physical machine, date tells me it's 17:15:45. Hwclock agrees.
> >> Booted a VM (using xl as xm seems to be labouring under the
> >> impression that blockdev is missing - it isn't)
> >> The login prompt displays the time as 17:17, which is the expected
> >> behaviour.
> >> Changed the time in dom0 - (date +%T -s 12:00:00), synced to hwclock.
> >> Check that date and hwclock match - they do.
> >> Destroy the VM and recreate.
> >> The login prompt displays the time as 17:22. Unexpected!
> >> 
> >> 
> >> Kernel: I git cloned tag v3.1 from the kernel.org linux.git, and
> >> applied xen-settime patches
> >> Also tested with jeremy-git-xen-next-2.6.32 (.41/.46) without patch,
> >> they wouldn't apply.
> >> Xen: 4.1.1/4.1.2
> >> Distribution: Gentoo
> >> 
> >> It still doesn't work.
> >> 
> >> I've tested that the issue also exists in Debian Squeeze (with
> >> linux-image-3.0.0 from testing as 2.6.32-5 is broken
> >> on my hardware).
> >> -- 
> >> 
> >> *Niall Fleming BSc. (Hons)*
> >> Systems Administrator
> >> Webanywhere Limited
> >> 
> >> Phone: 0800 862 0131 Ext: 203
> >> Web: http://www.webanywhere.co.uk 
> >> 
> >> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
> >> Registered in England with company number 4881346
> > 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com 
> >> http://lists.xensource.com/xen-devel 
> 
> 

Re: Time Change Issue Xen 4.1

[Jeremy Fitzhardinge]

On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
> Right. With those patches too (he used the xen-settime patch set which has it).
> The hypercall is done (and the do_settime gets called) and the results are saved
> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>
> The problem is that wc_sec and wc_nsec are only propagated to the
> existing guests.
>
> If you launch a new guest after the 'hwclock', the new guests
> retains the old wallclock time.

Existing (pvops) guests shouldn't see updated wallclock time, because
they never look at the hypervisor's wallclock after boot time.

It's surprising that new guests don't see the updated wallclock though. 
That sounds like a Xen issue.

    J

Re: Time Change Issue Xen 4.1

[Konrad Rzeszutek Wilk]

On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
> > Right. With those patches too (he used the xen-settime patch set which has it).
> > The hypercall is done (and the do_settime gets called) and the results are saved
> > in the RTC. And the wc_sec and wc_nsec are updated and propagated.
> >
> > The problem is that wc_sec and wc_nsec are only propagated to the
> > existing guests.
> >
> > If you launch a new guest after the 'hwclock', the new guests
> > retains the old wallclock time.
> 
> Existing (pvops) guests shouldn't see updated wallclock time, because
> they never look at the hypervisor's wallclock after boot time.
> 
> It's surprising that new guests don't see the updated wallclock though. 
> That sounds like a Xen issue.

<nods> That is what I think is happening here.

Re: Time Change Issue Xen 4.1

[Niall Fleming]

[-- Attachment #1.1: Type: text/plain, Size: 1368 bytes --]

OK, what's the lead time on getting that patched?

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>> Right. With those patches too (he used the xen-settime patch set which has it).
>>> The hypercall is done (and the do_settime gets called) and the results are saved
>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>
>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>> existing guests.
>>>
>>> If you launch a new guest after the 'hwclock', the new guests
>>> retains the old wallclock time.
>> Existing (pvops) guests shouldn't see updated wallclock time, because
>> they never look at the hypervisor's wallclock after boot time.
>>
>> It's surprising that new guests don't see the updated wallclock though.
>> That sounds like a Xen issue.
> <nods>  That is what I think is happening here.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 2221 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Time Change Issue Xen 4.1

[Niall Fleming]

[-- Attachment #1.1: Type: text/plain, Size: 1324 bytes --]

ping?

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>> Right. With those patches too (he used the xen-settime patch set which has it).
>>> The hypercall is done (and the do_settime gets called) and the results are saved
>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>
>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>> existing guests.
>>>
>>> If you launch a new guest after the 'hwclock', the new guests
>>> retains the old wallclock time.
>> Existing (pvops) guests shouldn't see updated wallclock time, because
>> they never look at the hypervisor's wallclock after boot time.
>>
>> It's surprising that new guests don't see the updated wallclock though.
>> That sounds like a Xen issue.
> <nods>  That is what I think is happening here.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 2177 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Time Change Issue Xen 4.1

[Niall Fleming]

[-- Attachment #1.1: Type: text/plain, Size: 1365 bytes --]

Another week, and no response?

ping?

Please?

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>> Right. With those patches too (he used the xen-settime patch set which has it).
>>> The hypercall is done (and the do_settime gets called) and the results are saved
>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>
>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>> existing guests.
>>>
>>> If you launch a new guest after the 'hwclock', the new guests
>>> retains the old wallclock time.
>> Existing (pvops) guests shouldn't see updated wallclock time, because
>> they never look at the hypervisor's wallclock after boot time.
>>
>> It's surprising that new guests don't see the updated wallclock though.
>> That sounds like a Xen issue.
> <nods>  That is what I think is happening here.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 2256 bytes --]

[-- Attachment #2: Attached Message Part --]
[-- Type: text/plain, Size: 139 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Time Change Issue Xen 4.1

[Konrad Rzeszutek Wilk]

On Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote:
> Another week, and no response?

I am sooo tempted to make a time joke :-)
> 
> ping?

We are just swamped. <sigh> Wish I had a better response,
like: Try this patch, but not yet.

> 
> Please?
> 
> *Niall Fleming BSc. (Hons)*
> Systems Administrator
> Webanywhere Limited
> 
> Phone: 0800 862 0131 Ext: 203
> Web: http://www.webanywhere.co.uk
> 
> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
> Registered in England with company number 4881346
> 
> On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> >On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
> >>On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
> >>>Right. With those patches too (he used the xen-settime patch set which 
> >>>has it).
> >>>The hypercall is done (and the do_settime gets called) and the results 
> >>>are saved
> >>>in the RTC. And the wc_sec and wc_nsec are updated and propagated.
> >>>
> >>>The problem is that wc_sec and wc_nsec are only propagated to the
> >>>existing guests.
> >>>
> >>>If you launch a new guest after the 'hwclock', the new guests
> >>>retains the old wallclock time.
> >>Existing (pvops) guests shouldn't see updated wallclock time, because
> >>they never look at the hypervisor's wallclock after boot time.
> >>
> >>It's surprising that new guests don't see the updated wallclock though.
> >>That sounds like a Xen issue.
> ><nods>  That is what I think is happening here.
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xensource.com
> >http://lists.xensource.com/xen-devel

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Time Change Issue Xen 4.1

[Niall Fleming]

[-- Attachment #1.1: Type: text/plain, Size: 2531 bytes --]

Cheers, at least I know that someone is still looking at it!

If someone could give me a general timeframe, like it'll be a month, 
before we fix it, or
two weeks or whatever, I just need to give my line manager something so 
he gets off my
case about it!


*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 30/11/2011 22:26, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote:
>> Another week, and no response?
> I am sooo tempted to make a time joke :-)
>> ping?
> We are just swamped.<sigh>  Wish I had a better response,
> like: Try this patch, but not yet.
>
>> Please?
>>
>> *Niall Fleming BSc. (Hons)*
>> Systems Administrator
>> Webanywhere Limited
>>
>> Phone: 0800 862 0131 Ext: 203
>> Web: http://www.webanywhere.co.uk
>>
>> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
>> Registered in England with company number 4881346
>>
>> On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>>>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>>>> Right. With those patches too (he used the xen-settime patch set which
>>>>> has it).
>>>>> The hypercall is done (and the do_settime gets called) and the results
>>>>> are saved
>>>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>>>
>>>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>>>> existing guests.
>>>>>
>>>>> If you launch a new guest after the 'hwclock', the new guests
>>>>> retains the old wallclock time.
>>>> Existing (pvops) guests shouldn't see updated wallclock time, because
>>>> they never look at the hypervisor's wallclock after boot time.
>>>>
>>>> It's surprising that new guests don't see the updated wallclock though.
>>>> That sounds like a Xen issue.
>>> <nods>   That is what I think is happening here.
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 4356 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Time Change Issue Xen 4.1

[Ian Campbell]

On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
> Cheers, at least I know that someone is still looking at it!
> 
> If someone could give me a general timeframe, like it'll be a month,
> before we fix it, or two weeks or whatever, I just need to give my
> line manager something so he gets off my case about it!

I'm afraid OSS software doesn't generally work like that. If you (or
your boss) wants something fixed on a specific time scale or priority
you'll have to role your sleeves up and scratch the itch. Otherwise I'm
sorry but you will just have to wait until someone has the cycles to
look into this issue.

Ian.

Re: Time Change Issue Xen 4.1

[Laszlo Ersek]

Hello Niall,

On 12/01/11 10:53, Ian Campbell wrote:
> On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
>> Cheers, at least I know that someone is still looking at it!
>>
>> If someone could give me a general timeframe, like it'll be a month,
>> before we fix it, or two weeks or whatever, I just need to give my
>> line manager something so he gets off my case about it!
>
> I'm afraid OSS software doesn't generally work like that. If you (or
> your boss) wants something fixed on a specific time scale or priority
> you'll have to role your sleeves up and scratch the itch. Otherwise I'm
> sorry but you will just have to wait until someone has the cycles to
> look into this issue.

I shouldn't comment on this, because
- it'll be off-topic, and
- (more importantly) personally I'm not knowledgeable enough to fix the 
problem,

but I feel compelled to point out that *in general* it's not about the 
various rights accompanying the bits (ie. proprietary / open source / 
free software). It's about who gets to allocate whose resources. Under 
this aspect it's irrelevant under what rights the end product will be 
released, the question is instead who backs the effort & costs of the 
end product being hammered into existence.

Users of FLOSS tend to mix up these two things ("what rights do I have 
to the code?" vs. "work on this for my sake!"). For the second concept, 
commercial relationships are (and have always been) the default, even if 
extremely forthcoming FLOSS developers used to evoke a different impression.

(To make it abundantly clear, this is not an advertisment, and I'm 
speaking *strictly* personally, for myself alone.)

Laszlo

Re: Time Change Issue Xen 4.1

[Niall Fleming]

[-- Attachment #1.1: Type: text/plain, Size: 2880 bytes --]

I wasn't expecting anyone to speed up and fix the issue, I just hoped 
that one or more of
people who were involved in the original ticket could respond to a 
request for an update,
I only asked for an update about once a week, even with busy schedules I 
would have
thought that that was possible.

I would look into the problem myself, but kernel hacking and hardcore 
XEN development is
not my thing, I did not intend to put anyone's back up about the issue. 
I'd love to fix the
problem myself, and am quite willing to test and debug stuff.

For reference the issue is not a massive deal-breaker for me, but it 
will be when the hardware
clock drifts next, particularly on the production machines which may 
have up to 100 instances
on, it becomes a massive ball-ache to down the server and reboot it just 
to get the instances to
boot with the correct time.

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 01/12/2011 10:28, Laszlo Ersek wrote:
> Hello Niall,
>
> On 12/01/11 10:53, Ian Campbell wrote:
>> On Thu, 2011-12-01 at 08:55 +0000, Niall Fleming wrote:
>>> Cheers, at least I know that someone is still looking at it!
>>>
>>> If someone could give me a general timeframe, like it'll be a month,
>>> before we fix it, or two weeks or whatever, I just need to give my
>>> line manager something so he gets off my case about it!
>>
>> I'm afraid OSS software doesn't generally work like that. If you (or
>> your boss) wants something fixed on a specific time scale or priority
>> you'll have to role your sleeves up and scratch the itch. Otherwise I'm
>> sorry but you will just have to wait until someone has the cycles to
>> look into this issue.
>
> I shouldn't comment on this, because
> - it'll be off-topic, and
> - (more importantly) personally I'm not knowledgeable enough to fix 
> the problem,
>
> but I feel compelled to point out that *in general* it's not about the 
> various rights accompanying the bits (ie. proprietary / open source / 
> free software). It's about who gets to allocate whose resources. Under 
> this aspect it's irrelevant under what rights the end product will be 
> released, the question is instead who backs the effort & costs of the 
> end product being hammered into existence.
>
> Users of FLOSS tend to mix up these two things ("what rights do I have 
> to the code?" vs. "work on this for my sake!"). For the second 
> concept, commercial relationships are (and have always been) the 
> default, even if extremely forthcoming FLOSS developers used to evoke 
> a different impression.
>
> (To make it abundantly clear, this is not an advertisment, and I'm 
> speaking *strictly* personally, for myself alone.)
>
> Laszlo

[-- Attachment #1.2: Type: text/html, Size: 4071 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel