From owner-freebsd-emulation@FreeBSD.ORG Mon Mar 8 20:29:52 2010 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73AE01065688 for ; Mon, 8 Mar 2010 20:29:52 +0000 (UTC) (envelope-from per@hedeland.org) Received: from pluto.hedeland.org (1-1-1-13a.mal.sth.bostream.se [82.182.84.27]) by mx1.freebsd.org (Postfix) with ESMTP id D22BA8FC1B for ; Mon, 8 Mar 2010 20:29:51 +0000 (UTC) Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.14.3/8.14.3) with ESMTP id o28KTnoa015717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Mar 2010 21:29:49 +0100 (CET) (envelope-from per@pluto.hedeland.org) Received: (from per@localhost) by pluto.hedeland.org (8.14.3/8.14.3/Submit) id o28KTnsa015716; Mon, 8 Mar 2010 21:29:49 +0100 (CET) (envelope-from per) Date: Mon, 8 Mar 2010 21:29:49 +0100 (CET) From: Per Hedeland Message-Id: <201003082029.o28KTnsa015716@pluto.hedeland.org> To: freebsd-emulation@freebsd.org In-Reply-To: <201003031701.o23H1SVM038408@pluto.hedeland.org> X-Scanned-By: MIMEDefang 2.64 on 10.1.1.1 Subject: Re: VirtualBox won't start X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 20:29:52 -0000 Well, in the absence of any feedback on the below, I went and re-read the wiki, including "Known Issues in previous versions of the port" which shouldn't be relevant, and there, lo and behold, was a description of this exact problem, with the advice "Kill one of them" - and it worked. After getting rid of a non-virtualbox-specific issue with the networking, I'm now up and running with a Linux guest - very nice. But, apparently this problem is not completely fixed in the 3.1.2 version - and since it was supposed to be fixed, I assume that someone knows something about it. Is there some debugging etc that I can do to track it down? The behavior is completely reproducible, and the workaround, while apparently reproducible too, will become annoying after a while I think.:-) --Per Hedeland Per Hedeland wrote: > >Hello, > >I was really looking forward to trying out VirtualBox after all the good >reports here, but it was not to be:-) - when I try to start it with >simply 'VirtualBox', it just sits there, doing basically nothing at >all... > >This is on i386 7.2-RELEASE, virtualbox-ose-3.1.2_1 and >virtualbox-ose-kmod-3.1.2_1 built from ports with default config and no >issues, vboxdrv.ko/vboxnetflt.ko/vboxnetadp.ko loaded fine as per >instructions. > >Below is the tail of a ktrace - the original process (1421) forks >(1422), and then 1421 is repeatedly and unsuccessfully polling on what I >believe is a pipe to 1422, while 1422 seems stuck in a _umtx_op() >call. The SIGINT is me hitting ^C (which works "fine"), rather quickly >here but I have also tried waiting a long time, it just keeps polling >forever. > >Any ideas about what the problem might be would be appreciated! > >Thanks >--Per Hedeland > > > 1421 VirtualBox CALL fork > 1421 VirtualBox RET fork 1422/0x58e > 1422 VirtualBox RET fork 0 > 1422 VirtualBox CALL thr_self(0x88301040) > 1422 VirtualBox RET thr_self 0 > 1421 VirtualBox CALL sigprocmask(SIG_SETMASK,0x883010d8,0) > 1421 VirtualBox RET sigprocmask 0 > 1421 VirtualBox CALL _umtx_op(0x88092dc4,0x12,0,0,0) > 1421 VirtualBox RET _umtx_op 0 > 1421 VirtualBox CALL _umtx_op(0x804edfc,0x11,0,0,0) > 1421 VirtualBox RET _umtx_op 0 > 1422 VirtualBox CALL getpid > 1422 VirtualBox RET getpid 1422/0x58e > 1421 VirtualBox CALL _umtx_op(0x804edfc,0x12,0,0,0) > 1421 VirtualBox RET _umtx_op 0 > 1422 VirtualBox CALL sysarch(0xa,0xbfbf76c0) > 1422 VirtualBox RET sysarch 0 > 1421 VirtualBox CALL mmap(0,0x100000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0) > 1422 VirtualBox CALL sigprocmask(SIG_SETMASK,0x883010d8,0) > 1421 VirtualBox RET mmap -1975517184/0x8a400000 > 1421 VirtualBox RET _umtx_op 0 > 1422 VirtualBox RET sigprocmask 0 > 1422 VirtualBox CALL _umtx_op(0x88092e0c,0x12,0,0,0) > 1422 VirtualBox RET _umtx_op 0 > 1422 VirtualBox CALL _umtx_op(0x88092de8,0x12,0,0,0) > 1422 VirtualBox RET _umtx_op 0 > 1422 VirtualBox CALL _umtx_op(0x88092dc4,0x12,0,0,0) > 1422 VirtualBox RET _umtx_op 0 > 1421 VirtualBox CALL close(0xf) > 1421 VirtualBox RET close 0 > 1421 VirtualBox CALL read(0xe,0xbfbf782b,0x1) > 1421 VirtualBox RET read -1 errno 35 Resource temporarily unavailable > 1422 VirtualBox CALL _umtx_op(0x804edfc,0x11,0,0,0) > 1421 VirtualBox CALL poll(0xbfbf7764,0x1,0x1388) > 1421 VirtualBox CALL wait4(0,0xbf9fef08,0,0) > 1421 VirtualBox RET poll 0 > 1421 VirtualBox CALL poll(0xbfbf7764,0x1,0x1388) > 1421 VirtualBox RET poll 0 > 1421 VirtualBox CALL poll(0xbfbf7764,0x1,0x1388) > 1421 VirtualBox RET poll 0 > 1421 VirtualBox CALL poll(0xbfbf7764,0x1,0x1388) > 1421 VirtualBox RET wait4 RESTART > 1421 VirtualBox PSIG SIGINT SIG_DFL > 1422 VirtualBox RET _umtx_op RESTART > 1422 VirtualBox PSIG SIGINT SIG_DFL