All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: rpm@xenomai.org
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] rtdm_iomap_to_user on PPC
Date: Sun, 19 Oct 2008 19:56:44 +0200	[thread overview]
Message-ID: <48FB74DC.7090906@domain.hid> (raw)
In-Reply-To: <48FB7465.6040607@domain.hid>

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.


  reply	other threads:[~2008-10-19 17:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-08  9:49 [Xenomai-help] rtdm_iomap_to_user on PPC thomas.debes
2008-10-17  4:46 ` thomas.debes
2008-10-19  0:58   ` Alexis Berlemont
2008-10-19 17:47     ` Gilles Chanteperdrix
2008-10-19 17:54       ` Philippe Gerum
2008-10-19 17:56         ` Gilles Chanteperdrix [this message]
2008-10-19 18:10           ` Philippe Gerum
2008-10-21  6:00             ` thomas.debes
2008-10-21 11:12               ` Philippe Gerum
2008-10-23  5:03                 ` thomas.debes
2008-10-23  9:15                   ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48FB74DC.7090906@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=rpm@xenomai.org \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.