Hi,
We had the problem that one of our threads, which we initially assigned
priority 29, ended up having priority 89.
I know that PI is the reason why the priority of the thread was first bumped up
to 89 and then to 90 because
two higher priority threads started blocking on two different mutexes
> We had the problem that one of our threads, which we initially assigned
> priority 29, ended up having priority 89.
> I know that PI is the reason why the priority of the thread was first bumped
> up to 89 and then to 90 because
> two higher priority threads started blocking on two different mu
On Wed, 2009-11-18 at 09:46 -0500, Andreas Glatz wrote:
> Hi,
>
> We had the problem that one of our threads, which we initially assigned
> priority 29, ended up having priority 89.
> I know that PI is the reason why the priority of the thread was first bumped
> up to 89 and then to 90 because
>
Jan,
>I think we can change rtdm_iomap_to_user to take src_addr as
>phys_addr_t
>and propagate this internally properly. We also need to add a wrapper
>for phys_addr_t for kernels that doesn't support this (<2.6.28). To my
>current understanding, this should be sufficient, right?
>
This is a dif
Herrera-Bendezu, Luis wrote:
> Jan,
>
>> I think we can change rtdm_iomap_to_user to take src_addr as
>> phys_addr_t
>> and propagate this internally properly. We also need to add a wrapper
>> for phys_addr_t for kernels that doesn't support this (<2.6.28). To my
>> current understanding, this sh
