On Thursday 14 February 2008, Thomas Gleixner wrote:
> futex_lock_pi is called with an absolute timeout, which is based on
> CLOCK_REALTIME. Nothing wrong with that, but the clockevents WARN_ON
> might trap over a false positive, when the expiry value is less than
> base->offset. This was
On Thursday 14 February 2008, Thomas Gleixner wrote:
futex_lock_pi is called with an absolute timeout, which is based on
CLOCK_REALTIME. Nothing wrong with that, but the clockevents WARN_ON
might trap over a false positive, when the expiry value is less than
base-offset. This was intentional
On Wed, 13 Feb 2008, Frans Pop wrote:
> On Wednesday 13 February 2008, Thomas Gleixner wrote:
> > can you please apply the following patch ? I really should have
> > thought about that, when I fixed the above one.
>
> I still get the bug with this patch. At least I'm now certain it happens
>
On Wednesday 13 February 2008, Thomas Gleixner wrote:
> can you please apply the following patch ? I really should have
> thought about that, when I fixed the above one.
I still get the bug with this patch. At least I'm now certain it happens
during glibc compilation and that I can reproduce it.
On Wed, 13 Feb 2008, Frans Pop wrote:
> On Wednesday 13 February 2008, Thomas Gleixner wrote:
> > On Tue, 12 Feb 2008, Andrew Morton wrote:
> > > On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop <[EMAIL PROTECTED]> wrote:
> > > the hrtimer code is preparing an invalid ktime_t. Note that
> > >
On Wednesday 13 February 2008, Thomas Gleixner wrote:
> On Tue, 12 Feb 2008, Andrew Morton wrote:
> > On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop <[EMAIL PROTECTED]> wrote:
> > the hrtimer code is preparing an invalid ktime_t. Note that
> > clockevents_program_event() actually fails when this
On Tue, 12 Feb 2008, Andrew Morton wrote:
> On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop <[EMAIL PROTECTED]> wrote:
> the hrtimer code is preparing an invalid ktime_t. Note that
> clockevents_program_event() actually fails when this happens - I am
> surprised that this is not causing observeable
On Tue, 12 Feb 2008, Andrew Morton wrote:
On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop [EMAIL PROTECTED] wrote:
the hrtimer code is preparing an invalid ktime_t. Note that
clockevents_program_event() actually fails when this happens - I am
surprised that this is not causing observeable
On Wednesday 13 February 2008, Thomas Gleixner wrote:
On Tue, 12 Feb 2008, Andrew Morton wrote:
On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop [EMAIL PROTECTED] wrote:
the hrtimer code is preparing an invalid ktime_t. Note that
clockevents_program_event() actually fails when this happens - I
On Wed, 13 Feb 2008, Frans Pop wrote:
On Wednesday 13 February 2008, Thomas Gleixner wrote:
On Tue, 12 Feb 2008, Andrew Morton wrote:
On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop [EMAIL PROTECTED] wrote:
the hrtimer code is preparing an invalid ktime_t. Note that
On Wednesday 13 February 2008, Thomas Gleixner wrote:
can you please apply the following patch ? I really should have
thought about that, when I fixed the above one.
I still get the bug with this patch. At least I'm now certain it happens
during glibc compilation and that I can reproduce it.
On Wed, 13 Feb 2008, Frans Pop wrote:
On Wednesday 13 February 2008, Thomas Gleixner wrote:
can you please apply the following patch ? I really should have
thought about that, when I fixed the above one.
I still get the bug with this patch. At least I'm now certain it happens
during
On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop <[EMAIL PROTECTED]> wrote:
> Kernel: vanilla 2.6.24 x86_64 SMP
> Environment: Debian unstable
> Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core)
>
> I've been running this kernel without problems since its release, but
> yesterday evening I
On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop [EMAIL PROTECTED] wrote:
Kernel: vanilla 2.6.24 x86_64 SMP
Environment: Debian unstable
Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core)
I've been running this kernel without problems since its release, but
yesterday evening I suddenly
On Sunday 10 February 2008, Frans Pop wrote:
> I have no idea yet what triggers it and am unsure if I'll be able to
> reproduce.
I think I know at least _when_ it happens: during compilation of glibc.
This was almost certainly while compiling in the normal amd64 environment:
> Pid: 2210, comm:
Kernel: vanilla 2.6.24 x86_64 SMP
Environment: Debian unstable
Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core)
I've been running this kernel without problems since its release, but
yesterday evening I suddenly got the following error, and this afternoon it
was repeated (below). The
Kernel: vanilla 2.6.24 x86_64 SMP
Environment: Debian unstable
Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core)
I've been running this kernel without problems since its release, but
yesterday evening I suddenly got the following error, and this afternoon it
was repeated (below). The
On Sunday 10 February 2008, Frans Pop wrote:
I have no idea yet what triggers it and am unsure if I'll be able to
reproduce.
I think I know at least _when_ it happens: during compilation of glibc.
This was almost certainly while compiling in the normal amd64 environment:
Pid: 2210, comm:
18 matches
Mail list logo
