Yes, I ONLY changed the glibc, glibc-2.2.5 doesn't works, and glibc-2.2.4 works. I have also tried to use glibc-2.3.1, but I couldn't get it working. Kernel used to do this test is 2.4.19 which comes with mdk9.
I have also tried differents kernels with the glibc-2.2.5: I have tried 2.4.8, 2.4.19 and 2.4.20. None solved the problem.
Yes, i have confirmed this, the kernel is not at fault here. According to the mplayer source code, they are trying to use the old vm86old() syscall instead of using the standard vm86() one. mplayer/linux/lrmi.c: /* I don't know how to make sure I get the right vm86() from libc. The one I want is syscall # 113 (vm86old() in libc 5, vm86() in glibc) which should be declared as "int vm86(struct vm86_struct *);" in <sys/vm86.h>. This just does syscall 113 with inline asm, which should work for both libc's (I hope). */ however, in mplayer/libvo/vo_vesa.c i see the code that checks if the vm86 call worked. If i run mplayer with -v -v after a big enormous log i get: vo_vesa: preinit((null)) was called vo_vesa: subdevice (null) is being initialized vo_subdevice: initialization returns: 0 and after some query_format calls, i get the "requires root" and killed. Some highlights from man vm86: NAME vm86old, vm86 - enter virtual 8086 mode SYNOPSIS #include <sys/vm86.h> int vm86old(struct vm86_struct *info); int vm86(unsigned long fn, struct vm86plus_struct *v86); ERRORS (for vm86old) EPERM Saved kernel stack exists. (This is a kernel sanity check; the saved stack should only exist within vm86 mode itself.) CONFORMING TO This call is specific to Linux on Intel processors, and should not be used in programs intended to be portable.