On Mon, Apr 04 2022 at 10:37, Johannes Berg wrote:
> On Mon, 2022-04-04 at 10:32 +0200, Thomas Gleixner wrote:
>> --- a/kernel/time/timer.c
>> +++ b/kernel/time/timer.c
>> @@ -1724,9 +1724,8 @@ static inline void __run_timers(struct t
>> /*
>> * The only possible reason f
On Mon, 2022-04-04 at 10:32 +0200, Thomas Gleixner wrote:
> On Mon, Apr 04 2022 at 09:02, Johannes Berg wrote:
> > On Sun, 2022-04-03 at 21:51 +0200, Thomas Gleixner wrote:
> > > but that's fine and it is overwritten by every timer which is inserted
> > > to expire before that. So that's not an iss
On Mon, Apr 04 2022 at 09:02, Johannes Berg wrote:
> On Sun, 2022-04-03 at 21:51 +0200, Thomas Gleixner wrote:
>> but that's fine and it is overwritten by every timer which is inserted
>> to expire before that. So that's not an issue as the prandom timer is
>> firing and rearmed.
>
> No, as I said
On Sun, 2022-04-03 at 21:51 +0200, Thomas Gleixner wrote:
>
> > There was no timer. If there's ever a timer on this base (BASE_DEF) then
> > this doesn't happen.
>
> You said:
>
> > > > init_timer_cpu(0) base 0 clk=0x8ad0, next_expiry=0x13fff8acf
> > > > init_timer_cpu(0) base 1 clk=0x8a
Johannes,
On Sun, Apr 03 2022 at 19:19, Johannes Berg wrote:
> Actually, in a sense, this *is* the case of (just) recalculating
> next_expiry, no? We just never set next_expiry_recalc since there was
> never any timer on this?
why are you insisting on fishing in the dark?
> So actually this als
On Sun, Apr 03 2022 at 19:13, Johannes Berg wrote:
> On Sun, 2022-04-03 at 18:18 +0200, Thomas Gleixner wrote:
>> On Sat, Apr 02 2022 at 16:09, Johannes Berg wrote:
> There was no timer. If there's ever a timer on this base (BASE_DEF) then
> this doesn't happen.
You said:
>> > init_timer_cpu(0) b
On Sun, 2022-04-03 at 19:13 +0200, Johannes Berg wrote:
> On Sun, 2022-04-03 at 18:18 +0200, Thomas Gleixner wrote:
> > On Sat, Apr 02 2022 at 16:09, Johannes Berg wrote:
> > > At init, we get
> > >
> > > init_timer_cpu(0) base 0 clk=0x8ad0, next_expiry=0x13fff8acf
> > > init_timer_cpu(0) base
On Sun, 2022-04-03 at 18:18 +0200, Thomas Gleixner wrote:
> On Sat, Apr 02 2022 at 16:09, Johannes Berg wrote:
> > At init, we get
> >
> > init_timer_cpu(0) base 0 clk=0x8ad0, next_expiry=0x13fff8acf
> > init_timer_cpu(0) base 1 clk=0x8ad0, next_expiry=0x13fff8acf
> >
> > which makes sens
On Sat, Apr 02 2022 at 16:09, Johannes Berg wrote:
> At init, we get
>
> init_timer_cpu(0) base 0 clk=0x8ad0, next_expiry=0x13fff8acf
> init_timer_cpu(0) base 1 clk=0x8ad0, next_expiry=0x13fff8acf
>
> which makes sense, jiffies is set up to wrap very quickly after boot.
>
> The warning trig
Hi Vincent,
> [10737482.72][C0] [ cut here ]
> [10737482.72][C0] WARNING: CPU: 0 PID: 0 at kernel/time/timer.c:1729
> __run_timers+0x36d/0x380
>
[for those new on the thread, full message and config here:
https://lore.kernel.org/r/20220330110156.ga9...@a
On Sat, 2022-04-02 at 16:09 +0200, Johannes Berg wrote:
>
> (I put a WARN_ON into get_timer_cpu_base() and get_timer_this_cpu_base()
> in the if, and it never triggered; I guess my config has something that
> creates a deferrable timer, so it didn't trigger, but I didn't check
> that now.)
>
OK,
On Wed, 2022-03-30 at 13:01 +0200, Vincent Whitchurch wrote:
> Hello Johannes,
>
> As requested in the roadtest thread[0], here is some information about
> reproducing the warnings I'm seeing from the timekeeping code with time
> travel in UML, after about 10-20 wall time seconds of idling.
>
> [
Hello Johannes,
As requested in the roadtest thread[0], here is some information about
reproducing the warnings I'm seeing from the timekeeping code with time
travel in UML, after about 10-20 wall time seconds of idling.
[0]
https://lore.kernel.org/lkml/5b39d572e619c812109af7a1b8028bfb8353efda.c
13 matches
Mail list logo
