Hi, Jan
Any ideas on this?
I-pipe frozen back-tracing service on 2.6.16.21-xenomai/ipipe-1.5-02
------------------------------------------------------------
******** WARNING ********
The following debugging options will increase the observed latencies:
o CONFIG_DEBUG_PREEMPT
Freeze: 3525267255803 cycles, Trace Points: 30 (+10)
+--------------- Hard IRQs ('|': locked)
| +- Delay flag ('+': > 1 us, '!': > 10 us)
| |
Type Time Function (Parent)
: func -5 _call_console_drivers (release_console_sem)
: func -4 __ipipe_restore_root (release_console_sem)
: func -4 __ipipe_unstall_root (__ipipe_restore_root)
:|begin -4 __ipipe_unstall_root (__ipipe_restore_root)
:|end -4 __ipipe_unstall_root (__ipipe_restore_root)
: func -4 __ipipe_test_and_stall_root (release_console_sem)
: func -4 add_preempt_count (release_console_sem)
: func -4 __ipipe_restore_root (release_console_sem)
: func -3 __ipipe_unstall_root (__ipipe_restore_root)
:|begin -3 __ipipe_unstall_root (__ipipe_restore_root)
:|end -3 __ipipe_unstall_root (__ipipe_restore_root)
: func -3 sub_preempt_count (release_console_sem)
: func -3 sub_preempt_count (vprintk)
: func -2 kmem_cache_alloc (tdma_ioctl)
: func -2 __ipipe_test_and_stall_root (kmem_cache_alloc)
: func -2 debug_smp_processor_id (kmem_cache_alloc)
: func -2 __ipipe_test_root (debug_smp_processor_id)
: func -2 __ipipe_restore_root (kmem_cache_alloc)
: func -2 __ipipe_unstall_root (__ipipe_restore_root)
:|begin -1 __ipipe_unstall_root (__ipipe_restore_root)
:|end -1 __ipipe_unstall_root (__ipipe_restore_root)
: func -1 __kmalloc (tdma_ioctl)
: func -1 __ipipe_test_and_stall_root (__kmalloc)
: func -1 debug_smp_processor_id (__kmalloc)
: func 0 __ipipe_test_root (debug_smp_processor_id)
: func 0 __ipipe_restore_root (__kmalloc)
: func 0 __ipipe_unstall_root (__ipipe_restore_root)
:|begin 0 __ipipe_unstall_root (__ipipe_restore_root)
:|end 0 __ipipe_unstall_root (__ipipe_restore_root)
< freeze 0 tdma_ioctl (rtnet_ioctl)
func 0 rtnet_rtpc_dispatch_call (tdma_ioctl)
func 0 __kmalloc (rtnet_rtpc_dispatch_call)
func 1 __ipipe_test_and_stall_root (__kmalloc)
func 1 debug_smp_processor_id (__kmalloc)
func 1 __ipipe_test_root (debug_smp_processor_id)
func 1 __ipipe_restore_root (__kmalloc)
func 1 __ipipe_unstall_root (__ipipe_restore_root)
|begin 2 __ipipe_unstall_root (__ipipe_restore_root)
|end 2 __ipipe_unstall_root (__ipipe_restore_root)
|begin 2 rtnet_rtpc_dispatch_call (tdma_ioctl)
Regards,
Chun Yeow
On 9/3/07, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>
> Yeoh Chun Yeow wrote:
> > Dear Jan Kiszka,
> >
> > --> Did you check before that there is, e.g., no IRQ conflict of the
> > rt_eepro100 with some Linux hardware that prevents correct operation?
> > cat /proc/xenomai/irq
> > IRQ CPU0
> > 7: 12 rt_eepro100
> > 216: 532151 [timer]
> > 258: 7 [virtual]
> >
> > cat /proc/interrupts
> > CPU0
> > 0: 134467 XT-PIC timer, rthal_broadcast_timer
> > 1: 1819 XT-PIC i8042
> > 2: 0 XT-PIC cascade
> > 4: 260 XT-PIC serial
> > 5: 0 XT-PIC uhci_hcd:usb2
> > 8: 2 XT-PIC rtc
> > 10: 332 XT-PIC uhci_hcd:usb1
> > 12: 7505 XT-PIC i8042
> > 15: 21746 XT-PIC ide1
> > NMI: 0
> > LOC: 134415
> > ERR: 0
> > MIS: 0
> >
> > So, I think that there is no conflict for IRQ.
>
> Ack.
>
> >
> > --> Does the slave work without any RTmac/TDMA being activated (test
> with
> > rtping)?
> > I have loaded rt_eepro100, rt_loopback, rtipv4, rtpacket and rtnet.
> Later
> > on, I try to rtping the AT91 board from Intel board or rtping the Intel
> > board from AT91 board and both the results are possitive.
> >
> > linux:/usr/local/rtnet/sbin # lsmod
> > Module Size Used by
> > rt_loopback 4356 1
> > rt_eepro100 19848 1
> > rtpacket 6912 0
> > rtipv4 26400 0
> > rtnet 38540 4 rt_loopback,rt_eepro100,rtpacket,rtipv4
> > af_packet 21768 0
> > ipv6 241920 12
> > loop 17032 0
> > <snipped>
> > linux:/usr/local/rtnet/sbin # ./rtroute add 172.16.6.20314:09:07:05:05:02
> > dev rteth0
> > linux:/usr/local/rtnet/sbin # ./rtping 172.16.6.203
> > Real-time PING 172.16.6.203 56(84) bytes of data.
> > 64 bytes from 172.16.6.203: icmp_seq=1 time=868.4 us
> > 64 bytes from 172.16.6.203: icmp_seq=2 time=861.6 us
> > 64 bytes from 172.16.6.203: icmp_seq=3 time=872.4 us
> > 64 bytes from 172.16.6.203: icmp_seq=4 time=860.7 us
> > 64 bytes from 172.16.6.203: icmp_seq=5 time=867.3 us
>
> Interesting. That points to some issue around TDMA.
>
> [The good news is that your driver is likely fine - now looking forward
> to see some code... :-> ]
>
> >
> > So what to do next? Please advice. Thanks
>
> Now debugging gets a bit more complicated: I would suggest to take a
> trace of what happens around the failing calibration. That means to put
> a xntrace_user_freeze(0, 1); before that
> rtpc_dispatch_call(start_calibration, ...) which doesn't complete. You
> should then tune the I-pipe tracer to do significantly long post-tracing
> (likely a few thousand points) and make the tracer verbose (see [1]).
> The result under /proc/ipipe/trace/frozen would then be interesting to
> see (compressed) here.
>
> Thanks,
> Jan
>
> [1] http://www.xenomai.org/index.php/I-pipe:Tracer
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
