Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Am Freitag, 10. November 2006 11:14 schrieb Gilles Chanteperdrix: > Sebastian Smolorz wrote: > > Hi all, > > > > now that the teething problems of my I-pipe port to the S3C24xx are cured > > (hopefully ...) I'm going to iterate it to v4. We've established a > > project homepage for that port > > http://opensource.emlix.com/ipipe-s3c24xx/ > > What happens with __ipipe_mach_irq_mux_p if irq is smaller than IRQ_CAM ? OK, this is not correct. I will fix it to #define __ipipe_irqbit(irq) (1 << ((irq) - S3C2410_CPUIRQ_OFFSET)) as you suggested originally. Thanks, Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Sebastian Smolorz wrote: Hi all, now that the teething problems of my I-pipe port to the S3C24xx are cured (hopefully ...) I'm going to iterate it to v4. We've established a project homepage for that port http://opensource.emlix.com/ipipe-s3c24xx/ What happens with __ipipe_mach_irq_mux_p if irq is smaller than IRQ_CAM ? -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Sebastian Smolorz wrote: > Jan Kiszka wrote: >> Sebastian Smolorz wrote: >>> However, there is one disturbing issue. When I execute >>> >>> dd if=/dev/zero of=/dev/null >>> >>> and the latency test in userspace with a period not less than 150 us the >>> worst case latency is about 220 us. But when I start latency with -p 100 >>> I get a softlock like the one attached. I guess this is the same problem >>> as Detlef Vollmann described in [2]. So I think it's time for a big fat >>> ARM-specific warning in the troubleshooting file and perhaps a >>> modification of the testsuite so that if being compiled for ARM the >>> default sample periods are greater than the 100 us now. >> Something is preventing the watchdog kthread from being executed for >> more than 10 s. Maybe this is just a sign that the systems is hopelessly >> overloaded (what are average latencies?). > > They are 120-130 us. Which is a good sign that the board is basically only flushing caches when running the test at this frequency. Still the question remains if the BUG is an expectable behaviour or a sign for hidden problems. > >> Maybe it is a real IRQ or >> scheduling issue in Linux caused by I-pipe. Maybe it is time to port the >> I-pipe tracer... ;) > > With the latest Adeos upgrade for ARM the I-pipe tracer was integrated, > wasn't > it? I was already taking its usage into account. The arch-independent code is merged for ARM, but it still takes to port ipipe-mcount.S and likely ipipe_read_tsc + related services. Not much to do, though. Take a look at the code in PREEMPT_RT for the mcount part. 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] I-pipe patch for ARM S3C24xx (v4)
Jan Kiszka wrote: > Sebastian Smolorz wrote: > > However, there is one disturbing issue. When I execute > > > > dd if=/dev/zero of=/dev/null > > > > and the latency test in userspace with a period not less than 150 us the > > worst case latency is about 220 us. But when I start latency with -p 100 > > I get a softlock like the one attached. I guess this is the same problem > > as Detlef Vollmann described in [2]. So I think it's time for a big fat > > ARM-specific warning in the troubleshooting file and perhaps a > > modification of the testsuite so that if being compiled for ARM the > > default sample periods are greater than the 100 us now. > > Something is preventing the watchdog kthread from being executed for > more than 10 s. Maybe this is just a sign that the systems is hopelessly > overloaded (what are average latencies?). They are 120-130 us. > Maybe it is a real IRQ or > scheduling issue in Linux caused by I-pipe. Maybe it is time to port the > I-pipe tracer... ;) With the latest Adeos upgrade for ARM the I-pipe tracer was integrated, wasn't it? I was already taking its usage into account. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
Sebastian Smolorz wrote: > Hi all, > > now that the teething problems of my I-pipe port to the S3C24xx are cured > (hopefully ...) I'm going to iterate it to v4. We've established a project > homepage for that port > http://opensource.emlix.com/ipipe-s3c24xx/ > in order to concentrate the source code and information at one point. > Probably > tomorrow I will come up with a patch in order to address point 2 in my email > from 27.10.2006 ([1]). After that I can go to v5 of my patch and beg for > integration. :-) Nice to hear. > > However, there is one disturbing issue. When I execute > > dd if=/dev/zero of=/dev/null > > and the latency test in userspace with a period not less than 150 us the > worst > case latency is about 220 us. But when I start latency with -p 100 I get a > softlock like the one attached. I guess this is the same problem as Detlef > Vollmann described in [2]. So I think it's time for a big fat ARM-specific > warning in the troubleshooting file and perhaps a modification of the > testsuite so that if being compiled for ARM the default sample periods are > greater than the 100 us now. Something is preventing the watchdog kthread from being executed for more than 10 s. Maybe this is just a sign that the systems is hopelessly overloaded (what are average latencies?). Maybe it is a real IRQ or scheduling issue in Linux caused by I-pipe. Maybe it is time to port the I-pipe tracer... ;) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
