Hello Alexis, hello Philippe, thanks for your suggestions - the protection bits did the trick! Adding them to xnarch_remap_io_page_range(...) in rtdm_mmap_buffer() solved the problem. We already tried this few months ago using
pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE | _PAGE_GUARDED | PAGE_SHARED; but missed the fact that xnarch_remap_io_page_range only takes PAGE_SHARED instead of use vma->vm_page_prot as its 5th parameter. I am not sure wether this extension will have side effects on other architectures. Maybe there is a better place for this fix. What do you think? Thanks again! Thomas > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Philippe Gerum > Gesendet: Sonntag, 19. Oktober 2008 20:11 > An: Gilles Chanteperdrix > Cc: [email protected] > Betreff: Re: [Xenomai-help] rtdm_iomap_to_user on PPC > > Gilles Chanteperdrix wrote: > > Philippe Gerum wrote: > >> Gilles Chanteperdrix wrote: > >>> Alexis Berlemont wrote: > >>>> Hi, > >>>> > >>>> On Friday 17 October 2008 06:46, > [EMAIL PROTECTED] wrote: > >>>>> No comments or ideas? Providing this feature is > essential for our > >>>>> CPCI drivers. We have to port some Linux applications > to Xenomai > >>>>> which use that mmap stuff intensely. > >>>>> > >>>>> Thanks again! > >>>>> > >>>>> Thomas > >>>>> > >>>>>> -----Ursprüngliche Nachricht----- > >>>>>> Von: [EMAIL PROTECTED] > >>>>>> [mailto:[EMAIL PROTECTED] Im Auftrag von > >>>>>> [EMAIL PROTECTED] > >>>>>> Gesendet: Mittwoch, 8. Oktober 2008 11:49 > >>>>>> An: [email protected] > >>>>>> Betreff: [Xenomai-help] rtdm_iomap_to_user on PPC > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> in the following thread I was asking for a solution to use > >>>>>> rtdm_iomap_to_user() on PPC (MPC5200, Denx 2.4.25) > >>>> In 2.4 kernel, rtdm_iomap_to_user() is based on the function > >>>> remap_page_range (with vma->vm_flags |= VM_RESERVED). > >>>> > >>>> Once, I had to develop a classical Linux driver (for PPC) which > >>>> provided mmap functionalites so as to let a user > application mmap a > >>>> buffer allocated thanks to __get_free_pages(). > >>>> > >>>> On a 2.6 kernel, I used remap_pfn_range() and it works > great but on > >>>> 2.4 kernel the function remap_page_range() did not work as I > >>>> expected. I had a quick look on its implementation and I > found that > >>>> instead of mapping my buffer it mapped newly allocated > zeroed pages (if my memories are correct). > >>>> > >>>> If I remember well, these pages were allocated in lazy > mode. That > >>>> could explain the freeze of your whole system: in case a RT > >>>> application in primary mode tries to access the mmapped buffer. > >>> Well, normally, the fault should cause the RT application > to switch > >>> to secondary mode and be handled gracefully from there, > unless there > >>> is a bug hidden in Xenomai or I-pipe. Besides, RT applications > >>> usually use "mlockall", so the kernel should make all the pages > >>> present and not rely on further faults (at least, is it > how it works on 2.6). > >>> > >> powerpc may still trigger minor faults upon TLB misses > though. That > >> arch has a software-assisted MMU. > > > > Ok, and can these faults cause lockups when they happen in > primary mode? > > > > Unless I messed up things in the I-pipe patch, no. Depending > on the MMU management code, some of them will reach the Linux > fault handler and trigger the mode switch via the Xenomai > fault handler, others will be processed directly from the > low-level exception code when it is possible to fix up the > mapping from there. > > As I mentioned a long time ago, the issue is more likely > related to the protection bits used with PCI memory > resources, which do require additional fixup on powerpc > (_PAGE_GUARDED and _PAGE_NO_CACHE come to mind here). > > -- > Philippe. > > _______________________________________________ > Xenomai-help mailing list > [email protected] > https://mail.gna.org/listinfo/xenomai-help > Achtung: Neue E-Mail-Adresse! Attention: New e-mail-address! [EMAIL PROTECTED] -------------------------------------------------------- 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 [email protected] https://mail.gna.org/listinfo/xenomai-help
