Steve Hunt | 17 Apr 15:29 2006
Picon

Re: Network problem - header checksum error -

I have found that by changing file
cpukit/libnetworking/netinet/ip_output.c - by adding a delay just before
in_cksum_hdr(ip) - the checksum is correctly calculated and everything
works!!!! so perhaps the header is still being changed by the driver at
that time? or is everything in the same thread? perhaps 'ip' is pointing
directly to the hardware and the registers are not stable???.

Very strange ...  but I have not have had time to investigate further
yet - but I will also see if using in_cksum() in place of in_cksum_hdr()
fixes (hides) the problem.

As a side issue - I noticed that when my delay was by adding a 'printf'
I had a quite stable time reported by ping (~2ms) - but when I used
usleep() the time for ping to return changed in a cyclical and
predictable way from 10ms to 1mS !!!!! - would this be expected?  I will
do some more tests.

By the way, my target system is a pc104+ ... not very fast by modern
standards.

Steve Hunt

On Fri, 2006-04-14 at 18:15 +0200, Steve Hunt wrote:
> No - it looks like only the header checksum is wrong.
> 
> On Fri, 2006-04-14 at 16:30 +0200, Sylvain Prestavoine wrote:
> > ----- Original Message ----- 
> > From: "Steve Hunt" <hunt@...>
> > To: <rtems-users@...>
> > Sent: Friday, April 14, 2006 2:44 PM
(Continue reading)

Steve Hunt | 17 Apr 16:23 2006
Picon

Re: Network problem - header checksum error -

in_cksum() does work (without the delay).

On Mon, 2006-04-17 at 15:29 +0200, Steve Hunt wrote:
> I have found that by changing file
> cpukit/libnetworking/netinet/ip_output.c - by adding a delay just before
> in_cksum_hdr(ip) - the checksum is correctly calculated and everything
> works!!!! so perhaps the header is still being changed by the driver at
> that time? or is everything in the same thread? perhaps 'ip' is pointing
> directly to the hardware and the registers are not stable???.
> 
> Very strange ...  but I have not have had time to investigate further
> yet - but I will also see if using in_cksum() in place of in_cksum_hdr()
> fixes (hides) the problem.
> 
> As a side issue - I noticed that when my delay was by adding a 'printf'
> I had a quite stable time reported by ping (~2ms) - but when I used
> usleep() the time for ping to return changed in a cyclical and
> predictable way from 10ms to 1mS !!!!! - would this be expected?  I will
> do some more tests.
> 
> By the way, my target system is a pc104+ ... not very fast by modern
> standards.
> 
> Steve Hunt
> 
> On Fri, 2006-04-14 at 18:15 +0200, Steve Hunt wrote:
> > No - it looks like only the header checksum is wrong.
> > 
> > On Fri, 2006-04-14 at 16:30 +0200, Sylvain Prestavoine wrote:
> > > ----- Original Message ----- 
(Continue reading)

Joel Sherrill | 17 Apr 18:42 2006

Re: Network problem - header checksum error -


Steve Hunt wrote:

>in_cksum() does work (without the delay).
>
>
>On Mon, 2006-04-17 at 15:29 +0200, Steve Hunt wrote:
>  
>
>>I have found that by changing file
>>cpukit/libnetworking/netinet/ip_output.c - by adding a delay just before
>>in_cksum_hdr(ip) - the checksum is correctly calculated and everything
>>works!!!! so perhaps the header is still being changed by the driver at
>>that time? or is everything in the same thread? perhaps 'ip' is pointing
>>directly to the hardware and the registers are not stable???.
>>
>>    
>>
Is there any possible way you are seeing some type of caching effect?  
PowerPC
systems sometimes get caching issues with NIC drivers in PCI memory space. 

>>Very strange ...  but I have not have had time to investigate further
>>yet - but I will also see if using in_cksum() in place of in_cksum_hdr()
>>fixes (hides) the problem.
>>
>>As a side issue - I noticed that when my delay was by adding a 'printf'
>>I had a quite stable time reported by ping (~2ms) - but when I used
>>usleep() the time for ping to return changed in a cyclical and
>>predictable way from 10ms to 1mS !!!!! - would this be expected?  I will
(Continue reading)

gregory.menke | 17 Apr 19:04 2006
Picon

Re: Network problem - header checksum error -


It suggests to me a driver bug where perhaps DMA is screwing up buffers
someplace or maybe there are problems manipulating mbufs leading to
extra or too few packet bytes.  The stack is also extremely fragile with
respect to how mbufs are handled- not much sanity checking goes on and
its easy to screw up both the processing and the related arithmetic.
Whoever thought up the mbufs had a bit too much fun for too long while
at University, I think.

I never noticed checksum errors coming from the stack or sensitivity to
delay in the dec21140 or the elnk drivers.

I also didn't see any cache issues on the PPC though the elnk is not
affected because its IO space.  The ppc cache is not supposed to cover
the PCI memory space- and I've not seen PCI cache issues happen with the
dec21140 or the proprietary boards we have here either.

Regards,

Greg

Joel Sherrill writes:
 > 
 > 
 > Steve Hunt wrote:
 > 
 > >in_cksum() does work (without the delay).
 > >
 > >
 > >On Mon, 2006-04-17 at 15:29 +0200, Steve Hunt wrote:
(Continue reading)

Luís Henriques | 17 Apr 19:17 2006

RTEMS code documentation references

Dear Joel,

While analysing the ERC32 specific code from RTEMS, I found 2 references
to documentation which I could not trace.  These references are both in
file c/src/exec/score/cpu/sparc/erc32.h (still on the old RTEMS tree - I
am using 4.5.0 version):

73 /*
74  *  Trap Types for on-chip peripherals
75  *
76  *  Source: Table 8 - Interrupt Trap Type and Default Priority Assignments
77  *
78  *  NOTE: The priority level for each source corresponds to the least
79  *        significant nibble of the trap type.
80  */
81
82 #define ERC32_TRAP_TYPE( _source ) SPARC_ASYNCHRONOUS_TRAP((_source) + 0x10)

[ . . . ]

90 /*
91  *  Structure for ERC32 memory mapped registers.
92  *
93  *  Source: Section 3.25.2 - Register Address Map
94  *
95  *  NOTE:  There is only one of these structures per CPU, its base address
96  *         is 0x01f80000, and the variable MEC is placed there by the
97  *         linkcmds file.
98  */

(Continue reading)

Joel Sherrill | 18 Apr 15:15 2006

old ERC32 docs was Re: RTEMS code documentation references

Luís Henriques wrote:

>Dear Joel,
>
>While analysing the ERC32 specific code from RTEMS, I found 2 references
>to documentation which I could not trace.  These references are both in
>file c/src/exec/score/cpu/sparc/erc32.h (still on the old RTEMS tree - I
>am using 4.5.0 version):
>  
>

I am offsite today and can't check my bookshelf to give details if I 
even still have the
original manual (I think I still do) but I can almost swear it would 
have come from
whatever ERC32 documentation was available when the port was initially 
done. 
The initial date on the README in the BSP is 1996/12/02 so it would have 
been
the revision from that time frame.

I do recall Jiri sending us multiple sis revisions as they were bring up 
the initial
CPUs at the same time and finding discrepancies.

Maybe Jiri has access to this old documentation today.  I will try to 
give a specific
reference tomorrow.

>73 /*
(Continue reading)

Jiri Gaisler | 18 Apr 15:40 2006

Re: old ERC32 docs was Re: RTEMS code documentation references


I believe that the references were made against some
early versions of the 3-chip erc32 docs. I left all
these documents behind when I left the Agency some
5 year ago. The Atmel web page on TSC695 has some
newer version of the docs online though...

Jiri.

Joel Sherrill wrote:
> Luís Henriques wrote:
> 
>> Dear Joel,
>>
>> While analysing the ERC32 specific code from RTEMS, I found 2 references
>> to documentation which I could not trace.  These references are both in
>> file c/src/exec/score/cpu/sparc/erc32.h (still on the old RTEMS tree - I
>> am using 4.5.0 version):
>>  
>>
> 
> I am offsite today and can't check my bookshelf to give details if I 
> even still have the
> original manual (I think I still do) but I can almost swear it would 
> have come from
> whatever ERC32 documentation was available when the port was initially 
> done. The initial date on the README in the BSP is 1996/12/02 so it 
> would have been
> the revision from that time frame.
> 
(Continue reading)

Jerry Needell | 18 Apr 15:42 2006

Re: old ERC32 docs was Re: RTEMS code documentation references

The link below contains many of the old documents for the ERC32 and the 
TSC691/2/3 chipsets. The chapter and table references do not match the 
examples in the original request, but you may find these documents useful.

http://klabs.org/DEI/Processor/sparc/ERC32/ERC32_docs.htm

I hope it helps - Jerry

Joel Sherrill wrote:

> Luís Henriques wrote:
>
>> Dear Joel,
>>
>> While analysing the ERC32 specific code from RTEMS, I found 2 references
>> to documentation which I could not trace.  These references are both in
>> file c/src/exec/score/cpu/sparc/erc32.h (still on the old RTEMS tree - I
>> am using 4.5.0 version):
>>  
>>
>
> I am offsite today and can't check my bookshelf to give details if I 
> even still have the
> original manual (I think I still do) but I can almost swear it would 
> have come from
> whatever ERC32 documentation was available when the port was initially 
> done. The initial date on the README in the BSP is 1996/12/02 so it 
> would have been
> the revision from that time frame.
>
(Continue reading)

Luís Henriques | 18 Apr 15:58 2006

Re: RTEMS code documentation references

Thanks a lot for all the replies.  The information provided is, indeed,
very useful.

It would be nice to have the "original" versions of these documents
(those referred in the code).  But this information is enough!

--
Luís Henriques

On 17 Abr 2006, lhenriques@... wrote:
> Dear Joel,
>
> While analysing the ERC32 specific code from RTEMS, I found 2 references
> to documentation which I could not trace.  These references are both in
> file c/src/exec/score/cpu/sparc/erc32.h (still on the old RTEMS tree - I
> am using 4.5.0 version):
>
> 73 /*
> 74  *  Trap Types for on-chip peripherals
> 75  *
> 76 * Source: Table 8 - Interrupt Trap Type and Default Priority Assignments
> 77  *
> 78  *  NOTE: The priority level for each source corresponds to the least
> 79  *        significant nibble of the trap type.
> 80  */
> 81
> 82 #define ERC32_TRAP_TYPE( _source ) SPARC_ASYNCHRONOUS_TRAP((_source) + 0x10)
>
> [ . . . ]
>
(Continue reading)

Joel Sherrill | 18 Apr 16:24 2006

Re: RTEMS code documentation references

Luís Henriques wrote:

>Thanks a lot for all the replies.  The information provided is, indeed,
>very useful.
>
>It would be nice to have the "original" versions of these documents
>(those referred in the code).  But this information is enough!
>
>  
>
If you can match the comments up against something you can download, I would
be happy to get a patch to update the documentation.

--joel

>--
>Luís Henriques
>
>On 17 Abr 2006, lhenriques@... wrote:
>  
>
>>Dear Joel,
>>
>>While analysing the ERC32 specific code from RTEMS, I found 2 references
>>to documentation which I could not trace.  These references are both in
>>file c/src/exec/score/cpu/sparc/erc32.h (still on the old RTEMS tree - I
>>am using 4.5.0 version):
>>
>>73 /*
>>74  *  Trap Types for on-chip peripherals
(Continue reading)


Gmane