Date:	Fri, 12 Dec 2008 10:10:50 -0800
From:	Mike Travis <travis@....com>
To:	Ingo Molnar <mingo@...e.hu>, Rusty Russell <rusty@...tcorp.com.au>
CC:	Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] x86: fix assign_irq_vector boot up problem

Ingo Molnar wrote:
> * Rusty Russell <rusty@...tcorp.com.au> wrote:
> 
>> On Thursday 11 December 2008 21:58:07 Mike Travis wrote:
>>> Impact: fix boot up problem.
>>>
>>> Fix a problem encountered with the Intel SATA-AHCI disk driver
>>> right at system startup.  Cpumask_intersects really needs to be
>>> a 3-way intersect, and since we need a cpumask_var_t later on,
>>> then just use it for the 3-way intersect as well.
>> This one looks fine.
>>
>> My plan was for Ingo to pull that for-ingo tree into his cpus4096 tree 
>> and take the x86 patches from there.  But he hasn't so maybe I should 
>> take this chance to fold that patch in?
> 
> i have no objections against the bits - just the sparseirq complication 
> came in. A lot of effort went into irq/sparseirq's io_apic.c changes and 
> cleanup.
> 
> So to do this cleanly, i merged those bits into cpus4096 and the 
> x86/reboot bits as well - now the plan would be for Mike to send a 
> (rebased) series against that base. I tried a plain merge and the 
> conflicts in io_apic.c were a horrendous 76 rejects due to the 
> irq/sparseirq interaction. Also, some of the commits subjects looked a 
> bit raw so this bit of the tree needs to be redone.
> 
> (Note that the existing cpumask-base+scheduler bits in cpus4096 are 
> golden already and we dont have to touch them in any way, it's just the 
> new x86 bits and new cpumask infrastructure bits that look odd or 
> clashy.)
> 
> 	Ingo

I have the merged result for io_apic and I believe it should also be
very clean in respect that it maintains the logic of of both patchsets
accurately. (About 6 hours to work through the complete file.)

What I'm confused about is how I'm to send this re-basing?  Do you only
want the patches in:

	.../pub/scm/linux/kernel/git/rusty/linux-2.6-for-ingo.git

And I've no clue how to cause a git tree to rebase.  What I can do is extract
them into quilt patches, reapply and fix conflicts, and then send them
(as quilt patches).  I'll do that today, and if you need a git tree to pull from,
then we'll figure out how to do that (with Rusty's help as again, I do not
have an external source to provide one.)

Also, you mention in separate mail:

    Please tidy up the commit logs of new cpumask bits and dont leave bits in 
    it like:

     e861b55: cpumask: Add CONFIG_CPUMASK_OFFSTACK
     65bda29: cpumask:clock_event_device-takes-cpumask-ptr
     07d73a8: cpumask:irq-functions-take-cpumask_t-ptr
     01fdd7d: cpumask:convert-few-difficult-cpumask_t-users
     9cc67bb: cpumask:centralize-common-maps

These patches went in via linux-next/rr, and are not part of the x86 patchset that
I'm working on.  I can only offer to help resolve the conflicts though again, I'm
not sure how I send them to you?  Would it be the commit from a "merge conflict
resolution" sent as a git-bundle?  [I've not done this yet so I'm really guessing.]

The tree for these changes are in:

	.../pub/scm/linux/kernel/git/rusty/linux-2.6-cpumask.git

and they include many, many non-x86 arch files, so sending them to you is not what
should be done, yes?

Rusty - can you fix these subject lines in your git tree?

Thanks!
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists