[ANNOUNCE] 3.8.4-rt1

[ANNOUNCE] 3.8.4-rt1

[Thomas Gleixner]

Dear RT Folks,

I'm pleased to announce the 3.8.4-rt1 release.

Again the credit for the heavy lifting goes to Sebastian Siewior, AKA
bigeasy, who took up most of the work to get this out. He's on my
companies engineering team and I hope you trust him as much as I do.

Known issues:

      - SLUB behaves worse than SLAB on ARM
      - SLAB is broken on PowerPC

Still we think that it's time to get out the stuff for broader
testing. It's -rt1 and we need your help to get this stabilized.

The RT patch against 3.8.4 can be found here:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.4-rt1.patch.xz

The split quilt queue is available at:

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patches-3.8.4-rt1.tar.xz

Enjoy,

        tglx

Re: [ANNOUNCE] 3.8.4-rt1

[Luis Claudio R. Goncalves]

On Fri, Mar 22, 2013 at 11:10:11PM +0100, Thomas Gleixner wrote:
| Dear RT Folks,
| 
| I'm pleased to announce the 3.8.4-rt1 release.
| 
| Again the credit for the heavy lifting goes to Sebastian Siewior, AKA
| bigeasy, who took up most of the work to get this out. He's on my
| companies engineering team and I hope you trust him as much as I do.
| 
| Known issues:
| 
|       - SLUB behaves worse than SLAB on ARM
|       - SLAB is broken on PowerPC
| 
| Still we think that it's time to get out the stuff for broader
| testing. It's -rt1 and we need your help to get this stabilized.

Thomas, in order to build 3.8.4-rt1 I had to apply this little chenge:

As struct completion has a raw_spin_lock, we need to use the matching
(raw_*) locking funtions.

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index de45b60..817e60b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -116,9 +116,9 @@ i915_gem_wait_for_error(struct drm_device *dev)
 		 * end up waiting upon a subsequent completion event that
 		 * will never happen.
 		 */
-		spin_lock_irqsave(&x->wait.lock, flags);
+		raw_spin_lock_irqsave(&x->wait.lock, flags);
 		x->done++;
-		spin_unlock_irqrestore(&x->wait.lock, flags);
+		raw_spin_unlock_irqrestore(&x->wait.lock, flags);
 	}
 	return 0;
 }
@@ -949,9 +949,9 @@ i915_gem_check_wedge(struct drm_i915_private *dev_priv,
 		unsigned long flags;
 
 		/* Give the error handler a chance to run. */
-		spin_lock_irqsave(&x->wait.lock, flags);
+		raw_spin_lock_irqsave(&x->wait.lock, flags);
 		recovery_complete = x->done > 0;
-		spin_unlock_irqrestore(&x->wait.lock, flags);
+		raw_spin_unlock_irqrestore(&x->wait.lock, flags);
 
 		/* Non-interruptible callers can't handle -EAGAIN, hence return
 		 * -EIO unconditionally for these. */

-- 
[ Luis Claudio R. Goncalves                    Bass - Gospel - RT ]
[ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9  2696 7203 D980 A448 C8F8 ]

Re: [ANNOUNCE] 3.8.4-rt1

[Luis Claudio R. Goncalves]

On Fri, Mar 22, 2013 at 11:10:11PM +0100, Thomas Gleixner wrote:
| Dear RT Folks,
| 
| I'm pleased to announce the 3.8.4-rt1 release.
| 
| Again the credit for the heavy lifting goes to Sebastian Siewior, AKA
| bigeasy, who took up most of the work to get this out. He's on my
| companies engineering team and I hope you trust him as much as I do.
| 
| Known issues:
| 
|       - SLUB behaves worse than SLAB on ARM
|       - SLAB is broken on PowerPC
| 
| Still we think that it's time to get out the stuff for broader
| testing. It's -rt1 and we need your help to get this stabilized.

I had to put two ugly hacks in place in order to let kernel build progress
a bit further. Even though they are not elegant at all, they can hint a way
to fix the two issues listed below:

fs/fscache/page.c: In function ‘fscache_invalidate_writes’:
fs/fscache/page.c:799:9: error: expected expression before ‘do’

and

drivers/gpu/drm/i915/i915_gem.c: In function ‘mutex_is_locked_by’:
drivers/gpu/drm/i915/i915_gem.c:4370:14: error: ‘struct mutex’ has no member named ‘owner’


diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index de45b60..d2b04fc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4367,7 +4367,11 @@ static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
 		return false;
 
 #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
+#ifdef CONFIG_PREEMPT_RT_FULL
+	return mutex->lock.owner == task;
+#else
 	return mutex->owner == task;
+#endif
 #else
 	/* Since UP may be pre-empted, we cannot assume that we own the lock */
 	return false;
diff --git a/fs/fscache/page.c b/fs/fscache/page.c
index ff000e5..d607a58 100644
--- a/fs/fscache/page.c
+++ b/fs/fscache/page.c
@@ -788,6 +788,12 @@ superseded:
 /*
  * Clear the pages pending writing for invalidation
  */
+
+static inline void lock_cookie(spinlock_t *lock)
+{
+	spin_lock(lock);
+}
+
 void fscache_invalidate_writes(struct fscache_cookie *cookie)
 {
 	struct page *page;
@@ -796,7 +802,7 @@ void fscache_invalidate_writes(struct fscache_cookie *cookie)
 
 	_enter("");
 
-	while (spin_lock(&cookie->stores_lock),
+	while (lock_cookie(&cookie->stores_lock),
 	       n = radix_tree_gang_lookup_tag(&cookie->stores, results, 0,
 					      ARRAY_SIZE(results),
 					      FSCACHE_COOKIE_PENDING_TAG),
-- 
[ Luis Claudio R. Goncalves                    Bass - Gospel - RT ]
[ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9  2696 7203 D980 A448 C8F8 ]

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cpufreq + PREEMPT_RT_FULL give bad context sleeping BUG

[Gregoire Gentil]

Hello,

On OMAP + 3.4 + rt patches with CONFIG_PREEMPT_RT_FULL 
CONFIG_CPU_FREQ_GOV_ONDEMAND, I get a lot of those cpufreq-related bugs:

http://pastebin.com/csy9y3xk

BUG: sleeping function called from invalid context at kernel/rtmutex.c:646
in_atomic(): 1, irqs_disabled(): 128, pid: 1089, name: kworker/0:2
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [< (null)>] (null)
hardirqs last disabled at (0): [<c0043f3c>] copy_process+0x498/0x11c0
softirqs last enabled at (0): [<c0043f3c>] copy_process+0x498/0x11c0
softirqs last disabled at (0): [< (null)>] (null)
(unwind_backtrace+0x0/0xf0) from (dump_stack+0x20/0x24)
(dump_stack+0x20/0x24) from (__might_sleep+0x124/0x144)
(__might_sleep+0x124/0x144) from (rt_spin_lock+0x30/0x64)
(rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)
(clk_get_rate+0x30/0x54) from (twd_update_frequency+0x20/0x58)
(twd_update_frequency+0x20/0x58) from (smp_call_function_single+0xd0/0x1c4)
(smp_call_function_single+0xd0/0x1c4) from 
(twd_cpufreq_transition+0x34/0x40)
(twd_cpufreq_transition+0x34/0x40) from (notifier_call_chain+0x48/0x78)
(notifier_call_chain+0x48/0x78) from (__srcu_notifier_call_chain+0x80/0xb8)
(__srcu_notifier_call_chain+0x80/0xb8) from 
(srcu_notifier_call_chain+0x28/0x30)
(srcu_notifier_call_chain+0x28/0x30) from 
(cpufreq_notify_transition+0x1c8/0x200)
(cpufreq_notify_transition+0x1c8/0x200) from (omap_cpufreq_scale+0xec/0x12c)
(omap_cpufreq_scale+0xec/0x12c) from (omap_target+0x8c/0xb4)
(omap_target+0x8c/0xb4) from (__cpufreq_driver_target+0x74/0x8c)
(__cpufreq_driver_target+0x74/0x8c) from (do_dbs_timer+0x39c/0x454)
(do_dbs_timer+0x39c/0x454) from (process_one_work+0x2ec/0x50c)
(process_one_work+0x2ec/0x50c) from (worker_thread+0x1c4/0x2c8)
(worker_thread+0x1c4/0x2c8) from (kthread+0x98/0xa4)
(kthread+0x98/0xa4) from (kernel_thread_exit+0x0/0x8)

Any idea what I should do to fix this problem?

Grégoire

PS: Here is some related code:

http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=arch/arm/mach-omap2/omap2plus-cpufreq.c;h=c60eb61a60fb524ac9eb3a4bcbb13bfa9d96e76f;hb=3e1c9f139425663ceee48f92e8d3f23158580334

http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=arch/arm/plat-omap/clock.c;h=8c0e8fe2c5c51673e41e4304194d922dbfaedf38;hb=3e1c9f139425663ceee48f92e8d3f23158580334

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] 3.8.4-rt1

[Sebastian Andrzej Siewior]

* Luis Claudio R. Goncalves | 2013-03-22 22:30:03 [-0300]:

What about this:

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index de45b60..9b51712 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -91,7 +91,6 @@ i915_gem_wait_for_error(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct completion *x = &dev_priv->error_completion;
-	unsigned long flags;
 	int ret;
 
 	if (!atomic_read(&dev_priv->mm.wedged))
@@ -116,9 +115,7 @@ i915_gem_wait_for_error(struct drm_device *dev)
 		 * end up waiting upon a subsequent completion event that
 		 * will never happen.
 		 */
-		spin_lock_irqsave(&x->wait.lock, flags);
-		x->done++;
-		spin_unlock_irqrestore(&x->wait.lock, flags);
+		complete(x);
 	}
 	return 0;
 }
@@ -946,12 +943,9 @@ i915_gem_check_wedge(struct drm_i915_private *dev_priv,
 	if (atomic_read(&dev_priv->mm.wedged)) {
 		struct completion *x = &dev_priv->error_completion;
 		bool recovery_complete;
-		unsigned long flags;
 
 		/* Give the error handler a chance to run. */
-		spin_lock_irqsave(&x->wait.lock, flags);
-		recovery_complete = x->done > 0;
-		spin_unlock_irqrestore(&x->wait.lock, flags);
+		recovery_complete = completion_done(x);
 
 		/* Non-interruptible callers can't handle -EAGAIN, hence return
 		 * -EIO unconditionally for these. */
@@ -4366,7 +4360,7 @@ static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
 	if (!mutex_is_locked(mutex))
 		return false;
 
-#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
+#if (defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)) && !defined(CONFIG_PREEMPT_RT_BASE)
 	return mutex->owner == task;
 #else
 	/* Since UP may be pre-empted, we cannot assume that we own the lock */


I'm not very happy with the complete() here, I am not sure what kind of
problem they try to solve here…

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] 3.8.4-rt1

[Luis Claudio R. Goncalves]

On Sat, Mar 23, 2013 at 07:38:27PM +0100, Sebastian Andrzej Siewior wrote:
| * Luis Claudio R. Goncalves | 2013-03-22 22:30:03 [-0300]:
| 
| What about this:
| 
| diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
| index de45b60..9b51712 100644
| --- a/drivers/gpu/drm/i915/i915_gem.c
| +++ b/drivers/gpu/drm/i915/i915_gem.c
| @@ -91,7 +91,6 @@ i915_gem_wait_for_error(struct drm_device *dev)
|  {
|  	struct drm_i915_private *dev_priv = dev->dev_private;
|  	struct completion *x = &dev_priv->error_completion;
| -	unsigned long flags;
|  	int ret;
|  
|  	if (!atomic_read(&dev_priv->mm.wedged))
| @@ -116,9 +115,7 @@ i915_gem_wait_for_error(struct drm_device *dev)
|  		 * end up waiting upon a subsequent completion event that
|  		 * will never happen.
|  		 */
| -		spin_lock_irqsave(&x->wait.lock, flags);
| -		x->done++;
| -		spin_unlock_irqrestore(&x->wait.lock, flags);
| +		complete(x);
|  	}
|  	return 0;
|  }
| @@ -946,12 +943,9 @@ i915_gem_check_wedge(struct drm_i915_private *dev_priv,
|  	if (atomic_read(&dev_priv->mm.wedged)) {
|  		struct completion *x = &dev_priv->error_completion;
|  		bool recovery_complete;
| -		unsigned long flags;
|  
|  		/* Give the error handler a chance to run. */
| -		spin_lock_irqsave(&x->wait.lock, flags);
| -		recovery_complete = x->done > 0;
| -		spin_unlock_irqrestore(&x->wait.lock, flags);
| +		recovery_complete = completion_done(x);
|  
|  		/* Non-interruptible callers can't handle -EAGAIN, hence return
|  		 * -EIO unconditionally for these. */

Good catch. The resulting code is cleaner. I took the simplest approach while
trying to fix the issue, but your solution is more elegant.

| @@ -4366,7 +4360,7 @@ static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
|  	if (!mutex_is_locked(mutex))
|  		return false;
|  
| -#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)
| +#if (defined(CONFIG_SMP) || defined(CONFIG_DEBUG_MUTEXES)) && !defined(CONFIG_PREEMPT_RT_BASE)
|  	return mutex->owner == task;
|  #else
|  	/* Since UP may be pre-empted, we cannot assume that we own the lock */

I was trying to keep the behavior of CONFIG_DEBUG_MUTEXES, but we do have
the RT counterpart, CONFIG_DEBUG_RT_MUTEXES. So, yours is probably the
right one.

| I'm not very happy with the complete() here, I am not sure what kind of
| problem they try to solve here…

I was looking at the code and IMHO it seems to fit there perfectly.

Cheers,
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cpufreq + PREEMPT_RT_FULL give bad context sleeping BUG

[Sebastian Andrzej Siewior]

* Gregoire Gentil | 2013-03-23 10:17:51 [-0700]:

>Hello,
Hi,

>On OMAP + 3.4 + rt patches with CONFIG_PREEMPT_RT_FULL
>CONFIG_CPU_FREQ_GOV_ONDEMAND, I get a lot of those cpufreq-related
>bugs:
>
>http://pastebin.com/csy9y3xk
>
>BUG: sleeping function called from invalid context at kernel/rtmutex.c:646
>(__might_sleep+0x124/0x144) from (rt_spin_lock+0x30/0x64)
>(rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)
>(clk_get_rate+0x30/0x54) from (twd_update_frequency+0x20/0x58)

Here it tries to grab a mutex

>(twd_update_frequency+0x20/0x58) from (smp_call_function_single+0xd0/0x1c4)
>(smp_call_function_single+0xd0/0x1c4) from

Here it calls a smp functions which runs with interupts off.

>(twd_cpufreq_transition+0x34/0x40)

that means it should trigger on mainline as well.

>Any idea what I should do to fix this problem?

This has been introduced in 4fd7f9b12 ("ARM: 7212/1: smp_twd: reconfigure
clockevents after cpufreq change"). I think that omap got later
converted to the generic clk framework which uses now the mutex. Could
somebody please look at this?

>Grégoire

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cpufreq + PREEMPT_RT_FULL give bad context sleeping BUG

[Thomas Gleixner]

On Tue, 26 Mar 2013, Sebastian Andrzej Siewior wrote:

> * Gregoire Gentil | 2013-03-23 10:17:51 [-0700]:
> 
> >Hello,
> Hi,
> 
> >On OMAP + 3.4 + rt patches with CONFIG_PREEMPT_RT_FULL
> >CONFIG_CPU_FREQ_GOV_ONDEMAND, I get a lot of those cpufreq-related
> >bugs:
> >
> >http://pastebin.com/csy9y3xk
> >
> >BUG: sleeping function called from invalid context at kernel/rtmutex.c:646
> >(__might_sleep+0x124/0x144) from (rt_spin_lock+0x30/0x64)
> >(rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)
> >(clk_get_rate+0x30/0x54) from (twd_update_frequency+0x20/0x58)
> 
> Here it tries to grab a mutex
> 
> >(twd_update_frequency+0x20/0x58) from (smp_call_function_single+0xd0/0x1c4)
> >(smp_call_function_single+0xd0/0x1c4) from
> 
> Here it calls a smp functions which runs with interupts off.
> 
> >(twd_cpufreq_transition+0x34/0x40)
> 
> that means it should trigger on mainline as well.

No. It won't. Mainline uses a spinlock which gets converted to a
sleeping spinlock on rt.

  (rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)
 
> >Any idea what I should do to fix this problem?

One possibility would be to convert the clk->spinlock to a raw
spinlock, but you have to audit the code which implications this has
latency wise. In theory the code under the spinlock should not do
anything time consuming, so it should be fine. If it does something
time consuming, we better fix that anyway.

Thanks,

	tglx

 

Re: cpufreq + PREEMPT_RT_FULL give bad context sleeping BUG

[Sebastian Andrzej Siewior]

* Thomas Gleixner | 2013-03-26 22:07:45 [+0100]:

>> that means it should trigger on mainline as well.
>
>No. It won't. Mainline uses a spinlock which gets converted to a
>sleeping spinlock on rt.
>
>  (rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)

This is true but this spinlock in only available in the OOT code
Gregoire Gentil pointed out ([0]). In mainline we have a mutex in
drivers/clk/clk.c and this is what my omap4 blaze is using.

[0] http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=arch/arm/plat-omap/clock.c;h=8c0e8fe2c5c51673e41e4304194d922dbfaedf38;hb=3e1c9f139425663ceee48f92e8d3f23158580334

>Thanks,
>
>	tglx

Sebastian

Re: cpufreq + PREEMPT_RT_FULL give bad context sleeping BUG

[Thomas Gleixner]

On Tue, 26 Mar 2013, Sebastian Andrzej Siewior wrote:

> * Thomas Gleixner | 2013-03-26 22:07:45 [+0100]:
> 
> >> that means it should trigger on mainline as well.
> >
> >No. It won't. Mainline uses a spinlock which gets converted to a
> >sleeping spinlock on rt.
> >
> >  (rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)
> 
> This is true but this spinlock in only available in the OOT code
> Gregoire Gentil pointed out ([0]). In mainline we have a mutex in
> drivers/clk/clk.c and this is what my omap4 blaze is using.
> 
> [0] http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=arch/arm/plat-omap/clock.c;h=8c0e8fe2c5c51673e41e4304194d922dbfaedf38;hb=3e1c9f139425663ceee48f92e8d3f23158580334

Yeah, it's that way in mainline as well. I did not look at the source,
I just looked at the backtrace.

So either way, this needs to be resolved :)

Thanks,

	tglx

Re: cpufreq + PREEMPT_RT_FULL give bad context sleeping BUG

[Thomas Gleixner]

On Tue, 26 Mar 2013, Thomas Gleixner wrote:

> On Tue, 26 Mar 2013, Sebastian Andrzej Siewior wrote:
> 
> > * Thomas Gleixner | 2013-03-26 22:07:45 [+0100]:
> > 
> > >> that means it should trigger on mainline as well.
> > >
> > >No. It won't. Mainline uses a spinlock which gets converted to a
> > >sleeping spinlock on rt.
> > >
> > >  (rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)
> > 
> > This is true but this spinlock in only available in the OOT code
> > Gregoire Gentil pointed out ([0]). In mainline we have a mutex in
> > drivers/clk/clk.c and this is what my omap4 blaze is using.
> > 
> > [0] http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=arch/arm/plat-omap/clock.c;h=8c0e8fe2c5c51673e41e4304194d922dbfaedf38;hb=3e1c9f139425663ceee48f92e8d3f23158580334
> 
> Yeah, it's that way in mainline as well.

I meant, that the mutex is taken. So yes, this will cause a warning in
!RT too.

Re: cpufreq + PREEMPT_RT_FULL give bad context sleeping BUG

[Gregoire Gentil]

On 03/26/2013 02:44 PM, Thomas Gleixner wrote:
> On Tue, 26 Mar 2013, Thomas Gleixner wrote:
>
>> On Tue, 26 Mar 2013, Sebastian Andrzej Siewior wrote:
>>
>>> * Thomas Gleixner | 2013-03-26 22:07:45 [+0100]:
>>>
>>>>> that means it should trigger on mainline as well.
>>>>
>>>> No. It won't. Mainline uses a spinlock which gets converted to a
>>>> sleeping spinlock on rt.
>>>>
>>>>   (rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)
>>>
>>> This is true but this spinlock in only available in the OOT code
>>> Gregoire Gentil pointed out ([0]). In mainline we have a mutex in
>>> drivers/clk/clk.c and this is what my omap4 blaze is using.
>>>
>>> [0] http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=arch/arm/plat-omap/clock.c;h=8c0e8fe2c5c51673e41e4304194d922dbfaedf38;hb=3e1c9f139425663ceee48f92e8d3f23158580334
>>
>> Yeah, it's that way in mainline as well.
>
> I meant, that the mutex is taken. So yes, this will cause a warning in
> !RT too.
Hello,

So what could be a tentative solution? Could you advise what I could try?

Many thanks in advance,

Grégoire

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cpufreq + PREEMPT_RT_FULL give bad context sleeping BUG

[Sebastian Andrzej Siewior]

* Gregoire Gentil | 2013-03-27 08:23:16 [-0700]:

>>>>[0] http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=arch/arm/plat-omap/clock.c;h=8c0e8fe2c5c51673e41e4304194d922dbfaedf38;hb=3e1c9f139425663ceee48f92e8d3f23158580334
>>>
>>>Yeah, it's that way in mainline as well.
>>
>>I meant, that the mutex is taken. So yes, this will cause a warning in
>>!RT too.
>Hello,
>
>So what could be a tentative solution? Could you advise what I could try?

The easy way would be to get the clockfw_lock lock changed into a
raw_spinlock_t and fix clk_get_rate() and others. If the lock is taken
for a long time it will increase you latency.
You try to check if it is possible to defer twd_update_frequency() to a
workqueue and execute it later and not directly from the interrupt.

On the other hand you might want simply disable cpufreq. If you have a
certain latency and the cpu frequency goes down because the system is
idle then you latency will increase. Basicaly an idle machine will worse
latency than a busy one. You probably don't want this.

>
>Many thanks in advance,
>
>Grégoire

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html