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.203 14: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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
