Re: [Xenomai-core] [PATCH] shared irqs v.3

2006-01-18 Thread Dmitry Adamushko
Hi Jan, As lighter may mean that reducing the structure size also reduces the number of used cache lines, it might be a good idea. The additional complexity for entry removal is negligible. My current working version is already lighter when it comes to the size of additional data

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
When testing, also check the dmesg logs please. When nucleus debugging is off, you get only a kernel warning 'scheduling while atomic'. - Could you replace MAXLONG on line 119 with TM_INFINITE and rerun the sem test (to avoid printf'ing) You can terminate with Ctrl+C. - Could you try to run with

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
# ./sem 1.0e5Running for 2.15 seconds.L119: Operation not permitted. Could be a dirty cleanup. Sorry for that. ...ipipe_supend_domain...default_idle...cpu_idle...start_kernel...unknown_bootoptionKernel panic start_kernel ? Unknown_bootoption ? The plot is thickening. # ./mutex 1.0e5ALERT: No

[Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Hm. When I remove the output() from both tasks, all seems fine. Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Hold on. Just crashed without the file access: please disregard last post. Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Gilles, I cannot reproduce those messages after turning nucleus debugging on. Instead, I now either get relatively more failing mutexes oreven hard lockups with the test program I sent to you. If thecomputer didn't crash, dmesg contains 3 Xenomai messages relating to a task being movend to

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Gilles Chanteperdrix
Jeroen Van den Keybus wrote: Gilles, I cannot reproduce those messages after turning nucleus debugging on. Instead, I now either get relatively more failing mutexes or even hard lockups with the test program I sent to you. If the computer didn't crash, dmesg contains 3 Xenomai

Re: [Xenomai-core] [PATCH] shared irqs v.3

2006-01-18 Thread Dmitry Adamushko
Hi Jan, As lighter may mean that reducing the structure size also reduces the number of used cache lines, it might be a good idea. The additional complexity for entry removal is negligible. My current working version is already lighter when it comes to the size of additional data

[Xenomai-core] Missing IRQ end function on PowerPC

2006-01-18 Thread Wolfgang Grandegger
Hello, with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai does not distinguish between a normal IRQ enable and an IRQ unmask at the end of an ISR (to reenable the IRQ). In the latter case the IRQ should be enabled on PowerPC as shown: if

[Xenomai-core] Initialization of a nucleus pod

2006-01-18 Thread Germain Olivier
Hello I am trying to understand how a pod is initialized. I think it start with xncore_attach() from core.c, then with xnpod_init from pod.c But here (in xnpod_init) there is something not clear about the root thread creation. It use xnthread_init(sched-rootcb, ...), but I don't see where

[Xenomai-core] [PATCH] Shared irqs v.5

2006-01-18 Thread Dmitry Adamushko
Hello Jan, as I promised earlier today, here is the patch. hehe.. more comments later together with other explanations I promised. I have to go now since I have to make a trip and my bus is leaving in 45 minutes :) -- Best regards,Dmitry Adamushko shirq-v4.patch Description: Binary data

[Xenomai-core] Re: --enable-linux-build

2006-01-18 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Gilles, I just tested your new build option. Maybe I'm using it the wrong way, but I stumbled over two quirks: o make install-nodev fails as it tries to install the kernel without being root. Actually, I only wanted to

[Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Hello, Apparently, the code I shared with Gilles never made it to this forum. Anyway, the issue I'm having here is really a problem and it might be useful if some of you could try it out or comment on it. I might be making a silly programming error here, but the result is invariably erroneous

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jan Kiszka
Jan Kiszka wrote: ... [Update] While writing this mail and letting your test run for a while, I *did* get a hard lock-up. Hold on, digging deeper... And here are its last words, spoken via serial console: c31dfab0 0086 c30d1a90 c02a2500 c482a360 0001 0001 0020

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jan Kiszka
Jan Kiszka wrote: Jan Kiszka wrote: ... [Update] While writing this mail and letting your test run for a while, I *did* get a hard lock-up. Hold on, digging deeper... And here are its last words, spoken via serial console: c31dfab0 0086 c30d1a90 c02a2500 c482a360 0001 0001

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Jeroen Van den Keybus wrote: Gilles, I cannot reproduce those messages after turning nucleus debugging on. Instead, I now either get relatively more failing mutexes or even hard lockups with the test program I sent to you.

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Interesting, when writing to 2 different files, I get the same crashes. Will test with only one task/fd. In fact, my last crash report did contain a difference with yours: ROOT task was at priority 0 main was at 1 task0 was at 30 timeout 3.7ms task1 was at 29 timeout 4.9 ms Does this mean

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jan Kiszka
Hannes Mayer wrote: Jeroen Van den Keybus wrote: Hello, Apparently, the code I shared with Gilles never made it to this forum. Anyway, the issue I'm having here is really a problem and it might be useful if some of you could try it out or comment on it. If you have a makefile for

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jan Kiszka
Jeroen Van den Keybus wrote: Interesting, when writing to 2 different files, I get the same crashes. Will test with only one task/fd. File ops doesn't matter for me. I took them out of task0/1, and I still got the crashes. (BTW, this may explain the difference in your backtrace you reported

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Hannes Mayer
Jan Kiszka wrote: [...] Do you (or anybody else) have a running 2.0.x installation? If so, please test that setup as well. Sure :-) # uname -r 2.6.13.4-adeos-xenomai # cat /proc/xenomai/version 2.0 # ./mutex Running for 2.15 seconds. ALERT: No lock! (lockcnt=0) Offending task: task0 ALERT: No

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
Hm. When I remove the output() from both tasks, all seems fine. Jeroen.

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Hannes Mayer
Jeroen Van den Keybus wrote: - Could you replace MAXLONG on line 119 with TM_INFINITE and rerun the sem test (to avoid printf'ing) You can terminate with Ctrl+C. - Could you try to run with tmax somewhat lower (to increase the load): e.g. ./sem 5.0e6 or so. Be careful not to starve Linux. I

Re: [Xenomai-core] Scheduling while atomic

2006-01-18 Thread Jeroen Van den Keybus
When testing, also check the dmesg logs please. When nucleus debugging is off, you get only a kernel warning 'scheduling while atomic'. - Could you replace MAXLONG on line 119 with TM_INFINITE and rerun the sem test (to avoid printf'ing) You can terminate with Ctrl+C. - Could you try to run with