Don't reference non-standard realtime group

Don't reference non-standard realtime group

[Uwe Kleine-König]

There is no dedicated realtime group in most distributions. So make the
error message a bit more understandable for people not running Redhat
MRG.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Closes: http://bugs.debian.org/619938
---
 src/lib/rt-utils.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/src/lib/rt-utils.c
+++ b/src/lib/rt-utils.c
@@ -72,7 +72,8 @@
 	param.sched_priority = 1;
 	if (sched_setscheduler(0, SCHED_FIFO, &param)) {
 		fprintf(stderr, "Unable to change scheduling policy!\n");
-		fprintf(stderr, "either run as root or join realtime group\n");
+		fprintf(stderr, "Probably missing capabilities, either run as "
+				"root or increase RLIMIT_RTPRIO limits.\n");
 		return 1;
 	}
 
--
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: Don't reference non-standard realtime group

[Uwe Kleine-König]

On Wed, Jul 13, 2011 at 10:48:31PM +0200, Uwe Kleine-König wrote:
> There is no dedicated realtime group in most distributions. So make the
> error message a bit more understandable for people not running Redhat
> MRG.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Closes: http://bugs.debian.org/619938
ping?!

> ---
>  src/lib/rt-utils.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- a/src/lib/rt-utils.c
> +++ b/src/lib/rt-utils.c
> @@ -72,7 +72,8 @@
>  	param.sched_priority = 1;
>  	if (sched_setscheduler(0, SCHED_FIFO, &param)) {
>  		fprintf(stderr, "Unable to change scheduling policy!\n");
> -		fprintf(stderr, "either run as root or join realtime group\n");
> +		fprintf(stderr, "Probably missing capabilities, either run as "
> +				"root or increase RLIMIT_RTPRIO limits.\n");
>  		return 1;
>  	}

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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

"g_serial: fix deadlock with PREEMPT_RT enabled" still not integrated

[Gregoire Gentil]

Hello,

I think that the g_serial patch is still not integrated and it's still 
needed at least as I experienced it on 3.4-rt17 on ARM:
http://www.spinics.net/lists/linux-rt-users/msg07158.html

Here is an update of the patch:

--- a/drivers/usb/gadget/u_serial.c	2012-08-29 12:17:48.607922510 -0700
+++ b/drivers/usb/gadget/u_serial.c	2012-08-29 12:23:21.305572267 -0700
@@ -554,7 +554,15 @@
  	 * a workqueue, so we won't get callbacks and can hold port_lock
  	 */
  	if (tty && do_push)
-		tty_flip_buffer_push(tty);
+		/*
+		* Drop the lock here since it might end up calling
+		* gs_flush_chars, which takes the lock.
+		*/
+		spin_unlock_irq(&port->port_lock);
+ 		tty_flip_buffer_push(tty);
+		spin_lock_irq(&port->port_lock);
+		/* tty may have been closed */
+		tty = port->port_tty;


  	/* We want our data queue to become empty ASAP, keeping data


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

TI wl1271 wireless bug with 3.4-rt17

[Gregoire Gentil]

Hello,

I'm trying to debug a wifi bug with 3.4-rt17 applied, running on an 
OMAP4 ARM board such as Pandaboard.

Wi-Fi works perfectly well without rt patches. It also works quite well 
with rt patches AND without wifi module loaded. But with both rt patches 
and wifi module, the system is very flaky and even if I manage to launch 
a big download, I get a kernel hang. I managed to get a trace:

BUG: scheduling while atomic: irq/213-wl12xx/1588/0x00010002
Modules linked in: omapdce(C) wl12xx wlcore omaprpc(C) mac80211 d
[<c001beb4>] (unwind_backtrace+0x0/0xf0) from [<c0613548>] (dump)
[<c0613548>] (dump_stack+0x20/0x24) from [<c0073908>] (__schedul)
[<c0073908>] (__schedule_bug+0x54/0x60) from [<c0614818>] (__sch)
[<c0614818>] (__schedule+0x74/0x6c0) from [<c0614f60>] (schedule)
[<c0614f60>] (schedule+0xa0/0xb8) from [<c0615eb8>] (rt_spin_loc)
[<c0615eb8>] (rt_spin_lock_slowlock+0x198/0x288) from [<c06160a8)
[<c06160a8>] (rt_spin_lock+0x18/0x1c) from [<bf0c6b24>] (wl12xx_)
[<bf0c6b24>] (wl12xx_hardirq+0x2c/0xa4 [wlcore]) from [<c00bd4f0)
[<c00bd4f0>] (handle_irq_event_percpu+0xac/0x24c) from [<c00bd70)
[<c00bd70c>] (handle_irq_event+0x7c/0x9c) from [<c00c08f0>] (han)
[<c00c08f0>] (handle_level_irq+0xe4/0x134) from [<c00bcf58>] (ge)
[<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c03217e8>] (g)
[<c03217e8>] (gpio_irq_handler+0x160/0x1a4) from [<c00bcf58>] (g)
[<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c001449c>] (h)
[<c001449c>] (handle_IRQ+0x88/0xc8)

Source code including the function wl12xx_hardirq is here:
http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=drivers/net/wireless/ti/wlcore/main.c;h=45fe911a6504f92dddff5a9415bb77a643b3c4a9;hb=f84c72f6b36418ff11d16808c16a7c3216730bb0

Any idea what could be wrong and how I could debug and fix this situation?

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: TI wl1271 wireless bug with 3.4-rt17

[Josh Cartwright]

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

On Sun, Sep 02, 2012 at 11:24:47PM -0700, Gregoire Gentil wrote:
> Hello,
> 
> I'm trying to debug a wifi bug with 3.4-rt17 applied, running on an
> OMAP4 ARM board such as Pandaboard.
> 
> Wi-Fi works perfectly well without rt patches. It also works quite
> well with rt patches AND without wifi module loaded. But with both
> rt patches and wifi module, the system is very flaky and even if I
> manage to launch a big download, I get a kernel hang. I managed to
> get a trace:
> 
> BUG: scheduling while atomic: irq/213-wl12xx/1588/0x00010002
> Modules linked in: omapdce(C) wl12xx wlcore omaprpc(C) mac80211 d
> [<c001beb4>] (unwind_backtrace+0x0/0xf0) from [<c0613548>] (dump)
> [<c0613548>] (dump_stack+0x20/0x24) from [<c0073908>] (__schedul)
> [<c0073908>] (__schedule_bug+0x54/0x60) from [<c0614818>] (__sch)
> [<c0614818>] (__schedule+0x74/0x6c0) from [<c0614f60>] (schedule)
> [<c0614f60>] (schedule+0xa0/0xb8) from [<c0615eb8>] (rt_spin_loc)
> [<c0615eb8>] (rt_spin_lock_slowlock+0x198/0x288) from [<c06160a8)
> [<c06160a8>] (rt_spin_lock+0x18/0x1c) from [<bf0c6b24>] (wl12xx_)
> [<bf0c6b24>] (wl12xx_hardirq+0x2c/0xa4 [wlcore]) from [<c00bd4f0)
> [<c00bd4f0>] (handle_irq_event_percpu+0xac/0x24c) from [<c00bd70)
> [<c00bd70c>] (handle_irq_event+0x7c/0x9c) from [<c00c08f0>] (han)
> [<c00c08f0>] (handle_level_irq+0xe4/0x134) from [<c00bcf58>] (ge)
> [<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c03217e8>] (g)
> [<c03217e8>] (gpio_irq_handler+0x160/0x1a4) from [<c00bcf58>] (g)
> [<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c001449c>] (h)
> [<c001449c>] (handle_IRQ+0x88/0xc8)
> 
> Source code including the function wl12xx_hardirq is here:
> http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=drivers/net/wireless/ti/wlcore/main.c;h=45fe911a6504f92dddff5a9415bb77a643b3c4a9;hb=f84c72f6b36418ff11d16808c16a7c3216730bb0
> 
> Any idea what could be wrong and how I could debug and fix this situation?

On first glance, it looks like the driver uses request_threaded_irq(),
to register its handlers, but is trying to acquire a regular spin_lock
in its primary handler.  That's bad news, since spin_locks' can
schedule() when contended with CONFIG_PREEMPT_RT.

And it's not just that, unfortunately, since the primary handler also
complete()s a completion, which also can schedule().

It looks like the overall interrupt handling strategy of this driver
probably needs to be revisited. :(.

-- 
          joshc

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: TI wl1271 wireless bug with 3.4-rt17

[Gregoire Gentil]

On 09/04/2012 07:11 AM, Josh Cartwright wrote:
> On Sun, Sep 02, 2012 at 11:24:47PM -0700, Gregoire Gentil wrote:
>> Hello,
>>
>> I'm trying to debug a wifi bug with 3.4-rt17 applied, running on an
>> OMAP4 ARM board such as Pandaboard.
>>
>> Wi-Fi works perfectly well without rt patches. It also works quite
>> well with rt patches AND without wifi module loaded. But with both
>> rt patches and wifi module, the system is very flaky and even if I
>> manage to launch a big download, I get a kernel hang. I managed to
>> get a trace:
>>
>> BUG: scheduling while atomic: irq/213-wl12xx/1588/0x00010002
>> Modules linked in: omapdce(C) wl12xx wlcore omaprpc(C) mac80211 d
>> [<c001beb4>] (unwind_backtrace+0x0/0xf0) from [<c0613548>] (dump)
>> [<c0613548>] (dump_stack+0x20/0x24) from [<c0073908>] (__schedul)
>> [<c0073908>] (__schedule_bug+0x54/0x60) from [<c0614818>] (__sch)
>> [<c0614818>] (__schedule+0x74/0x6c0) from [<c0614f60>] (schedule)
>> [<c0614f60>] (schedule+0xa0/0xb8) from [<c0615eb8>] (rt_spin_loc)
>> [<c0615eb8>] (rt_spin_lock_slowlock+0x198/0x288) from [<c06160a8)
>> [<c06160a8>] (rt_spin_lock+0x18/0x1c) from [<bf0c6b24>] (wl12xx_)
>> [<bf0c6b24>] (wl12xx_hardirq+0x2c/0xa4 [wlcore]) from [<c00bd4f0)
>> [<c00bd4f0>] (handle_irq_event_percpu+0xac/0x24c) from [<c00bd70)
>> [<c00bd70c>] (handle_irq_event+0x7c/0x9c) from [<c00c08f0>] (han)
>> [<c00c08f0>] (handle_level_irq+0xe4/0x134) from [<c00bcf58>] (ge)
>> [<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c03217e8>] (g)
>> [<c03217e8>] (gpio_irq_handler+0x160/0x1a4) from [<c00bcf58>] (g)
>> [<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c001449c>] (h)
>> [<c001449c>] (handle_IRQ+0x88/0xc8)
>>
>> Source code including the function wl12xx_hardirq is here:
>> http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=drivers/net/wireless/ti/wlcore/main.c;h=45fe911a6504f92dddff5a9415bb77a643b3c4a9;hb=f84c72f6b36418ff11d16808c16a7c3216730bb0
>>
>> Any idea what could be wrong and how I could debug and fix this situation?
>
> On first glance, it looks like the driver uses request_threaded_irq(),
> to register its handlers, but is trying to acquire a regular spin_lock
> in its primary handler.  That's bad news, since spin_locks' can
> schedule() when contended with CONFIG_PREEMPT_RT.
>
> And it's not just that, unfortunately, since the primary handler also
> complete()s a completion, which also can schedule().
>
> It looks like the overall interrupt handling strategy of this driver
> probably needs to be revisited. :(.

Josh,

I really appreciate the answer. Thank you. Though I'm definitely not a 
RT expert, I really would like to make this work... Could you provide a 
little bit more guideline what I should patch to fix this situation? 
Could I change request_threaded_irq to something else? Would raw_spin* help?

Many thanks in advance for any explanation,

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: TI wl1271 wireless bug with 3.4-rt17

[Josh Cartwright]

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

CC'd Luciano to let him know about breakage of wl12xx on -rt.

On Tue, Sep 04, 2012 at 06:22:33PM -0700, Gregoire Gentil wrote:
> On 09/04/2012 07:11 AM, Josh Cartwright wrote:
> >On Sun, Sep 02, 2012 at 11:24:47PM -0700, Gregoire Gentil wrote:
> >>Hello,
> >>
> >>I'm trying to debug a wifi bug with 3.4-rt17 applied, running on an
> >>OMAP4 ARM board such as Pandaboard.
> >>
> >>Wi-Fi works perfectly well without rt patches. It also works quite
> >>well with rt patches AND without wifi module loaded. But with both
> >>rt patches and wifi module, the system is very flaky and even if I
> >>manage to launch a big download, I get a kernel hang. I managed to
> >>get a trace:
> >>
> >>BUG: scheduling while atomic: irq/213-wl12xx/1588/0x00010002
> >>Modules linked in: omapdce(C) wl12xx wlcore omaprpc(C) mac80211 d
> >>[<c001beb4>] (unwind_backtrace+0x0/0xf0) from [<c0613548>] (dump)
> >>[<c0613548>] (dump_stack+0x20/0x24) from [<c0073908>] (__schedul)
> >>[<c0073908>] (__schedule_bug+0x54/0x60) from [<c0614818>] (__sch)
> >>[<c0614818>] (__schedule+0x74/0x6c0) from [<c0614f60>] (schedule)
> >>[<c0614f60>] (schedule+0xa0/0xb8) from [<c0615eb8>] (rt_spin_loc)
> >>[<c0615eb8>] (rt_spin_lock_slowlock+0x198/0x288) from [<c06160a8)
> >>[<c06160a8>] (rt_spin_lock+0x18/0x1c) from [<bf0c6b24>] (wl12xx_)
> >>[<bf0c6b24>] (wl12xx_hardirq+0x2c/0xa4 [wlcore]) from [<c00bd4f0)
> >>[<c00bd4f0>] (handle_irq_event_percpu+0xac/0x24c) from [<c00bd70)
> >>[<c00bd70c>] (handle_irq_event+0x7c/0x9c) from [<c00c08f0>] (han)
> >>[<c00c08f0>] (handle_level_irq+0xe4/0x134) from [<c00bcf58>] (ge)
> >>[<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c03217e8>] (g)
> >>[<c03217e8>] (gpio_irq_handler+0x160/0x1a4) from [<c00bcf58>] (g)
> >>[<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c001449c>] (h)
> >>[<c001449c>] (handle_IRQ+0x88/0xc8)
> >>
> >>Source code including the function wl12xx_hardirq is here:
> >>http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=drivers/net/wireless/ti/wlcore/main.c;h=45fe911a6504f92dddff5a9415bb77a643b3c4a9;hb=f84c72f6b36418ff11d16808c16a7c3216730bb0
> >>
> >>Any idea what could be wrong and how I could debug and fix this situation?
> >
> >On first glance, it looks like the driver uses request_threaded_irq(),
> >to register its handlers, but is trying to acquire a regular spin_lock
> >in its primary handler.  That's bad news, since spin_locks' can
> >schedule() when contended with CONFIG_PREEMPT_RT.
> >
> >And it's not just that, unfortunately, since the primary handler also
> >complete()s a completion, which also can schedule().
> >
> >It looks like the overall interrupt handling strategy of this driver
> >probably needs to be revisited. :(.
> 
> Josh,
> 
> I really appreciate the answer. Thank you. Though I'm definitely not
> a RT expert, I really would like to make this work... Could you
> provide a little bit more guideline what I should patch to fix this
> situation? Could I change request_threaded_irq to something else?
> Would raw_spin* help?

In general, the hardirq handler should be doing the absolute bare
minimum necessary to determine whether or not the device is interrupting
(and if so, quiet it down and return IRQ_WAKE_THREAD), since
longer-running handlers have detrimental impact to the system
determinism.

The right solution for wl12xx seems to be pushing the logic currently
implemented in the hardirq handler into the threaded handler, but
without knowing too many details about the driver, its difficult to
judge the viability/impact of this solution.

Also, unfortunately, it looks like this driver isn't the only one acquiring
non-raw_spinlocks or complete()ing in their hardirq handler registered
with request_threaded_irq().  My grepping shows that the following
drivers will also break in similar ways with -rt.

   drivers/dma/sh/shdma-base.c
   drivers/media/video/via-camera.c
   drivers/mfd/db8500-prcmu.c
   drivers/misc/lis3lv02d/lis3lv02d.c
   drivers/mmc/host/jz4740_mmc.c
   drivers/mmc/host/sh_mmcif.c
   drivers/net/wireless/b43/main.c
   drivers/virt/fsl_hypervisor.c
   virt/kvm/assigned-dev.c

Potentially IIO as well, but my eyes started to glaze over reading the
iio interrupt handling code :\.

      joshc

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: TI wl1271 wireless bug with 3.4-rt17

[Gregoire Gentil]

On 09/05/2012 08:48 PM, Josh Cartwright wrote:
> CC'd Luciano to let him know about breakage of wl12xx on -rt.
>
> On Tue, Sep 04, 2012 at 06:22:33PM -0700, Gregoire Gentil wrote:
>> On 09/04/2012 07:11 AM, Josh Cartwright wrote:
>>> On Sun, Sep 02, 2012 at 11:24:47PM -0700, Gregoire Gentil wrote:
>>>> Hello,
>>>>
>>>> I'm trying to debug a wifi bug with 3.4-rt17 applied, running on an
>>>> OMAP4 ARM board such as Pandaboard.
>>>>
>>>> Wi-Fi works perfectly well without rt patches. It also works quite
>>>> well with rt patches AND without wifi module loaded. But with both
>>>> rt patches and wifi module, the system is very flaky and even if I
>>>> manage to launch a big download, I get a kernel hang. I managed to
>>>> get a trace:
>>>>
>>>> BUG: scheduling while atomic: irq/213-wl12xx/1588/0x00010002
>>>> Modules linked in: omapdce(C) wl12xx wlcore omaprpc(C) mac80211 d
>>>> [<c001beb4>] (unwind_backtrace+0x0/0xf0) from [<c0613548>] (dump)
>>>> [<c0613548>] (dump_stack+0x20/0x24) from [<c0073908>] (__schedul)
>>>> [<c0073908>] (__schedule_bug+0x54/0x60) from [<c0614818>] (__sch)
>>>> [<c0614818>] (__schedule+0x74/0x6c0) from [<c0614f60>] (schedule)
>>>> [<c0614f60>] (schedule+0xa0/0xb8) from [<c0615eb8>] (rt_spin_loc)
>>>> [<c0615eb8>] (rt_spin_lock_slowlock+0x198/0x288) from [<c06160a8)
>>>> [<c06160a8>] (rt_spin_lock+0x18/0x1c) from [<bf0c6b24>] (wl12xx_)
>>>> [<bf0c6b24>] (wl12xx_hardirq+0x2c/0xa4 [wlcore]) from [<c00bd4f0)
>>>> [<c00bd4f0>] (handle_irq_event_percpu+0xac/0x24c) from [<c00bd70)
>>>> [<c00bd70c>] (handle_irq_event+0x7c/0x9c) from [<c00c08f0>] (han)
>>>> [<c00c08f0>] (handle_level_irq+0xe4/0x134) from [<c00bcf58>] (ge)
>>>> [<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c03217e8>] (g)
>>>> [<c03217e8>] (gpio_irq_handler+0x160/0x1a4) from [<c00bcf58>] (g)
>>>> [<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c001449c>] (h)
>>>> [<c001449c>] (handle_IRQ+0x88/0xc8)
>>>>
>>>> Source code including the function wl12xx_hardirq is here:
>>>> http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=drivers/net/wireless/ti/wlcore/main.c;h=45fe911a6504f92dddff5a9415bb77a643b3c4a9;hb=f84c72f6b36418ff11d16808c16a7c3216730bb0
>>>>
>>>> Any idea what could be wrong and how I could debug and fix this situation?
>>>
>>> On first glance, it looks like the driver uses request_threaded_irq(),
>>> to register its handlers, but is trying to acquire a regular spin_lock
>>> in its primary handler.  That's bad news, since spin_locks' can
>>> schedule() when contended with CONFIG_PREEMPT_RT.
>>>
>>> And it's not just that, unfortunately, since the primary handler also
>>> complete()s a completion, which also can schedule().
>>>
>>> It looks like the overall interrupt handling strategy of this driver
>>> probably needs to be revisited. :(.
>>
>> Josh,
>>
>> I really appreciate the answer. Thank you. Though I'm definitely not
>> a RT expert, I really would like to make this work... Could you
>> provide a little bit more guideline what I should patch to fix this
>> situation? Could I change request_threaded_irq to something else?
>> Would raw_spin* help?
>
> In general, the hardirq handler should be doing the absolute bare
> minimum necessary to determine whether or not the device is interrupting
> (and if so, quiet it down and return IRQ_WAKE_THREAD), since
> longer-running handlers have detrimental impact to the system
> determinism.
>
> The right solution for wl12xx seems to be pushing the logic currently
> implemented in the hardirq handler into the threaded handler, but
> without knowing too many details about the driver, its difficult to
> judge the viability/impact of this solution.
[G2]. Luciano,

Could you please comment on this suggestion? With the right guideline, 
I'm willing to patch and test and see if we can improve this buggy 
situation.

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: TI wl1271 wireless bug with 3.4-rt17

[Gregoire Gentil]

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



On 09/05/2012 09:22 PM, Gregoire Gentil wrote:
>
>
> On 09/05/2012 08:48 PM, Josh Cartwright wrote:
>> CC'd Luciano to let him know about breakage of wl12xx on -rt.
>>
>> On Tue, Sep 04, 2012 at 06:22:33PM -0700, Gregoire Gentil wrote:
>>> On 09/04/2012 07:11 AM, Josh Cartwright wrote:
>>>> On Sun, Sep 02, 2012 at 11:24:47PM -0700, Gregoire Gentil wrote:
>>>>> Hello,
>>>>>
>>>>> I'm trying to debug a wifi bug with 3.4-rt17 applied, running on an
>>>>> OMAP4 ARM board such as Pandaboard.
>>>>>
>>>>> Wi-Fi works perfectly well without rt patches. It also works quite
>>>>> well with rt patches AND without wifi module loaded. But with both
>>>>> rt patches and wifi module, the system is very flaky and even if I
>>>>> manage to launch a big download, I get a kernel hang. I managed to
>>>>> get a trace:
>>>>>
>>>>> BUG: scheduling while atomic: irq/213-wl12xx/1588/0x00010002
>>>>> Modules linked in: omapdce(C) wl12xx wlcore omaprpc(C) mac80211 d
>>>>> [<c001beb4>] (unwind_backtrace+0x0/0xf0) from [<c0613548>] (dump)
>>>>> [<c0613548>] (dump_stack+0x20/0x24) from [<c0073908>] (__schedul)
>>>>> [<c0073908>] (__schedule_bug+0x54/0x60) from [<c0614818>] (__sch)
>>>>> [<c0614818>] (__schedule+0x74/0x6c0) from [<c0614f60>] (schedule)
>>>>> [<c0614f60>] (schedule+0xa0/0xb8) from [<c0615eb8>] (rt_spin_loc)
>>>>> [<c0615eb8>] (rt_spin_lock_slowlock+0x198/0x288) from [<c06160a8)
>>>>> [<c06160a8>] (rt_spin_lock+0x18/0x1c) from [<bf0c6b24>] (wl12xx_)
>>>>> [<bf0c6b24>] (wl12xx_hardirq+0x2c/0xa4 [wlcore]) from [<c00bd4f0)
>>>>> [<c00bd4f0>] (handle_irq_event_percpu+0xac/0x24c) from [<c00bd70)
>>>>> [<c00bd70c>] (handle_irq_event+0x7c/0x9c) from [<c00c08f0>] (han)
>>>>> [<c00c08f0>] (handle_level_irq+0xe4/0x134) from [<c00bcf58>] (ge)
>>>>> [<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c03217e8>] (g)
>>>>> [<c03217e8>] (gpio_irq_handler+0x160/0x1a4) from [<c00bcf58>] (g)
>>>>> [<c00bcf58>] (generic_handle_irq+0x34/0x3c) from [<c001449c>] (h)
>>>>> [<c001449c>] (handle_IRQ+0x88/0xc8)
>>>>>
>>>>> Source code including the function wl12xx_hardirq is here:
>>>>> http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=blob;f=drivers/net/wireless/ti/wlcore/main.c;h=45fe911a6504f92dddff5a9415bb77a643b3c4a9;hb=f84c72f6b36418ff11d16808c16a7c3216730bb0
>>>>>
>>>>>
>>>>> Any idea what could be wrong and how I could debug and fix this
>>>>> situation?
>>>>
>>>> On first glance, it looks like the driver uses request_threaded_irq(),
>>>> to register its handlers, but is trying to acquire a regular spin_lock
>>>> in its primary handler.  That's bad news, since spin_locks' can
>>>> schedule() when contended with CONFIG_PREEMPT_RT.
>>>>
>>>> And it's not just that, unfortunately, since the primary handler also
>>>> complete()s a completion, which also can schedule().
>>>>
>>>> It looks like the overall interrupt handling strategy of this driver
>>>> probably needs to be revisited. :(.
>>>
>>> Josh,
>>>
>>> I really appreciate the answer. Thank you. Though I'm definitely not
>>> a RT expert, I really would like to make this work... Could you
>>> provide a little bit more guideline what I should patch to fix this
>>> situation? Could I change request_threaded_irq to something else?
>>> Would raw_spin* help?
>>
>> In general, the hardirq handler should be doing the absolute bare
>> minimum necessary to determine whether or not the device is interrupting
>> (and if so, quiet it down and return IRQ_WAKE_THREAD), since
>> longer-running handlers have detrimental impact to the system
>> determinism.
>>
>> The right solution for wl12xx seems to be pushing the logic currently
>> implemented in the hardirq handler into the threaded handler, but
>> without knowing too many details about the driver, its difficult to
>> judge the viability/impact of this solution.
> [G2]. Luciano,
>
> Could you please comment on this suggestion? With the right guideline,
> I'm willing to patch and test and see if we can improve this buggy
> situation.
>
> Many thanks in advance,
>
> Grégoire
Find attached a patch which seems to work but I really don't know what 
I'm doing here! Any comment would be appreciated,

Grégoire


[-- Attachment #2: rt-wifi.patch --]
[-- Type: text/x-patch, Size: 1085 bytes --]

--- a/drivers/net/wireless/ti/wlcore/main.c	2012-09-06 08:35:44.821870411 -0700
+++ b/drivers/net/wireless/ti/wlcore/main.c	2012-09-06 08:38:32.994704341 -0700
@@ -5234,6 +5234,11 @@
 
 static irqreturn_t wl12xx_hardirq(int irq, void *cookie)
 {
+	return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t wl1271_irq_special(int irq, void *cookie)
+{
 	struct wl1271 *wl = cookie;
 	unsigned long flags;
 
@@ -5253,12 +5258,10 @@
 		wl1271_debug(DEBUG_IRQ, "should not enqueue work");
 		disable_irq_nosync(wl->irq);
 		pm_wakeup_event(wl->dev, 0);
-		spin_unlock_irqrestore(&wl->wl_lock, flags);
-		return IRQ_HANDLED;
 	}
 	spin_unlock_irqrestore(&wl->wl_lock, flags);
 
-	return IRQ_WAKE_THREAD;
+	return wl1271_irq(irq, cookie);
 }
 
 int __devinit wlcore_probe(struct wl1271 *wl, struct platform_device *pdev)
@@ -5292,7 +5295,7 @@
 	else
 		irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
 
-	ret = request_threaded_irq(wl->irq, wl12xx_hardirq, wl1271_irq,
+	ret = request_threaded_irq(wl->irq, wl12xx_hardirq, wl1271_irq_special,
 				   irqflags,
 				   pdev->name, wl);
 	if (ret < 0) {

how to put in higher priority a thread in rt-kernel?

[Gregoire Gentil]

Hello,

I have a mission critical job (reading some I2C and turning on/off some 
GPIOs) running inside a thread of my rt-kernel. This thread is created 
by my driver (create_singlethread_workqueue). How can I put this thread 
in highest priority? In other words, is there an equivalent of 
sched_setscheduler for thread inside the kernel?

Thanks in advance for any advice,

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: how to put in higher priority a thread in rt-kernel?

[Mike Galbraith]

On Sun, 2012-09-09 at 15:51 -0700, Gregoire Gentil wrote: 
> In other words, is there an equivalent of 
> sched_setscheduler for thread inside the kernel?

Yup, and it's even called sched_setscheduler() :)

-Mike

Re: how to put in higher priority a thread in rt-kernel?

[Gregoire Gentil]

On 09/09/2012 08:52 PM, Mike Galbraith wrote:
> On Sun, 2012-09-09 at 15:51 -0700, Gregoire Gentil wrote:
>> In other words, is there an equivalent of
>> sched_setscheduler for thread inside the kernel?
>
> Yup, and it's even called sched_setscheduler() :)
>
> -Mike
Thanks for answering! I don't think that my question is the smartest one 
ever asked on this mailing list ;-)

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: how to put in higher priority a thread in rt-kernel?

[Clark Williams]

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

On Sun, 09 Sep 2012 22:23:08 -0700
Gregoire Gentil <gregoire@gentil.com> wrote:

> 
> 
> On 09/09/2012 08:52 PM, Mike Galbraith wrote:
> > On Sun, 2012-09-09 at 15:51 -0700, Gregoire Gentil wrote:
> >> In other words, is there an equivalent of
> >> sched_setscheduler for thread inside the kernel?
> >
> > Yup, and it's even called sched_setscheduler() :)
> >
> > -Mike
> Thanks for answering! I don't think that my question is the smartest one 
> ever asked on this mailing list ;-)
>

I've heard worse :).

My only comment is that I'd think long and hard before setting my
interrupt thread up at fifo:99, since that's where the migration and
watchdog live and you really don't want to impact them. 

Are you trying to have your interrupt serviced ahead of all the other
system interrupts or just trying to be up above the SCHED_OTHER
threads? If the former, then you just need to be up above wherever the
IRQ threads live (default is fifo:50). If the later then fifo:2 would
be a safe bet.  

Clark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Don't reference non-standard realtime group

[John Kacur]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1741 bytes --]



On Sun, 2 Sep 2012, Uwe Kleine-König wrote:

> On Wed, Jul 13, 2011 at 10:48:31PM +0200, Uwe Kleine-König wrote:
> > There is no dedicated realtime group in most distributions. So make the
> > error message a bit more understandable for people not running Redhat
> > MRG.

I thought we rejected this (via irc) the first time you sent it. The idea 
of a realtime group is pretty generic, but sure, it isn't there by default 
if you don't create it. However, the worse thing about this patch is that 
your message is in no way clearer than the original. It's longer though.

Sorry, I don't like it, maybe Clark will overrule me if he's bored, or 
cares enough, but I'm not putting it in.

> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > Closes: http://bugs.debian.org/619938
> ping?!
> 
> > ---
> >  src/lib/rt-utils.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > --- a/src/lib/rt-utils.c
> > +++ b/src/lib/rt-utils.c
> > @@ -72,7 +72,8 @@
> >  	param.sched_priority = 1;
> >  	if (sched_setscheduler(0, SCHED_FIFO, &param)) {
> >  		fprintf(stderr, "Unable to change scheduling policy!\n");
> > -		fprintf(stderr, "either run as root or join realtime group\n");
> > +		fprintf(stderr, "Probably missing capabilities, either run as "
> > +				"root or increase RLIMIT_RTPRIO limits.\n");
> >  		return 1;
> >  	}
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> --
> 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: Don't reference non-standard realtime group

[Josh Cartwright]

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

On Tue, Oct 16, 2012 at 01:13:35AM +0200, John Kacur wrote:
> On Sun, 2 Sep 2012, Uwe Kleine-König wrote:
>
> > On Wed, Jul 13, 2011 at 10:48:31PM +0200, Uwe Kleine-König wrote:
> > > There is no dedicated realtime group in most distributions. So make the
> > > error message a bit more understandable for people not running Redhat
> > > MRG.
>
> I thought we rejected this (via irc) the first time you sent it. The idea
> of a realtime group is pretty generic, but sure, it isn't there by default
> if you don't create it. However, the worse thing about this patch is that
> your message is in no way clearer than the original. It's longer though.

FWIW, our systems also lack a 'realtime' group, so the existing error
message can lead to a WTF for our users.  At least mentioning
RLIMIT_RTPRIO provides a googlable keyword for those newbie users who
may not know what it means.

It looks like Debian's been carrying Uwe's patch for about a year now.
A downstream distribution patching a specific message into a generic one
seems like an inversion to me.  Shouldn't upstream contain the most
generic message, and downstream distributors patch to make them more
specific?

  Josh

> Sorry, I don't like it, maybe Clark will overrule me if he's bored, or
> cares enough, but I'm not putting it in.
>
> > >
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > Closes: http://bugs.debian.org/619938
> > ping?!
> >
> > > ---
> > >  src/lib/rt-utils.c |    3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > --- a/src/lib/rt-utils.c
> > > +++ b/src/lib/rt-utils.c
> > > @@ -72,7 +72,8 @@
> > >  	param.sched_priority = 1;
> > >  	if (sched_setscheduler(0, SCHED_FIFO, &param)) {
> > >  		fprintf(stderr, "Unable to change scheduling policy!\n");
> > > -		fprintf(stderr, "either run as root or join realtime group\n");
> > > +		fprintf(stderr, "Probably missing capabilities, either run as "
> > > +				"root or increase RLIMIT_RTPRIO limits.\n");
> > >  		return 1;
> > >  	}

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Don't reference non-standard realtime group

[Josh Cartwright]

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

On Tue, Oct 16, 2012 at 01:13:35AM +0200, John Kacur wrote:
> 
> 
> On Sun, 2 Sep 2012, Uwe Kleine-König wrote:
> 
> > On Wed, Jul 13, 2011 at 10:48:31PM +0200, Uwe Kleine-König wrote:
> > > There is no dedicated realtime group in most distributions. So make the
> > > error message a bit more understandable for people not running Redhat
> > > MRG.
> 
> I thought we rejected this (via irc) the first time you sent it. The idea 
> of a realtime group is pretty generic, but sure, it isn't there by default 
> if you don't create it. However, the worse thing about this patch is that 
> your message is in no way clearer than the original. It's longer though.

How do you feel about this wording?

Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>

diff --git a/src/lib/rt-utils.c b/src/lib/rt-utils.c
index f4da4b3..e799c15 100644
--- a/src/lib/rt-utils.c
+++ b/src/lib/rt-utils.c
@@ -264,8 +264,11 @@ int check_privs(void)
 	/* try to change to SCHED_FIFO */
 	param.sched_priority = 1;
 	if (sched_setscheduler(0, SCHED_FIFO, &param)) {
-		fprintf(stderr, "Unable to change scheduling policy!\n");
-		fprintf(stderr, "either run as root or join realtime group\n");
+		fprintf(stderr, "Unable to change scheduling policy.\n");
+		fprintf(stderr, "This likely means you lack real-time privileges.\n");
+		fprintf(stderr, "It may be necessary to run as root or create/join a 'realtime' group.\n");
+		fprintf(stderr, "More details at the RTWiki:\n");
+		fprintf(stderr, "https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions\n");
 		return 1;
 	}
 

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Don't reference non-standard realtime group

[Clark Williams]

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

On Thu, 18 Oct 2012 11:13:21 -0500
Josh Cartwright <josh.cartwright@ni.com> wrote:

> On Tue, Oct 16, 2012 at 01:13:35AM +0200, John Kacur wrote:
> > 
> > 
> > On Sun, 2 Sep 2012, Uwe Kleine-König wrote:
> > 
> > > On Wed, Jul 13, 2011 at 10:48:31PM +0200, Uwe Kleine-König wrote:
> > > > There is no dedicated realtime group in most distributions. So make the
> > > > error message a bit more understandable for people not running Redhat
> > > > MRG.
> > 
> > I thought we rejected this (via irc) the first time you sent it. The idea 
> > of a realtime group is pretty generic, but sure, it isn't there by default 
> > if you don't create it. However, the worse thing about this patch is that 
> > your message is in no way clearer than the original. It's longer though.
> 
> How do you feel about this wording?
> 
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> 
> diff --git a/src/lib/rt-utils.c b/src/lib/rt-utils.c
> index f4da4b3..e799c15 100644
> --- a/src/lib/rt-utils.c
> +++ b/src/lib/rt-utils.c
> @@ -264,8 +264,11 @@ int check_privs(void)
>  	/* try to change to SCHED_FIFO */
>  	param.sched_priority = 1;
>  	if (sched_setscheduler(0, SCHED_FIFO, &param)) {
> -		fprintf(stderr, "Unable to change scheduling policy!\n");
> -		fprintf(stderr, "either run as root or join realtime group\n");
> +		fprintf(stderr, "Unable to change scheduling policy.\n");
> +		fprintf(stderr, "This likely means you lack real-time privileges.\n");
> +		fprintf(stderr, "It may be necessary to run as root or create/join a 'realtime' group.\n");
> +		fprintf(stderr, "More details at the RTWiki:\n");
> +		fprintf(stderr, "https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions\n");
>  		return 1;
>  	}
>  

I'm good with this.

Clark


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]