7.3-STABLE and Linux version of SIMetrix

[Andre Albsmeier]

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 at 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 at 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.