Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[Philippe Gerum <rpm@xenomai.org>]

thomas.debes@domain.hid wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Philippe Gerum [mailto:rpm@xenomai.org] 
>> Gesendet: Dienstag, 21. Oktober 2008 13:12
>> An: Debes, Thomas RAEK3 MRA
>> Cc: xenomai@xenomai.org
>> Betreff: Re: [Xenomai-help] rtdm_iomap_to_user on PPC
>>
>> thomas.debes@domain.hid 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)?
>

Yes.

> Regards
> Thomas
> 
> 
>>> Thanks again!
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: xenomai-help-bounces@domain.hid
>>>> [mailto:xenomai-help-bounces@domain.hid] Im Auftrag von Philippe Gerum
>>>> Gesendet: Sonntag, 19. Oktober 2008 20:11
>>>> An: Gilles Chanteperdrix
>>>> Cc: xenomai@xenomai.org
>>>> 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,
>>>> thomas.debes@domain.hid 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: xenomai-help-bounces@domain.hid 
>>>>>>>>>> [mailto:xenomai-help-bounces@domain.hid] Im Auftrag von 
>>>>>>>>>> thomas.debes@domain.hid
>>>>>>>>>> Gesendet: Mittwoch, 8. Oktober 2008 11:49
>>>>>>>>>> An: xenomai@xenomai.org
>>>>>>>>>> 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
>>>> Xenomai-help@domain.hid
>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>
>>> Achtung: Neue E-Mail-Adresse! Attention: New e-mail-address! 
>>> thomas.debes@domain.hid
>>> --------------------------------------------------------
>>> 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.
>>
> 
> Achtung: Neue E-Mail-Adresse! Attention: New e-mail-address! thomas.debes@domain.hid
> --------------------------------------------------------
> 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.