Thread: [RTnet-developers] Only slave mode works on new port to ns9xxx
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-developers
|
From: James K. <jam...@gm...> - 2009-12-10 21:35:43
|
I'm running into another problem porting the ns9xxx-eth.c network driver to RTnet. Slave mode works well when connecting to a known working PC with RTnet, and rtping works fine after the connection is established. But device cannot establish a connection in master mode, neither while broadcasting for the PC nor while using another identical device (which obviously is known to work in slave mode). I've verified that the RTcfg Stage 1 Config packets are identical (except for IP addresses) between the working setup (in slave mode) and the non-working condition (in master mode). The problem seems to be with the TDMA Sync packets. There are a number of fields which are simply not populated. The "Cycle Number" is incrementing and "Scheduled Transmission Time" appears to be a somewhat reasonable value. Why would the other values not be populated? (see data capture below) Thanks, - James ___________________ Device as Slave - packet captures: 0000 ff ff ff ff ff ff 00 30 ab 02 87 df 90 21 00 01 .......0 .....!.. 0010 02 00 02 01 00 00 00 04 9a 1a 11 7e 0b 2d 7a d5 ........ ...~.-z. 0020 b4 24 11 7e 0b 2d 7a d5 b0 ec 20 73 6c 6f 74 20 .$.~.-z. .. slot 0030 30 20 32 30 30 3b 69 66 63 6f 6e 66 0 200;if conf 0000 ff ff ff ff ff ff 00 30 ab 02 87 df 90 22 00 01 .......0 .....".. 0010 0a 65 01 7e 0a 65 01 7f 04 00 42 24 54 44 4d 41 .e.~.e.. ..B$TDMA 0020 43 46 47 20 72 74 65 74 68 30 20 73 6c 6f 74 20 CFG rtet h0 slot 0030 30 20 32 30 30 3b 69 66 63 6f 6e 66 69 67 20 76 0 200;if config v 0040 6e 69 63 30 20 75 70 20 24 49 50 41 44 44 52 20 nic0 up $IPADDR 0050 24 4e 45 54 4d 41 53 4b 5f 4f 50 54 0a $NETMASK _OPT. ___________________ Device as Master - packet captures: 0000 ff ff ff ff ff ff 00 04 f3 ff ff fa 90 21 00 01 ........ .....!.. 0010 02 00 02 01 00 00 00 00 71 37 00 00 00 00 00 00 ........ q7........ 0020 00 00 00 00 00 25 22 b7 d2 ea 00 00 00 00 00 00 .....%". ........ 0030 00 00 00 00 00 00 00 00 00 00 00 00 ........ ..... 0000 ff ff ff ff ff ff 00 30 ab 02 87 df 90 22 00 01 .......0 .....".. 0010 0a 65 01 7f 0a 65 01 7e 04 00 42 24 54 44 4d 41 .e...e.~ ..B$TDMA 0020 43 46 47 20 72 74 65 74 68 30 20 73 6c 6f 74 20 CFG rtet h0 slot 0030 30 20 32 30 30 3b 69 66 63 6f 6e 66 69 67 20 76 0 200;if config v 0040 6e 69 63 30 20 75 70 20 24 49 50 41 44 44 52 20 nic0 up $IPADDR 0050 24 4e 45 54 4d 41 53 4b 5f 4f 50 54 0a $NETMASK _OPT. |
|
From: Jan K. <jan...@si...> - 2009-12-11 10:00:24
|
James Kilts wrote: > I'm running into another problem porting the ns9xxx-eth.c network > driver to RTnet. Slave mode works well when connecting to a known > working PC with RTnet, and rtping works fine after the connection is > established. But device cannot establish a connection in master mode, > neither while broadcasting for the PC nor while using another > identical device (which obviously is known to work in slave mode). > > I've verified that the RTcfg Stage 1 Config packets are identical > (except for IP addresses) between the working setup (in slave mode) > and the non-working condition (in master mode). The problem seems to > be with the TDMA Sync packets. There are a number of fields which are > simply not populated. The "Cycle Number" is incrementing and > "Scheduled Transmission Time" appears to be a somewhat reasonable > value. Why would the other values not be populated? (see data > capture below) (Better include the parsed frames as wireshark displays them - easier to read unless one knows all protocol bits by heart.) Is your driver trying to time-stamp outgoing frame already? If yes, maybe the is a problem with the required late update of the frame. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux |
|
From: Jan K. <jan...@si...> - 2009-12-11 11:35:41
|
CCs... :) James Kilts wrote: >> (Better include the parsed frames as wireshark displays them - easier to >> read unless one knows all protocol bits by heart.) > > Attached are the full Wireshark captures showing the device failing to populate all of the fields of the TDMA synch broadcast when running in master mode. It shows that the driver obviously fails to populate the xmit-stamp field: > TDMA RTmac Discipline, Synchronisation > Version: 0x0201 > Message ID: Synchronisation (0x0000) > Cycle Number: 10376 > Transmission Time Stamp: 0 (-80052902983) > Scheduled Transmission Time: 80052902983 and > TDMA RTmac Discipline, Synchronisation > Version: 0x0201 > Message ID: Synchronisation (0x0000) > Cycle Number: 89575 > Transmission Time Stamp: 0 (-466667678324) > Scheduled Transmission Time: 466667678324 It's zero in both cases, but it should be close to the scheduled time. > > >> Is your driver trying to time-stamp outgoing frame already? If yes, >> maybe the is a problem with the required late update of the frame. > > I'm not entirely sure I understand. The driver time-stamps the outgoing frame in hard_start_xmit(), the same as many of the other drivers. I've tried doing the time-stamp earlier and later in the process, but the result is basically the same. In what part of the code does/should the "late update of the frame" occur? It should happen atomically together with giving the transmission signal to the hardware. If special measures are required to prepare the payload transfer (like some cache flush e.g.), the frame patching must happen before that or the measures need to be repeated for the modified payload range. Maybe you want to share your current work already, that would make the discussion a bit more concrete. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux |
|
From: James K. <jam...@gm...> - 2009-12-11 13:00:22
Attachments:
rt_ns9xxx-eth.c
|
__________________________________________________________________
WITH VALID TRANSMISSION TIME, FAILING WITH REMAINING DATA
No. Time Source Destination Protocol Info
18615 32.524751 FsForth-_ff:ff:fa Broadcast TDMA Synchronisation
Frame 18615 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Source: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa)
Address: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: Real-Time Media Access Control (0x9021)
Real-Time Media Access Control, Version 2
Type: TDMA (0x0001)
Version: 2
Flags: 0x00
0000 000. = Reserved Flags: 0x00
.... ...0 = Tunnelling Flag: Not Set
TDMA RTmac Discipline, Synchronisation
Version: 0x0201
Message ID: Synchronisation (0x0000)
Cycle Number: 1936
Transmission Time Stamp: 23252741687 (+120304)
Scheduled Transmission Time: 23252621383
0000 ff ff ff ff ff ff 00 04 f3 ff ff fa 90 21 00 01 .............!..
0010 02 00 02 01 00 00 00 00 07 90 00 00 00 05 69 f8 ..............i.
0020 ae 37 00 00 00 05 69 f6 d8 47 00 00 00 00 00 00 .7....i..G......
0030 00 00 00 00 00 00 00 00 00 00 00 00 ............
_______________________________________________________________
FAILING WITH TRANSMISSION TIME
No. Time Source Destination Protocol Info
17857 20.935036 FsForth-_ff:ff:fa Broadcast TDMA Synchronisation
Frame 17857 (60 bytes on wire, 60 bytes captured)
Arrival Time: Dec 11, 2009 05:34:58.936120000
[Time delta from previous captured frame: 0.000347000 seconds]
[Time delta from previous displayed frame: 0.005003000 seconds]
[Time since reference or first frame: 20.935036000 seconds]
Frame Number: 17857
Frame Length: 60 bytes
Capture Length: 60 bytes
[Frame is marked: False]
[Protocols in frame: eth:rtmac]
[Coloring Rule Name: Broadcast]
[Coloring Rule String: eth[0] & 1]
Ethernet II, Src: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Source: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa)
Address: FsForth-_ff:ff:fa (00:04:f3:ff:ff:fa)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: Real-Time Media Access Control (0x9021)
Real-Time Media Access Control, Version 2
Type: TDMA (0x0001)
Version: 2
Flags: 0x00
0000 000. = Reserved Flags: 0x00
.... ...0 = Tunnelling Flag: Not Set
TDMA RTmac Discipline, Synchronisation
Version: 0x0201
Message ID: Synchronisation (0x0000)
Cycle Number: 10376
Transmission Time Stamp: 0 (-80052902983)
Scheduled Transmission Time: 80052902983
0000 ff ff ff ff ff ff 00 04 f3 ff ff fa 90 21 00 01 .............!..
0010 02 00 02 01 00 00 00 00 28 88 00 00 00 00 00 00 ........(.......
0020 00 00 00 00 00 12 a3 86 5c 47 00 00 00 00 00 00 ........\G......
0030 00 00 00 00 00 00 00 00 00 00 00 00 ............
|
|
From: Jan K. <jan...@si...> - 2009-12-11 14:16:04
|
James Kilts wrote: > Well, after populating the xmit_stamp field before calling dma_map_single() from hard_start_xmit(), it seems that at least that part is transmitted. The rest of the payload, however, is still non-existent. What rest to you refer to? There is no further payload beyond that five TDMA fields. > It looks like the packet should be 60 bytes long, but the skb->len is only 42 in hard_start_xmit(). I've verified that 42 is indeed the actual length, because anything beyond that is garbage data. Who is responsible for padding with the ns9xxx, the driver or the hardware (though there should be no difference between Linux operation and RTnet)? What does the receiver see of the sync frames? > > The source code in its current state is attached, as well as the packet capture as it was failing before (without timestamps), and the most recent capture with timestamps but still without the remaining payload. The parts of interest for the driver are hard_start_xmit around line 1100 and the transmit interrupt around line 720. > > Thanks, > - James > Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux |
|
From: James K. <jam...@gm...> - 2009-12-11 15:02:21
|
> What rest to you refer to? There is no further payload beyond that five > TDMA fields. When the 8139too driver is acting as master, it generally contains "slot 0 200;if conf". I guess I just assumed that these were meaningful since "slot" and numbers seem like reasonable things for a TDMA protocol. :-) The 8139 driver must just be transmitting garbage at the end of the message then. It appears that moving xmit_stamp earlier has corrected the problem. After removing some debug messages the master/slave connection goes through with the device as master. I'm still a little concerned that the timestamp has to occur so early (could this cause problems with the TDMA?). It also seems strange that just a few rtdm_printk's can cause the entire thing to fail so completely. I suppose I've got a bit more investigation to do, but it seems to be working good so far with debug messages turned off. Thank you so much for your help! - James On Fri, Dec 11, 2009 at 3:15 PM, Jan Kiszka <jan...@si...> wrote: > James Kilts wrote: > > Well, after populating the xmit_stamp field before calling > dma_map_single() from hard_start_xmit(), it seems that at least that part is > transmitted. The rest of the payload, however, is still non-existent. > > What rest to you refer to? There is no further payload beyond that five > TDMA fields. > > > It looks like the packet should be 60 bytes long, but the skb->len is > only 42 in hard_start_xmit(). I've verified that 42 is indeed the actual > length, because anything beyond that is garbage data. > > Who is responsible for padding with the ns9xxx, the driver or the > hardware (though there should be no difference between Linux operation > and RTnet)? What does the receiver see of the sync frames? > > > > > The source code in its current state is attached, as well as the packet > capture as it was failing before (without timestamps), and the most recent > capture with timestamps but still without the remaining payload. The parts > of interest for the driver are hard_start_xmit around line 1100 and the > transmit interrupt around line 720. > > > > Thanks, > > - James > > > > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux > |
Thanks for helping keep SourceForge clean.
X