On Wed, 26 Mar 2008 15:57:32 -0500
Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Wed, 12 Mar 2008 18:47:45 -0700 (PDT)
> Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> > The only machine I have at home for testing powerpc is an Apple G5,
> > supplied to me by IBM. It says:
> > cpu :
On Wed, 12 Mar 2008 18:47:45 -0700 (PDT)
Roland McGrath <[EMAIL PROTECTED]> wrote:
> The only machine I have at home for testing powerpc is an Apple G5,
> supplied to me by IBM. It says:
> cpu : PPC970FX, altivec supported
> revision: 3.0 (pvr 003c 0300)
> so I am
On Fri, 2008-03-14 at 09:42 +0100, Segher Boessenkool wrote:
> > I saw no effect from that change. So now we're back to pure
> mystery,
> > I guess.
>
> Hey, we know something now: it's "just" a problem in the kernel :-)
We don't know that for sure. The DABR context switching code is trivial
e
> Since the 970 kernel never sets DABRX currently, #8 cannot explain
> _intermittent_ problems: either it always works, or never does.
Uh... could be the boot code setting it, the setting happening on LSU0
but not LSU1. No ?
Ben.
___
Linuxppc-dev mail
If this doesn't help, and the failures stay intermittent, I don't
think
there is a close-to-the-hardware problem here.
I saw no effect from that change. So now we're back to pure mystery,
I guess.
Hey, we know something now: it's "just" a problem in the kernel :-)
Segher
> In both these cases, the storage access goes to LSU0, so you're
> not hitting the errata.
I'll take your word for it.
> If this doesn't help, and the failures stay intermittent, I don't think
> there is a close-to-the-hardware problem here.
I saw no effect from that change. So now we're back
The pointer to the test case was given here before.
Oh, I missed that. Anyway, I wanted to see the asm, and who knows,
with different compiler versions and all that.
0x1984 : bl 0x10001750
0x1988 : lis r9,4097
---> 0x198c : stw r29,7792(r9)
> Since the 970 kernel never sets DABRX currently, #8 cannot explain
> _intermittent_ problems: either it always works, or never does.
That's kind of what I thought, but I couldn't make enough sense of
the #8 text to be very sure.
> You could be happening upon #5, if the non-triggering data break
AFAICT the DABRX register just has two global bits that enable paying
attention to the DABR register.
It has four bits:
01 match in user mode
02 match in supervisor mode
04 match in hypervisor mode
08 ignore translation field in DABR
If the k
On Wed, 2008-03-12 at 23:30 +0100, Jens Osterkamp wrote:
> > Just to make sure, i tested the binary against the 2.6.25-rc4 kernel. It
> > still fails. So this is really an open bug for PPC.
>
> On a Cell- or 970-based machine ?
>
> Gruß,
> Jens
On a 970-based machine.
Regards,
--
Luis M
AFAICT the DABRX register just has two global bits that enable paying
attention to the DABR register. It only needs to be set once at boot time
(as the cell code does). I don't see how missing that initialization could
ever have explained the behavior we see where DABR matches are intermittent.
I
> Just to make sure, i tested the binary against the 2.6.25-rc4 kernel. It
> still fails. So this is really an open bug for PPC.
On a Cell- or 970-based machine ?
Gruß,
Jens
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Hi,
> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> already did this. Uli Weigand found this back in November. I submitted
> a patch for this which went into 2.6.25-rc4.
> Can you please try again with rc4 ?
> Gruß,
>
> Jens
Just to make sure, i tested the binary against
On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
already did this. Uli Weigand found this back in November. I submitted
a patch for this which went into 2.6.25-rc4.
Can you please try again with rc4 ?
This is not the problem. This came up before and everyone seems have
forgot
The G5 that I have says:
cpu : PPC970FX, altivec supported
revision: 3.0 (pvr 003c 0300)
and it does indeed reproduce this bug.
It also strange for it to be the DABRX issue given the failure mode.
That is, it works sometimes but unreliably (as if the context s
On Mon, Mar 10, 2008 at 04:36:37PM -0300, Luis Machado wrote:
> On Mon, 2008-03-10 at 12:19 -0700, Roland McGrath wrote:
> > > On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> > > already did this. Uli Weigand found this back in November. I submitted
> > > a patch for this whic
On Mon, 2008-03-10 at 12:19 -0700, Roland McGrath wrote:
> > On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> > already did this. Uli Weigand found this back in November. I submitted
> > a patch for this which went into 2.6.25-rc4.
> > Can you please try again with rc4 ?
>
> T
> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> already did this. Uli Weigand found this back in November. I submitted
> a patch for this which went into 2.6.25-rc4.
> Can you please try again with rc4 ?
This is not the problem. This came up before and everyone seems have
> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> already did this. Uli Weigand found this back in November. I submitted
> a patch for this which went into 2.6.25-rc4.
> Can you please try again with rc4 ?
I will try it and will post the results back.
Thanks Jens.
Regards,
On Monday 10 March 2008, Luis Machado wrote:
> > Yes, I know. I tried it on the PS3 first and couldn't reproduce
> > the bug he saw on the blade.
>
> Arnd,
>
> Do we have any news on this topic?
>
> I've seen this happening quite often within GDB when using hardware
> watchpoints on a shared va
> Yes, I know. I tried it on the PS3 first and couldn't reproduce
> the bug he saw on the blade.
Arnd,
Do we have any news on this topic?
I've seen this happening quite often within GDB when using hardware
watchpoints on a shared variable in a threaded (7+ threads) binary.
Sometimes the watchpo
On Wednesday 28 November 2007 23:59:36 Geoff Levand wrote:
> > This sounds like a bug recently reported by Uli Weigand. BenH
> > said he'd take a look, but it probably fell under the table.
> > The problem found by Uli is that on certain processors (Cell/B.E.
> > in his case), the DABRX register ne
Arnd Bergmann wrote:
> On Monday 26 November 2007, Jan Kratochvil wrote:
>> Hi,
>>
>> this testcase:
>> http://people.redhat.com/jkratoch/dabr-lost.c
>>
>> reproduces a PPC DABR kernel bug. The variable `variable' should not get
>> modified as the thread modifying it should be caught by
On Wed, 28 Nov 2007 13:28:48 +0100, Arnd Bergmann wrote:
> On Wednesday 28 November 2007, Jan Kratochvil wrote:
> > Please be aware DABR works fine if the same code runs just 1 (always) or
> > 2 (sometimes) threads. It starts failing with too many threads running:
> >
> > $ ./dabr-lost
> > TID 32
On Wednesday 28 November 2007, Jan Kratochvil wrote:
> Please be aware DABR works fine if the same code runs just 1 (always) or
> 2 (sometimes) threads. It starts failing with too many threads running:
>
> $ ./dabr-lost
> TID 32725: DABR 0x1001279f NIP 0xfecf41c
> TID 32726: DABR 0x1001279f NIP 0
On Tue, 27 Nov 2007 23:35:36 +0100, Arnd Bergmann wrote:
> On Monday 26 November 2007, Jan Kratochvil wrote:
> > Hi,
> >
> > this testcase:
> > http://people.redhat.com/jkratoch/dabr-lost.c
> >
> > reproduces a PPC DABR kernel bug. The variable `variable' should not get
> > modified as t
On Monday 26 November 2007, Jan Kratochvil wrote:
> Hi,
>
> this testcase:
> http://people.redhat.com/jkratoch/dabr-lost.c
>
> reproduces a PPC DABR kernel bug. The variable `variable' should not get
> modified as the thread modifying it should be caught by its DABR:
>
> $ ./dabr-lost
>
Hi,
this testcase:
http://people.redhat.com/jkratoch/dabr-lost.c
reproduces a PPC DABR kernel bug. The variable `variable' should not get
modified as the thread modifying it should be caught by its DABR:
$ ./dabr-lost
TID 30914: DABR 0x10012a77 NIP 0x80f6ebb318
TID 30915: DABR 0x10012a7
28 matches
Mail list logo
