[Xenomai-help] rtdm_iomap_to_user on PPC

[Xenomai-help] rtdm_iomap_to_user on PPC

[thomas.debes]

Hello,

in the following thread I was asking for a solution to use
rtdm_iomap_to_user() on PPC (MPC5200, Denx 2.4.25)

https://mail.gna.org/public/xenomai-help/2008-05/msg00153.html

As suggested by Philippe I tried the current 2.4.5 stable release, but
the problem still remains. The call to rtdm_iomap_to_user returns
success (0) but any access to the mapped memory section ends in freezing
the whole system.

Thanks for your help!

Thomas

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

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[thomas.debes]

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)
> 
> https://mail.gna.org/public/xenomai-help/2008-05/msg00153.html
> 
> As suggested by Philippe I tried the current 2.4.5 stable 
> release, but the problem still remains. The call to 
> rtdm_iomap_to_user returns success (0) but any access to the 
> mapped memory section ends in freezing the whole system.
> 
> Thanks for your help!
> 
> Thomas
> 
> 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
>

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

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[Alexis Berlemont]

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.

My remembrance are not very accurate and considering the hour, I will just be 
able to give you some idea of tests to perform.

1) Have you tried to access your driver with a classical NRT process (not with 
a RT task even on secondary mode); in such a configuration, I think there 
should be no freeze.

2) Could you try to develop a minimal Linux driver (without RTDM) which maps a 
buffer thanks to remap_page_range(). Could you check that you are not able to 
properly access the data (you should read zero everywhere) ? A good test 
would be to open and perform the mmap with a classical user process and, once 
the mmap initialization is done, you could shadow your process 
(rt_task_shadow) and try to access the mmapped buffer. That should freeze 
your system and then prove that the problem comes from remap_page_range().

In my case, I resolved my problem by using the no_page() way described in 
Rubbini's book (Linux device driver 2nd edition). By the way, I think that 
was the recommended method for my configuration.

Alexis.

> > https://mail.gna.org/public/xenomai-help/2008-05/msg00153.html
> >
> > As suggested by Philippe I tried the current 2.4.5 stable
> > release, but the problem still remains. The call to
> > rtdm_iomap_to_user returns success (0) but any access to the
> > mapped memory section ends in freezing the whole system.
> >
> > Thanks for your help!
> >
> > Thomas
> >
> > 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
>
> 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

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[Gilles Chanteperdrix]

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

-- 
					    Gilles.

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[Philippe Gerum]

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.

-- 
Philippe.

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[Gilles Chanteperdrix]

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?

-- 
					    Gilles.

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[Philippe Gerum]

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.

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[thomas.debes]

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

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[Philippe Gerum]

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

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,

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

[-- Attachment #2: platform-dependent-phys-access-prot.patch --]
[-- Type: text/x-diff, Size: 2599 bytes --]

Index: include/asm-generic/system.h
===================================================================
--- include/asm-generic/system.h	(revision 4270)
+++ include/asm-generic/system.h	(working copy)
@@ -409,13 +409,16 @@
     return wrap_remap_vm_page(vma,from,to);
 }
 
-static inline int xnarch_remap_io_page_range(struct vm_area_struct *vma,
+static inline int xnarch_remap_io_page_range(struct file *filp,
+					     struct vm_area_struct *vma,
 					     unsigned long from,
 					     unsigned long to,
 					     unsigned long size,
 					     pgprot_t prot)
 {
-    return wrap_remap_io_page_range(vma,from,to,size,prot);
+	return wrap_remap_io_page_range(vma,from,to,size,
+					wrap_phys_mem_prot(filp, (to) >> PAGE_SHIFT,
+							   size, prot));
 }
 
 static inline int xnarch_remap_kmem_page_range(struct vm_area_struct *vma,
Index: include/asm-powerpc/wrappers.h
===================================================================
--- include/asm-powerpc/wrappers.h	(revision 4270)
+++ include/asm-powerpc/wrappers.h	(working copy)
@@ -31,6 +31,9 @@
 
 #define CONFIG_MMU 1
 
+#define wrap_phys_mem_prot(filp,pfn,size,prot)  \
+  __pgprot(pgprot_val(prot) | _PAGE_NO_CACHE | _PAGE_GUARDED)
+
 #define atomic_inc_and_test(v) (atomic_inc_return(v) == 0)
 #define show_stack(p,sp)       print_backtrace(sp)	/* Only works for current. */
 
@@ -51,6 +54,9 @@
 
 #else /*  LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)  */
 
+#define wrap_phys_mem_prot(filp,pfn,size,prot) \
+  phys_mem_access_prot(filp, pfn, size, prot)
+
 #ifdef CONFIG_PPC64
 #define wrap_range_ok(task,addr,size) \
     __access_ok(((__force unsigned long)(addr)),(size),(task->thread.fs))
Index: ksrc/skins/rtdm/drvlib.c
===================================================================
--- ksrc/skins/rtdm/drvlib.c	(revision 4270)
+++ ksrc/skins/rtdm/drvlib.c	(working copy)
@@ -1807,7 +1807,7 @@
 	} else
 #endif /* CONFIG_MMU */
 	if (mmap_data->src_paddr)
-		return xnarch_remap_io_page_range(vma, maddr, paddr,
+	  	return xnarch_remap_io_page_range(filp, vma, maddr, paddr,
 						  size, PAGE_SHARED);
 	else
 		return xnarch_remap_kmem_page_range(vma, maddr, paddr,
Index: ksrc/nucleus/heap.c
===================================================================
--- ksrc/nucleus/heap.c	(revision 4270)
+++ ksrc/nucleus/heap.c	(working copy)
@@ -1053,7 +1053,7 @@
 			vaddr += PAGE_SIZE;
 			size -= PAGE_SIZE;
 		}
-	} else if (xnarch_remap_io_page_range(vma,
+	} else if (xnarch_remap_io_page_range(file,vma,
 					      vma->vm_start,
 					      virt_to_phys((void *)vaddr),
 					      size, PAGE_SHARED))

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[thomas.debes]

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

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

Re: [Xenomai-help] rtdm_iomap_to_user on PPC

[Philippe Gerum]

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.