On 24 Apr 2008, Jeff Dike uttered the following:
> OK, yell if it starts happening again...
I tempted fate, and lo, it happens within the hour...
(gdb) bt
#0 0x08083e3a in getnstimeofday ()
I will now do what I should have done long since and turn on frame
pointers and debugging info so I can g
On Thu, Apr 24, 2008 at 08:57:54PM +0100, Nix wrote:
> On 16 Apr 2008, [EMAIL PROTECTED] stated:
> > This *is* a change in behaviour: the backtrace is different! Yay! :)
>
> I upgraded the guest to 2.6.25 a week ago and it stopped happening.
> There is hope. (Mind you it's stopped going wrong for
On 16 Apr 2008, [EMAIL PROTECTED] stated:
> This *is* a change in behaviour: the backtrace is different! Yay! :)
I upgraded the guest to 2.6.25 a week ago and it stopped happening.
There is hope. (Mind you it's stopped going wrong for week-long periods
before...)
--
`If you are having a "ua lue
On 15 Apr 2008, [EMAIL PROTECTED] said:
> OK, trying that. (I'll extend the instrumentation patch to watch for
> zero cycle_interval as well, and see what happens. With luck nothing
> will happen except that the crashes will stop... except that they
> already *have* stopped for me. Annoying.)
Hard
On Tue, Apr 15, 2008 at 12:47 PM, Nix <[EMAIL PROTECTED]> wrote:
> > The problem is NTP adjusting the multiplier part of the clock-provided
> > cycles-to-ns conversion function. UML pretended to have a ns clock,
> > with a multiplier of 1. When NTP adjusted that down in order to slow
> > down
On 14 Apr 2008, Jeff Dike spake thusly:
> Below is another patch for you to try. I spent most of last week
> chasing this one. The symptoms are somewhat similar to yours -
> intermittent UML hangs, although not with UML spinning, and it still
> pings.
Having not quite the same symptoms is intere
On Sat, Apr 05, 2008 at 05:45:39PM +0100, Nix wrote:
> The fixed timer patch you posted a few weeks back has indeed fixed my
> select()-based timeout woes.
>
> Unfortunately, both with the old kludgy approach and with the new
> remain-versus-max estimator code, I see intermittent tight lockups of
The fixed timer patch you posted a few weeks back has indeed fixed my
select()-based timeout woes.
Unfortunately, both with the old kludgy approach and with the new
remain-versus-max estimator code, I see intermittent tight lockups of
the UML kernel-space ptrace thread, with that thread chewing al
