linux-kernel - Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1587553284.9537.96.camel@suse.cz>
Date:   Wed, 22 Apr 2020 13:01:24 +0200
From:   Giovanni Gherdovich <ggherdovich@...e.cz>
To:     Harald Arnesen <harald@...gtun.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Kleikamp <dave.kleikamp@...cle.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2)

On Wed, 2020-04-22 at 12:22 +0200, Harald Arnesen wrote:
> Harald Arnesen [22.04.2020 11:37]:
> 
> > Giovanni Gherdovich [22.04.2020 11:02]:
> > > 
> > > Harald:
> > > 
> > > I'll echo Linus' request of testing that the patch series linked above fixes
> > > the problem on your machine. Since you're testing -rc kernels and bisecting
> > > bugs I assume you're comfortable with patching and compiling kernels, but if
> > > that is not the case I am more than happy to assist by providing either an RPM
> > > or a DEB package, depending on the distribution you're running. Let me know.
> > Will try patching first, if I'm not successful, you may compile a DEB
> > package for me.
> 
> I can confirm that my Thinkpad T510i boots normally with the four
> patches added.
> 
> Thanks!

That's awesome, thank you for testing.

Regarding the turbostat output you attached to an earlier email, it confirms
the suspicion that the 4C turbo is reported as zero (being a 2 cores / 4 threads
machine), explaining why the fix works:

  cpu2: MSR_TURBO_RATIO_LIMIT: 0x00001313
  19 * 133.3 = 2533.3 MHz max turbo 2 active cores
  19 * 133.3 = 2533.3 MHz max turbo 1 active cores

In the above, bits 31:24 are zero. It's not a universal rule, though: my laptop
also has a 2 cores / 4 threads cpu, and that same MSR says:

  cpu3: MSR_TURBO_RATIO_LIMIT: 0x1b1b1b1b1b1d
  27 * 100.0 = 2700.0 MHz max turbo 6 active cores
  27 * 100.0 = 2700.0 MHz max turbo 5 active cores
  27 * 100.0 = 2700.0 MHz max turbo 4 active cores
  27 * 100.0 = 2700.0 MHz max turbo 3 active cores
  27 * 100.0 = 2700.0 MHz max turbo 2 active cores
  29 * 100.0 = 2900.0 MHz max turbo 1 active cores

So despite my CPU being similar to yours, it wouldn't show the bug. There is
even more: the bug can show on large core counts too, as seen in
https://lore.kernel.org/lkml/bf43772d-48e5-01d4-dd03-330110e487fa@linux.intel.com/
Like Xu from Intel has an Atom P-Series with 24 physical cores, yet their
MSR goes like:

  MSR_TURBO_RATIO_LIMIT: 0x00000016

which means only the 1C turbo is reported non-zero (that machine doesn't have
turbo at all, 1C turbo is the same as base frequency).


Thanks,
Giovanni