> -----Ursprüngliche Nachricht----- > Von: Philippe Gerum [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 21. Oktober 2008 13:12 > An: Debes, Thomas RAEK3 MRA > Cc: [email protected] > Betreff: Re: [Xenomai-help] rtdm_iomap_to_user on PPC > > [EMAIL PROTECTED] wrote: > > 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? > > > > Not all archs will have the same requirements, unfortunately. > Could you try the attached patch? It also makes sure that > prefetchable PCI memory won't be accessed as page guarded in 2.6. TIA,
Ok, got it working. Everything works as expected (at least for kernel 2.4). Will that patch be included in the next release (2.4.6)? Regards Thomas > > > 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 > > > > > -- > Philippe. > 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
