Magnus Hagander wrote:
On Monday 13 March 2006 12:27, Magnus Hagander wrote:
Great. That'll certainly help - now you don't have to wait for
binaries from me.
What I'd be interested in seeing is new stackdumps from a version
where
you:
1) Do *not* have the patch for mutexes applied
2) Have re
On Monday 13 March 2006 12:27, Magnus Hagander wrote:
> Great. That'll certainly help - now you don't have to wait for binaries
> from me.
>
> What I'd be interested in seeing is new stackdumps from a version where
> you:
> 1) Do *not* have the patch for mutexes applied
> 2) Have removed "static" f
> Do you have the ability to test 8.0 on the same machine? We did some
> extensive modifications to the signal stuff between 8.0 and 8.1, it'd be
> interesting to see if that changed things.
I had very similar behavior some weeks back on a machine that had not
been upgraded to 8.1. It was a dual
> On Monday 13 March 2006 12:27, Magnus Hagander wrote:
> > Great. That'll certainly help - now you don't have to wait for
> > binaries from me.
> >
> > What I'd be interested in seeing is new stackdumps from a version
> > where
> > you:
> > 1) Do *not* have the patch for mutexes applied
> > 2) H
> > > Looking a my system while testing this it still loooked
> like it was
> > > hanging on that plac ein the code, even though I saw no
> problems. So
> > > I'm not convinced we can actually trust the stacktrace from the
> > > non-default threads. So I don't think this patch will
> actually
On Monday 13 March 2006 09:26, Jan de Visser wrote:
> On Sunday 12 March 2006 09:40, Magnus Hagander wrote:
> > Looking a my system while testing this it still loooked like it was
> > hanging on that plac ein the code, even though I saw no problems. So I'm
> > not convinced we can actually trust th
On Sunday 12 March 2006 09:40, Magnus Hagander wrote:
> Looking a my system while testing this it still loooked like it was
> hanging on that plac ein the code, even though I saw no problems. So I'm
> not convinced we can actually trust the stacktrace from the non-default
> threads. So I don't thin
> > Ok, I've coded up a patch that changes the code to use a
> mutex instead.
>
> Are we asserting the problem is caused by the spinlock random
> wake-up order?
Not asserting, more making a wild guess. Which I, as I said, no lnoger
really beleive in - but since the patch was already coded up it
""Magnus Hagander"" <[EMAIL PROTECTED]> wrote
> Ok, I've coded up a patch that changes the code to use a mutex instead.
Are we asserting the problem is caused by the spinlock random wake-up order?
I am not sure why this would fix the problem. If my memory serves, a
critical section might be a pro
On Sunday 12 March 2006 09:40, Magnus Hagander wrote:
> > > If so,
> > > we could perhaps recode that part using a Mutex instead of
> >
> > a critical
> >
> > > section - since it's not a performance critical path, the
> >
> > difference
> >
> > > shouldn't be large. If I code up a patch for that,
> > If so,
> > we could perhaps recode that part using a Mutex instead of
> a critical
> > section - since it's not a performance critical path, the
> difference
> > shouldn't be large. If I code up a patch for that, can you re-apply
> > SP1 and test it? Or is this a production system you can'
11 matches
Mail list logo
