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 <redacted>
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,¶m)){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");return1;}--
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
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 <redacted>
Closes: http://bugs.debian.org/619938
@@ -72,7 +72,8 @@param.sched_priority=1;if(sched_setscheduler(0,SCHED_FIFO,¶m)){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");return1;}
--
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
@@ -554,7 +554,15 @@*aworkqueue,sowewon'tgetcallbacksandcanholdport_lock*/if(tty&&do_push)-tty_flip_buffer_push(tty);+/*+*Dropthelockheresinceitmightendupcalling+*gs_flush_chars,whichtakesthelock.+*/+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
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
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
On Sun, Sep 02, 2012 at 11:24:47PM -0700, Gregoire Gentil wrote:
quoted
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
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:
quoted
On Sun, Sep 02, 2012 at 11:24:47PM -0700, Gregoire Gentil wrote:
quoted
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
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:
quoted
On 09/04/2012 07:11 AM, Josh Cartwright wrote:
quoted
On Sun, Sep 02, 2012 at 11:24:47PM -0700, Gregoire Gentil wrote:
quoted
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
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:
quoted
On 09/04/2012 07:11 AM, Josh Cartwright wrote:
quoted
On Sun, Sep 02, 2012 at 11:24:47PM -0700, Gregoire Gentil wrote:
quoted
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
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
On Sun, 2012-09-09 at 15:51 -0700, Gregoire Gentil wrote:
quoted
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
On Sun, 2012-09-09 at 15:51 -0700, Gregoire Gentil wrote:
quoted
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
From: John Kacur <jkacur@redhat.com> Date: 2012-10-15 23:11:48
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:
quoted
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.
@@ -72,7 +72,8 @@param.sched_priority=1;if(sched_setscheduler(0,SCHED_FIFO,¶m)){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");return1;}
--
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
On Tue, Oct 16, 2012 at 01:13:35AM +0200, John Kacur wrote:
On Sun, 2 Sep 2012, Uwe Kleine-König wrote:
quoted
On Wed, Jul 13, 2011 at 10:48:31PM +0200, Uwe Kleine-König wrote:
quoted
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.
@@ -72,7 +72,8 @@param.sched_priority=1;if(sched_setscheduler(0,SCHED_FIFO,¶m)){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");return1;}
On Tue, Oct 16, 2012 at 01:13:35AM +0200, John Kacur wrote:
On Sun, 2 Sep 2012, Uwe Kleine-König wrote:
quoted
On Wed, Jul 13, 2011 at 10:48:31PM +0200, Uwe Kleine-König wrote:
quoted
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 <redacted>
@@ -264,8 +264,11 @@ int check_privs(void)/* try to change to SCHED_FIFO */param.sched_priority=1;if(sched_setscheduler(0,SCHED_FIFO,¶m)){-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");return1;}
From: Clark Williams <hidden> Date: 2012-10-19 02:12:47
On Thu, 18 Oct 2012 11:13:21 -0500
Josh Cartwright [off-list ref] wrote:
quoted hunk
On Tue, Oct 16, 2012 at 01:13:35AM +0200, John Kacur wrote:
quoted
On Sun, 2 Sep 2012, Uwe Kleine-König wrote:
quoted
On Wed, Jul 13, 2011 at 10:48:31PM +0200, Uwe Kleine-König wrote:
quoted
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 <redacted>
@@ -264,8 +264,11 @@ int check_privs(void)/* try to change to SCHED_FIFO */param.sched_priority=1;if(sched_setscheduler(0,SCHED_FIFO,¶m)){-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");return1;}