From: Thomas Gleixner <tglx@linutronix.de>
To: speck@linutronix.de
Subject: Re: Re: [patch V4 13/13] x86/apic: Ignore secondary threads if nosmt=force
Date: Fri, 29 Jun 2018 20:36:39 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1806292033080.1595@nanos.tec.linutronix.de> (raw)
In-Reply-To: <alpine.LFD.2.21.999.1806291003430.3418@i7.lan>
On Fri, 29 Jun 2018, speck for Linus Torvalds wrote:
> On Fri, 29 Jun 2018, speck for Luck, Tony wrote:
> >
> > MCi_CTL may or may not save you. Banks are shared across cores or the
> > whole package. So if you bring any CPU online that shares the bank that
> > reports the error, then the offline CPUs that share that bank will have
> > the machine check enabled.
> >
> > For the hyper-thread disabled case you are guaranteed to be screwed.
>
> Can we ask people inside intel to
>
> (a) get a babysitter for the people who designed MCE? They need a
> pacifier and/or a banana. It's not like this is the first time we hit
> a "christ, this is so stupid that clearly no adult ever checked it"
> issue with the garbage that Intel calls machine checks.
>
> (b) Get an adult to supervise and fix MCE once and for all for future
> CPU's.
>
> Honestly, MCE's are broken garbage. The whole "let's broadcast this shit
> to random CPU's" was incredibly broken from the very beginning. Adding
> this "let's initialize CPU's in a mode that is guaranteed to be broken" is
> just icing on the shit-cake that is MCE.
>
> Seriously. We've complained about MCE before. There must be people inside
> intel who are just twiddling their thumbs waiting for the process people
> get their shit together some day next decade, could some of them perhaps
> be made to look at MCE?
The thumb twiddlers might be already members of the Massive Cake
Engineering departement.
next prev parent reply other threads:[~2018-06-29 18:36 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 20:19 [patch V4 00/13] SMT control knobs Thomas Gleixner
2018-06-20 20:19 ` [patch V4 01/13] sched/smt: Update sched_smt_present at runtime Thomas Gleixner
2018-06-20 20:19 ` [patch V4 02/13] x86/smp: Provide topology_is_primary_thread() Thomas Gleixner
2018-06-27 13:56 ` [MODERATED] " Josh Poimboeuf
2018-06-27 15:54 ` Thomas Gleixner
2018-06-27 16:20 ` [MODERATED] " Josh Poimboeuf
2018-06-27 16:52 ` Thomas Gleixner
2018-06-20 20:19 ` [patch V4 03/13] cpu/hotplug: Make bringup/teardown of smp threads symmetric Thomas Gleixner
2018-06-20 20:19 ` [patch V4 04/13] cpu/hotplug: Split do_cpu_down() Thomas Gleixner
2018-06-20 20:19 ` [patch V4 05/13] cpu/hotplug: Provide knobs to control SMT Thomas Gleixner
2018-06-20 23:05 ` [MODERATED] " Greg KH
2018-06-21 6:08 ` Thomas Gleixner
2018-06-20 20:19 ` [patch V4 06/13] x86/cpu: Remove the pointless CPU printout Thomas Gleixner
2018-06-20 20:19 ` [patch V4 07/13] x86/cpu/AMD: Remove the pointless detect_ht() call Thomas Gleixner
2018-06-20 20:19 ` [patch V4 08/13] x86/cpu/common: Provide detect_ht_early() Thomas Gleixner
2018-06-20 20:19 ` [patch V4 09/13] x86/cpu/topology: Provide detect_extended_topology_early() Thomas Gleixner
2018-06-20 20:19 ` [patch V4 10/13] x86/cpu/intel: Evaluate smp_num_siblings early Thomas Gleixner
2018-06-20 20:19 ` [patch V4 11/13] x86/CPU/AMD: Do not check CPUID max ext level before parsing SMP info Thomas Gleixner
2018-06-20 20:19 ` [patch V4 12/13] x86/cpu/AMD: Evaluate smp_num_siblings early Thomas Gleixner
2018-06-20 20:19 ` [patch V4 13/13] x86/apic: Ignore secondary threads if nosmt=force Thomas Gleixner
2018-06-20 21:44 ` [MODERATED] " Linus Torvalds
2018-06-28 22:13 ` Dave Hansen
2018-06-28 22:19 ` Andrew Cooper
2018-06-28 22:23 ` Luck, Tony
2018-06-28 22:29 ` Andrew Cooper
2018-06-29 8:26 ` [MODERATED] " Borislav Petkov
2018-06-29 17:01 ` Luck, Tony
2018-06-29 17:08 ` Linus Torvalds
2018-06-29 18:36 ` Thomas Gleixner [this message]
2018-06-29 8:50 ` Thomas Gleixner
2018-06-29 16:48 ` [MODERATED] " Dave Hansen
2018-06-20 20:53 ` [patch V4 00/13] SMT control knobs Thomas Gleixner
2018-06-21 11:52 ` [MODERATED] " Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1806292033080.1595@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=speck@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).