From shuriku at shurik.kiev.ua Thu Oct 1 08:47:32 2009 From: shuriku at shurik.kiev.ua (Alexandr Krivulya) Date: Thu Oct 1 08:47:39 2009 Subject: guest win2k3 hangs under virtualbox Message-ID: <4AC46653.5010307@shurik.kiev.ua> Hello, comunity, I have FreeBSD 7.2 box with virtualbox_3.0.51.r22226 running win2k3 as guest in headless mode. Sometimes guest enviroment hangs for a period from a few seconds to few minutes. From Linux forums I found, that setting force_async_tsc=1 for vboxdrv kernel module may help. Any suggestions for FreeBSD? From ulrich at pukruppa.net Fri Oct 2 17:33:52 2009 From: ulrich at pukruppa.net (Peter Ulrich Kruppa) Date: Fri Oct 2 17:33:59 2009 Subject: VirtualBox: GUI-configuration couldn't be loaded; Callee RC: NS_ERROR_ABORT (0x80004004) Message-ID: <1254503836.1925.85.camel@pukruppa.net> Hi, whenever I try to start VirtualBox on my FreeBSD 8.0-RC1 amd64 I get an error message about GUI-configuration that couldn't be loaded and Callee RC: NS_ERROR_ABORT (0x80004004) There has been a mail about this back in May, but I couldn't find an answer (it was a very long thread). Has this issue been solved? Thanks for your answer Uli. From imb at protected-networks.net Fri Oct 2 17:43:31 2009 From: imb at protected-networks.net (Michael Butler) Date: Fri Oct 2 17:43:38 2009 Subject: panic using VirtualBox on -current Message-ID: <4AC631C1.9090705@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While installing a guest OS (Centos-5.3) under VirtualBox, I get a panic as below. Any pointers as to how to proceed would be appreciated. I have these defined in the kernel: # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks options WITNESS # Enable checks to detect deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks options KDB_TRACE # print a stack trace on panic options DEBUG_MEMGUARD # detect reads or writes options DIAGNOSTIC Michael panic: uma: item 0xc7efa400 did not belong to zone 64 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c0a94825,0,c0a85c81,e803fbb8,0,...) at db_trace_self_wrapper+0x26 panic(c0a85c81,c7efa400,c0a7dc8d,c7efa400,c148b060,...) at panic+0x106 uma_dbg_free(c148b000,0,c7efa400,7c8,c0a58349,...) at uma_dbg_free uma_zalloc_arg(c148b000,0,2,c0adae6c,2c,...) at uma_zalloc_arg+0x2b7 malloc(2c,c0adae6c,2,0,c0a58349,...) at malloc+0xa4 ioctl(c8f1b690,e803fcf8,c,c0a73dd2,c0ace5a8,...) at ioctl+0xeb syscall(e803fd38) at syscall+0x19e Xint0x80_syscall() at Xint0x80_syscall+0x20 - --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x482a3d0b, esp = 0xbf8bad4c, ebp = 0xbf8bad68 --- KDB: enter: panic exclusive spin mutex allpmaps (allpmaps) r = 0 (0xc0ced570) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:2461 exclusive lockmgr bufwait (bufwait) r = 0 (0xc52077f0) locked @ /usr/home/imb/svn/head/sys/kern/vfs_bio.c:1835 exclusive lockmgr ufs (ufs) r = 0 (0xc8edb9c4) locked @ /usr/home/imb/svn/head/sys/kern/vfs_vnops.c:607 exclusive sleep mutex 64 (UMA zone) r = 0 (0xc1494888) locked @ /usr/home/imb/svn/head/sys/vm/uma_core.c:1992 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc8b18a34) locked @ /usr/home/imb/svn/head/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc7dabbd0) locked @ /usr/home/imb/svn/head/sys/kern/uipc_sockbuf.c:148 exclusive sleep mutex PMAP2 (PMAP2) r = 0 (0xc0ceda44) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:2411 exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xc0ca4a84) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:3635 exclusive sleep mutex pmap (pmap) r = 0 (0xc0ced4e0) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:3629 exclusive sleep mutex system map (system map) r = 0 (0xc14900e8) locked @ /usr/home/imb/svn/head/sys/vm/vm_map.c:2766 exclusive sleep mutex UMA lock (UMA lock) r = 0 (0xc0ca4304) locked @ /usr/home/imb/svn/head/sys/vm/uma_core.c:1565 exclusive spin mutex allpmaps (allpmaps) r = 0 (0xc0ced570) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:2461 exclusive lockmgr bufwait (bufwait) r = 0 (0xc52077f0) locked @ /usr/home/imb/svn/head/sys/kern/vfs_bio.c:1835 exclusive lockmgr ufs (ufs) r = 0 (0xc8edb9c4) locked @ /usr/home/imb/svn/head/sys/kern/vfs_vnops.c:607 exclusive sleep mutex 64 (UMA zone) r = 0 (0xc1494888) locked @ /usr/home/imb/svn/head/sys/vm/uma_core.c:1992 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc8b18a34) locked @ /usr/home/imb/svn/head/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc7dabbd0) locked @ /usr/home/imb/svn/head/sys/kern/uipc_sockbuf.c:148 exclusive sleep mutex PMAP2 (PMAP2) r = 0 (0xc0ceda44) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:2411 exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xc0ca4a84) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:3635 exclusive sleep mutex pmap (pmap) r = 0 (0xc0ced4e0) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:3629 exclusive sleep mutex system map (system map) r = 0 (0xc14900e8) locked @ /usr/home/imb/svn/head/sys/vm/vm_map.c:2766 exclusive sleep mutex UMA lock (UMA lock) r = 0 (0xc0ca4304) locked @ /usr/home/imb/svn/head/sys/vm/uma_core.c:1565 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrGMcEACgkQQv9rrgRC1JKHSQCeOhesV8wJjh+RwhF7zgpBEkjc 1goAnjogPfY7b7jfiiObSSv7DgCu0n6a =7Gc6 -----END PGP SIGNATURE----- From npapke at acm.org Sat Oct 3 20:20:11 2009 From: npapke at acm.org (Norbert Papke) Date: Sat Oct 3 20:20:18 2009 Subject: VirtualBox: GUI-configuration couldn't be loaded; Callee RC: NS_ERROR_ABORT (0x80004004) In-Reply-To: <1254503836.1925.85.camel@pukruppa.net> References: <1254503836.1925.85.camel@pukruppa.net> Message-ID: <200910031320.09906.npapke@acm.org> On October 2, 2009, Peter Ulrich Kruppa wrote: > whenever I try to start VirtualBox on my > FreeBSD 8.0-RC1 amd64 > I get an error message about GUI-configuration that couldn't be loaded > and > Callee RC: NS_ERROR_ABORT (0x80004004) > There has been a mail about this back in May, but I couldn't find an > answer (it was a very long thread). > Has this issue been solved? I have seen similar errors when I didn't have the "vboxnetflt" kernel module loaded ... -- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From decke at bluelife.at Mon Oct 5 07:55:08 2009 From: decke at bluelife.at (Bernhard Froehlich) Date: Mon Oct 5 07:55:17 2009 Subject: Does vbox have support for cd-rom or usb in winxp guest? In-Reply-To: <4ABC05CD.6090108@FreeBSD.org> References: <4ABBE24E.3090306@FreeBSD.org> <4ABBEAAF.9020409@shapeshifter.se> <4ABC05CD.6090108@FreeBSD.org> Message-ID: <309ea2853e3ae7a0b592bde7806d1026.squirrel@webmail.itac.at> On Fri, September 25, 2009 1:50 am, Doug Barton wrote: > Fredrik Lindberg wrote: >> Doug Barton wrote: >>> >>> I'm also curious about access to USB devices. I don't even see options >>> for that, so is it just not possible? >>> >> >> The open source edition of VirtualBox doesn't include any USB support >> nor the virtual USB controller, it's a closed source component. >> >> Details at http://www.virtualbox.org/wiki/Editions > > Wow, what a bad web site! :) Where would I go to buy the closed > source version, and could I run it on FreeBSD if I did? > Looks like the virtualbox developers are working on USB and VRDP support so chances are good that there will be a closed source version of Sun xVM VirtualBox for FreeBSD in the future. http://www.virtualbox.org/changeset/23529 http://www.virtualbox.org/changeset/23531 -- Bernhard Fr?hlich http://www.bluelife.at/ From bugmaster at FreeBSD.org Mon Oct 5 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:07:35 2009 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200910051106.n95B6nPN088634@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/138944 emulation [parallels] [regression] Parallels no longer works in o kern/138880 emulation [linux] munmap segfaults after linux_mmap2 stresstest o ports/137332 emulation add caution messages to some adobe products f ports/136321 emulation x11-toolkits/linux-pango: please update linux based po o ports/136229 emulation [linux] certain linux apps look for libraries using a o ports/135337 emulation [PATCH] emulators/linux_base-f10: incorrect bash usage o ports/135322 emulation Port graphics/linux_dri has incorrect packaging list c o kern/130724 emulation [linprocfs] [patch] cpuinfo in linprocfs is dated, cau o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n f ports/127018 emulation Linuxulator incapable of using FreeBSD's LDAP environm o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/56451 emulation [linprocfs] /compat/linux/proc/cpuinfo gives wrong CPU o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 20 problems total. From nox at jelal.kn-bremen.de Wed Oct 7 22:11:08 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Wed Oct 7 22:11:15 2009 Subject: playing with qemu usermode emulation on FreeBSD... Message-ID: <20091007220549.GA65997@triton8.kn-bremen.de> I recently noticed there are x86 bsd-user targets now (yeah I totally missed those commits...) and now got it working a tiny little bit: I can run qemu-x86_64 -bsd freebsd /rescue/echo foo bar here on FreeBSD 8/amd64 and it echoes foo bar as expected, but segfaults afterwards. :) (in pthread_setcancelstate() invoked from a guest write() syscall, in case anyone is wondering.) Other things I tried either exit with errors or segfault as well, and i386 hosts probably still don't work at all yet. (qemu-i386 here on amd64 does at least something, but probably needs lock_user() treatment for all kinds of syscalls, I only tried adding that for sysctl so far.) Anyway, here is an emulators/qemu-devel git head snapshot port update with my current patches (files/patch-bsd-user), feel free to test/debug/improve: http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch (For the folks reading this on the qemu list: I shall start doing `proper' patch submissions later, this is more for the FreeBSD folks and because I was asked to send what I have...) Enjoy, Juergen PS: well I guess I could inline the patch here too so the curious don't have to extract it out of the update: Index: qemu/bsd-user/freebsd/strace.list @@ -39,6 +39,7 @@ { TARGET_FREEBSD_NR_ftruncate, "ftruncate", NULL, NULL, NULL }, { TARGET_FREEBSD_NR_futimes, "futimes", NULL, NULL, NULL }, { TARGET_FREEBSD_NR_getdirentries, "getdirentries", NULL, NULL, NULL }, +{ TARGET_FREEBSD_NR_freebsd6_mmap, "freebsd6_mmap", NULL, NULL, NULL }, { TARGET_FREEBSD_NR_getegid, "getegid", "%s()", NULL, NULL }, { TARGET_FREEBSD_NR_geteuid, "geteuid", "%s()", NULL, NULL }, { TARGET_FREEBSD_NR_getfh, "getfh", NULL, NULL, NULL }, Index: qemu/bsd-user/elfload.c @@ -126,6 +126,8 @@ regs->rax = 0; regs->rsp = infop->start_stack; regs->rip = infop->entry; + if (1 /* bsd_type == target_freebsd */) + regs->rdi = infop->start_stack; } #else Index: qemu/bsd-user/main.c @@ -171,26 +171,63 @@ switch(trapnr) { case 0x80: /* syscall from int $0x80 */ - env->regs[R_EAX] = do_openbsd_syscall(env, - env->regs[R_EAX], - env->regs[R_EBX], - env->regs[R_ECX], - env->regs[R_EDX], - env->regs[R_ESI], - env->regs[R_EDI], - env->regs[R_EBP]); + if (bsd_type == target_freebsd) { + abi_ulong params = (abi_ulong) env->regs[R_ESP] + + sizeof(int32_t); + abi_ulong arg1, arg2, arg3, arg4, arg5, arg6; + + get_user_s32(arg1, params); + params += sizeof(int32_t); + get_user_s32(arg2, params); + params += sizeof(int32_t); + get_user_s32(arg3, params); + params += sizeof(int32_t); + get_user_s32(arg4, params); + params += sizeof(int32_t); + get_user_s32(arg5, params); + params += sizeof(int32_t); + get_user_s32(arg6, params); + env->regs[R_EAX] = do_freebsd_syscall(env, + env->regs[R_EAX], + arg1, + arg2, + arg3, + arg4, + arg5, + arg6); + } else { //if (bsd_type == target_openbsd) + env->regs[R_EAX] = do_openbsd_syscall(env, + env->regs[R_EAX], + env->regs[R_EBX], + env->regs[R_ECX], + env->regs[R_EDX], + env->regs[R_ESI], + env->regs[R_EDI], + env->regs[R_EBP]); + } break; #ifndef TARGET_ABI32 case EXCP_SYSCALL: /* linux syscall from syscall intruction */ - env->regs[R_EAX] = do_openbsd_syscall(env, - env->regs[R_EAX], - env->regs[R_EDI], - env->regs[R_ESI], - env->regs[R_EDX], - env->regs[10], - env->regs[8], - env->regs[9]); + if (bsd_type == target_freebsd) + env->regs[R_EAX] = do_freebsd_syscall(env, + env->regs[R_EAX], + env->regs[R_EDI], + env->regs[R_ESI], + env->regs[R_EDX], + env->regs[10], + env->regs[8], + env->regs[9]); + else { //if (bsd_type == target_openbsd) + env->regs[R_EAX] = do_openbsd_syscall(env, + env->regs[R_EAX], + env->regs[R_EDI], + env->regs[R_ESI], + env->regs[R_EDX], + env->regs[10], + env->regs[8], + env->regs[9]); + } env->eip = env->exception_next_eip; break; #endif Index: qemu/bsd-user/syscall.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include @@ -40,14 +41,88 @@ static abi_ulong target_brk; static abi_ulong target_original_brk; -#define get_errno(x) (x) +static inline abi_long get_errno(abi_long ret) +{ + if (ret == -1) + /* XXX need to translate host -> target errnos here */ + return -(errno); + else + return ret; +} + #define target_to_host_bitmask(x, tbl) (x) +static inline int is_error(abi_long ret) +{ + return (abi_ulong)ret >= (abi_ulong)(-4096); +} + void target_set_brk(abi_ulong new_brk) { target_original_brk = target_brk = HOST_PAGE_ALIGN(new_brk); } +/* do_obreak() must return target errnos. */ +static abi_long do_obreak(abi_ulong new_brk) +{ + abi_ulong brk_page; + abi_long mapped_addr; + int new_alloc_size; + + if (!new_brk) + return 0; + if (new_brk < target_original_brk) + return -TARGET_EINVAL; + + brk_page = HOST_PAGE_ALIGN(target_brk); + + /* If the new brk is less than this, set it and we're done... */ + if (new_brk < brk_page) { + target_brk = new_brk; + return 0; + } + + /* We need to allocate more memory after the brk... */ + new_alloc_size = HOST_PAGE_ALIGN(new_brk - brk_page + 1); + mapped_addr = get_errno(target_mmap(brk_page, new_alloc_size, + PROT_READ|PROT_WRITE, + MAP_ANON|MAP_FIXED|MAP_PRIVATE, -1, 0)); + + if (!is_error(mapped_addr)) + target_brk = new_brk; + else + return mapped_addr; + + return 0; +} + +/* XXX this needs to be emulated on non-FreeBSD hosts... */ +static abi_long do_freebsd_sysctl(abi_ulong namep, int32_t namelen, abi_ulong oldp, + abi_ulong oldlenp, abi_ulong newp, abi_ulong newlen) +{ + abi_long ret; + void *hnamep, *holdp, *hnewp = NULL; + size_t holdlen; + abi_ulong oldlen = 0; + + if (oldlenp) + get_user_ual(oldlen, oldlenp); + if (!(hnamep = lock_user(VERIFY_READ, namep, namelen, 1))) + return -TARGET_EFAULT; + if (newp && !(hnewp = lock_user(VERIFY_READ, newp, newlen, 1))) + return -TARGET_EFAULT; + if (!(holdp = lock_user(VERIFY_WRITE, oldp, oldlen, 0))) + return -TARGET_EFAULT; + holdlen = oldlen; + ret = get_errno(sysctl(hnamep, namelen, holdp, &holdlen, hnewp, newlen)); + put_user_ual(holdlen, oldlenp); + unlock_user(hnamep, namep, 0); + unlock_user(holdp, oldp, holdlen); + if (hnewp) + unlock_user(hnewp, newp, 0); + return ret; +} + /* do_syscall() should always have a single exit point at the end so that actions, such as logging of syscall results, can be performed. All errnos that do_syscall() returns must be -TARGET_. */ @@ -103,12 +178,18 @@ case TARGET_FREEBSD_NR_mprotect: ret = get_errno(target_mprotect(arg1, arg2, arg3)); break; + case TARGET_FREEBSD_NR_break: + ret = do_obreak(arg1); + break; + case TARGET_FREEBSD_NR___sysctl: + ret = do_freebsd_sysctl(arg1, arg2, arg3, arg4, arg5, arg6); + break; case TARGET_FREEBSD_NR_syscall: case TARGET_FREEBSD_NR___syscall: ret = do_freebsd_syscall(cpu_env,arg1 & 0xffff,arg2,arg3,arg4,arg5,arg6,0); break; default: - ret = syscall(num, arg1, arg2, arg3, arg4, arg5, arg6); + ret = get_errno(syscall(num, arg1, arg2, arg3, arg4, arg5, arg6)); break; } fail: Index: qemu/cpu-exec.c @@ -1252,6 +1252,12 @@ # define TRAP_sig(context) ((context)->sc_trapno) # define ERROR_sig(context) ((context)->sc_err) # define MASK_sig(context) ((context)->sc_mask) +#elif defined(__FreeBSD__) +#include +#define EIP_sig(context) ((context)->uc_mcontext.mc_eip) +#define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) +#define ERROR_sig(context) ((context)->uc_mcontext.mc_err) +#define MASK_sig(context) ((context)->uc_sigmask) #else # define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP]) # define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO]) @@ -1265,6 +1271,8 @@ siginfo_t *info = pinfo; #if defined(__OpenBSD__) struct sigcontext *uc = puc; +#elif defined(__FreeBSD__) + ucontext_t *uc = puc; #else struct ucontext *uc = puc; #endif @@ -1297,6 +1305,12 @@ #define TRAP_sig(context) ((context)->sc_trapno) #define ERROR_sig(context) ((context)->sc_err) #define MASK_sig(context) ((context)->sc_mask) +#elif defined(__FreeBSD__) +#include +#define PC_sig(context) ((context)->uc_mcontext.mc_rip) +#define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) +#define ERROR_sig(context) ((context)->uc_mcontext.mc_err) +#define MASK_sig(context) ((context)->uc_sigmask) #else #define PC_sig(context) ((context)->uc_mcontext.gregs[REG_RIP]) #define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO]) @@ -1313,6 +1327,8 @@ ucontext_t *uc = puc; #elif defined(__OpenBSD__) struct sigcontext *uc = puc; +#elif defined(__FreeBSD__) + ucontext_t *uc = puc; #else struct ucontext *uc = puc; #endif From alex at 154cm.com Fri Oct 9 23:10:03 2009 From: alex at 154cm.com (Alexander K. Beros) Date: Fri Oct 9 23:10:15 2009 Subject: linux-f10-pango Message-ID: <20091009154320.f83e18f8440bd2ef381fd3fda3c93f72.22ec53800b.wbe@email.secureserver.net> portaudit returns a warning regarding linux-f10-pango-1.22.3 which is the current port. I cam across comments by bsam at http://www.freebsd.org/cgi/query-pr.cgi?pr=136321 regarding rpms.... I think you will need to work with the f11 rpm http://mirror.switch.ch/ftp/mirror/fedora/linux/releases/11/Fedora/source/SRPMS/pango-1.24.1-1.fc11.src.rpm best, alex From bsam at ipt.ru Sat Oct 10 09:12:12 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sat Oct 10 09:12:19 2009 Subject: linux-f10-pango In-Reply-To: <20091009154320.f83e18f8440bd2ef381fd3fda3c93f72.22ec53800b.wbe@email.secureserver.net> (Alexander K. Beros's message of "Fri, 09 Oct 2009 15:43:20 -0700") References: <20091009154320.f83e18f8440bd2ef381fd3fda3c93f72.22ec53800b.wbe@email.secureserver.net> Message-ID: <90552214@bb.ipt.ru> On Fri, 09 Oct 2009 15:43:20 -0700 Alexander K. Beros wrote: > portaudit returns a warning regarding linux-f10-pango-1.22.3 which is > the current port. > I cam across comments by bsam at > http://www.freebsd.org/cgi/query-pr.cgi?pr=136321 > regarding rpms.... > I think you will need to work with the f11 rpm > http://mirror.switch.ch/ftp/mirror/fedora/linux/releases/11/Fedora/source/SRPMS/pango-1.24.1-1.fc11.src.rpm Thanks for the feedback. Unfortunately we don't use f11 ports so far. If you can integrate this port alone to our currnet linux ports infrastructure please submit a PR. If vulnarable apps are not fixed upsteam then someone may take sources and compile custom distfile. I'm not sure how much work will it take. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From nox at jelal.kn-bremen.de Sun Oct 11 23:06:54 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Oct 11 23:07:01 2009 Subject: playing with qemu usermode emulation on FreeBSD... In-Reply-To: <20091007220549.GA65997@triton8.kn-bremen.de> References: <20091007220549.GA65997@triton8.kn-bremen.de> Message-ID: <20091011221840.GA55502@triton8.kn-bremen.de> On Thu, Oct 08, 2009 at 12:05:49AM +0200, Juergen Lock wrote: > I recently noticed there are x86 bsd-user targets now (yeah I totally > missed those commits...) and now got it working a tiny little bit: > I can run > qemu-x86_64 -bsd freebsd /rescue/echo foo bar > here on FreeBSD 8/amd64 and it echoes foo bar as expected, but > segfaults afterwards. :) (in pthread_setcancelstate() invoked from > a guest write() syscall, in case anyone is wondering.) Other things > I tried either exit with errors or segfault as well, and i386 hosts > probably still don't work at all yet. (qemu-i386 here on amd64 does > at least something, but probably needs lock_user() treatment for all > kinds of syscalls, I only tried adding that for sysctl so far.) > > Anyway, here is an emulators/qemu-devel git head snapshot port > update with my current patches (files/patch-bsd-user), feel free to > test/debug/improve: > http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch > (For the folks reading this on the qemu list: I shall start doing > `proper' patch submissions later, this is more for the FreeBSD folks > and because I was asked to send what I have...) New version at the same place, which now runs FreeBSD/{i386,sparc64} /rescue/echo on FreeBSD/amd64, the FreeBSD/amd64 target now segfaults in pthread_setcancelstate() invoked from the final writev() tho. Oh and I also uploaded the snapshot tarball so others can now actually build the port too... :) And I have switched to the cpu-exec.c patch posted by Aleksej Saushev on the qemu list and added back amd64 code there. Here is the bsd-user patch again: Index: qemu/bsd-user/elfload.c @@ -126,6 +126,8 @@ static inline void init_thread(struct ta regs->rax = 0; regs->rsp = infop->start_stack; regs->rip = infop->entry; + if (1 /* bsd_type == target_freebsd */) + regs->rdi = infop->start_stack; } #else @@ -249,8 +251,13 @@ static inline void init_thread(struct ta #else if (personality(infop->personality) == PER_LINUX32) regs->u_regs[14] = infop->start_stack - 16 * 4; - else + else { regs->u_regs[14] = infop->start_stack - 16 * 8 - STACK_BIAS; + if (1 /* bsd_type == target_freebsd */) { + regs->u_regs[8] = infop->start_stack; + regs->u_regs[11] = infop->start_stack; + } + } #endif } Index: qemu/bsd-user/freebsd/strace.list @@ -39,6 +39,7 @@ { TARGET_FREEBSD_NR_ftruncate, "ftruncate", NULL, NULL, NULL }, { TARGET_FREEBSD_NR_futimes, "futimes", NULL, NULL, NULL }, { TARGET_FREEBSD_NR_getdirentries, "getdirentries", NULL, NULL, NULL }, +{ TARGET_FREEBSD_NR_freebsd6_mmap, "freebsd6_mmap", NULL, NULL, NULL }, { TARGET_FREEBSD_NR_getegid, "getegid", "%s()", NULL, NULL }, { TARGET_FREEBSD_NR_geteuid, "geteuid", "%s()", NULL, NULL }, { TARGET_FREEBSD_NR_getfh, "getfh", NULL, NULL, NULL }, Index: qemu/bsd-user/main.c @@ -179,27 +179,86 @@ void cpu_loop(CPUX86State *env, enum BSD switch(trapnr) { case 0x80: /* syscall from int $0x80 */ - env->regs[R_EAX] = do_openbsd_syscall(env, - env->regs[R_EAX], - env->regs[R_EBX], - env->regs[R_ECX], - env->regs[R_EDX], - env->regs[R_ESI], - env->regs[R_EDI], - env->regs[R_EBP]); + if (bsd_type == target_freebsd) { + abi_ulong params = (abi_ulong) env->regs[R_ESP] + + sizeof(int32_t); + int32_t syscall_nr = env->regs[R_EAX]; + int32_t arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8; + + if (syscall_nr == TARGET_FREEBSD_NR_syscall) { + get_user_s32(syscall_nr, params); + params += sizeof(int32_t); + } else if (syscall_nr == TARGET_FREEBSD_NR___syscall) { + get_user_s32(syscall_nr, params); + params += sizeof(int64_t); + } + get_user_s32(arg1, params); + params += sizeof(int32_t); + get_user_s32(arg2, params); + params += sizeof(int32_t); + get_user_s32(arg3, params); + params += sizeof(int32_t); + get_user_s32(arg4, params); + params += sizeof(int32_t); + get_user_s32(arg5, params); + params += sizeof(int32_t); + get_user_s32(arg6, params); + params += sizeof(int32_t); + get_user_s32(arg7, params); + params += sizeof(int32_t); + get_user_s32(arg8, params); + env->regs[R_EAX] = do_freebsd_syscall(env, + syscall_nr, + arg1, + arg2, + arg3, + arg4, + arg5, + arg6, + arg7, + arg8); + } else { //if (bsd_type == target_openbsd) + env->regs[R_EAX] = do_openbsd_syscall(env, + env->regs[R_EAX], + env->regs[R_EBX], + env->regs[R_ECX], + env->regs[R_EDX], + env->regs[R_ESI], + env->regs[R_EDI], + env->regs[R_EBP]); + } + if (((abi_ulong)env->regs[R_EAX]) >= (abi_ulong)(-515)) + env->eflags |= CC_C; + else + env->eflags &= ~CC_C; break; #ifndef TARGET_ABI32 case EXCP_SYSCALL: - /* linux syscall from syscall intruction */ - env->regs[R_EAX] = do_openbsd_syscall(env, - env->regs[R_EAX], - env->regs[R_EDI], - env->regs[R_ESI], - env->regs[R_EDX], - env->regs[10], - env->regs[8], - env->regs[9]); + /* syscall from syscall intruction */ + if (bsd_type == target_freebsd) + env->regs[R_EAX] = do_freebsd_syscall(env, + env->regs[R_EAX], + env->regs[R_EDI], + env->regs[R_ESI], + env->regs[R_EDX], + env->regs[R_ECX], + env->regs[8], + env->regs[9], 0, 0); + else { //if (bsd_type == target_openbsd) + env->regs[R_EAX] = do_openbsd_syscall(env, + env->regs[R_EAX], + env->regs[R_EDI], + env->regs[R_ESI], + env->regs[R_EDX], + env->regs[10], + env->regs[8], + env->regs[9]); + } env->eip = env->exception_next_eip; + if (((abi_ulong)env->regs[R_EAX]) >= (abi_ulong)(-515)) + env->eflags |= CC_C; + else + env->eflags &= ~CC_C; break; #endif #if 0 @@ -459,13 +518,17 @@ void cpu_loop(CPUSPARCState *env, enum B case 0x80: #else case 0x100: + /* FreeBSD uses 0x141 for syscalls too */ + case 0x141: + if (bsd_type != target_freebsd) + goto badtrap; #endif syscall_nr = env->gregs[1]; if (bsd_type == target_freebsd) ret = do_freebsd_syscall(env, syscall_nr, env->regwptr[0], env->regwptr[1], env->regwptr[2], env->regwptr[3], - env->regwptr[4], env->regwptr[5]); + env->regwptr[4], env->regwptr[5], 0, 0); else if (bsd_type == target_netbsd) ret = do_netbsd_syscall(env, syscall_nr, env->regwptr[0], env->regwptr[1], @@ -587,6 +650,9 @@ void cpu_loop(CPUSPARCState *env, enum B } break; default: +#ifdef TARGET_SPARC64 + badtrap: +#endif printf ("Unhandled trap: 0x%x\n", trapnr); cpu_dump_state(env, stderr, fprintf, 0); exit (1); Index: qemu/bsd-user/qemu.h @@ -130,7 +130,8 @@ abi_long do_brk(abi_ulong new_brk); void syscall_init(void); abi_long do_freebsd_syscall(void *cpu_env, int num, abi_long arg1, abi_long arg2, abi_long arg3, abi_long arg4, - abi_long arg5, abi_long arg6); + abi_long arg5, abi_long arg6, abi_long arg7, + abi_long arg8); abi_long do_netbsd_syscall(void *cpu_env, int num, abi_long arg1, abi_long arg2, abi_long arg3, abi_long arg4, abi_long arg5, abi_long arg6); Index: qemu/bsd-user/syscall.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include @@ -40,20 +41,222 @@ static abi_ulong target_brk; static abi_ulong target_original_brk; -#define get_errno(x) (x) +static inline abi_long get_errno(abi_long ret) +{ + if (ret == -1) + /* XXX need to translate host -> target errnos here */ + return -(errno); + else + return ret; +} + #define target_to_host_bitmask(x, tbl) (x) +static inline int is_error(abi_long ret) +{ + return (abi_ulong)ret >= (abi_ulong)(-4096); +} + void target_set_brk(abi_ulong new_brk) { target_original_brk = target_brk = HOST_PAGE_ALIGN(new_brk); } +/* do_obreak() must return target errnos. */ +static abi_long do_obreak(abi_ulong new_brk) +{ + abi_ulong brk_page; + abi_long mapped_addr; + int new_alloc_size; + + if (!new_brk) + return 0; + if (new_brk < target_original_brk) + return -TARGET_EINVAL; + + brk_page = HOST_PAGE_ALIGN(target_brk); + + /* If the new brk is less than this, set it and we're done... */ + if (new_brk < brk_page) { + target_brk = new_brk; + return 0; + } + + /* We need to allocate more memory after the brk... */ + new_alloc_size = HOST_PAGE_ALIGN(new_brk - brk_page + 1); + mapped_addr = get_errno(target_mmap(brk_page, new_alloc_size, + PROT_READ|PROT_WRITE, + MAP_ANON|MAP_FIXED|MAP_PRIVATE, -1, 0)); + + if (!is_error(mapped_addr)) + target_brk = new_brk; + else + return mapped_addr; + + return 0; +} + +#ifdef __FreeBSD__ +/* + * XXX this uses the undocumented oidfmt interface to find the kind of + * a requested sysctl, see /sys/kern/kern_sysctl.c:sysctl_sysctl_oidfmt() + * (this is mostly copied from src/sbin/sysctl/sysctl.c) + */ +static int +oidfmt(int *oid, int len, char *fmt, uint32_t *kind) +{ + int qoid[CTL_MAXNAME+2]; + uint8_t buf[BUFSIZ]; + int i; + size_t j; + + qoid[0] = 0; + qoid[1] = 4; + memcpy(qoid + 2, oid, len * sizeof(int)); + + j = sizeof(buf); + i = sysctl(qoid, len + 2, buf, &j, 0, 0); + if (i) + return i; + + if (kind) + *kind = *(uint32_t *)buf; + + if (fmt) + strcpy(fmt, (char *)(buf + sizeof(uint32_t))); + return (0); +} + +/* + * try and convert sysctl return data for the target. + * XXX doesn't handle CTLTYPE_OPAQUE and CTLTYPE_STRUCT. + */ +static int sysctl_oldcvt(void *holdp, size_t holdlen, uint32_t kind) +{ + switch (kind & CTLTYPE) { + case CTLTYPE_INT: + case CTLTYPE_UINT: + *(uint32_t *)holdp = tswap32(*(uint32_t *)holdp); + break; +#ifdef TARGET_ABI32 + case CTLTYPE_LONG: + case CTLTYPE_ULONG: + *(uint32_t *)holdp = tswap32(*(long *)holdp); + break; +#else + case CTLTYPE_LONG: + *(uint64_t *)holdp = tswap64(*(long *)holdp); + case CTLTYPE_ULONG: + *(uint64_t *)holdp = tswap64(*(unsigned long *)holdp); + break; +#endif + case CTLTYPE_QUAD: + *(uint64_t *)holdp = tswap64(*(uint64_t *)holdp); + break; + case CTLTYPE_STRING: + break; + default: + /* XXX unhandled */ + return -1; + } + return 0; +} + +/* XXX this needs to be emulated on non-FreeBSD hosts... */ +static abi_long do_freebsd_sysctl(abi_ulong namep, int32_t namelen, abi_ulong oldp, + abi_ulong oldlenp, abi_ulong newp, abi_ulong newlen) +{ + abi_long ret; + void *hnamep, *holdp, *hnewp = NULL; + size_t holdlen; + abi_ulong oldlen = 0; + int32_t *snamep = qemu_malloc(sizeof(int32_t) * namelen), *p, *q, i; + uint32_t kind = 0; + + if (oldlenp) + get_user_ual(oldlen, oldlenp); + if (!(hnamep = lock_user(VERIFY_READ, namep, namelen, 1))) + return -TARGET_EFAULT; + if (newp && !(hnewp = lock_user(VERIFY_READ, newp, newlen, 1))) + return -TARGET_EFAULT; + if (!(holdp = lock_user(VERIFY_WRITE, oldp, oldlen, 0))) + return -TARGET_EFAULT; + holdlen = oldlen; + for (p = hnamep, q = snamep, i = 0; i < namelen; p++, i++) + *q++ = tswap32(*p); + oidfmt(snamep, namelen, NULL, &kind); + /* XXX swap hnewp */ + ret = get_errno(sysctl(snamep, namelen, holdp, &holdlen, hnewp, newlen)); + if (!ret) + sysctl_oldcvt(holdp, holdlen, kind); + put_user_ual(holdlen, oldlenp); + unlock_user(hnamep, namep, 0); + unlock_user(holdp, oldp, holdlen); + if (hnewp) + unlock_user(hnewp, newp, 0); + qemu_free(snamep); + return ret; +} +#endif + +/* FIXME + * lock_iovec()/unlock_iovec() have a return code of 0 for success where + * other lock functions have a return code of 0 for failure. + */ +static abi_long lock_iovec(int type, struct iovec *vec, abi_ulong target_addr, + int count, int copy) +{ + struct target_iovec *target_vec; + abi_ulong base; + int i; + + target_vec = lock_user(VERIFY_READ, target_addr, count * sizeof(struct target_iovec), 1); + if (!target_vec) + return -TARGET_EFAULT; + for(i = 0;i < count; i++) { + base = tswapl(target_vec[i].iov_base); + vec[i].iov_len = tswapl(target_vec[i].iov_len); + if (vec[i].iov_len != 0) { + vec[i].iov_base = lock_user(type, base, vec[i].iov_len, copy); + /* Don't check lock_user return value. We must call writev even + if a element has invalid base address. */ + } else { + /* zero length pointer is ignored */ + vec[i].iov_base = NULL; + } + } + unlock_user (target_vec, target_addr, 0); + return 0; +} + +static abi_long unlock_iovec(struct iovec *vec, abi_ulong target_addr, + int count, int copy) +{ + struct target_iovec *target_vec; + abi_ulong base; + int i; + + target_vec = lock_user(VERIFY_READ, target_addr, count * sizeof(struct target_iovec), 1); + if (!target_vec) + return -TARGET_EFAULT; + for(i = 0;i < count; i++) { + if (target_vec[i].iov_base) { + base = tswapl(target_vec[i].iov_base); + unlock_user(vec[i].iov_base, base, copy ? vec[i].iov_len : 0); + } + } + unlock_user (target_vec, target_addr, 0); + + return 0; +} + /* do_syscall() should always have a single exit point at the end so that actions, such as logging of syscall results, can be performed. All errnos that do_syscall() returns must be -TARGET_. */ abi_long do_freebsd_syscall(void *cpu_env, int num, abi_long arg1, abi_long arg2, abi_long arg3, abi_long arg4, - abi_long arg5, abi_long arg6) + abi_long arg5, abi_long arg6, abi_long arg7, + abi_long arg8) { abi_long ret; void *p; @@ -86,6 +289,18 @@ abi_long do_freebsd_syscall(void *cpu_en ret = get_errno(write(arg1, p, arg3)); unlock_user(p, arg2, 0); break; + case TARGET_FREEBSD_NR_writev: + { + int count = arg3; + struct iovec *vec; + + vec = alloca(count * sizeof(struct iovec)); + if (lock_iovec(VERIFY_READ, vec, arg2, count, 1) < 0) + goto efault; + ret = get_errno(writev(arg1, vec, count)); + unlock_iovec(vec, arg2, count, 0); + } + break; case TARGET_FREEBSD_NR_open: if (!(p = lock_user_string(arg1))) goto efault; @@ -103,12 +318,20 @@ abi_long do_freebsd_syscall(void *cpu_en case TARGET_FREEBSD_NR_mprotect: ret = get_errno(target_mprotect(arg1, arg2, arg3)); break; + case TARGET_FREEBSD_NR_break: + ret = do_obreak(arg1); + break; +#ifdef __FreeBSD__ + case TARGET_FREEBSD_NR___sysctl: + ret = do_freebsd_sysctl(arg1, arg2, arg3, arg4, arg5, arg6); + break; +#endif case TARGET_FREEBSD_NR_syscall: case TARGET_FREEBSD_NR___syscall: - ret = do_freebsd_syscall(cpu_env,arg1 & 0xffff,arg2,arg3,arg4,arg5,arg6,0); + ret = do_freebsd_syscall(cpu_env,arg1 & 0xffff,arg2,arg3,arg4,arg5,arg6,arg7,arg8,0); break; default: - ret = syscall(num, arg1, arg2, arg3, arg4, arg5, arg6); + ret = get_errno(syscall(num, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8)); break; } fail: Index: qemu/bsd-user/syscall_defs.h @@ -106,3 +106,9 @@ #include "freebsd/syscall_nr.h" #include "netbsd/syscall_nr.h" #include "openbsd/syscall_nr.h" + +struct target_iovec { + abi_long iov_base; /* Starting address */ + abi_long iov_len; /* Number of bytes */ +}; + Index: qemu/cpu-exec.c @@ -805,6 +805,20 @@ static inline int handle_cpu_signal(unsi # define TRAP_sig(context) ((context)->uc_mcontext->es.trapno) # define ERROR_sig(context) ((context)->uc_mcontext->es.err) # define MASK_sig(context) ((context)->uc_sigmask) +#elif defined (__NetBSD__) +# include + +# define EIP_sig(context) ((context)->uc_mcontext.__gregs[_REG_EIP]) +# define TRAP_sig(context) ((context)->uc_mcontext.__gregs[_REG_TRAPNO]) +# define ERROR_sig(context) ((context)->uc_mcontext.__gregs[_REG_ERR]) +# define MASK_sig(context) ((context)->uc_sigmask) +#elif defined (__FreeBSD__) || defined(__DragonFly__) +# include + +# define EIP_sig(context) (*((unsigned long*)&(context)->uc_mcontext.mc_eip)) +# define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) +# define ERROR_sig(context) ((context)->uc_mcontext.mc_err) +# define MASK_sig(context) ((context)->uc_sigmask) #elif defined(__OpenBSD__) # define EIP_sig(context) ((context)->sc_eip) # define TRAP_sig(context) ((context)->sc_trapno) @@ -821,7 +835,9 @@ int cpu_signal_handler(int host_signum, void *puc) { siginfo_t *info = pinfo; -#if defined(__OpenBSD__) +#if defined(__NetBSD__) || defined (__FreeBSD__) || defined(__DragonFly__) + ucontext_t *uc = puc; +#elif defined(__OpenBSD__) struct sigcontext *uc = puc; #else struct ucontext *uc = puc; @@ -855,6 +871,13 @@ int cpu_signal_handler(int host_signum, #define TRAP_sig(context) ((context)->sc_trapno) #define ERROR_sig(context) ((context)->sc_err) #define MASK_sig(context) ((context)->sc_mask) +#elif defined (__FreeBSD__) || defined(__DragonFly__) +#include + +#define PC_sig(context) (*((unsigned long*)&(context)->uc_mcontext.mc_rip)) +#define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) +#define ERROR_sig(context) ((context)->uc_mcontext.mc_err) +#define MASK_sig(context) ((context)->uc_sigmask) #else #define PC_sig(context) ((context)->uc_mcontext.gregs[REG_RIP]) #define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO]) @@ -867,7 +890,7 @@ int cpu_signal_handler(int host_signum, { siginfo_t *info = pinfo; unsigned long pc; -#ifdef __NetBSD__ +#if defined(__NetBSD__) || defined (__FreeBSD__) || defined(__DragonFly__) ucontext_t *uc = puc; #elif defined(__OpenBSD__) struct sigcontext *uc = puc; From Trond.Endrestol at fagskolen.gjovik.no Mon Oct 12 09:38:56 2009 From: Trond.Endrestol at fagskolen.gjovik.no (=?ISO-8859-1?Q?Trond_Endrest=F8l?=) Date: Mon Oct 12 09:39:03 2009 Subject: Any chance of an upgraded x11-toolkits/linux-pango? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Until we're all ready to move to 8.0, those of us who wants to run Adobe Reader 9.1.3 on 7.2 have no other option but to use x11-toolkits/linux-pango along with emulators/linux_base-fc4. I know the native x11-toolkits/pango was updated to correct for the integer overflow bug, but what about x11-toolkits/linux-pango? Please fix x11-toolkits/linux-pango. Best regards, Trond Endrest?l. - -- - ---------------------------------------------------------------------- Trond Endrest?l | Trond.Endrestol@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 7.2-STABLE & Alpine 2.00 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkrS+SYACgkQbYWZalUoElsIcgCcDz0u+7aX0pUYPcmFxBtnIPKk sgcAnRj4JsUzui70FqlqWytdago0vY+y =H/vn -----END PGP SIGNATURE----- From bugmaster at FreeBSD.org Mon Oct 12 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:07:46 2009 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200910121106.n9CB6oSr036350@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/138944 emulation [parallels] [regression] Parallels no longer works in o kern/138880 emulation [linux] munmap segfaults after linux_mmap2 stresstest o ports/137332 emulation add caution messages to some adobe products f ports/136321 emulation x11-toolkits/linux-pango: please update linux based po o ports/136229 emulation [linux] certain linux apps look for libraries using a o ports/135337 emulation [PATCH] emulators/linux_base-f10: incorrect bash usage o ports/135322 emulation Port graphics/linux_dri has incorrect packaging list c o kern/130724 emulation [linprocfs] [patch] cpuinfo in linprocfs is dated, cau o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n f ports/127018 emulation Linuxulator incapable of using FreeBSD's LDAP environm o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/56451 emulation [linprocfs] /compat/linux/proc/cpuinfo gives wrong CPU o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 20 problems total. From mlobo at digiart.art.br Mon Oct 12 14:00:04 2009 From: mlobo at digiart.art.br (Mario Lobo) Date: Mon Oct 12 14:00:11 2009 Subject: Problem with FreeBSD port Message-ID: <200910121059.26357.mlobo@digiart.art.br> Hi; I've been following the FreeBSD port through svn.bluelife.at. Up to revision 508, everything was fine. On Rev 519 (or before, i'm not sure), the port was split into 3. virtualbox, virtualbox-additions and virtualbox- kmod. There is no problem building virtualbox-kmod. and virtualbox. The modules load without errors and virtualbox starts fine. But when I try to start a VM I get this: 00:00:00.644 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={0a51994b- cbc6-4686-94eb-d4e4023280e2} aComponent={Console} aText={Failed to open the host network interface re0} aWarning=false, preserve=false 00:00:00.654 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={0a51994b- cbc6-4686-94eb-d4e4023280e2} aComponent={Console} aText={Failed to initialize Host Interface Networking (VERR_HOSTIF_INIT_FAILED). 00:00:00.654 Unknown error creating VM (VERR_HOSTIF_INIT_FAILED)} aWarning=false, preserve=false 00:00:00.658 Power up failed (vrc=VERR_HOSTIF_INIT_FAILED, rc=NS_ERROR_FAILURE (0X80004005)) kldstat Id Refs Address Size Name 1 60 0xffffffff80100000 caeef0 kernel 2 2 0xffffffff80daf000 41110 linux.ko 3 1 0xffffffff80df1000 5b58 snd_cmi.ko 4 3 0xffffffff80df7000 755a8 sound.ko 5 1 0xffffffff80e6d000 27d8 amdtemp.ko 6 1 0xffffffff80e70000 3e20 amdsmb.ko 7 2 0xffffffff80e74000 24d8 smbus.ko 8 2 0xffffffff80e77000 227d8 drm.ko 9 2 0xffffffff80e9a000 12c88 agp.ko 10 1 0xffffffff80ead000 712e0 radeon.ko 11 1 0xffffffff80f1f000 5278 atapicam.ko 12 1 0xffffffff80f25000 fff0 cpufreq.ko 13 1 0xffffffff81022000 3983 linprocfs.ko 14 3 0xffffffff81026000 22db6 vboxdrv.ko 15 2 0xffffffff81049000 26ce vboxnetflt.ko 16 2 0xffffffff8104c000 8d2c netgraph.ko 17 1 0xffffffff81055000 13a6 ng_ether.ko 18 1 0xffffffff81057000 d2c vboxnetadp.ko 19 1 0xffffffff81058000 a8ca fuse.ko 20 1 0xffffffff81063000 b5b2 ext2fs.ko It is as if virtualbox can't "see" that the modules ARE loaded, and connect to them. If I revert to the previous version (with the modules compiled together with virtualbox), everything works again. OS: FreeBSD 8.0-RC1 #0: Sat Oct 10 16:16:42 BRT 2009 amd64 Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE) From decke at bluelife.at Mon Oct 12 15:02:15 2009 From: decke at bluelife.at (Bernhard Froehlich) Date: Mon Oct 12 15:02:22 2009 Subject: Problem with FreeBSD port In-Reply-To: <200910121059.26357.mlobo@digiart.art.br> References: <200910121059.26357.mlobo@digiart.art.br> Message-ID: <0e2aa8e0f2a8a179f3c90b7dc7ad7bfb.squirrel@webmail.itac.at> On Mon, October 12, 2009 3:59 pm, Mario Lobo wrote: > Hi; > > I've been following the FreeBSD port through svn.bluelife.at. > > Up to revision 508, everything was fine. On Rev 519 (or before, i'm not > sure), > the port was split into 3. virtualbox, virtualbox-additions and > virtualbox- > kmod. > > > There is no problem building virtualbox-kmod. and virtualbox. The modules > load > without errors and virtualbox starts fine. But when I try to start a VM I > get > this: > > 00:00:00.644 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) > aIID={0a51994b- > cbc6-4686-94eb-d4e4023280e2} aComponent={Console} aText={Failed to open > the > host network interface re0} aWarning=false, preserve=false > > 00:00:00.654 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) > aIID={0a51994b- > cbc6-4686-94eb-d4e4023280e2} aComponent={Console} aText={Failed to > initialize > Host Interface Networking (VERR_HOSTIF_INIT_FAILED). > > 00:00:00.654 Unknown error creating VM (VERR_HOSTIF_INIT_FAILED)} > aWarning=false, preserve=false > > 00:00:00.658 Power up failed (vrc=VERR_HOSTIF_INIT_FAILED, > rc=NS_ERROR_FAILURE > (0X80004005)) > > kldstat > Id Refs Address Size Name > 1 60 0xffffffff80100000 caeef0 kernel > 2 2 0xffffffff80daf000 41110 linux.ko > 3 1 0xffffffff80df1000 5b58 snd_cmi.ko > 4 3 0xffffffff80df7000 755a8 sound.ko > 5 1 0xffffffff80e6d000 27d8 amdtemp.ko > 6 1 0xffffffff80e70000 3e20 amdsmb.ko > 7 2 0xffffffff80e74000 24d8 smbus.ko > 8 2 0xffffffff80e77000 227d8 drm.ko > 9 2 0xffffffff80e9a000 12c88 agp.ko > 10 1 0xffffffff80ead000 712e0 radeon.ko > 11 1 0xffffffff80f1f000 5278 atapicam.ko > 12 1 0xffffffff80f25000 fff0 cpufreq.ko > 13 1 0xffffffff81022000 3983 linprocfs.ko > 14 3 0xffffffff81026000 22db6 vboxdrv.ko > 15 2 0xffffffff81049000 26ce vboxnetflt.ko > 16 2 0xffffffff8104c000 8d2c netgraph.ko > 17 1 0xffffffff81055000 13a6 ng_ether.ko > 18 1 0xffffffff81057000 d2c vboxnetadp.ko > 19 1 0xffffffff81058000 a8ca fuse.ko > 20 1 0xffffffff81063000 b5b2 ext2fs.ko > > It is as if virtualbox can't "see" that the modules ARE loaded, and > connect to > them. > > If I revert to the previous version (with the modules compiled together > with > virtualbox), everything works again. > > OS: > FreeBSD 8.0-RC1 #0: Sat Oct 10 16:16:42 BRT 2009 amd64 > Good that you have found the correct mailinglist. FreeBSD related vbox problems are best discussed on freebsd-emulation@ and if we need help from upstream we contact vbox-dev@ or a few people on the virtualbox side in private to not annoy them with common or FreeBSD specific problems. The current svn version is very experimental as they have recently changed a lot of build and kernel module related things so i am not very surprised that this code doesn't work at the moment. I have an FreeBSD 8.0-RC1/amd64 box standing around so i will test it myself and see what we get. -- Bernhard Fr?hlich http://www.bluelife.at/ From oberman at es.net Mon Oct 12 15:07:41 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Oct 12 15:07:49 2009 Subject: Any chance of an upgraded x11-toolkits/linux-pango? In-Reply-To: Your message of "Mon, 12 Oct 2009 11:38:42 +0200." Message-ID: <20091012150728.6AD6E1CC45@ptavv.es.net> > Date: Mon, 12 Oct 2009 11:38:42 +0200 (CEST) > From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= > Sender: owner-freebsd-emulation@freebsd.org > > Hi, > > Until we're all ready to move to 8.0, those of us who wants to run > Adobe Reader 9.1.3 on 7.2 have no other option but to use > x11-toolkits/linux-pango along with emulators/linux_base-fc4. > > I know the native x11-toolkits/pango was updated to correct for the > integer overflow bug, but what about x11-toolkits/linux-pango? > > Please fix x11-toolkits/linux-pango. The number of systems that are running Fedora Core 4 are very few and far between. I doubt that it will ever be fixed. A better answer is to upgrade your system to use Fedora 10. It works fine on 7.2 systems. If you upgrade, look at the messages on upgrading the Linux emulation in /usr/port/UPDATING 20090401. Note the sysctls and make requirements. After upgrading linux_base to F10, you will need to re-install almost all linux-* ports to the linux-f10-* version. linux-nvu and linux-realplayer are exceptions. That said, linux-f10-pango is also now listed as vulnerable, and I am unsure when it will be updated, though discussion has been on-going for the past three or four days. Hopefully someone with an Fedora 10 system can build a new RPM to fix it. Rumor has it that pango built on a Fedora 11 system will also work, but I have no confirmation of that. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From Trond.Endrestol at fagskolen.gjovik.no Mon Oct 12 16:12:29 2009 From: Trond.Endrestol at fagskolen.gjovik.no (=?ISO-8859-1?Q?Trond_Endrest=F8l?=) Date: Mon Oct 12 16:12:36 2009 Subject: Any chance of an upgraded x11-toolkits/linux-pango? In-Reply-To: <20091012150728.6AD6E1CC45@ptavv.es.net> References: <20091012150728.6AD6E1CC45@ptavv.es.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 12 Oct 2009 08:07-0700, Kevin Oberman wrote: > The number of systems that are running Fedora Core 4 are very few and > far between. I doubt that it will ever be fixed. A better answer is to > upgrade your system to use Fedora 10. It works fine on 7.2 systems. Oh, I thought that would require me to upgrade to 8.0. I learned something today. > If you upgrade, look at the messages on upgrading the Linux emulation in > /usr/port/UPDATING 20090401. Note the sysctls and make requirements. April Fool's Day? No seriously, thank you for pointing me in the right direction. Trond. - -- - ---------------------------------------------------------------------- Trond Endrest?l | Trond.Endrestol@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX | FreeBSD 7.2-STABLE & Alpine 2.00 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkrTVVwACgkQbYWZalUoEluitgCeNLmjCDZJ2cnFh7h/VKSgikzO XqQAnjPu3vvo9gCv+4E0Zar+FbFBWgGL =2JWs -----END PGP SIGNATURE----- From blauwirbel at gmail.com Mon Oct 12 20:15:58 2009 From: blauwirbel at gmail.com (Blue Swirl) Date: Mon Oct 12 20:16:04 2009 Subject: [Qemu-devel] Re: playing with qemu usermode emulation on FreeBSD... In-Reply-To: <20091011221840.GA55502@triton8.kn-bremen.de> References: <20091007220549.GA65997@triton8.kn-bremen.de> <20091011221840.GA55502@triton8.kn-bremen.de> Message-ID: On Mon, Oct 12, 2009 at 1:18 AM, Juergen Lock wrote: > On Thu, Oct 08, 2009 at 12:05:49AM +0200, Juergen Lock wrote: >> I recently noticed there are x86 bsd-user targets now (yeah I totally >> missed those commits...) and now got it working a tiny little bit: >> I can run >> ? ? ? qemu-x86_64 -bsd freebsd /rescue/echo foo bar >> here on FreeBSD 8/amd64 and it echoes foo bar as expected, but >> segfaults afterwards. :) ?(in pthread_setcancelstate() invoked from >> a guest write() syscall, in case anyone is wondering.) ?Other things >> I tried either exit with errors or segfault as well, and i386 hosts >> probably still don't work at all yet. ?(qemu-i386 here on amd64 does >> at least something, but probably needs lock_user() treatment for all >> kinds of syscalls, I only tried adding that for sysctl so far.) >> >> ?Anyway, here is an emulators/qemu-devel git head snapshot port >> update with my current patches (files/patch-bsd-user), feel free to >> test/debug/improve: >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch >> (For the folks reading this on the qemu list: ?I shall start doing >> `proper' patch submissions later, this is more for the FreeBSD folks >> and because I was asked to send what I have...) > > New version at the same place, which now runs FreeBSD/{i386,sparc64} > /rescue/echo on FreeBSD/amd64, the FreeBSD/amd64 target now segfaults > in pthread_setcancelstate() invoked from the final writev() tho. > Oh and I also uploaded the snapshot tarball so others can now actually > build the port too... :) ?And I have switched to the cpu-exec.c patch > posted by Aleksej Saushev on the qemu list and added back amd64 > code there. > > ?Here is the bsd-user patch again: Please add Signed-off-by: line and use 'diff -u' (or preferably git diff). > + ? ?if (1 /* bsd_type == target_freebsd */) > + ? ? ? ?regs->rdi = infop->start_stack; Why the if and comment? > + ? ? ? ?if (1 /* bsd_type == target_freebsd */) { > + ? ? ? ? ? ?regs->u_regs[8] = infop->start_stack; > + ? ? ? ? ? ?regs->u_regs[11] = infop->start_stack; Same here. > ? ? ? ? case 0x100: > + ? ? ? ?/* FreeBSD uses 0x141 for syscalls too */ > + ? ? ? ?case 0x141: > + ? ? ? ? ? ?if (bsd_type != target_freebsd) > + ? ? ? ? ? ? ? ?goto badtrap; You are now also trapping on case 0x100 if bsd_type != target_freebsd, which probably breaks other BSDs. > +/* XXX this needs to be emulated on non-FreeBSD hosts... */ > +static abi_long do_freebsd_sysctl(abi_ulong namep, int32_t namelen, abi_ulong oldp, > + ? ? ? ? ? ? ? ? ? ? ? ? ?abi_ulong oldlenp, abi_ulong newp, abi_ulong newlen) What kind of call is this, is it possible to emulate on other BSDs? Is it important? I'm just wondering if the cross-BSD emulation makes sense after all. It would make the emulator much simpler if we could assume that host_bsdness == target_bsdness. From nox at jelal.kn-bremen.de Mon Oct 12 22:22:53 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Mon Oct 12 22:23:00 2009 Subject: [Qemu-devel] Re: playing with qemu usermode emulation on FreeBSD... In-Reply-To: References: <20091007220549.GA65997@triton8.kn-bremen.de> <20091011221840.GA55502@triton8.kn-bremen.de> Message-ID: <20091012222058.GA43121@triton8.kn-bremen.de> On Mon, Oct 12, 2009 at 10:55:24PM +0300, Blue Swirl wrote: > On Mon, Oct 12, 2009 at 1:18 AM, Juergen Lock wrote: > > On Thu, Oct 08, 2009 at 12:05:49AM +0200, Juergen Lock wrote: > >> I recently noticed there are x86 bsd-user targets now (yeah I totally > >> missed those commits...) and now got it working a tiny little bit: > >> I can run > >> ? ? ? qemu-x86_64 -bsd freebsd /rescue/echo foo bar > >> here on FreeBSD 8/amd64 and it echoes foo bar as expected, but > >> segfaults afterwards. :) ?(in pthread_setcancelstate() invoked from > >> a guest write() syscall, in case anyone is wondering.) ?Other things > >> I tried either exit with errors or segfault as well, and i386 hosts > >> probably still don't work at all yet. ?(qemu-i386 here on amd64 does > >> at least something, but probably needs lock_user() treatment for all > >> kinds of syscalls, I only tried adding that for sysctl so far.) > >> > >> ?Anyway, here is an emulators/qemu-devel git head snapshot port > >> update with my current patches (files/patch-bsd-user), feel free to > >> test/debug/improve: > >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch > >> (For the folks reading this on the qemu list: ?I shall start doing > >> `proper' patch submissions later, this is more for the FreeBSD folks > >> and because I was asked to send what I have...) > > > > New version at the same place, which now runs FreeBSD/{i386,sparc64} > > /rescue/echo on FreeBSD/amd64, the FreeBSD/amd64 target now segfaults > > in pthread_setcancelstate() invoked from the final writev() tho. > > Oh and I also uploaded the snapshot tarball so others can now actually > > build the port too... :) ?And I have switched to the cpu-exec.c patch > > posted by Aleksej Saushev on the qemu list and added back amd64 > > code there. > > > > ?Here is the bsd-user patch again: > > Please add Signed-off-by: line and use 'diff -u' (or preferably git diff). > Well I wasn't expecting this diff to be committed just yet anyway, it's still more a wip version... > > + ? ?if (1 /* bsd_type == target_freebsd */) > > + ? ? ? ?regs->rdi = infop->start_stack; > > Why the if and comment? > > > + ? ? ? ?if (1 /* bsd_type == target_freebsd */) { > > + ? ? ? ? ? ?regs->u_regs[8] = infop->start_stack; > > + ? ? ? ? ? ?regs->u_regs[11] = infop->start_stack; > > Same here. > Because bsd_type isn't available at these places in the code but probably should be checked, I still wanted to fix that. (Maybe make it global?) > > ? ? ? ? case 0x100: > > + ? ? ? ?/* FreeBSD uses 0x141 for syscalls too */ > > + ? ? ? ?case 0x141: > > + ? ? ? ? ? ?if (bsd_type != target_freebsd) > > + ? ? ? ? ? ? ? ?goto badtrap; > > You are now also trapping on case 0x100 if bsd_type != target_freebsd, > which probably breaks other BSDs. > Right, thats broken, the 0x141 case should come before the 0x100 here of course. > > +/* XXX this needs to be emulated on non-FreeBSD hosts... */ > > +static abi_long do_freebsd_sysctl(abi_ulong namep, int32_t namelen, abi_ulong oldp, > > + ? ? ? ? ? ? ? ? ? ? ? ? ?abi_ulong oldlenp, abi_ulong newp, abi_ulong newlen) > > What kind of call is this, is it possible to emulate on other BSDs? Is > it important? Its used mostly for things that on linux is done by manipulating /proc or /sys, like getting the kernel version, number of cpus, pagesize, etc. - and there are also sysctls that can be written to, like to enable ip forwarding or change sysV ipc settings. Although changes are usually restriced to root so `regular' executables rarely do them and I'm not really handling those yet. See here: http://www.freebsd.org/cgi/man.cgi?query=sysctl&apropos=0&sektion=3&manpath=FreeBSD+7.2-RELEASE&format=html > I'm just wondering if the cross-BSD emulation makes > sense after all. It would make the emulator much simpler if we could > assume that host_bsdness == target_bsdness. Yeah I was wondering about that too... Cheers, Juergen From bsam at FreeBSD.org Tue Oct 13 08:05:36 2009 From: bsam at FreeBSD.org (bsam@FreeBSD.org) Date: Tue Oct 13 08:05:43 2009 Subject: ports/135322: Port graphics/linux_dri has incorrect packaging list causing automatic port update to fail Message-ID: <200910130805.n9D85aHG069110@freefall.freebsd.org> Synopsis: Port graphics/linux_dri has incorrect packaging list causing automatic port update to fail State-Changed-From-To: open->feedback State-Changed-By: bsam State-Changed-When: Tue Oct 13 08:03:45 UTC 2009 State-Changed-Why: All ports has been fixed. Can you confirm that? http://www.freebsd.org/cgi/query-pr.cgi?pr=135322 From mlobo at digiart.art.br Tue Oct 13 12:28:30 2009 From: mlobo at digiart.art.br (Mario Lobo) Date: Tue Oct 13 12:28:38 2009 Subject: Problem with FreeBSD port (re-post) Message-ID: <200910130927.58883.mlobo@digiart.art.br> Hi; I've been following the FreeBSD port through svn.bluelife.at. Up to revision 508, everything was fine. On Rev 519 (or before, i'm not sure), the port was split into 3. virtualbox, virtualbox-additions and virtualbox- kmod. There is no problem building virtualbox-kmod. and virtualbox. The modules load without errors and virtualbox starts fine. But when I try to start a VM I get this: 00:00:00.644 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={0a51994b- cbc6-4686-94eb-d4e4023280e2} aComponent={Console} aText={Failed to open the host network interface re0} aWarning=false, preserve=false 00:00:00.654 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={0a51994b- cbc6-4686-94eb-d4e4023280e2} aComponent={Console} aText={Failed to initialize Host Interface Networking (VERR_HOSTIF_INIT_FAILED). 00:00:00.654 Unknown error creating VM (VERR_HOSTIF_INIT_FAILED)} aWarning=false, preserve=false 00:00:00.658 Power up failed (vrc=VERR_HOSTIF_INIT_FAILED, rc=NS_ERROR_FAILURE (0X80004005)) Neither "Bridge adapter" or "host only" are avaliable anymore. kldstat Id Refs Address Size Name 1 60 0xffffffff80100000 caeef0 kernel 2 2 0xffffffff80daf000 41110 linux.ko 3 1 0xffffffff80df1000 3ec0 ng_ether.ko 4 3 0xffffffff80df5000 14d78 netgraph.ko 5 1 0xffffffff80e0a000 5b58 snd_cmi.ko 6 3 0xffffffff80e10000 755a8 sound.ko 7 1 0xffffffff80e86000 27d8 amdtemp.ko 8 1 0xffffffff80e89000 3e20 amdsmb.ko 9 2 0xffffffff80e8d000 24d8 smbus.ko 10 2 0xffffffff80e90000 227d8 drm.ko 11 2 0xffffffff80eb3000 12c88 agp.ko 12 1 0xffffffff80ec6000 712e0 radeon.ko 13 3 0xffffffff80f38000 41070 vboxdrv.ko 14 2 0xffffffff80f7a000 6c40 vboxnetflt.ko 15 1 0xffffffff80f81000 25e8 vboxnetadp.ko 16 1 0xffffffff80f84000 5278 atapicam.ko 17 1 0xffffffff80f8a000 fff0 cpufreq.ko 18 1 0xffffffff81022000 3983 linprocfs.ko 19 1 0xffffffff81026000 a8ca fuse.ko 20 1 0xffffffff81031000 b5b2 ext2fs.ko [~]>ifconfig re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:19:66:d7:a3:45 inet 10.10.10.2 netmask 0xffffff00 broadcast 10.10.10.255 media: Ethernet autoselect (100baseTX ) status: active vboxnet0: flags=8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 It is as if virtualbox can't "see" that the modules ARE loaded, and "connect" to them. If I revert to the previous version (with the modules compiled together with virtualbox - ports/emulators/virtualbox/Makefile,v 1.3 2009/06/15 22:24:42 nox Exp $), everything works again. OS: FreeBSD 8.0-RC1 #0: Sat Oct 10 16:16:42 BRT 2009 amd64 Any suggestions? Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE) From miwi at FreeBSD.org Tue Oct 13 13:43:18 2009 From: miwi at FreeBSD.org (Martin Wilke) Date: Tue Oct 13 13:43:57 2009 Subject: Problem with FreeBSD port (re-post) In-Reply-To: <200910130927.58883.mlobo@digiart.art.br> References: <200910130927.58883.mlobo@digiart.art.br> Message-ID: <20091013134315.GL80150@bsdcrew.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 13, 2009 at 09:27:58AM -0300, Mario Lobo wrote: > Hi; > > I've been following the FreeBSD port through svn.bluelife.at. > > Up to revision 508, everything was fine. On Rev 519 (or before, i'm not sure), > the port was split into 3. virtualbox, virtualbox-additions and virtualbox- > kmod. > Mario, PLEASE PLEASE Stop now your cross posting, we are know about that error and we're working on that error. BUT we've ever said svn.bluelife.at. is our developers repo SO PLEASE DON'T BUG us for any errors in bluelife, if we're not call for test. At the moment we're working on a split of virtualbox and kernel module that's why you have the error. We call for testing if we are think it's ready for a public test. - - Martin on behalf of FreeBSD vbox team > > There is no problem building virtualbox-kmod. and virtualbox. The modules load > without errors and virtualbox starts fine. But when I try to start a VM I get > this: > > 00:00:00.644 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={0a51994b- > cbc6-4686-94eb-d4e4023280e2} aComponent={Console} aText={Failed to open the > host network interface re0} aWarning=false, preserve=false > > 00:00:00.654 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={0a51994b- > cbc6-4686-94eb-d4e4023280e2} aComponent={Console} aText={Failed to initialize > Host Interface Networking (VERR_HOSTIF_INIT_FAILED). > > 00:00:00.654 Unknown error creating VM (VERR_HOSTIF_INIT_FAILED)} > aWarning=false, preserve=false > > 00:00:00.658 Power up failed (vrc=VERR_HOSTIF_INIT_FAILED, rc=NS_ERROR_FAILURE > (0X80004005)) > > Neither "Bridge adapter" or "host only" are avaliable anymore. > > > kldstat > Id Refs Address Size Name > 1 60 0xffffffff80100000 caeef0 kernel > 2 2 0xffffffff80daf000 41110 linux.ko > 3 1 0xffffffff80df1000 3ec0 ng_ether.ko > 4 3 0xffffffff80df5000 14d78 netgraph.ko > 5 1 0xffffffff80e0a000 5b58 snd_cmi.ko > 6 3 0xffffffff80e10000 755a8 sound.ko > 7 1 0xffffffff80e86000 27d8 amdtemp.ko > 8 1 0xffffffff80e89000 3e20 amdsmb.ko > 9 2 0xffffffff80e8d000 24d8 smbus.ko > 10 2 0xffffffff80e90000 227d8 drm.ko > 11 2 0xffffffff80eb3000 12c88 agp.ko > 12 1 0xffffffff80ec6000 712e0 radeon.ko > 13 3 0xffffffff80f38000 41070 vboxdrv.ko > 14 2 0xffffffff80f7a000 6c40 vboxnetflt.ko > 15 1 0xffffffff80f81000 25e8 vboxnetadp.ko > 16 1 0xffffffff80f84000 5278 atapicam.ko > 17 1 0xffffffff80f8a000 fff0 cpufreq.ko > 18 1 0xffffffff81022000 3983 linprocfs.ko > 19 1 0xffffffff81026000 a8ca fuse.ko > 20 1 0xffffffff81031000 b5b2 ext2fs.ko > > [~]>ifconfig > re0: flags=8843 metric 0 mtu 1500 > options=389b > ether 00:19:66:d7:a3:45 > inet 10.10.10.2 netmask 0xffffff00 broadcast 10.10.10.255 > media: Ethernet autoselect (100baseTX ) > status: active > vboxnet0: flags=8802 metric 0 mtu 1500 > ether 0a:00:27:00:00:00 > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > > > It is as if virtualbox can't "see" that the modules ARE loaded, and "connect" > to them. > > If I revert to the previous version (with the modules compiled together with > virtualbox - ports/emulators/virtualbox/Makefile,v 1.3 2009/06/15 22:24:42 nox > Exp $), everything works again. > > OS: > FreeBSD 8.0-RC1 #0: Sat Oct 10 16:16:42 BRT 2009 amd64 > > Any suggestions? > > Thanks, > -- > Mario Lobo > http://www.mallavoodoo.com.br > FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE) > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org" > - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkrUg/MACgkQdLJIhLHm/OnTQACfReH8isBs2VPWroEyAyJw3hUK m1QAn04EiNZVRCFMu8c5B4WRiqX1RdIM =4/Au -----END PGP SIGNATURE----- From mlobo at digiart.art.br Tue Oct 13 14:04:10 2009 From: mlobo at digiart.art.br (Mario Lobo) Date: Tue Oct 13 14:04:15 2009 Subject: Problem with FreeBSD port (re-post) In-Reply-To: <20091013134315.GL80150@bsdcrew.de> References: <200910130927.58883.mlobo@digiart.art.br> <20091013134315.GL80150@bsdcrew.de> Message-ID: <200910131103.42148.mlobo@digiart.art.br> On Tuesday 13 October 2009 10:43:15 Martin Wilke wrote: > > Mario, > > PLEASE PLEASE Stop now your cross posting, we are know about that error > and we're working on that error. BUT we've ever said svn.bluelife.at. > is our developers repo SO PLEASE DON'T BUG us for any errors in bluelife, > if we're not call for test. I am aware of that. My only wish was to contribute but please forgive my wrong approach. > At the moment we're working on a split of virtualbox and kernel module > that's why you have the error. We call for testing if we are think > it's ready for a public test. > > - Martin on behalf of FreeBSD vbox team I'll just seat quietly and keep on trying what comes out of svn (just like I've been doing all along). Sorry about the noise. It won't happen again. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winedows FREE) From nox at jelal.kn-bremen.de Tue Oct 13 22:21:06 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Tue Oct 13 22:21:13 2009 Subject: [Qemu-devel] Re: playing with qemu usermode emulation on FreeBSD... In-Reply-To: <20091012222058.GA43121@triton8.kn-bremen.de> References: <20091007220549.GA65997@triton8.kn-bremen.de> <20091011221840.GA55502@triton8.kn-bremen.de> <20091012222058.GA43121@triton8.kn-bremen.de> Message-ID: <20091013221932.GA32808@triton8.kn-bremen.de> On Tue, Oct 13, 2009 at 12:20:58AM +0200, Juergen Lock wrote: > On Mon, Oct 12, 2009 at 10:55:24PM +0300, Blue Swirl wrote: > > On Mon, Oct 12, 2009 at 1:18 AM, Juergen Lock wrote: > > > On Thu, Oct 08, 2009 at 12:05:49AM +0200, Juergen Lock wrote: > > >> I recently noticed there are x86 bsd-user targets now (yeah I totally > > >> missed those commits...) and now got it working a tiny little bit: > > >> I can run > > >> ? ? ? qemu-x86_64 -bsd freebsd /rescue/echo foo bar > > >> here on FreeBSD 8/amd64 and it echoes foo bar as expected, but > > >> segfaults afterwards. :) ?(in pthread_setcancelstate() invoked from > > >> a guest write() syscall, in case anyone is wondering.) ?Other things > > >> I tried either exit with errors or segfault as well, and i386 hosts > > >> probably still don't work at all yet. ?(qemu-i386 here on amd64 does > > >> at least something, but probably needs lock_user() treatment for all > > >> kinds of syscalls, I only tried adding that for sysctl so far.) > > >> > > >> ?Anyway, here is an emulators/qemu-devel git head snapshot port > > >> update with my current patches (files/patch-bsd-user), feel free to > > >> test/debug/improve: > > >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch > > >> (For the folks reading this on the qemu list: ?I shall start doing > > >> `proper' patch submissions later, this is more for the FreeBSD folks > > >> and because I was asked to send what I have...) > > > > > > New version at the same place, which now runs FreeBSD/{i386,sparc64} > > > /rescue/echo on FreeBSD/amd64, the FreeBSD/amd64 target now segfaults > > > in pthread_setcancelstate() invoked from the final writev() tho. > > > Oh and I also uploaded the snapshot tarball so others can now actually > > > build the port too... :) ?And I have switched to the cpu-exec.c patch > > > posted by Aleksej Saushev on the qemu list and added back amd64 > > > code there. > > > > > > ?Here is the bsd-user patch again: > > > > Please add Signed-off-by: line and use 'diff -u' (or preferably git diff). > > > Well I wasn't expecting this diff to be committed just yet anyway, > it's still more a wip version... > > > > + ? ?if (1 /* bsd_type == target_freebsd */) > > > + ? ? ? ?regs->rdi = infop->start_stack; > > > > Why the if and comment? > > > > > + ? ? ? ?if (1 /* bsd_type == target_freebsd */) { > > > + ? ? ? ? ? ?regs->u_regs[8] = infop->start_stack; > > > + ? ? ? ? ? ?regs->u_regs[11] = infop->start_stack; > > > > Same here. > > > Because bsd_type isn't available at these places in the code but > probably should be checked, I still wanted to fix that. (Maybe > make it global?) > I still haven't fixed this... > > > ? ? ? ? case 0x100: > > > + ? ? ? ?/* FreeBSD uses 0x141 for syscalls too */ > > > + ? ? ? ?case 0x141: > > > + ? ? ? ? ? ?if (bsd_type != target_freebsd) > > > + ? ? ? ? ? ? ? ?goto badtrap; > > > > You are now also trapping on case 0x100 if bsd_type != target_freebsd, > > which probably breaks other BSDs. > > > Right, thats broken, the 0x141 case should come before the 0x100 > here of course. > ...but this I just fixed, and I added the multiboot.S patch, and fixed the port's cdrom dma disable knob (files/cdrom-dma-patch). (And I added the cpu-exec.c whitspace fix that was already in the patch I posted in the BSD support thread.) New version at the same place, http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch and I now also made a shar of the patched port: http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.shar Cheers, Juergen From jstub at jstub.com Thu Oct 15 16:13:47 2009 From: jstub at jstub.com (John B. Stubblebine) Date: Thu Oct 15 16:13:58 2009 Subject: FreeBSD Port: acroread9-9.2 Message-ID: <4AD74421.8020807@jstub.com> To: hrs (acroread), ports (cc: recipient for these ports), freebsd-emulation (linux-pango), I tried to "make install" for acroread9 and it failed with the messages that follow in the "ps" below. Acroread9 depends on "linux-pango-1.10.2_3" and others. Linux-pango did not "make" because of a defect. The messages include the URL: http://portaudit.freebsd.org/4b172278-3f46-11de-becb-001cc0377035.html This link says that a defect is in all: pango < 1.24 linux-pango < 1.24 linux-f8-pango < 1.24 linux-f10-pango < 1.24 I updated the ports tree, but the Make file still refers to: linux-pango-1.10.2_3 In addition, looking for "linux-pango" in the ports collection on FreeBSD.org shows only linux-pango version 1.10.2_3. So how do I get linux-pango 1.24, or later?? And if so, will acroread9 "make install" successfully? I looked at the "pango" web site: http://ftp.gnome.org/pub/GNOME/sources/pango/ and found that there are source versions of "pango" up to 1.26. It seems there is a need to upgrade all of the "pango" ports to 1.24 or later, and the make files for all the ports that use it, and perhaps some other aspects of those ports as well. I do not have the skills to do this. I am hoping that you can help. -- Best regards, John B. Stubblebine jstub@jstub.com ps: Pertinant output for failed "make install" for acroread9: ===> Running linux ldconfig /compat/linux/sbin/ldconfig -r /compat/linux ===> Registering installation for linux-jpeg-6b.34_2 ===> Returning to build of linux-gtk2-2.6.10_3 ===> linux-gtk2-2.6.10_3 depends on file: /compat/linux/usr/lib/libpango-1.0.so.0.1001.1 - not found ===> Verifying install for /compat/linux/usr/lib/libpango-1.0.so.0.1001.1 in/usr/ports/x11-toolkits/linux-pango ===> linux-pango-1.10.2_3 has known vulnerabilities: => pango -- integer overflow. Reference: => Please update your ports tree and try again. *** Error code 1 Stop in /usr/ports/x11-toolkits/linux-pango. *** Error code 1 Stop in /usr/ports/x11-toolkits/linux-gtk2. *** Error code 1 Stop in /usr/ports/print/acroread9. gw2# gw2# uname -a FreeBSD gw2.jstub.com 7.2-RELEASE-p3 FreeBSD 7.2-RELEASE-p3 #0: Thu Jul 30 06:20:21 PDT 2009 root@gw2.jstub.com:/usr/obj/usr/src/sys/GENERIC i386 gw2# pwd /usr/ports/print/acroread9 gw2# From naylor.b.david at gmail.com Thu Oct 15 18:11:11 2009 From: naylor.b.david at gmail.com (David Naylor) Date: Thu Oct 15 18:11:17 2009 Subject: VirtualBox: vboxnetflt related problems Message-ID: <200910151950.26620.naylor.b.david@gmail.com> Hi, Thanks for porting VirtualBox, it has proven most useful (no more slow RDC). I've found some problems relating to VirtualBox's bridged networking: 1) loader doesn't pull in all the dependencies for vboxnetflt (kldload does) [missing dependencies: ng_ether] 2) even with the dependencies specified in loader.conf vboxnetflt fails to initialise on boot [module_register_init: MOD_LOAD (ng_vboxnetflt, 0xc0f44fd9, 0xc19bd6a0) error 22] 3) bridging doesn't work when connecting to bridge0 or tap0: # netstat -w1 -I tap0 input (tap0) output packets errs bytes packets errs bytes colls 0 0 0 0 0 0 0 0 0 0 0 2 151 0 ... This happen with and without giving tap0 an IP address. This is using version virtualbox-3.0.51.r22902_2 from ports (recompiled today). Regards, David P.S. please CC me as I am not subscribed to mailing list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20091015/14089b97/attachment.pgp From nox at jelal.kn-bremen.de Fri Oct 16 22:39:09 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Fri Oct 16 22:39:16 2009 Subject: [Qemu-devel] Re: playing with qemu usermode emulation on FreeBSD... In-Reply-To: <20091013221932.GA32808@triton8.kn-bremen.de> References: <20091007220549.GA65997@triton8.kn-bremen.de> <20091011221840.GA55502@triton8.kn-bremen.de> <20091012222058.GA43121@triton8.kn-bremen.de> <20091013221932.GA32808@triton8.kn-bremen.de> Message-ID: <20091016223426.GA54110@triton8.kn-bremen.de> On Wed, Oct 14, 2009 at 12:19:32AM +0200, Juergen Lock wrote: > On Tue, Oct 13, 2009 at 12:20:58AM +0200, Juergen Lock wrote: > > On Mon, Oct 12, 2009 at 10:55:24PM +0300, Blue Swirl wrote: > > > On Mon, Oct 12, 2009 at 1:18 AM, Juergen Lock wrote: > > > > On Thu, Oct 08, 2009 at 12:05:49AM +0200, Juergen Lock wrote: > > > >> I recently noticed there are x86 bsd-user targets now (yeah I totally > > > >> missed those commits...) and now got it working a tiny little bit: > > > >> I can run > > > >> ? ? ? qemu-x86_64 -bsd freebsd /rescue/echo foo bar > > > >> here on FreeBSD 8/amd64 and it echoes foo bar as expected, but > > > >> segfaults afterwards. :) ?(in pthread_setcancelstate() invoked from > > > >> a guest write() syscall, in case anyone is wondering.) ?Other things > > > >> I tried either exit with errors or segfault as well, and i386 hosts > > > >> probably still don't work at all yet. ?(qemu-i386 here on amd64 does > > > >> at least something, but probably needs lock_user() treatment for all > > > >> kinds of syscalls, I only tried adding that for sysctl so far.) > > > >> > > > >> ?Anyway, here is an emulators/qemu-devel git head snapshot port > > > >> update with my current patches (files/patch-bsd-user), feel free to > > > >> test/debug/improve: > > > >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch > > > >> (For the folks reading this on the qemu list: ?I shall start doing > > > >> `proper' patch submissions later, this is more for the FreeBSD folks > > > >> and because I was asked to send what I have...) > > > > > > > > New version at the same place, which now runs FreeBSD/{i386,sparc64} > > > > /rescue/echo on FreeBSD/amd64, the FreeBSD/amd64 target now segfaults > > > > in pthread_setcancelstate() invoked from the final writev() tho. > > > > Oh and I also uploaded the snapshot tarball so others can now actually > > > > build the port too... :) ?And I have switched to the cpu-exec.c patch > > > > posted by Aleksej Saushev on the qemu list and added back amd64 > > > > code there. > > > > > > > > ?Here is the bsd-user patch again: > > > > > > Please add Signed-off-by: line and use 'diff -u' (or preferably git diff). > > > > > Well I wasn't expecting this diff to be committed just yet anyway, > > it's still more a wip version... > > > > > > + ? ?if (1 /* bsd_type == target_freebsd */) > > > > + ? ? ? ?regs->rdi = infop->start_stack; > > > > > > Why the if and comment? > > > > > > > + ? ? ? ?if (1 /* bsd_type == target_freebsd */) { > > > > + ? ? ? ? ? ?regs->u_regs[8] = infop->start_stack; > > > > + ? ? ? ? ? ?regs->u_regs[11] = infop->start_stack; > > > > > > Same here. > > > > > Because bsd_type isn't available at these places in the code but > > probably should be checked, I still wanted to fix that. (Maybe > > make it global?) > > > I still haven't fixed this... > > > > > ? ? ? ? case 0x100: > > > > + ? ? ? ?/* FreeBSD uses 0x141 for syscalls too */ > > > > + ? ? ? ?case 0x141: > > > > + ? ? ? ? ? ?if (bsd_type != target_freebsd) > > > > + ? ? ? ? ? ? ? ?goto badtrap; > > > > > > You are now also trapping on case 0x100 if bsd_type != target_freebsd, > > > which probably breaks other BSDs. > > > > > Right, thats broken, the 0x141 case should come before the 0x100 > > here of course. > > > ...but this I just fixed, and I added the multiboot.S patch, and > fixed the port's cdrom dma disable knob (files/cdrom-dma-patch). > (And I added the cpu-exec.c whitspace fix that was already in the > patch I posted in the BSD support thread.) > > New version at the same place, > http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch > and I now also made a shar of the patched port: > http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.shar Updated again, among other things I added basic FreeBSD sysarch(2) handling, fixed syscall errno return (I had added code to set the carry bit for the x86 target before but the sign of the returned errno was still wrong), and I finally fixed the if (1) above (made bsd_type global.) And, I now can run FreeBSD/amd64 /bin/sh and vim on same! :) (zsh not yet tho.) Oh and Toni tested taking FreeBSD/i386's default linker script, changing only the load address to 0x60000000 as in qemu's and, using that as i386.ld, he now can run qemu-i386 on FreeBSD/i386 with simple executables too... See files/patch-bsd-user-ld in the shar, which I also now moved the x86_64.ld patch to that I had talked about earlier. It probably can't be used everywhere as is tho since it has: OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd", "elf32-i386-freebsd") (and I also don't know if the one currently in the tree has other features that are needed at least on Linux, any linker gurus care to comment?) Here is the rest of the bsd-user patches again (files/patch-bsd-user in the shar), if you think they are ready to commit I'm not against it anymore :), comments are also welcome of course. Thanx, Juergen --- a/bsd-user/elfload.c +++ b/bsd-user/elfload.c @@ -126,6 +126,9 @@ static inline void init_thread(struct ta regs->rax = 0; regs->rsp = infop->start_stack; regs->rip = infop->entry; + if (bsd_type == target_freebsd) { + regs->rdi = infop->start_stack; + } } #else @@ -249,8 +252,13 @@ static inline void init_thread(struct ta #else if (personality(infop->personality) == PER_LINUX32) regs->u_regs[14] = infop->start_stack - 16 * 4; - else + else { regs->u_regs[14] = infop->start_stack - 16 * 8 - STACK_BIAS; + if (bsd_type == target_freebsd) { + regs->u_regs[8] = infop->start_stack; + regs->u_regs[11] = infop->start_stack; + } + } #endif } --- a/bsd-user/freebsd/strace.list +++ b/bsd-user/freebsd/strace.list @@ -39,6 +39,7 @@ { TARGET_FREEBSD_NR_ftruncate, "ftruncate", NULL, NULL, NULL }, { TARGET_FREEBSD_NR_futimes, "futimes", NULL, NULL, NULL }, { TARGET_FREEBSD_NR_getdirentries, "getdirentries", NULL, NULL, NULL }, +{ TARGET_FREEBSD_NR_freebsd6_mmap, "freebsd6_mmap", NULL, NULL, NULL }, { TARGET_FREEBSD_NR_getegid, "getegid", "%s()", NULL, NULL }, { TARGET_FREEBSD_NR_geteuid, "geteuid", "%s()", NULL, NULL }, { TARGET_FREEBSD_NR_getfh, "getfh", NULL, NULL, NULL }, --- a/bsd-user/i386/syscall.h +++ b/bsd-user/i386/syscall.h @@ -143,5 +143,19 @@ struct target_vm86plus_struct { struct target_vm86plus_info_struct vm86plus; }; +/* FreeBSD sysarch(2) */ +#define TARGET_FREEBSD_I386_GET_LDT 0 +#define TARGET_FREEBSD_I386_SET_LDT 1 + /* I386_IOPL */ +#define TARGET_FREEBSD_I386_GET_IOPERM 3 +#define TARGET_FREEBSD_I386_SET_IOPERM 4 + /* xxxxx */ +#define TARGET_FREEBSD_I386_VM86 6 +#define TARGET_FREEBSD_I386_GET_FSBASE 7 +#define TARGET_FREEBSD_I386_SET_FSBASE 8 +#define TARGET_FREEBSD_I386_GET_GSBASE 9 +#define TARGET_FREEBSD_I386_SET_GSBASE 10 + + #define UNAME_MACHINE "i386" --- a/bsd-user/main.c +++ b/bsd-user/main.c @@ -46,6 +46,7 @@ int have_guest_base; static const char *interp_prefix = CONFIG_QEMU_PREFIX; const char *qemu_uname_release = CONFIG_UNAME_RELEASE; extern char **environ; +enum BSDType bsd_type; /* XXX: on x86 MAP_GROWSDOWN only works if ESP <= address + 32, so we allocate a bigger stack. Need a better solution, for example @@ -168,7 +169,7 @@ static void set_idt(int n, unsigned int } #endif -void cpu_loop(CPUX86State *env, enum BSDType bsd_type) +void cpu_loop(CPUX86State *env) { int trapnr; abi_ulong pc; @@ -179,27 +180,90 @@ void cpu_loop(CPUX86State *env, enum BSD switch(trapnr) { case 0x80: /* syscall from int $0x80 */ - env->regs[R_EAX] = do_openbsd_syscall(env, - env->regs[R_EAX], - env->regs[R_EBX], - env->regs[R_ECX], - env->regs[R_EDX], - env->regs[R_ESI], - env->regs[R_EDI], - env->regs[R_EBP]); + if (bsd_type == target_freebsd) { + abi_ulong params = (abi_ulong) env->regs[R_ESP] + + sizeof(int32_t); + int32_t syscall_nr = env->regs[R_EAX]; + int32_t arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8; + + if (syscall_nr == TARGET_FREEBSD_NR_syscall) { + get_user_s32(syscall_nr, params); + params += sizeof(int32_t); + } else if (syscall_nr == TARGET_FREEBSD_NR___syscall) { + get_user_s32(syscall_nr, params); + params += sizeof(int64_t); + } + get_user_s32(arg1, params); + params += sizeof(int32_t); + get_user_s32(arg2, params); + params += sizeof(int32_t); + get_user_s32(arg3, params); + params += sizeof(int32_t); + get_user_s32(arg4, params); + params += sizeof(int32_t); + get_user_s32(arg5, params); + params += sizeof(int32_t); + get_user_s32(arg6, params); + params += sizeof(int32_t); + get_user_s32(arg7, params); + params += sizeof(int32_t); + get_user_s32(arg8, params); + env->regs[R_EAX] = do_freebsd_syscall(env, + syscall_nr, + arg1, + arg2, + arg3, + arg4, + arg5, + arg6, + arg7, + arg8); + } else { //if (bsd_type == target_openbsd) + env->regs[R_EAX] = do_openbsd_syscall(env, + env->regs[R_EAX], + env->regs[R_EBX], + env->regs[R_ECX], + env->regs[R_EDX], + env->regs[R_ESI], + env->regs[R_EDI], + env->regs[R_EBP]); + } + if (((abi_ulong)env->regs[R_EAX]) >= (abi_ulong)(-515)) { + env->regs[R_EAX] = -env->regs[R_EAX]; + env->eflags |= CC_C; + } else { + env->eflags &= ~CC_C; + } break; #ifndef TARGET_ABI32 case EXCP_SYSCALL: - /* linux syscall from syscall intruction */ - env->regs[R_EAX] = do_openbsd_syscall(env, - env->regs[R_EAX], - env->regs[R_EDI], - env->regs[R_ESI], - env->regs[R_EDX], - env->regs[10], - env->regs[8], - env->regs[9]); + /* syscall from syscall intruction */ + if (bsd_type == target_freebsd) + env->regs[R_EAX] = do_freebsd_syscall(env, + env->regs[R_EAX], + env->regs[R_EDI], + env->regs[R_ESI], + env->regs[R_EDX], + env->regs[R_ECX], + env->regs[8], + env->regs[9], 0, 0); + else { //if (bsd_type == target_openbsd) + env->regs[R_EAX] = do_openbsd_syscall(env, + env->regs[R_EAX], + env->regs[R_EDI], + env->regs[R_ESI], + env->regs[R_EDX], + env->regs[10], + env->regs[8], + env->regs[9]); + } env->eip = env->exception_next_eip; + if (((abi_ulong)env->regs[R_EAX]) >= (abi_ulong)(-515)) { + env->regs[R_EAX] = -env->regs[R_EAX]; + env->eflags |= CC_C; + } else { + env->eflags &= ~CC_C; + } break; #endif #if 0 @@ -446,7 +510,7 @@ static void flush_windows(CPUSPARCState #endif } -void cpu_loop(CPUSPARCState *env, enum BSDType bsd_type) +void cpu_loop(CPUSPARCState *env) { int trapnr, ret, syscall_nr; //target_siginfo_t info; @@ -458,6 +522,10 @@ void cpu_loop(CPUSPARCState *env, enum B #ifndef TARGET_SPARC64 case 0x80: #else + /* FreeBSD uses 0x141 for syscalls too */ + case 0x141: + if (bsd_type != target_freebsd) + goto badtrap; case 0x100: #endif syscall_nr = env->gregs[1]; @@ -465,7 +533,7 @@ void cpu_loop(CPUSPARCState *env, enum B ret = do_freebsd_syscall(env, syscall_nr, env->regwptr[0], env->regwptr[1], env->regwptr[2], env->regwptr[3], - env->regwptr[4], env->regwptr[5]); + env->regwptr[4], env->regwptr[5], 0, 0); else if (bsd_type == target_netbsd) ret = do_netbsd_syscall(env, syscall_nr, env->regwptr[0], env->regwptr[1], @@ -482,6 +550,7 @@ void cpu_loop(CPUSPARCState *env, enum B env->regwptr[4], env->regwptr[5]); } if ((unsigned int)ret >= (unsigned int)(-515)) { + ret = -ret; #if defined(TARGET_SPARC64) && !defined(TARGET_ABI32) env->xcc |= PSR_CARRY; #else @@ -587,6 +656,9 @@ void cpu_loop(CPUSPARCState *env, enum B } break; default: +#ifdef TARGET_SPARC64 + badtrap: +#endif printf ("Unhandled trap: 0x%x\n", trapnr); cpu_dump_state(env, stderr, fprintf, 0); exit (1); @@ -668,7 +740,7 @@ int main(int argc, char **argv) int gdbstub_port = 0; char **target_environ, **wrk; envlist_t *envlist = NULL; - enum BSDType bsd_type = target_openbsd; + bsd_type = target_openbsd; if (argc <= 1) usage(); @@ -1033,7 +1105,7 @@ int main(int argc, char **argv) gdbserver_start (gdbstub_port); gdb_handlesig(env, 0); } - cpu_loop(env, bsd_type); + cpu_loop(env); /* never exits */ return 0; } --- a/bsd-user/qemu.h +++ b/bsd-user/qemu.h @@ -18,6 +18,7 @@ enum BSDType { target_netbsd, target_openbsd, }; +extern enum BSDType bsd_type; #include "syscall_defs.h" #include "syscall.h" @@ -130,7 +131,8 @@ abi_long do_brk(abi_ulong new_brk); void syscall_init(void); abi_long do_freebsd_syscall(void *cpu_env, int num, abi_long arg1, abi_long arg2, abi_long arg3, abi_long arg4, - abi_long arg5, abi_long arg6); + abi_long arg5, abi_long arg6, abi_long arg7, + abi_long arg8); abi_long do_netbsd_syscall(void *cpu_env, int num, abi_long arg1, abi_long arg2, abi_long arg3, abi_long arg4, abi_long arg5, abi_long arg6); @@ -139,7 +141,7 @@ abi_long do_openbsd_syscall(void *cpu_en abi_long arg5, abi_long arg6); void gemu_log(const char *fmt, ...) __attribute__((format(printf,1,2))); extern THREAD CPUState *thread_env; -void cpu_loop(CPUState *env, enum BSDType bsd_type); +void cpu_loop(CPUState *env); char *target_strerror(int err); int get_osversion(void); void fork_start(void); --- a/bsd-user/syscall.c +++ b/bsd-user/syscall.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include @@ -40,20 +41,283 @@ static abi_ulong target_brk; static abi_ulong target_original_brk; -#define get_errno(x) (x) +static inline abi_long get_errno(abi_long ret) +{ + if (ret == -1) + /* XXX need to translate host -> target errnos here */ + return -(errno); + else + return ret; +} + #define target_to_host_bitmask(x, tbl) (x) +static inline int is_error(abi_long ret) +{ + return (abi_ulong)ret >= (abi_ulong)(-4096); +} + void target_set_brk(abi_ulong new_brk) { target_original_brk = target_brk = HOST_PAGE_ALIGN(new_brk); } +/* do_obreak() must return target errnos. */ +static abi_long do_obreak(abi_ulong new_brk) +{ + abi_ulong brk_page; + abi_long mapped_addr; + int new_alloc_size; + + if (!new_brk) + return 0; + if (new_brk < target_original_brk) + return -TARGET_EINVAL; + + brk_page = HOST_PAGE_ALIGN(target_brk); + + /* If the new brk is less than this, set it and we're done... */ + if (new_brk < brk_page) { + target_brk = new_brk; + return 0; + } + + /* We need to allocate more memory after the brk... */ + new_alloc_size = HOST_PAGE_ALIGN(new_brk - brk_page + 1); + mapped_addr = get_errno(target_mmap(brk_page, new_alloc_size, + PROT_READ|PROT_WRITE, + MAP_ANON|MAP_FIXED|MAP_PRIVATE, -1, 0)); + + if (!is_error(mapped_addr)) + target_brk = new_brk; + else + return mapped_addr; + + return 0; +} + +#if defined(TARGET_I386) +static abi_long do_freebsd_sysarch(CPUX86State *env, int op, abi_ulong parms) +{ + abi_long ret = 0; + abi_ulong val; + int idx; + + switch(op) { +#ifdef TARGET_ABI32 + case TARGET_FREEBSD_I386_SET_GSBASE: + case TARGET_FREEBSD_I386_SET_FSBASE: + if (op == TARGET_FREEBSD_I386_SET_GSBASE) +#else + case TARGET_FREEBSD_AMD64_SET_GSBASE: + case TARGET_FREEBSD_AMD64_SET_FSBASE: + if (op == TARGET_FREEBSD_AMD64_SET_GSBASE) +#endif + idx = R_GS; + else + idx = R_FS; + if (get_user(val, parms, abi_ulong)) + return -TARGET_EFAULT; + cpu_x86_load_seg(env, idx, 0); + env->segs[idx].base = val; + break; +#ifdef TARGET_ABI32 + case TARGET_FREEBSD_I386_GET_GSBASE: + case TARGET_FREEBSD_I386_GET_FSBASE: + if (op == TARGET_FREEBSD_I386_GET_GSBASE) +#else + case TARGET_FREEBSD_AMD64_GET_GSBASE: + case TARGET_FREEBSD_AMD64_GET_FSBASE: + if (op == TARGET_FREEBSD_AMD64_GET_GSBASE) +#endif + idx = R_GS; + else + idx = R_FS; + val = env->segs[idx].base; + if (put_user(val, parms, abi_ulong)) + return -TARGET_EFAULT; + break; + /* XXX handle the others... */ + default: + ret = -TARGET_EINVAL; + break; + } + return ret; +} +#endif + +#ifdef TARGET_SPARC +static abi_long do_freebsd_sysarch(void *env, int op, abi_ulong parms) +{ + /* XXX handle + * TARGET_FREEBSD_SPARC_UTRAP_INSTALL, + * TARGET_FREEBSD_SPARC_SIGTRAMP_INSTALL + */ + return -TARGET_EINVAL; +} +#endif + +#ifdef __FreeBSD__ +/* + * XXX this uses the undocumented oidfmt interface to find the kind of + * a requested sysctl, see /sys/kern/kern_sysctl.c:sysctl_sysctl_oidfmt() + * (this is mostly copied from src/sbin/sysctl/sysctl.c) + */ +static int +oidfmt(int *oid, int len, char *fmt, uint32_t *kind) +{ + int qoid[CTL_MAXNAME+2]; + uint8_t buf[BUFSIZ]; + int i; + size_t j; + + qoid[0] = 0; + qoid[1] = 4; + memcpy(qoid + 2, oid, len * sizeof(int)); + + j = sizeof(buf); + i = sysctl(qoid, len + 2, buf, &j, 0, 0); + if (i) + return i; + + if (kind) + *kind = *(uint32_t *)buf; + + if (fmt) + strcpy(fmt, (char *)(buf + sizeof(uint32_t))); + return (0); +} + +/* + * try and convert sysctl return data for the target. + * XXX doesn't handle CTLTYPE_OPAQUE and CTLTYPE_STRUCT. + */ +static int sysctl_oldcvt(void *holdp, size_t holdlen, uint32_t kind) +{ + switch (kind & CTLTYPE) { + case CTLTYPE_INT: + case CTLTYPE_UINT: + *(uint32_t *)holdp = tswap32(*(uint32_t *)holdp); + break; +#ifdef TARGET_ABI32 + case CTLTYPE_LONG: + case CTLTYPE_ULONG: + *(uint32_t *)holdp = tswap32(*(long *)holdp); + break; +#else + case CTLTYPE_LONG: + *(uint64_t *)holdp = tswap64(*(long *)holdp); + case CTLTYPE_ULONG: + *(uint64_t *)holdp = tswap64(*(unsigned long *)holdp); + break; +#endif + case CTLTYPE_QUAD: + *(uint64_t *)holdp = tswap64(*(uint64_t *)holdp); + break; + case CTLTYPE_STRING: + break; + default: + /* XXX unhandled */ + return -1; + } + return 0; +} + +/* XXX this needs to be emulated on non-FreeBSD hosts... */ +static abi_long do_freebsd_sysctl(abi_ulong namep, int32_t namelen, abi_ulong oldp, + abi_ulong oldlenp, abi_ulong newp, abi_ulong newlen) +{ + abi_long ret; + void *hnamep, *holdp, *hnewp = NULL; + size_t holdlen; + abi_ulong oldlen = 0; + int32_t *snamep = qemu_malloc(sizeof(int32_t) * namelen), *p, *q, i; + uint32_t kind = 0; + + if (oldlenp) + get_user_ual(oldlen, oldlenp); + if (!(hnamep = lock_user(VERIFY_READ, namep, namelen, 1))) + return -TARGET_EFAULT; + if (newp && !(hnewp = lock_user(VERIFY_READ, newp, newlen, 1))) + return -TARGET_EFAULT; + if (!(holdp = lock_user(VERIFY_WRITE, oldp, oldlen, 0))) + return -TARGET_EFAULT; + holdlen = oldlen; + for (p = hnamep, q = snamep, i = 0; i < namelen; p++, i++) + *q++ = tswap32(*p); + oidfmt(snamep, namelen, NULL, &kind); + /* XXX swap hnewp */ + ret = get_errno(sysctl(snamep, namelen, holdp, &holdlen, hnewp, newlen)); + if (!ret) + sysctl_oldcvt(holdp, holdlen, kind); + put_user_ual(holdlen, oldlenp); + unlock_user(hnamep, namep, 0); + unlock_user(holdp, oldp, holdlen); + if (hnewp) + unlock_user(hnewp, newp, 0); + qemu_free(snamep); + return ret; +} +#endif + +/* FIXME + * lock_iovec()/unlock_iovec() have a return code of 0 for success where + * other lock functions have a return code of 0 for failure. + */ +static abi_long lock_iovec(int type, struct iovec *vec, abi_ulong target_addr, + int count, int copy) +{ + struct target_iovec *target_vec; + abi_ulong base; + int i; + + target_vec = lock_user(VERIFY_READ, target_addr, count * sizeof(struct target_iovec), 1); + if (!target_vec) + return -TARGET_EFAULT; + for(i = 0;i < count; i++) { + base = tswapl(target_vec[i].iov_base); + vec[i].iov_len = tswapl(target_vec[i].iov_len); + if (vec[i].iov_len != 0) { + vec[i].iov_base = lock_user(type, base, vec[i].iov_len, copy); + /* Don't check lock_user return value. We must call writev even + if a element has invalid base address. */ + } else { + /* zero length pointer is ignored */ + vec[i].iov_base = NULL; + } + } + unlock_user (target_vec, target_addr, 0); + return 0; +} + +static abi_long unlock_iovec(struct iovec *vec, abi_ulong target_addr, + int count, int copy) +{ + struct target_iovec *target_vec; + abi_ulong base; + int i; + + target_vec = lock_user(VERIFY_READ, target_addr, count * sizeof(struct target_iovec), 1); + if (!target_vec) + return -TARGET_EFAULT; + for(i = 0;i < count; i++) { + if (target_vec[i].iov_base) { + base = tswapl(target_vec[i].iov_base); + unlock_user(vec[i].iov_base, base, copy ? vec[i].iov_len : 0); + } + } + unlock_user (target_vec, target_addr, 0); + + return 0; +} + /* do_syscall() should always have a single exit point at the end so that actions, such as logging of syscall results, can be performed. All errnos that do_syscall() returns must be -TARGET_. */ abi_long do_freebsd_syscall(void *cpu_env, int num, abi_long arg1, abi_long arg2, abi_long arg3, abi_long arg4, - abi_long arg5, abi_long arg6) + abi_long arg5, abi_long arg6, abi_long arg7, + abi_long arg8) { abi_long ret; void *p; @@ -86,6 +350,18 @@ abi_long do_freebsd_syscall(void *cpu_en ret = get_errno(write(arg1, p, arg3)); unlock_user(p, arg2, 0); break; + case TARGET_FREEBSD_NR_writev: + { + int count = arg3; + struct iovec *vec; + + vec = alloca(count * sizeof(struct iovec)); + if (lock_iovec(VERIFY_READ, vec, arg2, count, 1) < 0) + goto efault; + ret = get_errno(writev(arg1, vec, count)); + unlock_iovec(vec, arg2, count, 0); + } + break; case TARGET_FREEBSD_NR_open: if (!(p = lock_user_string(arg1))) goto efault; @@ -103,12 +379,23 @@ abi_long do_freebsd_syscall(void *cpu_en case TARGET_FREEBSD_NR_mprotect: ret = get_errno(target_mprotect(arg1, arg2, arg3)); break; + case TARGET_FREEBSD_NR_break: + ret = do_obreak(arg1); + break; +#ifdef __FreeBSD__ + case TARGET_FREEBSD_NR___sysctl: + ret = do_freebsd_sysctl(arg1, arg2, arg3, arg4, arg5, arg6); + break; +#endif + case TARGET_FREEBSD_NR_sysarch: + ret = do_freebsd_sysarch(cpu_env, arg1, arg2); + break; case TARGET_FREEBSD_NR_syscall: case TARGET_FREEBSD_NR___syscall: - ret = do_freebsd_syscall(cpu_env,arg1 & 0xffff,arg2,arg3,arg4,arg5,arg6,0); + ret = do_freebsd_syscall(cpu_env,arg1 & 0xffff,arg2,arg3,arg4,arg5,arg6,arg7,arg8,0); break; default: - ret = syscall(num, arg1, arg2, arg3, arg4, arg5, arg6); + ret = get_errno(syscall(num, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8)); break; } fail: --- a/bsd-user/syscall_defs.h +++ b/bsd-user/syscall_defs.h @@ -106,3 +106,9 @@ #include "freebsd/syscall_nr.h" #include "netbsd/syscall_nr.h" #include "openbsd/syscall_nr.h" + +struct target_iovec { + abi_long iov_base; /* Starting address */ + abi_long iov_len; /* Number of bytes */ +}; + --- a/bsd-user/x86_64/syscall.h +++ b/bsd-user/x86_64/syscall.h @@ -90,6 +90,24 @@ struct target_msqid64_ds { abi_ulong __unused5; }; +/* FreeBSD sysarch(2) */ +#define TARGET_FREEBSD_I386_GET_LDT 0 +#define TARGET_FREEBSD_I386_SET_LDT 1 + /* I386_IOPL */ +#define TARGET_FREEBSD_I386_GET_IOPERM 3 +#define TARGET_FREEBSD_I386_SET_IOPERM 4 + /* xxxxx */ +#define TARGET_FREEBSD_I386_GET_FSBASE 7 +#define TARGET_FREEBSD_I386_SET_FSBASE 8 +#define TARGET_FREEBSD_I386_GET_GSBASE 9 +#define TARGET_FREEBSD_I386_SET_GSBASE 10 + +#define TARGET_FREEBSD_AMD64_GET_FSBASE 128 +#define TARGET_FREEBSD_AMD64_SET_FSBASE 129 +#define TARGET_FREEBSD_AMD64_GET_GSBASE 130 +#define TARGET_FREEBSD_AMD64_SET_GSBASE 131 + + #define UNAME_MACHINE "x86_64" #define TARGET_ARCH_SET_GS 0x1001 --- a/cpu-exec.c +++ b/cpu-exec.c @@ -805,6 +805,20 @@ static inline int handle_cpu_signal(unsi # define TRAP_sig(context) ((context)->uc_mcontext->es.trapno) # define ERROR_sig(context) ((context)->uc_mcontext->es.err) # define MASK_sig(context) ((context)->uc_sigmask) +#elif defined (__NetBSD__) +# include + +# define EIP_sig(context) ((context)->uc_mcontext.__gregs[_REG_EIP]) +# define TRAP_sig(context) ((context)->uc_mcontext.__gregs[_REG_TRAPNO]) +# define ERROR_sig(context) ((context)->uc_mcontext.__gregs[_REG_ERR]) +# define MASK_sig(context) ((context)->uc_sigmask) +#elif defined (__FreeBSD__) || defined(__DragonFly__) +# include + +# define EIP_sig(context) (*((unsigned long*)&(context)->uc_mcontext.mc_eip)) +# define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) +# define ERROR_sig(context) ((context)->uc_mcontext.mc_err) +# define MASK_sig(context) ((context)->uc_sigmask) #elif defined(__OpenBSD__) # define EIP_sig(context) ((context)->sc_eip) # define TRAP_sig(context) ((context)->sc_trapno) @@ -821,7 +835,9 @@ int cpu_signal_handler(int host_signum, void *puc) { siginfo_t *info = pinfo; -#if defined(__OpenBSD__) +#if defined(__NetBSD__) || defined (__FreeBSD__) || defined(__DragonFly__) + ucontext_t *uc = puc; +#elif defined(__OpenBSD__) struct sigcontext *uc = puc; #else struct ucontext *uc = puc; @@ -855,6 +871,13 @@ int cpu_signal_handler(int host_signum, #define TRAP_sig(context) ((context)->sc_trapno) #define ERROR_sig(context) ((context)->sc_err) #define MASK_sig(context) ((context)->sc_mask) +#elif defined (__FreeBSD__) || defined(__DragonFly__) +#include + +#define PC_sig(context) (*((unsigned long*)&(context)->uc_mcontext.mc_rip)) +#define TRAP_sig(context) ((context)->uc_mcontext.mc_trapno) +#define ERROR_sig(context) ((context)->uc_mcontext.mc_err) +#define MASK_sig(context) ((context)->uc_sigmask) #else #define PC_sig(context) ((context)->uc_mcontext.gregs[REG_RIP]) #define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO]) @@ -867,7 +890,7 @@ int cpu_signal_handler(int host_signum, { siginfo_t *info = pinfo; unsigned long pc; -#ifdef __NetBSD__ +#if defined(__NetBSD__) || defined (__FreeBSD__) || defined(__DragonFly__) ucontext_t *uc = puc; #elif defined(__OpenBSD__) struct sigcontext *uc = puc; Signed-off-by: Juergen Lock From nox at jelal.kn-bremen.de Sat Oct 17 15:45:25 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat Oct 17 15:45:32 2009 Subject: how to test for linux base version? (googleearth) Message-ID: <20091017154404.GA80599@triton8.kn-bremen.de> I just got reminded to add a linux base version check to astro/google-earth (It now needs recent linux libstdc++.so.6 with GLIBCXX_3.4.9 that only is in f9 or f10, you can do objdump -T /compat/linux/usr/lib/libstdc++.so.6 |grep 'ABS.*GLIBCXX' to check) - and was wondering how to best check for that in a port. This is what I came up with so far: Index: Makefile =================================================================== RCS file: /home/pcvs/ports/astro/google-earth/Makefile,v retrieving revision 1.35 diff -u -p -r1.35 Makefile --- Makefile 24 Sep 2009 21:01:36 -0000 1.35 +++ Makefile 17 Oct 2009 15:32:22 -0000 @@ -38,6 +38,14 @@ RUN_DEPENDS+= ${LINUXBASE}/usr/lib/libGL USE_LINUX_APPS+= dri .endif +.if (${OSVERSION} < 800076 && \ + !defined(OVERRIDE_LINUX_BASE_PORT)) || \ + (defined(OVERRIDE_LINUX_BASE_PORT) && \ + !(${OVERRIDE_LINUX_BASE_PORT} == f10) || \ + ${OVERRIDE_LINUX_BASE_PORT} == f9) +IGNORE= needs at least f9 Linux base +.endif + do-extract: @${MKDIR} ${WRKSRC} @${CP} ${DISTDIR}/${DIST_SUBDIR}/${DISTFILES} ${WRKSRC} Anyone have a better idea? :) Thanx, Juergen From bsam at ipt.ru Sun Oct 18 10:06:56 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Oct 18 10:07:07 2009 Subject: FreeBSD Port: acroread9-9.2 In-Reply-To: <4AD74421.8020807@jstub.com> (John B. Stubblebine's message of "Thu\, 15 Oct 2009 08\:47\:45 -0700") References: <4AD74421.8020807@jstub.com> Message-ID: <65494917@ipt.ru> "John B. Stubblebine" writes: > So how do I get linux-pango 1.24, or later?? This is a real FAQ for some time. Please, search archieves (ports@, emulation@) and even the PR-database for the answer. -- WBR, bsam From bsam at ipt.ru Sun Oct 18 10:28:24 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Oct 18 10:28:29 2009 Subject: how to test for linux base version? (googleearth) In-Reply-To: <20091017154404.GA80599@triton8.kn-bremen.de> (Juergen Lock's message of "Sat\, 17 Oct 2009 17\:44\:04 +0200") References: <20091017154404.GA80599@triton8.kn-bremen.de> Message-ID: <99413628@ipt.ru> Juergen Lock writes: > I just got reminded to add a linux base version check to astro/google-earth > (It now needs recent linux libstdc++.so.6 with GLIBCXX_3.4.9 that only > is in f9 or f10, you can do First of, I'd recommend leaving f9 alone (I'm going to deprecate all linux base ports except fc4 and f10 soon). > objdump -T /compat/linux/usr/lib/libstdc++.so.6 |grep 'ABS.*GLIBCXX' > to check) - and was wondering how to best check for that in a port. > This is what I came up with so far: > > Index: Makefile > =================================================================== > RCS file: /home/pcvs/ports/astro/google-earth/Makefile,v > retrieving revision 1.35 > diff -u -p -r1.35 Makefile > --- Makefile 24 Sep 2009 21:01:36 -0000 1.35 > +++ Makefile 17 Oct 2009 15:32:22 -0000 > @@ -38,6 +38,14 @@ RUN_DEPENDS+= ${LINUXBASE}/usr/lib/libGL > USE_LINUX_APPS+= dri > .endif > > +.if (${OSVERSION} < 800076 && \ > + !defined(OVERRIDE_LINUX_BASE_PORT)) || \ > + (defined(OVERRIDE_LINUX_BASE_PORT) && \ > + !(${OVERRIDE_LINUX_BASE_PORT} == f10) || \ > + ${OVERRIDE_LINUX_BASE_PORT} == f9) > +IGNORE= needs at least f9 Linux base > +.endif > + > do-extract: > @${MKDIR} ${WRKSRC} > @${CP} ${DISTDIR}/${DIST_SUBDIR}/${DISTFILES} ${WRKSRC} > > Anyone have a better idea? :) I'm not sure if it's better but just an other idea: ----- .if ${OSVERSION}<7000XX /*** XX should be find out ***/ IGNORE FreeBSD>=7.X is needed with Linux emulation 2.6.x. .elif ${OSVERSION}<800076 && \ ! defined (OVERRIDE_LINUX_NONBASE_PORTS) || ! (${OVERRIDE_LINUX_NONBASE_PORTS} == f10) IGNORE= you need to use non-default linux ports (define OVERRIDE_LINUX_BASE_PORT=f10 and OVERRIDE_LINUX_NONBASE_PORTS=f10) .endif ----- This check is not strict either. The thing is that both BASE and NONBASE variables should be defined and have f10 value for OSVERSION<800076. I have an item at my TODO list to switch to using USE_LINUX=f10[+] or similar but it's not the highest priority and ENOTIME now... -- WBR, bsam From fli at shapeshifter.se Sun Oct 18 17:33:14 2009 From: fli at shapeshifter.se (Fredrik Lindberg) Date: Sun Oct 18 17:33:21 2009 Subject: VirtualBox: vboxnetflt related problems In-Reply-To: <200910151950.26620.naylor.b.david@gmail.com> References: <200910151950.26620.naylor.b.david@gmail.com> Message-ID: <4ADB515A.4050309@shapeshifter.se> David Naylor wrote: > Hi, > > Thanks for porting VirtualBox, it has proven most useful (no more slow RDC). > > I've found some problems relating to VirtualBox's bridged networking: > > 1) loader doesn't pull in all the dependencies for vboxnetflt (kldload > does) [missing dependencies: ng_ether] I couldn't figure out how properly depend on ng_ether, a simple MODULE_DEPEND does not work. I guess it's because ng_ether doesn't declare MODULE_VERSION. ng_ether *should* be loaded by the explicit kern_kldload, does this not happen on your system? > > 2) even with the dependencies specified in loader.conf vboxnetflt fails to > initialise on boot [module_register_init: MOD_LOAD (ng_vboxnetflt, 0xc0f44fd9, > 0xc19bd6a0) error 22] There is a known issue where the vboxdrv module (and thus VirtualBox) sometimes fail to see that vboxnetflt is loaded - is this what you're seeing? or does vboxnetflt simply not load at all? vnoxnetflt should load fine even without ng_ether loaded. > > 3) bridging doesn't work when connecting to bridge0 or tap0: > # netstat -w1 -I tap0 > input (tap0) output > packets errs bytes packets errs bytes colls > 0 0 0 0 0 0 0 > 0 0 0 0 2 151 0 > ... > This happen with and without giving tap0 an IP address. This is because vboxnetflt uses ng_ether and the interaction between ng_ether/bridge/tap/vboxnetflt doesn't work. Fredrik From nox at jelal.kn-bremen.de Sun Oct 18 17:43:44 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Oct 18 17:43:51 2009 Subject: how to test for linux base version? (googleearth) In-Reply-To: <99413628@ipt.ru> References: <20091017154404.GA80599@triton8.kn-bremen.de> <99413628@ipt.ru> Message-ID: <20091018174157.GB99191@triton8.kn-bremen.de> On Sun, Oct 18, 2009 at 02:30:43PM +0400, Boris Samorodov wrote: > Juergen Lock writes: > > > I just got reminded to add a linux base version check to astro/google-earth > > (It now needs recent linux libstdc++.so.6 with GLIBCXX_3.4.9 that only > > is in f9 or f10, you can do > > First of, I'd recommend leaving f9 alone (I'm going to deprecate all > linux base ports except fc4 and f10 soon). > Ah Ok. (Does f10 work well enough on 7.x yet?) > > objdump -T /compat/linux/usr/lib/libstdc++.so.6 |grep 'ABS.*GLIBCXX' > > to check) - and was wondering how to best check for that in a port. > > This is what I came up with so far: > > > > Index: Makefile > > =================================================================== > > RCS file: /home/pcvs/ports/astro/google-earth/Makefile,v > > retrieving revision 1.35 > > diff -u -p -r1.35 Makefile > > --- Makefile 24 Sep 2009 21:01:36 -0000 1.35 > > +++ Makefile 17 Oct 2009 15:32:22 -0000 > > @@ -38,6 +38,14 @@ RUN_DEPENDS+= ${LINUXBASE}/usr/lib/libGL > > USE_LINUX_APPS+= dri > > .endif > > > > +.if (${OSVERSION} < 800076 && \ > > + !defined(OVERRIDE_LINUX_BASE_PORT)) || \ > > + (defined(OVERRIDE_LINUX_BASE_PORT) && \ > > + !(${OVERRIDE_LINUX_BASE_PORT} == f10) || \ > > + ${OVERRIDE_LINUX_BASE_PORT} == f9) > > +IGNORE= needs at least f9 Linux base > > +.endif > > + > > do-extract: > > @${MKDIR} ${WRKSRC} > > @${CP} ${DISTDIR}/${DIST_SUBDIR}/${DISTFILES} ${WRKSRC} > > > > Anyone have a better idea? :) > > I'm not sure if it's better but just an other idea: > ----- > .if ${OSVERSION}<7000XX /*** XX should be find out ***/ > IGNORE FreeBSD>=7.X is needed with Linux emulation 2.6.x. > .elif ${OSVERSION}<800076 && \ > ! defined (OVERRIDE_LINUX_NONBASE_PORTS) || > ! (${OVERRIDE_LINUX_NONBASE_PORTS} == f10) > IGNORE= you need to use non-default linux ports (define OVERRIDE_LINUX_BASE_PORT=f10 and OVERRIDE_LINUX_NONBASE_PORTS=f10) > .endif > ----- In the meantime I found emulators/linux-systemsimcell does something similar, and it uses ${OSVERSION}<700055 for the first check. Does that look alright? (seems to be the last OSVERSION before 7.0-R from looking at http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#FREEBSD-VERSIONS ) > > This check is not strict either. The thing is that both BASE and NONBASE > variables should be defined and have f10 value for OSVERSION<800076. > Ok. > I have an item at my TODO list to switch to using USE_LINUX=f10[+] or > similar but it's not the highest priority and ENOTIME now... Heh yeah I guess that'd be useful here... Anyway, thanx, :) Juergen From blauwirbel at gmail.com Sun Oct 18 18:26:21 2009 From: blauwirbel at gmail.com (Blue Swirl) Date: Sun Oct 18 18:26:28 2009 Subject: [Qemu-devel] Re: playing with qemu usermode emulation on FreeBSD... In-Reply-To: <20091016223426.GA54110@triton8.kn-bremen.de> References: <20091007220549.GA65997@triton8.kn-bremen.de> <20091011221840.GA55502@triton8.kn-bremen.de> <20091012222058.GA43121@triton8.kn-bremen.de> <20091013221932.GA32808@triton8.kn-bremen.de> <20091016223426.GA54110@triton8.kn-bremen.de> Message-ID: On Sat, Oct 17, 2009 at 1:34 AM, Juergen Lock wrote: > On Wed, Oct 14, 2009 at 12:19:32AM +0200, Juergen Lock wrote: >> On Tue, Oct 13, 2009 at 12:20:58AM +0200, Juergen Lock wrote: >> > On Mon, Oct 12, 2009 at 10:55:24PM +0300, Blue Swirl wrote: >> > > On Mon, Oct 12, 2009 at 1:18 AM, Juergen Lock wrote: >> > > > On Thu, Oct 08, 2009 at 12:05:49AM +0200, Juergen Lock wrote: >> > > >> I recently noticed there are x86 bsd-user targets now (yeah I totally >> > > >> missed those commits...) and now got it working a tiny little bit: >> > > >> I can run >> > > >> ? ? ? qemu-x86_64 -bsd freebsd /rescue/echo foo bar >> > > >> here on FreeBSD 8/amd64 and it echoes foo bar as expected, but >> > > >> segfaults afterwards. :) ?(in pthread_setcancelstate() invoked from >> > > >> a guest write() syscall, in case anyone is wondering.) ?Other things >> > > >> I tried either exit with errors or segfault as well, and i386 hosts >> > > >> probably still don't work at all yet. ?(qemu-i386 here on amd64 does >> > > >> at least something, but probably needs lock_user() treatment for all >> > > >> kinds of syscalls, I only tried adding that for sysctl so far.) >> > > >> >> > > >> ?Anyway, here is an emulators/qemu-devel git head snapshot port >> > > >> update with my current patches (files/patch-bsd-user), feel free to >> > > >> test/debug/improve: >> > > >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch >> > > >> (For the folks reading this on the qemu list: ?I shall start doing >> > > >> `proper' patch submissions later, this is more for the FreeBSD folks >> > > >> and because I was asked to send what I have...) >> > > > >> > > > New version at the same place, which now runs FreeBSD/{i386,sparc64} >> > > > /rescue/echo on FreeBSD/amd64, the FreeBSD/amd64 target now segfaults >> > > > in pthread_setcancelstate() invoked from the final writev() tho. >> > > > Oh and I also uploaded the snapshot tarball so others can now actually >> > > > build the port too... :) ?And I have switched to the cpu-exec.c patch >> > > > posted by Aleksej Saushev on the qemu list and added back amd64 >> > > > code there. >> > > > >> > > > ?Here is the bsd-user patch again: >> > > >> > > Please add Signed-off-by: line and use 'diff -u' (or preferably git diff). >> > > >> > Well I wasn't expecting this diff to be committed just yet anyway, >> > it's still more a wip version... >> > >> > > > + ? ?if (1 /* bsd_type == target_freebsd */) >> > > > + ? ? ? ?regs->rdi = infop->start_stack; >> > > >> > > Why the if and comment? >> > > >> > > > + ? ? ? ?if (1 /* bsd_type == target_freebsd */) { >> > > > + ? ? ? ? ? ?regs->u_regs[8] = infop->start_stack; >> > > > + ? ? ? ? ? ?regs->u_regs[11] = infop->start_stack; >> > > >> > > Same here. >> > > >> > ?Because bsd_type isn't available at these places in the code but >> > probably should be checked, I still wanted to fix that. ?(Maybe >> > make it global?) >> > >> I still haven't fixed this... >> >> > > > ? ? ? ? case 0x100: >> > > > + ? ? ? ?/* FreeBSD uses 0x141 for syscalls too */ >> > > > + ? ? ? ?case 0x141: >> > > > + ? ? ? ? ? ?if (bsd_type != target_freebsd) >> > > > + ? ? ? ? ? ? ? ?goto badtrap; >> > > >> > > You are now also trapping on case 0x100 if bsd_type != target_freebsd, >> > > which probably breaks other BSDs. >> > > >> > ?Right, thats broken, the 0x141 case should come before the 0x100 >> > here of course. >> > >> ?...but this I just fixed, and I added the multiboot.S patch, and >> fixed the port's cdrom dma disable knob (files/cdrom-dma-patch). >> (And I added the cpu-exec.c whitspace fix that was already in the >> patch I posted in the BSD support thread.) >> >> ?New version at the same place, >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch >> and I now also made a shar of the patched port: >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.shar > > Updated again, among other things I added basic FreeBSD sysarch(2) > handling, fixed syscall errno return (I had added code to set the > carry bit for the x86 target before but the sign of the returned errno > was still wrong), and I finally fixed the if (1) above (made bsd_type > global.) > > ?And, I now can run FreeBSD/amd64 /bin/sh and vim on same! :) ?(zsh > not yet tho.) > > ?Oh and Toni tested taking FreeBSD/i386's default linker script, > changing only the load address to 0x60000000 as in qemu's and, > using that as i386.ld, he now can run qemu-i386 on FreeBSD/i386 with > simple executables too... ?See files/patch-bsd-user-ld in the shar, > which I also now moved the x86_64.ld patch to that I had talked about > earlier. ?It probably can't be used everywhere as is tho since it has: > ? ? ? ?OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd", > ? ? ? ? ? ? ? ? ? ? ?"elf32-i386-freebsd") > (and I also don't know if the one currently in the tree has other > features that are needed at least on Linux, any linker gurus care > to comment?) > > ?Here is the rest of the bsd-user patches again (files/patch-bsd-user > in the shar), if you think they are ready to commit I'm not against it > anymore :), comments are also welcome of course. Thanks, applied. I made up a short commit message. From oberman at es.net Sun Oct 18 20:09:39 2009 From: oberman at es.net (Kevin Oberman) Date: Sun Oct 18 20:11:31 2009 Subject: how to test for linux base version? (googleearth) In-Reply-To: Your message of "Sun, 18 Oct 2009 19:41:57 +0200." <20091018174157.GB99191@triton8.kn-bremen.de> Message-ID: <20091018200935.9C2DE1CC37@ptavv.es.net> > From: Juergen Lock > Date: Sun, 18 Oct 2009 19:41:57 +0200 > Sender: owner-freebsd-emulation@freebsd.org > > On Sun, Oct 18, 2009 at 02:30:43PM +0400, Boris Samorodov wrote: > > Juergen Lock writes: > > > > > I just got reminded to add a linux base version check to astro/google-earth > > > (It now needs recent linux libstdc++.so.6 with GLIBCXX_3.4.9 that only > > > is in f9 or f10, you can do > > > > First of, I'd recommend leaving f9 alone (I'm going to deprecate all > > linux base ports except fc4 and f10 soon). > > > Ah Ok. (Does f10 work well enough on 7.x yet?) It works pretty well with 7.2. I have heard that it might not with 7.1, but I don't have any 7.1 systems, so that is hear-say. My 7.2 system does Flash and Skype fine. I think it might do RealPlayer, but I'm not completely sure on that. (It works on 8.0, though.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From bsam at ipt.ru Sun Oct 18 20:11:02 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Oct 18 20:11:59 2009 Subject: how to test for linux base version? (googleearth) In-Reply-To: <20091018174157.GB99191@triton8.kn-bremen.de> (Juergen Lock's message of "Sun\, 18 Oct 2009 19\:41\:57 +0200") References: <20091017154404.GA80599@triton8.kn-bremen.de> <99413628@ipt.ru> <20091018174157.GB99191@triton8.kn-bremen.de> Message-ID: <99401887@ipt.ru> Juergen Lock writes: > On Sun, Oct 18, 2009 at 02:30:43PM +0400, Boris Samorodov wrote: >> Juergen Lock writes: >> >> > I just got reminded to add a linux base version check to astro/google-earth >> > (It now needs recent linux libstdc++.so.6 with GLIBCXX_3.4.9 that only >> > is in f9 or f10, you can do >> >> First of, I'd recommend leaving f9 alone (I'm going to deprecate all >> linux base ports except fc4 and f10 soon). >> > Ah Ok. (Does f10 work well enough on 7.x yet?) Well, there is no choice anyway. We do have fc4 and f10 infractructure ports. I think it's wise to use apropriate base ports. I don't think there is any difference between f9 and f10 linux base ports. If someone shows a difference (i.e. possibility to use f9 but not f10 linux base port under 7.x I may change my mind). >> > objdump -T /compat/linux/usr/lib/libstdc++.so.6 |grep 'ABS.*GLIBCXX' >> > to check) - and was wondering how to best check for that in a port. >> > This is what I came up with so far: >> > >> > Index: Makefile >> > =================================================================== >> > RCS file: /home/pcvs/ports/astro/google-earth/Makefile,v >> > retrieving revision 1.35 >> > diff -u -p -r1.35 Makefile >> > --- Makefile 24 Sep 2009 21:01:36 -0000 1.35 >> > +++ Makefile 17 Oct 2009 15:32:22 -0000 >> > @@ -38,6 +38,14 @@ RUN_DEPENDS+= ${LINUXBASE}/usr/lib/libGL >> > USE_LINUX_APPS+= dri >> > .endif >> > >> > +.if (${OSVERSION} < 800076 && \ >> > + !defined(OVERRIDE_LINUX_BASE_PORT)) || \ >> > + (defined(OVERRIDE_LINUX_BASE_PORT) && \ >> > + !(${OVERRIDE_LINUX_BASE_PORT} == f10) || \ >> > + ${OVERRIDE_LINUX_BASE_PORT} == f9) >> > +IGNORE= needs at least f9 Linux base >> > +.endif >> > + >> > do-extract: >> > @${MKDIR} ${WRKSRC} >> > @${CP} ${DISTDIR}/${DIST_SUBDIR}/${DISTFILES} ${WRKSRC} >> > >> > Anyone have a better idea? :) >> >> I'm not sure if it's better but just an other idea: >> ----- >> .if ${OSVERSION}<7000XX /*** XX should be find out ***/ >> IGNORE FreeBSD>=7.X is needed with Linux emulation 2.6.x. >> .elif ${OSVERSION}<800076 && \ >> ! defined (OVERRIDE_LINUX_NONBASE_PORTS) || >> ! (${OVERRIDE_LINUX_NONBASE_PORTS} == f10) >> IGNORE= you need to use non-default linux ports (define OVERRIDE_LINUX_BASE_PORT=f10 and OVERRIDE_LINUX_NONBASE_PORTS=f10) >> .endif >> ----- > > In the meantime I found emulators/linux-systemsimcell does something > similar, and it uses ${OSVERSION}<700055 for the first check. Does > that look alright? (seems to be the last OSVERSION before 7.0-R from > looking at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#FREEBSD-VERSIONS > ) We discussed those checks with the maintainer and his checks were good (for his software). I can't say more than that, sorry. -- WBR, bsam From webmaster at kibab.com Sun Oct 18 20:11:10 2009 From: webmaster at kibab.com (Ilya Bakulin) Date: Sun Oct 18 20:11:59 2009 Subject: USB webcam++ support for FreeBSD-8-current is soon here Message-ID: <20091019001101.31c22fad@kibab-nb.kibab.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20091018/9dafe50e/signature.pgp From nox at jelal.kn-bremen.de Sun Oct 18 20:12:41 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Oct 18 20:12:48 2009 Subject: [Qemu-devel] Re: playing with qemu usermode emulation on FreeBSD... In-Reply-To: References: <20091007220549.GA65997@triton8.kn-bremen.de> <20091011221840.GA55502@triton8.kn-bremen.de> <20091012222058.GA43121@triton8.kn-bremen.de> <20091013221932.GA32808@triton8.kn-bremen.de> <20091016223426.GA54110@triton8.kn-bremen.de> Message-ID: <20091018201011.GA52533@triton8.kn-bremen.de> On Sun, Oct 18, 2009 at 09:26:00PM +0300, Blue Swirl wrote: > On Sat, Oct 17, 2009 at 1:34 AM, Juergen Lock wrote: > > On Wed, Oct 14, 2009 at 12:19:32AM +0200, Juergen Lock wrote: > >> On Tue, Oct 13, 2009 at 12:20:58AM +0200, Juergen Lock wrote: > >> > On Mon, Oct 12, 2009 at 10:55:24PM +0300, Blue Swirl wrote: > >> > > On Mon, Oct 12, 2009 at 1:18 AM, Juergen Lock wrote: > >> > > > On Thu, Oct 08, 2009 at 12:05:49AM +0200, Juergen Lock wrote: > >> > > >> I recently noticed there are x86 bsd-user targets now (yeah I totally > >> > > >> missed those commits...) and now got it working a tiny little bit: > >> > > >> I can run > >> > > >> ? ? ? qemu-x86_64 -bsd freebsd /rescue/echo foo bar > >> > > >> here on FreeBSD 8/amd64 and it echoes foo bar as expected, but > >> > > >> segfaults afterwards. :) ?(in pthread_setcancelstate() invoked from > >> > > >> a guest write() syscall, in case anyone is wondering.) ?Other things > >> > > >> I tried either exit with errors or segfault as well, and i386 hosts > >> > > >> probably still don't work at all yet. ?(qemu-i386 here on amd64 does > >> > > >> at least something, but probably needs lock_user() treatment for all > >> > > >> kinds of syscalls, I only tried adding that for sysctl so far.) > >> > > >> > >> > > >> ?Anyway, here is an emulators/qemu-devel git head snapshot port > >> > > >> update with my current patches (files/patch-bsd-user), feel free to > >> > > >> test/debug/improve: > >> > > >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch > >> > > >> (For the folks reading this on the qemu list: ?I shall start doing > >> > > >> `proper' patch submissions later, this is more for the FreeBSD folks > >> > > >> and because I was asked to send what I have...) > >> > > > > >> > > > New version at the same place, which now runs FreeBSD/{i386,sparc64} > >> > > > /rescue/echo on FreeBSD/amd64, the FreeBSD/amd64 target now segfaults > >> > > > in pthread_setcancelstate() invoked from the final writev() tho. > >> > > > Oh and I also uploaded the snapshot tarball so others can now actually > >> > > > build the port too... :) ?And I have switched to the cpu-exec.c patch > >> > > > posted by Aleksej Saushev on the qemu list and added back amd64 > >> > > > code there. > >> > > > > >> > > > ?Here is the bsd-user patch again: > >> > > > >> > > Please add Signed-off-by: line and use 'diff -u' (or preferably git diff). > >> > > > >> > Well I wasn't expecting this diff to be committed just yet anyway, > >> > it's still more a wip version... > >> > > >> > > > + ? ?if (1 /* bsd_type == target_freebsd */) > >> > > > + ? ? ? ?regs->rdi = infop->start_stack; > >> > > > >> > > Why the if and comment? > >> > > > >> > > > + ? ? ? ?if (1 /* bsd_type == target_freebsd */) { > >> > > > + ? ? ? ? ? ?regs->u_regs[8] = infop->start_stack; > >> > > > + ? ? ? ? ? ?regs->u_regs[11] = infop->start_stack; > >> > > > >> > > Same here. > >> > > > >> > ?Because bsd_type isn't available at these places in the code but > >> > probably should be checked, I still wanted to fix that. ?(Maybe > >> > make it global?) > >> > > >> I still haven't fixed this... > >> > >> > > > ? ? ? ? case 0x100: > >> > > > + ? ? ? ?/* FreeBSD uses 0x141 for syscalls too */ > >> > > > + ? ? ? ?case 0x141: > >> > > > + ? ? ? ? ? ?if (bsd_type != target_freebsd) > >> > > > + ? ? ? ? ? ? ? ?goto badtrap; > >> > > > >> > > You are now also trapping on case 0x100 if bsd_type != target_freebsd, > >> > > which probably breaks other BSDs. > >> > > > >> > ?Right, thats broken, the 0x141 case should come before the 0x100 > >> > here of course. > >> > > >> ?...but this I just fixed, and I added the multiboot.S patch, and > >> fixed the port's cdrom dma disable knob (files/cdrom-dma-patch). > >> (And I added the cpu-exec.c whitspace fix that was already in the > >> patch I posted in the BSD support thread.) > >> > >> ?New version at the same place, > >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch > >> and I now also made a shar of the patched port: > >> ? ? ? http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.shar > > > > Updated again, among other things I added basic FreeBSD sysarch(2) > > handling, fixed syscall errno return (I had added code to set the > > carry bit for the x86 target before but the sign of the returned errno > > was still wrong), and I finally fixed the if (1) above (made bsd_type > > global.) > > > > ?And, I now can run FreeBSD/amd64 /bin/sh and vim on same! :) ?(zsh > > not yet tho.) > > > > ?Oh and Toni tested taking FreeBSD/i386's default linker script, > > changing only the load address to 0x60000000 as in qemu's and, > > using that as i386.ld, he now can run qemu-i386 on FreeBSD/i386 with > > simple executables too... ?See files/patch-bsd-user-ld in the shar, > > which I also now moved the x86_64.ld patch to that I had talked about > > earlier. ?It probably can't be used everywhere as is tho since it has: > > ? ? ? ?OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd", > > ? ? ? ? ? ? ? ? ? ? ?"elf32-i386-freebsd") > > (and I also don't know if the one currently in the tree has other > > features that are needed at least on Linux, any linker gurus care > > to comment?) > > > > ?Here is the rest of the bsd-user patches again (files/patch-bsd-user > > in the shar), if you think they are ready to commit I'm not against it > > anymore :), comments are also welcome of course. > > Thanks, applied. I made up a short commit message. Sorry, my fault, I should have supplied a `proper' one... :/ (sysarch(2) and errno were only the things I fixed since the last iteration, I guess its too late to add the rest now?) In other news... I have made another port update from today's git: http://people.freebsd.org/~nox/qemu/qemu-devel-20091018.patch resp. http://people.freebsd.org/~nox/qemu/qemu-devel-20091018.shar Enjoy, Juergen From naylor.b.david at gmail.com Sun Oct 18 20:30:09 2009 From: naylor.b.david at gmail.com (David Naylor) Date: Sun Oct 18 20:30:15 2009 Subject: VirtualBox: vboxnetflt related problems In-Reply-To: <4ADB515A.4050309@shapeshifter.se> References: <200910151950.26620.naylor.b.david@gmail.com> <4ADB515A.4050309@shapeshifter.se> Message-ID: <200910182230.08620.naylor.b.david@gmail.com> On Sunday, 18 October 2009 19:33:14 Fredrik Lindberg wrote: > David Naylor wrote: > > Hi, > > > > Thanks for porting VirtualBox, it has proven most useful (no more slow > > RDC). > > > > I've found some problems relating to VirtualBox's bridged networking: > > > > 1) loader doesn't pull in all the dependencies for vboxnetflt (kldload > > does) [missing dependencies: ng_ether] > > I couldn't figure out how properly depend on ng_ether, a simple > MODULE_DEPEND does not work. I guess it's because ng_ether doesn't > declare MODULE_VERSION. ng_ether *should* be loaded by the > explicit kern_kldload, does this not happen on your system? I assume you mean kldload after the system boots. Yes it does. > > 2) even with the dependencies specified in loader.conf vboxnetflt fails > > to initialise on boot [module_register_init: MOD_LOAD (ng_vboxnetflt, > > 0xc0f44fd9, 0xc19bd6a0) error 22] > > There is a known issue where the vboxdrv module (and thus VirtualBox) > sometimes fail to see that vboxnetflt is loaded - is this what you're > seeing? or does vboxnetflt simply not load at all? The module fails to register. As per the message I quoted above: module_register_init: MOD_LOAD (ng_vboxnetflt, 0xc0f44fd9, 0xc19bd6a0) error 22 This only happens if loader loads the module. I've never had a problem the kldload loading the module. > vnoxnetflt should load fine even without ng_ether loaded. The above error message occurs irrespective of ng_ether being loaded. > > 3) bridging doesn't work when connecting to bridge0 or tap0: > > # netstat -w1 -I tap0 > > input (tap0) output > > packets errs bytes packets errs bytes colls > > 0 0 0 0 0 0 0 > > 0 0 0 0 2 151 0 > > ... > > This happen with and without giving tap0 an IP address. > > This is because vboxnetflt uses ng_ether and the interaction between > ng_ether/bridge/tap/vboxnetflt doesn't work. Good to know :-). Is there anyway to communicate directly with the host using a bridged connection? This is not much of a concern for me since I need to bounce my files through a server (to accommodate windows) but it might be a concern for others. David -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20091018/ed855972/attachment.pgp From nox at jelal.kn-bremen.de Sun Oct 18 20:32:17 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Oct 18 20:32:24 2009 Subject: how to test for linux base version? (googleearth) In-Reply-To: <99401887@ipt.ru> References: <20091017154404.GA80599@triton8.kn-bremen.de> <99413628@ipt.ru> <20091018174157.GB99191@triton8.kn-bremen.de> <99401887@ipt.ru> Message-ID: <20091018202545.GA53402@triton8.kn-bremen.de> On Mon, Oct 19, 2009 at 12:13:20AM +0400, Boris Samorodov wrote: > Juergen Lock writes: > > On Sun, Oct 18, 2009 at 02:30:43PM +0400, Boris Samorodov wrote: > >> Juergen Lock writes: > >> > >> > I just got reminded to add a linux base version check to astro/google-earth > >> > (It now needs recent linux libstdc++.so.6 with GLIBCXX_3.4.9 that only > >> > is in f9 or f10, you can do > >> > >> First of, I'd recommend leaving f9 alone (I'm going to deprecate all > >> linux base ports except fc4 and f10 soon). > >> > > Ah Ok. (Does f10 work well enough on 7.x yet?) > > Well, there is no choice anyway. We do have fc4 and f10 infractructure > ports. I think it's wise to use apropriate base ports. I don't think > there is any difference between f9 and f10 linux base ports. > Oh I was more thinking of f8 since we have nonbase ports for that too... > If someone shows a difference (i.e. possibility to use f9 but not > f10 linux base port under 7.x I may change my mind). > Ok so `someone' would need to test this... > >> > objdump -T /compat/linux/usr/lib/libstdc++.so.6 |grep 'ABS.*GLIBCXX' > >> > to check) - and was wondering how to best check for that in a port. > >> > This is what I came up with so far: > >> > > >> > Index: Makefile > >> > =================================================================== > >> > RCS file: /home/pcvs/ports/astro/google-earth/Makefile,v > >> > retrieving revision 1.35 > >> > diff -u -p -r1.35 Makefile > >> > --- Makefile 24 Sep 2009 21:01:36 -0000 1.35 > >> > +++ Makefile 17 Oct 2009 15:32:22 -0000 > >> > @@ -38,6 +38,14 @@ RUN_DEPENDS+= ${LINUXBASE}/usr/lib/libGL > >> > USE_LINUX_APPS+= dri > >> > .endif > >> > > >> > +.if (${OSVERSION} < 800076 && \ > >> > + !defined(OVERRIDE_LINUX_BASE_PORT)) || \ > >> > + (defined(OVERRIDE_LINUX_BASE_PORT) && \ > >> > + !(${OVERRIDE_LINUX_BASE_PORT} == f10) || \ > >> > + ${OVERRIDE_LINUX_BASE_PORT} == f9) > >> > +IGNORE= needs at least f9 Linux base > >> > +.endif > >> > + > >> > do-extract: > >> > @${MKDIR} ${WRKSRC} > >> > @${CP} ${DISTDIR}/${DIST_SUBDIR}/${DISTFILES} ${WRKSRC} > >> > > >> > Anyone have a better idea? :) > >> > >> I'm not sure if it's better but just an other idea: > >> ----- > >> .if ${OSVERSION}<7000XX /*** XX should be find out ***/ > >> IGNORE FreeBSD>=7.X is needed with Linux emulation 2.6.x. > >> .elif ${OSVERSION}<800076 && \ > >> ! defined (OVERRIDE_LINUX_NONBASE_PORTS) || > >> ! (${OVERRIDE_LINUX_NONBASE_PORTS} == f10) > >> IGNORE= you need to use non-default linux ports (define OVERRIDE_LINUX_BASE_PORT=f10 and OVERRIDE_LINUX_NONBASE_PORTS=f10) > >> .endif > >> ----- > > > > In the meantime I found emulators/linux-systemsimcell does something > > similar, and it uses ${OSVERSION}<700055 for the first check. Does > > that look alright? (seems to be the last OSVERSION before 7.0-R from > > looking at > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#FREEBSD-VERSIONS > > ) > > We discussed those checks with the maintainer and his checks were good > (for his software). I can't say more than that, sorry. Ok. Maybe I should just commit it like that, I guess it's kinda unlikely someone who's running a FreeBSD _desktop_ still uses something as old as 7.0 anyway. Thanx, Juergen From bsam at ipt.ru Sun Oct 18 20:45:00 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Oct 18 20:45:06 2009 Subject: how to test for linux base version? (googleearth) In-Reply-To: <20091018202545.GA53402@triton8.kn-bremen.de> (Juergen Lock's message of "Sun\, 18 Oct 2009 22\:25\:45 +0200") References: <20091017154404.GA80599@triton8.kn-bremen.de> <99413628@ipt.ru> <20091018174157.GB99191@triton8.kn-bremen.de> <99401887@ipt.ru> <20091018202545.GA53402@triton8.kn-bremen.de> Message-ID: <33329848@ipt.ru> Juergen Lock writes: > On Mon, Oct 19, 2009 at 12:13:20AM +0400, Boris Samorodov wrote: >> Juergen Lock writes: >> > On Sun, Oct 18, 2009 at 02:30:43PM +0400, Boris Samorodov wrote: >> >> Juergen Lock writes: >> >> >> >> > I just got reminded to add a linux base version check to astro/google-earth >> >> > (It now needs recent linux libstdc++.so.6 with GLIBCXX_3.4.9 that only >> >> > is in f9 or f10, you can do >> >> >> >> First of, I'd recommend leaving f9 alone (I'm going to deprecate all >> >> linux base ports except fc4 and f10 soon). >> >> >> > Ah Ok. (Does f10 work well enough on 7.x yet?) >> >> Well, there is no choice anyway. We do have fc4 and f10 infractructure >> ports. I think it's wise to use apropriate base ports. I don't think >> there is any difference between f9 and f10 linux base ports. >> > Oh I was more thinking of f8 since we have nonbase ports for that too... Hm, but it were you who said that only f9 and f10 base ports had libstdc++.so.6 with apropriate symbols. ;-) About f8 ports. Almost all current linux ports play well with f10 ports at 7.2, 8.0 and 9-CURRENT. Only one exception I'm aware is acroread9 (a linux syscall should be implemented). If those ports (f8) are usefull for 7.0 and 7.1 (6.x doesn't have apropriate kernel sources) then they should stay until 7.0 and 7.1 are EOLed. -- WBR, bsam From nox at jelal.kn-bremen.de Sun Oct 18 21:04:36 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Oct 18 21:04:43 2009 Subject: VirtualBox: vboxnetflt related problems In-Reply-To: <4ADB515A.4050309@shapeshifter.se> References: <200910151950.26620.naylor.b.david@gmail.com> Message-ID: <200910182103.n9IL36HK054641@triton8.kn-bremen.de> In article <4ADB515A.4050309@shapeshifter.se> you write: >David Naylor wrote: >> Hi, >> >> Thanks for porting VirtualBox, it has proven most useful (no more slow RDC). >> >> I've found some problems relating to VirtualBox's bridged networking: >> >> 1) loader doesn't pull in all the dependencies for vboxnetflt (kldload >> does) [missing dependencies: ng_ether] > >I couldn't figure out how properly depend on ng_ether, a simple >MODULE_DEPEND does not work. I guess it's because ng_ether doesn't >declare MODULE_VERSION. ng_ether *should* be loaded by the >explicit kern_kldload, does this not happen on your system? > >> >> 2) even with the dependencies specified in loader.conf vboxnetflt fails to >> initialise on boot [module_register_init: MOD_LOAD (ng_vboxnetflt, 0xc0f44fd9, >> 0xc19bd6a0) error 22] > >There is a known issue where the vboxdrv module (and thus VirtualBox) >sometimes fail to see that vboxnetflt is loaded - is this what you're >seeing? or does vboxnetflt simply not load at all? > >vnoxnetflt should load fine even without ng_ether loaded. > >> >> 3) bridging doesn't work when connecting to bridge0 or tap0: >> # netstat -w1 -I tap0 >> input (tap0) output >> packets errs bytes packets errs bytes colls >> 0 0 0 0 0 0 0 >> 0 0 0 0 2 151 0 >> ... >> This happen with and without giving tap0 an IP address. > >This is because vboxnetflt uses ng_ether and the interaction between >ng_ether/bridge/tap/vboxnetflt doesn't work. Hmm, would it make sense to add back the tuntap code as a special case for when someone selects a tap interface for `bridged' networking? I haven't looked if thats even doable easily enough with all the conditional compilation going on tho. (VBOX_WITH_NETFLT...) Cheers, Juergen From nox at jelal.kn-bremen.de Sun Oct 18 21:09:30 2009 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Oct 18 21:09:37 2009 Subject: how to test for linux base version? (googleearth) In-Reply-To: <33329848@ipt.ru> References: <20091017154404.GA80599@triton8.kn-bremen.de> <99413628@ipt.ru> <20091018174157.GB99191@triton8.kn-bremen.de> <99401887@ipt.ru> <20091018202545.GA53402@triton8.kn-bremen.de> <33329848@ipt.ru> Message-ID: <20091018210821.GA55095@triton8.kn-bremen.de> On Mon, Oct 19, 2009 at 12:47:19AM +0400, Boris Samorodov wrote: > Juergen Lock writes: > > On Mon, Oct 19, 2009 at 12:13:20AM +0400, Boris Samorodov wrote: > >> Juergen Lock writes: > >> > On Sun, Oct 18, 2009 at 02:30:43PM +0400, Boris Samorodov wrote: > >> >> Juergen Lock writes: > >> >> > >> >> > I just got reminded to add a linux base version check to astro/google-earth > >> >> > (It now needs recent linux libstdc++.so.6 with GLIBCXX_3.4.9 that only > >> >> > is in f9 or f10, you can do > >> >> > >> >> First of, I'd recommend leaving f9 alone (I'm going to deprecate all > >> >> linux base ports except fc4 and f10 soon). > >> >> > >> > Ah Ok. (Does f10 work well enough on 7.x yet?) > >> > >> Well, there is no choice anyway. We do have fc4 and f10 infractructure > >> ports. I think it's wise to use apropriate base ports. I don't think > >> there is any difference between f9 and f10 linux base ports. > >> > > Oh I was more thinking of f8 since we have nonbase ports for that too... > > Hm, but it were you who said that only f9 and f10 base ports had > libstdc++.so.6 with apropriate symbols. ;-) > Oh yeah, that comment was meant more in general, not for this specific port. > About f8 ports. Almost all current linux ports play well with f10 > ports at 7.2, 8.0 and 9-CURRENT. Only one exception I'm aware is > acroread9 (a linux syscall should be implemented). If those ports > (f8) are usefull for 7.0 and 7.1 (6.x doesn't have apropriate > kernel sources) then they should stay until 7.0 and 7.1 are EOLed. Ok. Cheers, Juergen From hselasky at freebsd.org Mon Oct 19 01:22:48 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Mon Oct 19 01:22:53 2009 Subject: USB webcam++ support for FreeBSD-8-current is soon here In-Reply-To: <20091019001101.31c22fad@kibab-nb.kibab.com> References: <20091019001101.31c22fad@kibab-nb.kibab.com> Message-ID: <200910190223.45229.hselasky@freebsd.org> On Sunday 18 October 2009 22:11:01 Ilya Bakulin wrote: > Is there any way to make Skype work with Webcam (as I understand, it > requires /dev/video0 device to be present?) When skype links with libv4l like the rest of the Linux V4L applications nowadays, it will work given some minor changes I think. NOTE: if you try to build KDE4(network) after you installed my libv4l, then KDE4 will start using libv4l instead of /dev/video0. It will break a couple of times, but should be easy to fix. Mostly I needed to add libv4lxdrivers.so to the installed libv4l .pc files. Thanks for your patch. I will forward it. --HPS From linimon at FreeBSD.org Mon Oct 19 02:33:57 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Oct 19 02:34:08 2009 Subject: kern/139423: [parallels] Networking does not work on amd64 guest on Parallels Desktop Message-ID: <200910190233.n9J2XuLq088471@freefall.freebsd.org> Old Synopsis: Networking does not work on amd64 guest on Parallels Desktop New Synopsis: [parallels] Networking does not work on amd64 guest on Parallels Desktop Responsible-Changed-From-To: freebsd-amd64->freebsd-emulation Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 19 02:33:21 UTC 2009 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=139423 From fli at shapeshifter.se Mon Oct 19 05:10:12 2009 From: fli at shapeshifter.se (Fredrik Lindberg) Date: Mon Oct 19 05:10:18 2009 Subject: VirtualBox: vboxnetflt related problems In-Reply-To: <200910182103.n9IL36HK054641@triton8.kn-bremen.de> References: <200910151950.26620.naylor.b.david@gmail.com> <200910182103.n9IL36HK054641@triton8.kn-bremen.de> Message-ID: <9ffa951df1394cfafab170773a1c9b8d@localhost> On Sun, 18 Oct 2009 23:03:06 +0200 (CEST), Juergen Lock wrote: > In article <4ADB515A.4050309@shapeshifter.se> you write: >>David Naylor wrote: >>> >>> 3) bridging doesn't work when connecting to bridge0 or tap0: >>> # netstat -w1 -I tap0 >>> input (tap0) output >>> packets errs bytes packets errs bytes colls >>> 0 0 0 0 0 0 0 >>> 0 0 0 0 2 151 0 >>> ... >>> This happen with and without giving tap0 an IP address. >> >>This is because vboxnetflt uses ng_ether and the interaction between >>ng_ether/bridge/tap/vboxnetflt doesn't work. > > Hmm, would it make sense to add back the tuntap code as a special > case for when someone selects a tap interface for `bridged' > networking? > > I haven't looked if thats even doable easily enough with all the > conditional compilation going on tho. (VBOX_WITH_NETFLT...) > Yes, the tuntap stuff and the vboxnetflt stuff seemed to both be controlled by VBOX_WITH_NETFLT which makes life difficult :) I think the bridge case might be fixable, there are explicit calls to the bridge code inside ng_ether, but somewhere, something goes wrong. Briefly looking at if_tap.c, I see that it calls ether_attach so ng_ether *should* pick up frames from it - I need to look at this further. Fredrik From bugmaster at FreeBSD.org Mon Oct 19 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:07:53 2009 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200910191106.n9JB6owD063408@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139423 emulation [parallels] Networking does not work on amd64 guest on o kern/138944 emulation [parallels] [regression] Parallels no longer works in o kern/138880 emulation [linux] munmap segfaults after linux_mmap2 stresstest o ports/137332 emulation add caution messages to some adobe products f ports/136321 emulation x11-toolkits/linux-pango: please update linux based po o ports/136229 emulation [linux] certain linux apps look for libraries using a o ports/135337 emulation [PATCH] emulators/linux_base-f10: incorrect bash usage f ports/135322 emulation Port graphics/linux_dri has incorrect packaging list c o kern/130724 emulation [linprocfs] [patch] cpuinfo in linprocfs is dated, cau o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n f ports/127018 emulation Linuxulator incapable of using FreeBSD's LDAP environm o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/56451 emulation [linprocfs] /compat/linux/proc/cpuinfo gives wrong CPU o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 21 problems total. From dave.evans55 at googlemail.com Mon Oct 19 18:40:05 2009 From: dave.evans55 at googlemail.com (David Evans) Date: Mon Oct 19 18:40:11 2009 Subject: kern/138944: [parallels] [regression] Parallels no longer works in FreeBSD 8 Beta Message-ID: <200910191840.n9JIe5Og056170@freefall.freebsd.org> The following reply was made to PR kern/138944; it has been noted by GNATS. From: David Evans To: bug-followup@FreeBSD.org, charlie@begeistert.org Cc: Subject: Re: kern/138944: [parallels] [regression] Parallels no longer works in FreeBSD 8 Beta Date: Mon, 19 Oct 2009 19:04:34 +0100 What version of Parallels are you using? I find 8-RC1 i386 is working fine on Parallels 4.0 Build 3846 for Mac OS X Identical source compiled for amd64 also mostly works, but ifconfig leads to a crash. See my bug report kern/139423 From alexbestms at math.uni-muenster.de Thu Oct 22 05:20:02 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Oct 22 05:20:19 2009 Subject: kern/97326: [linux] file descriptor leakage in linux emulation Message-ID: <200910220520.n9M5K2oM092918@freefall.freebsd.org> The following reply was made to PR kern/97326; it has been noted by GNATS. From: Alexander Best To: Cc: Subject: Re: kern/97326: [linux] file descriptor leakage in linux emulation Date: Thu, 22 Oct 2009 07:12:52 +0200 (CEST) as reported by Marcin Cieslak and Vladimir Grebenschikov this PR was fixed in 1.138.2.1. linux binaries no longer leak descriptors. here's an example from running unreal tournament 2004. `while sleep 3; do lsof|grep ut2004|wc; done` reports: 0 0 0 28 247 2935 134 1201 15701 171 1534 20261 189 1697 23146 603 5523 74247 603 5523 74247 603 5523 74247 603 5523 74247 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 99 930 10920 0 0 0 cheers. alex From gavin at FreeBSD.org Thu Oct 22 14:23:03 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Oct 22 14:23:10 2009 Subject: kern/97326: [linux] file descriptor leakage in linux emulation Message-ID: <200910221423.n9MEN2ZL000249@freefall.freebsd.org> Synopsis: [linux] file descriptor leakage in linux emulation State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Thu Oct 22 14:22:36 UTC 2009 State-Changed-Why: >From the audit trail, it looks like this is now resolved. http://www.freebsd.org/cgi/query-pr.cgi?pr=97326 From yuri at rawbw.com Fri Oct 23 19:23:11 2009 From: yuri at rawbw.com (Yuri) Date: Fri Oct 23 19:23:20 2009 Subject: Can't start VirtualBox: COM server problem? Message-ID: <4AE1FCBD.3040307@rawbw.com> When I run: cat /dev/ad1s1 | VBoxManage stdin OutPutFile.vdi 21474836480 on 80-RC2 I get this output: ERROR: failed to create the VirtualBox object! ERROR: code NS_ERROR_ABORT (0x80004004) - Operation aborted (extended info not available) Most likely, the VirtualBox COM server is not running or failed to start. No processes with name VirtualBox are running. What could be the problem? Yuri From bugmaster at FreeBSD.org Mon Oct 26 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:07:50 2009 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200910261106.n9QB6ucH043725@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139423 emulation [parallels] Networking does not work on amd64 guest on o kern/138944 emulation [parallels] [regression] Parallels no longer works in o kern/138880 emulation [linux] munmap segfaults after linux_mmap2 stresstest o ports/137332 emulation add caution messages to some adobe products f ports/136321 emulation x11-toolkits/linux-pango: please update linux based po o ports/136229 emulation [linux] certain linux apps look for libraries using a o ports/135337 emulation [PATCH] emulators/linux_base-f10: incorrect bash usage f ports/135322 emulation Port graphics/linux_dri has incorrect packaging list c o kern/130724 emulation [linprocfs] [patch] cpuinfo in linprocfs is dated, cau o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n f ports/127018 emulation Linuxulator incapable of using FreeBSD's LDAP environm o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/56451 emulation [linprocfs] /compat/linux/proc/cpuinfo gives wrong CPU o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 20 problems total. From vova at fbsd.ru Tue Oct 27 09:51:30 2009 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Tue Oct 27 09:51:37 2009 Subject: Acroread 9 In-Reply-To: <200904101343.37355.jkim@FreeBSD.org> References: <200904101343.37355.jkim@FreeBSD.org> Message-ID: <1256634844.1619.51.camel@localhost> Hi > It is a known problem: > > http://docs.freebsd.org/cgi/mid.cgi?20090401175638.GA31233 hi, I have tried patch from above article (on RELENG_8) Patch applied, kernel build, but acroread behave same as before patch: linux: pid 79194 (acroread): syscall inotify_init not implemented something wrong in patch ? $ linux_kdump -m40 -f ~/acrored.kdump ... 36359 acroread CALL linux_fcntl64(0x8,0xd,0xbfbfdcc8) 36359 acroread RET linux_fcntl64 0 36359 acroread CALL close(0x8) 36359 acroread RET close 0 36359 acroread CALL linux_inotify_init 36359 acroread RET linux_inotify_init -1 errno 38 Socket operation on non-socket 36359 acroread CALL linux_socketcall(0x8,0xbfbfde80) 36359 acroread RET linux_socketcall 0 36359 acroread CALL linux_stat64(0xa5b9ec8,0xbfbfdd48,0x4b2b9ff4) 36359 acroread NAMI "/compat/linux/home/vova/.adobe/Acrobat/9.0/SharedDataEvents" 36359 acroread NAMI "/home/vova/.adobe/Acrobat/9.0/SharedDataEvents" 36359 acroread UNKNOWN(8) 36359 acroread RET linux_stat64 0 36359 acroread CALL write(0x9,0xbfbfde8c,0x1) 36359 acroread GIO fd 9 wrote 1 byte "M" 36359 acroread RET write 1 36359 acroread CALL linux_mmap2(0,0x100000,0x7,0x20022,0xffffffff,0) 36359 acroread RET linux_mmap2 1288486912/0x4cccc000 36359 acroread CALL linux_mprotect(0x4cccc000,0x1000,0) 36359 acroread RET linux_mprotect 0 36359 acroread CALL sched_getparam(0,0x4cdcbd94) 36359 acroread RET sched_getparam 0 36359 acroread CALL linux_sched_get_priority_min(0) 36359 acroread RET linux_sched_get_priority_min 0 36359 acroread CALL linux_sched_get_priority_max(0) 36359 acroread RET linux_sched_get_priority_max 63/0x3f 36359 acroread CALL linux_clone(0x3d0f00,0x4cdcb454,0x4cdcbbd8,0xbfbfde70,0x4cdcbbd8) 36359 acroread RET linux_clone 36395/0x8e2b 36359 acroread CALL linux_sched_setscheduler(0x8e2b,0,0x4cdcbd94) 36359 acroread RET linux_sched_setscheduler RESTART 36359 acroread CALL linux_tgkill(0x8e07,0x8e2b,0x20) 36359 acroread RET linux_tgkill 0 36359 acroread CALL linux_sys_futex(0x4b3bec28,0x81,0x7fffffff,0,0xbfbfde3c,0xbfbfdc34) 36359 acroread RET linux_sys_futex 0 36359 acroread CALL write(0x2,0x4b380c74,0x30) 36359 acroread GIO fd 2 wrote 48 bytes "terminate called after throwing an insta" 36359 acroread RET write 48/0x30 36359 acroread CALL write(0x2,0xac8eac0,0xb) 36359 acroread GIO fd 2 wrote 11 bytes "RSException" 36359 acroread RET write 11/0xb 36359 acroread CALL write(0x2,0x4b380c64,0x2) 36359 acroread GIO fd 2 wrote 2 bytes "' " 36359 acroread RET write 2 36359 acroread CALL linux_rt_sigprocmask(0x1,0xbfbfdd5c,0,0x8) 36359 acroread RET linux_rt_sigprocmask 0 36359 acroread CALL linux_tgkill(0x8e07,0x8e07,0x6) 36359 acroread RET linux_tgkill 0 36359 acroread PSIG SIGIOT caught handler=0x84fcd86 mask=0x0 code=0x0 36359 acroread CALL linux_rt_sigaction(0x6,0xbfbfd7ec,0xbfbfd760,0x8) 36359 acroread RET linux_rt_sigaction 0 36359 acroread CALL linux_exit_group(0x1) -- Vladimir B. Grebenschikov vova@fbsd.ru From rdivacky at FreeBSD.org Tue Oct 27 18:12:59 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Tue Oct 27 18:13:06 2009 Subject: Acroread 9 In-Reply-To: <1256634844.1619.51.camel@localhost> References: <200904101343.37355.jkim@FreeBSD.org> <1256634844.1619.51.camel@localhost> Message-ID: <20091027181207.GA67239@freebsd.org> On Tue, Oct 27, 2009 at 12:14:04PM +0300, Vladimir Grebenschikov wrote: > Hi > > > It is a known problem: > > > > http://docs.freebsd.org/cgi/mid.cgi?20090401175638.GA31233 > > hi, > > I have tried patch from above article (on RELENG_8) > Patch applied, kernel build, but acroread behave same as before patch: > > linux: pid 79194 (acroread): syscall inotify_init not implemented epoll has nothing to do with inotify. I am sorry but there's no support for inotify in linuxulator From dougb at FreeBSD.org Tue Oct 27 22:25:20 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Oct 27 22:25:27 2009 Subject: Can we suppress VBoxDrvFreeBSDClone messages? Message-ID: <4AE77348.70004@FreeBSD.org> Howdy, I have been trying to use virtualbox more for "real work" that I would usually have to boot windows for, and usually it works Ok. But in order to get any kind of reliability I need to load vboxdrv in loader.conf, which leads to a very large number of VBoxDrvFreeBSDClone every time I boot, to the point where I basically can't read anything on the console. Can we suppress these messages, and/or make them an optional feature? Is there an easy way to do this in the code that you could point me to? Thanks, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From amvandemore at gmail.com Tue Oct 27 22:39:09 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Tue Oct 27 22:39:15 2009 Subject: Can we suppress VBoxDrvFreeBSDClone messages? In-Reply-To: <4AE77348.70004@FreeBSD.org> References: <4AE77348.70004@FreeBSD.org> Message-ID: <6201873e0910271539p5b995319udec6a6c5cbe6c55d@mail.gmail.com> On Tue, Oct 27, 2009 at 5:25 PM, Doug Barton wrote: > Howdy, > > I have been trying to use virtualbox more for "real work" that I would > usually have to boot windows for, and usually it works Ok. But in > order to get any kind of reliability I need to load vboxdrv in > loader.conf, which leads to a very large number of VBoxDrvFreeBSDClone > every time I boot, to the point where I basically can't read anything > on the console. > > Can we suppress these messages, and/or make them an optional feature? > Is there an easy way to do this in the code that you could point me to? > > > Thanks, > > Doug > I think you may have compiled VB with debug turned on. Only way I know to disable it is to compile is debug knob to off. -- Adam Vande More From alexbestms at math.uni-muenster.de Wed Oct 28 16:21:27 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Oct 28 16:21:33 2009 Subject: quake live anyone? Message-ID: hi there, has anybody been able to run quake live? i've installed ff 3.5.3 (linux version). installing the plugin works, but then the plugin stalls when being accessed by the quake live website. no linuxulator warnings are being issued. i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r198504: Tue Oct 27 03:13:34 CET 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL i386 alex From chris.chambers at gmx.com Wed Oct 28 18:19:15 2009 From: chris.chambers at gmx.com (Christopher Chambers) Date: Wed Oct 28 18:54:07 2009 Subject: ldconfig set_thread_area Message-ID: Hi, I am using FreeBSD 6.3 and my linux base is fedora 10. I am missing the linux xorg libraries. When I attempt to install, "/compat/linux/sbin/ldconfig -r /compat/linux" tells me "set_thread_area failed." I do not know enough about ldconfig to know what this means or how to fix it. Running /compat/linux/sbin/ldconfig gives me a long list of libraries. Regards, Chris From bsam at ipt.ru Wed Oct 28 20:10:07 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Oct 28 20:10:14 2009 Subject: ldconfig set_thread_area In-Reply-To: (Christopher Chambers's message of "Wed\, 28 Oct 2009 11\:19\:03 -0700") References: Message-ID: <08230407@ipt.ru> "Christopher Chambers" writes: > I am using FreeBSD 6.3 and my linux base is fedora 10. I am missing the linux xorg libraries. When I attempt to install, "/compat/linux/sbin/ldconfig -r /compat/linux" tells me "set_thread_area failed." I do not know enough about ldconfig to know what this means or how to fix it. FreeBSD-6.x in incompatible with -f10- ports. Only FreeBSD 7-STABLE (I'm not sure about 7.2-RELEASE) is compatible (but not fully) and the defaults are -fc4- ports. You can get more information at /usr/ports/UPDATING and this maillist archives. -f10- ports are defaults only for upcomming 8.0 and 9-CURRENT. > Running /compat/linux/sbin/ldconfig gives me a long list of libraries. -- WBR, bsam From rdivacky at freebsd.org Wed Oct 28 20:14:42 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Wed Oct 28 20:14:47 2009 Subject: quake live anyone? In-Reply-To: References: Message-ID: <20091028201347.GA98869@freebsd.org> On Wed, Oct 28, 2009 at 05:21:24PM +0100, Alexander Best wrote: > hi there, > > has anybody been able to run quake live? i've installed ff 3.5.3 (linux > version). installing the plugin works, but then the plugin stalls when being > accessed by the quake live website. > > no linuxulator warnings are being issued. > > i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r198504: Tue Oct > 27 03:13:34 CET 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL i386 maybe you can ktrace it and show us the last ~50 lines of linux_kdump output? From alexbestms at math.uni-muenster.de Wed Oct 28 20:39:15 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Oct 28 20:39:21 2009 Subject: quake live anyone? In-Reply-To: <20091028201347.GA98869@freebsd.org> Message-ID: Roman Divacky schrieb am 2009-10-28: > On Wed, Oct 28, 2009 at 05:21:24PM +0100, Alexander Best wrote: > > hi there, > > has anybody been able to run quake live? i've installed ff 3.5.3 > > (linux > > version). installing the plugin works, but then the plugin stalls > > when being > > accessed by the quake live website. > > no linuxulator warnings are being issued. > > i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > > r198504: Tue Oct > > 27 03:13:34 CET 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL > > i386 > maybe you can ktrace it and show us the last ~50 lines of linux_kdump > output? sure. it stalls right after the last linux_waitpid() call: 1622 sh RET read 814/0x32e 1622 sh CALL #188(0x2833f7d4,0xbfbfe008) 1622 sh NAMI "/sbin/expr" 1622 sh RET #188 -1 errno 2 No such file or directory 1622 sh CALL #188(0x2833f7d4,0xbfbfe008) 1622 sh NAMI "/bin/expr" 1622 sh UNKNOWN(8) 1622 sh RET #188 0 1622 sh CALL linux_pipe 1622 sh RET linux_pipe 3 1622 sh CALL linux_fork 1622 sh RET linux_fork 1625/0x659 1622 sh CALL close(0x4) 1622 sh RET close 0 1622 sh CALL read(0x3,0xbfbfe258,0x80) 1622 sh GIO fd 3 read 2 bytes "1 " 1622 sh RET read 2 1622 sh CALL read(0x3,0xbfbfe258,0x80) 1622 sh GIO fd 3 read 0 bytes "" 1622 sh RET read 0 1622 sh CALL close(0x3) 1622 sh RET close 0 1622 sh CALL linux_setgroups16 1622 sh RET linux_setgroups16 1622/0x656 1622 sh CALL linux_waitpid(0xffffffff,0xbfbfe168,0x2,0) 1622 sh RET linux_waitpid 1625/0x659 1622 sh CALL linux_fork 1622 sh RET linux_fork 1626/0x65a 1622 sh CALL linux_setgroups16 1622 sh RET linux_setgroups16 1622/0x656 1622 sh CALL linux_waitpid(0xffffffff,0xbfbfe418,0x2,0) cheers. alex From rdivacky at freebsd.org Wed Oct 28 20:43:45 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Wed Oct 28 20:44:02 2009 Subject: quake live anyone? In-Reply-To: References: <20091028201347.GA98869@freebsd.org> Message-ID: <20091028204253.GA2981@freebsd.org> On Wed, Oct 28, 2009 at 09:39:12PM +0100, Alexander Best wrote: > Roman Divacky schrieb am 2009-10-28: > > On Wed, Oct 28, 2009 at 05:21:24PM +0100, Alexander Best wrote: > > > hi there, > > > > has anybody been able to run quake live? i've installed ff 3.5.3 > > > (linux > > > version). installing the plugin works, but then the plugin stalls > > > when being > > > accessed by the quake live website. > > > > no linuxulator warnings are being issued. > > > > i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > > > r198504: Tue Oct > > > 27 03:13:34 CET 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL > > > i386 > > > maybe you can ktrace it and show us the last ~50 lines of linux_kdump > > output? > > sure. it stalls right after the last linux_waitpid() call: you need ktrace -i From alexbestms at math.uni-muenster.de Wed Oct 28 20:55:05 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Oct 28 20:55:12 2009 Subject: quake live anyone? In-Reply-To: <20091028204253.GA2981@freebsd.org> Message-ID: Roman Divacky schrieb am 2009-10-28: > On Wed, Oct 28, 2009 at 09:39:12PM +0100, Alexander Best wrote: > > Roman Divacky schrieb am 2009-10-28: > > > On Wed, Oct 28, 2009 at 05:21:24PM +0100, Alexander Best wrote: > > > > hi there, > > > > has anybody been able to run quake live? i've installed ff > > > > 3.5.3 > > > > (linux > > > > version). installing the plugin works, but then the plugin > > > > stalls > > > > when being > > > > accessed by the quake live website. > > > > no linuxulator warnings are being issued. > > > > i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > > > > r198504: Tue Oct > > > > 27 03:13:34 CET 2009 > > > > root@otaku:/usr/obj/usr/src/sys/ARUNDEL > > > > i386 > > > maybe you can ktrace it and show us the last ~50 lines of > > > linux_kdump > > > output? > > sure. it stalls right after the last linux_waitpid() call: > you need ktrace -i oh sorry: 6204 firefox-bin RET writev 1560/0x618 6214 firefox-bin RET linux_sys_futex 0 6214 firefox-bin CALL gettimeofday(0x366ff20c,0) 6214 firefox-bin RET gettimeofday 0 6214 firefox-bin CALL gettimeofday(0x366ff1e4,0) 6214 firefox-bin RET gettimeofday 0 6214 firefox-bin CALL linux_sys_futex(0x2a256a60,0x81,0x1,0x2a256a60,0x2a256a60,0x366ff1a4) 6214 firefox-bin RET linux_sys_futex 0 6214 firefox-bin CALL linux_clock_gettime(0,0x366ff198) 6214 firefox-bin RET linux_clock_gettime 0 6214 firefox-bin CALL linux_sys_futex(0x2a206888,0x80,0x511f,0x366ff198,0x511f,0x366ff1dc) 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0x5) 6214 firefox-bin RET linux_sys_futex -1 errno 110 Unknown error: 110 6214 firefox-bin CALL gettimeofday(0x366ff20c,0) 6214 firefox-bin RET gettimeofday 0 6214 firefox-bin CALL linux_sys_futex(0x2a256a60,0x81,0x1,0x2a256a60,0x2a256a60,0x366ff1f8) 6214 firefox-bin RET linux_sys_futex 0 6214 firefox-bin CALL write(0xb,0x366ff153,0x1) 6214 firefox-bin GIO fd 11 wrote 1 byte "?" 6214 firefox-bin RET write 1 6204 firefox-bin RET poll 1 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0xa,0xbfbfdbcf,0x1) 6204 firefox-bin GIO fd 10 read 1 byte "?" 6204 firefox-bin RET read 1 6204 firefox-bin CALL gettimeofday(0xbfbfdcfc,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdbd4,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdbd4,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdb4c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdb1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0x1) 6214 firefox-bin CALL gettimeofday(0x366ff20c,0) 6214 firefox-bin RET gettimeofday 0 6214 firefox-bin CALL gettimeofday(0x366ff1e4,0) 6214 firefox-bin RET gettimeofday 0 6214 firefox-bin CALL linux_clock_gettime(0,0x366ff198) 6214 firefox-bin RET linux_clock_gettime 0 6214 firefox-bin CALL linux_sys_futex(0x2a206888,0x80,0x5121,0x366ff198,0x5121,0x366ff1dc) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL write(0xb,0xbfbfdc93,0x1) 6204 firefox-bin GIO fd 11 wrote 1 byte "?" 6204 firefox-bin RET write 1 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x3,0) 6204 firefox-bin RET poll 1 6204 firefox-bin CALL read(0xa,0xbfbfdbcf,0x1) 6204 firefox-bin GIO fd 10 read 1 byte "?" 6204 firefox-bin RET read 1 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL poll(0x38271278,0x1,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0x18) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL write(0xb,0xbfbfdc93,0x1) 6204 firefox-bin GIO fd 11 wrote 1 byte "?" 6204 firefox-bin RET write 1 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x3,0) 6204 firefox-bin RET poll 1 6204 firefox-bin CALL read(0xa,0xbfbfdbcf,0x1) 6204 firefox-bin GIO fd 10 read 1 byte "?" 6204 firefox-bin RET read 1 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL poll(0x38271278,0x1,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0x18) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL write(0xb,0xbfbfdc93,0x1) 6204 firefox-bin GIO fd 11 wrote 1 byte "?" 6204 firefox-bin RET write 1 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x3,0) 6204 firefox-bin RET poll 1 6204 firefox-bin CALL read(0xa,0xbfbfdbcf,0x1) 6204 firefox-bin GIO fd 10 read 1 byte "?" 6204 firefox-bin RET read 1 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL poll(0x38271278,0x1,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0x18) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL write(0xb,0xbfbfdc93,0x1) 6204 firefox-bin GIO fd 11 wrote 1 byte "?" 6204 firefox-bin RET write 1 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x3,0) 6204 firefox-bin RET poll 1 6204 firefox-bin CALL read(0xa,0xbfbfdbcf,0x1) 6204 firefox-bin GIO fd 10 read 1 byte "?" 6204 firefox-bin RET read 1 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL poll(0x38271278,0x1,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x4,0x18) 6354 firefox-bin RET linux_nanosleep 0 6354 firefox-bin CALL gettimeofday(0x3903b238,0) 6354 firefox-bin RET gettimeofday 0 6354 firefox-bin CALL linux_select(0x29,0x3903b114,0,0,0x3903b194) 6214 firefox-bin RET linux_sys_futex -1 errno 110 Unknown error: 110 6214 firefox-bin CALL gettimeofday(0x366ff20c,0) 6214 firefox-bin RET gettimeofday 0 6214 firefox-bin CALL linux_sys_futex(0x2a256a60,0x81,0x1,0x2a256a60,0x2a256a60,0x366ff1f8) 6214 firefox-bin RET linux_sys_futex 0 6214 firefox-bin CALL write(0xb,0x366ff153,0x1) 6214 firefox-bin GIO fd 11 wrote 1 byte "?" 6214 firefox-bin RET write 1 6204 firefox-bin RET poll 1 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0xa,0xbfbfdbcf,0x1) 6204 firefox-bin GIO fd 10 read 1 byte "?" 6204 firefox-bin RET read 1 6204 firefox-bin CALL gettimeofday(0xbfbfdcfc,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdc4c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdccc,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdc9c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfdd1c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL read(0x3,0x2a25f094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL read(0x26,0x37cf0094,0x1000) 6204 firefox-bin RET read -1 errno 11 Resource deadlock avoided 6204 firefox-bin CALL gettimeofday(0xbfbfdba8,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL poll(0x326f9620,0x3,0) 6204 firefox-bin RET poll 0 6204 firefox-bin CALL gettimeofday(0xbfbfcaac,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL gettimeofday(0xbfbfca7c,0) 6204 firefox-bin RET gettimeofday 0 6204 firefox-bin CALL linux_select(0x4,0xbfbfd9cc,0xbfbfd94c,0,0) 6204 firefox-bin RET linux_select 1 6204 firefox-bin CALL writev(0x3,0xbfbfdaac,0x1) 6204 firefox-bin GIO fd 3 wrote 1560 bytes "5\^X\^D\0?; \^An\^A \^A\^W\0\^P\0<\^X\^B\0?; \^A\M^S\^D\^E\0?; \^A?; \^A(\0\0\0\0\0\0\0\M^S\^E\^D\0?; \^A@\0\0\0\0\0\0\0\M^S\^Z\a\0\^C; \^A?; \^A\^Z\^Z\^U\^U\^Q\^Q??\0\0\0\0\^W\0\^P\08\^Z\^D\0?; \^A\0\0\b\0\0\0\0\08\^Z\^D\0?; \^A\0\0\b\0\0\0\0\0>\^Z\a\0s\^A \^A?; \^A?;\ \^A?\^B?\^A\0\0\0\0\^W\0\^P\0005 \^D\0?; \^A?; \^A\^W\0\r\08 \^D\0}0 \^A\0\0\b\0\0\0\0\0H\^B1\^A?; \^A}0 \^A\^W\0\r\0\0\0\0\0\0 \0\0\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\ \M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\ \M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0???????????????\ ?????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\ \M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\ \M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\ \M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0???????\ ?????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\ \M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\ \0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\ \M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\0\0\0\0????????????????????????\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\M^Y\M^Y\M^Y?\0\0\0\0????\M^S\ \^D\^F\0?; \^A?; \^A&\0\0\0\0\^A\0\0\^A\0\0\0\M^S\b \0\^C; \^A?; \^A\0\0\0\0?; \^A\0\0\0\0\0\0\0\0\0\0\^A\0\^W\0\r\0\M^S\a\^B\0?; \^A6\a\^B\0?; \^A7\a\^E\0?; \^An\^A \^A\0\0\^A\0\0\0\0\0;\^B\^E\0?; \^A\0\0\0\0\M^Q\^A?\^A\^W\0\^P\0>\^B\a\0?; \^An\^A \^A?; \^A\0\0\0\ \0\M^Q\^A?\^A\^W\0\^P\0\M^S\a\^B\0?; \^A6\a\^B\0?; \^A" this gets repeated over and over again. the ktrace output grows ~ 10mb/10sec. cheers. alex From vk7rb at internode.on.net Sat Oct 31 03:41:39 2009 From: vk7rb at internode.on.net (Robert McKenzie) Date: Sat Oct 31 03:41:45 2009 Subject: linux-f10-libidn Message-ID: <4AEBAE54.3060300@internode.on.net> Sir, I am just in the process of updating my system and have noted after having done a cvsup using server 18 that my dns ports directory although it has an f8 version, does not have an f10 version although the Makefile shows a conflict with f10. You comments would be most appreciated. Regards, Robert McKenzie. From vk7rb at internode.on.net Sat Oct 31 03:55:33 2009 From: vk7rb at internode.on.net (Robert McKenzie) Date: Sat Oct 31 03:55:40 2009 Subject: linux-f10-tiff Message-ID: <4AEBB1A2.5040403@internode.on.net> Sir, I have been in the process of updating my system and note that there is no such version of the above in the ports although there is an f8 version and the Makefile shows a conflict with f10. You comments regarding the above would be much appreciated. Regards, Robert McKenzie. From gary.jennejohn at freenet.de Sat Oct 31 13:38:25 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Oct 31 13:38:32 2009 Subject: linux-f10-tiff In-Reply-To: <4AEBB1A2.5040403@internode.on.net> References: <4AEBB1A2.5040403@internode.on.net> Message-ID: <20091031143822.048ca188@ernst.jennejohn.org> On Sat, 31 Oct 2009 14:40:18 +1100 Robert McKenzie wrote: > I have been in the process of updating my system and note that there is > no such version of the above in the ports although there is an f8 > version and the Makefile shows a conflict with f10. > > You comments regarding the above would be much appreciated. > It's in my ports tree: /usr/ports/graphics/linux-f10-tiff Not all CVS servers are updated frequently. Try using a different server. --- Gary Jennejohn From gavin at FreeBSD.org Sat Oct 31 14:47:19 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sat Oct 31 14:47:31 2009 Subject: kern/138860: [linux] linux_socketcall() causing buffer overflow Message-ID: <200910311447.n9VElJoO065533@freefall.freebsd.org> Synopsis: [linux] linux_socketcall() causing buffer overflow Responsible-Changed-From-To: freebsd-bugs->freebsd-emulation Responsible-Changed-By: gavin Responsible-Changed-When: Sat Oct 31 14:43:42 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138860 From gavin at FreeBSD.org Sat Oct 31 14:59:08 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sat Oct 31 14:59:14 2009 Subject: kern/133144: [linux] linuxulator 2.6 crashes with nvidias libGL.so.1 Message-ID: <200910311459.n9VEx7pE073918@freefall.freebsd.org> Synopsis: [linux] linuxulator 2.6 crashes with nvidias libGL.so.1 Responsible-Changed-From-To: freebsd-bugs->freebsd-emulation Responsible-Changed-By: gavin Responsible-Changed-When: Sat Oct 31 14:57:41 UTC 2009 Responsible-Changed-Why: Apparently this is actually a problem in our linuxulator, involving the threading model used. Submitter will provide more details shortly. http://www.freebsd.org/cgi/query-pr.cgi?pr=133144 From alexbestms at math.uni-muenster.de Sat Oct 31 15:50:05 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Oct 31 15:50:16 2009 Subject: kern/133144: [linux] linuxulator 2.6 crashes with nvidias libGL.so.1 Message-ID: <200910311550.n9VFo57R017686@freefall.freebsd.org> The following reply was made to PR kern/133144; it has been noted by GNATS. From: Alexander Best To: , Cc: Subject: Re: kern/133144: [linux] linuxulator 2.6 crashes with nvidias libGL.so.1 Date: Sat, 31 Oct 2009 16:48:33 +0100 (CET) it took some time to entirely identify the cause of the problems reported in this PR. please disregard all previous comments trying to describe problem! they merely dealt with symptoms and not the actual cause! they're superseded by this comment! 1. although the problem report deals with a segfault related to a linux lib supplied with the nvidia closed source freebsd driver the problem isn't limited to this specific linux lib. 2. the problem should occur with any linux binary/lib which was built under/for a linux version which uses one of the old linux threading models. this comment from http://wiki.freebsd.org/linux-kernel provides a short description of the problem: "Linux has gone through two threading model changes. If a Linux application or library has been linked against the old pthreads without fast TLS support or pthreads with internal TLS support libraries it will segfault." a detailed description of the threading situation under linux as well as under freebsd can be found in this thread: http://lists.freebsd.org/pipermail/freebsd-threads/2003-June/000530.html 3. the nvidia closed source drivers are no longer suffering from the problem described in this PR. the reason for that is that during installation of the driver an application is run which detects the linux kernel version. the application detects whether libnvidia-tls.so (old threading model) or libnvidia-tls.so (new threading model) needs to be installed. the old threading model is used on linux kernel < 2.6, the new one on >= 2.6. the symptoms described in this PR were caused by this libnvidia-tls.so the whole time and NOT by libGL.so (it's merely linked against libnvidia-tls.so). the following short statement by zander@nvidia.com is added as a reference: "the two libnvidia-tls libraries support different TLS models: the one currently shipped with the NVIDIA FreeBSD graphics driver supports the old-style TLS model, the tls/ one the new ELF TLS model. The crashes you were seeing were not due to a problem with the Linux emulation layer. Future NVIDIA FreeBSD graphics driver releases will automatically determine which library to install." 4. right now the only way to run linux bins/libs which got build against a linux kernel with an old threading model is to alter compat.linux.osrelease and revert to 2.4 linux emulation mode. 5. what needs to be done to solve this PR is to determine the threading model of a bin/lib and a) figure out a way to execute it under 2.6 linux emulation or b) issue a warning and abort execution. right now this PR should be considered a 2.6.26 emulation stopper and makes it impossible to remove 2.4.2 emulation legacy code since this would prevent certain bins/libs to run at all. alex