[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <395f63b5-a24b-0eb9-4cb2-06057c1882d8@skogtun.org>
Date: Wed, 22 Apr 2020 11:32:53 +0200
From: Harald Arnesen <harald@...gtun.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Giovanni Gherdovich <ggherdovich@...e.cz>
Subject: Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2)
Linus Torvalds [21.04.2020 21:03]:
> On Mon, Apr 20, 2020 at 1:52 AM Harald Arnesen <harald@...gtun.org> wrote:
>>
>> Neither rc1 nor rc2 will boot on my laptop. The attached picture is all
>> I have been able to capture.
>
> I know you saw the reply about this probably being fixed by
>
> https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@suse.cz/
>
> but it would be lovely if you could actually verify that that series
> of four patches does indeed fix it for you.
>
> Your oops is on that divide instruction:
>
> freq_scale = div64_u64(acnt, mcnt);
>
> and while we had a check for mcnt not being zero earlier, we did
>
> mcnt *= arch_max_freq_ratio;
>
> after that check. I could see it becoming zero either due to an
> overflow, or due to arch_max_freq_ratio being 0.
>
> I think the first commit in that series is supposed to fix that
> arch_max_freq_ratio being 0 case, but it still feels like the code
> that does the divide is checking for zero in the wrong place...
>
> Linus
I will try the patches today, and report back.
--
Hilsen Harald
Powered by blists - more mailing lists