On Wed, Nov 10, 2021 at 03:45:06PM +0200, Andriy Gapon wrote:
> On 10/11/2021 11:30, Andriy Gapon wrote:
> > On 09/11/2021 17:56, Andriy Gapon wrote:
> > > So, as I was saying, when the delta is large the calculations in
> > > tc_windup and bintime_off give slightly different results and that
> > >
On 10/11/2021 11:30, Andriy Gapon wrote:
On 09/11/2021 17:56, Andriy Gapon wrote:
So, as I was saying, when the delta is large the calculations in tc_windup and
bintime_off give slightly different results and that can lead to a
discontinuity of the time when timehands are switched.
A quick fo
On 09/11/2021 17:56, Andriy Gapon wrote:
So, as I was saying, when the delta is large the calculations in tc_windup and
bintime_off give slightly different results and that can lead to a discontinuity
of the time when timehands are switched.
A quick follow-up.
I think that both tc_windup and b
On Tue, Nov 09, 2021 at 11:58:30AM +0200, Andriy Gapon wrote:
Here is an explanation for the numbers reported in the panic message (sorted
from earliest to latest):
190543869603412 - 'now' as seen in sleepq_timeout(), returned by sbinuptime();
190543869738008 - td_sleeptimo, also c_time in the ca
On Tue, Nov 09, 2021 at 11:58:30AM +0200, Andriy Gapon wrote:
>
> Two years have passed since my original report, some things have changed,
> but we are still seeing the problem.
>
> To recap, the problem is that sometimes a callout for a sleepq timeout would
> fire to early. The code in sleepq_
Two years have passed since my original report, some things have changed, but we
are still seeing the problem.
To recap, the problem is that sometimes a callout for a sleepq timeout would
fire to early. The code in sleepq_timeout would ignore such a wake-up. And, as
there would not be ano
On 22/10/2019 16:16, Konstantin Belousov wrote:
> On Tue, Oct 22, 2019 at 02:48:56PM +0300, Andriy Gapon wrote:
>> On 22/10/2019 13:44, Konstantin Belousov wrote:
>>> On Tue, Oct 22, 2019 at 01:08:59PM +0300, Andriy Gapon wrote:
Has anyone seen anything like this problem?
>>> Yes, but it was v
On Tue, Oct 22, 2019 at 02:48:56PM +0300, Andriy Gapon wrote:
> On 22/10/2019 13:44, Konstantin Belousov wrote:
> > On Tue, Oct 22, 2019 at 01:08:59PM +0300, Andriy Gapon wrote:
> >>
> >> We observe a problem that happens very rarely (about once a month across
> >> many
> >> test machines). The p
On 22/10/2019 13:44, Konstantin Belousov wrote:
> On Tue, Oct 22, 2019 at 01:08:59PM +0300, Andriy Gapon wrote:
>>
>> We observe a problem that happens very rarely (about once a month across many
>> test machines). The problem is that a thread remain in sleepq_timedwait()
>> even
>> after its tim
On Tue, Oct 22, 2019 at 01:08:59PM +0300, Andriy Gapon wrote:
>
> We observe a problem that happens very rarely (about once a month across many
> test machines). The problem is that a thread remain in sleepq_timedwait()
> even
> after its timeout expires. The thread's td_slpcallout looks like t
We observe a problem that happens very rarely (about once a month across many
test machines). The problem is that a thread remain in sleepq_timedwait() even
after its timeout expires. The thread's td_slpcallout looks like the callout
has fired. But the thread's state looks like it was never no
11 matches
Mail list logo
