Re: [RTnet-developers] Only slave mode works on new port to ns9xxx

[James K. <jam...@gm...>]

> 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
>