On Mon, Mar 19, 2012 at 4:49 PM, Frederick Stevens
[email protected]wrote:
Tom,
New run using my simple “trace” See attached files.
Cheers,
Fred
Fred,
A good start. It’s only going through half of the data it’s supposed
before
seg faulting, so it’s like one of the buffers (probably the bPtr buffer
to
the 32f input) isn’t getting allocated properly.
I’ve attached a patch that only tests this kernel so no other outputs
will
confuse things and I’ve shortened the run length (single iteration,
fewer
samples). This now spits out the data used to generate the input and
output
buffers. It also outputs the size of the data types in the test instead
of
the pointer size.
if you’re unfamiliar with working with patches, just reset your git tree
(git reset --hard, unless you have some changes you need to / want to
keep)
and apply this (git apply location/volk_slackware32.diff). I suggest the
reset so there aren’t any conflicts or problems when applying.
Thanks,
Tom
Tom,
Thanks for the patch. I’ve applied it and will test and send more
output for you to examine. By the way, thank you for taking a look at
this. I am thankful for this project in the first place and appreciate
all of the work that goes into FOSS software. Hopefully this issue can
be resolved. I still need to test this on my other system but finding
work is a priority right now.
Got this error when applying the patch. I will try it manually (patch
-pX < …/location_to_diff sort of thing) and see what happens.
git apply …/volk_slackware32.diff
…/volk_slackware32.diff:13: trailing whitespace.
/*
warning: 1 line adds whitespace errors.
Cheers,
Fred
On Tue, Mar 20, 2012 at 10:39 AM, Frederick Stevens
[email protected]wrote:
generic completed in 0.02s
offset 21 in1: 0.379793 in2: 0.187764
Fred
Fred,
Thanks. Can you get the entire output (in a text file)? There’s some
information that’s printed at the top that’s important. Just run it from
the command-line and pipe (>) the output into a file.
Oh, and that trailing whitespace warning shouldn’t be a problem. The
patch
should have still be applied.
Thanks,
Tom
On 03/20/2012 10:42 AM, Tom R. wrote:
Fred,
Thanks. Can you get the entire output (in a text file)? There’s some
information that’s printed at the top that’s important. Just run it
from the command-line and pipe (>) the output into a file.
Just because I’m a grumpy old Unix guy from waaaaay back, I’ll point out
that the term “pipe” is very frequently mis-used to mean
“redirect”, when in fact, the pipe symbol in the Unix shell is “|”
and is a mechanism for attaching the standard output of one program
to the standard input of another. The “>” symbol means “redirect
the standard output to a file”, which is similar, but not the same as,
the use of a “pipe”, which is an IPC mechanism.
Tom, et. al.
Here is the output from the volk_profile run (see attached).
Cheers,
Fred
On Tue, Mar 20, 2012 at 11:03 AM, Frederick Stevens
[email protected]wrote:
Tom, et. al.
Here is the output from the volk_profile run (see attached).
Cheers,
Fred
Well, Fred, that output looks good. Everything’s showing up as it
should.
Interesting that it passed this time, but I half expected it to. It
seems
like there’s a memory allocation problem going on, since when it
crashes,
it did so just a bit after getting half way through, must have been when
it
hit something else allocated. Very odd behavior that I’ve seen on
occasion,
but they way the memory is allocated in the volk_qa_aligned_mem_pool, I
wouldn’t expect there to be a problem.
Right now, I’m at a loss on how to proceed. I can’t think of any more
really useful tests. Were I able to reproduce this error on one of my
machines, I’d just have to start tinkering around and getting more
output
data.
Tom
Tom,
Output from volk_profile with your patch applied:
8 4 8 2040
8 4 8 2041
8 4 8 2042
8 4 8 2043
8 4 8 2044
8 4 8 2045
generic completed in 0.02s
orc completed in 0s
offset 4 in1: 0.248167 in2: -0.655651
offset 6 in1: 0.277863 in2: -0.115331
offset 8 in1: 0.41971 in2: -0.133972
offset 10 in1: 0.0165064 in2: 0.0119338
offset 12 in1: 0.15143 in2: 0.228013
offset 16 in1: 0.131675 in2: -0.256315
offset 17 in1: 0.210833 in2: -0.410402
offset 18 in1: 0.499083 in2: -0.0775119
offset 20 in1: 0.714493 in2: 0.353234
offset 21 in1: 0.379793 in2: 0.187764
volk_32fc_32f_multiply_32fc_a: fail on arch orc
Best arch: orc
filename: /home/fred/.volk/volk_config
Program exited normally.
(gdb)
Cheers,
Fred
On Tue, Mar 20, 2012 at 10:59 AM, Tom R. [email protected] wrote:
really useful tests. Were I able to reproduce this error on one of my
machines, I’d just have to start tinkering around and getting more output
data.
If volk_qa_aligned_mem_pool were passed the wrong “type” argument due to
a
parser error, it could allocate half the required memory. But I’d expect
to
see significantly more catastrophic failures across many more machines &
tests if this were the case.
–n
On Tue, Mar 20, 2012 at 2:24 PM, Nick F. [email protected] wrote:
–n
Yes, the output info I asked Fred to produce was to test for exactly
that
problem, but it’s setting the correct type signature for all inputs and
outputs, so that’s not it. It looks like it’s allocating the right
amount
of memory and nothing suggests that it’s not (except for the segfault,
that
is).
Tom
Tom
Ton & Nick,
Let me try this on the other AMD 32 bit machine. This is a Tyan S2460
dual processor AMD motherboard which has it’s own quirks and has a
tendency to not like some things. I have it running fairly well without
linux kernel oops and such. I will also check my syslogs and dmesg for
more info. If things run fine without the patch on the other AMD
machine then I will consider it a specific motherboard issue and not
worry about it.
Cheers,
Fred
Tom,
See dmesg text below:
[53882.751765] volk_profile[30672]: segfault at b7191000 ip b76acb74 sp
bfddc894 error 4 in libvolk.so.0.0.0[b768b000+ec000]
I’m thinking that this is a linux kernel/hardware issue. I am going to
do some more testing on different hardware but same processor and
Slackware version, etc.
Cheers,
Fred
My technical observation:
UGH
On Tue, Mar 20, 2012 at 11:16 PM, Frederick Stevens