From owner-freebsd-emulation@freebsd.org Wed Sep 14 06:09:27 2016 Return-Path: Delivered-To: freebsd-emulation@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26957BDA01F for ; Wed, 14 Sep 2016 06:09:27 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from heemeyer.club (heemeyer.club [108.61.204.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "heemeyer.club", Issuer "heemeyer.club" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0814AA6E for ; Wed, 14 Sep 2016 06:09:26 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from chd.heemeyer.club (dchagin.static.corbina.ru [78.107.232.239]) by heemeyer.club (8.15.2/8.15.1) with ESMTPS id u8E5v0Ee096125 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Sep 2016 05:57:02 GMT (envelope-from dchagin@chd.heemeyer.club) X-Authentication-Warning: heemeyer.club: Host dchagin.static.corbina.ru [78.107.232.239] claimed to be chd.heemeyer.club Received: from chd.heemeyer.club (localhost [127.0.0.1]) by chd.heemeyer.club (8.15.2/8.15.1) with ESMTPS id u8E5uxK0010383 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Sep 2016 08:56:59 +0300 (MSK) (envelope-from dchagin@chd.heemeyer.club) Received: (from dchagin@localhost) by chd.heemeyer.club (8.15.2/8.15.2/Submit) id u8E5uxOR010382; Wed, 14 Sep 2016 08:56:59 +0300 (MSK) (envelope-from dchagin) Date: Wed, 14 Sep 2016 08:56:59 +0300 From: Chagin Dmitry To: Joe Love Cc: freebsd-emulation@freebsd.org Subject: Re: linux-compat semctl operation - bad address Message-ID: <20160914055659.GA10348@chd.heemeyer.club> References: <276F4863-DE8C-49F7-BB60-F8614F88064C@getsomewhere.net> <4AB10098-988D-4DB9-ADB3-8F0C26C86B73@getsomewhere.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4AB10098-988D-4DB9-ADB3-8F0C26C86B73@getsomewhere.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.23 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: Wed, 14 Sep 2016 06:09:27 -0000 On Mon, Sep 12, 2016 at 02:57:01PM -0500, Joe Love wrote: > > > On Sep 9, 2016, at 4:34 PM, Joe Love wrote: > > > > Hi, > > > > I have a linux binary I’m trying to run on a 12-CURRENT machine with the linux_base-c7 (64-bit) port. > > > > When trying to run it, it starts up and then spits out this error: > > shm_semaphores_init: semctl init error: Bad address - trying again > > > > I’m guessing that it’s reaching the end of the switch statement in sys/compat/linux/linux_ipc.c’s linux_semctl(…) function and getting an EINVAL result. That’s a guess, however, as I don’t know enough about debugging at this level in order to tell what it’s actually doing. > > > > Can anyone tell me how to get the results of the linux_msg() call at the end of the function to find out what ipc type it’s trying to utilize, and with a little luck maybe get a patch created to support whatever operation it’s trying? > > > > Thanks, > > -Joe > > > > A little further explanation (since I failed to give it earlier): I have two linux game servers that do this, “7 Days to Die” (7dtd) and “Unturned.” Based on the first dtrace probe I tried (entry), it seems that 7dtd might be easier to understand. Obviously I don’t have access to game sources. > > I did a little digging with dtrace, though my knowledge of dtrace is all new as of this experience. > > /* my dtrace probe file, semprobe.d */ > fbt:linux:linux_semctl:entry, > fbt:linux64:linux_semctl:entry > { > /* args->cmd & ~LINUX_IPC_64 .. LINUX_IPC_64 = 0x0100 */ > printf("%s (%d, %d, %d, %d)", probefunc, args[1]->cmd, args[1]->cmd & ~0x0100, args[1]->semid, args[1]->arg.val); > } > fbt:kernel:kern_semctl:entry > { > printf("%s (%d, %d, %d, %d)", probefunc, args[3], args[3], args[1], args[4]->val); > } > fbt:kernel:kern_semctl:return > { > printf("%s (%d, %d)", probefunc, args[1], errno); > } > > fbt:linux:linux_semctl:return, > fbt:linux64:linux_semctl:return > { > printf("%s (%d, %d)\n", probefunc, args[1], errno); > } > I ran that with "dtrace -n semprobe.d” > > When I ran the 7dtd server, dtrace proceeded to spit out this information (while 7dtd spat out it’s error in my first email): > dtrace: script 'semprobe.d' matched 6 probes > CPU ID FUNCTION:NAME > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952369158, 0) > 21 37620 kern_semctl:entry kern_semctl (9, 9, 952369158, -11936) > 21 37621 kern_semctl:return kern_semctl (14, 0) > 21 63001 linux_semctl:return linux_semctl (14, 0) > > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952369158, 0) > 21 37620 kern_semctl:entry kern_semctl (0, 0, 952369158, 1876522240) > 21 37621 kern_semctl:return kern_semctl (0, 14) > 21 63001 linux_semctl:return linux_semctl (0, 14) > > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952434694, 0) > 21 37620 kern_semctl:entry kern_semctl (9, 9, 952434694, -11936) > 21 37621 kern_semctl:return kern_semctl (14, 0) > 21 63001 linux_semctl:return linux_semctl (14, 0) > > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952434694, 0) > 21 37620 kern_semctl:entry kern_semctl (0, 0, 952434694, 1876522240) > 21 37621 kern_semctl:return kern_semctl (0, 14) > 21 63001 linux_semctl:return linux_semctl (0, 14) > > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952500230, 0) > 21 37620 kern_semctl:entry kern_semctl (9, 9, 952500230, -11936) > 21 37621 kern_semctl:return kern_semctl (14, 0) > 21 63001 linux_semctl:return linux_semctl (14, 0) > > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952500230, 0) > 21 37620 kern_semctl:entry kern_semctl (0, 0, 952500230, 1876522240) > 21 37621 kern_semctl:return kern_semctl (0, 14) > 21 63001 linux_semctl:return linux_semctl (0, 14) > > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952565766, 0) > 21 37620 kern_semctl:entry kern_semctl (9, 9, 952565766, -11936) > 21 37621 kern_semctl:return kern_semctl (14, 0) > 21 63001 linux_semctl:return linux_semctl (14, 0) > > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952565766, 0) > 21 37620 kern_semctl:entry kern_semctl (0, 0, 952565766, 1876522240) > 21 37621 kern_semctl:return kern_semctl (0, 0) > 21 63001 linux_semctl:return linux_semctl (0, 0) > > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952631302, 0) > 21 37620 kern_semctl:entry kern_semctl (9, 9, 952631302, -11936) > 21 37621 kern_semctl:return kern_semctl (14, 0) > 21 63001 linux_semctl:return linux_semctl (14, 0) > > 21 63000 linux_semctl:entry linux_semctl (0, 0, 952631302, 0) > 21 37620 kern_semctl:entry kern_semctl (0, 0, 952631302, 1876522240) > 21 37621 kern_semctl:return kern_semctl (0, 0) > 21 63001 linux_semctl:return linux_semctl (0, 0) > (and repeated the last 2 ’sets', with other semaphore ID’s, always incrementing) > > > I’m hoping someone can find fault with my assessment, because I don't understand why args->cmd seems to go from LINUX_IPC_RMID (0) to bsd’s SETALL (9). > > Anyone have thoughts on what to check, or maybe what is going on? > hi, could you please do: ktrace -di /path/to/u/bin and then kdump -HAR -m64 > xxxx.out and then send me xxxx.out, thanks