Re: [Xenomai-help] Some problems with shared memory

[Philippe Gerum <rpm@xenomai.org>]

On Wed, 2009-06-10 at 13:47 +0200, roderik.wildenburg@domain.hid
wrote:
> > -----Ursprüngliche Nachricht-----
> > Von: Philippe Gerum [mailto:rpm@xenomai.org
> > Gesendet: Dienstag, 9. Juni 2009 15:28
> > An: Wildenburg, Roderik RAEK3 MRA
> > Cc: gilles.chanteperdrix@xenomai.org; xenomai@xenomai.org
> > Betreff: Re: [Xenomai-help] Some problems with shared memory
> > 
> > On Mon, 2009-06-08 at 10:25 +0200, roderik.wildenburg@domain.hid
> > wrote:
> > > > 
> > > > roderik.wildenburg@domain.hid wrote:
> > > > >> All I want to hear is "yes, we ran the shm test 
> > without Xenomai, on
> > > > >> exactly the same kernel, on the same platform, and the shm 
> > > > >> test worked".
> > > > >> Because Xenomai runs plain Linux mmap under the hood and do no
> > > > >> particular check on the mmap length. So, the problem 
> > is either that
> > > > >> Linux mmap on that particular machine with that particular 
> > > > >> kernel does a
> > > > >> check on length, or that there is a subtle bug somewhere 
> > > > that I do not
> > > > >> want to investigate until I am usre that it is real.
> > > > > 
> > > > > 
> > > > > yes, we ran the shm test without Xenomai, on
> > > > > exactly the same kernel, on the same platform, and the shm 
> > > > > test worked.
> > > > > 
> > > > > This means : 
> > > > > I took a plain 2.4.25 PPC-Kernel and started killtest 
> > > > without pagealigned shm size and got the error message :
> > > > > shm_open fails. errno=38 SHM:/testshm
> > > > > shm_open: Function not implemented
> > > > > 
> > > > > Therefore I mounted a tmpfs on /dev/shm and killtest ran 
> > > > without any errormessage.
> > > > > To make shure the missing /dev/shm isn´t the reason for the 
> > > > mmap-error I took a xenomai-enhanced kernel, mounted /dev/shm 
> > > > and run (a xenomai-linked) killtest, but I still got the error :
> > > > > killtest2 # ./killtest -c
> > > > > createshm mmap: No such device or address
> > > > > shmsize = 100000; errno : 6 == Failed to create shm : -3
> > > > > killtest user exit !
> > > > > 
> > > > > This I tried with Xenomai 2.3.5 and 2.4.7 (and got the 
> > same error).
> > > > > Even on a Xenomai-enhanced kernel a killtest, which was 
> > > > linked without Xenomai-libraries, run without error.
> > > > > 
> > > > > Sorry for not having better news
> > > > > Roderik
> > > 
> > > 
> > > 
> > > > Hi,
> > > > 
> > > > this should have been fixed in the 2.4.8 release, so please 
> > > > test it and
> > > > tell us whether it works for you.
> > > > 
> > > 
> > > Hello,
> > > 
> > > sorry for the delayed answer.
> > > Yes and no: The restriction of a page aligned SHM-size 
> > seems to be abolished (I didn´t get the error message "No 
> > such device or address" any more).
> > > But my target still stalls, when I kill my test 
> > applications in the wrong order.
> > > For your convenience I appended the test again (start 
> > "killtest -c &" then "killtest &" and then kill the last one 
> > before the first).
> > > 
> > 
> > By "stalls", do you mean a lockup, or does your shell hang 
> > upon ^C while
> > the rest of the system keeps running fine?
> > 
> 
> In fact, my system reboots because a high priority (no other Xenomai task has higher priority) Xenomai watchdog trigger task isn´t executed any more (the hardware watchdog resets the system if it is not triggered for more than 0,5 seconds). 
> When I deactivate the watchdog, the console is dead immediatelly (after the kill) but the system seems to work  (ping works) for a while. Even a telnet login is sometimes (sometimes the system stalls with the login sometimes not) possible. Sometimes the system stalls only after a minute, sometimes not at all.
> Sorry that I can´t give you a better description, but the behaviour is pretty strange.
> 
> Here is the output of /proc/xenomai/irq when I had access to the system via telnet :
> fer1_rw:/ # cat /proc/xenomai/irq
> IRQ         CPU0
>   6:           0         pciibm0
> 256:       14619         [virtual]
> 259:           9         [virtual]
> fer1_rw:/ # cat /proc/xenomai/irq
> IRQ         CPU0
>   6:           0         pciibm0
> 256:       14619         [virtual]
> 259:           9         [virtual]
> fer1_rw:/ # cat /proc/xenomai/irq
> IRQ         CPU0
>   6:           0         pciibm0
> 256:       14619         [virtual]
> 259:           9         [virtual]

We have a stuck timer interrupt. Ok, the I-pipe 1.2 series for Linux 2.4
is so old that I have probably handwritten that code on some parchment
first, so please try the following patch. It is basically the most
recent I-pipe core available for the 2.6/powerpc series backported to
your venerable 2.4/ppc kernel. Let me know if the issue is gone; it
seems to be fixed here, but that's no proof unfortunately, given the
randomness of it.

http://download.gna.org/adeos/patches/v2.4/ppc/adeos-ipipe-2.4.25-ppc-DENX-2.0-00.patch

PS: this patch handles mpc5xxx, UIC and AIC (i.e. 4xx) PICs, so if you
are still based on an Icecube, this should do the trick; at least it
works on mine. Otherwise, just let me know which kind of hw you actually
run.

-- 
Philippe.