Hi,
I'm using vanilla 2.6.32.7 domU kernel with Xen 3.2 and get very often a
unresponsible system after approximately one or two days with messages such as
[43616.674502] CE: xen increasing min_delta_ns to 16086592372704132408 nsec
[43616.674502] CE: xen increasing min_delta_ns to 5683144485346646996 nsec
[43616.674502] CE: xen increasing min_delta_ns to 17748088764874746302 nsec
[43616.674502] CE: xen increasing min_delta_ns to 17398761110457343644 nsec
[43616.674502] CE: xen increasing min_delta_ns to 7651397591976463850 nsec
[43616.674502] CE: xen increasing min_delta_ns to 2253724351109919966 nsec
[43616.674502] CE: xen increasing min_delta_ns to 3380586526664879948 nsec
[43616.674502] CE: xen increasing min_delta_ns to 5070879789997319922 nsec
[43616.674502] CE: xen increasing min_delta_ns to 7606319684995979882 nsec
[43616.674502] CE: xen increasing min_delta_ns to 11409479527493969822 nsec
[43616.674502] CE: xen increasing min_delta_ns to 17114219291240954732 nsec
on the console. I fail to login via ssh and even to cleanly shutdown this
system via xm <id> shutdown. sysrq requests still work.
I searched the net but found only messages with 15000 nsec. My values are a
little bit larger :-)) Found references to the kernel parameter notsc and
tried it but the problem remains.
The problem started once I upgraded the kernel from 2.6.26 to 2.6.32.7.
I changed from 32bit to 64bit but apart from this I did only a make oldconfig.
That's why I think it's not my config which causes trouble.
Any ideas? Is it a known problem?
PS: Please CC: me.
Jens
Hello,
CCing to xen-devel..
-- Pasi
On Mon, Feb 22, 2010 at 09:26:59AM +0100, Jens Seidel wrote:
> Hi,
>
> I'm using vanilla 2.6.32.7 domU kernel with Xen 3.2 and get very often a
> unresponsible system after approximately one or two days with messages such as
>
> [43616.674502] CE: xen increasing min_delta_ns to 16086592372704132408 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 5683144485346646996 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 17748088764874746302 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 17398761110457343644 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 7651397591976463850 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 2253724351109919966 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 3380586526664879948 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 5070879789997319922 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 7606319684995979882 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 11409479527493969822 nsec
> [43616.674502] CE: xen increasing min_delta_ns to 17114219291240954732 nsec
>
> on the console. I fail to login via ssh and even to cleanly shutdown this
> system via xm <id> shutdown. sysrq requests still work.
>
> I searched the net but found only messages with 15000 nsec. My values are a
> little bit larger :-)) Found references to the kernel parameter notsc and
> tried it but the problem remains.
>
> The problem started once I upgraded the kernel from 2.6.26 to 2.6.32.7.
> I changed from 32bit to 64bit but apart from this I did only a make oldconfig.
> That's why I think it's not my config which causes trouble.
>
> Any ideas? Is it a known problem?
>
> PS: Please CC: me.
>
On Thu, Feb 25, 2010 at 11:44:42PM +0200, Pasi K?rkk?inen wrote:
> CCing to xen-devel..
thanks Pasi ...
I have more information:
> On Mon, Feb 22, 2010 at 09:26:59AM +0100, Jens Seidel wrote:
> > I'm using vanilla 2.6.32.7 domU kernel with Xen 3.2 and get very often a
> > unresponsible system after approximately one or two days with messages such as
The problem seems to occur between 10h - 11.5h (verified three times).
Using the options "hpet=disable clocksource=jiffies nolapic acpi=off" the
problem vanished but I get a minor time drift between dom0 and domU (and
missed at least once my bus :-()
> > [43616.674502] CE: xen increasing min_delta_ns to 16086592372704132408 nsec
> >
> > on the console. I fail to login via ssh and even to cleanly shutdown this
> > system via xm <id> shutdown. sysrq requests still work.
Oops, forget about sysrq. Now I think it didn't worked.
> > PS: Please CC: me.
Jens