On Wed, Sep 5, 2012 at 10:05 AM, Tom Rondeau <t...@trondeau.com> wrote: > On Tue, Sep 4, 2012 at 9:01 PM, ikjtel <ikj12...@yahoo.com> wrote: >> >> >>> Yes, looks like it. But it's an Atom, which might change things. I >> >>> know we had some issues on Atom's before, but I thought that we worked >>> them out. I'll be interested to see how cmake reports the architecture >>> checks for VOLK here. >> >> Hi Tom >> >> I've made some further progress, and this may be premature, but I'll go so >> far as to say we can rule this out entirely. >> >> Here's a strawman theory - criticism of the theory is invited, shooting it >> down would be welcomed ; ) >> >> Our app uses lots of disconnect() and connect() calls because our appetite >> for widgets is bigger than the CPU available. Also, since the widgets are >> tab-selectable there is only one widget visible at a time. So when the user >> hits a tab we call disconnect and connect (surrounded by lock() / unlock() >> of course) in order to dynamically create a flow graph that connects up all >> the elements needed by that tab (and disconnects the elements, filters, >> demods, FFT's and other blocks that aren't needed by this tab, to conserve >> CPU. >> >> The theory is that this is "messing up" the boundary alignments of the >> operands to the SSE instructions, making them no longer properly aligned, >> resulting in a GPF. >> >> Here's the minimal python app , it seg faults in volk 100% reliably for me. >> If the call to shuffle() is removed, the script does not crash. >> >> Max > > Max, > > That's not a bad theory as I've run into the same situation before. I > had a fix for that, though, back before the release of 3.6.0. It's > possible that it's more complicated, though. I'll use your script to > see if I can do more to figure it out. > > Tom > > >> p.s. kindly let me know if this code isn't properly machine-readable >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> #!/usr/bin/env python >> import math >> import time >> from gnuradio import gr, gru, audio, eng_notation, blks2, optfir >> >> class app_top_block(gr.top_block): >> def __init__(self): >> gr.top_block.__init__(self, "mhp") >> >> self.source = gr.sig_source_f(48000, gr.GR_TRI_WAVE, 1.0, 1.0, 0) >> self.amp = gr.multiply_const_ff(65.0) >> self.sink = gr.null_sink(gr.sizeof_float) >> >> self.connect(self.source, self.amp, self.sink) >> self.amp_connected = True >> >> def shuffle(self): >> self.lock() >> if self.amp_connected: >> self.disconnect(self.source, self.amp, self.sink) >> self.connect(self.source, self.sink) >> else: >> self.disconnect(self.source, self.sink) >> self.connect(self.source, self.amp, self.sink) >> self.amp_connected = not self.amp_connected >> self.unlock() >> >> if __name__ == "__main__": >> tb = app_top_block() >> tb.start() >> while True: >> time.sleep(0.1) >> tb.shuffle() >>
Max, I believe I have fixed your problem. Check out the latest master branch (it's commit 77035b5d188be9e5dcd6731b1a58a4ce47451bde). I was using your demo code that you posted here as a test, and it's now working fine for me now. Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
