The current implementation of the ethernet driver exposes some bugs in the way the driver treats egress timestamps: If the driver starts filling in the time-stamps in the 'cptsCacheEvent' structure, then it can happen that 'stale' entries lead to wrong timestamps being reported back to upper layers.
The issue was detected when we had multiple packets where egress time-stamping was requested. Let's say there's a transmit packet A buffer sequence ID X and packet B sequence ID Y for which egress timestamps are requested. However the egress timestamps for buffer sequence Y are not queried for some reason.
In this situation the egress timestamps of B with sequence ID Y can be put into the cache variable 'cptsCacheEvent' by the function CpswCpts_cacheUpdate. If there is no 'query' (i.e.: call to CpswCpts_cacheLookUp with the given sequence Y) of the cache entry, this entry can remain indefinitely in the cache being marked as belonging to sequence 'Y' and remaining marked as 'valid'.
However the sequence numbers are currently assigned based on the ethernet buffer indices - which can be re-used. If at a later point in time the packet 'A' is again re-transmitted from the ethernet buffer 'Y' (assigning sequence ID Y to it), then the subsequent high-level query of the egress timestamp of packet 'A' will provide an erronous result as the function CpswCpts_getHostEgressTimeStamp first always checks the cache, which may still contain the 'stale' entry for packet 'B' with sequence ID 'Y'.
To summarize: based on the above scenario it seems that the cache-handling/buffer-assignment is broken in the driver. It seems advisable to clear any stale cache entries when a buffer is re-assigned for a new message.