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
