[Xenomai-core] [patch-trivial ] fix a couple spelling errs
[EMAIL PROTECTED] xenomai]$ diff -u ./ksrc/arch/i386/Kconfig{~,} --- ./ksrc/arch/i386/Kconfig~ 2006-03-23 19:06:35.0 -0700 +++ ./ksrc/arch/i386/Kconfig2006-08-10 19:12:39.0 -0600 @@ -67,7 +67,7 @@ and hence may not be altered. For this reason, Xenomai contains code to detect chipsets using -SMIs and optionnaly activate some workarounds to stop SMIs. +SMIs and optionally activate some workarounds to stop SMIs. Enabling this option will cause Xenomai not to try and detect whether your hardware use SMIs. This option is mostly useful if you know @@ -98,7 +98,7 @@ and hence may not be altered. For this reason, Xenomai contains code to detect chipsets using -SMIs and optionnaly activate some workarounds to stop SMIs. +SMIs and optionally activate some workarounds to stop SMIs. Enabling this option cause those workarounds to be activated. if XENO_HW_SMI_WORKAROUND ___ 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
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
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] Re: [Xenomai-help] -110 error on rt_task_send... bug?
The patch works here too. Thanks for looking into this so quickly. I'll switch back to 2.1 until this is resolved. Vincent Levesque [EMAIL PROTECTED] 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 ! That's good. Thanks for your assistance. So synch. message passing interface (IOW, rt_task_send/receive/reply) is mgmglmgmm... slightly broken at the moment for all versions. The ones who need it may use this patch so far. I'll think a bit more on it in the mean time but I tend to think that "Fixed Ownership" (expressed by XNSYNCH_FOWNER) should really be a property of the synch. object indeed (as in the current patch). > Only one small typo was in the patch, it is fixed in the attached patch > version. Ok, now I need to run diff -u old-patch new-patch to find out this typo :) -- Best regards, Dmitry Adamushko ___ 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] -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] 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|}/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 #include +/* 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] Re: [Xenomai-help] -110 error on rt_task_send... bug?
Hello, if you take a look e.g. at how synch->owner is used in the current SVN codebase then you will notice that this field is actually usefull only for PIP objects but xnsynch_wakeup_* and friends update it for all cases. No, I don't want to say that's why let's do the same with PENDING. This is a preliminary patch and, that said, I'm going to take a closer look at the synch.c. Regarding PENDING : not sure at the moment if it would be helpful (have to think about possible use cases), but with the help of PENDING it's possible to support "ownership"-stealing for FOWNER objects. Sounds funny? :) if (testbits(synch->status, XNSYNCH_FOWNER | XNSYNCH_PENDING) == XNSYNCH_FOWNER) { // the object has been stolen while a thread was waiting to be scheduled on } -- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
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|}/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] 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 > #include > > +/* 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);
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