linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Rusty Russell <rusty@rustcorp.com.au>, Andi Kleen <ak@suse.de>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch 0/3] Per cpu relocation to ZERO and x86_32 percpu ops on x86_64
Date: Fri, 30 Nov 2007 11:59:59 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0711301147100.2242@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20071130194517.GD9928@elte.hu>

On Fri, 30 Nov 2007, Ingo Molnar wrote:

> This was not any "formal" x86 maintainance activity - your patches are 
> still cooking. But i was thinking about maybe putting these patches into 
> the x86 test grind to get them shaken out some more the random 1000 
> bootup tests a day that it does. When integrating your patches I found a 
> bug and tentatively reported it to you, pointing out that it could 
> easily be my merge fault. Basically i was offering you to let your 
> patches cook in another kitchen as well. I never before had a negative 
> response to that :-/

You could have asked me for a patch against the x86 tree instead of 
forcing these into your tree. Then I could have made sure that everything 
is okay for your tests, I would have put the stuff into a git tree for you 
to pull etc. I'd be glad if you would test this but if at least if you get 
these kinds of rejects then its probably wise to stop and reconsider your 
approach.

> > I am a bit surprised since Andi and I never had this issue.
> 
> huh??? I am really wondering where this hostile attitude of yours comes 
> from. Getting patches build and boot is something architecture 
> maintainers do on a regular basis, it's a minimum requirement before 
> getting something merged into an architecture.

Hostile? AFAICT this is not the usual way how things are handled with mm 
patches. Preparing a patch against mainline would take some doing.
 
> And btw., -rc3-mm2 seems to have grown a spontaneous reboot problem, 
> that looks quite similar to what i saw:
> 
>   http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm2/announce.txt

Side swipe against mm? ;-) mm2 works fine here. What is so bad about mm?

> so from now on i guess i'll have to tag you as "does not want any 
> advance testing and review help with his patches" person and will leave 
> you alone.

I have tried to help you as best as I could in a endeavor that I 
expected to be fruitless while warning you not to go down that route.

I am in the same situation supposed to go on vacation from today till the 
12th. I took some hours to test your config and figure out how to clean up 
the mess.


  reply	other threads:[~2007-11-30 20:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-30  6:43 [patch 0/3] Per cpu relocation to ZERO and x86_32 percpu ops on x86_64 Christoph Lameter
2007-11-30  6:43 ` [patch 1/3] Percpu infrastructure to rebase the per cpu area to 0UL Christoph Lameter
2007-12-02  3:04   ` Rusty Russell
2007-12-02  3:13   ` Rusty Russell
2007-11-30  6:43 ` [patch 2/3] X86_64: Declare pda as per cpu data thereby moving it into the cpu area Christoph Lameter
2007-11-30  6:43 ` [patch 3/3] x86_64: Make the x86_32 percpu operations usable on x86_64 Christoph Lameter
2007-11-30 20:07   ` Christoph Lameter
2007-11-30 11:24 ` [patch 0/3] Per cpu relocation to ZERO and x86_32 percpu ops " Ingo Molnar
2007-11-30 11:26   ` Ingo Molnar
2007-11-30 17:08     ` Christoph Lameter
2007-11-30 17:19     ` Christoph Lameter
2007-11-30 18:00       ` Ingo Molnar
2007-11-30 18:24         ` Christoph Lameter
2007-11-30 18:35           ` Ingo Molnar
2007-11-30 18:47             ` Christoph Lameter
2007-11-30 19:45               ` Ingo Molnar
2007-11-30 19:59                 ` Christoph Lameter [this message]
2007-11-30 20:06                   ` Ingo Molnar
2007-11-30 20:09                     ` Christoph Lameter
2007-11-30 20:26                   ` Ingo Molnar
2007-11-30 20:43                     ` Ingo Molnar
2007-11-30 18:41           ` Ingo Molnar
2007-11-30 18:43             ` Christoph Lameter

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=Pine.LNX.4.64.0711301147100.2242@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@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 NNTP newsgroup(s).