On Wed, 27 Apr 2022 11:27:59 -0400 Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > I'm able to trigger this on x86 64bit too. > > One thing I noticed, is that the two numbers I have (from a different > trace, but very similar to the above) > > $ printf "%llx\n" 498151194674148935 > 6e9c9df4afd3647 > > $ printf "%llx\n" 1651072699280995911 > 16e9c9df4afd3647 > > That is, the last nibble either is 0 or 1, causing the change? > > 06e9c9df4afd3647 > 16e9c9df4afd3647 > > The numbers are the same except for that last nibble. And I just realized what the issue is. The ring buffer only allows for 59 bits of timestamp, as there's times it needs to inject a timestamp into the buffer, which is 16 bytes, and the first 5 bits are meta data, leaving 59 bits for the timestamp. Since no timestamp came close to that before this timer, everything worked. Thus, when a full timestamp is injected, it takes off the 5 MSBs of the timestamp (which took off that 1) and that is what is happening. I can see if I can play some games to detect this and replace the top 5 bits with the saved timestamp at the head of the sub buffer. -- Steve
