On Fri Apr 12, 2024 at 2:21 AM EEST, William Brown wrote: > > > > On 12 Apr 2024, at 08:50, Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > > > On Thu Apr 4, 2024 at 6:49 PM EEST, James Bottomley wrote: > >> On Thu, 2024-04-04 at 18:09 +0300, Jarkko Sakkinen wrote: > >>> [...] > >>> Emphasis that I might have forgotten something but this is what I can > >>> remember right now. > >> > >> What you forgot is that I did originally proposed session degapping in > >> the kernel resource manager but it was rather complex, so you made me > >> take it out for lack of a use case. It dates back to when we used the > >> old sourceforge tpmdd list which seems to have caused message loss, so > >> I'm not sure how complete this thread is: > > > > I might be forgetting some detail to contxt gap but since kernel flushes > > every single object per transaction contextCounter should be updated all > > the time and thus there should not be too large gap that would cause > > emitting this error. > > > > I quickly reviewed section 30.5 for architecture specificaton to check > > if I got it right and it says that: "On receiving this error, the > > management software either would explicitly flush old session contexts > > or would load the old session contexts to update their associated > > counter values.." > > The issue is that we *are* flushing session contexts and this error is still occurring. Was there a way that I could reproduce the same workload or something simpler that would reproduce the issue on my side? BR, Jarkko
