[Xenomai-help] Some problems with shared memory

[Xenomai-help] Some problems with shared memory

[roderik.wildenburg]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

I have two problems with shared memory and Xenomai 2.4.6 (2.4.25 PPC-kernel):

1.) If I don´t page align the size of shared memory (multiple of 4096) I get the following error message :
"createshm mmap: No such device or address"

Detailed programm output of attached testprogram :
{
prompt # ./killtest -c &
[1] 104
prompt # createshm mmap: No such device or address
shmsize = 100000; errno : 6 == Failed to create shm : -3
killtest user exit !
}

You can reproduce this effect by commenting out line 60 in the attached source file and calling the program as follows:

prompt # killtest -c


2.) If I create 2 processes which use the same shared memory and I kill the process which created the SHM before (!) the other process, which only uses the SHM, the whole system stalls.
You can reproduce this with the attached testprogramm by calling it in the following way :

prompt # ./killtest -c &
[1] 105
prompt # ./killtest &
[2] 106
prompt # kill 105
prompt # killtest user exit !
[1]-  Done                    ./killtest -c
prompt # kill 106

System stalls    


Is this a problem of Xenomai (Cleanup od SHM) or am I creating/deleting the SHM in a wrong way ?
Could you please try to reproduce this problem ?

Many thanks in advance
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

[-- Attachment #2: killtest.c --]
[-- Type: application/octet-stream, Size: 2967 bytes --]

/*
 * killtest.c
 *
 *  Created on: 24.03.2009
 *      Author: arowil
 */

#include <errno.h>
#include <unistd.h>
#include <signal.h>
#include <sys/mman.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/timex.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <sys/mman.h>
#include <string.h>
#include <fcntl.h>
#include <pthread.h>


#define SHMNAME "/testshm"

char *testshm=NULL;
int shmfd=-1;
int shmsize=0;
int create=0;
int finished=0;
pthread_t testtaskid;

int createshm(char **shmbuf, int *shmfd, int create)
{
   int ret, shmsize=0;
   int oflags;
   char *tshm;

   tshm=MAP_FAILED;
   ret=0;
   *shmbuf=NULL;
   *shmfd=-1;

   if(create)
      oflags=O_CREAT | O_RDWR;
   else
      oflags=O_RDWR;

   *shmfd = shm_open(SHMNAME, oflags, 0);
   if (*shmfd == -1)
   {
       printf("shm_open fails. errno=%d SHM:%s\n",errno,SHMNAME);
       perror("shm_open");
       ret=-1;
       goto createshmexit;
   }

   /*SHM-Size*/
   shmsize=100000;
   shmsize=((shmsize>>12)+1)<<12; /*page (4096) align*/
   ret=shmsize;
   if (ftruncate(*shmfd,shmsize) == -1)
   {
      printf("ftruncate fails. errno=%d\n",errno);
      ret=-2;
      goto createshmexit;
   }

   /* Map shared memory object */
   tshm = mmap(NULL, shmsize, PROT_READ | PROT_WRITE, MAP_SHARED, *shmfd, 0);
   if(tshm==MAP_FAILED)
   {
      printf("shmsize = %d; errno : %d == ", shmsize, errno);
      perror("createshm mmap");
      ret=-3;
      goto createshmexit;
   }
   else
   {
      if(create)
      {
         memset(tshm,0,shmsize);
      }
   }

   *shmbuf=tshm;

createshmexit :
   if(ret<0)
   {
      if(tshm!=MAP_FAILED)
      {
         munmap(tshm,shmsize);
      }
      if(*shmfd>=0)
      {
         shm_unlink(SHMNAME);
         close(*shmfd);
      }
      *shmbuf=NULL;
      *shmfd=-1;
   }

   return(ret);
}

void deleteshm(char *testshm, int shmsize, int shmfd, int create)
{
   if( (testshm!=NULL) && (shmfd!=-1) )
   {
      munmap(testshm,shmsize);
      if(create)
         shm_unlink(SHMNAME);
      close(shmfd);
      shmfd=-1;
   }
}

void user_exit(void)
{
   if(create)
      deleteshm(testshm,shmsize,shmfd,create);
   printf("killtest user exit !\n");
}



void sighand(int sig __attribute__ ((unused)))
{
   finished = 1;
}

int main(int argc, char *argv[])
{
   int c;

   while( (c = getopt(argc, argv, "c")) != EOF)
   {
      switch (c)
      {
         case 'c': // create SHM
            create=1;
            break;
         default:
            printf("killtest [-c]\n");
            return(0);
            break;
      }
   }

   signal(SIGINT, sighand);
   signal(SIGTERM, sighand);
   signal(SIGHUP, sighand);
   signal(SIGALRM, sighand);


   mlockall(MCL_CURRENT|MCL_FUTURE);

   if( (shmsize=createshm(&testshm, &shmfd, create))<0)
   {
      printf("Failed to create shm : %d\n",shmsize);
      user_exit();
      return(-1);
   }

   while (!finished)
      pause();

   user_exit();

   return 0;
}

[-- Attachment #3: Makefile --]
[-- Type: application/octet-stream, Size: 650 bytes --]

CROSSCOMPILE := ppc_6xx
TARGETS := killtest

XENO_PATH=/opt/eldk/xenomai-2.4.6
XENO_CONFIG=$(XENO_PATH)/bin/xeno-config
prefix := $(shell $(XENO_CONFIG) --prefix)

ifeq ($(prefix),)
$(error Please add <xenomai-install-path>/bin to your PATH variable or type: \
make XENO_CONFIG=<xenomai-install-path>/bin/xeno-config)
endif

CFLAGS_RT:= $(shell  $(XENO_CONFIG) --posix-cflags) -g -O -Wall 
LDFLAGS_RT:= $(shell  $(XENO_CONFIG) --posix-ldflags)

CC := $(CROSSCOMPILE)-gcc

all: $(TARGETS) 

killtest.o: killtest.c 
	$(CC) $(CFLAGS_RT) $< -c -o $@

killtest: killtest.o 
	$(CC)  $(LDFLAGS_RT) -Wall -o $@  killtest.o

	
clean:
	rm *.o $(TARGETS) *.asm 

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

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
> I have two problems with shared memory and Xenomai 2.4.6 (2.4.25 PPC-kernel):
> 
> 1.) If I don´t page align the size of shared memory (multiple of 4096) I get the following error message :
> "createshm mmap: No such device or address"
> 
> Detailed programm output of attached testprogram :
> {
> prompt # ./killtest -c &
> [1] 104
> prompt # createshm mmap: No such device or address
> shmsize = 100000; errno : 6 == Failed to create shm : -3
> killtest user exit !
> }
> 
> You can reproduce this effect by commenting out line 60 in the attached source file and calling the program as follows:
> 
> prompt # killtest -c
> 
> 
> 2.) If I create 2 processes which use the same shared memory and I kill the process which created the SHM before (!) the other process, which only uses the SHM, the whole system stalls.
> You can reproduce this with the attached testprogramm by calling it in the following way :
> 
> prompt # ./killtest -c &
> [1] 105
> prompt # ./killtest &
> [2] 106
> prompt # kill 105
> prompt # killtest user exit !
> [1]-  Done                    ./killtest -c
> prompt # kill 106
> 
> System stalls    
> 
> 
> Is this a problem of Xenomai (Cleanup od SHM) or am I creating/deleting the SHM in a wrong way ?
> Could you please try to reproduce this problem ?

Could you try to reproduce these issues with xenomai 2.4.7 and the patch
posted here:
https://mail.gna.org/public/xenomai-help/2009-03/msg00098.html

-- 
                                                 Gilles.

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

[roderik.wildenburg]

> > I have two problems with shared memory and Xenomai 2.4.6 
> (2.4.25 PPC-kernel):
> > 
> > 1.) If I don´t page align the size of shared memory 
> (multiple of 4096) I get the following error message :
> > "createshm mmap: No such device or address"
> > 
> > Detailed programm output of attached testprogram :
> > {
> > prompt # ./killtest -c &
> > [1] 104
> > prompt # createshm mmap: No such device or address
> > shmsize = 100000; errno : 6 == Failed to create shm : -3
> > killtest user exit !
> > }
> > 
> > You can reproduce this effect by commenting out line 60 in 
> the attached source file and calling the program as follows:
> > 
> > prompt # killtest -c
> > 
> > 
> > 2.) If I create 2 processes which use the same shared 
> memory and I kill the process which created the SHM before 
> (!) the other process, which only uses the SHM, the whole 
> system stalls.
> > You can reproduce this with the attached testprogramm by 
> calling it in the following way :
> > 
> > prompt # ./killtest -c &
> > [1] 105
> > prompt # ./killtest &
> > [2] 106
> > prompt # kill 105
> > prompt # killtest user exit !
> > [1]-  Done                    ./killtest -c
> > prompt # kill 106
> > 
> > System stalls    
> > 
> > 
> > Is this a problem of Xenomai (Cleanup od SHM) or am I 
> creating/deleting the SHM in a wrong way ?
> > Could you please try to reproduce this problem ?
> 
> Could you try to reproduce these issues with xenomai 2.4.7 
> and the patch
> posted here:
> https://mail.gna.org/public/xenomai-help/2009-03/msg00098.html
> 

Sorry, neither problem 1 nor problem 2 changed with 2.4.7 and your patch :

Output of killtest and Shared Memory not page aligned :
------------------------------------------------------
killtest2 # cat /proc/xenomai/version
2.4.7
killtest2 # ./killtest -c &
[1] 107
killtest2 # createshm mmap: No such device or address
shmsize = 100000; errno : 6 == Failed to create shm : -3
killtest user exit !
 
Output of killtest and Shared Memory page aligned :
---------------------------------------------------
killtest2 # cat /proc/xenomai/version
2.4.7
killtest2 # ./killtest -c &
[1] 109
killtest2 # ./killtest &
[2] 110
killtest2 #
killtest2 # kill 109
killtest user exit !
[1]-  Done                    ./killtest -c
killtest2 #
killtest2 # kill 110 

System stalled


Page align problem is the same with Xenomai 2.3.5
Output of killtest and Shared Memory not page aligned with xenomai 2.3.5:
-------------------------------------------------------------------------
killtest2 # cat /proc/xenomai/version
2.3.5
killtest2 # ./killtest -c &
[1] 120
killtest2 # createshm mmap: No such device or address
shmsize = 100000; errno : 6 == Failed to create shm : -3
killtest user exit !

[1]+  Done(255)               ./killtest -c
killtest2 # 


But the "stall"-problem does not occur with Xenomai 2.3.5 !
Output of killtest and Shared Memory page aligned with xenomai 2.3.5:
----------------------------------------------------------------------
killtest2 # cat /proc/xenomai/version
2.3.5
killtest2 # ./killtest -c &
[1] 122
killtest2 #
killtest2 # ./killtest &
[2] 123
killtest2 #
killtest2 # kill 122
killtest user exit !
[1]-  Done                    ./killtest -c
killtest2 #
killtest2 # kill 123
killtest2 # killtest user exit !

[2]+  Done                    ./killtest
killtest2 #
killtest2 #


Anything else I could test ?
Does the problem accour on your testequipment ?

Many thanks for your help
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

[Xenomai-help] Some problems with shared memory

[roderik.wildenburg]

Hi Gurus,

has anybody been able to reproduce this topic or is it just a problem of my hardware and software constellation ?

Roderik

> > > I have two problems with shared memory and Xenomai 2.4.6 
> > (2.4.25 PPC-kernel):
> > > 
> > > 1.) If I don´t page align the size of shared memory 
> > (multiple of 4096) I get the following error message :
> > > "createshm mmap: No such device or address"
> > > 
> > > Detailed programm output of attached testprogram :
> > > {
> > > prompt # ./killtest -c &
> > > [1] 104
> > > prompt # createshm mmap: No such device or address
> > > shmsize = 100000; errno : 6 == Failed to create shm : -3
> > > killtest user exit !
> > > }
> > > 
> > > You can reproduce this effect by commenting out line 60 in 
> > the attached source file and calling the program as follows:
> > > 
> > > prompt # killtest -c
> > > 
> > > 
> > > 2.) If I create 2 processes which use the same shared 
> > memory and I kill the process which created the SHM before 
> > (!) the other process, which only uses the SHM, the whole 
> > system stalls.
> > > You can reproduce this with the attached testprogramm by 
> > calling it in the following way :
> > > 
> > > prompt # ./killtest -c &
> > > [1] 105
> > > prompt # ./killtest &
> > > [2] 106
> > > prompt # kill 105
> > > prompt # killtest user exit !
> > > [1]-  Done                    ./killtest -c
> > > prompt # kill 106
> > > 
> > > System stalls    
> > > 
> > > 
> > > Is this a problem of Xenomai (Cleanup od SHM) or am I 
> > creating/deleting the SHM in a wrong way ?
> > > Could you please try to reproduce this problem ?
> > 
> > Could you try to reproduce these issues with xenomai 2.4.7 
> > and the patch
> > posted here:
> > https://mail.gna.org/public/xenomai-help/2009-03/msg00098.html
> > 
> 
> Sorry, neither problem 1 nor problem 2 changed with 2.4.7 and 
> your patch :
> 
> Output of killtest and Shared Memory not page aligned :
> ------------------------------------------------------
> killtest2 # cat /proc/xenomai/version
> 2.4.7
> killtest2 # ./killtest -c &
> [1] 107
> killtest2 # createshm mmap: No such device or address
> shmsize = 100000; errno : 6 == Failed to create shm : -3
> killtest user exit !
>  
> Output of killtest and Shared Memory page aligned :
> ---------------------------------------------------
> killtest2 # cat /proc/xenomai/version
> 2.4.7
> killtest2 # ./killtest -c &
> [1] 109
> killtest2 # ./killtest &
> [2] 110
> killtest2 #
> killtest2 # kill 109
> killtest user exit !
> [1]-  Done                    ./killtest -c
> killtest2 #
> killtest2 # kill 110 
> 
> System stalled
> 
> 
> Page align problem is the same with Xenomai 2.3.5
> Output of killtest and Shared Memory not page aligned with 
> xenomai 2.3.5:
> --------------------------------------------------------------
> -----------
> killtest2 # cat /proc/xenomai/version
> 2.3.5
> killtest2 # ./killtest -c &
> [1] 120
> killtest2 # createshm mmap: No such device or address
> shmsize = 100000; errno : 6 == Failed to create shm : -3
> killtest user exit !
> 
> [1]+  Done(255)               ./killtest -c
> killtest2 # 
> 
> 
> But the "stall"-problem does not occur with Xenomai 2.3.5 !
> Output of killtest and Shared Memory page aligned with xenomai 2.3.5:
> ----------------------------------------------------------------------
> killtest2 # cat /proc/xenomai/version
> 2.3.5
> killtest2 # ./killtest -c &
> [1] 122
> killtest2 #
> killtest2 # ./killtest &
> [2] 123
> killtest2 #
> killtest2 # kill 122
> killtest user exit !
> [1]-  Done                    ./killtest -c
> killtest2 #
> killtest2 # kill 123
> killtest2 # killtest user exit !
> 
> [2]+  Done                    ./killtest
> killtest2 #
> killtest2 #
> 
> 
> Anything else I could test ?
> Does the problem accour on your testequipment ?
> 
> Many thanks for your help
> Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
> I have two problems with shared memory and Xenomai 2.4.6 (2.4.25 PPC-kernel):
> 
> 1.) If I don´t page align the size of shared memory (multiple of 4096) I get the following error message :
> "createshm mmap: No such device or address"
> 
> Detailed programm output of attached testprogram :
> {
> prompt # ./killtest -c &
> [1] 104
> prompt # createshm mmap: No such device or address
> shmsize = 100000; errno : 6 == Failed to create shm : -3
> killtest user exit !
> }
> 
> You can reproduce this effect by commenting out line 60 in the attached source file and calling the program as follows:
> 
> prompt # killtest -c

Hi,

sorry for the late answer, your questions got somewhat forgotten.

Are you sure this issue is specific to xenomai, do not you have the same
effect with plain Linux shared memories ?

> 
> 
> 2.) If I create 2 processes which use the same shared memory and I kill the process which created the SHM before (!) the other process, which only uses the SHM, the whole system stalls.
> You can reproduce this with the attached testprogramm by calling it in the following way :

This issue should have been fixed in the course of the 2.5-rc1 release.

-- 
					    Gilles.

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

[Wolfgang Denk]

Dear Gilles,

in message <49FDFCC7.6000009@domain.hid> you wrote:
>
> > 1.) If I don´t page align the size of shared memory (multiple of 4096)
> I get the following error message :
> > "createshm mmap: No such device or address"
...
> Are you sure this issue is specific to xenomai, do not you have the same
> effect with plain Linux shared memories ?

To avoid misunderstandings, we should first point  out  that  we  are
here  in  fact *not* discussing classic shared memory in the sense of
the SysV SHM code, but the creation of shared memory regions by using
the mmap() system call.


For completeness: shmget(2) *does* allow to allocate sizes which are
not a multiple of pages sizes; but it then rounds up internally:

SHMGET(2) ... DESCRIPTION:

        ... A new shared memory segment, with size equal to the value
        of size rounded up to a multiple of PAGE_SIZE, is created ...

As far as mmap()  is  concerned,  there  is  no  restriction  on  the
"length"  parameter  (though  it  is  clear  that  internally this is
rounded up to a multiple of pages, too, but only "length"  bytes  are
visible to the user).

The restrictions for page allignments affect the addr and offset
paraemters only.


To me it seems clear that mmap() in plain Linux and Xenomai behave
differently.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@domain.hid
Let's say the docs present a simplified view of reality...    :-)
                      - Larry Wall in  <6940@domain.hid>

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

[Gilles Chanteperdrix]

Wolfgang Denk wrote:
> Dear Gilles,
> 
> in message <49FDFCC7.6000009@domain.hid> you wrote:
>>> 1.) If I don´t page align the size of shared memory (multiple of 4096)
>> I get the following error message :
>>> "createshm mmap: No such device or address"
> ...
>> Are you sure this issue is specific to xenomai, do not you have the same
>> effect with plain Linux shared memories ?
> 
> To avoid misunderstandings, we should first point  out  that  we  are
> here  in  fact *not* discussing classic shared memory in the sense of
> the SysV SHM code, but the creation of shared memory regions by using
> the mmap() system call.

Yes, obviously.

> 
> 
> For completeness: shmget(2) *does* allow to allocate sizes which are
> not a multiple of pages sizes; but it then rounds up internally:
> 
> SHMGET(2) ... DESCRIPTION:
> 
>         ... A new shared memory segment, with size equal to the value
>         of size rounded up to a multiple of PAGE_SIZE, is created ...
> 
> As far as mmap()  is  concerned,  there  is  no  restriction  on  the
> "length"  parameter  (though  it  is  clear  that  internally this is
> rounded up to a multiple of pages, too, but only "length"  bytes  are
> visible to the user).
> 
> The restrictions for page allignments affect the addr and offset
> paraemters only.
> 
> 
> To me it seems clear that mmap() in plain Linux and Xenomai behave
> differently.

It will be clear to me when someone will have run the tests.

-- 
					    Gilles.

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

[Thomas Lockhart]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

> >> 1.) If I don´t page align the size of shared memory (multiple of
> >> 4096)...
>  The restrictions for page allignments affect the addr and offset
>  paraemters only. To me it seems clear that mmap() in plain Linux and
>  Xenomai behave differently.

Sorry for not having the start of the thread. I'm not sure if it is 
helpful to note that when I implemented memory mapped "device drivers" 
for our system I had to align the address and offset to the page size 
before the call to mmap would succeed. That was with plain Linux and the 
driver also works with Xenomai.

                                      - Tom

-- 
Thomas Lockhart
Supervisor, Distributed and Real-time Group
Instrument Software and Science Data Systems
Caltech/JPL


[-- Attachment #2: Type: text/html, Size: 1272 bytes --]

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

[Wolfgang Denk]

Dear Thomas,

In message <49FF08C4.40908@domain.hid> you wrote:
>
> > >> 1.) If I don´t page align the size of shared memory (multiple of
> > >> 4096)...
> >  The restrictions for page allignments affect the addr and offset
> >  paraemters only. To me it seems clear that mmap() in plain Linux and
> >  Xenomai behave differently.
> 
> Sorry for not having the start of the thread. I'm not sure if it is 
> helpful to note that when I implemented memory mapped "device drivers" 
> for our system I had to align the address and offset to the page size 
> before the call to mmap would succeed. That was with plain Linux and the 
> driver also works with Xenomai.

This is correct, and documented behaviour. And if one thinks about
possible implementations, it just makes sense.

But the problem that the origonal poster reported was  a  restriction
of  the "length" parameter - his test seems to demonstrate that under
Xenomai the legth must be a multiple of the page sise, while in plain
Linux no such restriction exists (I can provide test  code  for  that
case, if wanted).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@domain.hid
What can it profit a man to gain the whole world and to come  to  his
property with a gastric ulcer, a blown prostate, and bifocals?
                                     -- John Steinbeck, _Cannery Row_

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

[Gilles Chanteperdrix]

Wolfgang Denk wrote:
> Dear Thomas,
> 
> In message <49FF08C4.40908@domain.hid> you wrote:
>>>>> 1.) If I don´t page align the size of shared memory (multiple of
>>>>> 4096)...
>>>  The restrictions for page allignments affect the addr and offset
>>>  paraemters only. To me it seems clear that mmap() in plain Linux and
>>>  Xenomai behave differently.
>> Sorry for not having the start of the thread. I'm not sure if it is 
>> helpful to note that when I implemented memory mapped "device drivers" 
>> for our system I had to align the address and offset to the page size 
>> before the call to mmap would succeed. That was with plain Linux and the 
>> driver also works with Xenomai.
> 
> This is correct, and documented behaviour. And if one thinks about
> possible implementations, it just makes sense.
> 
> But the problem that the origonal poster reported was  a  restriction
> of  the "length" parameter - his test seems to demonstrate that under
> Xenomai the legth must be a multiple of the page sise, while in plain
> Linux no such restriction exists (I can provide test  code  for  that
> case, if wanted).

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.

-- 
					    Gilles.

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

[roderik.wildenburg]

> 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

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Thomas Lockhart]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

>  But the problem that the origonal poster reported was  a  restriction
>  of  the "length" parameter - his test seems to demonstrate that
>  under Xenomai the legth must be a multiple of the page sise, while in
>  plain Linux no such restriction exists (I can provide test  code  for
>  that case, if wanted).

Hmm. My code does round the length to a multiple of the page size too. 
I'm pretty sure I would not have done this if it was not required but my 
svn notes are not explicit on this. The man page could be considered 
ambiguous: "EINVAL We  don't  like  start,  length, or offset (e.g., 
they are too large, or not aligned on a page boundary)." but only with a 
liberal reading of the sentence.

hth

                                      - Tom

-- 
Thomas Lockhart
Supervisor, Distributed and Real-time Group
Instrument Software and Science Data Systems
Caltech/JPL


[-- Attachment #2: Type: text/html, Size: 1453 bytes --]

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

[Wolfgang Denk]

Dear Thomas Lockhart,

In message <4A006AFD.1030409@domain.hid> you wrote:
>
> Hmm. My code does round the length to a multiple of the page size too. 
> I'm pretty sure I would not have done this if it was not required but my 
> svn notes are not explicit on this. The man page could be considered 
> ambiguous: "EINVAL We  don't  like  start,  length, or offset (e.g., 
> they are too large, or not aligned on a page boundary)." but only with a 
> liberal reading of the sentence.

If you read the man page carefully, then the meaning is clear: either
length is too large, and/or start and/or offset are too large or not
page aligned.

Please keep in mind that lots of code use mmap() to perform file I/O,
and most of the files in your file system have NOT a size that happens
to be a multiple of pages.

Here is a small example:

------------------------- cut here ------------------------------
#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

char	*cmdname;

int main(int argc, char *argv[])
{
	int fd;
	volatile caddr_t addr;
	char c;
	struct stat sbuf;

	cmdname =*argv++;

	if (argc != 2) {
		fprintf (stderr, "usage: %s file\n", cmdname);
		return 1;
	}

	if ((fd = open(*argv, O_RDWR)) < 0) {
		fprintf (stderr, "%s: can't open %s\n", cmdname, *argv);
		return 1;
	}

	/*
	 * Get the file size and try to map the whole file.
	 */
	if (fstat(fd, &sbuf) < 0) {
		perror ("stat");
		return 1;
	}

	printf ("Mapping %ld bytes\n", sbuf.st_size);

	addr = mmap(0, sbuf.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

	if (addr == (caddr_t)-1) {		/* mmap failed */
		perror ("mmap");
		return 1;
	}

	c = *addr;

	printf ("C = '%c' = 0x%02x\n", c, c);

	for ( ; ; ) {
		char new = *addr;

		if (c != new) {
			printf ("'%c' = 0x%02x  -->  '%c' = 0x%02x\n",
				c, c, new, new);
			c = new;
		}
		printf ("----------------------------------------\n");
		sleep (1);
	}

	/*
	 * Undo the mapping.
	 */
	munmap(addr, sbuf.st_size);
	return 0;
}
------------------------- cut here ------------------------------

Compile and test as follows:

-> gcc -Wall -pedantic -O -o mmap mmap.c
-> date >foo
-> ls -l foo
-rw-r--r-- 1 wd users 30 May  5 20:58 foo
-> ./mmap foo
Mapping 30 bytes
C = 'T' = 0x54
----------------------------------------
----------------------------------------
----------------------------------------
----------------------------------------
----------------------------------------
'T' = 0x54  -->  '3' = 0x33
----------------------------------------
----------------------------------------
----------------------------------------
----------------------------------------
----------------------------------------
'3' = 0x33  -->  'r' = 0x72
----------------------------------------
----------------------------------------
----------------------------------------
----------------------------------------
^C

While the program was running, I ran these commands from another
window:

-> echo 3 >/tmp/foo
-> echo r >/tmp/foo


The mapped lenght here is 30 bytes, which is obviously not a multiple
of the page size.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@domain.hid
When properly administered, vacations do not  diminish  productivity:
for every week you're away and get nothing done, there's another when
your boss is away and you get twice as much done.  -- Daniel B. Luten

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

[Gilles Chanteperdrix]

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.


-- 
					    Gilles.

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

[roderik.wildenburg]

[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]

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

Best regards
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

[-- Attachment #2: killtest2.zip --]
[-- Type: application/x-zip-compressed, Size: 23468 bytes --]

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

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
> 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).

Do you get this with a 2.4 or a 2.6 kernel?

-- 
					    Gilles.

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

[roderik.wildenburg]

> -----Ursprüngliche Nachricht-----
> Von: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
> Gesendet: Montag, 8. Juni 2009 22:37
> An: Wildenburg, Roderik RAEK3 MRA
> Cc: wd@domain.hid; xenomai@xenomai.org
> Betreff: Re: AW: AW: [Xenomai-help] Some problems with shared memory
> 
> roderik.wildenburg@domain.hid wrote:
> > 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).
> 
> Do you get this with a 2.4 or a 2.6 kernel?
> 

PPC 2.4 Kernel

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Philippe Gerum]

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?

> Best regards
> Roderik
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

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

[Philippe Gerum]

On Tue, 2009-06-09 at 15:28 +0200, Philippe Gerum wrote:
> On Mon, 2009-06-08 at 10:25 +0200, roderik.wildenburg@domain.hid
> > 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 case you still do have access to your system while the killtest
application stalled, then I would be interested by the combined output
of /proc/xenomai/irq, taken 3 times in a row. TIA,

-- 
Philippe.

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

[roderik.wildenburg]

> -----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]
 

Best regards
Roderik

P.s.: I will not be in office till next monday.

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Philippe Gerum]

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.

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

[roderik.wildenburg]

Hi,


> -----Ursprüngliche Nachricht-----
> Von: Philippe Gerum [mailto:rpm@xenomai.org
> Gesendet: Freitag, 12. Juni 2009 16:06
> An: Wildenburg, Roderik RAEK3 MRA
> Cc: gilles.chanteperdrix@xenomai.org; xenomai@xenomai.org
> Betreff: Re: AW: [Xenomai-help] Some problems with shared memory
> 
> 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.
> 

I applied your ipipe-patch to our 2.4.25 ppc kernel, but unfortunatelly I now can´t compile the kernel any more.
I get following error messages :

ipipe.c:393: error: `__switch_to' undeclared here (not in a function)
ipipe.c:393: error: initializer element is not constant
ipipe.c:393: error: (near initialization for `__ksymtab___switch_to.value')
ipipe.c:394: error: `show_stack' undeclared here (not in a function)
ipipe.c:394: error: initializer element is not constant
ipipe.c:394: error: (near initialization for `__ksymtab_show_stack.value')
ipipe.c:393: error: __ksymtab___switch_to causes a section type conflict
ipipe.c:394: error: __ksymtab_show_stack causes a section type conflict
make[1]: *** [ipipe.o] Fehler 1


The first error I could elimnate by deleting one '_'. 
"`show_stack' undeclared here" I eliminated by simply commenting out "EXPORT_SYMBOL_GPL(show_stack);" in ipipe.c
(just to see what will happen). 
But even after commenting out the most of the tail of ipipe.c :

EXPORT_SYMBOL_GPL(__switch_to);
//EXPORT_SYMBOL_GPL(show_stack);
EXPORT_SYMBOL_GPL(_switch);
EXPORT_SYMBOL_GPL(tasklist_lock);
//void atomic_set_mask(unsigned long mask, unsigned long *ptr);
//void atomic_clear_mask(unsigned long mask, unsigned long *ptr);
#ifdef FEW_CONTEXTS
EXPORT_SYMBOL_GPL(nr_free_contexts);
EXPORT_SYMBOL_GPL(context_mm);
EXPORT_SYMBOL_GPL(steal_context);
#endif	/* !FEW_CONTEXTS */
//EXPORT_SYMBOL_GPL(atomic_set_mask);
//EXPORT_SYMBOL_GPL(atomic_clear_mask);
EXPORT_SYMBOL_GPL(last_task_used_math);

the linker complains about multiple definitions of symbols :

ppc_6xx-ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic arch/ppc/kernel/head.o arch/ppc/kernel/idle_6xx.o init/main.o init/version.o init/do_mounts.o \
                --start-group \
                arch/ppc/kernel/kernel.o arch/ppc/platforms/platform.o arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
                 drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/ide/idedriver.o drivers/mtd/mtdlink.o drivers/macintosh/macintosh.o drivers/video/video.o drivers/media/media.o drivers/i2c/i2c.o kernel/xenomai/nucleus/xeno_nucleus.o kernel/xenomai/skins/native/xeno_native.o kernel/xenomai/skins/posix/xeno_posix.o kernel/xenomai/skins/rtdm/xeno_rtdm.o arch/ppc/5xxx_io/5xxx_io.o arch/ppc/xenomai/built-in.o \
                net/network.o \
                /home/arowil/mc45/svn/kernel_withoutadeos/source/lib/lib.a \
                --end-group \
                -o vmlinux
kernel/kernel.o(__ksymtab+0xfb0): In function `wait_for_completion':
/home/arowil/mc45/svn/kernel_withoutadeos/source/kernel/sched.c:851: multiple definition of `__ksymtab_tasklist_lock'
arch/ppc/kernel/kernel.o(__ksymtab+0x18):/home/arowil/mc45/svn/kernel_withoutadeos/source/arch/ppc/kernel/irq.c:575: first defined here
kernel/kernel.o(.kstrtab+0x2064): In function `ipipe_reenter_root':
/home/arowil/mc45/svn/kernel_withoutadeos/source/kernel/sched.c:536: multiple definition of `__kstrtab_tasklist_lock'
arch/ppc/kernel/kernel.o(.kstrtab+0x30):/home/arowil/mc45/svn/kernel_withoutadeos/source/arch/ppc/kernel/irq.c:578: first defined here
ppc_6xx-ld: Warning: size of symbol `__kstrtab_tasklist_lock' changed from 22 in arch/ppc/kernel/kernel.o to 14 in kernel/kernel.o


So, I stuck here a little bit. Do you have an idea what went wrong, or can you give me a hint where I have to look (I couldn´t even find the symbol  "tasklist_lock" in irq.c).
(Next problem will be, that Stefano Babic´s LTT-Patch for Xenomai/Linux won´t work any more with your new adeos patch, but this is an other story).

Our hardware is based on a freescale 5200B, so, as far as I understand your question about PICs, your patch should work for our hardware (I hope).

Thank you for your help and best regards
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Philippe Gerum]

On Tue, 2009-06-16 at 15:20 +0200, roderik.wildenburg@domain.hid
wrote:
> Hi,
> 
> I applied your ipipe-patch to our 2.4.25 ppc kernel, but unfortunatelly I now can´t compile the kernel any more.
> I get following error messages :
> 
> ipipe.c:393: error: `__switch_to' undeclared here (not in a function)
> ipipe.c:393: error: initializer element is not constant
> ipipe.c:393: error: (near initialization for `__ksymtab___switch_to.value')
> ipipe.c:394: error: `show_stack' undeclared here (not in a function)
> ipipe.c:394: error: initializer element is not constant
> ipipe.c:394: error: (near initialization for `__ksymtab_show_stack.value')
> ipipe.c:393: error: __ksymtab___switch_to causes a section type conflict
> ipipe.c:394: error: __ksymtab_show_stack causes a section type conflict
> make[1]: *** [ipipe.o] Fehler 1
> 
> 
> The first error I could elimnate by deleting one '_'.
>  
> "`show_stack' undeclared here" I eliminated by simply commenting out "EXPORT_SYMBOL_GPL(show_stack);" in ipipe.c
> (just to see what will happen). 
> But even after commenting out the most of the tail of ipipe.c :
> 
> EXPORT_SYMBOL_GPL(__switch_to);
> //EXPORT_SYMBOL_GPL(show_stack);
> EXPORT_SYMBOL_GPL(_switch);
> EXPORT_SYMBOL_GPL(tasklist_lock);
> //void atomic_set_mask(unsigned long mask, unsigned long *ptr);
> //void atomic_clear_mask(unsigned long mask, unsigned long *ptr);
> #ifdef FEW_CONTEXTS
> EXPORT_SYMBOL_GPL(nr_free_contexts);
> EXPORT_SYMBOL_GPL(context_mm);
> EXPORT_SYMBOL_GPL(steal_context);
> #endif	/* !FEW_CONTEXTS */
> //EXPORT_SYMBOL_GPL(atomic_set_mask);
> //EXPORT_SYMBOL_GPL(atomic_clear_mask);
> EXPORT_SYMBOL_GPL(last_task_used_math);
> 
> the linker complains about multiple definitions of symbols :
> 
> ppc_6xx-ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic arch/ppc/kernel/head.o arch/ppc/kernel/idle_6xx.o init/main.o init/version.o init/do_mounts.o \
>                 --start-group \
>                 arch/ppc/kernel/kernel.o arch/ppc/platforms/platform.o arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
>                  drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/ide/idedriver.o drivers/mtd/mtdlink.o drivers/macintosh/macintosh.o drivers/video/video.o drivers/media/media.o drivers/i2c/i2c.o kernel/xenomai/nucleus/xeno_nucleus.o kernel/xenomai/skins/native/xeno_native.o kernel/xenomai/skins/posix/xeno_posix.o kernel/xenomai/skins/rtdm/xeno_rtdm.o arch/ppc/5xxx_io/5xxx_io.o arch/ppc/xenomai/built-in.o \
>                 net/network.o \
>                 /home/arowil/mc45/svn/kernel_withoutadeos/source/lib/lib.a \
>                 --end-group \
>                 -o vmlinux
> kernel/kernel.o(__ksymtab+0xfb0): In function `wait_for_completion':
> /home/arowil/mc45/svn/kernel_withoutadeos/source/kernel/sched.c:851: multiple definition of `__ksymtab_tasklist_lock'
> arch/ppc/kernel/kernel.o(__ksymtab+0x18):/home/arowil/mc45/svn/kernel_withoutadeos/source/arch/ppc/kernel/irq.c:575: first defined here
> kernel/kernel.o(.kstrtab+0x2064): In function `ipipe_reenter_root':
> /home/arowil/mc45/svn/kernel_withoutadeos/source/kernel/sched.c:536: multiple definition of `__kstrtab_tasklist_lock'
> arch/ppc/kernel/kernel.o(.kstrtab+0x30):/home/arowil/mc45/svn/kernel_withoutadeos/source/arch/ppc/kernel/irq.c:578: first defined here
> ppc_6xx-ld: Warning: size of symbol `__kstrtab_tasklist_lock' changed from 22 in arch/ppc/kernel/kernel.o to 14 in kernel/kernel.o
> 
> 
> So, I stuck here a little bit. Do you have an idea what went wrong, or can you give me a hint where I have to look (I couldn´t even find the symbol  "tasklist_lock" in irq.c).
> (Next problem will be, that Stefano Babic´s LTT-Patch for Xenomai/Linux won´t work any more with your new adeos patch, but this is an other story).
> 
> Our hardware is based on a freescale 5200B, so, as far as I understand your question about PICs, your patch should work for our hardware (I hope).

This patch is based on the current HEAD of
git://www.denx.de/git/linuxppc_2_4_devel.git
(commit 5bab6d641ff5ba139f9f41869502cb7c96d785bc)

The patched kernel builds and runs fine using lite5200b_defconfig.

-- 
Philippe.

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

[roderik.wildenburg]

[-- Attachment #1: Type: text/plain, Size: 2338 bytes --]

Hello, 

> On Tue, 2009-06-16 at 15:20 +0200, roderik.wildenburg@domain.hid
> wrote:
> > Hi,
> > 
> > I applied your ipipe-patch to our 2.4.25 ppc kernel, but 
> unfortunatelly I now can´t compile the kernel any more.
> > I get following error messages :
> > 
> > ipipe.c:393: error: `__switch_to' undeclared here (not in a 
> function)
> > ipipe.c:393: error: initializer element is not constant
> > ipipe.c:393: error: (near initialization for 
> `__ksymtab___switch_to.value')
> > ipipe.c:394: error: `show_stack' undeclared here (not in a function)
> > ipipe.c:394: error: initializer element is not constant
> > ipipe.c:394: error: (near initialization for 
> `__ksymtab_show_stack.value')
> > ipipe.c:393: error: __ksymtab___switch_to causes a section 
> type conflict
> > ipipe.c:394: error: __ksymtab_show_stack causes a section 
> type conflict
> > make[1]: *** [ipipe.o] Fehler 1
> > 
> > 
> > 
> > Our hardware is based on a freescale 5200B, so, as far as I 
> understand your question about PICs, your patch should work 
> for our hardware (I hope).
> 
> This patch is based on the current HEAD of
> git://www.denx.de/git/linuxppc_2_4_devel.git
> (commit 5bab6d641ff5ba139f9f41869502cb7c96d785bc)
> 
> The patched kernel builds and runs fine using lite5200b_defconfig.
> 

Our kernel isn´t HEAD but is close to (2 or 3 commits before HEAD).
Nevetheless I checked out HEAD and used the lite5200b_defconfig.
Indeed the kernel compiles fine with this configuration. 
After comparing the lite5200b configuration with our one (uc101) and playing around quite a while with the options I figured out that "CONFIG_MODULES=y" does the trick. Activating this option leads to the errors I described in my ealier mails. Please find attached the .config I used to produce the compile errors.
Do you have an idea what I have to change in the 2.0-Ipipe-patch to make it work with CONFIG_MODULES enabled.

Thank you for your help and best regards 
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 23582 bytes --]

#
# Automatically generated by make menuconfig: don't edit
#
# CONFIG_UID16 is not set
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_ADVANCED_OPTIONS=y

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
# CONFIG_KMOD is not set

#
# Platform support
#
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E500 is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_8260 is not set
# CONFIG_83xx is not set
CONFIG_PPC_STD_MMU=y
# CONFIG_ALL_PPC is not set
# CONFIG_APUS is not set
# CONFIG_INKA4X0 is not set
# CONFIG_WILLOW is not set
# CONFIG_TOP5200 is not set
# CONFIG_CPCI690 is not set
# CONFIG_PCORE is not set
# CONFIG_POWERPMC250 is not set
# CONFIG_PPMC260 is not set
# CONFIG_EV64260 is not set
# CONFIG_SPRUCE is not set
# CONFIG_V38B is not set
# CONFIG_HMI1001 is not set
# CONFIG_PP01 is not set
# CONFIG_CPC45 is not set
# CONFIG_CU824 is not set
# CONFIG_PM520 is not set
# CONFIG_MCC200_BIG is not set
# CONFIG_PRS200 is not set
# CONFIG_PUMA_A is not set
# CONFIG_ALASKA is not set
# CONFIG_GLACIER is not set
# CONFIG_ICECUBE is not set
CONFIG_LITE5200B=y
# CONFIG_HXEB100 is not set
# CONFIG_LOPEC is not set
# CONFIG_MCPN765 is not set
# CONFIG_MVME5100 is not set
# CONFIG_PPLUS is not set
# CONFIG_PRPMC750 is not set
# CONFIG_PRPMC800 is not set
# CONFIG_SANDPOINT is not set
# CONFIG_P3G4 is not set
# CONFIG_ADIR is not set
# CONFIG_K2 is not set
# CONFIG_PAL4 is not set
# CONFIG_SL8245 is not set
# CONFIG_SMMACO4 is not set
# CONFIG_GEMINI is not set
# CONFIG_TQM5200 is not set
# CONFIG_UC101 is not set
# CONFIG_O2DNT is not set
# CONFIG_SORCERY is not set
CONFIG_PPC_5xxx=y
# CONFIG_SMP is not set
# CONFIG_ALTIVEC is not set
# CONFIG_TAU is not set
CONFIG_PPC_ISATIMER=y
# CONFIG_MPC5100 is not set
CONFIG_MPC5200=y
CONFIG_PPC_5xxx_PSC_CONSOLE_BAUD=115200
CONFIG_UBOOT=y
CONFIG_UBOOT=y
CONFIG_PPC_5xxx_PSC_CONSOLE_PORT=0
# CONFIG_PM is not set

#
# General setup
#
# CONFIG_BIGPHYS_AREA is not set
# CONFIG_HIGHMEM is not set
# CONFIG_LOWMEM_SIZE_BOOL is not set
# CONFIG_KERNEL_START_BOOL is not set
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
CONFIG_PCI=y
CONFIG_IPIPE=y
# CONFIG_IPIPE_DEBUG_CONTEXT is not set
CONFIG_NET=y
CONFIG_SYSCTL=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_KERNEL_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_OOM_KILLER is not set
# CONFIG_PCI_NAMES is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set
# CONFIG_GEN_RTC is not set
CONFIG_PPC_RTC=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="ip=off"

#
# Embedded options
#
# CONFIG_EMBEDDED is not set

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_CONCAT is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PUMA_A is not set
# CONFIG_MTD_CHESTNUT is not set
# CONFIG_MTD_K2 is not set
# CONFIG_MTD_HXEB100 is not set
# CONFIG_MTD_PPMC260 is not set
# CONFIG_MTD_CU824 is not set
# CONFIG_MTD_CPC45 is not set
# CONFIG_MTD_HMI1001 is not set
# CONFIG_MTD_ICECUBE is not set
# CONFIG_MTD_V38B is not set
# CONFIG_MTD_INKA4X0 is not set
# CONFIG_MTD_O2DNT is not set
# CONFIG_MTD_P3G4 is not set
# CONFIG_MTD_PP01 is not set
# CONFIG_MTD_MCC200 is not set
# CONFIG_MTD_PM520 is not set
# CONFIG_MTD_SL8245 is not set
# CONFIG_MTD_SMMACO4 is not set
# CONFIG_MTD_SORCERY is not set
# CONFIG_MTD_TOP5200 is not set
# CONFIG_MTD_TQM5200 is not set
# CONFIG_MTD_UC101 is not set
# CONFIG_MTD_PCI is not set
# CONFIG_MTD_PCMCIA is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_DOCPROBE is not set
# CONFIG_MTD_DOCECC is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_NANDSIM is not set

#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_CISS_MONITOR_THREAD is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BLK_STATS is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set

#
#    SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set

#
# Appletalk devices
#
# CONFIG_DEV_APPLETALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_IDEPCI_SHARE_IRQ is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_PCI_AUTO is not set
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_ADMA100 is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_PDC202XX_BURST is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_SL82C105 is not set
CONFIG_BLK_DEV_IDE_MPC5xxx=y
CONFIG_BLK_DEV_IDE_MPC5xxx_MDMA=y
CONFIG_BLK_DEV_IDE_MPC5xxx_UDMA=y
# CONFIG_IDE_CHIPSETS is not set
# CONFIG_IDEDMA_AUTO is not set
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set
# CONFIG_BLK_DEV_ATARAID_SII is not set

#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_SCSI_DEBUG_QUEUES is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_MEGARAID2 is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MACE is not set
# CONFIG_BMAC is not set
# CONFIG_GMAC is not set
# CONFIG_SUNLANCE is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_GIANFAR is not set
# CONFIG_GFAR_NAPI is not set
# CONFIG_GFAR_BDSTASH is not set
# CONFIG_GFAR_BUFSTASH is not set
# CONFIG_FDDI is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Console drivers
#
# CONFIG_VGA_CONSOLE is not set

#
# Frame-buffer support
#
# CONFIG_FB is not set

#
# Input core support
#
# CONFIG_INPUT is not set
# CONFIG_INPUT_KEYBDEV is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_UINPUT is not set

#
# Macintosh device drivers
#

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL is not set
# CONFIG_SERIAL_EXTENDED is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_DIGI is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_N_HDLC is not set
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set
# CONFIG_PS2MULT is not set
# CONFIG_KEYMAP_DE_LATIN1 is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# I2C support
#
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set

#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_QIC02_TAPE is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
# CONFIG_IPMI_KCS is not set
# CONFIG_IPMI_WATCHDOG is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_SCx200 is not set
# CONFIG_SCx200_GPIO is not set
# CONFIG_AMD_PM768 is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_RTC_11_MINUTE_MODE is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_FLASH is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set

#
# Direct Rendering Manager (XFree86 DRI support)
#
# CONFIG_DRM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_QFMT_V2 is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=y
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_JFFS2_LZO is not set
# CONFIG_JFFS2_LZARI is not set
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
CONFIG_JFFS2_PROC=y
CONFIG_CRAMFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
CONFIG_ROMFS_FS=y
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_XFS_FS is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_TRACE is not set
# CONFIG_XFS_DEBUG is not set

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SMB_NLS is not set
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# MPC5xxx I/O Options
#
CONFIG_BESTCOMM_API=y
CONFIG_PPC_5xxx_FEC=y
CONFIG_USE_MDIO=y
CONFIG_FEC_GENERIC_PHY=y
CONFIG_FEC_LXT971=y
# CONFIG_FEC_DP83847 is not set
# CONFIG_FEC_AM79C874 is not set
CONFIG_PPC_5xxx_PSC=y
CONFIG_PPC_5xxx_PSC_CONSOLE=y
CONFIG_SERIAL_CONSOLE=y
# CONFIG_5200_I2S is not set
# CONFIG_5200_I2S_RING is not set
# CONFIG_UDA_1344 is not set
# CONFIG_5200_AC97 is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_DEVICEFS is not set
# CONFIG_USB_BANDWIDTH is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_UHCI is not set
# CONFIG_USB_UHCI_ALT is not set
CONFIG_USB_OHCI_PCI=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_OHCI_5xxx is not set
# CONFIG_USB_SINGLEENDED is not set
# CONFIG_USB_USEBOTH is not set
CONFIG_USB_OHCI=y
# CONFIG_USB_ISP1362 is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_BLUETOOTH is not set
# CONFIG_USB_MIDI is not set
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT is not set
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_CATC is not set
# CONFIG_USB_CDCETHER is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_BRLVGER is not set
# CONFIG_USB_LCD is not set
# CONFIG_ISP1362_USB is not set
# CONFIG_ISP1362_NETLINK is not set

#
# Support for USB gadgets
#
# CONFIG_USB_GADGET is not set

#
# Bluetooth support
#
# CONFIG_BLUEZ is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
# CONFIG_CRC32 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
# CONFIG_REED_SOLOMON is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_WAITQ is not set
# CONFIG_KGDB is not set
# CONFIG_XMON is not set
CONFIG_BDI_SWITCH=y
CONFIG_MORE_COMPILE_OPTIONS=y
CONFIG_COMPILE_OPTIONS="-g -ggdb"
# CONFIG_SERIAL_TEXT_DEBUG is not set
CONFIG_LOG_BUF_SHIFT=0

#
# Real-time sub-system
#
# CONFIG_XENOMAI is not set

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

[Philippe Gerum]

On Wed, 2009-06-17 at 13:40 +0200, roderik.wildenburg@domain.hid
wrote:
> Hello, 
> 
> > On Tue, 2009-06-16 at 15:20 +0200, roderik.wildenburg@domain.hid
> > wrote:
> > > Hi,
> > > 
> > > I applied your ipipe-patch to our 2.4.25 ppc kernel, but 
> > unfortunatelly I now can´t compile the kernel any more.
> > > I get following error messages :
> > > 
> > > ipipe.c:393: error: `__switch_to' undeclared here (not in a 
> > function)
> > > ipipe.c:393: error: initializer element is not constant
> > > ipipe.c:393: error: (near initialization for 
> > `__ksymtab___switch_to.value')
> > > ipipe.c:394: error: `show_stack' undeclared here (not in a function)
> > > ipipe.c:394: error: initializer element is not constant
> > > ipipe.c:394: error: (near initialization for 
> > `__ksymtab_show_stack.value')
> > > ipipe.c:393: error: __ksymtab___switch_to causes a section 
> > type conflict
> > > ipipe.c:394: error: __ksymtab_show_stack causes a section 
> > type conflict
> > > make[1]: *** [ipipe.o] Fehler 1
> > > 
> > > 
> > > 
> > > Our hardware is based on a freescale 5200B, so, as far as I 
> > understand your question about PICs, your patch should work 
> > for our hardware (I hope).
> > 
> > This patch is based on the current HEAD of
> > git://www.denx.de/git/linuxppc_2_4_devel.git
> > (commit 5bab6d641ff5ba139f9f41869502cb7c96d785bc)
> > 
> > The patched kernel builds and runs fine using lite5200b_defconfig.
> > 
> 
> Our kernel isn´t HEAD but is close to (2 or 3 commits before HEAD).
> Nevetheless I checked out HEAD and used the lite5200b_defconfig.
> Indeed the kernel compiles fine with this configuration. 
> After comparing the lite5200b configuration with our one (uc101) and playing around quite a while with the options I figured out that "CONFIG_MODULES=y" does the trick. Activating this option leads to the errors I described in my ealier mails. Please find attached the .config I used to produce the compile errors.
> Do you have an idea what I have to change in the 2.0-Ipipe-patch to make it work with CONFIG_MODULES enabled.
> 

The EXPORT directives were wrong, actually copied&pasted as is from 2.6.
Try this patch instead:

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


> Thank you for your help and best regards 
> Roderik
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933
-- 
Philippe.

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

[roderik.wildenburg]

Hi,

> 
> The EXPORT directives were wrong, actually copied&pasted as 
> is from 2.6.
> Try this patch instead:
> 
> http://download.gna.org/adeos/patches/v2.4/ppc/adeos-ipipe-2.4
.25-ppc-DENX-2.0-01.patch
> 
> 

Great! This patch applies and compiles fine and solves my "stall" problem.
Thanks a lot !!

Best regards
Roderik


(Just as a hint for all those, whose kernel isn´t Head of the 2.4.25 Denx git-repository:
The new adeos-patch tries to patch a file named .gitignore. If this does not exist, xenomai prepare-kernel fails. 
I simply deleted the hunk concerning .gitignore which is, at least from my point of view, sustainable, as this file isn´t needed for compilation.)

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

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

[Philippe Gerum]

On Thu, 2009-06-18 at 10:37 +0200, roderik.wildenburg@domain.hid
wrote:
> Hi,
> 
> > 
> > The EXPORT directives were wrong, actually copied&pasted as 
> > is from 2.6.
> > Try this patch instead:
> > 
> > http://download.gna.org/adeos/patches/v2.4/ppc/adeos-ipipe-2.4
> .25-ppc-DENX-2.0-01.patch
> > 
> > 
> 
> Great! This patch applies and compiles fine and solves my "stall" problem.
> Thanks a lot !!
> 
> Best regards
> Roderik
> 
> 
> (Just as a hint for all those, whose kernel isn´t Head of the 2.4.25 Denx git-repository:
> The new adeos-patch tries to patch a file named .gitignore. If this does not exist, xenomai prepare-kernel fails. 
> I simply deleted the hunk concerning .gitignore which is, at least from my point of view, sustainable, as this file isn´t needed for compilation.)
> 

This extraneous hunk has just been removed from the patch in the dl and
Xenomai repo. Thanks.

> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933
-- 
Philippe.