Bugzilla Bug 129022

Hi,

the mp4live tool crashes at startup with the following message:

localhost bin # mp4live
15:34:29.839-mp4live-3: type 0 usb type 0
15:34:29.886-mp4live-3: mp4live version 1.4.1 V4L2
Illegal instruction

GDB Stacktrace says:
(gdb) run
Starting program: /home/emanuel/temp/bin/mp4live
[Thread debugging using libthread_db enabled]
[New Thread 47188270361088 (LWP 11549)]
15:34:50.403-mp4live-3: type 0 usb type 0
15:34:50.449-mp4live-3: /home/emanuel/temp/bin/mp4live version 1.4.1 V4L2

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 47188270361088 (LWP 11549)]
0x00002aeadf2f0200 in xvid_plugin_psnr () from /usr/lib/libxvidcore.so.4

The bug is reproduceable. As workaround mpeg4ip-1.4.1 can be compiled without
xvid support.

[ebuild   R   ] media-video/mpeg4ip-1.4.1  USE="a52 aac alsa arts ffmpeg ipv6
lame mp4live mpeg2 v4l2 x264 xvid -esd -id3 -nas -player" 0 kB

localhost bin # emerge --info
Portage 2.1_pre7-r4 (default-linux/amd64/2006.0, gcc-3.4.4, glibc-2.3.5-r2,
2.6.16-gentoo-r1 x86_64)
=================================================================
System uname: 2.6.16-gentoo-r1 x86_64 Intel(R) Pentium(R) D CPU 2.80GHz
Gentoo Base System version 1.6.14
dev-lang/python:     2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -fomit-frame-pointer -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/share/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/env.d"
CXXFLAGS="-march=nocona -O2 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LINGUAS="de en"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X a52 aac acl acpi alsa amr apache2 arts artswrappersuid avi berkdb
bitmap-fonts cli crypt ctype cups dba dri dts eds emboss encode expat fastbuild
ffmpeg foomaticdb force-cgi-redirect fortran ftp gd gif gpm gstreamer gtk gtk2
hal ieee1394 imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog java
jpeg kde kdeenablefinal lame lzw lzw-tiff matroska memlimit mono mp3 mp4
mp4live mpeg mpeg2 ncurses nls nptl ogg opengl pam pcre pdflib perl png posix
pppd python qt quicktime rdesktop readline samba sdl session simplexml soap
sockets speex spell spl ssl tcpd threads tiff tokenizer truetype truetype-fonts
type1-fonts unicode usb v4l v4l2 video_cards_ati vorbis wxwindows x264 xinerama
xml xpm xsl xv xvid zeroconf zlib elibc_glibc kernel_linux linguas_de
linguas_en userland_GNU"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, PORTDIR_OVERLAY

hmm, can't reproduce here.. but I have an Athlon64.

Which version of xvid do you have ?

in gdb, when it crashes, can you do bt ? and disassemble. I'm curious to know
which instruction fails.

I have

[ebuild   R   ] media-libs/xvid-1.1.0  USE="-doc" 0 kB


The bad boy is line video_xvid10.cpp:290, the jump goes into
/usr/lib/libxvidcore.so.4. The call for this is

m_vopBufferLength = xvid_encore(m_xvidHandle, XVID_ENC_ENCODE, &xvidFrame,     
                            &m_xvidResult);

Now I will look whether there are some fixes for xvid... Stay tuned

It seems to be somewhere in 

Program received signal SIGILL, Illegal instruction.
0x00002ab4f5ef93b0 in emms_3dn () from /usr/lib/libxvidcore.so.4

My guess is that xvid tries to use some 3D-Now AMD commands which are unknown
to the x64 Intel architecture.

then its an xvid bug.. reassigning to media-video

it seems to be in xvidcore/src/utils/x86_64_asm/cpuid.asm
emms_3dn calls the opcode "femms" with is AMD specific.

in src/xvid.c
it sets the emms=emms_3dn if x86_64, but it should check for the 3dnow flag
first.

As a workaround, you should downgrade to the stable xvid.. it seems to use the
mmx version for x86_64.

Okay to resolve this bug we have only these ways:

a) resurrect the 3dnow useflag;
b) use PROFILE_ARCH like sparc does, and making sure that with em64t that part
of the code is disabled;
c) change the code to use cpuid to identify the CPU and its ability to run
3Dnow code;
d) use __3dNOW__ define to check if to use it or not; but without
-march=athlon64 it _will_ disable 3dnow support at all.

I'm not sure how much media-video can do about this, it's more for amd64@g.o
IMHO.

Having a check on /proc/cpuinfo at compile time is a no go.

Reassigning to amd64 herd, going for solution (c), but someone has to help with
asm coding.

Okay, I should have looked to the code instead of going by memory of 1.0
series.

The code already has a cpu_flags loading capabilities, so I can just check
against that, hopefully... still a check on em64t should be done to make sure
that there's no code that tries to execute AMD-specific instructions, and
that's up to amd64 team anyway.

Diego, the real problem lies in src/xvid.c:
xvid does

==
        emms = emms_c;
<snip>
        if ((cpu_flags & XVID_CPU_MMX) || (cpu_flags & XVID_CPU_MMXEXT) ||
                (cpu_flags & XVID_CPU_3DNOW) || (cpu_flags & XVID_CPU_3DNOWEXT)
||
                (cpu_flags & XVID_CPU_SSE) || (cpu_flags & XVID_CPU_SSE2))
        {
                /* Restore FPU context : emms_c is a nop functions */
                emms = emms_mmx;
        }
<snip>
        if ((cpu_flags & XVID_CPU_3DNOW)) {

                emms = emms_3dn;
==

That looks quite sane to me. I rather think that the detection of
XVID_CPU_3DNOW is somewhat b0rked.

Could not reproduce this bug on em64t.

Emanuel: Please run mp4live throught gdb and break at xvid_global.
Then step through and add a watchpoint on emms. Please tell us
where it gets assigned emms_3dn. I don't see any possibility where this
could happen.

This gets tricky, 1.1.0-r1 that should fix this problem breaks on 3dNow!
enabled systems.

This gets tricky, 1.1.0-r1 that should fix this problem breaks on 3dNow!
enabled systems.

*** Bug 135326 has been marked as a duplicate of this bug. ***

*** Bug 131422 has been marked as a duplicate of this bug. ***

I've added a straight-to-stable -r2 to fix the issue because it was starting to
be quite obnoxious.

This is one of the cases in which we'd need a 3dnow useflag on amd64
profiles...

Bug #135326 has been marked as a duplicate of this bug and both have been
marked resolved. However, I still suffer from the textrel issue with mencoder.
Removing the textrel patch solves the problem. I think bug #135326 should be
reopened.

xvid-1.1.0-r2 still do not work on my AMD XP 2000+!
I have the same behavior as described in this bug:
http://bugs.gentoo.org/show_bug.cgi?id=131422 . 
So better reopen 131422 it? 

I now use xvid-1.1.0 - the last one which worked on my AMD XP 2000+.

# cat /proc/cpuinfo |grep "flags"
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts

This starts to be funny, different problems with very similar behaviour...
Well, this one should now be fixed for good and we should be kosher, I'll
reopen one of the others.

Well, it might work for EM64T now, but the patch for xvid-1.1.0-r2 seriously
butchered xvid performance on AMD machines for me. On the same source material
with the same options I went from 15 fps to 3 fps on a 2 pass encode, both with
mencoder and transcode. Commenting out the 3dnow-2.patch in the ebuild got me
back to where performance was supposed to be.

This should be fixed with xvid-1.1.0-r3, closing bug.