public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: "ananth@in.ibm.com" <ananth@in.ibm.com>,
	Ingo Molnar <mingo@elte.hu>, Yinghai Lu <yinghai@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"stable@kernel.org" <stable@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Subject: Re: [PATCH] Revert 2fbd07a5f so machines with BSPs phsyical apic id != 0 can boot
Date: Mon, 11 Jan 2010 16:46:38 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1001111641180.17145@localhost.localdomain> (raw)
In-Reply-To: <1263253513.2859.833.camel@sbs-t61.sc.intel.com>



On Mon, 11 Jan 2010, Suresh Siddha wrote:
> 
> Linus, We are in -rc3 and thought we have few days atleast to sort it
> out and post the correct fix to the problem, rather than do a quick
> revert (as we know that the current code is not fundamentally broken).

You seem to think that -rc3 is "early". It's not. 

Also, you seem to dismiss the fact that the commit has been reported to 
break real machines, and then you try to blame the MACHINE instead of 
blaming the commit. 

That makes me irritated. I don't understand why it's so hard for people to 
see that if there is a problem IT NEEDS TO BE FIXED.

The default action should not be "let's keep the problem and then try to 
figure it out". No, the default action is "let's FIX the problem first!"

Once the problem is fixed, you have as much time as you want to try to 
figure out why it happened in the first time. But we do _not_ just keep a 
broken kernel around because you don't know what is broken. 

> But if you want to revert, I have appended a patch to revert this, which
> has the correct subject, description etc atleast. I can work with Ananth
> and re-submit this for the next release.

Quite frankly, I hope the "re-submit" is not actually that. There's no 
point in submitting something like this again. I still think that the 
whole "let's have different code-paths for Intel and AMD" thing is just 
plain crazy. There's no reason to do this.

For example, quite apart from the actual problem report, your patch causes 
the x86-64 code to simply become UGLIER AND LESS MAINTAINABLE. That whole 
intel-vs-amd issue is total black magic, with no comments and no reason.

So no. I'm not going to take a resubmission. 

		Linus

  parent reply	other threads:[~2010-01-12  0:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-09 10:10 [PATCH] Make Intel 8-way Xeons boot again Ananth N Mavinakayanahalli
2010-01-09 18:11 ` Linus Torvalds
2010-01-09 22:51   ` Yinghai Lu
2010-01-11 17:38   ` Suresh Siddha
2010-01-09 21:13 ` Yinghai Lu
2010-01-10  2:30   ` Ananth N Mavinakayanahalli
2010-01-10  6:35     ` Yinghai Lu
2010-01-10 10:26       ` Ingo Molnar
2010-01-11  4:53         ` [PATCH] Revert 2fbd07a5f so machines with BSPs phsyical apic id != 0 can boot Ananth N Mavinakayanahalli
2010-01-11 21:39           ` Suresh Siddha
2010-01-11 22:55             ` Linus Torvalds
2010-01-11 23:45               ` Suresh Siddha
2010-01-11 23:51                 ` Suresh Siddha
2010-01-12  0:46                 ` Linus Torvalds [this message]
2010-01-12  0:50                   ` Linus Torvalds
2010-01-12  2:27                   ` Suresh Siddha
2010-01-14  0:03           ` Yuhong Bao
2010-01-11 21:43         ` [PATCH] Make Intel 8-way Xeons boot again Yinghai Lu
2010-01-11 21:53           ` Suresh Siddha
2010-01-12 19:10             ` Yinghai Lu
2010-01-12 20:20               ` Suresh Siddha
2010-01-12 21:02                 ` H. Peter Anvin
2010-01-12 21:07                   ` Suresh Siddha
2010-01-12 22:46     ` Suresh Siddha
2010-01-13  4:42       ` Ananth N Mavinakayanahalli

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.LFD.2.00.1001111641180.17145@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stable@kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=venkatesh.pallipadi@intel.com \
    --cc=yinghai@kernel.org \
    /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