> 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 <[email protected]> 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 >
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
