>
>
>
> You need to compile with -fno-omit-frame-pointer, that is precisely the
> contrary of -fomit-frame-pointer
>
>
Indeed I had to, thank you very much. So for sake of completeness:
Variant 4 (works):
- ./configure --enable-x86-sep --enable-smp CFLAGS="-m32 -O2
-fno-omit-frame-pointer" LDFLAGS
I have patched a 2.6.38.8 kernel with the Adeos 2.10-01 patch. All Xenomai
2.5.6 built-in in the kernel. The system boots properly on an Atom D525:
> [0.510257] I-pipe: Domain Xenomai registered.
> [0.510493] Xenomai: hal/i386 started.
> [0.510626] Xenomai: scheduling class idle regis
>
> I'm sorry for replying late. my interrupt conflicts could be solved by
> using only one NIC or upgrade to Linux 2.6.23.9. Interestingly I
> noticed that the kernel 2.6.23.9 assigned different IRQ for each PCI
> device.
That's exactly what I meant by trying to have ACPI reorganize the interr
I want to create an RTDM driver that uses a thread (rtdm_task_t) to perform
a cyclic job. Although it's possible to start this thread (using
rtdm_task_init) from the module_init code, I'm unsure of how I should
terminate this thread.
I seem to have several options:
1. Just kill the thread with rt
yen wrote:
> > Most of the times the RTnet/Xenomai disabled the IRQ right away. few
> > time it ran for a while.
> > It doesn't matter the system has single or 2 cards, it still have
> > conflict IRQ. I tried to change the slot but it did not help.
> > Thank
>
> The Xenomai disabled the interrupt when it saw the sharing.
I may have mislooked, but doesn't xnintr_shirq_handler only disable the line
after XNINTR_MAX_UNHANDLED problematic IRQs (which is by default set to
1000) ? If you get the error immediately after loading the driver, it looks
like eit
>
> Yes, I have problem with sharing the IRQ 11.
> my questions are:
> How can I set the rteth0 to a known not sharing IRQ in the system?
- You already said you don't have BIOS options.
- If you have multiple PCI slots, try swapping the cards. Usually, adjacent
slots have different interrupt line
Debugging tools also suggested 'normal' pagefaults. Made me look for the mlockall() call which turns out to be unsuccessful. I made a mistake in evaluating its (non-zero) return value, which caused the error to go by unnoticed.
The reason mlockall() fails is that I executed the real-time program
Maybe not all of your user memory is cleanly locked and got swapped out(swapping activated?). If you don't see kernel oopses and your programs
don't receive segfaults, these faults are references to swapped out ornot yet mapped in pages. BTW, what does the kernel console tell you?
I have a mlock
I'm observing a considerable amount of Page Faults (5090 after an hour or so), each one associated with a MSW increase in /proc/xenomai/stat. I'm missing RT deadlines on those occasions and I want to fix it, so I would like to know what Page Faults actually are.
Jeroen.
___
Have you tried loading the Celeron to 100% as well ? Remember that, depending on where your interface resides, inb/outb access to the PCI bus or, even worse, the LPC, may be stalled by heavy traffic on the CPU front-end bus or the MCH-ICH link.
Just giving you all a heads up. The geode sucks an
Indeed. Thanks and sorry for bothering.
Jeroen.
The dev_private data field of an rtdm_dev_context is defined as
char[0]. How do I access such a field properly (given the fact that I
defined a nonzero context_size in the rtdm_device structure during
driver registration) ?
E.g. trying to do:
(struct my_struct *)context->dev_private = NULL;
resu
Indeed. Thanks and sorry for bothering.
Jeroen.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
The dev_private data field of an rtdm_dev_context is defined as
char[0]. How do I access such a field properly (given the fact that I
defined a nonzero context_size in the rtdm_device structure during
driver registration) ?
E.g. trying to do:
(struct my_struct *)context->dev_private = NULL;
resu
It would be helpful if a complete code could be posted. That means, including the main() function, in which the task dispatching is done as well.
Furthermore, be sure to declare counting variables inside waiting loops with the 'volatile' specifier. The compiler might optimize it away otherwise.
It would be helpful if a complete code could be posted. That means, including the main() function, in which the task dispatching is done as well.
Furthermore, be sure to declare counting variables inside waiting loops with the 'volatile' specifier. The compiler might optimize it away otherwise.
My distro is FC3 with linux-2.6.9. I'm trying to get the SMP version of2.6.13 running with Xenomai.
Why not use 2.6.15 immediately ?
Test #2==I used the single CPU kernel config to build the adeos-patched 2.6.13kernel. This boots and xeno latency runs fine. I had a problem with
`mak
My distro is FC3 with linux-2.6.9. I'm trying to get the SMP version of2.6.13 running with Xenomai.
Why not use 2.6.15 immediately ?
Test #2==I used the single CPU kernel config to build the adeos-patched 2.6.13kernel. This boots and xeno latency runs fine. I had a problem with
`mak
Jan,
Can't you start it with a short Linux user-space app upon startup ? Doesn't even need to go realtime.
I'm planning to try this as I want to start two unrelated Xenomai processes which need the timer for timeouts (obviously in a perpetual effort to test the Xenomai kernel ;-))
Jeroen.
Jan,
Can't you start it with a short Linux user-space app upon startup ? Doesn't even need to go realtime.
I'm planning to try this as I want to start two unrelated Xenomai processes which need the timer for timeouts (obviously in a perpetual effort to test the Xenomai kernel ;-))
Jeroen.
I'm confused. Did you really mean TM_NONBLOCK?Am I missing something?
I think you have to read it like this:
Bind to a shared heap which has been created elsewhere, either in kernel or user-space. The call will block us until such heap is created with the expected name.
I'm confused. Did you really mean TM_NONBLOCK?Am I missing something?
I think you have to read it like this:
Bind to a shared heap which has been created elsewhere, either in kernel or user-space. The call will block us until such heap is created with the expected name.
Gilles, Jan,
The offending program is quite complex (several .c files and a considerable .h file tree) and involves 2 computers. However, I think I can narrow down the problem to concurrent access (from 2 Xenomai threads in 2nd domain) to the same Linux file descriptor for a TCP/IP connection.
Gilles, Jan,
The offending program is quite complex (several .c files and a considerable .h file tree) and involves 2 computers. However, I think I can narrow down the problem to concurrent access (from 2 Xenomai threads in 2nd domain) to the same Linux file descriptor for a TCP/IP connection.
I got a fair number of 'scheduling while atomic' entries in the dmesg log after running a multithread Xenomai program. What do they mean ?
Jeroen.
I got a fair number of 'scheduling while atomic' entries in the dmesg log after running a multithread Xenomai program. What do they mean ?
Jeroen.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
27 matches
Mail list logo
