Mytbackend killed with SIGILL on AMD

It's tested on hardy with myth 0.21.

This looks strikingly familiar. Are you using 32 bit or 64 bit builds on
each?

On Mon, Mar 3, 2008 at 1:53 PM, Anders Kvist <email address hidden> wrote:

> It's tested on hardy with myth 0.21.
>
> --
> Mytbackend killed with SIGILL on AMD
> https://bugs.launchpad.net/bugs/198115
> You received this bug notification because you are a member of MythTV
> Ubuntu Maintainers, which is subscribed to mythtv in ubuntu.
>

--
Mario Limonciello
<email address hidden>

Both are running 32 bits builds.

Anders Kvist wrote:
> Public bug reported:
>
> It works fine on my Intel Core2 Duo laptop but not on my old AMD box...
>
> root@mythtv:~# mythbackend
> Illegal instruction (core dumped)
>
> gdb:
> Program received signal SIGILL, Illegal instruction.
> [Switching to Thread 0xb5705720 (LWP 27706)]
> NetInterfaceTrafficStats (this=0xb6f84f80) at groupsock/NetInterface.cpp:152
> 152 groupsock/NetInterface.cpp: No such file or directory.
> in groupsock/NetInterface.cpp
>
> #0 NetInterfaceTrafficStats (this=0xb6f84f80) at groupsock/NetInterface.cpp:152
> #1 0xb6efec1d in __static_initialization_and_destruction_0 (__initialize_p=<value optimized out>, __priority=65535) at groupsock/Groupsock.cpp:104
> #2 0xb6f54855 in __do_global_ctors_aux () from /usr/lib/libmythlivemedia-0.21.so.0
> #3 0xb6ef7440 in _init () from /usr/lib/libmythlivemedia-0.21.so.0
> #4 0xb7fd29a0 in ?? () from /lib/ld-linux.so.2
> #5 0x00000001 in ?? ()
> #6 0xbff9793c in ?? ()
> #7 0x08056ea0 in ?? ()
> #8 0xbff97934 in ?? ()
> #9 0x00000001 in ?? ()
> #10 0xb7fdfff4 in ?? () from /lib/ld-linux.so.2
> #11 0x0000001c in ?? ()
> #12 0xb7fe0668 in _r_debug ()
> #13 0xb7fc5000 in ?? ()
> #14 0x00000047 in ?? ()
> #15 0x00000000 in ?? ()
>
> strace:
> uname({sys="Linux", node="mythtv", ...}) = 0
> brk(0) = 0x815a000
> brk(0x817b000) = 0x817b000
> open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
> statfs64("/selinux", 84, 0xbfd2d5bc) = -1 ENOENT (No such file or directory)
> open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
> fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f05000
> read(3, "rootfs / rootfs rw 0 0\nnone /sys"..., 1024) = 738
> read(3, "", 1024) = 0
> close(3) = 0
> munmap(0xb7f05000, 4096) = 0
> futex(0xb5d42674, 0x81 /* FUTEX_??? */, 2147483647) = 0
> futex(0xb5d47700, 0x81 /* FUTEX_??? */, 2147483647) = 0
> --- SIGILL (Illegal instruction) @ 0 (0) ---
> +++ killed by SIGILL (core dumped) +++
> Process 27710 detached
>
> root@mythtv:~# cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 6
> model : 4
> model name : AMD Athlon(tm) Processor
> stepping : 2
> cpu MHz : 1337.932
> cache size : 256 KB
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
> bogomips : 2678.40
> clflush size : 32
>
> ** Affects: mythtv (Ubuntu)
> Importance: Undecided
> Status: New
>
Can you post the /proc/cpuinfo from the working one? I suspect different flags
supported.

--
Mario Limonciello
<email address hidden>

This one works

vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU U7600 @ 1.20GHz
stepping : 2
cpu MHz : 800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 2394.08
clflush size : 64

Okay so the missing flag is SSE. I don't know its a good idea to disable it across the board. I'll think on this one. How many CPUs don't support SSE these days?

[QUOTE: Peter Alderson - Bug: 198104]
Mario - Has it just become more likely with recent updates to MythTV? I have run MythTV on this computer for a year without this problem but since applying MythTV updates about a week ago (fixes16338?) it has always failed in this way. Is there anything I can do? Peter
[/QUOTE]

I have also been running MythTV on this box for years, but since I decided to run mythbuntu on Hardy it has failed. It must be possible to detect SSE runtime in MythTV and use different functions where needed... We do this in rawstudio (rawstudio.org).

/Anders

This bug was fixed in the package mythtv - 0.21.0-0ubuntu1

---------------
mythtv (0.21.0-0ubuntu1) hardy; urgency=low

  * New upstream version. (LP: #192486)
  * Include etc/network/if-up.d/mythtv-backend.if-up.d. This makes sure
    that if the network is to come up late, myth starts late. (LP: #187348)
  * Start mysql from mythtv-database postinst if we can.
  * Start mythtv-setup with taskset -c 0 (Thanks Daniel Kristjansson)
  * Only --tune to i686 again due to upstream changes in the configure
    script. This time add MMX though. (LP: #198104) (LP: #198115)

 -- Mario Limonciello <email address hidden> Sat, 08 Mar 2008 01:31:06 -0600

Thanks Mario, MythTV is now working again for me on my AMD CPU (problem raised in 198104). Peter

It also works here, thanks for the fix :)