[Xenomai-help] RTDM interrupt programming practice

[Xenomai-help] RTDM interrupt programming practice

[vdkeybus]

I've programmed an RTDM PCI driver using interrupts. However, I've a 
few questions regarding the programming practices (especially because 
I'm not getting the performance I want). 

1. The PCI system assigns an interrupt 177 which is totally outside the 
range 0..15 I'm used to. Is it ok to pass this value to rtdm_irq_request
() ?

2. Is it obligatory to use a rtdm_toseq_t in rtdm_event_timedwait() and 
friends. Or, in other words, can I do rtdm_event_timedwait(&evt, 10000, 
NULL); ?

3. Currently, I register my ISR in the open() function. I unregister it 
in close(), after I've disabled the card's interrupt line. 
Nevertheless, I get a kernel message right after shutting down:

irq 177: nobody cared (try booting with the "irqpoll" option)
 [<c013a18f>] __report_bad_irq+0x24/0x7f
 [<c013a26a>] note_interrupt+0x62/0xb8
 [<c0139c70>] __do_IRQ+0xb7/0xc7
 [<c010511b>] do_IRQ+0x53/0x8b
 =======================
 [<c011c045>] profile_tick+0x20/0x49
 [<c0114908>] __ipipe_sync_stage+0xf1/0x13a
 [<c011490d>] __ipipe_sync_stage+0xf6/0x13a
 [<c0115187>] __ipipe_handle_irq+0x233/0x24c
 [<c010104a>] default_idle+0x30/0x3b
 [<c010101a>] default_idle+0x0/0x3b
 [<c0103b30>] common_interrupt+0x18/0x30
 [<c010101a>] default_idle+0x0/0x3b
 [<c010104a>] default_idle+0x30/0x3b
 [<c01010c2>] cpu_idle+0x3a/0x52
 [<c0327785>] start_kernel+0x179/0x1df
 [<c0327330>] unknown_bootoption+0x0/0x1b6
handlers:
[<f88ae638>] (snd_intel8x0_interrupt+0x0/0x23c [snd_intel8x0])
Disabling IRQ #177

After this message, it is impossible to reuse the interrupt line (after 
e.g. rmmod and insmod of driver and xeno_... modules) and the computer 
becomes very slow. Also note that I have traces of snd_intel8x0 
appearing in this context.

4. How can I verify the status of running xenomai processes (and the 
driver). I would like to find out why I'm not meeting my interrupt 
deadlines.

Thanks for any help,


Jeroen.


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Xenomai-help] RTDM interrupt programming practice

[Jan Kiszka]

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

vdkeybus wrote:
> I've programmed an RTDM PCI driver using interrupts. However, I've a 
> few questions regarding the programming practices (especially because 
> I'm not getting the performance I want). 
> 
> 1. The PCI system assigns an interrupt 177 which is totally outside the 
> range 0..15 I'm used to. Is it ok to pass this value to rtdm_irq_request
> () ?

Hmm, don't know if the underlying layers (Xenomai HAL, Ipipe patch) will
accept them. RTDM just forwards this value without looking further at
it. If the return code is Ok but it doesn't work, someone else has to
blamed. ;)

> 
> 2. Is it obligatory to use a rtdm_toseq_t in rtdm_event_timedwait() and 
> friends. Or, in other words, can I do rtdm_event_timedwait(&evt, 10000, 
> NULL); ?
> 

The latter is fine for most scenarios and will not cause oopses.

> 3. Currently, I register my ISR in the open() function. I unregister it 
> in close(), after I've disabled the card's interrupt line. 
> Nevertheless, I get a kernel message right after shutting down:
> 
> irq 177: nobody cared (try booting with the "irqpoll" option)
>  [<c013a18f>] __report_bad_irq+0x24/0x7f
>  [<c013a26a>] note_interrupt+0x62/0xb8
>  [<c0139c70>] __do_IRQ+0xb7/0xc7
>  [<c010511b>] do_IRQ+0x53/0x8b
>  =======================
>  [<c011c045>] profile_tick+0x20/0x49
>  [<c0114908>] __ipipe_sync_stage+0xf1/0x13a
>  [<c011490d>] __ipipe_sync_stage+0xf6/0x13a
>  [<c0115187>] __ipipe_handle_irq+0x233/0x24c
>  [<c010104a>] default_idle+0x30/0x3b
>  [<c010101a>] default_idle+0x0/0x3b
>  [<c0103b30>] common_interrupt+0x18/0x30
>  [<c010101a>] default_idle+0x0/0x3b
>  [<c010104a>] default_idle+0x30/0x3b
>  [<c01010c2>] cpu_idle+0x3a/0x52
>  [<c0327785>] start_kernel+0x179/0x1df
>  [<c0327330>] unknown_bootoption+0x0/0x1b6
> handlers:
> [<f88ae638>] (snd_intel8x0_interrupt+0x0/0x23c [snd_intel8x0])
> Disabling IRQ #177
> 
> After this message, it is impossible to reuse the interrupt line (after 
> e.g. rmmod and insmod of driver and xeno_... modules) and the computer 
> becomes very slow. Also note that I have traces of snd_intel8x0 
> appearing in this context.
> 

Did you also disabled it inside your PCI hardware? Someone seems to
continue producing IRQs. Anyway, calling rtdm_irq_disable should disable
the line and prevent such alarms. What does the return value of the
disable call says?

Hmm, is that IRQ line shared with non-RT hardware BTW? This is typically
a no-go for hard-RT scenarios. Already tried to disable that sound
interface (e.g. in the BIOS if on-chip)?

> 4. How can I verify the status of running xenomai processes (and the 
> driver). I would like to find out why I'm not meeting my interrupt 
> deadlines.

Ha, that would be a good job for the latency tracer I recently posted.
Put some ipipe_trace_begin() in the IRQ handler and an ipipe_trace_end()
in the driver before waking up the user application (or just
ipipe_trace_freeze() here could also help). With the pre- and
post-tracing feature you will also be able to see what happens before
and after that, e.g. if something delayed your IRQ handler.

I don't think Philippe has already rolled out some ipipe version with
the patch included, but you can start with the version I posted two days
ago as add-on to an existing Xeno-kernel. Feel free to ask me if things
do not work - this could be a first interesting test case in the field! :)

Jan

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

Re: [Xenomai-help] RTDM interrupt programming practice

[Philippe Gerum]

Jan Kiszka wrote:
> vdkeybus wrote:
> 
>>I've programmed an RTDM PCI driver using interrupts. However, I've a 
>>few questions regarding the programming practices (especially because 
>>I'm not getting the performance I want). 
>>
>>1. The PCI system assigns an interrupt 177 which is totally outside the 
>>range 0..15 I'm used to. Is it ok to pass this value to rtdm_irq_request
>>() ?

$ cat /proc/ipipe/Linux ?

> 
> 
> Hmm, don't know if the underlying layers (Xenomai HAL, Ipipe patch) will
> accept them.

Xeno will accept anything the I-pipe does accept. IRQ 177 means that the 
IO-APIC is enabled, and I would bet CONFIG_MSI is too. If there is no 
Linux handler for this interrupt, then the solution is to ask Xeno not 
to relay the IRQ down the pipeline to Linux when it sees it.

  RTDM just forwards this value without looking further at
> it. If the return code is Ok but it doesn't work, someone else has to
> blamed. ;)
> 
> 
>>2. Is it obligatory to use a rtdm_toseq_t in rtdm_event_timedwait() and 
>>friends. Or, in other words, can I do rtdm_event_timedwait(&evt, 10000, 
>>NULL); ?
>>
> 
> 
> The latter is fine for most scenarios and will not cause oopses.
> 
> 
>>3. Currently, I register my ISR in the open() function. I unregister it 
>>in close(), after I've disabled the card's interrupt line. 
>>Nevertheless, I get a kernel message right after shutting down:
>>
>>irq 177: nobody cared (try booting with the "irqpoll" option)
>> [<c013a18f>] __report_bad_irq+0x24/0x7f
>> [<c013a26a>] note_interrupt+0x62/0xb8
>> [<c0139c70>] __do_IRQ+0xb7/0xc7
>> [<c010511b>] do_IRQ+0x53/0x8b
>> =======================
>> [<c011c045>] profile_tick+0x20/0x49
>> [<c0114908>] __ipipe_sync_stage+0xf1/0x13a
>> [<c011490d>] __ipipe_sync_stage+0xf6/0x13a
>> [<c0115187>] __ipipe_handle_irq+0x233/0x24c
>> [<c010104a>] default_idle+0x30/0x3b
>> [<c010101a>] default_idle+0x0/0x3b
>> [<c0103b30>] common_interrupt+0x18/0x30
>> [<c010101a>] default_idle+0x0/0x3b
>> [<c010104a>] default_idle+0x30/0x3b
>> [<c01010c2>] cpu_idle+0x3a/0x52
>> [<c0327785>] start_kernel+0x179/0x1df
>> [<c0327330>] unknown_bootoption+0x0/0x1b6
>>handlers:
>>[<f88ae638>] (snd_intel8x0_interrupt+0x0/0x23c [snd_intel8x0])
>>Disabling IRQ #177
>>
>>After this message, it is impossible to reuse the interrupt line (after 
>>e.g. rmmod and insmod of driver and xeno_... modules) and the computer 
>>becomes very slow. Also note that I have traces of snd_intel8x0 
>>appearing in this context.
>>
> 
> 
> Did you also disabled it inside your PCI hardware? Someone seems to
> continue producing IRQs. Anyway, calling rtdm_irq_disable should disable
> the line and prevent such alarms. What does the return value of the
> disable call says?
> 
> Hmm, is that IRQ line shared with non-RT hardware BTW? This is typically
> a no-go for hard-RT scenarios. Already tried to disable that sound
> interface (e.g. in the BIOS if on-chip)?
> 
> 
>>4. How can I verify the status of running xenomai processes (and the 
>>driver). I would like to find out why I'm not meeting my interrupt 
>>deadlines.
> 

$ cat /proc/xenomai/sched
$ cat /proc/xenomai/stat

> 
> Ha, that would be a good job for the latency tracer I recently posted.
> Put some ipipe_trace_begin() in the IRQ handler and an ipipe_trace_end()
> in the driver before waking up the user application (or just
> ipipe_trace_freeze() here could also help). With the pre- and
> post-tracing feature you will also be able to see what happens before
> and after that, e.g. if something delayed your IRQ handler.
> 
> I don't think Philippe has already rolled out some ipipe version with
> the patch included, but you can start with the version I posted two days
> ago as add-on to an existing Xeno-kernel. Feel free to ask me if things
> do not work - this could be a first interesting test case in the field! :)
> 

I've just rolled out two patches, the first issue of the 1.1 series for 
x86, and the accompanying tracer patch. Apply them in that order:

http://download.gna.org/adeos/patches/v2.6/adeos/i386/adeos-ipipe-2.6.14-i386-1.1-00.patch
http://download.gna.org/adeos/patches/v2.6/adeos/i386/tracer/ipipe-tracer-2.6.14-i386-1.1-00.patch

The core patch does not include Dmitry's work on the shared IRQ issues 
yet, but -01 will.

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


-- 

Philippe.

Re: [Xenomai-help] RTDM interrupt programming practice

[vdkeybus]

Ok. I've applied the patches (kernel is now also 2.6.14-5).

1. I've also upgraded the kernel from 2.6.14 to 2.6.14-5, because 
Xenomai's make ...config was complaining about not finding 
CONFIG_IPIPE_EXTENDED after application of Adeos patch 1.1-00 to 
a 'vanilla' 2.6.14-5 Linux kernel. Eventually I added the CONFIG line 
myself, but I'm now consequently working with a newer kernel than the 
one in my previous report.

2. While compiling kernels (I'm still far from enjoying this 
activity...), I accidentally turned back on SMP (2 CPUs) with 
multithreading (SMT). Everything worked fine (as opposed to my first 
2.6.14 SMP venture some weeks ago, which gave tons of smp_processor_id
() bugwarnings and forced me to turn of SMP), but I was getting massive 
delays with ./latency (about 20 times normal values with lots of 
overruns). I turned SMP+SMT back off, and all values are normal again. 
Is this a known issue ? Or should I just not try to push things...

3. Three things concerning interrupt programming:

3a - I _did_ disable the card's interrupt lines, but I _forgot_ to 
enable interrupts with rtdm_irq_enable(). Nevertheless, I still _got_ 
the interrupts, until I placed the PCI card in a slot without interrupt 
sharing. BTW the return value of the rtdm_irq_request() and 
rtdm_irq_free() funtions was 0.

3b - Is it ok to return from the ISR with RTDM_IRQ_ENABLE if the 
interrupt is for the card and to return with RTDM_IRQ_PROPAGATE if it 
is not ? Should I logically OR them together ?

3c - ipipe_trace() indeed seems to be a very powerful tool for finding 
out the source of excessive latencies. Thanks for pointing it out.

4. What is the test one has to perform to 'load' a Linux machine and 
verify proper operation of Xenomai ? I've tried running 'latency' while 
my RT program is running, but it causes a missed deadline in my RT 
program and latency won't run.

5. While X is running, the computer becomes very sluggish during 
execution of an RT-program. I'm getting processing times of around 30 
us between interrupt generation and PCI register updates and a 
repetition rate of 100 us (all measured with a hardware timer on the 
PCI board). I'm wondering what could be the reason for this 
disproportional degradation of the user interface (it certainly doesn't 
seem the computer is only 30 % slower. Rather, it feels like 95 % and 
bringing up e.g. Firefox takes more than 30 s.).

> > Hmm, is that IRQ line shared with non-RT hardware BTW? This is
> typically
> > a no-go for hard-RT scenarios. Already tried to disable that sound
> > interface (e.g. in the BIOS if on-chip)?

It was. And in fact, it still is, because if I removed the sound in 
BIOS, it got replaced by USB. Touch the mouse in RT and...

> >>4. How can I verify the status of running xenomai processes (and
> the 
> >>driver). I would like to find out why I'm not meeting my interrupt
> >>deadlines.
> > 
> 
> $ cat /proc/xenomai/sched
> $ cat /proc/xenomai/stat

I could not find stat. (Xenomai 2.0.2) But sched also shows the status. 
I found the symbol explanations in thread.h.

Anyway, the system is now working at interrupt rates between 4,000 and 
20,000 per second. There is still an occasional overrun, which I'll try 
to trace with my new toy (ipipe_trace).

Thanks for all your help,


Jeroen.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Xenomai-help] RTDM interrupt programming practice

[Philippe Gerum]

vdkeybus wrote:
> Ok. I've applied the patches (kernel is now also 2.6.14-5).
> 
> 1. I've also upgraded the kernel from 2.6.14 to 2.6.14-5, because 
> Xenomai's make ...config was complaining about not finding 
> CONFIG_IPIPE_EXTENDED after application of Adeos patch 1.1-00 to 
> a 'vanilla' 2.6.14-5 Linux kernel. Eventually I added the CONFIG line 
> myself, but I'm now consequently working with a newer kernel than the 
> one in my previous report.

Which is wrong. Xeno 2.0.x is not expected to work with the Adeos 1.1 
series. The fact that it still does with -00 is pure luck, and won't be 
true anymore with the next 1.1 releases. You should stick with the 
patches available from arch/i386/patches which have been validated 
against the Xeno version that ships them, at least until you have a 
working configuration. I know that the tracer is a very desirable tool, 
but the workforce is not infinite here, and backporting every 
significant improvement to each Xenomai version on every platform is not 
possible.

> 
> 2. While compiling kernels (I'm still far from enjoying this 
> activity...), I accidentally turned back on SMP (2 CPUs) with 
> multithreading (SMT). Everything worked fine (as opposed to my first 
> 2.6.14 SMP venture some weeks ago, which gave tons of smp_processor_id
> () bugwarnings and forced me to turn of SMP), but I was getting massive 
> delays with ./latency (about 20 times normal values with lots of 
> overruns). I turned SMP+SMT back off, and all values are normal again. 
> Is this a known issue ? Or should I just not try to push things...
> 

It's hard to answer this until you explain which things you are trying 
to push... Xeno version? Adeos patch version? Kind of hw?

> 3. Three things concerning interrupt programming:
> 
> 3a - I _did_ disable the card's interrupt lines, but I _forgot_ to 
> enable interrupts with rtdm_irq_enable(). Nevertheless, I still _got_ 
> the interrupts, until I placed the PCI card in a slot without interrupt 
> sharing. BTW the return value of the rtdm_irq_request() and 
> rtdm_irq_free() funtions was 0.
> 

Linux was likely re-enabling the channel after the interrupt hit its 
pipeline stage.

> 3b - Is it ok to return from the ISR with RTDM_IRQ_ENABLE if the 
> interrupt is for the card and to return with RTDM_IRQ_PROPAGATE if it 
> is not ?

If Linux is not expected to care for the interrupt, yes.

  Should I logically OR them together ?
> 

You would relay interrupts Linux does not care for uselessly.

> 3c - ipipe_trace() indeed seems to be a very powerful tool for finding 
> out the source of excessive latencies. Thanks for pointing it out.
> 
> 4. What is the test one has to perform to 'load' a Linux machine and 
> verify proper operation of Xenomai ?

Resilience to cache trashing is a significant aspect; running the 
latency test + dd loop + some compilation in the background would be 
meaningful.

  I've tried running 'latency' while
> my RT program is running, but it causes a missed deadline in my RT 
> program and latency won't run.
> 

Did you look at the the code in latency.c? What it does very likely 
conflicts with what your program does wrt configuration and deadlines 
(timer setup, task priorities...).

> 5. While X is running, the computer becomes very sluggish during 
> execution of an RT-program. I'm getting processing times of around 30 
> us between interrupt generation and PCI register updates and a 
> repetition rate of 100 us (all measured with a hardware timer on the 
> PCI board). I'm wondering what could be the reason for this 
> disproportional degradation of the user interface (it certainly doesn't 
> seem the computer is only 30 % slower. Rather, it feels like 95 % and 
> bringing up e.g. Firefox takes more than 30 s.).
>

X acceleration often leads to surprising results, since nowadays graphic 
cards are not that RT friendly when they "optimize" things.

> 
>>>Hmm, is that IRQ line shared with non-RT hardware BTW? This is
>>
>>typically
>>
>>>a no-go for hard-RT scenarios. Already tried to disable that sound
>>>interface (e.g. in the BIOS if on-chip)?
> 
> 
> It was. And in fact, it still is, because if I removed the sound in 
> BIOS, it got replaced by USB. Touch the mouse in RT and...
> 
> 
>>>>4. How can I verify the status of running xenomai processes (and
>>
>>the 
>>
>>>>driver). I would like to find out why I'm not meeting my interrupt
>>>>deadlines.
>>>
>>$ cat /proc/xenomai/sched
>>$ cat /proc/xenomai/stat
> 

Stats requires the proper option to be selected in the Nucleus menu.

> 
> I could not find stat. (Xenomai 2.0.2) But sched also shows the status. 
> I found the symbol explanations in thread.h.
> 
> Anyway, the system is now working at interrupt rates between 4,000 and 
> 20,000 per second. There is still an occasional overrun, which I'll try 
> to trace with my new toy (ipipe_trace).
> 
> Thanks for all your help,
> 
> 
> Jeroen.
> 
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

RE: [Xenomai-help] RTDM interrupt programming practice

[Dominique.RAGOT]

Hello,

I can answer only to item 2.

Measurements were made on bi-Xeon PCs for SMP and SMP+SMT configurations, using kernel 2.6.13 and Xenomai 2.0. It showed that SMT has a negative impact on latency benchmark figures. Disabling SMT and keeping SMP brought latency figures back to nominal performance.

Hope this can help.

----------
Dominique RAGOT

> -----Message d'origine-----
> De : xenomai-help-bounces@domain.hid
> [mailto:xenomai-help-bounces@domain.hid la part de Philippe Gerum
> Envoyé : mardi 3 janvier 2006 10:27
> À : vdkeybus
> Cc : xenomai@xenomai.org
> Objet : Re: [Xenomai-help] RTDM interrupt programming practice
> 
> 
> vdkeybus wrote:
> > Ok. I've applied the patches (kernel is now also 2.6.14-5).
> > 
> > 1. I've also upgraded the kernel from 2.6.14 to 2.6.14-5, because 
> > Xenomai's make ...config was complaining about not finding 
> > CONFIG_IPIPE_EXTENDED after application of Adeos patch 1.1-00 to 
> > a 'vanilla' 2.6.14-5 Linux kernel. Eventually I added the 
> CONFIG line 
> > myself, but I'm now consequently working with a newer 
> kernel than the 
> > one in my previous report.
> 
> Which is wrong. Xeno 2.0.x is not expected to work with the Adeos 1.1 
> series. The fact that it still does with -00 is pure luck, 
> and won't be 
> true anymore with the next 1.1 releases. You should stick with the 
> patches available from arch/i386/patches which have been validated 
> against the Xeno version that ships them, at least until you have a 
> working configuration. I know that the tracer is a very 
> desirable tool, 
> but the workforce is not infinite here, and backporting every 
> significant improvement to each Xenomai version on every 
> platform is not 
> possible.
> 
> > 
> > 2. While compiling kernels (I'm still far from enjoying this 
> > activity...), I accidentally turned back on SMP (2 CPUs) with 
> > multithreading (SMT). Everything worked fine (as opposed to 
> my first 
> > 2.6.14 SMP venture some weeks ago, which gave tons of 
> smp_processor_id
> > () bugwarnings and forced me to turn of SMP), but I was 
> getting massive 
> > delays with ./latency (about 20 times normal values with lots of 
> > overruns). I turned SMP+SMT back off, and all values are 
> normal again. 
> > Is this a known issue ? Or should I just not try to push things...
> > 
> 
> It's hard to answer this until you explain which things you 
> are trying 
> to push... Xeno version? Adeos patch version? Kind of hw?
> 
> > 3. Three things concerning interrupt programming:
> > 
> > 3a - I _did_ disable the card's interrupt lines, but I _forgot_ to 
> > enable interrupts with rtdm_irq_enable(). Nevertheless, I 
> still _got_ 
> > the interrupts, until I placed the PCI card in a slot 
> without interrupt 
> > sharing. BTW the return value of the rtdm_irq_request() and 
> > rtdm_irq_free() funtions was 0.
> > 
> 
> Linux was likely re-enabling the channel after the interrupt hit its 
> pipeline stage.
> 
> > 3b - Is it ok to return from the ISR with RTDM_IRQ_ENABLE if the 
> > interrupt is for the card and to return with 
> RTDM_IRQ_PROPAGATE if it 
> > is not ?
> 
> If Linux is not expected to care for the interrupt, yes.
> 
>   Should I logically OR them together ?
> > 
> 
> You would relay interrupts Linux does not care for uselessly.
> 
> > 3c - ipipe_trace() indeed seems to be a very powerful tool 
> for finding 
> > out the source of excessive latencies. Thanks for pointing it out.
> > 
> > 4. What is the test one has to perform to 'load' a Linux 
> machine and 
> > verify proper operation of Xenomai ?
> 
> Resilience to cache trashing is a significant aspect; running the 
> latency test + dd loop + some compilation in the background would be 
> meaningful.
> 
>   I've tried running 'latency' while
> > my RT program is running, but it causes a missed deadline in my RT 
> > program and latency won't run.
> > 
> 
> Did you look at the the code in latency.c? What it does very likely 
> conflicts with what your program does wrt configuration and deadlines 
> (timer setup, task priorities...).
> 
> > 5. While X is running, the computer becomes very sluggish during 
> > execution of an RT-program. I'm getting processing times of 
> around 30 
> > us between interrupt generation and PCI register updates and a 
> > repetition rate of 100 us (all measured with a hardware 
> timer on the 
> > PCI board). I'm wondering what could be the reason for this 
> > disproportional degradation of the user interface (it 
> certainly doesn't 
> > seem the computer is only 30 % slower. Rather, it feels 
> like 95 % and 
> > bringing up e.g. Firefox takes more than 30 s.).
> >
> 
> X acceleration often leads to surprising results, since 
> nowadays graphic 
> cards are not that RT friendly when they "optimize" things.
> 
> > 
> >>>Hmm, is that IRQ line shared with non-RT hardware BTW? This is
> >>
> >>typically
> >>
> >>>a no-go for hard-RT scenarios. Already tried to disable that sound
> >>>interface (e.g. in the BIOS if on-chip)?
> > 
> > 
> > It was. And in fact, it still is, because if I removed the sound in 
> > BIOS, it got replaced by USB. Touch the mouse in RT and...
> > 
> > 
> >>>>4. How can I verify the status of running xenomai processes (and
> >>
> >>the 
> >>
> >>>>driver). I would like to find out why I'm not meeting my interrupt
> >>>>deadlines.
> >>>
> >>$ cat /proc/xenomai/sched
> >>$ cat /proc/xenomai/stat
> > 
> 
> Stats requires the proper option to be selected in the Nucleus menu.
> 
> > 
> > I could not find stat. (Xenomai 2.0.2) But sched also shows 
> the status. 
> > I found the symbol explanations in thread.h.
> > 
> > Anyway, the system is now working at interrupt rates 
> between 4,000 and 
> > 20,000 per second. There is still an occasional overrun, 
> which I'll try 
> > to trace with my new toy (ipipe_trace).
> > 
> > Thanks for all your help,
> > 
> > 
> > Jeroen.
> > 
> > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> > 
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> > 
> 
> 
> -- 
> 
> Philippe.
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>