Re: [Xenomai-core] SMI update
On Thursday 10 August 2006 00:44, Jan Kiszka wrote: Thanks for the patch, we just need some additional define of PCI_DEVICE_ID_INTEL_ICH7_0 for kernel 2.4 compatibility. And if you additionally provide a ChangeLog fragment, your patch would be perfect! (I tend to forget the last part often too... :) ) Where to add the new define for kernel 2.4 ? Ulrich -- inmess GmbH Frankfurter Str. 74 D - 64521 Gross-Gerau Phone: +49 6152 97790 Fax : +49 6152 977920 mail : [EMAIL PROTECTED] web: www.inmess.de ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [Xenomai-help] -110 error on rt_task_send... bug?
Hi Dmitry,
some comments on the patch, but I still haven't run it. The basic idea
is sane, but we have to wait for Philippe's comments of course.
Ulrich Schwab wrote:
On Wednesday 09 August 2006 13:42, Dmitry Adamushko wrote:
So could anyone test this patch and let me know if it works?
Note : I haven't compiled it even as I don't have a proper environment. But
the changes are pretty simple so it should be ok.
I just did run the test program supplied by Vincent after applying Your patch
(against 2.2.0)
It did work !
Only one small typo was in the patch, it is fixed in the attached patch
version.
There was actually yet another problem mmm... who cares to delete a sender
from the msendq?
Now should be ok or maybe I'm completely wrong and see the things which do
not exist at all :)
p.s. I cc'ed xenomai-core as it may involve further discussions and it's
the right place indeed.
diff -urp xenomai-a/include/nucleus/synch.h xenomai-b/include/nucleus/synch.h
--- xenomai-a/include/nucleus/synch.h 2006-07-20 11:09:01.0 +0200
+++ xenomai-b/include/nucleus/synch.h 2006-08-09 12:53:37.044217000 +0200
@@ -28,6 +28,7 @@
#define XNSYNCH_NOPIP 0x0
#define XNSYNCH_PIP 0x2
#define XNSYNCH_DREORD 0x4
+#define XNSYNCH_FOWNER 0x20/* Fixed owner */
#if defined(__KERNEL__) || defined(__XENO_SIM__)
diff -urp xenomai-a/ksrc/nucleus/synch.c xenomai-b/ksrc/nucleus/synch.c
--- xenomai-a/ksrc/nucleus/synch.c2006-06-15 14:15:25.0 +0200
+++ xenomai-b/ksrc/nucleus/synch.c2006-08-09 13:28:55.199081000 +0200
@@ -37,6 +37,14 @@
#include nucleus/module.h
#include nucleus/ltt.h
+/* temporarily here */
+static inline void xnsynch_set_owner_internal(xnsynch_t *synch, xnthread_t
*thread)
+{
+ if (!testbits(synch-status, XNSYNCH_FOWNER))
+ synch-owner = thread;
+}
+
+
I don't think we should use this inline function after the changes I'm
suggesting below. There will be too many exceptions from this pattern,
and the code is more readable with this unrolled.
/*!
* \fn void xnsynch_init(xnsynch_t *synch, xnflags_t flags);
* \brief Initialize a synchronization object.
@@ -181,7 +189,7 @@ void xnsynch_sleep_on(xnsynch_t *synch,
if (testbits(synch-status, XNSYNCH_PENDING)) {
/* Ownership is still pending, steal
the resource. */
- synch-owner = thread;
+ xnsynch_set_owner_internal(synch,
thread);
__clrbits(thread-status,
XNRMID | XNTIMEO | XNBREAK);
goto grab_ownership;
Mmm, given the fixed ownership, should we ever enter this code path
under XNSYNCH_FOWNER? Is there a scenario with XNSYNCH_FOWNER |
XNSYNCH_PENDING? If yes, I would say: fix that one. Then the change
above is no longer required.
@@ -209,7 +217,7 @@ void xnsynch_sleep_on(xnsynch_t *synch,
xnpod_suspend_thread(thread, XNPEND, timeout, synch);
- if (unlikely(synch-owner != thread)) {
+ if (!testbits(synch-status, XNSYNCH_FOWNER)
unlikely(synch-owner != thread)) {
/* Somebody stole us the ownership while we
were ready to
run, waiting for the CPU: we need to wait
again for the
resource. */
(synch-owner != thread) is more likely to be unlikely ;). I would
reorder it, i.e. put the owner check to the front again.
@@ -362,12 +370,12 @@ xnthread_t *xnsynch_wakeup_one_sleeper(x
if (holder) {
thread = link2thread(holder, plink);
thread-wchan = NULL;
- synch-owner = thread;
+ xnsynch_set_owner_internal(synch, thread);
__setbits(synch-status, XNSYNCH_PENDING);
Here we are: I think we shouldn't set XNSYNCH_PENDING if XNSYNCH_FOWNER
is set.
xnltt_log_event(xeno_ev_wakeup1, thread-name, synch);
xnpod_resume_thread(thread, XNPEND);
} else {
- synch-owner = NULL;
+ xnsynch_set_owner_internal(synch, thread);
__clrbits(synch-status, XNSYNCH_PENDING);
}
@@ -435,7 +443,7 @@ xnpholder_t *xnsynch_wakeup_this_sleeper
nholder = poppq(synch-pendq, holder);
thread = link2thread(holder, plink);
thread-wchan = NULL;
- synch-owner = thread;
+ xnsynch_set_owner_internal(synch, thread);
__setbits(synch-status, XNSYNCH_PENDING);
...and here again.
xnltt_log_event(xeno_ev_wakeupx, thread-name, synch);
xnpod_resume_thread(thread, XNPEND);
@@ -523,7 +531,7 @@ int xnsynch_flush(xnsynch_t *synch, xnfl
status = XNSYNCH_RESCHED;
Re: [Xenomai-core] SMI update
Ulrich Schwab wrote:
On Thursday 10 August 2006 00:44, Jan Kiszka wrote:
Thanks for the patch, we just need some additional define of
PCI_DEVICE_ID_INTEL_ICH7_0 for kernel 2.4 compatibility. And if you
additionally provide a ChangeLog fragment, your patch would be perfect!
(I tend to forget the last part often too... :) )
Where to add the new define for kernel 2.4 ?
I would say to smi.c directly as there are no other users in sight.
Otherwise, wrapping code goes to include/asm-{generic|arch}/wrapper.h.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] SMI update
On Thursday 10 August 2006 10:27, Jan Kiszka wrote:
Ulrich Schwab wrote:
On Thursday 10 August 2006 00:44, Jan Kiszka wrote:
Thanks for the patch, we just need some additional define of
PCI_DEVICE_ID_INTEL_ICH7_0 for kernel 2.4 compatibility. And if you
additionally provide a ChangeLog fragment, your patch would be perfect!
(I tend to forget the last part often too... :) )
Where to add the new define for kernel 2.4 ?
I would say to smi.c directly as there are no other users in sight.
Otherwise, wrapping code goes to include/asm-{generic|arch}/wrapper.h.
I did add the new Id to smi.c directly now.
Ulrich
--
inmess GmbH
Frankfurter Str. 74
D - 64521 Gross-Gerau
Phone: +49 6152 97790
Fax : +49 6152 977920
mail : [EMAIL PROTECTED]
web: www.inmess.de
diff -urp xenomai-2.2.0-org/ChangeLog xenomai-2.2.0-patched/ChangeLog
--- xenomai-2.2.0-org/ChangeLog 2006-07-17 18:50:17.0 +0200
+++ xenomai-2.2.0-patched/ChangeLog 2006-08-10 14:51:28.0 +0200
@@ -1,3 +1,7 @@
+2006-08-10 Ulrich Schwab [EMAIL PROTECTED]
+
+ * ksrc/arch/i386/smi.c added id of Intel ICH7 to list of SMI chipsets
+
2006-07-17 Philippe Gerum [EMAIL PROTECTED]
* RELEASE: Xenomai 2.2 (Engines Of Creation)
diff -urp xenomai-2.2.0-org/ksrc/arch/i386/smi.c xenomai-2.2.0-patched/ksrc/arch/i386/smi.c
--- xenomai-2.2.0-org/ksrc/arch/i386/smi.c 2006-07-03 08:44:33.0 +0200
+++ xenomai-2.2.0-patched/ksrc/arch/i386/smi.c 2006-08-10 14:50:37.0 +0200
@@ -31,6 +31,13 @@
#include linux/reboot.h
#include asm/xenomai/smi.h
+/* DEVICE_IDs needed for 2.4 support */
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0)
+#ifndef PCI_DEVICE_ID_INTEL_ICH7_0
+#define PCI_DEVICE_ID_INTEL_ICH7_0 0x27b8
+#endif
+#endif
+
static struct pci_device_id rthal_smi_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_0) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_0) },
@@ -45,6 +52,7 @@ static struct pci_device_id rthal_smi_pc
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_2) },
+{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0) },
{ 0, },
};
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE
That looks like a correct behaviour to me: the kernel module is trying to read from pipe1 (MyPipe0, /dev/rtp0) and is blocked on it. The user-space tool tries to do the same (is this intended BTW?). Then the user-space program gets terminate, thus pipe1 is cleaned up. During that cleanup all RT-readers on the pipe are woken up with -EINTR as return code [1]. Hi Jan, Thanks for your reply. Indeed, I was on a wrong track: [CTRL-C] closed the application and also the pipes, thus sending this INTR signal to the kernel module. BTW, is there a limit to the size of a message one can send in a pipe. Could this limit be around 65535 ? I'm porting a RTAI application to xenomai and I am still hunting a bug on a pipe. Writing on the user side more than 65530 bytes on a pipe yields a Cannot allocate memory perror message. Thanks a lot for your hints, Jacques ___ Prof. Jacques GANGLOFF Strasbourg I University LSIIT Laboratory, EAVR team Bd S. Brant BP 10413, 67412 ILLKIRCH cedex, FRANCE Tel : +33 (0)3 90 24 44 68 Fax : +33 (0)3 90 24 44 80 http://eavr.u-strasbg.fr ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE
Hello,
take a look at the 4-th parameter of rt_pipe_create() :
@param poolsize Specifies the size of a dedicated buffer pool for the
* pipe. Passing 0 means that all message allocations for this pipe are
* performed on the system heap.
The system heap is also used for other allocations and not only to
serve a given heap. It's default size is 128 Kb (configurable through
the config though).
Passing non-zero parameter causes a private heap of the given size to be created for this heap.
Note, it's a size in bytes, not a flag (in your example you use 1 for the second heap).
This value is rounded up to a page size.
rt_pipe_create()
{
...
if (poolsize 2 * PAGE_SIZE)
poolsize = 2 * PAGE_SIZE;
poolsize = xnheap_rounded_size(poolsize, PAGE_SIZE);
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [Xenomai-help] -110 error on rt_task_send... bug?
The patch works here too. Thanks for looking into this so quickly. I'llswitch back to 2.1 until this is resolved. It's also broken in 2.1. There are 2 problems there not releted to recently introduced ownership-stealing part. That said, you may safely (well, you remember this WITHOUT ANY WARRANTY... but indeed :) apply this patch so far if you really need synch. message passing mechanism. -- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] expected output and runtime of switchtest ?
Jan Kiszka wrote: Jim Cromie wrote: soekris:/usr/xenomai/testsuite/switchtest# modprobe xeno_switchtest [ 160.221018] Xenomai: starting RTDM services. soekris:/usr/xenomai/testsuite/switchtest# soekris:/usr/xenomai/testsuite/switchtest# switch -n soekris:/usr/xenomai/testsuite/switchtest# switch rtk0 cpu 0: 498 cpu 0: 998 cpu 0: 1498 cpu 0: 2000 cpu 0: 2496 cpu 0: 2998 cpu 0: 3498 cpu 0: 3998 cpu 0: 4500 ... This prog has been running for atleast 1/2 hr, with minimum args.. what should it be doing ? This is a regression test. You should see an error message or a system crash if something goes wrong. The output above looks ok (number of passed loops, kind of lifesign). OK thanks. FWIW, I noted that xeno-test is not running these: - switchbench - switchtest - irqbench Im not sure they belong in xeno-test though, since they dont appear to produce output that shows good vs bad performance, only an informal 'sanity' check. And technically, dont regression tests have to yield a PASS / FAIL decision ? ;-) Speaking more broadly, there are 3 possible kinds of test-progs - regression tests PASS / FAIL - either by exit(rc), or by printf( %s\n, rc ? not-ok : ok) see perl's regression test suite ( 100k separate tests ) usually test details, are not tutorial - performance tests progs stress xenomai, print performance data should help see performance problems, expose bugs xeno-test aims to collect performance data performance data must be expressive (switchtest is perhaps insufficient here) - examples / tutorials ex: satch.c simple, clear progs (low feature clutter, etc) Id like to see all demo/**/ progs in single dir forex satch-native, satch-vxworks, etc .. makes for easier browsing simple makefile builds out-of-tree handles kernel-modules and user-progs (Ive seen some clean ones, cant find now. Mine are crufty:-( 'patterns' of usage IWBGreat if we had common usage patterns isolated, named, and described Towards this last item, Ive done 2 things: - poached code from Hannes Mayer :-) http://www.captain.at/xenomai.php task-timers.c does periodic timer 3 ways: sleeper, waiter, alarm. - scrounged old rtai/fusion code (ls -l says Jul 05 ;-) cleaned up, 1/2 compile now maybe theres examples-tutorials-patterns fodder in here. attached tarball has these in 2 top-level dirs. Id like to see if theres a place for them long-term, and clean them up so theyre correct and helpful. Jan thanks -jimc xeno-examples-tuts.tgz Description: application/gzip ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [patch] update email addr
im trying to inline this patch, pls let me know if its still ws fouled (in thunderbird, cp from svn diff |less, preformat b4 paste) Index: CREDITS === --- CREDITS (revision 1412) +++ CREDITS (working copy) @@ -43,7 +43,7 @@ D: the map. N: Jim Cromie -E: [EMAIL PROTECTED] +E: [EMAIL PROTECTED] D: Comprehensive statistics collection for the testsuite. D: Validation test script. Various script fixes and sanitization. (END) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
