Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On 32bit systems VOLK crashes #2

Closed
BogdanDIA opened this issue Jan 22, 2014 · 5 comments
Closed

On 32bit systems VOLK crashes #2

BogdanDIA opened this issue Jan 22, 2014 · 5 comments

Comments

@BogdanDIA
Copy link
Owner

At least in ofdm_sym_acquisition_impl.cc with VOLK enabled the gr-dvbt crashes on 32bit systems.

@drmpeg
Copy link

drmpeg commented Jan 23, 2014

The function is_unaligned() doesn't really work as expected (at least on 32-bit systems). It returns False even when the address of one or more parameters is unaligned.

If all the volk functions in ofdm_sym_acquisition_impl.cc and dvbt_demap_impl.cc are forced to be unaligned, there are no GPF's and the flow works perfectly.

@BogdanDIA
Copy link
Owner Author

It seem that the alignement need to be taken form volk and set in each block like this:

const int alignment_multiple =
volk_get_alignment() / sizeof(gr_complex);
set_alignment(std::max(1, alignment_multiple));

Also for locally allocated buffers I modified the allocation method from new (c++) to posix_memalign()

The changes are in the latest github commits.

@drmpeg
Copy link

drmpeg commented Jan 25, 2014

I can see why you abandoned 32-bit Linux and went to 64-bit. The alignment issues seem quite painful. After testing the new commits, it appears that posix_memalign() is buggy on 32-bit systems. It's causing segfaults and errors in unrelated modules. Here's what I've seen:

[Fri Jan 24 16:29:22 2014] python2[31620]: segfault at 43289bd0 ip b1af6a90 sp bfea11b0 error 4 in libglib-2.0.so.0.3600.0[b1a80000+ff000]

[Fri Jan 24 16:37:19 2014] python2[32631]: segfault at 426dd030 ip b1a62984 sp bf819290 error 4 in libpango-1.0.so.0.3200.5[b1a46000+49000]

and "bad_weak_ptr error" in GRC. Reverting back to the "new" allocation eliminates these issues.

At this point, I'd have to say that you should not waste any more effort on these issues. I'll just make a local patch to force unaligned volk calls.

@BogdanDIA
Copy link
Owner Author

Ok, I have now a 32bit machine to see what's going on. VOLK is working fine but the alignment is guaranteed only for out/in buffers. If a buffer is aligned and then one plays with the start of the buffer then it become unaligned. Probably a redesign to make sure ANY buffer passed to VOLK is aligned is necessary.
For now the unaligned functions are used so the flow should not crash.

BogdanDIA added a commit that referenced this issue Jan 31, 2014
…ceback for SSE2 viterbi. #3 Cleaned-up the implementation
BogdanDIA added a commit that referenced this issue Jan 31, 2014
…ceback for SSE2 viterbi. #3 Cleaned-up the implementation
@BogdanDIA
Copy link
Owner Author

Closing this issue as it is fixed for my machines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants