[Xenomai-help] Interrupt shield

[Xenomai-help] Interrupt shield

[Sebastian Smolorz]

Hello,

can anybody confirm this behaviour? If I configure the I-shield into the 
kernel and start the latency test the RT tasks have not activated T_SHIELD 
although the documentation states it (and btw in rt_task_create this bit is 
set). If I try to set T_SHIELD inside the display task, the system hangs, a 
soft lockup appears and sometimes a few correct lines of the display task are 
printed, followed by the next lockup.

Explainable?

I'm testing on ARM with my S3C24xx I-pipe patch.

--
Sebastian

Re: [Xenomai-help] Interrupt shield

[Jan Kiszka]

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

Sebastian Smolorz wrote:
> Hello,
> 
> can anybody confirm this behaviour? If I configure the I-shield into the 
> kernel and start the latency test the RT tasks have not activated T_SHIELD 
> although the documentation states it (and btw in rt_task_create this bit is 
> set). If I try to set T_SHIELD inside the display task, the system hangs, a 
> soft lockup appears and sometimes a few correct lines of the display task are 
> printed, followed by the next lockup.
> 
> Explainable?
> 
> I'm testing on ARM with my S3C24xx I-pipe patch.

Have you tried over x86, too? The shield used to be off by default for
quite some time, and it's a fairly special feature. I wouldn't be
surprised if there is some regression sleeping. But it might also be an
ARM-specific issue.

Soft lockup sounds like the shield is not released appropriately again.
The tracer would visualise this nicely in verbose mode...

Jan


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

Re: [Xenomai-help] Interrupt shield

[Sebastian Smolorz]

Jan Kiszka wrote:
> Sebastian Smolorz wrote:
> > Hello,
> >
> > can anybody confirm this behaviour? If I configure the I-shield into the
> > kernel and start the latency test the RT tasks have not activated
> > T_SHIELD although the documentation states it (and btw in rt_task_create
> > this bit is set). If I try to set T_SHIELD inside the display task, the
> > system hangs, a soft lockup appears and sometimes a few correct lines of
> > the display task are printed, followed by the next lockup.
> >
> > Explainable?
> >
> > I'm testing on ARM with my S3C24xx I-pipe patch.
>
> Have you tried over x86, too?

No, but I'm considering it.

> The shield used to be off by default for 
> quite some time, and it's a fairly special feature. I wouldn't be
> surprised if there is some regression sleeping. But it might also be an 
> ARM-specific issue.
>
> Soft lockup sounds like the shield is not released appropriately again.
> The tracer would visualise this nicely in verbose mode...

Yes, I was thinking the same. So now there are two good arguments to learn 
some assembler for ARM ... ;-)

--
Sebastian

Re: [Xenomai-help] Interrupt shield

[Philippe Gerum]

On Thu, 2006-11-16 at 10:57 +0100, Sebastian Smolorz wrote:
> Hello,
> 
> can anybody confirm this behaviour? If I configure the I-shield into the 
> kernel and start the latency test the RT tasks have not activated T_SHIELD 
> although the documentation states it (and btw in rt_task_create this bit is 
> set).

The documentation of rt_task_create() is wrong. The default behaviour
should be to create tasks with disabled I-shield support.

>  If I try to set T_SHIELD inside the display task, the system hangs, a 
> soft lockup appears and sometimes a few correct lines of the display task are 
> printed, followed by the next lockup.

Confirmed here (on x86).

> 
> Explainable?
> 

Yes. I must have screwed up something somewhere, many moons ago.

> I'm testing on ARM with my S3C24xx I-pipe patch.
> 

The I-shield does not depend on any arch-specific code; it's purely
based on a few generic Adeos services making use of the pipeline
abstraction. Will fix.

> --
> Sebastian
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Interrupt shield

[Philippe Gerum]

On Thu, 2006-11-16 at 22:32 +0100, Philippe Gerum wrote:
> On Thu, 2006-11-16 at 10:57 +0100, Sebastian Smolorz wrote:
> > Hello,
> > 
> > can anybody confirm this behaviour? If I configure the I-shield into the 
> > kernel and start the latency test the RT tasks have not activated T_SHIELD 
> > although the documentation states it (and btw in rt_task_create this bit is 
> > set).
> 
> The documentation of rt_task_create() is wrong. The default behaviour
> should be to create tasks with disabled I-shield support.
> 
> >  If I try to set T_SHIELD inside the display task, the system hangs, a 
> > soft lockup appears and sometimes a few correct lines of the display task are 
> > printed, followed by the next lockup.
> 
> Confirmed here (on x86).
> 
> > 
> > Explainable?
> > 
> 
> Yes. I must have screwed up something somewhere, many moons ago.
> 

Yes I did. This patch should fix the issue on your setup too.

--- ksrc/nucleus/shadow.c	(revision 1838)
+++ ksrc/nucleus/shadow.c	(working copy)
@@ -554,6 +554,9 @@
 #ifndef CONFIG_XENO_OPT_RPIDISABLE
 			xnpod_renice_root(XNPOD_ROOT_PRIO_BASE);
 #endif /* CONFIG_XENO_OPT_RPIDISABLE */
+#ifdef CONFIG_XENO_OPT_ISHIELD
+			disengage_irq_shield();
+#endif /* CONFIG_XENO_OPT_ISHIELD */
 			xnpod_schedule();
 		}
 
-- 
Philippe.

Re: [Xenomai-help] Interrupt shield

[Sebastian Smolorz]

Philippe Gerum wrote:
> On Thu, 2006-11-16 at 22:32 +0100, Philippe Gerum wrote:
> > On Thu, 2006-11-16 at 10:57 +0100, Sebastian Smolorz wrote:
> > > Hello,
> > >
> > > can anybody confirm this behaviour? If I configure the I-shield into
> > > the kernel and start the latency test the RT tasks have not activated
> > > T_SHIELD although the documentation states it (and btw in
> > > rt_task_create this bit is set).
> >
> > The documentation of rt_task_create() is wrong. The default behaviour
> > should be to create tasks with disabled I-shield support.
> >
> > >  If I try to set T_SHIELD inside the display task, the system hangs, a
> > > soft lockup appears and sometimes a few correct lines of the display
> > > task are printed, followed by the next lockup.
> >
> > Confirmed here (on x86).
> >
> > > Explainable?
> >
> > Yes. I must have screwed up something somewhere, many moons ago.
>
> Yes I did. This patch should fix the issue on your setup too.

Yes, it is working now. Thank you!

--
Sebastian

[Xenomai-help] Interrupt Shield

[smannori]

Hi everybody:

I installed xenomai 2.1 on a little Celeron M laptop with SiS chipset

00:00.0 Host bridge: Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX
Host (rev 11)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS]: Unknown device 0003
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media
IO] (rev 25)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller
(rev a0)00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound
Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller
(rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller
(rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI
Fast Ethernet (rev 90)
00:09.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
00:09.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
00:09.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller
(rev 04)00:0e.0 Network controller: Intersil Corporation ISL3886 [Prism
Javelin/Prism Xbow] (rev 01)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS]
661FX/M661FX/M661MX/741/M741/760/M760 PCI/AGP

I left the SMI detection active, but I don't have warning message because
SiS does NOT use SMI interrupt. As I know, everything works ok.

I want to use a little USB data acquisition board USB-1208FS because some
brave soul ( Warren J. Jasper ) has developed a generi linux library for
this card.

This board is garantee to reach 250 S/s. On my PC, without Xenomai, the
maximum free-running speed is 330 S/s.

My idea is to use a real time xenomai task to pace the data acquisition. As
demo, I decided to generate a square wave with the internal DAC and hear the
results on a little piezoelectric speaker. it's sound good :).

To sh


Now the problems:

1) If I push the sample rate above 50 S/s (