Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Gilles Chanteperdrix]

xenomai@domain.hid wrote:
>  -------------- Original message ----------------------
> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> 
>>xenomai@domain.hid wrote:
>>
>>>#
>>># SMI workaround
>>>#
>>># CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
>>>CONFIG_XENO_HW_SMI_DETECT=y
>>>CONFIG_XENO_HW_SMI_WORKAROUND=y
>>># CONFIG_XENO_HW_SMI_ALL is not set
>>># CONFIG_XENO_HW_SMI_INTEL_USB2 is not set
>>># CONFIG_XENO_HW_SMI_LEGACY_USB2 is not set
>>># CONFIG_XENO_HW_SMI_PERIODIC is not set
>>># CONFIG_XENO_HW_SMI_TCO is not set
>>># CONFIG_XENO_HW_SMI_MC is not set
>>>CONFIG_XENO_HW_SMI_APMC=y
>>># CONFIG_XENO_HW_SMI_LEGACY_USB is not set
>>>CONFIG_XENO_HW_SMI_BIOS=y
>>
>>Chances are that the latencies you get are due to the SMI you leave
>>enabled (APMC or BIOS). Could you try first with only
>>CONFIG_XENO_HW_SMI_ALL ?
>>
> WOW!!!  I did try that with the 2.6.17 kernel but it wouldnt boot,
> I had to enable APM.  It is working like  charm now.  Max latency
> is 4-5 us while running X.  If I drag a window around it goes up
> to 7us or so.  Deffinately a step in the righ direction!  Thanks.

Good news.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[xenomai]

RE Previous message : hanging daemons


I just started removing modules.  First timerbench, then native, then rtdm.... That did it.  When I remove rtdm the daemon drops to normal cpu usage.

Mike

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Jan Kiszka]

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

xenomai@domain.hid wrote:
> RE Previous message : hanging daemons
> 
> 
> I just started removing modules.  First timerbench, then native, then rtdm.... That did it.  When I remove rtdm the daemon drops to normal cpu usage.

That sounds a bit like we have some issue with the host timer of Linux
once Xenomai takes over.

A lot changed during your last tests. To make sure we are discussing the
same setup, could you re-post your current .config and the used versions
of Xenomai, kernel, and ipipe patch to the list?

TiA,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Philippe Gerum]

On Fri, 2007-03-23 at 18:27 +0100, Jan Kiszka wrote:
> xenomai@domain.hid wrote:
> > RE Previous message : hanging daemons
> > 
> > 
> > I just started removing modules.  First timerbench, then native, then rtdm.... That did it.  When I remove rtdm the daemon drops to normal cpu usage.
> 
> That sounds a bit like we have some issue with the host timer of Linux
> once Xenomai takes over.
> 

Just loading the native skin over the nucleus would confirm this or not.

> A lot changed during your last tests. To make sure we are discussing the
> same setup, could you re-post your current .config and the used versions
> of Xenomai, kernel, and ipipe patch to the list?
> 
> TiA,
> Jan
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[xenomai]

 > I did configure a dual-core box with Broadcom GigE I/F and experience
> trouble weird behavior and total lockup if
>  MSI was enabled
>  HPET was enabled.
> 
> My trouble comes out only to 1 of the 3 ethernet I/F but...
> 
> I disabled MSI and HPET and all is working fine until now (with xenomai 2.3.0).
> 

I ended up turning off the SUSE Firewall and I could get out.  I'll look into why that is happening later.  I am back to my 100% cpu usage problem though.... As soon as I load the xeno-timerbench module either the beagled or hald peg the cpu.  If I don't load xeno-timerbench, it doesn't happen.  Only one process does this... never both.

Mike

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[xenomai]

> Btw, make sure 100% that all your modules issued from the kernel
> compilation in question have been properly installed under /lib/modules.
> 
> Additionally, it has been reported (and I recently experienced this
> myself) than under some specific circumstances, only running a "make
> clean" in an old Xenomai-enabled kernel tree before upgrading the
> Xenomai support with prepare-kernel.sh, then compiling anew, is _not_
> enough. This may introduce some funky issues, likely due to missed
> dependencies in the kernel tree.


I did originally build the kernel form fresh source and have only patched once.  I am however rebuilding after a make mrproper just for kicks.  Since building the nucleus as a module, It appears that things are being scheduled on both processors  for linux.  I still however can't get my network connection to work properly.  It is a Broadcom NetExtreme GigE card.  It successfully get's a DHCP address as if it is working fine.  No messages in any of the log files.  I however can not get out at all.  When trying to get in from the outside with ssh it supplies me the host key but then hangs for about 1 minute then prompts me for a password and works fine from there.    From inside, even pings dont work.

Mike

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Gilles Chanteperdrix]

xenomai@domain.hid wrote:
>>Btw, make sure 100% that all your modules issued from the kernel
>>compilation in question have been properly installed under /lib/modules.
>>
>>Additionally, it has been reported (and I recently experienced this
>>myself) than under some specific circumstances, only running a "make
>>clean" in an old Xenomai-enabled kernel tree before upgrading the
>>Xenomai support with prepare-kernel.sh, then compiling anew, is _not_
>>enough. This may introduce some funky issues, likely due to missed
>>dependencies in the kernel tree.
> 
> 
> 
> I did originally build the kernel form fresh source and have only patched
> once.  I am however rebuilding after a make mrproper just for kicks.
> Since building the nucleus as a module, It appears that things are being
> scheduled on both processors  for linux.  I still however can't get my
> network connection to work properly.  It is a Broadcom NetExtreme GigE
> card.  It successfully get's a DHCP address as if it is working fine.
> No messages in any of the log files.  I however can not get out at all.
> When trying to get in from the outside with ssh it supplies me the host
> key but then hangs for about 1 minute then prompts me for a password and
> works fine from there.    From inside, even pings dont work.

Do you have the same behaviour of your network card when the SMI
workaround is disabled ?
Did you try to disable CONFIG_PCI_MSI ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> xenomai@domain.hid wrote:
> 
>>>Btw, make sure 100% that all your modules issued from the kernel
>>>compilation in question have been properly installed under /lib/modules.
>>>
>>>Additionally, it has been reported (and I recently experienced this
>>>myself) than under some specific circumstances, only running a "make
>>>clean" in an old Xenomai-enabled kernel tree before upgrading the
>>>Xenomai support with prepare-kernel.sh, then compiling anew, is _not_
>>>enough. This may introduce some funky issues, likely due to missed
>>>dependencies in the kernel tree.
>>
>>
>>
>>I did originally build the kernel form fresh source and have only patched
>>once.  I am however rebuilding after a make mrproper just for kicks.
>>Since building the nucleus as a module, It appears that things are being
>>scheduled on both processors  for linux.  I still however can't get my
>>network connection to work properly.  It is a Broadcom NetExtreme GigE
>>card.  It successfully get's a DHCP address as if it is working fine.
>>No messages in any of the log files.  I however can not get out at all.
>>When trying to get in from the outside with ssh it supplies me the host
>>key but then hangs for about 1 minute then prompts me for a password and
>>works fine from there.    From inside, even pings dont work.
> 
> 
> Do you have the same behaviour of your network card when the SMI
> workaround is disabled ?
> Did you try to disable CONFIG_PCI_MSI ?
> 

What does tcpdump say during the 1 minute before prompting your password
and when ping does not work ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Eric Noulard]

2007/3/23, xenomai@domain.hid <xenomai@domain.hid>:
> I still however can't get my network connection to work
>properly.  It is a Broadcom NetExtreme GigE card.  It successfully
get's a DHCP
>address as if it is working fine.  No messages in any of the log
files.  I however
>can not get out at all.  When trying to get in from the outside with
ssh it supplies
>me the host key but then hangs for about 1 minute then prompts me for a
>password and works fine from there.    From inside, even pings dont work.


Did you tried mii-tool or ethtool on the I/F
your I/F may wrongly negotiate the link (wrong speed and/or half duplex...)

I did configure a dual-core box with Broadcom GigE I/F and experience
trouble weird behavior and total lockup if
 MSI was enabled
 HPET was enabled.

My trouble comes out only to 1 of the 3 ethernet I/F but...

I disabled MSI and HPET and all is working fine until now (with xenomai 2.3.0).

-- 
Erk

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[xenomai]

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

>Regarding "nothing gets scheduled on" CPU #2: Do you mean no Linux job
or no Xenomai task? The bug that was (/should be) fixed in 2.3.1 was
concerning Linux, Xenomai requires explicit scheduling.

>But you are right, something is fishy here. I never heard of hanging
modules like that before.


Well, I made nucleus as a module and it boots up and runs fine.  After installing the modules the tests run although with slightly different results.  Insted of single digit latencies, I get upwared of 38us every once in a while.

Mike


 -------------- Original message ----------------------
From: Jan Kiszka <jan.kiszka@domain.hid>



[-- Attachment #2: Type: message/rfc822, Size: 1600 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 587 bytes --]

[Please don't top-post, cite only what you comment on.]

xenomai@domain.hid wrote:
> I disabled CONFIG_ACPI_AC and I got the same hang with ACPI_BATTERY. I am using 2.31.  Any other suggestions?  I will remove all that hang
but I feer that that is not the right way to go.

Regarding "nothing gets scheduled on" CPU #2: Do you mean no Linux job
or no Xenomai task? The bug that was (/should be) fixed in 2.3.1 was
concerning Linux, Xenomai requires explicit scheduling.

But you are right, something is fishy here. I never heard of hanging
modules like that before.

Jan


[-- Attachment #2.1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[xenomai]

I removed the offending modules that were hanging modprobe but am now seeing hald doing the same thing.  I'll try making it as a module and loading after bootup.

Mike
 -------------- Original message ----------------------
From: Philippe Gerum <rpm@xenomai.org>
> On Fri, 2007-03-23 at 14:04 +0000, xenomai@domain.hid wrote:
> > Hello,
> > 
> > I have been working on trying to find the optimal linux kernel configuration 
> and have noticed a couple problems.
> > No matter what I do it seems that while cpu #2 is detected, nothing gets 
> scheduled on it. 
> 
> If not already done, try building the Xenomai nucleus as a module
> instead of statically into the kernel. Is the situation normal with
> respect to load balancing between CPUs before you eventually modprobe
> this module?
> 
> > Also, there is always a modprobe process running at 100%cpu that I can't kill.
> 
> modprobe of which module?
> 
> >   The command that is showed in top is "modprobe -s ac".  If I run it from the 
> command line it hangs as well.
> >   Latencies are however very acceptable when running xeno-test.  I do however 
> see some negative values
> >  in the test output.
> 
> Negative values are (mostly) ok. This only means that your machine is
> faster than pre-calibrated for, which causes the timer shots to be ahead
> of time, due to a pessimistic calibration.
> Check /proc/xenomai/latency, this gives the intrinsic latency Xenomai
> anticipates when programming timer shots (i.e. interrupt latency +
> scheduling latency altogether), given as a count of nanoseconds.
> 
> You can change this value on the fly while the latency test is running;
> just echo a new value to this file. You should try lowering it until all
> the values (particularly the leftmost ones, i.e. "min lat") raise
> slightly above zero.
> 
> > 
> > The config file that I am using currently is the same as the one below just 
> with CONFIG_XENO_HW_SMI_ALL.
> >   This seems to give me the best latencies.
> > 
> > Mike
> > 
> >  -------------- Original message ----------------------
> > From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> > > xenomai@domain.hid wrote:
> > > >  -------------- Original message ----------------------
> > > > From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> > > > 
> > > >>xenomai@domain.hid wrote:
> > > >>
> > > >>>#
> > > >>># SMI workaround
> > > >>>#
> > > >>># CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
> > > >>>CONFIG_XENO_HW_SMI_DETECT=y
> > > >>>CONFIG_XENO_HW_SMI_WORKAROUND=y
> > > >>># CONFIG_XENO_HW_SMI_ALL is not set
> > > >>># CONFIG_XENO_HW_SMI_INTEL_USB2 is not set
> > > >>># CONFIG_XENO_HW_SMI_LEGACY_USB2 is not set
> > > >>># CONFIG_XENO_HW_SMI_PERIODIC is not set
> > > >>># CONFIG_XENO_HW_SMI_TCO is not set
> > > >>># CONFIG_XENO_HW_SMI_MC is not set
> > > >>>CONFIG_XENO_HW_SMI_APMC=y
> > > >>># CONFIG_XENO_HW_SMI_LEGACY_USB is not set
> > > >>>CONFIG_XENO_HW_SMI_BIOS=y
> > > >>
> > > >>Chances are that the latencies you get are due to the SMI you leave
> > > >>enabled (APMC or BIOS). Could you try first with only
> > > >>CONFIG_XENO_HW_SMI_ALL ?
> > > >>
> > > > WOW!!!  I did try that with the 2.6.17 kernel but it wouldnt boot,
> > > > I had to enable APM.  It is working like  charm now.  Max latency
> > > > is 4-5 us while running X.  If I drag a window around it goes up
> > > > to 7us or so.  Deffinately a step in the righ direction!  Thanks.
> > > 
> > > Good news.
> > > 
> > > -- 
> > >                                                  Gilles Chanteperdrix
> > 
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> -- 
> Philippe.
> 
> 

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Philippe Gerum]

On Fri, 2007-03-23 at 14:47 +0000, xenomai@domain.hid wrote:
> I removed the offending modules that were hanging modprobe but am now seeing hald doing the same thing.  I'll try making it as a module and loading after bootup.
> 

Btw, make sure 100% that all your modules issued from the kernel
compilation in question have been properly installed under /lib/modules.

Additionally, it has been reported (and I recently experienced this
myself) than under some specific circumstances, only running a "make
clean" in an old Xenomai-enabled kernel tree before upgrading the
Xenomai support with prepare-kernel.sh, then compiling anew, is _not_
enough. This may introduce some funky issues, likely due to missed
dependencies in the kernel tree.

E.g.

$ cd .../linux-xeno-2.2.5 && make clean
$ ~/xenomai-2.3.1/scripts/prepare-kernel.sh --forcelink --arch=x86
--linux=.
$ [ make oldconfig && ] make

The above may _NOT_ always work as expected.

The best way to prevent this is to compile a freshly patched kernel,
only recycling the .config file from the old kernel, which is definitely
ok (make mrproper in the old kernel would likely work too).

> Mike
>  -------------- Original message ----------------------
> From: Philippe Gerum <rpm@xenomai.org>
> > On Fri, 2007-03-23 at 14:04 +0000, xenomai@domain.hid wrote:
> > > Hello,
> > > 
> > > I have been working on trying to find the optimal linux kernel configuration 
> > and have noticed a couple problems.
> > > No matter what I do it seems that while cpu #2 is detected, nothing gets 
> > scheduled on it. 
> > 
> > If not already done, try building the Xenomai nucleus as a module
> > instead of statically into the kernel. Is the situation normal with
> > respect to load balancing between CPUs before you eventually modprobe
> > this module?
> > 
> > > Also, there is always a modprobe process running at 100%cpu that I can't kill.
> > 
> > modprobe of which module?
> > 
> > >   The command that is showed in top is "modprobe -s ac".  If I run it from the 
> > command line it hangs as well.
> > >   Latencies are however very acceptable when running xeno-test.  I do however 
> > see some negative values
> > >  in the test output.
> > 
> > Negative values are (mostly) ok. This only means that your machine is
> > faster than pre-calibrated for, which causes the timer shots to be ahead
> > of time, due to a pessimistic calibration.
> > Check /proc/xenomai/latency, this gives the intrinsic latency Xenomai
> > anticipates when programming timer shots (i.e. interrupt latency +
> > scheduling latency altogether), given as a count of nanoseconds.
> > 
> > You can change this value on the fly while the latency test is running;
> > just echo a new value to this file. You should try lowering it until all
> > the values (particularly the leftmost ones, i.e. "min lat") raise
> > slightly above zero.
> > 
> > > 
> > > The config file that I am using currently is the same as the one below just 
> > with CONFIG_XENO_HW_SMI_ALL.
> > >   This seems to give me the best latencies.
> > > 
> > > Mike
> > > 
> > >  -------------- Original message ----------------------
> > > From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> > > > xenomai@domain.hid wrote:
> > > > >  -------------- Original message ----------------------
> > > > > From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> > > > > 
> > > > >>xenomai@domain.hid wrote:
> > > > >>
> > > > >>>#
> > > > >>># SMI workaround
> > > > >>>#
> > > > >>># CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
> > > > >>>CONFIG_XENO_HW_SMI_DETECT=y
> > > > >>>CONFIG_XENO_HW_SMI_WORKAROUND=y
> > > > >>># CONFIG_XENO_HW_SMI_ALL is not set
> > > > >>># CONFIG_XENO_HW_SMI_INTEL_USB2 is not set
> > > > >>># CONFIG_XENO_HW_SMI_LEGACY_USB2 is not set
> > > > >>># CONFIG_XENO_HW_SMI_PERIODIC is not set
> > > > >>># CONFIG_XENO_HW_SMI_TCO is not set
> > > > >>># CONFIG_XENO_HW_SMI_MC is not set
> > > > >>>CONFIG_XENO_HW_SMI_APMC=y
> > > > >>># CONFIG_XENO_HW_SMI_LEGACY_USB is not set
> > > > >>>CONFIG_XENO_HW_SMI_BIOS=y
> > > > >>
> > > > >>Chances are that the latencies you get are due to the SMI you leave
> > > > >>enabled (APMC or BIOS). Could you try first with only
> > > > >>CONFIG_XENO_HW_SMI_ALL ?
> > > > >>
> > > > > WOW!!!  I did try that with the 2.6.17 kernel but it wouldnt boot,
> > > > > I had to enable APM.  It is working like  charm now.  Max latency
> > > > > is 4-5 us while running X.  If I drag a window around it goes up
> > > > > to 7us or so.  Deffinately a step in the righ direction!  Thanks.
> > > > 
> > > > Good news.
> > > > 
> > > > -- 
> > > >                                                  Gilles Chanteperdrix
> > > 
> > > 
> > > _______________________________________________
> > > Xenomai-help mailing list
> > > Xenomai-help@domain.hid
> > > https://mail.gna.org/listinfo/xenomai-help
> > -- 
> > Philippe.
> > 
> > 
> 
-- 
Philippe.

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[xenomai]

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

I disabled CONFIG_ACPI_AC and I got the same hang with ACPI_BATTERY.  I am using 2.31.  Any other suggestions?  I will remove all that hang but I feer that that is not the right way to go.

Mike


 -------------- Original message ----------------------
From: Jan Kiszka <jan.kiszka@domain.hid>



[-- Attachment #2: Type: message/rfc822, Size: 2111 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 1108 bytes --]

xenomai@domain.hid wrote:
> Hello,
> 
> I have been working on trying to find the optimal linux kernel
> configuration and have noticed a couple problems.  No matter what I
> do it seems that while cpu #2 is detected, nothing gets scheduled on

Sounds like some bug that was fixed in 2.3.1. Are you already using that
version? If not: highly recommended.

> it.  Also, there is always a modprobe process running at 100%cpu that
> I can't kill.  The command that is showed in top is "modprobe -s ac".

Probably due to SMI being disable. Don't know what that module precisely
does when it loops, but it may wait on SMI-backed activity of the
hardware that is now disabled. Try to switch off CONFIG_ACPI_AC in your
config.

> If I run it from the command line it hangs as well.  Latencies are
> however very acceptable when running xeno-test.  I do however see
> some negative values in the test output.
> 
> The config file that I am using currently is the same as the one
> below just with CONFIG_XENO_HW_SMI_ALL.  This seems to give me the
> best latencies.
> 
> Mike
> 

Jan


[-- Attachment #2.1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Jan Kiszka]

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

[Please don't top-post, cite only what you comment on.]

xenomai@domain.hid wrote:
> I disabled CONFIG_ACPI_AC and I got the same hang with ACPI_BATTERY. I am using 2.31.  Any other suggestions?  I will remove all that hang
but I feer that that is not the right way to go.

Regarding "nothing gets scheduled on" CPU #2: Do you mean no Linux job
or no Xenomai task? The bug that was (/should be) fixed in 2.3.1 was
concerning Linux, Xenomai requires explicit scheduling.

But you are right, something is fishy here. I never heard of hanging
modules like that before.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[xenomai]

Hello,

I have been working on trying to find the optimal linux kernel configuration and have noticed a couple problems.  No matter what I do it seems that while cpu #2 is detected, nothing gets scheduled on it.  Also, there is always a modprobe process running at 100%cpu that I can't kill.  The command that is showed in top is "modprobe -s ac".  If I run it from the command line it hangs as well.  Latencies are however very acceptable when running xeno-test.  I do however see some negative values in the test output.

The config file that I am using currently is the same as the one below just with CONFIG_XENO_HW_SMI_ALL.  This seems to give me the best latencies.

Mike

 -------------- Original message ----------------------
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> xenomai@domain.hid wrote:
> >  -------------- Original message ----------------------
> > From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> > 
> >>xenomai@domain.hid wrote:
> >>
> >>>#
> >>># SMI workaround
> >>>#
> >>># CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
> >>>CONFIG_XENO_HW_SMI_DETECT=y
> >>>CONFIG_XENO_HW_SMI_WORKAROUND=y
> >>># CONFIG_XENO_HW_SMI_ALL is not set
> >>># CONFIG_XENO_HW_SMI_INTEL_USB2 is not set
> >>># CONFIG_XENO_HW_SMI_LEGACY_USB2 is not set
> >>># CONFIG_XENO_HW_SMI_PERIODIC is not set
> >>># CONFIG_XENO_HW_SMI_TCO is not set
> >>># CONFIG_XENO_HW_SMI_MC is not set
> >>>CONFIG_XENO_HW_SMI_APMC=y
> >>># CONFIG_XENO_HW_SMI_LEGACY_USB is not set
> >>>CONFIG_XENO_HW_SMI_BIOS=y
> >>
> >>Chances are that the latencies you get are due to the SMI you leave
> >>enabled (APMC or BIOS). Could you try first with only
> >>CONFIG_XENO_HW_SMI_ALL ?
> >>
> > WOW!!!  I did try that with the 2.6.17 kernel but it wouldnt boot,
> > I had to enable APM.  It is working like  charm now.  Max latency
> > is 4-5 us while running X.  If I drag a window around it goes up
> > to 7us or so.  Deffinately a step in the righ direction!  Thanks.
> 
> Good news.
> 
> -- 
>                                                  Gilles Chanteperdrix

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Jan Kiszka]

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

xenomai@domain.hid wrote:
> Hello,
> 
> I have been working on trying to find the optimal linux kernel
> configuration and have noticed a couple problems.  No matter what I
> do it seems that while cpu #2 is detected, nothing gets scheduled on

Sounds like some bug that was fixed in 2.3.1. Are you already using that
version? If not: highly recommended.

> it.  Also, there is always a modprobe process running at 100%cpu that
> I can't kill.  The command that is showed in top is "modprobe -s ac".

Probably due to SMI being disable. Don't know what that module precisely
does when it loops, but it may wait on SMI-backed activity of the
hardware that is now disabled. Try to switch off CONFIG_ACPI_AC in your
config.

> If I run it from the command line it hangs as well.  Latencies are
> however very acceptable when running xeno-test.  I do however see
> some negative values in the test output.
> 
> The config file that I am using currently is the same as the one
> below just with CONFIG_XENO_HW_SMI_ALL.  This seems to give me the
> best latencies.
> 
> Mike
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Philippe Gerum]

On Fri, 2007-03-23 at 14:04 +0000, xenomai@domain.hid wrote:
> Hello,
> 
> I have been working on trying to find the optimal linux kernel configuration and have noticed a couple problems.
> No matter what I do it seems that while cpu #2 is detected, nothing gets scheduled on it. 

If not already done, try building the Xenomai nucleus as a module
instead of statically into the kernel. Is the situation normal with
respect to load balancing between CPUs before you eventually modprobe
this module?

> Also, there is always a modprobe process running at 100%cpu that I can't kill.

modprobe of which module?

>   The command that is showed in top is "modprobe -s ac".  If I run it from the command line it hangs as well.
>   Latencies are however very acceptable when running xeno-test.  I do however see some negative values
>  in the test output.

Negative values are (mostly) ok. This only means that your machine is
faster than pre-calibrated for, which causes the timer shots to be ahead
of time, due to a pessimistic calibration.
Check /proc/xenomai/latency, this gives the intrinsic latency Xenomai
anticipates when programming timer shots (i.e. interrupt latency +
scheduling latency altogether), given as a count of nanoseconds.

You can change this value on the fly while the latency test is running;
just echo a new value to this file. You should try lowering it until all
the values (particularly the leftmost ones, i.e. "min lat") raise
slightly above zero.

> 
> The config file that I am using currently is the same as the one below just with CONFIG_XENO_HW_SMI_ALL.
>   This seems to give me the best latencies.
> 
> Mike
> 
>  -------------- Original message ----------------------
> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> > xenomai@domain.hid wrote:
> > >  -------------- Original message ----------------------
> > > From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> > > 
> > >>xenomai@domain.hid wrote:
> > >>
> > >>>#
> > >>># SMI workaround
> > >>>#
> > >>># CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
> > >>>CONFIG_XENO_HW_SMI_DETECT=y
> > >>>CONFIG_XENO_HW_SMI_WORKAROUND=y
> > >>># CONFIG_XENO_HW_SMI_ALL is not set
> > >>># CONFIG_XENO_HW_SMI_INTEL_USB2 is not set
> > >>># CONFIG_XENO_HW_SMI_LEGACY_USB2 is not set
> > >>># CONFIG_XENO_HW_SMI_PERIODIC is not set
> > >>># CONFIG_XENO_HW_SMI_TCO is not set
> > >>># CONFIG_XENO_HW_SMI_MC is not set
> > >>>CONFIG_XENO_HW_SMI_APMC=y
> > >>># CONFIG_XENO_HW_SMI_LEGACY_USB is not set
> > >>>CONFIG_XENO_HW_SMI_BIOS=y
> > >>
> > >>Chances are that the latencies you get are due to the SMI you leave
> > >>enabled (APMC or BIOS). Could you try first with only
> > >>CONFIG_XENO_HW_SMI_ALL ?
> > >>
> > > WOW!!!  I did try that with the 2.6.17 kernel but it wouldnt boot,
> > > I had to enable APM.  It is working like  charm now.  Max latency
> > > is 4-5 us while running X.  If I drag a window around it goes up
> > > to 7us or so.  Deffinately a step in the righ direction!  Thanks.
> > 
> > Good news.
> > 
> > -- 
> >                                                  Gilles Chanteperdrix
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

[Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[xenomai]

Hello,

Just to give you a little background, I am a software engineer with alot of experience in VxWorks.  I am currently investigating moving a large, high speed, data aquisition system from a multi single board computer, VME based system over to a PC with a PCI-Express expansion bus and create a portable slimmed down version.  While the time constraints I have are in the 10s of microseconds, I do have a need for consistency.  I have some experience with eCos but would like the bennefits that linux will offer.

I have a need for the same software work in various configurations in both a server configuration and a portable configuration.  The systems that I have are as follows :

Dell Precision M65 Laptop with 2.16ghz dual core processor
   4gb memory
  Nvidia Quadro FX350 Graphics
   SATA disk
   Configuration 1 :
        Docking station containing Pentek 7131 Digital Receiver
   Configuration 2:
        ExpressCard expansion chassis containing multiple Pentek 7131 Digial Receivers
                                 and IOTech 2100 Data Digital/Analog I/O cards
  
Dell Precision 690 with 2 Dual core 5160 3ghz Processors (Woodcrest)
  8gb memory
  Nvidia Quadro 4500 
  Multiple 15k SAS disks with both Perc5E and/or LSI Logic 8580E SAS Controller
  Multiple slot expansion chassis connected 8x to the server containing multiple cards

I have tried the RTAI approach with little success and have since switched to Xenomai with limited success.
I currently am using the 2.6.17 kernel due to no success with patching the .19 kernel.  When patching the .19 kernel for some reason the Real Time menu in the configuration contains only the APM/ACPI warning and no menu options  there were however no errors when patching.

For the 2.6.17 kernel installation was fairly smooth but with one hiccup.  For some reason, the patch did not add CONFIG_X86_TCS to the configuration.  I added it manually by editing /arch/i386/Kconfig and adding an entry for X86_TCS.  This allowed me to successfully run the tests supplied with the Xenomai distribution.

All the above has been done on the M65 Laptop which does have an ICH7 chipset.  I have tried both SMI enabled and disabled (ACPI SMI must remain enabled inorder for video to work) with no change in performance.  APM and CPU Freq scaling are disabled as well as ACPI Processor.  In this configuration the tests would run to completion but with disturbing results.  About ever 8-10 seconds the latency goes from somewhere between 1-50 micro seconds to over 700 microseconds.  (I'm assuming the output is in microseconds).  It continues this in a very predictable manner.  I have read the mailing list and have tried what others have recommended with no change at all.  (Shared memory is enabled).  Also, occasionally when I run the tests while running an X server it hard hangs the system.  I am not expecting the same type of problems to present themselves on my Server but I have a very large interest in getting a portable system working.

Are there any hard and fast configurations that I should try?  Is there a repository of .config files for differen kernel/hardware configurations?

Thanks in advance for your help.  If all goes well, I hope to return the favor to those who can bennefit from my experience.

Michael Freedman

Re: [Xenomai-help] New install of Xenomai 2.3 for 2.6.17 kernel.... Various problems

[Gilles Chanteperdrix]

xenomai@domain.hid wrote:
> Hello,
> 
> Just to give you a little background, I am a software engineer with alot of experience in VxWorks.  I am currently investigating moving a large, high speed, data aquisition system from a multi single board computer, VME based system over to a PC with a PCI-Express expansion bus and create a portable slimmed down version.  While the time constraints I have are in the 10s of microseconds, I do have a need for consistency.  I have some experience with eCos but would like the bennefits that linux will offer.
> 
> I have a need for the same software work in various configurations in both a server configuration and a portable configuration.  The systems that I have are as follows :
> 
> Dell Precision M65 Laptop with 2.16ghz dual core processor
>    4gb memory
>   Nvidia Quadro FX350 Graphics
>    SATA disk
>    Configuration 1 :
>         Docking station containing Pentek 7131 Digital Receiver
>    Configuration 2:
>         ExpressCard expansion chassis containing multiple Pentek 7131 Digial Receivers
>                                  and IOTech 2100 Data Digital/Analog I/O cards
>   
> Dell Precision 690 with 2 Dual core 5160 3ghz Processors (Woodcrest)
>   8gb memory
>   Nvidia Quadro 4500 
>   Multiple 15k SAS disks with both Perc5E and/or LSI Logic 8580E SAS Controller
>   Multiple slot expansion chassis connected 8x to the server containing multiple cards
> 
> I have tried the RTAI approach with little success and have since
> switched to Xenomai with limited success. I currently am using the
> 2.6.17 kernel due to no success with patching the .19 kernel.
> When patching the .19 kernel for some reason the Real Time menu in
> the configuration contains only the APM/ACPI warning and no menu
> options  there were however no errors when patching.

Could you send us the .config which leads to this situation ?

> For the 2.6.17 kernel installation was fairly smooth but with one
> hiccup.  For some reason, the patch did not add CONFIG_X86_TCS
> to the configuration.

I assume you are talking about the CONFIG_X86_TSC option. The reason why
CONFIG_X86_TSC is not set is usually that you are configuring the kernel
for a processor without tsc, for instance 486 or pentium.

Here again, sending your .config would help us.

> I added it manually by editing /arch/i386/Kconfig and adding an entry
> for X86_TCS.  This allowed me to successfully run the tests supplied
> with the Xenomai distribution.

No, you should not have to do this. The fact that you have to manually
modify arch/i386/Kconfig should ring a bell: you are doing something wrong.



> All the above has been done on the M65 Laptop which does have an
> ICH7 chipset.  I have tried both SMI enabled and disabled (ACPI
> SMI must remain enabled inorder for video to work) with no change
> in performance.  APM and CPU Freq scaling are disabled as well as
> ACPI Processor.  In this configuration the tests would run to
> completion but with disturbing results.  About ever 8-10 seconds
> the latency goes from somewhere between 1-50 micro seconds to over
> 700 microseconds.  (I'm assuming the output is in microseconds).
> It continues this in a very predictable manner.

This really looks like the TCO interrupt. Could you check that the SMI
workaround does not display a message "SMI workaround failed!" when
starting Xenomai nucleus?

> I have read the
> mailing list and have tried what others have recommended with no
> change at all.  (Shared memory is enabled).  Also, occasionally
> when I run the tests while running an X server it hard hangs the
> system.  I am not expecting the same type of problems to present
> themselves on my Server but I have a very large interest in
> getting a portable system working.

This is abnormal. Do your keyboard leds blink ?

> Are there any hard and fast configurations that I should try?
> Is there a repository of .config files for differen
> kernel/hardware configurations?
> 
> Thanks in advance for your help.  If all goes well, I hope to
> return the favor to those who can bennefit from my experience.

The configuration which should work for Xenomai configuration items is
the default configuration. If it does not work, then you came to the
right place.

-- 
                                                 Gilles Chanteperdrix