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
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
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
enough...
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 to
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
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 Machado
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
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
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 child_thread+52: bl 0x10001750 sleep
0x1988 child_thread+56: lis r9,4097
---
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 the
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.
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 variable in
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 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 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 ?
This is
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 which went
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
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
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
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
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 32725: DABR
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 its DABR:
$
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 needs to
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
TID
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
25 matches
Mail list logo
