This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Cache Problem on TQ850


Hi,

I had almost the same problem as you have right now. However, my network stack didnt work at all when i had the cache enabled. This was because the ethernet buffer (as well as the serial buffer) were filled by the CPM and read by the core. There is problably a better solution for this but i decided to put my ethernet buffer in an uncached area which in my case was between 15MB and 16Mb of the upper memory. The rest of the memory 0-15M reside within the cache area.

The above should really not be neccisary because it shall be handled by the driver - if_quicc.c - but it was a quicc workaround. 

/Daniel

-----Original Message-----
From: Retallack, Mark (Poole) [mailto:Mark.Retallack@stcl.siemens.co.uk] 
Sent: den 15 oktober 2002 11:34
To: ecos-discuss@sources.redhat.com
Cc: Hughes, Paul (Poole); Ballantine, Jim (Poole)
Subject: [ECOS] Cache Problem on TQ850


Cache Problem under eCos on TQ850
 
 
The hardware set up being used is a PowerPC 850.
 
The following packets are SNMP responses to a GET command on an OID .2.16.44.1.4.1.1.4.1.1.3.1.2.0  .   The previous two gets also failed with the Text message being send over the network having the same error as shown here the correct value is "Bit0-CByte_str" and for the error the string is shown as "Bit0-Cbyteescr".   From other runs the text message returned is combined with the text of previous OID strings. 
 
This is the first failure, with the UDP check sum failing as the text has been changed.
 
User Datagram Protocol, Src Port: snmp (161), Dst Port: 4050 (4050)
    Source port: snmp (161)
    Destination port: 4050 (4050)
    Length: 78
    Checksum: 0x35a9 (incorrect, should be 0x40a9)
Simple Network Management Protocol
    Version: 1
    Community: public   
    PDU type: RESPONSE
    Request Id: 0x6d4dc731
    Error Status: NO ERROR
    Error Index: 0
    Object identifier 1: 2.16.44.1.4.1.1.4.1.1.3.1.2.0
    Value: OCTET STRING: Bit0-CByteescr
 
 
0000  00 30 05 19 b8 f9 00 d0 93 00 1f 80 08 00 45 00   .0............E.
0010  00 62 34 eb 00 00 40 11 43 cb 89 df 98 d5 89 df   .b4...@.C.......
0020  55 41 00 a1 0f d2 00 4e 35 a9 30 82 00 42 02 01   UA.....N5.0..B..
0030  00 04 06 70 75 62 6c 69 63 a2 82 00 33 02 04 6d   ...public...3..m
0040  4d c7 31 02 01 00 02 01 00 30 82 00 23 30 82 00   M.1......0..#0..
0050  1f 06 0d 60 2c 01 04 01 01 04 01 01 03 01 02 00   ...`,...........
0060  04 0e 42 69 74 30 2d 43 42 79 74 65 65 73 63 72   ..Bit0-CByteescr
 
 
 
The second packet is successful the text message not being changed and the checksum is now correct.  Both packets have the data and request Id so the error can be seen to have occurred after the checksum calculations.
 
User Datagram Protocol, Src Port: snmp (161), Dst Port: 4050 (4050)
    Source port: snmp (161)
    Destination port: 4050 (4050)
    Length: 78
    Checksum: 0x35a9 (correct)
Simple Network Management Protocol
    Version: 1
    Community: public
    PDU type: RESPONSE
    Request Id: 0x6d4dc731
    Error Status: NO ERROR
    Error Index: 0
    Object identifier 1: 2.16.44.1.4.1.1.4.1.1.3.1.2.0
    Value: OCTET STRING: Bit0-CByte_str
 
 
0000  00 30 05 19 b8 f9 00 d0 93 00 1f 80 08 00 45 00   .0............E.
0010  00 62 34 ec 00 00 40 11 43 ca 89 df 98 d5 89 df   .b4...@.C.......
0020  55 41 00 a1 0f d2 00 4e 35 a9 30 82 00 42 02 01   UA.....N5.0..B..
0030  00 04 06 70 75 62 6c 69 63 a2 82 00 33 02 04 6d   ...public...3..m
0040  4d c7 31 02 01 00 02 01 00 30 82 00 23 30 82 00   M.1......0..#0..
0050  1f 06 0d 60 2c 01 04 01 01 04 01 01 03 01 02 00   ...`,...........
0060  04 0e 42 69 74 30 2d 43 42 79 74 65 5f 73 74 72   ..Bit0-CByte_str
 
 
When the cache is turned off this error is no longer seen,  when on about 3% of all packets were failing.  However with cache enabled the flood test did not generate any errors.

We are using the OpenBSD stack from a CVS snapshot taken a month ago. Does anyone know why enabling the cache would directly effect the upper layers of the protocol stack, and how to solve the problem?



Siemens Plc 
Registered office: Siemens House, Oldbury, Bracknell, Berkshire, RG12 8FZ. 
Registered no: 727817, England. 


This communication contains information which is confidential and 
may also be privileged. It is for the exclusive use of the addressee. 
If you are not the addressee please note that any distribution, 
reproduction, copying, publication or use of this communication 
or the information in it is prohibited. If you have received this 
communication in error, please contact us immediately and also 
delete the communication from your computer. 

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]