Linux-Next discussions
 help / color / mirror / Atom feed
* linux-next: build warning after merge of the tip tree
From: Stephen Rothwell @ 2011-09-14  6:34 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Shan Hai, Yong Zhang

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

Hi all,

After merging the tip tree, today's linux-next build (powerpc allnoconfig)
produced this warning:

lib/atomic64.c: In function 'lock_addr':
lib/atomic64.c:42:2: warning: return from incompatible pointer type

Introduced by commit f59ca05871a0 ("locking, lib/atomic64: Annotate
atomic64_lock::lock as raw").  This function (which is declared to return
"spinlock_t *") is now returning "raw_spinlock_t *".
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply

* linux-next: manual merge of the akpm tree with the slab tree
From: Stephen Rothwell @ 2011-09-14  6:24 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Dave Jones, Sebastian Andrzej Siewior,
	Pekka Enberg, Christoph Lameter

Hi Andrew,

Today's linux-next merge of the scsi-post-merge tree got a conflict in
mm/slab.c between commit fdde6abb3e8d ("slab: use print_hex_dump") from
the slab tree and commit 0cf5ab251a1a ("When we get corruption reports,
it's useful to see if the kernel was") from the akpm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/slab.c
index 5bfc204,10a3624..0000000
--- a/mm/slab.c
+++ b/mm/slab.c
@@@ -3037,11 -3037,16 +3037,11 @@@ static void check_slabp(struct kmem_cac
  	if (entries != cachep->num - slabp->inuse) {
  bad:
  		printk(KERN_ERR "slab: Internal list corruption detected in "
- 				"cache '%s'(%d), slabp %p(%d). Hexdump:\n",
- 			cachep->name, cachep->num, slabp, slabp->inuse);
+ 				"cache '%s'(%d), slabp %p(%d). Tainted(%s). Hexdump:\n",
+ 			cachep->name, cachep->num, slabp, slabp->inuse, print_tainted());
 -		for (i = 0;
 -		     i < sizeof(*slabp) + cachep->num * sizeof(kmem_bufctl_t);
 -		     i++) {
 -			if (i % 16 == 0)
 -				printk("\n%03x:", i);
 -			printk(" %02x", ((unsigned char *)slabp)[i]);
 -		}
 -		printk("\n");
 +		print_hex_dump(KERN_ERR, "", DUMP_PREFIX_OFFSET, 16, 1, slabp,
 +			sizeof(*slabp) + cachep->num * sizeof(kmem_bufctl_t),
 +			1);
  		BUG();
  	}
  }

^ permalink raw reply

* linux-next: build warning after merge of the tip tree
From: Stephen Rothwell @ 2011-09-14  6:22 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, John Stultz

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

Hi all,

After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

kernel/time/alarmtimer.c: In function 'alarmtimer_rtc_interface_setup':
kernel/time/alarmtimer.c:106:26: warning: ignoring return value of 'class_interface_register', declared with attribute warn_unused_result

Introduced by commit 8bc0dafb5cf3 ("alarmtimers: Rework RTC device
selection using class interface").

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

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

^ permalink raw reply

* linux-next: manual merge of the moduleh tree with the s390 tree
From: Stephen Rothwell @ 2011-09-14  5:25 UTC (permalink / raw)
  To: Paul Gortmaker
  Cc: linux-next, linux-kernel, Peter Oberparleiter, Martin Schwidefsky,
	Heiko Carstens

Hi Paul,

Today's linux-next merge of the moduleh tree got a conflict in
drivers/s390/char/vmur.c between commit 003184781fea ("[S390] s390: fix
mismatch in summation of I/O IRQ statistics") from the s390 tree and
commit e7a6a4ef9ffe ("s390: add missing module.h/export.h includes") from
the moduleh tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.  (Or this part of the moduleh commit could be added to the
s390 tree.)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/s390/char/vmur.c
index d291a54,c9782ff..0000000
--- a/drivers/s390/char/vmur.c
+++ b/drivers/s390/char/vmur.c
@@@ -11,6 -11,8 +11,7 @@@
  #define KMSG_COMPONENT "vmur"
  #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
  
 -#include <linux/kernel_stat.h>
+ #include <linux/module.h>
  #include <linux/cdev.h>
  #include <linux/slab.h>
  

^ permalink raw reply

* linux-next: manual merge of the wireless tree with the wireless-current tree
From: Stephen Rothwell @ 2011-09-14  3:05 UTC (permalink / raw)
  To: John W. Linville
  Cc: linux-next, linux-kernel, Johannes Berg, Wey-Yi Guy,
	Emmanuel Grumbach

Hi John,

Today's linux-next merge of the wireless tree got a conflict in
drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c between commit
282cdb325aea ("iwlagn: fix command queue timeout") from the
wireless-current tree and commit 6d8f6eeb3506 ("iwlagn: transport layer
should receive iwl_trans") from the wireless tree.

Just context changes.  I fixed ti up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c
index 222d410,ea6a0bc..0000000
--- a/drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c
@@@ -771,9 -921,8 +921,10 @@@ void iwl_tx_cmd_complete(struct iwl_pri
  	cmd = txq->cmd[cmd_index];
  	meta = &txq->meta[cmd_index];
  
 +	txq->time_stamp = jiffies;
 +
- 	iwlagn_unmap_tfd(priv, meta, &txq->tfds[index], DMA_BIDIRECTIONAL);
+ 	iwlagn_unmap_tfd(trans, meta, &txq->tfds[index],
+ 			 DMA_BIDIRECTIONAL);
  
  	/* Input error checking is done when commands are added to queue. */
  	if (meta->flags & CMD_WANT_SKB) {

^ permalink raw reply

* linux-next: manual merge of the net tree with the s390 tree
From: Stephen Rothwell @ 2011-09-14  2:50 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Peter Oberparleiter, Martin Schwidefsky,
	Heiko Carstens, Frank Blaschka, Einar Lueck, Jan Glauber

Hi all,

Today's linux-next merge of the net tree got a conflict in
drivers/s390/cio/qdio_main.c between commit 003184781fea ("[S390] s390:
fix mismatch in summation of I/O IRQ statistics") from the s390 tree and
commit 104ea556ee7f ("qdio: support asynchronous delivery of storage
blocks") from the net tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/s390/cio/qdio_main.c
index a122c1c,9a12228..0000000
--- a/drivers/s390/cio/qdio_main.c
+++ b/drivers/s390/cio/qdio_main.c
@@@ -14,6 -14,8 +14,7 @@@
  #include <linux/timer.h>
  #include <linux/delay.h>
  #include <linux/gfp.h>
+ #include <linux/io.h>
 -#include <linux/kernel_stat.h>
  #include <linux/atomic.h>
  #include <asm/debug.h>
  #include <asm/qdio.h>

^ permalink raw reply

* Re: linux-next: manual merge of the xen tree with the tip tree
From: Stephen Rothwell @ 2011-09-14  0:48 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Thomas Gleixner, H. Peter Anvin, Xen Devel, linux-next,
	linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110914103234.4f2f6a2dd65734de6622e79f@canb.auug.org.au>

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

Hi all,

On Wed, 14 Sep 2011 10:32:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> My understanding is this:  I do *not* need to revert the spinlock changes
> from tip anymore, correct?

Right, having looked at the tip tree, they are not in there any more.

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

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

^ permalink raw reply

* Re: linux-next: manual merge of the xen tree with the tip tree
From: Jeremy Fitzhardinge @ 2011-09-14  0:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, H. Peter Anvin, Xen Devel, linux-next,
	linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110914103234.4f2f6a2dd65734de6622e79f@canb.auug.org.au>

On 09/13/2011 05:32 PM, Stephen Rothwell wrote:
> Hi Jeremy,
>
> On Tue, 13 Sep 2011 13:53:39 -0700 Jeremy Fitzhardinge
<jeremy@goop.org> wrote:
>>
>> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
>>> On Tue, 13 Sep 2011, Stephen Rothwell wrote:
>>>>
>>>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell
<sfr@canb.auug.org.au> wrote:
>>>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com>
wrote:
>>>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>>>>>>>> should be dropped.
>>>>>>> That's a bit tricky as I get a rolled up tip tree. The best I
could do
>>>>>>> is revert the commit that merges the x86/spinlocks branch into
>>>>>>> auto-latest ... I'll do that for today (unless something happens
to the
>>>>>>> tip tree in the next hour).
>>>>>>>
>>>>>> OK, let me bother Ingo about it.
>>>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
>>>>> tip tree.
>>>> I am still doing this in each linux-next, and it doesn't appear to have
>>>> been fixed up the the tree on tesla.tglx.de, yet, I think.
>>> We'll take it out.
>>
>> Actually, the tip x86/spinlocks was the most up-to-date version of those
>> patches (since hpa had rebased them to a more recent version of mainline).
>>
>> But never mind. Stephen, could you use
>>
>> git://github.com/jsgf/linux-xen.git upstream/xen
>>
>> for linux-next instead of the kernel.org xen.git, and I've re-added the
>> up-to-date spinlock changes there.
>
> OK, I have switched to this from today.
>
> My understanding is this: I do *not* need to revert the spinlock changes
> from tip anymore, correct?

Right.  tglx has removed these changes from tip.git (even though they
were OK), and I've reinstated the proper versions in my tree.  The
xen.git on git.kernel.org still has old versions, but I'll sort that out
once it's back online.  I expect it will ultimately go upstream via
tip.git, but we can work that out later too.

Thanks,
    J

^ permalink raw reply

* Re: linux-next: manual merge of the xen tree with the tip tree
From: Stephen Rothwell @ 2011-09-14  0:32 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Thomas Gleixner, H. Peter Anvin, Xen Devel, linux-next,
	linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <4E6FC2D3.2060408@goop.org>

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

Hi Jeremy,

On Tue, 13 Sep 2011 13:53:39 -0700 Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
> > On Tue, 13 Sep 2011, Stephen Rothwell wrote:
> >>
> >> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> >>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> >>>>>> should be dropped.
> >>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
> >>>>> is revert the commit that merges the x86/spinlocks branch into
> >>>>> auto-latest ...  I'll do that for today (unless something happens to the
> >>>>> tip tree in the next hour).
> >>>>>
> >>>> OK, let me bother Ingo about it.
> >>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> >>> tip tree.
> >> I am still doing this in each linux-next, and it doesn't appear to have
> >> been fixed up the the tree on tesla.tglx.de, yet, I think.
> > We'll take it out. 
> 
> Actually, the tip x86/spinlocks was the most up-to-date version of those
> patches (since hpa had rebased them to a more recent version of mainline).
> 
> But never mind.  Stephen, could you use
> 
>     git://github.com/jsgf/linux-xen.git upstream/xen
> 
> for linux-next instead of the kernel.org xen.git, and I've re-added the
> up-to-date spinlock changes there.

OK, I have switched to this from today.

My understanding is this:  I do *not* need to revert the spinlock changes
from tip anymore, correct?

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

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

^ permalink raw reply

* Re: Temporary -rcu tree location
From: Stephen Rothwell @ 2011-09-14  0:20 UTC (permalink / raw)
  To: paulmck; +Cc: Jiri Kosina, linux-next, linux-kernel
In-Reply-To: <20110913160645.GA6258@linux.vnet.ibm.com>

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

Hi Paul,

On Tue, 13 Sep 2011 09:06:45 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> OK, I pushed a small update to one of the commits, this time to branch
> rcu/next, again at https://github.com/paulmckrcu/linux.

I have switched to that branch from today.

> I guess that the acid test is the next time I update.  ;-)

Indeed,  It should work, though.

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

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

^ permalink raw reply

* Re: Temporary relocation of my git trees
From: Stephen Rothwell @ 2011-09-14  0:17 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-next, linux-kernel
In-Reply-To: <20110913134500.GA10912@sirena.org.uk>

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

Hi Mark,

On Tue, 13 Sep 2011 14:45:00 +0100 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> Given the kernel.org issues I'm currently hosting my git trees at:
> 
> asoc: git://opensource.wolfsonmicro.com/linux-2.6-asoc.git for-next
> regmap: git://opensource.wolfsonmicro.com/regmap.git for-next
> 
> If you're still doing linux-next builds while things are down please
> update to pull from those until such time as kernel.org recovers.

I will switch from today, thanks.

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

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

^ permalink raw reply

* Re: linux-next: manual merge of the xen tree with the tip tree
From: Jeremy Fitzhardinge @ 2011-09-13 21:00 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, H. Peter Anvin, Xen Devel, linux-next,
	linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <alpine.LFD.2.02.1109132254470.2723@ionos>

On 09/13/2011 01:56 PM, Thomas Gleixner wrote:
> On Tue, 13 Sep 2011, Jeremy Fitzhardinge wrote:
>
>> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
>>> On Tue, 13 Sep 2011, Stephen Rothwell wrote:
>>>> Hi,
>>>>
>>>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>>>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>>>>>>>> should be dropped.
>>>>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
>>>>>>> is revert the commit that merges the x86/spinlocks branch into
>>>>>>> auto-latest ...  I'll do that for today (unless something happens to the
>>>>>>> tip tree in the next hour).
>>>>>>>
>>>>>> OK, let me bother Ingo about it.
>>>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
>>>>> tip tree.
>>>> I am still doing this in each linux-next, and it doesn't appear to have
>>>> been fixed up the the tree on tesla.tglx.de, yet, I think.
>>> We'll take it out. 
>> Actually, the tip x86/spinlocks was the most up-to-date version of those
>> patches (since hpa had rebased them to a more recent version of mainline).
> Mooo. You tell that after we did a nasty rebase from hell :(

I'd been meaning to take it out of my tree to solve Stephen's problem,
but, well, kernel.org.

    J

^ permalink raw reply

* Re: linux-next: manual merge of the xen tree with the tip tree
From: Thomas Gleixner @ 2011-09-13 20:56 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Stephen Rothwell, H. Peter Anvin, Xen Devel, linux-next,
	linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <4E6FC2D3.2060408@goop.org>

On Tue, 13 Sep 2011, Jeremy Fitzhardinge wrote:

> On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
> > On Tue, 13 Sep 2011, Stephen Rothwell wrote:
> >> Hi,
> >>
> >> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> >>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> >>>>>> should be dropped.
> >>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
> >>>>> is revert the commit that merges the x86/spinlocks branch into
> >>>>> auto-latest ...  I'll do that for today (unless something happens to the
> >>>>> tip tree in the next hour).
> >>>>>
> >>>> OK, let me bother Ingo about it.
> >>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> >>> tip tree.
> >> I am still doing this in each linux-next, and it doesn't appear to have
> >> been fixed up the the tree on tesla.tglx.de, yet, I think.
> > We'll take it out. 
> 
> Actually, the tip x86/spinlocks was the most up-to-date version of those
> patches (since hpa had rebased them to a more recent version of mainline).

Mooo. You tell that after we did a nasty rebase from hell :(
 
Thanks,

	tglx

^ permalink raw reply

* Re: linux-next: manual merge of the xen tree with the tip tree
From: Jeremy Fitzhardinge @ 2011-09-13 20:53 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephen Rothwell, H. Peter Anvin, Xen Devel, linux-next,
	linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <alpine.LFD.2.02.1109131706410.2723@ionos>

On 09/13/2011 08:07 AM, Thomas Gleixner wrote:
> On Tue, 13 Sep 2011, Stephen Rothwell wrote:
>> Hi,
>>
>> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>>>> On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
>>>>>> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
>>>>>> should be dropped.
>>>>> That's a bit tricky as I get a rolled up tip tree.  The best I could do
>>>>> is revert the commit that merges the x86/spinlocks branch into
>>>>> auto-latest ...  I'll do that for today (unless something happens to the
>>>>> tip tree in the next hour).
>>>>>
>>>> OK, let me bother Ingo about it.
>>> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
>>> tip tree.
>> I am still doing this in each linux-next, and it doesn't appear to have
>> been fixed up the the tree on tesla.tglx.de, yet, I think.
> We'll take it out. 

Actually, the tip x86/spinlocks was the most up-to-date version of those
patches (since hpa had rebased them to a more recent version of mainline).

But never mind.  Stephen, could you use

    git://github.com/jsgf/linux-xen.git upstream/xen

for linux-next instead of the kernel.org xen.git, and I've re-added the
up-to-date spinlock changes there.

Thanks,
    J

^ permalink raw reply

* Re: Temporary -rcu tree location
From: Paul E. McKenney @ 2011-09-13 16:06 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Jiri Kosina, linux-next, linux-kernel
In-Reply-To: <20110913040647.GC2313@linux.vnet.ibm.com>

On Mon, Sep 12, 2011 at 09:06:47PM -0700, Paul E. McKenney wrote:
> On Tue, Sep 13, 2011 at 12:07:16PM +1000, Stephen Rothwell wrote:
> > Hi Paul,
> > 
> > On Mon, 12 Sep 2011 18:34:00 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > > there doesn't seem to be 'rcu/next' branch, right?
> > > 
> > > No, there is not.  So the idea is to push "rcu/next" the first time,
> > > then ":rcu/next" thereafter?
> > 
> > Can't you just do a (forced) push over and over again without removing
> > the branch each time?
> 
> I will give it a try on the next update.  ;-)

OK, I pushed a small update to one of the commits, this time to branch
rcu/next, again at https://github.com/paulmckrcu/linux.

I guess that the acid test is the next time I update.  ;-)

								Thanx, Paul

^ permalink raw reply

* Re: linux-next: manual merge of the xen tree with the tip tree
From: Thomas Gleixner @ 2011-09-13 15:07 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: H. Peter Anvin, Jeremy Fitzhardinge, Xen Devel, linux-next,
	linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110913211154.fe53ca8c1d608def77a69022@canb.auug.org.au>

On Tue, 13 Sep 2011, Stephen Rothwell wrote:
> Hi,
> 
> On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> > >
> > > On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> > > >>
> > > >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> > > >> should be dropped.
> > > > 
> > > > That's a bit tricky as I get a rolled up tip tree.  The best I could do
> > > > is revert the commit that merges the x86/spinlocks branch into
> > > > auto-latest ...  I'll do that for today (unless something happens to the
> > > > tip tree in the next hour).
> > > > 
> > > 
> > > OK, let me bother Ingo about it.
> > 
> > For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> > tip tree.
> 
> I am still doing this in each linux-next, and it doesn't appear to have
> been fixed up the the tree on tesla.tglx.de, yet, I think.

We'll take it out. Thanks,

      tglx

^ permalink raw reply

* Temporary relocation of my git trees
From: Mark Brown @ 2011-09-13 13:45 UTC (permalink / raw)
  To: Stephen Rothwell, linux-next, linux-kernel

Hi Stephen,

Given the kernel.org issues I'm currently hosting my git trees at:

asoc: git://opensource.wolfsonmicro.com/linux-2.6-asoc.git for-next
regmap: git://opensource.wolfsonmicro.com/regmap.git for-next

If you're still doing linux-next builds while things are down please
update to pull from those until such time as kernel.org recovers.

Thanks,
Mark

^ permalink raw reply

* Re: linux-next: manual merge of the xen tree with the tip tree
From: Stephen Rothwell @ 2011-09-13 11:11 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Jeremy Fitzhardinge, Xen Devel, linux-next, linux-kernel,
	Thomas Gleixner, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110826125441.709aa423cdf072ce085fb91c@canb.auug.org.au>

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

Hi,

On Fri, 26 Aug 2011 12:54:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 25 Aug 2011 16:12:33 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> > On 08/25/2011 04:06 PM, Stephen Rothwell wrote:
> > >>
> > >> Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
> > >> should be dropped.
> > > 
> > > That's a bit tricky as I get a rolled up tip tree.  The best I could do
> > > is revert the commit that merges the x86/spinlocks branch into
> > > auto-latest ...  I'll do that for today (unless something happens to the
> > > tip tree in the next hour).
> > > 
> > 
> > OK, let me bother Ingo about it.
> 
> For today, I have done "git revert -m 1 6f8fa39c81f1" after merging the
> tip tree.

I am still doing this in each linux-next, and it doesn't appear to have
been fixed up the the tree on tesla.tglx.de, yet, I think.

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

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

^ permalink raw reply

* Re: ACPI git tree re-locates to github.com
From: Stephen Rothwell @ 2011-09-13  7:16 UTC (permalink / raw)
  To: Brown, Len
  Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-next@vger.kernel.org
In-Reply-To: <E87738D94A6AD54789B5B8D1BAEB06CC829B3E4886@azsmsx503.amr.corp.intel.com>

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

Hi Len,

On Mon, 12 Sep 2011 20:03:52 -0700 "Brown, Len" <len.brown@intel.com> wrote:
>
> Effective immediately...
> 
> https://github.com/lenb/linux.git acpi
> 
> replaces
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git test

I will switch starting tomorrow.

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

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

^ permalink raw reply

* linux-next: Tree for Sept 13
From: Stephen Rothwell @ 2011-09-13  6:53 UTC (permalink / raw)
  To: linux-next; +Cc: LKML

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

Hi all,

With master.kernel.org down, some trees have moved to temporary locations
(so some updates are coming through).  However, the actual release will
be delayed until master returns.  I will still do the overnight builds,
though.

The powerpc allyesconfig build still fails today.

Changes since 20110912:

New tree: hexagon

Undropped tree: mips

I applied a merge fixup to the arm-soc tree.

The openrisc tree gained a conflict against Linus' tree.

I have still reverted the x86/spinlocks branch from the tip tree for
today.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 200 trees (counting Linus' and 27 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging kbuild-current/rc-fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging 52xx-and-virtex-current/powerpc/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging driver-core.current/driver-core-linus
Merging tty.current/tty-linus
Merging usb.current/usb-linus
Merging staging.current/staging-linus
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging devicetree-current/devicetree/merge
Merging spi-current/spi/merge
Merging arm/for-next
Merging arm-lpae/for-next
CONFLICT (content): Merge conflict in arch/arm/include/asm/page.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgalloc.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgtable-hwdef.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgtable.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/tlb.h
CONFLICT (content): Merge conflict in arch/arm/kernel/head.S
CONFLICT (content): Merge conflict in arch/arm/kernel/sleep.S
CONFLICT (content): Merge conflict in arch/arm/mm/dma-mapping.c
CONFLICT (content): Merge conflict in arch/arm/mm/mmu.c
Merging arm-soc/for-next
CONFLICT (content): Merge conflict in arch/arm/include/asm/hardware/cache-l2x0.h
CONFLICT (delete/modify): arch/arm/mach-at91/board-usb-a9260.c deleted in arm-soc/for-next and modified in HEAD. Version HEAD of arch/arm/mach-at91/board-usb-a9260.c left in tree.
CONFLICT (content): Merge conflict in arch/arm/mach-msm/board-msm8x60.c
CONFLICT (content): Merge conflict in arch/arm/mach-mxs/include/mach/gpio.h
CONFLICT (content): Merge conflict in arch/arm/mach-u300/Makefile.boot
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/include/mach/gpio.h
$ git rm -f arch/arm/mach-at91/board-usb-a9260.c
Applying: arm-soc: merge fixup for fixup/reserve being added to MACHINE descriptions
Merging at91/at91-next
Merging davinci/davinci-next
Merging i.MX/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-imx/Makefile
Merging linux-spec/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
CONFLICT (delete/modify): arch/arm/mach-exynos4/mach-smdkc210.c deleted in s5p/for-next and modified in HEAD. Version HEAD of arch/arm/mach-exynos4/mach-smdkc210.c left in tree.
$ git rm -f arch/arm/mach-exynos4/mach-smdkc210.c
Applying: s5p: merge fixup for atags_offset use
Merging tegra/for-next
Merging ux500-core/ux500-core
Merging xilinx/arm-next
Merging blackfin/for-linus
Merging cris/for-next
Merging quilt/hexagon
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging openrisc/for-upstream
CONFLICT (content): Merge conflict in arch/openrisc/kernel/signal.c
Merging parisc/for-next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/powerpc/next
Merging galak/next
Merging s390/features
Merging sh/sh-latest
Merging rmobile/rmobile-latest
Merging sparc/master
Merging tile/master
Merging unicore32/unicore32
Merging xtensa/master
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/dev
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/trans_virtio.c
Merging ubifs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/xfs/xfs_super.c
Merging vfs/for-next
Merging vfs-scale/vfs-scale-working
Merging pci/linux-next
Merging hid/for-next
CONFLICT (content): Merge conflict in drivers/hid/hid-core.c
CONFLICT (content): Merge conflict in drivers/hid/hid-ids.h
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging docs/docs-move
Merging v4l-dvb/master
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging powertools/tools-test
Merging cpupowerutils/master
Merging ieee1394/for-next
Merging ubi/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging iscsi-target/for-next
Merging slave-dma/next
Merging async_tx/next
Merging net/master
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (delete/modify): arch/powerpc/configs/40x/hcu4_defconfig deleted in HEAD and modified in net/master. Version net/master of arch/powerpc/configs/40x/hcu4_defconfig left in tree.
$ git rm -f arch/powerpc/configs/40x/hcu4_defconfig
Merging wireless/master
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-pci.c
Merging bluetooth/master
Merging mtd/master
Merging l2-mtd/master
CONFLICT (delete/modify): arch/arm/mach-at91/board-usb-a9260.c deleted in HEAD and modified in l2-mtd/master. Version l2-mtd/master of arch/arm/mach-at91/board-usb-a9260.c left in tree.
CONFLICT (content): Merge conflict in drivers/mtd/maps/lantiq-flash.c
$ git rm -f arch/arm/mach-at91/board-usb-a9260.c
Merging crypto/master
Merging sound/for-next
Merging sound-asoc/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
Merging input-mt/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
CONFLICT (content): Merge conflict in drivers/leds/Kconfig
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/rtc/rtc-twl.c
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/fbdev-next
Merging viafb/viafb-next
Merging omap_dss2/for-next
Merging voltage/for-next
Merging security/next
CONFLICT (content): Merge conflict in fs/ocfs2/xattr.c
Merging selinux/master
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging iommu/next
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging pm/linux-next
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/board-ap4evb.c
CONFLICT (content): Merge conflict in arch/s390/include/asm/thread_info.h
CONFLICT (content): Merge conflict in drivers/mfd/twl4030-irq.c
Merging apm/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging i7core_edac/linux_next
Merging i7300_edac/linux_next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/mcheck/mce.c
Merging devicetree/devicetree/next
CONFLICT (content): Merge conflict in drivers/of/base.c
Merging spi/spi/next
Merging gpio/gpio/next
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/mm/fault.c
[master 5cbb447] Revert "Merge branch 'x86/spinlocks' into auto-latest"
Merging rcu/rcu/next
Merging kvm/linux-next
Merging oprofile/for-next
Merging ptrace/ptrace
Merging xen/upstream/xen
Merging xen-two/linux-next
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging namespace/master
Merging regmap/for-next
Merging driver-core/driver-core-next
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/devices.c
Merging tty/tty-next
Merging usb/usb-next
Merging staging/staging-next
CONFLICT (delete/modify): drivers/staging/rtl8192e/r8192E_core.c deleted in staging/staging-next and modified in HEAD. Version HEAD of drivers/staging/rtl8192e/r8192E_core.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/xgifb/XGI_main_26.c
$ git rm -f drivers/staging/rtl8192e/r8192E_core.c
Merging bkl-config/config
Merging tmem/linux-next
Merging writeback/next
Merging arm-dt/devicetree/arm-next
Merging moduleh/module.h-split
CONFLICT (content): Merge conflict in arch/arm/mach-bcmring/mm.c
CONFLICT (content): Merge conflict in drivers/scsi/libfc/fc_lport.c
CONFLICT (content): Merge conflict in include/linux/dmaengine.h
Applying: dm: use export.h instead of module.h where possible
Applying: block: bsg-lib.c needs export.h not module.h
Applying: PM: EXPORT_SYMBOL needs export.h
Merging kvmtool/master
CONFLICT (content): Merge conflict in include/net/9p/9p.h
Merging scsi-post-merge/merge-base:master
$ git checkout akpm
Applying: Because of x86-implement-strict-user-copy-checks-for-x86_64.patch
Applying: When no floppy is found the module code can be released while a timer
Applying: Fix kconfig unmet dependency warning.  BACKLIGHT_CLASS_DEVICE depends on
Applying: The parameter's origin type is long.  On an i386 architecture, it can
Applying: Since the commit below which added O_PATH support to the *at() calls, the
Applying: Add support for Aspire 1410 BIOS v1.3314.  Fixes the following error:
Applying: This makes the iris driver use the platform API, so it is properly exposed
Applying: On x86_32 casting the unsigned int result of get_random_int() to long may
Applying: This new driver replaces the old PCEngines Alix 2/3 LED driver with a new
Applying: Cc: Ed Wildgoose <git@wildgooses.com>
Applying: Replace the bubble sort in sanitize_e820_map() with a call to the generic
Applying: The x86 timer interrupt handler is the only handler not traced in the
Applying: The current interrupt traces from irq_handler_entry and irq_handler_exit
Applying: Don't allow everybody to use a modem.
Applying: The address limit is already set in flush_old_exec() so this
Applying: A call to va_copy() should always be followed by a call to va_end() in the
Applying: Don't dereference em if it's NULL or an error pointer.
Applying: Some messing with error codes to return 0 on out id's and match
Applying: kbuf is a buffer that is local to this function, so all of the error paths
Applying: fb_set_suspend() must be called with the console semaphore held, which
Applying: hwmon was using an idr with a NULL pointer, so convert to an
Applying: A straightforward looking use of idr for a device id.
Applying: This patchset aims at addressing /proc/stat issue which has been
Applying: update_ts_time_stat currently updates idle time even if we are in iowait
Applying: get_cpu_{idle,iowait}_time_us update idle/iowait counters unconditionally
Applying: show_stat handler of the /proc/stat file relies on kstat_cpu(cpu)
Applying: The address limit is already set in flush_old_exec() so this
Applying: The address limit is already set in flush_old_exec() so this
Applying: Add new check (assert_init) to make sure objects are initialized and
Applying: del_timer_sync() calls debug_object_assert_init() to assert that a timer
Applying: ext4_{set,clear}_bit() is defined as __test_and_{set,clear}_bit_le() for
Applying: The dqc_bitmap field of struct ocfs2_local_disk_chunk is 32-bit aligned,
Applying: The address limit is already set in flush_old_exec() so those calls to
Applying: When do pci remove/rescan on system that have more iommus, got
Applying: The current implementation of dmi_name_in_vendors() is an invitation to
Applying: For headers that get exported to userland and make use of u32 style
Applying: Fix sparse warnings of right shift bigger than source value size:
Applying: We leak in drivers/scsi/aacraid/commctrl.c::aac_send_raw_srb() :
Applying: Some mangling of errors was necessary to maintain current interface.
Applying: This does involve additional use of the spin lock in idr.c.  Is this an
Applying: Instead of open coding this function use kstrtoul_from_user() directly.
Applying: brd_make_request() always returns 0, which doesn't make much sense.
Applying: The address limit is already set in flush_old_exec() so this assignment of
Applying: Unbreak the alpha build.
Applying: Unbreak alpha build.
Applying: Unbreak alpha build.
Applying: When we get corruption reports, it's useful to see if the kernel was
Applying: When we get corruption reports, it's useful to see if the kernel was
Applying: The basic idea behind cross memory attach is to allow MPI programs doing
Applying: - Add x86_64 specific wire up
Applying: > You might get some speed benefit by optimising for the small copies
Applying: acct_isolated of compaction uses page_lru_base_type which returns only
Applying: Change ISOLATE_XXX macro with bitwise isolate_mode_t type.  Normally,
Applying: In async mode, compaction doesn't migrate dirty or writeback pages.  So,
Applying: In __zone_reclaim case, we don't want to shrink mapped page.  Nonetheless,
Applying: unmap_and_move() is one a big messy function.  Clean it up.
Applying: radix_tree_tag_get()'s BUG (when it sees a tag after saw_unset_tag) was
Applying: per-task block plug can reduce block queue lock contention and increase
Applying: The tracing ring-buffer used this function briefly, but not anymore.
Applying: After selecting a task to kill, the oom killer iterates all processes and
Applying: Add the leading word "tmpfs" to the Kconfig string to make it blindingly
Applying: When we get a bad_page bug report, it's useful to see what modules the
Applying: Without swap, anonymous pages are not scanned.  As such, they should not
Applying: fix comment
Applying: The nr_force_scan[] tuple holds the effective scan numbers for anon and
Applying: Some kernel components pin user space memory (infiniband and perf) (by
Applying: Add comments to explain the page statistics field in the mm_struct.
Applying: add missing ;
Applying: Testing from the XFS folk revealed that there is still too much I/O from
Applying: Lumpy reclaim worked with two passes - the first which queued pages for IO
Applying: Direct reclaim should never writeback pages.  For now, handle the
Applying: Direct reclaim should never writeback pages.  Warn if an attempt is made.
Applying: It is preferable that no dirty pages are dispatched for cleaning from the
Applying: Workloads that are allocating frequently and writing files place a large
Applying: When direct reclaim encounters a dirty page, it gets recycled around the
Applying: It's possible a zone watermark is ok when entering the balance_pgdat()
Applying: printk_ratelimit() should not be used, because it shares ratelimiting
Applying: memchr_inv() is mainly used to check whether the whole buffer is filled
Applying: Use newly introduced memchr_inv() for page verification.
Applying: A shrinker function can return -1, means that it cannot do anything
Applying: Use atomic-long operations instead of looping around cmpxchg().
Applying: massage atomic.h inclusions
Applying: The /proc/vmallocinfo shows information about vmalloc allocations in
Applying: Commit 645747462435 ("vmscan: detect mapped file pages used only once")
Applying: Logic added in commit 8cab4754d24a0 ("vmscan: make mapped executable pages
Applying: SPARC32 require access to the start address.  Add a new helper
Applying: With the NO_BOOTMEM symbol added architectures may now use the following
Applying: Using "- 1" relies on the old_end to be page aligned and PAGE_SIZE > 1,
Applying: This replaces ptep_clear_flush() with ptep_get_and_clear() and a single
Applying: This adds THP support to mremap (decreases the number of split_huge_page()
Applying: coding-style nitpicking
Applying: Cc: Andrea Arcangeli <aarcange@redhat.com>
Applying: Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applying: vmstat_text is only available when PROC_FS or SYSFS is enabled.  This
Applying: reduce ifdeffery
Applying: Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applying: Make the security_inode_init_security() initxattrs arg const, to match the
Applying: The current implementation of the /dev/hpet driver couples opening the
Applying: smp_call_function() only lets all other CPUs execute a specific function,
Applying: auto_demotion_disable is called only for online CPUs.  For hotplugged
Applying: Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following warning:
Applying: Strict user copy checks are only really supported on x86_32 even though
Applying: The help text for this config is duplicated across the x86, parisc, and
Applying: s/lib-/obj-/ for usercopy.o
Applying: After an "unexpected" reboot, I found this Oops in my logs:
Applying: In the move of the lis3 driver, the hp_accel.c file got dropped from the
Applying: Add axis correction for HP EliteBook 2730p.
Applying: Add axis correction for HP EliteBook 8540w.
Applying: Add axis correction for HP ProBook 6555b.
Applying: Adapt the help text for CONFIG_HP_ACCEL to the move of
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: Change exported functions to use the device given as parameter
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: We are enabling some power features on medfield.  To test suspend-2-RAM
Applying: We are enabling some power features on medfield.  To test suspend-2-RAM
Applying: We are enabling some power features on medfield.  To test suspend-2-RAM
Applying: Cc: Al Viro <viro@zeniv.linux.org.uk>
Applying: Add V2 of the LED driver for a single timer channel for the TPU hardware
Applying: include linux/module.h
Applying: The memory for struct led_trigger should be kfreed in the
Applying: Currently termination logic (\0 or \n\0) is hardcoded in _kstrtoull(),
Applying: Add support for slice by 8 to existing crc32 algorithm.  Also modify
Applying: don't include asm/msr.h
Applying: epoll can acquire recursively acquire ep->mtx on multiple "struct
Applying: Currently in oprofilefs, files that use ulong_fops mis-handle writes of
Applying: This is the one use of an ida that doesn't retry on receiving -EAGAIN.
Applying: One can get this information from minix/inode.c, but adding the
Applying: The memcg code sometimes uses "struct mem_cgroup *mem" and sometimes uses
Applying: Before calling schedule_timeout(), task state should be changed.
Applying: Signed-off-by: Bob Liu <lliubbo@gmail.com>
Applying: While back-porting Johannes Weiner's patch "mm: memcg-aware global
Applying: If somebody is touching data too early, it might be easier to diagnose a
Applying: Both mem_cgroup_charge_statistics() and mem_cgroup_move_account() were
Applying: On reading sysctl dirs we should return -EISDIR instead of -EINVAL.
Applying: Force this on for -next/mm testing purposes.
Applying: Expand root=PARTUUID=UUID syntax to support selecting a root partition by
Applying: After merging the akpm tree, today's linux-next build (lost of them)
Applying: The discovered bit in PGCCSR register indicates if the device has been
Applying: Add RapidIO mport driver for IDT TSI721 PCI Express-to-SRIO bridge device.
Applying: When I tried to send a patch to remove it, Andi told me we still need to
Applying: A default echo function has been provided so it is no longer an error when
Applying: This client driver allows you to use a GPIO pin as a source for PPS
Applying: remove unneeded cast of void*
Applying: Straightforward.  As an aside, the ida_init calls are not needed as far as
Applying: Simply creates one point to call the w1 interface.
Applying: Adds a nolock function to the w1 interface to avoid locking the
Applying: Fixes the deadlock when inserting and removing the ds2780.
Merging akpm

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

^ permalink raw reply

* Re: Temporary -rcu tree location
From: Paul E. McKenney @ 2011-09-13  4:06 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Jiri Kosina, linux-next, linux-kernel
In-Reply-To: <20110913120716.1b893c483ee91d6b7f12a5b4@canb.auug.org.au>

On Tue, Sep 13, 2011 at 12:07:16PM +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> On Mon, 12 Sep 2011 18:34:00 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > > there doesn't seem to be 'rcu/next' branch, right?
> > 
> > No, there is not.  So the idea is to push "rcu/next" the first time,
> > then ":rcu/next" thereafter?
> 
> Can't you just do a (forced) push over and over again without removing
> the branch each time?

I will give it a try on the next update.  ;-)

							Thanx, Paul

^ permalink raw reply

* ACPI git tree re-locates to github.com
From: Brown, Len @ 2011-09-13  3:03 UTC (permalink / raw)
  To: linux-acpi@vger.kernel.org, Stephen Rothwell
  Cc: linux-kernel@vger.kernel.org, linux-next@vger.kernel.org

Effective immediately...

https://github.com/lenb/linux.git acpi

replaces

git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git test

This is where I will consolidate ACPI-related patches for linux-next,
and upstream.

Note that I reserve the right to re-base this branch from time to time
as needed to revise or remove patches before they are pulled upstream.

Currently there are only a couple of patches on this branch,
and I'll use them as a test case to make sure the workflow is okay.

thanks,
-Len Brown
Intel Open Source Technology Center

^ permalink raw reply

* linux-next: manual merge of the openrisc tree with Linus' tree
From: Stephen Rothwell @ 2011-09-13  2:11 UTC (permalink / raw)
  To: Jonas Bonn; +Cc: linux-next, linux-kernel

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

Hi Jonas,

Today's linux-next merge of the openrisc tree got a conflict in
arch/openrisc/kernel/signal.c between commit d7cb66670905 ("openrisc:
don't use pt_regs in struct sigcontext") from Linus' tree and commit
ddf54eaa745b ("openrisc: don't use pt_regs in struct sigcontext") from
the openrisc tree.

Two slightly differentl versions of the same change.  I used the version
in Linus' tree.

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

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

^ permalink raw reply

* Re: Temporary -rcu tree location
From: Stephen Rothwell @ 2011-09-13  2:07 UTC (permalink / raw)
  To: paulmck; +Cc: Jiri Kosina, linux-next, linux-kernel
In-Reply-To: <20110913013400.GB2313@linux.vnet.ibm.com>

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

Hi Paul,

On Mon, 12 Sep 2011 18:34:00 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> > there doesn't seem to be 'rcu/next' branch, right?
> 
> No, there is not.  So the idea is to push "rcu/next" the first time,
> then ":rcu/next" thereafter?

Can't you just do a (forced) push over and over again without removing
the branch each time?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

^ permalink raw reply

* Re: linux-next: manual merge of the arm-soc tree with the arm tree
From: Stephen Rothwell @ 2011-09-13  1:55 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: Arnd Bergmann, linux-next, linux-kernel, David Brown,
	Russell King
In-Reply-To: <4E6D6C0D.60100@codeaurora.org>

Hi Stephen,

On Sun, 11 Sep 2011 19:18:53 -0700 Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> The device tree machine description also needs to have the .fixup and
> .reserve callbacks added to it so that the device tree machines boot
> properly. Perhaps the soc tree needs to pull in Russell's tree at some
> point to resolve this subtle logical conflict or when the trees are
> merged together someone will need to do an evil merge and add the
> callbacks in the merge commit.

Ah, right.  I have added this merge fixup for today and can carry it as
necessary.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 13 Sep 2011 11:51:48 +1000
Subject: [PATCH] arm-soc: merge fixup for fixup/reserve being added to
 MACHINE descriptions

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mach-msm/board-msm8x60.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-msm/board-msm8x60.c b/arch/arm/mach-msm/board-msm8x60.c
index 328df27..4ad2afb 100644
--- a/arch/arm/mach-msm/board-msm8x60.c
+++ b/arch/arm/mach-msm/board-msm8x60.c
@@ -153,6 +153,8 @@ MACHINE_END
 #ifdef CONFIG_OF
 /* TODO: General device tree support for all MSM. */
 DT_MACHINE_START(MSM_DT, "Qualcomm MSM (Flattened Device Tree)")
+	.fixup = msm8x60_fixup,
+	.reserve = msm8x60_reserve,
 	.map_io = msm8x60_map_io,
 	.init_irq = msm8x60_init_irq,
 	.init_machine = msm8x60_dt_init,
-- 
1.7.5.4

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

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox