Playing with gr-gcell/src/qa_fft.py and seeing if it can be made to
handle more than one size=32 fft. If I simply double the input data so
it gets 2 chunks, I get a segmentation fault. Might this be the same
thing as the ‘make check’ on Fedora7 issue?
This works fine:
ph =
gcell.program_handle_from_filename("…/…/gcell/src/lib/spu/gcell_all")
opts = gcell.jm_options(ph, 1)
mgr = gcell.job_manager(opts)
gcell.set_singleton(mgr)
tb = gr.top_block()
fft_size = 32
src_data = tuple([complex(primes[2i], primes[2i+1]) for i in
range(fft_size)])
src = gr.vector_source_c(src_data)
s2v = gr.stream_to_vector(gr.sizeof_gr_complex, fft_size)
fft = gcell.fft_vcc(fft_size, True, [], False)
v2s = gr.vector_to_stream(gr.sizeof_gr_complex, fft_size)
dst = gr.vector_sink_c()
tb.connect(src, s2v, fft, v2s, dst)
tb.run()
result_data = dst.data()
and with a print statement in gcell_fft_vcc.cc to show the noutput_items
it shows 1 and runs fine. Changing to this:
src_data_1 = tuple([complex(primes[2i], primes[2i+1]) for i in
range(fft_size)])
src_data = src_data_1 + src_data_1
I get:
gcell_fft_vcc::work - noutput_items: 2
Segmentation fault
I’ll just upgrade to Fedora8 if that appears to be the problem, per
this:
FYI, I took a build tree compiled on Fedora 8, and was able to
"make
check" it OK on an FC7 PS3 and an F8 PS3. I haven't spent any
time
narrowing down the problem beyond this. Thus, it's not kernel
related. I also ran the inverse test: code compiled on an FC7
PS3
fails on FC7 and F8.
–Chuck