, Arjan van de Ven [EMAIL PROTECTED]:
On Mon, 2007-07-16 at 21:46 +0200, Remy Bohmer wrote:
So I was wondering if anybody knows some tool/kernel mechanism which
can do this?
If not, I will build a kernel extension for it myself (new extension
to 'latency_trace' ?)
systemtap has been able to do
Hello Darren,
I disagree. The point of real-time is to provide user-space with more control
of what get's run, when, instead of something else - including system
interrupts, etc. For instance, if networking should take a higher priority
than their application, but disk i/o should take a
Hello Steven,
Actually, the handler thread runs _all_ register interrupt handlers. So
there's no way to make one a higher priority than the other. This is a
tough problem. If you have two shared handlers on the same irq line,
and think you can make one a higher priority than the other, you
Hello Steven,
Perhaps adding in a new command line interface (We may need to extend the
command line size limit). Where one could do
irq_priority_map=10-51,21-40,... Where the first number is the irq number
followed by the irq priority. We can also do something similar to
softirqs.
Would
threads
like Interrupt threads and soft-irqs to match them with our
applications.
Signed-off-by: Remy Bohmer [EMAIL PROTECTED]
---
kernel/irq/manage.c | 12 +--
kernel/softirq.c| 53 +---
2 files changed, 44 insertions(+), 21 deletions
Hello Manfred,
At http://www.spinics.net/lists/arm-kernel/msg42349.html you can find
a patch that will probably work. Due to the lack of proper atomic
instructions on the ARM-v4 core this patch is likely to be the best
possible solution.
Kind Regards,
Remy
2007/8/20, Manfred Gruber [EMAIL
Hello Manfred,
My question if I run the pi_stress, my watchdog triggers, if watchdog is
disabled i get this:
Is this the correct behaviour ? Or does it show a problem ?
Depends on the priority of your watchdog-feeder thread. If it is not
running in RT mode, with a priority higher than used in
is not available in RAM, but e.g. somewhere in a swap space. If
the memory has to be paged in, probably interrupts are needed. In my
system things like this will never happen...
Maybe Ingo, Thomas or someone else can acknowledge (or trash) my opinion here?
Kind Regards,
Remy Bohmer
-
To unsubscribe
Hello Steven,
Thanks for your explanation, here are my answers:
So, A normal (non-raw) spinlock should NOT be used here, because that
does would be converted to a rt-mutex, which is preemptible. If this
code is preemptible, it could be preempted by another user space
thread which could,
and
processor type/speed that is supported.
What do you think?
Kind Regards,
Remy Bohmer
2007/10/1, Jaswinder Singh [EMAIL PROTECTED]:
Hello all,
I tried to fill remaining entries in :
http://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions
Please it out, is these OK.
Thank you
it was there in the past, but I thought these were all
fixed by now.
AFAIK: The latest kernels have fixed the netwerk performance
degradation bug, and on Dual-Core we even notice a performance
improvement compared to non-RT.
Kind Regards,
Remy Bohmer
2007/10/2, Theodore Tso [EMAIL PROTECTED]:
On Mon, Oct
-2.6.23/arch/s390/kernel/time.c:197
Kind Regards,
Remy Bohmer
2007/8/28, Daniel Walker [EMAIL PROTECTED]:
Replace the old PICK_OP style macros with PICK_FUNCTION. Although,
seqlocks has some alien code, which I also replaced as can be seen
from the line count below.
Signed-off-by: Daniel Walker
Hello Steven,
It should print out warnings, do you have CONFIG_DEBUG_RT_MUTEXES set?
Nope, not yet... I will do that on Monday also. (On ARM I have as less
as debug options enabled per default, because it eats too much
CPU-power)
* PI should only take place if it is for 100% sure that the
in
mainline of the RT-patch.
Kind Regards,
Remy Bohmer
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Sure, you want to split the list?
split the list with you? Feel free to take any of those :-) dev-sem is
nontrivial and probably not possible right now - and some of the others
might be problematic too. But there might be fixable ones in the list.
This shouldnt become like the BKL
Hello Daniel,
Can we coordinate who is doing what somehow, to prevent double work?
Remy
2007/11/19, Daniel Walker [EMAIL PROTECTED]:
On Mon, 2007-11-19 at 02:24 -0500, Jon Masters wrote:
On Sat, 2007-11-17 at 09:55 -0800, Daniel Walker wrote:
Sure, you want to split the list?
I'm
handling stalls forever.
This is caused by a unbalanced interrupt mask/unmask problem in the kernel.
The attached patch fixes this. More information about this problem is
documented inside the patch itself.
This patch is meant for Preempt-RT only.
Kind Regards,
Remy Bohmer
On ARM there is a problem
Attached the same patch, but it also cleans the manage.c code a bit,
because the IRQ types 'simple IRQ', 'level-IRQ' and 'FastEOI' were
handled differently while they should be handled the same.
Kind Regards,
Remy
2007/11/26, Remy Bohmer [EMAIL PROTECTED]:
Hello,
I use 2.6.23.1-rt5
Hello Kevin,
Just copied your mail to the list, maybe your solution is also worth looking at.
Remy
I had a similar issue when using the chained GPIO interrupts on OMAP
under PREEMPT_RT.
I believe the chained handler itself is supposed to be doing the
ack/unmask instead of the
King - ARM Linux [EMAIL PROTECTED]:
On Thu, Nov 29, 2007 at 11:14:30AM +0100, Remy Bohmer wrote:
I do not think Russell is right here with assuming that the wrong
interrupt handler type is used. Looking at the behaviour of the
mainline kernel (non-RT), the implementation is quite different
Hello Russell,
While I realise that, I'm telling you that the _problem_ is being
caused by the wrong handler being used.
Okay, I believe you... (someone told me once, Russell is right, and if
you do not believe him, he is still right ;-)
SA1100 and PXA have exactly the same setup. They use
time on that board.
Kind Regards,
Remy
2007/11/29, Remy Bohmer [EMAIL PROTECTED]:
Hello Russell,
While I realise that, I'm telling you that the _problem_ is being
caused by the wrong handler being used.
Okay, I believe you... (someone told me once, Russell is right, and if
you do
In that case, shall I create a new patchset for this compared to mainline?
Then we can merge the DMA patch in the interrupt handler later on. (it
is really difficult to do)
Oops, Typo, I meant: it is NOT really difficult...
Remy
2007/12/7, Remy Bohmer [EMAIL PROTECTED]:
Hello Andrew
Hello Steven,
In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling
was implemented, and the simple irq handler had a masking set to it.
Remy Bohmer discovered that some devices in the ARM architecture
would trigger the mask, but never unmask it. His patch to do
No problem. Could you also ACK the one I sent for mainline.
I will test it first tomorrow morning.
Remy
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Steven,
So, I have here 3 patches:
* atmel_serial_cleanup - This patch adapts the driver to the coding
rules, splits the interrupt handler into 3 routines (cuts the routine
in more readable pieces) , but there is no functional change involved.
* atmel_serial_irq_splitup - This
for page draining during cpu (Andi Kleen)
- Revert lazy disable irq from simple irq handler (Steven Rostedt)
- AT91 switch to edge from simple irq (Remy Bohmer)
to build a 2.6.23.9-rt13 tree, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux
-patch:
* atmel_serial_irqf_nodelay.patch
I hope this set is easier to integrate.
Kind Regards,
Remy
2007/12/12, Remy Bohmer [EMAIL PROTECTED]:
Hello Steven,
So, I have here 3 patches:
* atmel_serial_cleanup - This patch adapts the driver to the coding
rules, splits the interrupt
on top of this set to make this patch queue easier to
handle.
Regards,
Remy
This patch cleans up the atmel_serial driver to conform the coding rules.
It contains no functional change.
Signed-off-by: Remy Bohmer [EMAIL PROTECTED]
---
drivers/serial/atmel_serial.c | 351
character.
This patch demands the following patches to be installed first:
* atmel_serial_cleanup.patch
Signed-off-by: Remy Bohmer [EMAIL PROTECTED]
---
drivers/serial/atmel_serial.c | 150 +-
1 file changed, 133 insertions(+), 17 deletions(-)
Index: linux
Hello Haavard,
I'll give it a shot, but first I have some comments on your other
patches.
Good news someone is working on this bug again. Also good news you
already found a bug in there.
Btw, it would be nice if patches that affect more or less
architecture-independent drivers were posted
Hi Steven and/or Thomas,
I have a question regarding the stability of the time-of-day on
PREEMPT_RT and NTP and such. I hope one of you can answer them.
In a hard real time user space application, running on a PREEMPT_RT
kernel (currently 2.6.20-rt8), we are using the clock_gettime() API
from
a __setup(sirq_pmap=) routine to kernel/softirq.c
I hope you can find the time to review this set.
Kind Regards,
Remy Bohmer
--
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
kernel/Documentation/kernel-parameters.txt for usage info.
Signed-off-by: Remy Bohmer [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt | 11 +++
kernel/softirq.c| 105 ++--
2 files changed, 99 insertions(+), 17 deletions(-)
Index
kernel/Documentation/kernel-parameters.txt for usage info.
Signed-off-by: Remy Bohmer [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt | 11 +++
kernel/softirq.c| 105 ++--
2 files changed, 99 insertions(+), 17 deletions(-)
Index
Hello Randy,
Sorry for the language errors, English is not my Native language, so I
make these stupid errors...
+ * get_map_option - Parse integer from an option map
The @param lines (below) need to go here, immediately following the
function short description (the line above). No
36 matches
Mail list logo
