[Xenomai-core] Strange behaviour of RTDM CAN driver
Hello all, the following is a really nasty problem I am trying to solve for months now. I really hope that someone on the list knows the solution. As you may remember some months ago I announced a RTDM CAN driver for SJA1000 based cards (see https://mail.gna.org/public/xenomai-core/2005-11/msg00108.html). The driver works well with the cards at our institute. Some time ago I was asked to extend the driver so that it would work also with a card from another vendor (Advantech PCM3680). By now, the driver does its job as expected, with one exception: It gets stuck in the interrupt handler. The problem is that the interrupt register of the SJA1000 chip does not get cleared after a read command like it should. So the driver never knows that there is no interrupt anymore and therefore never leaves the interrupt handler. After I installed a break after 20 loops inside the handler and an additional read of the interrupt register in the following syscall routine issued by the test program, I noticed that the register is cleared! So I strongly think that the reason for clearing this register lies in actions taken after the driver left the interrupt handler. But I am not very sure about this. Maybe there is another reason I do not see (or in the end the hardware is faulty ...). Did any of you experienced a similar problem in the past? Any hint would be appreciated! Interestingly, the driver does not show the above behaviour with all interrupt numbers. E.g. with interrupt number 12 the driver gets no interrupt at all. Some technical details: - Linux Kernel 2.6.16 - adeos-ipipe-2.6.16-i386-1.3-01.patch - Xenomai 2.1.50 Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: LTTng intergration roadmap
Alexis Berlemont wrote: > Hi, > >> the need for a high-level tracing tool constantly increases with the >> growing code base of Xenomai applications. >> >> Yesterday I started a short discussion with Alexis about the status of >> his LTTng combo patch, the Xenomai integration, and the advances of >> LTTng itself. But there are certainly more people interested in this >> topic and may contribute ideas, comments, or even concrete code. >> >> Daniel, you once said that some of your students would start to work on >> this topic. In which domain precisely, more at patch level or rather on >> tools? What is the scheduled beginning and/or deadline for this thesis? >> >> Moreover, does anyone on this list recently tried LTTng on standard >> Linux? Can we consider it reasonably stable and usable? One new thing >> about LTTng internals which Alexis brought up were changes in the custom >> tracing event interface. As this is a rather crucial point with respect >> to the Xenomai instrumentation, we certainly do not want to change it >> back and forth until LTTng stabilises. > > Here is a little quotation from the LTTng Quickstart guide, I used it to > define the LTT events for Xenomai: > > * Add new events to the kernel with genevent > > su - > cd /usr/local/share/LinuxTraceToolkitViewer/facilities > cp process.xml yourfacility.xml > * edit yourfacility.xml to fit your needs. > cd /tmp > /usr/local/bin/genevent > /usr/local/share/LinuxTraceToolkitViewer/facilities/yourfacility.xml > cp ltt-facility-yourfacility.h ltt-facility-id-yourfacility.h \ > /usr/src/linux-2.6.16-lttng-0.x.xx8/include/linux/ltt > cp ltt-facility-loader-yourfacility.c ltt-facility-loader-yourfacility.h \ > /usr/src/linux-2.6.16-lttng-0.x.xx/ltt > * edit the kernel file you want to instrument > - Add #include at the beginning > of the file. > - Add a call to the tracing functions. See their names and parameters in > > /usr/src/linux-2.6.16-lttng-0.x.xx/include/linux/ltt/ltt-facility-yourfacility.h > > So, In order to test the combo patch adeos + LTTng I made: > -> I wrote xenomai.xml (cf. attached file) which defines all the Xeno-LTT > events; > -> I used genevent so as to generate the sources and the headers relative > with > my events; > -> Instead of copying them in the kernel, I integrated the sources in > Xenomai. > I was considering that the Xeno events was independant from Linux. > > As a matter of fact, the last point should be rethought as the Xeno build > procedure is now integrated in the kernel. Not necessarily, you may still compile the nucleus as a module. > > Things are simpler now, we could create an "I-pipe aware LTTng" patch which > could contain : > -> the modifications in Relayfs (for a proper functioning with Adeos); > -> the LTTng core stuff adapted for Adeos (not much work to do on this part); > -> the Xenomai events in include/linux/ltt, and the loading code in ... Hmm, I guess Philippe will not be happy to see Xeno-specific code in the ipipe patch (like I had with my kgdb hack). Is there no clean way to introduce this code together with the Xenomai installation, e.g. when preparing the kernel with the script? > > This patch would be applied after the I-pipe patch (in the same way as the > I-pipe tracer patch). So there would be no need to make combo patches, an > arch-independant additionnal patch would be easier to maintain. > > What do you think of that ? I do not overview every detail (I should actually look at the patch more in detail, but - you know - time...). Everything that helps to reduce maintenance costs while still keeping clean abstraction layers (ipipe is ipipe, xenomai is an independent add-on) is certainly good. > > Eventually, concerning LTTng stabilisation status, I had a look a their > mailing-list (I am lurking on it since the beginning of LTTng) and at their > roadmap: starting from now, their TODO list contains integration and ports, > therefore undertaking an integration of LTTng with Xenomai (rigth now or next > month) does not seem too risky, does it? Sounds good. Sounds at least like they found a stable design we can use now - or soon when resources are available. 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] Strange behaviour of RTDM CAN driver
Hello Ulrich! On Tue, 16 May 2006 [EMAIL PROTECTED] wrote: > I don't know your hardware, but i think it's a not a hardware problem. > Your desctription sounds more than a compiler optimization problem. > > Ok, this is your READ_REG definition, > > /** Read access to a register of the SJA1000 CAN controller */ > #define READ_REG(base, register) \ > readb((void *)(base+register)) > > please try this one: > > /** Read access to a register of the SJA1000 CAN controller */ > #define READ_REG(base, register) \ > readb((volatile void *)(base+register)) Thank you for your suggestion. In my initial mail I forgot to mention that the problem of an over-optimising compiler came into my mind, too. I tried several workarounds to exclude every effect of the compiler (compiling with -O0 instead of -O2, replacing readb directly with the definition used in the Linux Kernel sources, and lastly disassembling the driver to assure myself that there are really memory access commands to the IO memory). Also, when I compile the driver with the change you suggested, the kernel module is not different to that compiled without that change. But I am desperate enough to try this one out. (That means mailing your suggestion to the person who owns the Advantech CAN card; developing a driver without the possibility to test it is really difficult.) Regards, Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Strange behaviour of RTDM CAN driver
Sebastian Smolorz wrote: Hello all, the following is a really nasty problem I am trying to solve for months now. I really hope that someone on the list knows the solution. As you may remember some months ago I announced a RTDM CAN driver for SJA1000 based cards (see https://mail.gna.org/public/xenomai-core/2005-11/msg00108.html). The driver works well with the cards at our institute. Some time ago I was asked to extend the driver so that it would work also with a card from another vendor (Advantech PCM3680). By now, the driver does its job as expected, with one exception: It gets stuck in the interrupt handler. The problem is that the interrupt register of the SJA1000 chip does not get cleared after a read command like it should. So the driver never knows that there is no interrupt anymore and therefore never leaves the interrupt handler. After I installed a break after 20 loops inside the handler and an additional read of the interrupt register in the following syscall routine issued by the test program, I noticed that the register is cleared! So I strongly think that the reason for clearing this register lies in actions taken after the driver left the interrupt handler. But I am not very sure about this. Maybe there is another reason I do not see (or in the end the hardware is faulty ...). Did any of you experienced a similar problem in the past? Any hint would be appreciated! Interestingly, the driver does not show the above behaviour with all interrupt numbers. E.g. with interrupt number 12 the driver gets no interrupt at all. Some technical details: - Linux Kernel 2.6.16 - adeos-ipipe-2.6.16-i386-1.3-01.patch - Xenomai 2.1.50 It would be interesting to know how Adeos is asked to deal with such interrupt upon receipt, e.g. does it relay it to Linux? What do the following say? And also, which is the number of your interrupt in the dumps below? $ cat /proc/ipipe/Xenomai $ cat /proc/ipipe/Linux $ cat /proc/xenomai/irq -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Strange behaviour of RTDM CAN driver
Hello Philippe, on Tue, 16 May 2006, Philippe Gerum wrote: > It would be interesting to know how Adeos is asked to deal with such > interrupt upon receipt, e.g. does it relay it to Linux? In the init_module routine the driver calls rtdm_irq_request() with flags RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE. The interrupt handler returns RTDM_IRQ_NONE if the interrupt register of the CAN chip reports zero (which is not the case here) or RTDM_IRQ_HANDLED if it is not zero. > What do the > following say? And also, which is the number of your interrupt in the > dumps below? > > $ cat /proc/ipipe/Xenomai > $ cat /proc/ipipe/Linux > $ cat /proc/xenomai/irq I've sent a mail to Roland Riepl who has got that strange piece of CAN hardware and also suggested him to directly post his answer to this ML. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Patch for better error messages in posix testsuite
Niklaus Giger wrote: > Hi > > If one greps the output of the posix testsuite failures does not show > up cleanly as the assertions are terminated by a line feed. > > Please apply the following patch which fixes this problem Applied, thanks. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RE: LTTng intergration roadmap
Hi Jan, Sorry for my late answer. > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoyé : lundi, 15. mai 2006 17:18 > À : xenomai-core > Cc : Alexis Berlemont; ROSSIER Daniel > Objet : LTTng intergration roadmap > > Hi, > > the need for a high-level tracing tool constantly increases with the > growing code base of Xenomai applications. > > Yesterday I started a short discussion with Alexis about the status of > his LTTng combo patch, the Xenomai integration, and the advances of > LTTng itself. But there are certainly more people interested in this > topic and may contribute ideas, comments, or even concrete code. > > Daniel, you once said that some of your students would start to work on > this topic. In which domain precisely, more at patch level or rather on > tools? What is the scheduled beginning and/or deadline for this thesis? > Yes, it's right; my student is actually working on a first investigation in order to prepare its diploma project which starts from October to December. So, the most insteresting results should not come up until then. The project consists in enhancing LTTng with Xenomai events and some specific algorithmic filtering on the related events, such as detecting abnormal situations (deadline misses, priority inversion at a certain level, etc.); the way how events are presented are also an issue to be considered (events per threads and not per process, different ways to represent the events). We are therefore very open to some proposals and ideas. The interesting thing is that Jean-Olivier (the student) will perform his project at Matthieu Denoyers's premises at Montreal; besides, he already visited him to have first discussions. I think this will help us greatly. > Moreover, does anyone on this list recently tried LTTng on standard > Linux? Can we consider it reasonably stable and usable? One new thing > about LTTng internals which Alexis brought up were changes in the custom > tracing event interface. As this is a rather crucial point with respect > to the Xenomai instrumentation, we certainly do not want to change it > back and forth until LTTng stabilises. > > Jan Thanks also to Alexis. The way how to generated lttng events matches with how we're doing now; we will also examine his Xenomai events and give you a feedback. Of course, we keep the forum informed about the progress, but as mentioned before, it risks to evolve quite slowly on our side since the "big" project is for the three last months. Daniel ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
