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
[Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
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. :-) 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. Sebastian [1] https://mail.gna.org/public/xenomai-core/2006-10/msg00079.html [2] https://mail.gna.org/public/xenomai-core/2006-09/msg00055.html # ./latency == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... BUG: soft lockup detected on CPU#0! Pid: 772, comm: dd CPU: 0 PC is at __ipipe_mach_get_tsc+0x44/0x54 LR is at 0x0 pc : []lr : [<>]Not tainted sp : ip : fp : r10: r9 : r8 : r7 : r6 : r5 : r4 : r3 : r2 : r1 : r0 : Flags: nZcv IRQs on FIQs on Mode USER_32 Segment user Control: C000317F Table: 31FF DAC: 0015 [] (show_regs+0x0/0x4c) from [] (softlockup_tick+0x64/0x7c) r4 = C027F424 [] (softlockup_tick+0x0/0x7c) from [] (do_timer+0x3e8/0x468) r4 = C02A265C [] (do_timer+0x0/0x468) from [] (timer_tick+0xb4/0xe4) [] (timer_tick+0x0/0xe4) from [] (s3c2410_timer_interrupt+0x78/0xa4) r6 = C02A1610 r5 = r4 = C022A4C8 [] (s3c2410_timer_interrupt+0x0/0xa4) from [] (__do_irq+0x40/0x74) r8 = C027F424 r7 = 001E r6 = r5 = r4 = C022A4C8 [] (__do_irq+0x0/0x74) from [] (do_edge_IRQ+0xa0/0xfc) r8 = C027F424 r7 = C027F424 r6 = C022A4C8 r5 = 001E r4 = C027E3A0 [] (do_edge_IRQ+0x0/0xfc) from [] (asm_do_IRQ+0x50/0x13c) r7 = C022DFC0 r6 = 001E r5 = r4 = C022DFC8 [] (asm_do_IRQ+0x0/0x13c) from [] (__ipipe_sync_stage+0x1e0/0x268) [] (__ipipe_sync_stage+0x0/0x268) from [] (__ipipe_walk_pipeline+0x98/0xbc) [] (__ipipe_walk_pipeline+0x0/0xbc) from [] (__ipipe_handle_irq+0x1a4/0x1b4) r7 = C02A3B00 r6 = 001E r5 = 001E r4 = [] (__ipipe_handle_irq+0x0/0x1b4) from [] (__ipipe_grab_irq+0xc4/0x110) [] (__ipipe_grab_irq+0x0/0x110) from [] (__irq_usr+0x40/0x170) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
