Hi all, The following problem was quite hard to discover and still I am not sure it is solved completely. I present it below for comments, suggestions and future use. The problem is around receiving *more* data using speculative receive requests on one gigabit port. The problem raises due to : 1. The default settings of the gigabit controller (IXF1002) (For the ENP2506 and the IXP1200EB using giga_drv.o module) 2. Wrong number of valid bytes reported in RCV_CTL register. 3. Using two RFIFO elements per receive request. The scenario is : 1. Eight threads (2 microEngines) issue speculative receive requests (RR) on one gigabit port in strict order. 2. For each thread, two RFIFO elements are statically assigned. 3. Each RR tries to fill two RFIFO elements. 4. We sent to the gigabit port one packet of 192Bytes (3 MPKTs) 5. We count the number of bytes and the number of MPKTs received The problem : 1. Sometimes we receive 4 MPKTs and the total number of (reported valid) bytes received are more than 192Bytes. The bug: In the ENP2506 the giga_drv.o module configures the gigabit port so as to assert rxvrdy signal when: 1. There are 128B available, OR 2. There is a "header" available. where "header" is defined as the first "headersz" bytes of a packet. By default, headersz is set to 64B long. Therefore, sometimes the rxvrdy signal is asserted when the port buffer has 64B. Then, the Receive State machine tries to fill 2 RFIFO elements from the data that exists in the port buffer. For sure, there are sufficient data to fill one RFIFO element. However, the second element may not be filled completely with valid data. The RCV_CNTL register, however, erroneously reports: 1. That two elements where filled, 2. That all bytes of the second element are valid. I checked the contents of the second RFIFO and found that the last 16 bytes were replicas of the last four correctly received bytes of the second MPKT. That is, if the MPKT in longwords was : ABCD EFGH IJKL MNOP, the received was : ABCD EFGH IJKL KLKL. The solution was to set the "headersz" value to 128B. Another solution would be to set the port not to signal rxvrdy when the header is available, however the driver giga_drv.o needs to be modified so as to allow the chacge of the specific bit of the port_mode register. That's all, Yannis Haritakis, www.ics.forth.gr www.csd.uoc.gr