On Mon, Oct 27, 2008 at 4:38 PM, Jesse Chappell <[EMAIL PROTECTED]> wrote:
> For the records, here is the output from a dual IBM Cell system
> (QS-21), each PowerPC unit is exposed with two cores.
This is actually a QS-20, sorry.
jlc
___
Linux-audio-dev
For the records, here is the output from a dual IBM Cell system
(QS-21), each PowerPC unit is exposed with two cores.
jlc
$ cat /proc/cpuinfo
processor : 0
cpu : Cell Broadband Engine, altivec supported
clock : 3200.00MHz
revision: 5.1 (pvr 0070 0501)
pro
Sean Bolton wrote:
> On Oct 20, 2008, at 3:18 PM, Olivier Guilyardi wrote:
>> What about the test-int-array-* family of tests on PPC?
>
> They all pass on my uniprocessor G4, but that doesn't
> really tell us much. Anybody got a multiprocessor PPC?
I think it might be worth to try the following
On Oct 20, 2008, at 3:18 PM, Olivier Guilyardi wrote:
> What about the test-int-array-* family of tests on PPC?
They all pass on my uniprocessor G4, but that doesn't
really tell us much. Anybody got a multiprocessor PPC?
This stuff makes my head hurt, too, but as best I can
figure out, I believe
Olivier Guilyardi a écrit :
> Hi,
>
> Pieter Palmers a écrit :
>> Sean Bolton wrote:
>>>
test-bit-circle-jack - starting (5s max) - buffer size: 512
|| FAILURE: 2 != 514
>>>
>>> I thought it suspicious that 514 = 2 + 2 * 256, while on a PPC it
>>> returns
>>> FAILURE: 2 != 0. Endianne
Hi,
Pieter Palmers a écrit :
> Sean Bolton wrote:
>>
>>> test-bit-circle-jack - starting (5s max) - buffer size: 512
>>> || FAILURE: 2 != 514
>>
>> I thought it suspicious that 514 = 2 + 2 * 256, while on a PPC it
>> returns
>> FAILURE: 2 != 0. Endianness bug? No, but it's a clue...
Do you hav
Sean Bolton wrote:
> Hi Olivier,
>
> On Oct 20, 2008, at 6:13 AM, Olivier Guilyardi wrote:
>> Until now, I just couldn't write a test that fail because of the
>> lack of memory
>> barrier on x86. However, I think I found another bug in Jack
>> ringbuffer, by
>> writing another test.
>>
>> It's
Hi Olivier,
On Oct 20, 2008, at 6:13 AM, Olivier Guilyardi wrote:
> Until now, I just couldn't write a test that fail because of the
> lack of memory
> barrier on x86. However, I think I found another bug in Jack
> ringbuffer, by
> writing another test.
>
> It's a bit of a weird test, I call i
Jack O'Quin wrote:
> On Sun, Oct 19, 2008 at 2:55 AM, Paul Davis <[EMAIL PROTECTED]> wrote:
>
>> i don't know whether to shoot myself or eat another couple of the
>> oft-promised hats.
>
> Don't beat yourself up too badly. Multiple threads accessing shared memory
> is *very* tricky. Even smart
On Sun, Oct 19, 2008 at 1:08 PM, Fons Adriaensen <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 19, 2008 at 12:36:55PM -0400, Paul Coccoli wrote:
>
>> The only time you can get away without atomic ops is on uni-processor.
>> Please cite a reference that says otherwise.
>
> Plaese show us how using a non
On Sun, Oct 19, 2008 at 12:36:55PM -0400, Paul Coccoli wrote:
> The only time you can get away without atomic ops is on uni-processor.
> Please cite a reference that says otherwise.
Plaese show us how using a non-atomic addition could go wrong.
> Notice that all the fixes proposed all involve r
On Sun, Oct 19, 2008 at 12:24 AM, Jack O'Quin <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 18, 2008 at 10:45 PM, Paul Coccoli <[EMAIL PROTECTED]> wrote:
>> On Sat, Oct 18, 2008 at 11:29 PM, Jack O'Quin <[EMAIL PROTECTED]> wrote:
>>> This is wrong. For the single reader, single writer case, atomic oper
On Sun, Oct 19, 2008 at 2:55 AM, Paul Davis <[EMAIL PROTECTED]> wrote:
> i don't know whether to shoot myself or eat another couple of the
> oft-promised hats.
Don't beat yourself up too badly. Multiple threads accessing shared memory
is *very* tricky. Even smart people (like you) get it wrong
On Sun, Oct 19, 2008 at 09:55:54AM +0200, Paul Davis wrote:
>1) fons' design, which never actually wraps readptr or writeptr, but
> masks the address used to access the data buffer
>
>2) removing the intermediate state's visibility
>
> i admit to preferring (2) even though i know t
On Sun, 2008-10-19 at 09:55 +0200, Paul Davis wrote:
> i am deeply embarrassed but also puzzled.
maybe i don't need to eat any hats except for the "paying insufficient
attention" one. the jack ringbuffer code was ported from my original C++
implementation, which specifically does not have the pro
On Sat, 2008-10-18 at 23:24 -0500, Jack O'Quin wrote:
> If the amount read or written exactly fills the buffer, then a read or write
> pointer equal to the last entry plus one will be stored momentarily, before
> the correct (masked) value wraps it back to the beginning of the buffer. If
> the ot
On Sat, Oct 18, 2008 at 10:45 PM, Paul Coccoli <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 18, 2008 at 11:29 PM, Jack O'Quin <[EMAIL PROTECTED]> wrote:
>> This is wrong. For the single reader, single writer case, atomic operations
>> are *not* necessary. The bug, as was already pointed out, is due t
On Sat, Oct 18, 2008 at 11:29 PM, Jack O'Quin <[EMAIL PROTECTED]> wrote:
> This is wrong. For the single reader, single writer case, atomic operations
> are *not* necessary. The bug, as was already pointed out, is due to storing
Let's agree to disagree, then. Single-reader, single-writer does n
On Sat, Oct 18, 2008 at 10:22 PM, Paul Coccoli <[EMAIL PROTECTED]> wrote:
> [Switched from LAU to LAD]
>
> Forget I said anything about context switches. Those don't matter.
> The concern here is SMP systems. The bug in the original code is +=
> operator used to increment the read and write poin
On Sat, Oct 18, 2008 at 5:30 PM, Fons Adriaensen <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 18, 2008 at 10:56:31PM +0200, Paul Davis wrote:
>
>> if read_ptr > size then the math should result in the write space being
>> *under* estimated. if thats not happening then my worst nightmares come
>> true,
Olivier Guilyardi wrote:
> Here's how to run the test:
>
> svn co http://svn.samalyse.com/misc/rbtest
> cd rbtest
> make test
on a pentium-m 32bit notebook:
[EMAIL PROTECTED]:/local/rbtest> make test
gcc -Wall -I. -I./jack -lpthread -o test-int-array-jack \
test-int-array.c jac
Olivier Guilyardi wrote:
> To figure whether memory barriers are needed or not, we need to run the test
> on
> various architectures.
>
> For this purpose, I've set up a small svn repo with everything to run the test
> easily. There's no dependency, you just need pthread, gcc and sh.
>
> Here's
22 matches
Mail list logo
