linux-next: Tree for Oct 25

linux-next: Tree for Oct 25

[Thierry Reding]

Hi all,

I've uploaded today's linux-next tree to the master branch of the
repository below:

        git://gitorious.org/thierryreding/linux-next.git

A next-20131025 tag is also provided for convenience.

One new trivial conflicts and a new build failure caused by an incorrect
use of the genpool allocator.

Upon a request from Olof Johansson I've only included fixes for build
breakage as a result of interactions between the various trees. But
since I've fixed many of the other build failures already, I've pushed
those to a separate tag (next-20131025-fixes). That builds fine on x86
32-bit and 64-bit allmodconfigs as well as ARM and x86 default
configurations. Most of the PowerPC build errors have also been fixed.

Thierry

linux-next: manual merge of the block tree

[Thierry Reding]

Today's linux-next tree of the block tree got conflicts in

	include/linux/blk_types.h

caused by commits 1063cee (nfs: simplify swap) and 8382f11 (block: make
rq->cmd_flags be 64-bit).

I fixed them up (see below). Please verify that the resolution looks good.

Thanks,
Thierry
---
diff --cc include/linux/blk_types.h
index 1bea25f,238ef0e..2c1c8c9
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@@ -176,7 -176,9 +176,8 @@@ enum rq_flag_bits 
  	__REQ_FLUSH_SEQ,	/* request for flush sequence */
  	__REQ_IO_STAT,		/* account I/O stat */
  	__REQ_MIXED_MERGE,	/* merge of different types, fail separately */
 -	__REQ_KERNEL, 		/* direct IO to kernel pages */
  	__REQ_PM,		/* runtime pm request */
+ 	__REQ_END,		/* last of chain of requests */
  	__REQ_NR_BITS,		/* stops here */
  };
  
@@@ -205,27 -207,29 +206,28 @@@
  #define REQ_NOMERGE_FLAGS \
  	(REQ_NOMERGE | REQ_STARTED | REQ_SOFTBARRIER | REQ_FLUSH | REQ_FUA)
  
- #define REQ_RAHEAD		(1 << __REQ_RAHEAD)
- #define REQ_THROTTLED		(1 << __REQ_THROTTLED)
- 
- #define REQ_SORTED		(1 << __REQ_SORTED)
- #define REQ_SOFTBARRIER		(1 << __REQ_SOFTBARRIER)
- #define REQ_FUA			(1 << __REQ_FUA)
- #define REQ_NOMERGE		(1 << __REQ_NOMERGE)
- #define REQ_STARTED		(1 << __REQ_STARTED)
- #define REQ_DONTPREP		(1 << __REQ_DONTPREP)
- #define REQ_QUEUED		(1 << __REQ_QUEUED)
- #define REQ_ELVPRIV		(1 << __REQ_ELVPRIV)
- #define REQ_FAILED		(1 << __REQ_FAILED)
- #define REQ_QUIET		(1 << __REQ_QUIET)
- #define REQ_PREEMPT		(1 << __REQ_PREEMPT)
- #define REQ_ALLOCED		(1 << __REQ_ALLOCED)
- #define REQ_COPY_USER		(1 << __REQ_COPY_USER)
- #define REQ_FLUSH		(1 << __REQ_FLUSH)
- #define REQ_FLUSH_SEQ		(1 << __REQ_FLUSH_SEQ)
- #define REQ_IO_STAT		(1 << __REQ_IO_STAT)
- #define REQ_MIXED_MERGE		(1 << __REQ_MIXED_MERGE)
- #define REQ_SECURE		(1 << __REQ_SECURE)
- #define REQ_PM			(1 << __REQ_PM)
+ #define REQ_RAHEAD		(1ULL << __REQ_RAHEAD)
+ #define REQ_THROTTLED		(1ULL << __REQ_THROTTLED)
+ 
+ #define REQ_SORTED		(1ULL << __REQ_SORTED)
+ #define REQ_SOFTBARRIER		(1ULL << __REQ_SOFTBARRIER)
+ #define REQ_FUA			(1ULL << __REQ_FUA)
+ #define REQ_NOMERGE		(1ULL << __REQ_NOMERGE)
+ #define REQ_STARTED		(1ULL << __REQ_STARTED)
+ #define REQ_DONTPREP		(1ULL << __REQ_DONTPREP)
+ #define REQ_QUEUED		(1ULL << __REQ_QUEUED)
+ #define REQ_ELVPRIV		(1ULL << __REQ_ELVPRIV)
+ #define REQ_FAILED		(1ULL << __REQ_FAILED)
+ #define REQ_QUIET		(1ULL << __REQ_QUIET)
+ #define REQ_PREEMPT		(1ULL << __REQ_PREEMPT)
+ #define REQ_ALLOCED		(1ULL << __REQ_ALLOCED)
+ #define REQ_COPY_USER		(1ULL << __REQ_COPY_USER)
+ #define REQ_FLUSH		(1ULL << __REQ_FLUSH)
+ #define REQ_FLUSH_SEQ		(1ULL << __REQ_FLUSH_SEQ)
+ #define REQ_IO_STAT		(1ULL << __REQ_IO_STAT)
+ #define REQ_MIXED_MERGE		(1ULL << __REQ_MIXED_MERGE)
+ #define REQ_SECURE		(1ULL << __REQ_SECURE)
 -#define REQ_KERNEL		(1ULL << __REQ_KERNEL)
+ #define REQ_PM			(1ULL << __REQ_PM)
+ #define REQ_END			(1ULL << __REQ_END)
  
  #endif /* __LINUX_BLK_TYPES_H */

Re: linux-next: Tree for Oct 25 (powercap_sys.c)

[Randy Dunlap]

On 10/25/13 08:03, Thierry Reding wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
>         git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131025 tag is also provided for convenience.
> 
> One new trivial conflicts and a new build failure caused by an incorrect
> use of the genpool allocator.
> 
> Upon a request from Olof Johansson I've only included fixes for build
> breakage as a result of interactions between the various trees. But
> since I've fixed many of the other build failures already, I've pushed
> those to a separate tag (next-20131025-fixes). That builds fine on x86
> 32-bit and 64-bit allmodconfigs as well as ARM and x86 default
> configurations. Most of the PowerPC build errors have also been fixed.

on i386:

drivers/powercap/powercap_sys.c:484:2: error: unknown field 'dev_attrs' specified in initializer
drivers/powercap/powercap_sys.c:484:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/powercap/powercap_sys.c:484:2: warning: (near initialization for 'powercap_class.suspend') [enabled by default]



-- 
~Randy

Re: linux-next: Tree for Oct 25 (powercap_sys.c)

[Srinivas Pandruvada]

On 10/25/2013 12:46 PM, Randy Dunlap wrote:
> On 10/25/13 08:03, Thierry Reding wrote:
>> Hi all,
>>
>> I've uploaded today's linux-next tree to the master branch of the
>> repository below:
>>
>>          git://gitorious.org/thierryreding/linux-next.git
>>
>> A next-20131025 tag is also provided for convenience.
>>
>> One new trivial conflicts and a new build failure caused by an incorrect
>> use of the genpool allocator.
>>
>> Upon a request from Olof Johansson I've only included fixes for build
>> breakage as a result of interactions between the various trees. But
>> since I've fixed many of the other build failures already, I've pushed
>> those to a separate tag (next-20131025-fixes). That builds fine on x86
>> 32-bit and 64-bit allmodconfigs as well as ARM and x86 default
>> configurations. Most of the PowerPC build errors have also been fixed.
> on i386:
>
> drivers/powercap/powercap_sys.c:484:2: error: unknown field 'dev_attrs' specified in initializer
> drivers/powercap/powercap_sys.c:484:2: warning: initialization from incompatible pointer type [enabled by default]
> drivers/powercap/powercap_sys.c:484:2: warning: (near initialization for 'powercap_class.suspend') [enabled by default]
Submitted patch and copied to you all.

Thanks,
Srinivas

Re: linux-next: Tree for Oct 25 (powercap_sys.c)

[Srinivas Pandruvada]

Ignore my patch. Already a patch by Thierry Reding is in PM next tree.

Thanks,
Srinivas


On 10/25/2013 03:17 PM, Srinivas Pandruvada wrote:
>
> On 10/25/2013 12:46 PM, Randy Dunlap wrote:
>> On 10/25/13 08:03, Thierry Reding wrote:
>>> Hi all,
>>>
>>> I've uploaded today's linux-next tree to the master branch of the
>>> repository below:
>>>
>>>          git://gitorious.org/thierryreding/linux-next.git
>>>
>>> A next-20131025 tag is also provided for convenience.
>>>
>>> One new trivial conflicts and a new build failure caused by an 
>>> incorrect
>>> use of the genpool allocator.
>>>
>>> Upon a request from Olof Johansson I've only included fixes for build
>>> breakage as a result of interactions between the various trees. But
>>> since I've fixed many of the other build failures already, I've pushed
>>> those to a separate tag (next-20131025-fixes). That builds fine on x86
>>> 32-bit and 64-bit allmodconfigs as well as ARM and x86 default
>>> configurations. Most of the PowerPC build errors have also been fixed.
>> on i386:
>>
>> drivers/powercap/powercap_sys.c:484:2: error: unknown field 
>> 'dev_attrs' specified in initializer
>> drivers/powercap/powercap_sys.c:484:2: warning: initialization from 
>> incompatible pointer type [enabled by default]
>> drivers/powercap/powercap_sys.c:484:2: warning: (near initialization 
>> for 'powercap_class.suspend') [enabled by default]
> Submitted patch and copied to you all.
>
> Thanks,
> Srinivas
>

Re: linux-next: Tree for Oct 25

[Guenter Roeck]

On Fri, Oct 25, 2013 at 05:03:45PM +0200, Thierry Reding wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
>         git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131025 tag is also provided for convenience.
> 
> One new trivial conflicts and a new build failure caused by an incorrect
> use of the genpool allocator.
> 
> Upon a request from Olof Johansson I've only included fixes for build
> breakage as a result of interactions between the various trees. But
> since I've fixed many of the other build failures already, I've pushed
> those to a separate tag (next-20131025-fixes). That builds fine on x86
> 32-bit and 64-bit allmodconfigs as well as ARM and x86 default
> configurations. Most of the PowerPC build errors have also been fixed.
> 
Hi Thierry,

You are making a good point for your previous approach, but maybe it is
necessary to show people the real status of the -next tree.

	total: 110 pass: 4 skipped: 4 fail: 102

All ten qemu tests fail as well, though I didn't check if all are build failures
or if there are some runtime failures.

This is with " v3.12-rc5-8053-g9e11bce".

Guenter

Re: linux-next: Tree for Oct 25 (of_gpio.h)

[Randy Dunlap]

On 10/25/13 08:03, Thierry Reding wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
>         git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131025 tag is also provided for convenience.
> 
> One new trivial conflicts and a new build failure caused by an incorrect
> use of the genpool allocator.
> 
> Upon a request from Olof Johansson I've only included fixes for build
> breakage as a result of interactions between the various trees. But
> since I've fixed many of the other build failures already, I've pushed
> those to a separate tag (next-20131025-fixes). That builds fine on x86
> 32-bit and 64-bit allmodconfigs as well as ARM and x86 default
> configurations. Most of the PowerPC build errors have also been fixed.

on x86_64:

CONFIG_GPIOLIB is not set
CONFIG_OF is not set

In file included from drivers/leds/leds-lp55xx-common.c:24:0:
include/linux/of_gpio.h: In function 'of_get_named_gpio_flags':
include/linux/of_gpio.h:93:3: error: implicit declaration of function 'desc_to_gpio' [-Werror=implicit-function-declaration]

(not specific to leds-lp55xx-common.c)


-- 
~Randy

Re: linux-next: Tree for Oct 25

[Randy Dunlap]

On 10/25/13 08:03, Thierry Reding wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
>         git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131025 tag is also provided for convenience.
> 
> One new trivial conflicts and a new build failure caused by an incorrect
> use of the genpool allocator.
> 
> Upon a request from Olof Johansson I've only included fixes for build
> breakage as a result of interactions between the various trees. But
> since I've fixed many of the other build failures already, I've pushed
> those to a separate tag (next-20131025-fixes). That builds fine on x86
> 32-bit and 64-bit allmodconfigs as well as ARM and x86 default
> configurations. Most of the PowerPC build errors have also been fixed.

That's unfortunate.  The fixes should be part of the tree IMO.


-- 
~Randy

Re: linux-next: Tree for Oct 25

[Mark Brown]

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

On Fri, Oct 25, 2013 at 03:31:44PM -0700, Randy Dunlap wrote:

> That's unfortunate.  The fixes should be part of the tree IMO.

What Stephen does (which does seem like a good policy) is to keep the
tree at the previous day's version instead of taking a new version if it
introduces breakages on the architectures he tests.  That seems to
strike a good balance between keeping things working for users and
providing pushback to get things fixed before they go to Linus.

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

Re: linux-next: Tree for Oct 25

[Thierry Reding]

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

On Fri, Oct 25, 2013 at 03:31:44PM -0700, Randy Dunlap wrote:
> On 10/25/13 08:03, Thierry Reding wrote:
> > Hi all,
> > 
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> > 
> >         git://gitorious.org/thierryreding/linux-next.git
> > 
> > A next-20131025 tag is also provided for convenience.
> > 
> > One new trivial conflicts and a new build failure caused by an incorrect
> > use of the genpool allocator.
> > 
> > Upon a request from Olof Johansson I've only included fixes for build
> > breakage as a result of interactions between the various trees. But
> > since I've fixed many of the other build failures already, I've pushed
> > those to a separate tag (next-20131025-fixes). That builds fine on x86
> > 32-bit and 64-bit allmodconfigs as well as ARM and x86 default
> > configurations. Most of the PowerPC build errors have also been fixed.
> 
> That's unfortunate.  The fixes should be part of the tree IMO.

Cc'ing Olof and Stephen.

Perhaps something like the above scheme might be a good compromise. On
one hand, many people are using linux-next for their daily work, myself
included. That implies that if linux-next doesn't build, people either
use a previous one that does build (so we don't get as much testing of
new trees as we possibly could) or they fix the build errors themselves
which in turn may cause potentially many people to have to fix the same
issues. On the other hand, if patches to fix build issues are included
then people might just assume that there are no problems.

I know that linux-next is a ton of work already and I don't expect this
to be done by Stephen alone. Perhaps people could collaborate some more
and provide a separate tag with additional build fixes and make sure
they get merged into the appropriate subsystems.

With such a scheme next-YYYYMMDD could serve as a metric of how good or
broken the various trees are, while next-YYYYMMDD-fixes would be a base
that people could use for daily work, with a set of known build fixes.
Perhaps it could even contain fixes for non-build issues, such as boot
failures, if we can come up with those quickly enough to make sense in a
linux-next context.

Any thought?

Thierry

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

Re: linux-next: Tree for Oct 25

[Mark Brown]

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

On Mon, Oct 28, 2013 at 09:01:24AM +0100, Thierry Reding wrote:

> Perhaps something like the above scheme might be a good compromise. On
> one hand, many people are using linux-next for their daily work, myself
> included. That implies that if linux-next doesn't build, people either
> use a previous one that does build (so we don't get as much testing of
> new trees as we possibly could) or they fix the build errors themselves
> which in turn may cause potentially many people to have to fix the same
> issues. On the other hand, if patches to fix build issues are included
> then people might just assume that there are no problems.

This is one of the things that the per merge build tests really help
with - they filter out the vast majority of errors by just not letting
updates into -next (which applies some backpressure to get thing fixed
in the original tree too).

> With such a scheme next-YYYYMMDD could serve as a metric of how good or
> broken the various trees are, while next-YYYYMMDD-fixes would be a base
> that people could use for daily work, with a set of known build fixes.
> Perhaps it could even contain fixes for non-build issues, such as boot
> failures, if we can come up with those quickly enough to make sense in a
> linux-next context.

> Any thought?

This seems really tough to do given the rate of change of -next -
there's about 24 hours to get fixes in there before you have to rebase
forwards again.

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