Linux emulation on FreeBSD AMD64

[Yuri Pankov]

On Sun, 2007-10-28 at 00:08 +0300, Valery V.Chikalov wrote:
> Ivan Voras wrote:
> > Valery V.Chikalov wrote:
> >> Hi, list.
> > 
> >> Now being inspired the great performance improvements on multiprocessors
> >> configurations I am trying to switch to FreeBSD 7.0 version, moreover on
> >> AMD64 architecture. Must I expect some regression in support old Linux
> >> application here? Are some theoretical obstacles exists that linux
> >> application which successfully worked on FreeBSD from 5.0 up to 6.2
> >> can not be running on 7.0 AMD64?
> > 
> > AFAIK Linux emulation on AMD64 works only for 32-bit code, so you have
> > practically two emulation layers: linux-freebsd and 32-64. There's all
> > kinds of things that might go wrong.
> > 
> > This is a "generic" answer, I don't really know the exact answer to your
> > question.
> > 
> >
> Hi, Ivan.
> 
> Thank you for your answer.
> 
> Yes I know that Linux emulation is 32 bit ever on AMD64 FreeBSD and that 
> exactly what I need as I own old 32bit 9.0.1 Oracle server.
> 
> I have investigated this problem little more.
> 
> Oracle(+ rh7) can be successfully started on FreeBSD 7.0 (i386)
>     SMP capable kernel, SHED_ULE, Core2Duo and so on...
> 
> I fond this: http://wiki.freebsd.org/linux-kernel/ltp
> I don't know how actual this info now, it seems little bit old.
> 
> I did:
> 
> grep UNIMPL /sys/amd64/linux32/syscalls.master > amd64.unimpl.txt
> grep UNIMPL /sys/i386/linux/syscalls.master > i386.unimpl.txt
> 
> diff i386.unimpl.txt amd64.unimpl.txt
> 
> 6d5
> < 28    AUE_FSTAT       UNIMPL  fstat
> 14d12
> < 86    AUE_USELIB      UNIMPL  linux_uselib
> 16d13
> < 101   AUE_NULL        UNIMPL  ioperm
> 18,19d14
> < 113   AUE_NULL        UNIMPL  vm86old
> < 123   AUE_NULL        UNIMPL  modify_ldt
> 21d15
> < 166   AUE_NULL        UNIMPL  vm86
> 29d22
> < 244   AUE_NULL        UNIMPL  linux_get_thread_area
> 
> So there is some regression between i386 and AMD64 in a number of system 
> calls emulated.
> 
> But Oracle not dumping core with signal 12(non-existent system call)
> It's saying:
> ==========
> 27122, 00000, "unable to protect memory"
> // *Cause: mprotect() call failed
> ==========
> 
> and than dumps core with signal 11.
> 
> I instrumented mprotect(2) system call in linux32_machdep.c with
> 
> -return (mprotect(td, &bsd_args));
> 
> +ret = mprotect(td, &bsd_args);
> +printf("mprotect addr:%lx, return %d\n", uap->addr, ret);
> +return ret;
> 
> and got something like:
> 
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a27d000, return 0
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7c1000, return 0
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7cd000, return 0
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7e2000, return 0
> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7ef000, return 0
> Oct 27 19:43:09 tiger kernel: mprotect addr:55c00000, return 13
> Oct 27 19:43:09 tiger kernel: mprotect addr:55c81000, return 13
> 
> where 13 is EACCES.
> 
> So, I think we have some regression in supporting old linux binaries on 
> AMD64 and possibly not connected with missing system calls.
> Don't know where to move from here.
> 
> BTW, ktrace don't usable for me on FreeBSD 7.0 any arch,
> kdump dumping core on freebsd6_mmap system call.
> 
> Thanks.
> Valery.

Hi, Valery.

Are you using linux_kdump (devel/linux_kdump or, much faster, with
pkg_add -r)?


Yuri