SV: Question about using device driver with RTAI/LXRT

[Per-Arne Söderkvist]

Thanks for the answer,

I have tried the proposed solution and it works, i.e. the program don't hang
up any more;)


Question: What's the difference between this solution, see below:

1. mlockall(MCL_CURRENT)
2. mmap() the PCI space
3. mlockall(MCL_FUTURE)

compared to "mlockall(MCL_CURRENT | MCL_FUTURE);" , i.e. the reason why it
works now?



Thanks again for all answers,

Per-Arne Söderkvist

----------------------------------------------------------------------------
--
Per-Arne Söderkvist wrote:
> Hello!
>
> With the line "mlockall(MCL_CURRENT | MCL_FUTURE);" commented away, works
> the modified LXRT-program when I read/write to the "PCI-memory"
(reflective
> memory), works both with own driver with /dev/vmic0 and direct mapping
> against /dev/mem.
>
> I found that is an old problem (threads with "mlockall and mmap of IO
> devices don't mix", see below:
> "the use of mlockall(2) in a process that has mmap(2)ed the registers of
an
> IO device will hang that process uninterruptibly. "
>
> See thread/link below for more information:
>
http://groups.google.se/group/fa.linux.kernel/browse_thread/thread/46154bebe
>
b608da/4a9ba1e874d58783?lnk=st&q=mlockall+and+mmap+of+IO+devices+don%27t+mix
> &rnum=1&hl=sv#4a9ba1e874d58783).
>
> This thread talks about a "There's an utterly ancient patch in -mm which
> might fix this.", see below:
>
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-m
> m4/broken-out/get_user_pages-handle-VM_IO.patch
>
> Note: I'm using kernel 2.6.9 and RTAI 3.2
>
>
> QUESTIONS:
>
> Q1: Is there any new patch/solution for this problem or should I use this
> old solution?
>

If the following is an option implementation-wise, you should be able to
work around this issue by splitting the mlockall request in two parts:

1. mlockall(MCL_CURRENT)
2. mmap() the PCI space
3. mlockall(MCL_FUTURE)

...

--

Philippe.