headers
Yogesh Chaudhari | 1 Dec 2009 06:48
Picon
Gravatar

Re: Ethernet issues with lite5200 board from linux-2.6.31

Hello Grant,

2009/11/30 Grant Likely <grant.likely <at> secretlab.ca>:
> On Mon, Nov 30, 2009 at 2:50 AM, Yogesh Chaudhari <mr.yogesh <at> gmail.com> wrote:
>> Hello,
>>         I am running linux kernel with rt patch on embedded board
>> based on lite5200 eval board. From linux-2.6.31 release, in which the
>> mdio patch has gone inside,  the fec ethernet does not come up on this
>> board. I get the following message at startup:
>> mpc52xx MII bus: probed
>> mdio_bus f0003000: error probing PHY at address 1
>>
>>
>> After the bootup if I try to do a ifconfig I get the message:
>> net eth2: of_phy_connect failed
>>
>>
>> If I change the value of reg in dts file (lite5200.dts) to 0 then this
>> ethernet comes up. However upto this kernel version, this was not
>> required.
>>
>> Ethernet does not come up on board with original lite5200.dts file
>
> Is your board based on the Lite5200 or the Lite5200B?  The phys are at
> different addresses on those two revisions of the board.  There is a
> different .dts file for each board.
>
>> phy0: ethernet-phy <at> 1 {
>>                                 reg = <1>;
>>                         };
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yogesh Chaudhari | 1 Dec 2009 06:48
Picon
Gravatar

Re: Ethernet issues with lite5200 board from linux-2.6.31

2009/11/30 Steven Rostedt <rostedt <at> goodmis.org>:
> On Mon, 2009-11-30 at 15:20 +0530, Yogesh Chaudhari wrote:
>> Hello,
>>          I am running linux kernel with rt patch on embedded board
>> based on lite5200 eval board. From linux-2.6.31 release, in which the
>> mdio patch has gone inside,  the fec ethernet does not come up on this
>> board. I get the following message at startup:
>> mpc52xx MII bus: probed
>
> Do you see the same issue without adding the rt patch?
This issue is present even without the rt patch.
>
> -- Steve
>
>
>

--

-- 
DREAM IT, CODE IT

"CODITO, ERGO SUM"
"I CODE, THEREFORE I AM"
--
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
Permalink | Reply | 0 comments |
headers
Hector Perez Tijero | 1 Dec 2009 13:14
Picon
Favicon

Posix Execution time clock

Hi,

My question might be a little basic for this list... Maybe someone could 
point me out to another forum :)

I'm trying to get some measures using the execution time clock in my 
system and I found some slight differences in the use of the 
CLOCK_THREAD_CPUTIME_ID and CLOCK_MONOTONIC clocks. The measures are 
between the same points of code. My concern is that, sometimes, the 
measure obtained with CLOCK_MONOTONIC is lower than using 
CLOCK_THREAD_CPUTIME_ID. Find below a dummy example to test this strange 
behavior.

It doesn't happen very often but the error could be around hundreds of 
microseconds.

So my question is: are both POSIX clocks based on different physical 
clocks? I always though they use the TSC...

My previous guess was that such behavior could be caused by the CPU 
frequency scaling but the same happened when I disabled it.

My system is running Linux 2.6.24-25-rt #1 SMP PREEMPT RT  (Ubuntu 
package) and I run my tests using the affinity parameter to bind all the 
threads included in the test to the same CPU.

Thanks so much and great work

Hector
(Continue reading)

Permalink | Reply | 5 comments |
headers
Uwe Kleine-König | 1 Dec 2009 10:53
Picon
Favicon
Gravatar

Re: Posix Execution time clock

Hi Hector,

On Tue, Dec 01, 2009 at 07:14:45AM -0500, Hector Perez Tijero wrote:
> My system is running Linux 2.6.24-25-rt #1 SMP PREEMPT RT  (Ubuntu  
> package) and I run my tests using the affinity parameter to bind all the  
> threads included in the test to the same CPU.
I'm not the expert here, but the experts might ask you to reproduce on a
vanilla rt kernel.  (I'm sure the question will contain the word "crap"
:-)

Best regards
Uwe

--

-- 
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 <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Luis Claudio R. Goncalves | 1 Dec 2009 13:32

Re: Posix Execution time clock

On Tue, Dec 01, 2009 at 07:14:45AM -0500, Hector Perez Tijero wrote:
> Hi,
>
> My question might be a little basic for this list... Maybe someone could  
> point me out to another forum :)
>
> I'm trying to get some measures using the execution time clock in my  
> system and I found some slight differences in the use of the  
> CLOCK_THREAD_CPUTIME_ID and CLOCK_MONOTONIC clocks. The measures are  
> between the same points of code. My concern is that, sometimes, the  
> measure obtained with CLOCK_MONOTONIC is lower than using  
> CLOCK_THREAD_CPUTIME_ID. Find below a dummy example to test this strange  
> behavior.
>
> It doesn't happen very often but the error could be around hundreds of  
> microseconds.
>
> So my question is: are both POSIX clocks based on different physical  
> clocks? I always though they use the TSC...

Check the dmesg logs for hints on TSC. There are some TSCs that are not
used as clocksources because they are out-of-sync between CPUs, because
they halt on idle, because they halt on inner C-states and so on...

> My previous guess was that such behavior could be caused by the CPU  
> frequency scaling but the same happened when I disabled it.

How many CPUs?

From http://www.tin.org/bin/man.cgi?section=3&topic=clock_gettime :
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hector Perez Tijero | 2 Dec 2009 10:01
Picon
Favicon

Re: Posix Execution time clock

Hi again,

Thanks for your really quick replies and your contributions!  I have 
found some interesting info:

Luis Claudio R. Goncalves escribió:
> On Tue, Dec 01, 2009 at 07:14:45AM -0500, Hector Perez Tijero wrote:
>   
>> Hi,
>>
>> My question might be a little basic for this list... Maybe someone could  
>> point me out to another forum :)
>>
>> I'm trying to get some measures using the execution time clock in my  
>> system and I found some slight differences in the use of the  
>> CLOCK_THREAD_CPUTIME_ID and CLOCK_MONOTONIC clocks. The measures are  
>> between the same points of code. My concern is that, sometimes, the  
>> measure obtained with CLOCK_MONOTONIC is lower than using  
>> CLOCK_THREAD_CPUTIME_ID. Find below a dummy example to test this strange  
>> behavior.
>>
>> It doesn't happen very often but the error could be around hundreds of  
>> microseconds.
>>
>> So my question is: are both POSIX clocks based on different physical  
>> clocks? I always though they use the TSC...
>>     
>
> Check the dmesg logs for hints on TSC. There are some TSCs that are not
> used as clocksources because they are out-of-sync between CPUs, because
(Continue reading)

Permalink | Reply | 0 comments |
headers
Uwe Kleine-König | 2 Dec 2009 20:08
Picon
Favicon
Gravatar

Re: Posix Execution time clock

On Tue, Dec 01, 2009 at 10:32:28AM -0200, Luis Claudio R. Goncalves wrote:
> Along with that, the latest version for 2.6.24, IIRC, was 2.6.24.7-rt27.
> So, it sounds like you are using older versions of old software.
The version scheme of Ubuntu doesn't allow to read the used rt patch
from the kernel version.  The Ubuntu version used is 2.6.24-25-rt.  This
only means something like:  The 25th Ubuntu revision of the 2.6.24
kernel in the rt feature set.

Best regards
Uwe

--

-- 
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 <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Hector Perez Tijero | 5 Dec 2009 03:23
Picon
Favicon

Re: Posix Execution time clock

Hi all,

Just to complete the info. I have repeated a similar test (SMP and 
scaling frequency disabled in the BIOS, TSC clock) with another function:

If I measure the attached function with CLOCK_THREAD_CPUTIME_ID, I keep 
getting variable timing results. The execution of this function takes 
about 400 usecs in my system. Having called it more than 10_000 times, 
most of the measures are within 100 usecs from this value. This range 
makes sense to me. But I have found a few measures (less than 10 out of 
10_000) which are over 1100 usecs, which it's a bit suspicious. Since 
this clock just takes the execution time associated to a single thread 
(no preemption time should be included) and the function's execution 
time could be considered as "constant", it seems that something is going 
wrong with this kind of clock.

Any idea?

Thanks

Hector

PS: Ubuntu 2.6.24.-25-rt is based on 2.6.24.7-rt27 patch (link 
<http://packages.ubuntu.com/hardy-updates/linux-restricted-modules-2.6.24-25-rt>)

void make_job ()
{
  long temp = 0;
  int index, index2 = 0;
  for (index = 0; index < 5000; index ++) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Kacur | 14 Dec 2009 16:58
Picon
Favicon

[PATCH 3/7] Make use of the new library functions in signaltest.

From: Carsten Emde <carsten.emde <at> osadl.org>

Signed-off-by: Carsten Emde <carsten.emde <at> osadl.org>
Signed-off-by: John Kacur <jkacur <at> redhat.com>
---
 Makefile                    |    2 +-
 src/signaltest/signaltest.c |   27 ++-------------------------
 2 files changed, 3 insertions(+), 26 deletions(-)

diff --git a/Makefile b/Makefile
index 2bb0009..2507a1f 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -23,7 +23,7  <at>  <at>  all: $(TARGETS)
 cyclictest: src/cyclictest/cyclictest.c $(UTILS)
 	$(CC) $(CFLAGS) -D VERSION_STRING=$(VERSION_STRING) $^ -o $ <at>  $(LIBS)

-signaltest: src/signaltest/signaltest.c
+signaltest: src/signaltest/signaltest.c $(UTILS)
 	$(CC) $(CFLAGS) -D VERSION_STRING=$(VERSION_STRING) $^ -o $ <at>  $(LIBS)

 classic_pi: src/pi_tests/classic_pi.c
diff --git a/src/signaltest/signaltest.c b/src/signaltest/signaltest.c
index b637aae..e6016c9 100644
--- a/src/signaltest/signaltest.c
+++ b/src/signaltest/signaltest.c
 <at>  <at>  -27,6 +27,8  <at>  <at> 
 #include <sys/time.h>
 #include <sys/mman.h>
(Continue reading)

Permalink | Reply | 7 comments |
headers
John Kacur | 14 Dec 2009 16:58
Picon
Favicon

[PATCH 2/7] Make use of the library functions in cyclic test.

From: Carsten Emde <carsten.emde <at> osadl.org>

Signed-off-by: Carsten Emde <carsten.emde <at> osadl.org>
Signed-off-by: John Kacur <jkacur <at> redhat.com>
---
 Makefile                    |    6 ++-
 src/cyclictest/cyclictest.c |   84 ++++++------------------------------------
 2 files changed, 16 insertions(+), 74 deletions(-)

diff --git a/Makefile b/Makefile
index d0c4da0..2bb0009 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -8,17 +8,19  <at>  <at>  prefix  ?= /usr/local
 bindir  ?= $(prefix)/bin
 mandir	?= $(prefix)/share/man/man8

-CFLAGS = -Wall -Wno-nonnull
+CFLAGS = -Wall -Wno-nonnull -Isrc/lib
 ifndef DEBUG
 	CFLAGS	+= -O2
 else
 	CFLAGS	+= -O0 -g
 endif

+UTILS	= src/lib/rt-utils.o
+
 .PHONY: all
 all: $(TARGETS)
(Continue reading)

Permalink | Reply | 8 comments |

Gmane