Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Feb 2003 22:31:46 -0400 (AST)
From:      The Hermit Hacker <scrappy@hub.org>
To:        freebsd-stable@freebsd.org
Cc:        freebsd-emulation@freebsd.org
Subject:   Re: Raising KVA_PAGES breaks linux emulation?
Message-ID:  <20030221222943.O59175@localhost>
In-Reply-To: <20030221220648.T59175@localhost>
References:  <20030221140043.Y68094@hub.org> <20030221220648.T59175@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help

And the core dump provides no information:

#0  0x87c0b256 in ?? ()
(kgdb) where
#0  0x87c0b256 in ?? ()
#1  0x8014e46c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:223
#2  0x8014eb91 in panic (fmt=0x8022fcf9 "%s") at /usr/src/sys/kern/kern_shutdown.c:595
#3  0x801ffb69 in trap_fatal (frame=0xb07c3e50, eva=3217030872) at /usr/src/sys/i386/i386/trap.c:974
#4  0x801ff7d5 in trap_pfault (frame=0xb07c3e50, usermode=0, eva=3217030872) at /usr/src/sys/i386/i386/trap.c:867
#5  0x801ff333 in trap (frame={tf_fs = -2075394024, tf_es = 16, tf_ds = 16, tf_edi = -1077936424, tf_esi = -1334034672, tf_ebp = -1334034788, tf_isp = -1334034820, tf_ebx = -1077936432,
      tf_edx = -2017468000, tf_ecx = -1077936408, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -2017490092, tf_cs = 8, tf_eflags = 66118, tf_esp = -1077936432, tf_ss = -1334034672})
    at /usr/src/sys/i386/i386/trap.c:466
#6  0x87bf8b54 in ?? ()
#7  0x87bf8c58 in ?? ()
#8  0x87bf8dd7 in ?? ()
#9  0x87bf8ecd in ?? ()
#10 0x801ffea5 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 17, tf_esi = 8, tf_ebp = 2143287320, tf_isp = -1334034476, tf_ebx = 17, tf_edx = 2143287008, tf_ecx = 2143287152,
      tf_eax = 174, tf_trapno = 12, tf_err = 2, tf_eip = 672200619, tf_cs = 31, tf_eflags = 514, tf_esp = 2143286988, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175
#11 0x801ed1eb in Xint0x80_syscall ()
#12 0x807c660 in ?? ()
#13 0x807a375 in ?? ()
#14 0x805a78c in ?? ()
#15 0x80591c8 in ?? ()
#16 0x280fd336 in ?? ()
(kgdb) up 5
#5  0x801ff333 in trap (frame={tf_fs = -2075394024, tf_es = 16, tf_ds = 16, tf_edi = -1077936424, tf_esi = -1334034672, tf_ebp = -1334034788, tf_isp = -1334034820, tf_ebx = -1077936432,
      tf_edx = -2017468000, tf_ecx = -1077936408, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -2017490092, tf_cs = 8, tf_eflags = 66118, tf_esp = -1077936432, tf_ss = -1334034672})
    at /usr/src/sys/i386/i386/trap.c:466
466                             (void) trap_pfault(&frame, FALSE, eva);
(kgdb) frame frame->tf_ebp frame->tf_eip
#0  0x87bf8b54 in ?? ()
(kgdb)


On Fri, 21 Feb 2003, The Hermit Hacker wrote:

>
> 'K, just to confirm this, I just tried it on my other machine with
> KVA_PAGES set to 512 ... just blew up, but looks like I'm going to get a
> core ... it blows up at the same spot:
>
> ===>  Installing for linux_base-7.1_2
> kern.fallback_elf_brand: -1 -> 3
> glibc-common-2.2.4-31.i386.rpm
> glibc-2.2.4-31.i386.rpm
> redhat-release-7.1-1.noarch.rpm
> setup-2.4.7-1.noarch.rpm
> filesystem-2.0.7-1.noarch.rpm
> basesystem-7.0-2.noarch.rpm
> termcap-11.0.1-8.noarch.rpm
> db1-1.85-5.i386.rpm
> db3-3.1.17-7.i386.rpm
> gdbm-1.8.0-5.i386.rpm
> glib-1.2.9-1.i386.rpm
> libtermcap-2.0.8-26.i386.rpm
> bash-2.04-21.i386.rpm
> <hangs solid>
>
> The system is running relatively recent source code, with KVA_PAGES set to
> 512, and the following patch applied to libc_r that I got from Tor:
>
> Index: uthread/uthread_init.c
> ===================================================================
> RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v
> retrieving revision 1.23.2.10
> diff -u -r1.23.2.10 uthread_init.c
> --- uthread/uthread_init.c      22 Oct 2002 14:44:03 -0000      1.23.2.10
> +++ uthread/uthread_init.c      14 Feb 2003 21:18:22 -0000
> @@ -245,6 +245,11 @@
>                 len = sizeof (int);
>                 if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) == -1)
>                         _usrstack = (void *)USRSTACK;
> +               else
> +                       _next_stack = (void *) ((char *)_usrstack
> +                                               - PTHREAD_STACK_INITIAL
> +                                               - PTHREAD_STACK_DEFAULT
> +                                               - (2 * PTHREAD_STACK_GUARD));
>                 /*
>                  * Create a red zone below the main stack.  All other stacks are
>                  * constrained to a maximum size by the paramters passed to
>
>
> Will post gdb output as soon as core is finished dumping ...
>
>
> On Fri, 21 Feb 2003, Marc G. Fournier wrote:
>
> >
> > Morning all ...
> >
> >   I've just increased my KVA_PAGES to 512, based on recommendations, and
> > fixed the issue with libc_r, based on a patch I received ... the system as
> > a whole is working working quite well now, but, linux emulation no longer
> > appears to be working ...
> >
> >   linux is loaded:
> >
> >  4    1 0x87beb000 15000    linux.ko
> >
> >   and libraries are installed:
> >
> > venus# ls -lt /compat/linux/lib/libpthread*
> > lrwxr-xr-x  1 root  wheel      17 Dec 31 20:31 /compat/linux/lib/libpthread.so.0 -> libpthread-0.9.so
> > -rwxr-xr-x  1 root  wheel  559279 Oct 10 11:49 /compat/linux/lib/libpthread-0.9.so
> >
> >   but if I try and run the linux javac, it gives me:
> >
> > error while loading shared libraries: libpthread.so.0: cannot open shared object file: Error 14
> >
> >   if I try to run /compat/linux/sbin/ldconfig (as in /etc/rc when
> >   linux_enable is YES), I get:
> >
> > venus# /compat/linux/sbin/ldconfig
> > /compat/linux/sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: Bad address
> > /compat/linux/sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Bad address
> >
> >   did raising KVA_PAGES break the linux emulation / libraries, or is this
> > something else I'm missing?
> >
> >   As a side note, on another server that I raised KVA_PAGES to 512 on, I
> > tried doing a 'make install' of linux_base, and each time I ran it (did it
> > a couple of times, just to confirm that it was that that was causing the
> > crash), the server would crash, but I was unable to get core to dump ... I
> > had thought maybe it was a problem with that server, but now I'm
> > suspecting it might be the linux emulation itself ...
> >
> >   Server code is relatively up to date:
> >
> > 	4.7-STABLE #32: Fri Feb 14 12:58:45 CST 2003
> >
> > Thoughts?  Suggestions?
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-emulation" in the body of the message
> >
>
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org
>

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030221222943.O59175>