Actually - which processor is it specifically (execute "cat /proc/cpuinfo")? I think it matters.. I've dug through a little bit and discovered something interesting. In fact, I can get it working with changes to the code that bypass using the extended AES instruction set.
Some chips come with instructions to help speed up encryption and decryption using the AES standard. Others do not. There is a function in /plex-home-theater-public/plex/Third-Party/aes/aes_via_ace.h near line 351 called is_via_cpu() -- which presumably exists to determine whether or not the AES instruction set exists on the processor.
This is the processor I have. You can see that the AES instruction set is NOT supported on this processor:
http://ark.intel.com/products/29755/Intel-Core2-Duo-Processor-E6420-4M-Cache-2_13-GHz-1066-MHz-FSB
So I took that function and you can see the code that was there that I commented out, and replaced with a more hard "no this is not a VIA cpu":
INLINE int is_via_cpu(void)
{ int val;
/*asm("pushl %ebx
");
asm("xorl %eax,%eax
");
asm("cpuid
");
asm("xorl %eax,%eax
");
asm("subl $0x746e6543,%ebx
");
asm("orl %ebx,%eax
");
asm("subl $0x48727561,%edx
");
asm("orl %edx,%eax
");
asm("subl $0x736c7561,%ecx
");
asm("orl %ecx,%eax
");
asm("movl %%eax,%0
" : "=m" (val));
asm("popl %ebx
");
val = (val ? 0 : 1);
via_flags = (val | NEH_CPU_READ);
return val;*/
via_flags = (0 | NEH_CPU_READ);
return 0;
}
I then rebuilt AND NOW PLEX IS VERY STABLE AND WORKS WELL FOR ME! Hooray for me, I guess - but lots of other people don't know how to compile from scratch. I wish I knew the appropriate venue to file a bug report for this... the github repo does not have the issue tracker enabled. If anyone knows the proper place to file this I can attach a backtrace and stuff.
I read through some of the code comments and it seems that if it can't use the AES instruction set it just falls back to using a slower software-based solution, but considering it allowed me to authenticate with plex and everything's running well (I'm basing my build off the 1.3.3 code but I bet this would work fine against 1.3.4 or HEAD) I think I've at least found the crux of the issue.
Specifically, the segfault happens when trying to set via_flags:
via_flags = (val | NEH_CPU_READ);
So val must be something pretty bogus after all that assembler code executes...?
