linux-next: manual merge of the rr_cpumask tree

linux-next: manual merge of the rr_cpumask tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr_cpumask tree got a conflict in
arch/x86/kernel/io_apic.c between commit
3145e941fcfe2548fa2270afb1a05bab3a6bc418 ("x86, MSI: pass irq_cfg and
irq_desc") from the sparseirq tree and commit
0de26520c7cabf36e1de090ea8092f011a6106ce ("cpumask: make irq_set_affinity
() take a const struct cpumask") from the rr_cpumask tree.

There are lots of overlapping changes.  I fixed it up (see below) and can carry the
fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc arch/x86/kernel/io_apic.c
index 23f3141,1184210..0000000
--- a/arch/x86/kernel/io_apic.c
+++ b/arch/x86/kernel/io_apic.c
@@@ -396,48 -359,37 +396,49 @@@ static void __target_IO_APIC_irq(unsign
  	}
  }
  
 -static int assign_irq_vector(int irq, cpumask_t mask);
 +static int assign_irq_vector(int irq, struct irq_cfg *cfg, cpumask_t mask);
  
- static void set_ioapic_affinity_irq_desc(struct irq_desc *desc, cpumask_t mask)
 -static void set_ioapic_affinity_irq(unsigned int irq,
++static void set_ioapic_affinity_irq_desc(struct irq_desc *desc,
+ 				    const struct cpumask *mask)
  {
  	struct irq_cfg *cfg;
  	unsigned long flags;
  	unsigned int dest;
  	cpumask_t tmp;
 -	struct irq_desc *desc;
 +	unsigned int irq;
  
- 	cpus_and(tmp, mask, cpu_online_map);
- 	if (cpus_empty(tmp))
+ 	if (!cpumask_intersects(mask, cpu_online_mask))
  		return;
  
 -	cfg = irq_cfg(irq);
 -	if (assign_irq_vector(irq, *mask))
 +	irq = desc->irq;
 +	cfg = desc->chip_data;
- 	if (assign_irq_vector(irq, cfg, mask))
++	if (assign_irq_vector(irq, cfg, *mask))
  		return;
  
- 	set_extra_move_desc(desc, mask);
++	set_extra_move_desc(desc, *mask);
 +
- 	cpus_and(tmp, cfg->domain, mask);
+ 	cpumask_and(&tmp, &cfg->domain, mask);
  	dest = cpu_mask_to_apicid(tmp);
  	/*
  	 * Only the high 8 bits are valid.
  	 */
  	dest = SET_APIC_LOGICAL_ID(dest);
  
 -	desc = irq_to_desc(irq);
  	spin_lock_irqsave(&ioapic_lock, flags);
 -	__target_IO_APIC_irq(irq, dest, cfg->vector);
 +	__target_IO_APIC_irq(irq, dest, cfg);
- 	desc->affinity = mask;
+ 	cpumask_copy(&desc->affinity, mask);
  	spin_unlock_irqrestore(&ioapic_lock, flags);
  }
 +
- static void set_ioapic_affinity_irq(unsigned int irq, cpumask_t mask)
++static void set_ioapic_affinity_irq(unsigned int irq,
++				    const struct cpumask *mask)
 +{
 +	struct irq_desc *desc;
 +
 +	desc = irq_to_desc(irq);
 +
 +	set_ioapic_affinity_irq_desc(desc, mask);
 +}
  #endif /* CONFIG_SMP */
  
  /*
@@@ -2281,22 -2198,19 +2282,24 @@@ static void ir_irq_migration(struct wor
  /*
   * Migrates the IRQ destination in the process context.
   */
- static void set_ir_ioapic_affinity_irq_desc(struct irq_desc *desc, cpumask_t mask)
 -static void set_ir_ioapic_affinity_irq(unsigned int irq,
++static void set_ir_ioapic_affinity_irq_desc(struct irq_desc *desc,
+ 				       const struct cpumask *mask)
  {
 -	struct irq_desc *desc = irq_to_desc(irq);
 -
  	if (desc->status & IRQ_LEVEL) {
  		desc->status |= IRQ_MOVE_PENDING;
- 		desc->pending_mask = mask;
+ 		cpumask_copy(&desc->pending_mask, mask);
 -		migrate_irq_remapped_level(irq);
 +		migrate_irq_remapped_level_desc(desc);
  		return;
  	}
  
- 	migrate_ioapic_irq_desc(desc, mask);
 -	migrate_ioapic_irq(irq, *mask);
++	migrate_ioapic_irq_desc(desc, *mask);
 +}
- static void set_ir_ioapic_affinity_irq(unsigned int irq, cpumask_t mask)
++static void set_ir_ioapic_affinity_irq(unsigned int irq,
++				       const struct cpumask *mask)
 +{
 +	struct irq_desc *desc = irq_to_desc(irq);
 +
 +	set_ir_ioapic_affinity_irq_desc(desc, mask);
  }
  #endif
  
@@@ -3145,64 -3028,61 +3148,63 @@@ static int msi_compose_msg(struct pci_d
  }
  
  #ifdef CONFIG_SMP
- static void set_msi_irq_affinity(unsigned int irq, cpumask_t mask)
+ static void set_msi_irq_affinity(unsigned int irq, const struct cpumask *mask)
  {
 +	struct irq_desc *desc = irq_to_desc(irq);
  	struct irq_cfg *cfg;
  	struct msi_msg msg;
  	unsigned int dest;
  	cpumask_t tmp;
 -	struct irq_desc *desc;
  
- 	cpus_and(tmp, mask, cpu_online_map);
- 	if (cpus_empty(tmp))
+ 	if (!cpumask_intersects(mask, cpu_online_mask))
  		return;
  
 -	if (assign_irq_vector(irq, *mask))
 +	cfg = desc->chip_data;
- 	if (assign_irq_vector(irq, cfg, mask))
++	if (assign_irq_vector(irq, cfg, *mask))
  		return;
  
- 	set_extra_move_desc(desc, mask);
 -	cfg = irq_cfg(irq);
++	set_extra_move_desc(desc, *mask);
 +
- 	cpus_and(tmp, cfg->domain, mask);
+ 	cpumask_and(&tmp, &cfg->domain, mask);
  	dest = cpu_mask_to_apicid(tmp);
  
 -	read_msi_msg(irq, &msg);
 +	read_msi_msg_desc(desc, &msg);
  
  	msg.data &= ~MSI_DATA_VECTOR_MASK;
  	msg.data |= MSI_DATA_VECTOR(cfg->vector);
  	msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
  	msg.address_lo |= MSI_ADDR_DEST_ID(dest);
  
 -	write_msi_msg(irq, &msg);
 -	desc = irq_to_desc(irq);
 +	write_msi_msg_desc(desc, &msg);
- 	desc->affinity = mask;
+ 	cpumask_copy(&desc->affinity, mask);
  }
 -
  #ifdef CONFIG_INTR_REMAP
  /*
   * Migrate the MSI irq to another cpumask. This migration is
   * done in the process context using interrupt-remapping hardware.
   */
- static void ir_set_msi_irq_affinity(unsigned int irq, cpumask_t mask)
+ static void ir_set_msi_irq_affinity(unsigned int irq,
+ 				    const struct cpumask *mask)
  {
 +	struct irq_desc *desc = irq_to_desc(irq);
  	struct irq_cfg *cfg;
  	unsigned int dest;
  	cpumask_t tmp, cleanup_mask;
  	struct irte irte;
 -	struct irq_desc *desc;
  
- 	cpus_and(tmp, mask, cpu_online_map);
- 	if (cpus_empty(tmp))
+ 	if (!cpumask_intersects(mask, cpu_online_mask))
  		return;
  
  	if (get_irte(irq, &irte))
  		return;
  
 -	if (assign_irq_vector(irq, *mask))
 +	cfg = desc->chip_data;
- 	if (assign_irq_vector(irq, cfg, mask))
++	if (assign_irq_vector(irq, cfg, *mask))
  		return;
  
- 	set_extra_move_desc(desc, mask);
 -	cfg = irq_cfg(irq);
++	set_extra_move_desc(desc, *mask);
 +
- 	cpus_and(tmp, cfg->domain, mask);
+ 	cpumask_and(&tmp, &cfg->domain, mask);
  	dest = cpu_mask_to_apicid(tmp);
  
  	irte.vector = cfg->vector;
@@@ -3225,9 -3105,9 +3227,9 @@@
  		cfg->move_in_progress = 0;
  	}
  
- 	desc->affinity = mask;
 -	desc = irq_to_desc(irq);
+ 	cpumask_copy(&desc->affinity, mask);
  }
 +
  #endif
  #endif /* CONFIG_SMP */
  
@@@ -3416,25 -3308,22 +3418,24 @@@ void arch_teardown_msi_irq(unsigned in
  
  #ifdef CONFIG_DMAR
  #ifdef CONFIG_SMP
- static void dmar_msi_set_affinity(unsigned int irq, cpumask_t mask)
+ static void dmar_msi_set_affinity(unsigned int irq, const struct cpumask *mask)
  {
 +	struct irq_desc *desc = irq_to_desc(irq);
  	struct irq_cfg *cfg;
  	struct msi_msg msg;
  	unsigned int dest;
  	cpumask_t tmp;
 -	struct irq_desc *desc;
  
- 	cpus_and(tmp, mask, cpu_online_map);
- 	if (cpus_empty(tmp))
+ 	if (!cpumask_intersects(mask, cpu_online_mask))
  		return;
  
 -	if (assign_irq_vector(irq, *mask))
 +	cfg = desc->chip_data;
- 	if (assign_irq_vector(irq, cfg, mask))
++	if (assign_irq_vector(irq, cfg, *mask))
  		return;
  
- 	set_extra_move_desc(desc, mask);
 -	cfg = irq_cfg(irq);
++	set_extra_move_desc(desc, *mask);
 +
- 	cpus_and(tmp, cfg->domain, mask);
+ 	cpumask_and(&tmp, &cfg->domain, mask);
  	dest = cpu_mask_to_apicid(tmp);
  
  	dmar_msi_read(irq, &msg);
@@@ -3445,9 -3334,9 +3446,9 @@@
  	msg.address_lo |= MSI_ADDR_DEST_ID(dest);
  
  	dmar_msi_write(irq, &msg);
- 	desc->affinity = mask;
 -	desc = irq_to_desc(irq);
+ 	cpumask_copy(&desc->affinity, mask);
  }
 +
  #endif /* CONFIG_SMP */
  
  struct irq_chip dmar_msi_type = {
@@@ -3479,25 -3368,22 +3480,24 @@@ int arch_setup_dmar_msi(unsigned int ir
  #ifdef CONFIG_HPET_TIMER
  
  #ifdef CONFIG_SMP
- static void hpet_msi_set_affinity(unsigned int irq, cpumask_t mask)
+ static void hpet_msi_set_affinity(unsigned int irq, const struct cpumask *mask)
  {
 +	struct irq_desc *desc = irq_to_desc(irq);
  	struct irq_cfg *cfg;
 -	struct irq_desc *desc;
  	struct msi_msg msg;
  	unsigned int dest;
  	cpumask_t tmp;
  
- 	cpus_and(tmp, mask, cpu_online_map);
- 	if (cpus_empty(tmp))
+ 	if (!cpumask_intersects(mask, cpu_online_mask))
  		return;
  
 -	if (assign_irq_vector(irq, *mask))
 +	cfg = desc->chip_data;
- 	if (assign_irq_vector(irq, cfg, mask))
++	if (assign_irq_vector(irq, cfg, *mask))
  		return;
  
- 	set_extra_move_desc(desc, mask);
 -	cfg = irq_cfg(irq);
++	set_extra_move_desc(desc, *mask);
 +
- 	cpus_and(tmp, cfg->domain, mask);
+ 	cpumask_and(&tmp, &cfg->domain, mask);
  	dest = cpu_mask_to_apicid(tmp);
  
  	hpet_msi_read(irq, &msg);
@@@ -3508,9 -3394,9 +3508,9 @@@
  	msg.address_lo |= MSI_ADDR_DEST_ID(dest);
  
  	hpet_msi_write(irq, &msg);
- 	desc->affinity = mask;
 -	desc = irq_to_desc(irq);
+ 	cpumask_copy(&desc->affinity, mask);
  }
 +
  #endif /* CONFIG_SMP */
  
  struct irq_chip hpet_msi_type = {
@@@ -3563,30 -3449,27 +3563,29 @@@ static void target_ht_irq(unsigned int 
  	write_ht_irq_msg(irq, &msg);
  }
  
- static void set_ht_irq_affinity(unsigned int irq, cpumask_t mask)
+ static void set_ht_irq_affinity(unsigned int irq, const struct cpumask *mask)
  {
 +	struct irq_desc *desc = irq_to_desc(irq);
  	struct irq_cfg *cfg;
  	unsigned int dest;
  	cpumask_t tmp;
 -	struct irq_desc *desc;
  
- 	cpus_and(tmp, mask, cpu_online_map);
- 	if (cpus_empty(tmp))
+ 	if (!cpumask_intersects(mask, cpu_online_mask))
  		return;
  
 -	if (assign_irq_vector(irq, *mask))
 +	cfg = desc->chip_data;
- 	if (assign_irq_vector(irq, cfg, mask))
++	if (assign_irq_vector(irq, cfg, *mask))
  		return;
  
- 	set_extra_move_desc(desc, mask);
 -	cfg = irq_cfg(irq);
++	set_extra_move_desc(desc, *mask);
 +
- 	cpus_and(tmp, cfg->domain, mask);
+ 	cpumask_and(&tmp, &cfg->domain, mask);
  	dest = cpu_mask_to_apicid(tmp);
  
  	target_ht_irq(irq, dest, cfg->vector);
- 	desc->affinity = mask;
 -	desc = irq_to_desc(irq);
+ 	cpumask_copy(&desc->affinity, mask);
  }
 +
  #endif
  
  static struct irq_chip ht_irq_chip = {
@@@ -3927,10 -3791,10 +3926,10 @@@ void __init setup_ioapic_dest(void
  
  #ifdef CONFIG_INTR_REMAP
  			if (intr_remapping_enabled)
- 				set_ir_ioapic_affinity_irq_desc(desc, mask);
 -				set_ir_ioapic_affinity_irq(irq, &mask);
++				set_ir_ioapic_affinity_irq_desc(desc, &mask);
  			else
  #endif
- 				set_ioapic_affinity_irq_desc(desc, mask);
 -				set_ioapic_affinity_irq(irq, &mask);
++				set_ioapic_affinity_irq_desc(desc, &mask);
  		}
  
  	}

Re: linux-next: manual merge of the rr_cpumask tree

[Rusty Russell]

On Monday 15 December 2008 16:39:45 Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next merge of the rr_cpumask tree got a conflict in
> arch/x86/kernel/io_apic.c between commit
> 3145e941fcfe2548fa2270afb1a05bab3a6bc418 ("x86, MSI: pass irq_cfg and
> irq_desc") from the sparseirq tree and commit
> 0de26520c7cabf36e1de090ea8092f011a6106ce ("cpumask: make irq_set_affinity
> () take a const struct cpumask") from the rr_cpumask tree.
> 
> There are lots of overlapping changes.  I fixed it up (see below) and can carry the
> fix as necessary.

I have performed this merge before.  The results are in
	git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-ingo.git

Ingo, can you pull these into cpus4096?  It's just the cpumask/cpus4096 merge.

Thanks,
Rusty.

Re: linux-next: manual merge of the rr_cpumask tree

[Mike Travis]

Rusty Russell wrote:
> On Monday 15 December 2008 16:39:45 Stephen Rothwell wrote:
>> Hi Rusty,
>>
>> Today's linux-next merge of the rr_cpumask tree got a conflict in
>> arch/x86/kernel/io_apic.c between commit
>> 3145e941fcfe2548fa2270afb1a05bab3a6bc418 ("x86, MSI: pass irq_cfg and
>> irq_desc") from the sparseirq tree and commit
>> 0de26520c7cabf36e1de090ea8092f011a6106ce ("cpumask: make irq_set_affinity
>> () take a const struct cpumask") from the rr_cpumask tree.
>>
>> There are lots of overlapping changes.  I fixed it up (see below) and can carry the
>> fix as necessary.
> 
> I have performed this merge before.  The results are in
> 	git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-ingo.git
> 
> Ingo, can you pull these into cpus4096?  It's just the cpumask/cpus4096 merge.
> 
> Thanks,
> Rusty.

Hi Rusty,

Did you update your tip/cpus4096 branch?  The resultant code in the above tree
does not have the additions from the sparseirq branch, which was the 6 hour merge
I did last week (but used the wrong tip branch.)  I'm re-doing the merge based
on the latest tip/cpus4096 which has this as the HEAD commit:


commit 8299608f140ae321e4eb5d1306184265d2b9511e
Merge: 45ab6b0... 30cb367... 69b88af... 8daa190...
Author: Ingo Molnar <mingo@elte.hu>
Date:   Fri Dec 12 13:49:17 2008 +0100

    Merge branches 'irq/sparseirq', 'x86/quirks' and 'x86/reboot' into cpus4096

    We merge the irq/sparseirq, x86/quirks and x86/reboot trees into the
    cpus4096 tree because the io-apic changes in the sparseirq change
    conflict with the cpumask changes in the cpumask tree, and we
    want to resolve those.

It will be done as soon as I figure out what arguments to git-rebase (or whatever)
are correct to get the output that Ingo needs, to apply to his tip/cpus4096 branch.

Thanks,
Mike

Re: linux-next: manual merge of the rr_cpumask tree

[Mike Travis]

Mike Travis wrote:
> Rusty Russell wrote:
>> On Monday 15 December 2008 16:39:45 Stephen Rothwell wrote:
>>> Hi Rusty,
>>>
>>> Today's linux-next merge of the rr_cpumask tree got a conflict in
>>> arch/x86/kernel/io_apic.c between commit
>>> 3145e941fcfe2548fa2270afb1a05bab3a6bc418 ("x86, MSI: pass irq_cfg and
>>> irq_desc") from the sparseirq tree and commit
>>> 0de26520c7cabf36e1de090ea8092f011a6106ce ("cpumask: make irq_set_affinity
>>> () take a const struct cpumask") from the rr_cpumask tree.
>>>
>>> There are lots of overlapping changes.  I fixed it up (see below) and can carry the
>>> fix as necessary.
>> I have performed this merge before.  The results are in
>> 	git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-ingo.git
>>
>> Ingo, can you pull these into cpus4096?  It's just the cpumask/cpus4096 merge.
>>
>> Thanks,
>> Rusty.
> 
> Hi Rusty,
> 
> Did you update your tip/cpus4096 branch?  The resultant code in the above tree
> does not have the additions from the sparseirq branch, which was the 6 hour merge
> I did last week (but used the wrong tip branch.)  I'm re-doing the merge based
> on the latest tip/cpus4096 which has this as the HEAD commit:
> 

Hmm, building the tree a bit differently and the below commit does show up:

git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
git-remote add for-ingo git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-ingo.git
git-remote update
git-checkout -b for-ingo for-ingo/master

Ingo - does this mean that the above "for-ingo" tree will merge into your tip/cpus4096 correctly?

(I'm doing a patch now to add in the missing pieces that were dropped after the rebase.)

> 
> commit 8299608f140ae321e4eb5d1306184265d2b9511e
> Merge: 45ab6b0... 30cb367... 69b88af... 8daa190...
> Author: Ingo Molnar <mingo@elte.hu>
> Date:   Fri Dec 12 13:49:17 2008 +0100
> 
>     Merge branches 'irq/sparseirq', 'x86/quirks' and 'x86/reboot' into cpus4096
> 
>     We merge the irq/sparseirq, x86/quirks and x86/reboot trees into the
>     cpus4096 tree because the io-apic changes in the sparseirq change
>     conflict with the cpumask changes in the cpumask tree, and we
>     want to resolve those.
> 

Re: linux-next: manual merge of the rr_cpumask tree

[Rusty Russell]

On Tuesday 16 December 2008 02:57:09 Mike Travis wrote:
> Rusty Russell wrote:
> > On Monday 15 December 2008 16:39:45 Stephen Rothwell wrote:
> >> Hi Rusty,
> >>
> >> Today's linux-next merge of the rr_cpumask tree got a conflict in
> >> arch/x86/kernel/io_apic.c between commit
> >> 3145e941fcfe2548fa2270afb1a05bab3a6bc418 ("x86, MSI: pass irq_cfg and
> >> irq_desc") from the sparseirq tree and commit
> >> 0de26520c7cabf36e1de090ea8092f011a6106ce ("cpumask: make irq_set_affinity
> >> () take a const struct cpumask") from the rr_cpumask tree.
> >>
> >> There are lots of overlapping changes.  I fixed it up (see below) and can carry the
> >> fix as necessary.
> > 
> > I have performed this merge before.  The results are in
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-ingo.git
> > 
> > Ingo, can you pull these into cpus4096?  It's just the cpumask/cpus4096 merge.
> > 
> > Thanks,
> > Rusty.
> 
> Hi Rusty,
> 
> Did you update your tip/cpus4096 branch?

No.  As I said, I just did a merge of ingo's 4096 tree with the cpumask tree.
He should pull that, and then the rest of the x86 patches can go on top.

Cheers,
Rusty.

Re: linux-next: manual merge of the rr_cpumask tree

[Mike Travis]

Rusty Russell wrote:
> On Tuesday 16 December 2008 02:57:09 Mike Travis wrote:
>> Rusty Russell wrote:
>>> On Monday 15 December 2008 16:39:45 Stephen Rothwell wrote:
>>>> Hi Rusty,
>>>>
>>>> Today's linux-next merge of the rr_cpumask tree got a conflict in
>>>> arch/x86/kernel/io_apic.c between commit
>>>> 3145e941fcfe2548fa2270afb1a05bab3a6bc418 ("x86, MSI: pass irq_cfg and
>>>> irq_desc") from the sparseirq tree and commit
>>>> 0de26520c7cabf36e1de090ea8092f011a6106ce ("cpumask: make irq_set_affinity
>>>> () take a const struct cpumask") from the rr_cpumask tree.
>>>>
>>>> There are lots of overlapping changes.  I fixed it up (see below) and can carry the
>>>> fix as necessary.
>>> I have performed this merge before.  The results are in
>>> 	git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-ingo.git
>>>
>>> Ingo, can you pull these into cpus4096?  It's just the cpumask/cpus4096 merge.
>>>
>>> Thanks,
>>> Rusty.
>> Hi Rusty,
>>
>> Did you update your tip/cpus4096 branch?
> 
> No.  As I said, I just did a merge of ingo's 4096 tree with the cpumask tree.
> He should pull that, and then the rest of the x86 patches can go on top.
> 
> Cheers,
> Rusty.

Hi Rusty,

Yes, I did finally figure that out.  Thanks for rebasing the part that Ingo needed
so maybe the rest can be pushed.  There was a problem when the 'for-ingo' tree was
merged as there were mixed up API calls in io_apic.c, but I fixed them in the first
x86 only patch.  I wasn't sure of what else to do.

All the x86 patches build and boot (and test! ;-) on x86_64.  My 32-bit box has gone
into a coma until I can figure out what's up (and the 64-bit box lost it's 32-bit
root partition.)  Since they are pretty much exactly as you had tested last week,
I not expecting any problems.

I'm working through the remainder of your cpumask patches now.

Thanks!
Mike

Re: linux-next: manual merge of the rr_cpumask tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Hi Mike,

On Mon, 15 Dec 2008 22:02:25 -0800 Mike Travis <travis@sgi.com> wrote:
>
> Yes, I did finally figure that out.  Thanks for rebasing the part that Ingo needed
> so maybe the rest can be pushed.  There was a problem when the 'for-ingo' tree was
> merged as there were mixed up API calls in io_apic.c, but I fixed them in the first
> x86 only patch.  I wasn't sure of what else to do.

You could have fixed them up as part of the actual merge commit.  If each
tree was correct on it own, then the merge is the place for such
resolutions.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr_cpumask tree

[Mike Travis]

Stephen Rothwell wrote:
> Hi Mike,
> 
> On Mon, 15 Dec 2008 22:02:25 -0800 Mike Travis <travis@sgi.com> wrote:
>> Yes, I did finally figure that out.  Thanks for rebasing the part that Ingo needed
>> so maybe the rest can be pushed.  There was a problem when the 'for-ingo' tree was
>> merged as there were mixed up API calls in io_apic.c, but I fixed them in the first
>> x86 only patch.  I wasn't sure of what else to do.
> 
> You could have fixed them up as part of the actual merge commit.  If each
> tree was correct on it own, then the merge is the place for such
> resolutions.
> 

Thanks, I will try that next time.

Ingo - if you need a small patch to make the post-merge tree buildable, let me know. 
I can extract that from the 1st patch (that modifies the smp api).

Thanks,
Mike

Re: linux-next: manual merge of the rr_cpumask tree

[Ingo Molnar]

* Mike Travis <travis@sgi.com> wrote:

> Stephen Rothwell wrote:
> > Hi Mike,
> > 
> > On Mon, 15 Dec 2008 22:02:25 -0800 Mike Travis <travis@sgi.com> wrote:
> >> Yes, I did finally figure that out.  Thanks for rebasing the part that Ingo needed
> >> so maybe the rest can be pushed.  There was a problem when the 'for-ingo' tree was
> >> merged as there were mixed up API calls in io_apic.c, but I fixed them in the first
> >> x86 only patch.  I wasn't sure of what else to do.
> > 
> > You could have fixed them up as part of the actual merge commit.  If each
> > tree was correct on it own, then the merge is the place for such
> > resolutions.
> > 
> 
> Thanks, I will try that next time.

actually, it's a quite obscure place for it and easy to miss (git log -p 
does not display them by default, etc.) - it's better to have an explicit 
commit after the merge. 'git bisect next' works if someone happens to hit 
this bisection breakage.

> Ingo - if you need a small patch to make the post-merge tree buildable, 
> let me know. I can extract that from the 1st patch (that modifies the 
> smp api).

yes, please put that fix as the first patch in your tree that i'll 
hopefully be able to pull :)

	Ingo

linux-next: manual merge of the rr_cpumask tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr_cpumask tree got conflicts in
kernel/sched.c and kernel/sched_stats.h between commits
sched_domain_debug_one ("sched: wrap sched_group and sched_domain cpumask
accesses") and dcc30a35f71bcf51f1e9b336dc5e41923071509a ("sched: convert
cpu_isolated_map to cpumask_var_t") from the cpus4096 tree and commit
29c0177e6a4ac094302bed54a1d4bbb6b740a9ef ("cpumask: change
cpumask_scnprintf, cpumask_parse_user, cpulist_parse, and
cpulist_scnprintf to take pointers") from the rr_cpumask tree.

Overlapping changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/sched.c
index b6b60dd,d2d16d1..0000000
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@@ -6637,8 -6666,8 +6637,8 @@@ static int sched_domain_debug_one(struc
  	struct sched_group *group = sd->groups;
  	char str[256];
  
- 	cpulist_scnprintf(str, sizeof(str), *sched_domain_span(sd));
 -	cpulist_scnprintf(str, sizeof(str), &sd->span);
 -	cpus_clear(*groupmask);
++	cpulist_scnprintf(str, sizeof(str), sched_domain_span(sd));
 +	cpumask_clear(groupmask);
  
  	printk(KERN_DEBUG "%*s domain %d: ", level, "", level);
  
@@@ -6688,9 -6718,9 +6688,9 @@@
  			break;
  		}
  
 -		cpus_or(*groupmask, *groupmask, group->cpumask);
 +		cpumask_or(groupmask, groupmask, sched_group_cpus(group));
  
- 		cpulist_scnprintf(str, sizeof(str), *sched_group_cpus(group));
 -		cpulist_scnprintf(str, sizeof(str), &group->cpumask);
++		cpulist_scnprintf(str, sizeof(str), sched_group_cpus(group));
  		printk(KERN_CONT " %s", str);
  
  		group = group->next;
@@@ -6932,7 -6922,14 +6932,7 @@@ static cpumask_var_t cpu_isolated_map
  /* Setup the mask of cpus configured for isolated domains */
  static int __init isolated_cpu_setup(char *str)
  {
- 	cpulist_parse(str, *cpu_isolated_map);
 -	static int __initdata ints[NR_CPUS];
 -	int i;
 -
 -	str = get_options(str, ARRAY_SIZE(ints), ints);
 -	cpus_clear(cpu_isolated_map);
 -	for (i = 1; i <= ints[0]; i++)
 -		if (ints[i] < NR_CPUS)
 -			cpu_set(ints[i], cpu_isolated_map);
++	cpulist_parse(str, cpu_isolated_map);
  	return 1;
  }
  
diff --cc kernel/sched_stats.h
index ce34083,6beff1e..0000000
--- a/kernel/sched_stats.h
+++ b/kernel/sched_stats.h
@@@ -42,8 -42,7 +42,8 @@@ static int show_schedstat(struct seq_fi
  		for_each_domain(cpu, sd) {
  			enum cpu_idle_type itype;
  
 -			cpumask_scnprintf(mask_str, mask_len, &sd->span);
 +			cpumask_scnprintf(mask_str, mask_len,
- 					  *sched_domain_span(sd));
++					  sched_domain_span(sd));
  			seq_printf(seq, "domain%d %s", dcount++, mask_str);
  			for (itype = CPU_IDLE; itype < CPU_MAX_IDLE_TYPES;
  					itype++) {

linux-next: manual merge of the rr_cpumask tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

Hi Rusty,

Today's linux-next merge of the rr_cpumask tree got a conflict in
arch/x86/kernel/io_apic.c between commit
22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
new cpumask API") from the cpus4096 tree and commit
2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
something - I suspect git has failed me a little here) from the
rr_cpumask tree.

It is a bit of a train wreck :-)

I have dropped the rr_cpumask tree for today and also the rr tree that
depends on it.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr_cpumask tree

[Rusty Russell]

On Friday 02 January 2009 13:05:57 Stephen Rothwell wrote:
> Hi Rusty,
> 
> Today's linux-next merge of the rr_cpumask tree got a conflict in
> arch/x86/kernel/io_apic.c between commit
> 22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
> new cpumask API") from the cpus4096 tree and commit
> 2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
> something - I suspect git has failed me a little here)

Yes, I've had several 'git blame' pointing to merges from Ingo's tree.
And they tend to be n-way merges, so tracing it down is too hard.

The cpus4096 tree is supposed to have already merged the cpumask tree,
so this should not have happened.

> I have dropped the rr_cpumask tree for today and also the rr tree that
> depends on it.

OK I will remove this dependency for the moment.

Rusty.

Re: linux-next: manual merge of the rr_cpumask tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

Hi Rusty,

On Fri, 2 Jan 2009 16:17:40 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> On Friday 02 January 2009 13:05:57 Stephen Rothwell wrote:
> Yes, I've had several 'git blame' pointing to merges from Ingo's tree.
> And they tend to be n-way merges, so tracing it down is too hard.

If you are in the middle of a merge operations with conflicts, the "gitk
--merge" is generally useful.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: manual merge of the rr_cpumask tree

[Mike Travis]

Rusty Russell wrote:
> On Friday 02 January 2009 13:05:57 Stephen Rothwell wrote:
>> Hi Rusty,
>>
>> Today's linux-next merge of the rr_cpumask tree got a conflict in
>> arch/x86/kernel/io_apic.c between commit
>> 22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
>> new cpumask API") from the cpus4096 tree and commit
>> 2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
>> something - I suspect git has failed me a little here)
> 
> Yes, I've had several 'git blame' pointing to merges from Ingo's tree.
> And they tend to be n-way merges, so tracing it down is too hard.
> 
> The cpus4096 tree is supposed to have already merged the cpumask tree,
> so this should not have happened.
> 
>> I have dropped the rr_cpumask tree for today and also the rr tree that
>> depends on it.
> 
> OK I will remove this dependency for the moment.
> 
> Rusty.

Hi Rusty & Stephen,

Thanks for dealing with these thorny issues.

Yes, if there's a more pita file than sched.c it's io_apic.c ... ;-)

Cheers,
Mike

Re: linux-next: manual merge of the rr_cpumask tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Rusty,
> 
> Today's linux-next merge of the rr_cpumask tree got a conflict in
> arch/x86/kernel/io_apic.c between commit
> 22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
> new cpumask API") from the cpus4096 tree and commit
> 2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
> something - I suspect git has failed me a little here) from the
> rr_cpumask tree.
> 
> It is a bit of a train wreck :-)
> 
> I have dropped the rr_cpumask tree for today and also the rr tree that 
> depends on it.

hm, i'll work with Rusty on fixing that - you should really not be seeing 
conflicts on that level.

	Ingo

Re: linux-next: manual merge of the rr_cpumask tree

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Rusty,
> > 
> > Today's linux-next merge of the rr_cpumask tree got a conflict in
> > arch/x86/kernel/io_apic.c between commit
> > 22f65d31b25a320a5246592160bcb102d2791c45 ("x86: Update io_apic.c to use
> > new cpumask API") from the cpus4096 tree and commit
> > 2ca1a615835d9f4990f42102ab1f2ef434e7e89c ("Merge branch 'master' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6") (or
> > something - I suspect git has failed me a little here) from the
> > rr_cpumask tree.
> > 
> > It is a bit of a train wreck :-)
> > 
> > I have dropped the rr_cpumask tree for today and also the rr tree that 
> > depends on it.
> 
> hm, i'll work with Rusty on fixing that - you should really not be 
> seeing conflicts on that level.

ok, i think i got it all sorted out - there will be a new cpus4096 tree 
later today (if it passes the tests) that should merge cleanly with 
Rusty's latest.

	Ingo

linux-next: manual merge of the rr_cpumask tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr_cpumask tree got a conflict in
kernel/time/tick-common.c between commit
5762ba1873b0bb9faa631aaa02f533c2b9837f82 ("hrtimers: allow the
hot-unplugging of all cpus") from the timers tree and commit
6b954823c24f04ed026a8517f6bab5abda279db8 ("cpumask: convert kernel time
functions") from the rr_cpumask tree.

I fixed it up (see below) and can carry the fix as necessary., 
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/time/tick-common.c
index b21410b,63e05d4..0000000
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@@ -274,21 -274,6 +274,21 @@@ out_bc
  }
  
  /*
 + * Transfer the do_timer job away from a dying cpu.
 + *
 + * Called with interrupts disabled.
 + */
 +static void tick_handover_do_timer(int *cpup)
 +{
 +	if (*cpup == tick_do_timer_cpu) {
- 		int cpu = first_cpu(cpu_online_map);
++		int cpu = cpumask_first(cpu_online_map);
 +
- 		tick_do_timer_cpu = (cpu != NR_CPUS) ? cpu :
++		tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu :
 +			TICK_DO_TIMER_NONE;
 +	}
 +}
 +
 +/*
   * Shutdown an event device on a given cpu:
   *
   * This is called on a life CPU, when a CPU is dead. So we cannot