Could you run 'orc-bugreport' and see what it shows/outputs?

If you're using bleeding edge GStreamer, then you might also have run into this:

commit 3674742957efcd217344f9a114551f02f60265f8
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Thu Jan 21 16:08:46 2016 +0100

    audio-converter: ensure correct alignment of samples
    
    Make sure that the data we allocate for our temporary buffers is
    properly aligned.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=760938

Dear Tim,

it's not git gstreamer, i'm working with ye good olde 1.6.0 / 1.6.2 
also, I doubt it's an audio converter bug because i've observed the illegal instructions in other cases where orc acceleration would have been used, like subtitle blending.

root@dm7080:~# orc-bugreport 
Orc 0.4.23 - integrated testing tool
Active backend: mips
L1 cache: 0
L2 cache: 0
L3 cache: 0
Family/Model/Stepping: 0/0/0
CPU name: unknown
Compiler options: 
Opcode test:
Illegal instruction

I can confirm this bug, on 4.1.x Linux on MIPSel32r5 (MIPS P5600) on Debian.

I'm using orc 0.4.26.

The orc-bugreport utility crashes in the same way.
My GDB stops at this instruction:
0x77fb42f8      addu.qb        t6,t6,t7

It seems that the problem is that liborc generates those instructions without actually checking if they are available at runtime, which is a problem in a binary distro.

Created attachment 370593 [details] [review]
patch1

Created attachment 370595 [details] [review]
patch2

Created attachment 370598 [details] [review]
patch3

I think these patches will fix this bug.

Comment on attachment 370595 [details] [review]
patch2

commit 07026694253fbc0f2b51e4b7b5b4a198f92e3fdf
Author: James Cowgill <jcowgill@debian.org>
Date:   Fri Apr 6 15:38:54 2018 +0100

    meson: fix mips cpu_family test
    
    The cpu family "mipsel" does not exist in meson so the current test to
    enable the HAVE_MIPSEL macro is always false. The real cpu family is
    "mips" but this also matches big endian platforms so also check that the
    endian is little.
    
    https://bugzilla.gnome.org/attachment.cgi?id=370595

Comment on attachment 370593 [details] [review]
patch1

Thanks for the patches!

This one is generally fine, just some small nitpicks:

 - unistd.h include should be guarded with HAVE_UNISTD_H

 - I think get_file() should be called get_proc_cpuinfo() as before, since it only reads at most 4095 bytes, so let's leave it specific until someone needs a more general get_file() ?

 - should we only build the get_file/get_proc_cpuinfo function if actually needed? (HAVE_ARM or HAVE_MIPSEL) - thinking about open/read on windows build.

I can make these changes as well if you agree.

(There's some ugliness about having internal helper API in the public orcutils.h header, but will fix that independently.)

Comment on attachment 370598 [details] [review]
patch3

Looks fine at first glance, and it fixes this bug on a Creator CI-20 board at least.

Thanks for the review. I agree with all your points, so if you want to make the nessesary changes then feel free to do so. Otherwise I'll try and sort them over the next few days.

Created attachment 371135 [details] [review]
patch1 v2

Created attachment 371136 [details] [review]
patch3 v2

Here are some revised patches which hopefully address your comments.

Thanks!

commit d5be86cc73304689712ad920877e152fb7a2460a
Author: James Cowgill <jcowgill@debian.org>
Date:   Fri Apr 6 15:26:43 2018 +0100

    orcmips: only enable if the DSPr2 ASE is present
    
    The mips target uses various instructions that a part of the MIPS DSPr2
    ASE which is not present on all processors. The easiest solution is to
    gate the target on the presense of DSPr2 at runtime.
    
    Unfortunately there isn't a "nice" way to detect if DSPr2 is present, so
    resort to parsing /proc/cpuinfo to get the information.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=760834

commit 88371bf16bfbdcd235140c882578a2883002fbe0
Author: James Cowgill <jcowgill@debian.org>
Date:   Fri Apr 6 15:24:47 2018 +0100

    orcutils: refactor /proc/cpuinfo reading code from orccpu-arm.c
    
    This code will later be used by mips target, so it makes sense
    to use a common function instead of duplicating the code.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=760834