dashesy | 2 May 20:05 2011
Picon

Recommended motherboard

I have tested the rt31 patch and everything seems great on my
off-the-shelf high-end Xeon desktop so far. I will continue testing
and let you know if I find any oopses or panics :)

We are in the process of upgrading our embedded system, now based on
an old ADEOS patch.
In the first step we need to substitute our soon to be obsolete
motherboard with a new long life industrial motherboard that works
with -rt (as we all hope it will be all in the mainline).
I know I will be going to a lengthy validation and testing phase to
choose the right motherboard, one that is reliable (for a medical
device), state-of-the-art (at least two cores) and of course -rt
compliant (some indication about thing like SMI or hrtimer issues for
example).

There are few book and plenty of resources out there. "Building
Embedded Linux Systems by Karim Yaghmour, et al" is a nice book, and
linux-rt archives, LWN and LKML have been the ultimate source to keep
up with the past (as much as I could) an learn the new. To find out
what might cause problem or what to avoid when designing the system.

It seems the manufacturers section of the OSADL Realtime QA Farm is a
good starting point to look for motherboards if one is concerned about
the latency plots, however,
That would be great if there was some sort of -rt compliance
certificate or tag, issued by OSADL (one organization that I can think
of). I believe, this might generate some revenue for the project, and
some ease of mind for developers who want to start a fresh design.

I appreciate any comments or suggestion about the motherboard.
(Continue reading)

Johannes Bauer | 3 May 09:13 2011
Picon

Re: sched_clock for arm

Does nobody have any idea about that topic?

At the moment im using that implementation and it seems to work unless i am using cyclcitest with -i < 1000.
However when i \"cat /proc/timer_list\" i sometimes get \"active timers\" that expire before
\"next_event\", which seems somhow odd to me. The difference in that values is about 1 ms which should be
easily be able to handle by the highres timer...

> Hello everybody!

Again i am a little bit confused - sorry!

For the lpc2478 board (arm7tdmi-s), with Patrice Kadionik\\\'s help, I implemented a clocksource and
clock event source to achieve hrtimer resolution. I realised i have to implement a sched_clock function
too, in order to achieve better scheduling resolution. I took some examples from the arch/arm directory,
where totally different solution exist. Very few using a cnt32_to_63() functions, others only clocksource_cyc2ns().
Is it ok to implement a sched_clock with only clocksource_cyc2ns() with a 72MHz 32bit counter, since it
wraps somehow often?
It seems the newest preempt-release announced by Thomas Gleixner a few weeks ago has a new arm sched_clock
support provided by Russel King, but I am using 2.6.33.7.2-rt30, where those features are not built in and
i cannot update the kernel yet
I found a conversation initiated by Johannes Stezenbach
(http://ns.spinics.net/lists/arm-kernel/msg86383.html) having the same toopic, but actually no
specific answer to that question was posted.

So is it enough to use clocksource_cyc2ns(), or do I have use something else, and if yould you please point
out some code that does exactly what needs to be done for arm architecture.

At the moment my implemetations looks as following:

   unsigned long long notrace sched_clock(void)
(Continue reading)

Daniel James | 3 May 10:42 2011

Re: Recommended motherboard

Hi dashesy,

> That would be great if there was some sort of -rt compliance
> certificate or tag, issued by OSADL (one organization that I can think
> of). 

At 64 Studio, we would be interested in being part of a certification
scheme.

> I appreciate any comments or suggestion about the motherboard.

You might consider asking Kontron about a suitable board, they have
products such as:

http://uk.kontron.com/products/systems+and+platforms/embedded+ipc++thinkio/thinkioduo.html

Click on Downloads -> Linux on that page, there is a BSP package with an
RT kernel, and also a Debian based distro available, I believe.

Their boards are too expensive for most of our customers, but for a
medical application the cost may be justifiable:

http://uk.kontron.com/industries/medical/

To be clear, we have no business relationship with Kontron, we just keep
an eye on the boards they bring out.

Cheers!

Daniel
(Continue reading)

Ehsan Azarnasab | 3 May 19:08 2011
Picon

Re: Recommended motherboard

Hi Daniel,

On Tue, May 3, 2011 at 2:42 AM, Daniel James <daniel <at> 64studio.com> wrote:
> Hi dashesy,
>
>> That would be great if there was some sort of -rt compliance
>> certificate or tag, issued by OSADL (one organization that I can think
>> of).
>
> At 64 Studio, we would be interested in being part of a certification
> scheme.
Great, I am looking forward to see your mark being advertised on the
future motherboards.
>
>> I appreciate any comments or suggestion about the motherboard.
>
> You might consider asking Kontron about a suitable board, they have
> products such as:
>
> http://uk.kontron.com/products/systems+and+platforms/embedded+ipc++thinkio/thinkioduo.html
>
> Click on Downloads -> Linux on that page, there is a BSP package with an
> RT kernel, and also a Debian based distro available, I believe.
>
> Their boards are too expensive for most of our customers, but for a
> medical application the cost may be justifiable:
>
> http://uk.kontron.com/industries/medical/
>
> To be clear, we have no business relationship with Kontron, we just keep
(Continue reading)

Armin Steinhoff | 3 May 22:13 2011
Picon

Re: Recommended motherboard


Hello Dashesy,

very good information are available at:

https://www.osadl.org/Individual-system-data.qa-farm-data.0.html#c4630

Check out the latency plots and make your own conclusion.

--Armin

dashesy wrote:
> I have tested the rt31 patch and everything seems great on my
> off-the-shelf high-end Xeon desktop so far. I will continue testing
> and let you know if I find any oopses or panics :)
>
> We are in the process of upgrading our embedded system, now based on
> an old ADEOS patch.
> In the first step we need to substitute our soon to be obsolete
> motherboard with a new long life industrial motherboard that works
> with -rt (as we all hope it will be all in the mainline).
> I know I will be going to a lengthy validation and testing phase to
> choose the right motherboard, one that is reliable (for a medical
> device), state-of-the-art (at least two cores) and of course -rt
> compliant (some indication about thing like SMI or hrtimer issues for
> example).
>
> There are few book and plenty of resources out there. "Building
> Embedded Linux Systems by Karim Yaghmour, et al" is a nice book, and
> linux-rt archives, LWN and LKML have been the ultimate source to keep
(Continue reading)

dashesy | 4 May 01:16 2011
Picon

Re: [ANNOUNCE] 2.6.33.9-rt31

On Sat, Apr 16, 2011 at 2:35 AM, Jeremy Jongepier <jeremy <at> autostatic.com> wrote:
> On 04/15/2011 05:02 PM, dashesy wrote:
>>
>> Thanks, works great on 64-bit Ubuntu (Selected SMP and Core i7 and
>> minimal ACPI), the only problem I have is with two displays and
>> nouveau driver.
>
> Which is exactly the same issue I am having. This is because the nouveau
> driver is crippled since rt29.
I applied this patch and now nouveau driver works fine with two monitors:
http://forums.debian.net/viewtopic.php?f=6&t=59599#p348758
>
> Best,
>
> Jeremy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

John Kacur | 12 May 12:55 2011
Picon

[PATCH] rt-tests - minor clean-ups


Hi Clark

Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/jkacur/rt-tests.git
branch: rt-tests-dev

I have a few clean-ups in my repo that aren't in yours.
1. Spelling clean-ups - makes it look more professional
2. A function header style clean-up, and spacing.

The diff between our trees is shown below.

Thanks

diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
index 29d0fe5..d13669b 100644
--- a/src/cyclictest/cyclictest.c
+++ b/src/cyclictest/cyclictest.c
 <at>  <at>  -313,9 +313,7  <at>  <at>  void traceopt(char *option)
 	traceptr[traceopt_count++] = ptr;
 }

John Kacur | 13 May 13:08 2011
Picon

Re: [PATCH] rt-tests - minor clean-ups


On Thu, 12 May 2011, John Kacur wrote:

> 
> Hi Clark
> 
> Please pull from
> git://git.kernel.org/pub/scm/linux/kernel/git/jkacur/rt-tests.git
> branch: rt-tests-dev
> 
> I have a few clean-ups in my repo that aren't in yours.
> 1. Spelling clean-ups - makes it look more professional
> 2. A function header style clean-up, and spacing.
> 
> The diff between our trees is shown below.
> 
> Thanks
> 
> diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
> index 29d0fe5..d13669b 100644
> --- a/src/cyclictest/cyclictest.c
> +++ b/src/cyclictest/cyclictest.c
>  <at>  <at>  -313,9 +313,7  <at>  <at>  void traceopt(char *option)
>  	traceptr[traceopt_count++] = ptr;
>  }
>  
> -
> -static int
> -trace_file_exists(char *name)
> +static int trace_file_exists(char *name)
(Continue reading)

John Kacur | 14 May 17:47 2011
Picon

[stable] Patch for 2.6.33


I merging the latest 2.6.33.13 stable branch into the real-time kernel and 
using a distro with a make 3.82, and needed to cherry-pick the following 
commit in order to compile. Please consider picking it up for 2.6.33.y 
stable.

Thanks
John

From cbbe989bf5f3c8d4671b0c008022a8b718a3c082 Mon Sep 17 00:00:00 2001
From: Jan Beulich <JBeulich <at> novell.com>
Date: Mon, 16 Aug 2010 11:58:58 +0100
Subject: [PATCH] fixes for using make 3.82

commit 3c955b407a084810f57260d61548cc92c14bc627 upstream

It doesn't like pattern and explicit rules to be on the same line,
and it seems to be more picky when matching file (or really directory)
names with different numbers of trailing slashes.

Signed-off-by: Jan Beulich <jbeulich <at> novell.com>
Acked-by: Sam Ravnborg <sam <at> ravnborg.org>
Andrew Benton <b3nton <at> gmail.com>
Cc: <stable <at> kernel.org>
Signed-off-by: Michal Marek <mmarek <at> suse.cz>
Cherry-picked-for: rt/2.6.33
Signed-off-by: John Kacur <jkacur <at> redhat.com>
---
 firmware/Makefile  |    2 +-
 scripts/mkmakefile |    4 +++-
(Continue reading)

John Kacur | 14 May 17:59 2011
Picon

merge of real-time 2.6.33.9-rt31 with stable 2.6.33.13


Hi Thomas

I did some light testing merging 2.6.33.13 into real-time 2.6.33.9-rt31.
In addition I cherry-picked 3c955b407a084810f57260d61548cc92c14bc627
in order to compile on newer distros.

Please consider picking this up. You can get it from
git://git.kernel.org/pub/scm/linux/kernel/git/jkacur/jk-2.6.git rt/2.6.33

Thanks

John Kacur

Here is the result of cyclic test on one machine
sudo ./cyclictest -t32 -p 80 -n -i 10000 -l 10000
policy: fifo: loadavg: 0.00 0.00 0.00 1/541 3759          

T: 0 ( 3728) P:80 I:10000 C:  10000 Min:      7 Act:  104 Avg:  114 Max:     470
T: 1 ( 3729) P:79 I:10500 C:   9524 Min:      4 Act:   93 Avg:  105 Max:     417
T: 2 ( 3730) P:78 I:11000 C:   9091 Min:      4 Act:  114 Avg:  125 Max:     420
T: 3 ( 3731) P:77 I:11500 C:   8696 Min:      4 Act:   58 Avg:   91 Max:     387
T: 4 ( 3732) P:76 I:12000 C:   8333 Min:      4 Act:   84 Avg:  114 Max:     425
T: 5 ( 3733) P:75 I:12500 C:   8000 Min:      4 Act:  133 Avg:  112 Max:     385
T: 6 ( 3734) P:74 I:13000 C:   7692 Min:      3 Act:    8 Avg:   65 Max:     377
T: 7 ( 3735) P:73 I:13500 C:   7407 Min:      3 Act:   91 Avg:   71 Max:     358
T: 8 ( 3736) P:72 I:14000 C:   7143 Min:      4 Act:   78 Avg:   98 Max:     323
T: 9 ( 3737) P:71 I:14500 C:   6897 Min:      7 Act:  133 Avg:  109 Max:     300
T:10 ( 3738) P:70 I:15000 C:   6667 Min:      5 Act:  115 Avg:   98 Max:     314
T:11 ( 3739) P:69 I:15500 C:   6452 Min:      3 Act:    6 Avg:   79 Max:     280
(Continue reading)


Gmane