On Mon, Jan 29, 2007 at 10:53:30PM -0500, Blair Sadewitz wrote:
> $ /usr/pkg/emul/linux/usr/bin/ldd /usr/pkg/emul/linux/bin/ls
>        librt.so.1 => /lib64/librt.so.1 (0x00007f7ffdce8000)
>        libacl.so.1 => /lib64/libacl.so.1 (0x00007f7ffdbe1000)
>        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f7ffdacf000)
>        libc.so.6 => /lib64/libc.so.6 (0x00007f7ffd8a6000)
>        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7ffd711000)
>        /lib64/ld-linux-x86-64.so.2 (0x00007f7ffde00000)
>        libattr.so.1 => /lib64/libattr.so.1 (0x00007f7ffd60e000)
> That works.
> 
> procfs on /usr/pkg/emul/linux/proc type procfs (read-only, local)
> 
> $ /emul/linux/bin/date
> Memory fault (core dumped)
> $ /emul/linux/bin/ls
> Memory fault (core dumped)
> 
> sh-3.00$ uname -a
> Linux woodrow.homeunix.net 2.4.18 #0 Wed Feb 20 20:00:02 CET 2002
> x86_64 x86_64 x86_64 GNU/Linux
> 
> but I can run bash or linux sh and do that.
> 
> Are there any known issues with this?

Not that i know. It works fine here with an up to date -current.

njoly@lanfeust [~]> uname -a
NetBSD lanfeust.sis.pasteur.fr 4.99.9 NetBSD 4.99.9 (LANFEUST_DEVEL) #2: Mon Jan 29 14:11:23 CET 2007  njoly@lanfeust.sis.pasteur.fr:/local/src/NetBSD/obj/amd64/sys/arch/amd64/compile/LANFEUST_DEVEL amd64

njoly@lanfeust [~]> file /emul/linux/bin/date
/emul/linux/bin/date: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped
njoly@lanfeust [~]> /emul/linux/bin/date
Tue Jan 30 10:52:13 CET 2007

>  I will send ktruss output, etc.  upon request.

Yes, please.

> Running linux uptime gives this ktruss output, looping over and over:
> 
>       "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\a\0t\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
> 28924      1 uptime   fcntl(0x3, 0x7, 0x7f7fffffbe80) = 0
> 28924      1 uptime   alarm(0)                    = 0
> 28924      1 uptime   rt_sigaction(0xe, 0x7f7fffffbc70, 0, 0x8) = 0
> 28924      1 uptime   alarm(0)                    = 0
> 28924      1 uptime   rt_sigaction(0xe, 0x7f7fffffbc70,
> 0x7f7fffffbbd0, 0x8) = 0
> 28924      1 uptime   alarm(0x1)                  = 0
> 28924      1 uptime   fcntl(0x3, 0x7, 0x7f7fffffbe80) Err#4 EINTR
> 28924      1 uptime   SIGALRM caught handler=0x7f7ffdcc0750 mask=0x0 
> code=0x0
> 28924      1 uptime   rt_sigreturn()              = 0
> 28924      1 uptime   read(0x3, 0x7f7ffddfea60, 0x180) = 384
>       "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
> 28924      1 uptime   fcntl(0x3, 0x7, 0x7f7fffffbe80) = 0
> 28924      1 uptime   alarm(0)                    = 0
> 28924      1 uptime   rt_sigaction(0xe, 0x7f7fffffbc70, 0, 0x8) = 0
> 28924      1 uptime   alarm(0)                    = 0
> 28924      1 uptime   rt_sigaction(0xe, 0x7f7fffffbc70,
> 0x7f7fffffbbd0, 0x8) = 0
> 
> but eventually (~45 seconds) later completes with:
> 
> sh-3.00$ /emul/linux/usr/bin/uptime
> 10:52pm  up  22:29,  0 users
> 
> I have *NEVER* seen anything like that before.  What is going on? ;)

I do see the same for this one, i'll try to have a look.

-- 
Nicolas Joly

Biological Software and Databanks.
Institut Pasteur, Paris.