Ok managed to reproduce it on Linux by setting interval in config.h to
1ms and the patch fixes it. Thanks :)
Am Fr., 15. Feb. 2019 um 00:20 Uhr schrieb Michael Buch
<michaelbuch12_AT_gmail.com>:
>
> Ah I see, thanks for the example. Sorry, I overlooked your initial
> email since it wasn't part of your patch mail. The patch seems fine
> then, but I don't run OpenBSD at the moment and on the other platforms
> this never occurred to me but perhaps someone who has encountered this
> or can reproduce it with a trace can chime in.
>
> Thanks,
> Michael
>
> Am Do., 14. Feb. 2019 um 23:41 Uhr schrieb Ingo Feinerer <feinerer_AT_logic.at>:
> >
> > On Thu, Feb 14, 2019 at 09:16:23PM +0000, Michael Buch wrote:
> > > Thanks for changing, on second thought though, I have my doubts about this
> > > situation being possible. The cp times are millisecond increments since
> > > boot and would only not increment from our perspective if we sampled at
> > > submillisecond frequency. You can maximally
> > > configure slstatus to 1ms so I dont think we need a check here
> > > Did this happen to you?
> >
> > Yes, as I wrote in my initial explanatory mail
> > (https://lists.suckless.org/hackers/1902/16697.html) this happens
> > regularly (but not always) after a suspend and resume cycle on OpenBSD.
> > This causes slstatus to crash.
> >
Received on Fri Feb 15 2019 - 04:11:09 CET