Date: Mon, 3 Jan 2011 15:26:24 +0100 From: Andre Albsmeier <Andre.Albsmeier@siemens.com> To: Alexander Leidinger <Alexander@leidinger.net> Cc: "freebsd-emulation@freebsd.org" <freebsd-emulation@freebsd.org> Subject: Re: 7.3-STABLE and Linux version of SIMetrix Message-ID: <20110103142624.GA51543@curry.mchp.siemens.de> In-Reply-To: <20110102115021.00000c8b@unknown> References: <20101230075124.GA12923@curry.mchp.siemens.de> <20101231144800.00005c6d@unknown> <20110101224629.GA30540@curry.mchp.siemens.de> <20110102115021.00000c8b@unknown>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 02-Jan-2011 at 11:50:21 +0100, Alexander Leidinger wrote: > On Sat, 1 Jan 2011 23:46:29 +0100 Andre Albsmeier > <Andre.Albsmeier@siemens.com> wrote: > > > On Fri, 31-Dec-2010 at 14:48:00 +0100, Alexander Leidinger wrote: > > > On Thu, 30 Dec 2010 08:51:24 +0100 Andre Albsmeier > > > <Andre.Albsmeier@siemens.com> wrote: > > > > > > > I try to get the Linux version of SIMetrix (a very nice circuit > > > > simulator) running. Everything looks fine: It starts, the GUI > > > > comes up, you can draw schematics and so on. But when it comes > > > > to simulation, the (SIMetrix-)console says: > > > > > > > > *** Fatal error, out of memory *** > > > > Could not allocate shared heap > > > > Exception occurred while executing script command Run > > > > > > Is there something in the dmesg output? In case it tries to execute > > > an unsupported ioctl/syscall it should show up there. If not I > > > suggest to give 8.x a try, it has an improved linuxulator. > > > > Bad luck. I just started the PC-BSD 8.1 live system and > > the error there is exactly the same... > > Then there is only ktrace + linux_kdump (use the package) or dtrace > left. OK, that's what I found out so far: SIMetrix calls shm_open() (people over there are really helpful as I explained to them what I tried to do).. I can find this: 40654 SimIntro 1294053922.366978 CALL compat.accept(0x48eecee7,0xbfbf8830) 40654 SimIntro 1294053922.366983 NAMI "/compat/linux/dev/shm/" 40654 SimIntro 1294053922.366993 NAMI "/dev/shm/" 40654 SimIntro 1294053922.367017 RET compat.accept JUSTRETURN 40654 SimIntro 1294053922.367025 CALL open(0x48eecec9,O_RDONLY,<unused>0x1b6) 40654 SimIntro 1294053922.367029 NAMI "/compat/linux/proc/mounts" 40654 SimIntro 1294053922.367048 NAMI "/compat/linux" 40654 SimIntro 1294053922.367059 NAMI "/compat/linux/proc/mounts" ... reading in mounts ... Judging from a comment in Linux' shm_open.c: /* Open shared memory object. This implementation assumes the shmfs implementation introduced in the late 2.3.x kernel series to be available. Normally the filesystem will be mounted at /dev/shm but we fall back on searching for the actual mount point should opening such a file fail. */ the mount stuff found in kdump's output is where the code tries to find the shmfs which fails of course. Now I have to sit back and think what to do... -Andre -- Linux is no OS. It's a core dump which boots by accident.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110103142624.GA51543>