After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760834 - orc Illegal Instructions on mips32el
orc Illegal Instructions on mips32el
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: orc
unspecified
Other Linux
: Normal critical
: 0.4.29
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-01-19 13:47 UTC by Andreas Frisch
Modified: 2018-04-22 19:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch1 (3.48 KB, patch)
2018-04-06 15:16 UTC, James Cowgill
none Details | Review
patch2 (900 bytes, patch)
2018-04-06 15:16 UTC, James Cowgill
committed Details | Review
patch3 (5.39 KB, patch)
2018-04-06 15:16 UTC, James Cowgill
none Details | Review
patch1 v2 (3.45 KB, patch)
2018-04-19 15:41 UTC, James Cowgill
committed Details | Review
patch3 v2 (5.37 KB, patch)
2018-04-19 15:42 UTC, James Cowgill
committed Details | Review

Description Andreas Frisch 2016-01-19 13:47:04 UTC
on our mips set-top-box with Linux 3.4-3.5 and orc 0.4.24, gstreamer 1.0 plugins that involve orc accelerated code, will fail to run with Illegal Instruction errors, for example vorbis playback.

i know ORC_CODE=backup can be used a workaround
Comment 1 Tim-Philipp Müller 2016-01-21 18:11:18 UTC
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
Comment 2 Andreas Frisch 2016-01-22 08:11:10 UTC
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
Comment 3 okitain 2018-04-03 11:14:09 UTC
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.
Comment 4 James Cowgill 2018-04-06 15:16:08 UTC
Created attachment 370593 [details] [review]
patch1
Comment 5 James Cowgill 2018-04-06 15:16:24 UTC
Created attachment 370595 [details] [review]
patch2
Comment 6 James Cowgill 2018-04-06 15:16:52 UTC
Created attachment 370598 [details] [review]
patch3

I think these patches will fix this bug.
Comment 7 Tim-Philipp Müller 2018-04-09 11:59:02 UTC
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 8 Tim-Philipp Müller 2018-04-09 12:27:15 UTC
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 9 Tim-Philipp Müller 2018-04-09 12:50:31 UTC
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.
Comment 10 James Cowgill 2018-04-10 15:22:37 UTC
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.
Comment 11 James Cowgill 2018-04-19 15:41:22 UTC
Created attachment 371135 [details] [review]
patch1 v2
Comment 12 James Cowgill 2018-04-19 15:42:23 UTC
Created attachment 371136 [details] [review]
patch3 v2

Here are some revised patches which hopefully address your comments.
Comment 13 Tim-Philipp Müller 2018-04-22 19:25:56 UTC
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