* [PATCH -next] staging: fix rts5139 depends & build
From: Randy Dunlap @ 2011-08-26 18:06 UTC (permalink / raw)
To: Stephen Rothwell, Edwin Rong, gregkh, akpm; +Cc: linux-next, LKML, driverdevel
In-Reply-To: <20110826150000.302334d0b86c17cd9b89b590@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
RTS5139 should depend on USB, not USB_SUPPORT, to fix build
errors.
USB_SUPPORT can be enabled for gadget-only support
or when PCI is not enabled.
ERROR: "usb_reset_endpoint" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_kill_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_deregister_dev" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_unlink_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_deregister" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_register_dev" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_free_coherent" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_submit_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_sg_cancel" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_find_interface" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_sg_init" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_register_driver" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_alloc_coherent" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_free_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
ERROR: "usb_alloc_urb" [drivers/staging/rts5139/rts5139.ko] undefined!
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Edwin Rong <edwin_rong@realsil.com.cn>
---
drivers/staging/rts5139/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20110826.orig/drivers/staging/rts5139/Kconfig
+++ linux-next-20110826/drivers/staging/rts5139/Kconfig
@@ -1,6 +1,6 @@
config RTS5139
tristate "Realtek RTS5139 USB card reader support"
- depends on USB_SUPPORT && SCSI
+ depends on USB && SCSI
help
Say Y here to include driver code to support the Realtek
RTS5139 USB card readers.
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Sedat Dilek @ 2011-08-26 17:54 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Mauro Carvalho Chehab, linux-next, LKML,
linux-edac
In-Reply-To: <20110826104031.4c5861e5.rdunlap@xenotime.net>
On Fri, Aug 26, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Fri, 26 Aug 2011 16:16:11 +0200 Sedat Dilek wrote:
>
>> On Fri, Aug 26, 2011 at 10:07 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> >
>> > On Thu, August 25, 2011 10:00 pm, Stephen Rothwell wrote:
>> >> Hi all,
>> >>
>> >> The powerpc allyesconfig build still fails today.
>> >>
>> >> Changes since 20110825:
>> >
>> >
>> > on i386:
>> >
>> > ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!
>> >
>> > in both get_sdram_scrub_rate()
>> > and set_sdram_scrub_rate()
>> >
>> > --
>>
>> Hi Randy,
>>
>> can you test with the patch attached, please?
>>
>> ( UNTESTED, just followed patches like "[PATCH] p54: Use do_div for
>> 64-bit division to fix 32-bit kernels" or "[PATCH v1] carl9170: Use
>> do_div for 64-bit division to fix 32-bit kernels" )
>
> Yes, this works after I removed the extra right parens in both cases.
The closing brackets were a test for you (indeed they are wrong).
> (did you test it?)
>
No, even not compile-tested, still struggling with todays linux-next.
Seems I am not alone [1].
- Sedat -
[1] http://lkml.org/lkml/2011/8/26/300
> thanks,
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Randy Dunlap @ 2011-08-26 17:40 UTC (permalink / raw)
To: sedat.dilek
Cc: Sedat Dilek, Stephen Rothwell, Mauro Carvalho Chehab, linux-next,
LKML, linux-edac
In-Reply-To: <CA+icZUX1zaw7xxka8yP4B0tFt7XgXe=8faw8vBnNWm+6teJVaA@mail.gmail.com>
On Fri, 26 Aug 2011 16:16:11 +0200 Sedat Dilek wrote:
> On Fri, Aug 26, 2011 at 10:07 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> >
> > On Thu, August 25, 2011 10:00 pm, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> The powerpc allyesconfig build still fails today.
> >>
> >> Changes since 20110825:
> >
> >
> > on i386:
> >
> > ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!
> >
> > in both get_sdram_scrub_rate()
> > and set_sdram_scrub_rate()
> >
> > --
>
> Hi Randy,
>
> can you test with the patch attached, please?
>
> ( UNTESTED, just followed patches like "[PATCH] p54: Use do_div for
> 64-bit division to fix 32-bit kernels" or "[PATCH v1] carl9170: Use
> do_div for 64-bit division to fix 32-bit kernels" )
Yes, this works after I removed the extra right parens in both cases.
(did you test it?)
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (evm)
From: Randy Dunlap @ 2011-08-26 17:00 UTC (permalink / raw)
To: Mimi Zohar
Cc: Arnaud Lacombe, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
In-Reply-To: <1314362342.3224.19.camel@localhost.localdomain>
On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:
> On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
> > Hi,
> >
> > On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > > I think that you are going to need to do something like Arnaud suggested
> > > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> > > unless you can convince someone that this is a kconfig bug.
> > >
> > dammit... I guess there is...
> >
> > If you consider the following Kconfig:
> >
> > config MOD
> > bool
> > default y
> > option modules
> >
> > config EXPERIMENTAL
> > bool
> > default y
> >
> > menuconfig A
> > tristate "A"
> > depends on EXPERIMENTAL
> >
> > config B
> > bool "B"
> >
> > config B0
> > bool
> >
> > config C
> > tristate "C"
> > depends on B
> >
> > config C0
> > tristate
> >
> > config D
> > boolean "D"
> > depends on A && B
> > select C
> > select C0
> >
> > config E
> > tristate "E"
> >
> > config F
> > tristate "F"
> > select E
> >
> > B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
> > (TCG_TPM) allows to set D (EVM), which will select (C). Now,
> > menuconfig highlight the problem very well. Proceeding as following
> > A=m, B=y, C=m, E=y, F=y, we ends up having:
> >
> > <M> A --->
> > [*] B
> > {M} C
> > [*] D
> > -*- E
> > <*> F
> >
> > which translate in the following config:
> >
> > CONFIG_MOD=y
> > CONFIG_EXPERIMENTAL=y
> > CONFIG_A=m
> > CONFIG_B=y
> > CONFIG_C=m
> > CONFIG_C0=m
> > CONFIG_D=y
> > CONFIG_E=y
> > CONFIG_F=y
> >
> > I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
> > If you remove D's dependency on 'A', everything works as expected. So
> > it would seem direct dependency state influence the state of reverse
> > dependencies...
> >
> > Will have a look...
> >
> > - Arnaud
>
> Thanks for looking into this! Instead of changing 'TCG_TPM' to
> 'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
> I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
> on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
> TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
Yes, linux-next (randconfig) builds are still failing, so we need something
to prevent that.
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* RE: linux-next: Tree for Aug 25
From: Zou, Yi @ 2011-08-26 16:59 UTC (permalink / raw)
To: Bhanu Prakash Gollapudi, Randy Dunlap
Cc: Stephen Rothwell, linux-scsi@vger.kernel.org,
linux-next@vger.kernel.org, LKML, Love, Robert W,
devel@open-fcoe.org
In-Reply-To: <4E57CCEC.9060000@broadcom.com>
>
> On 8/26/2011 12:26 AM, Randy Dunlap wrote:
> >
> > On Wed, August 24, 2011 11:35 pm, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> The powerpc allyesconfig build still fails today.
> >
> >
> > CONFIG_FCOE is not enabled:
> >
> > drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function 'bnx2fc_net_config':
> > drivers/scsi/bnx2fc/bnx2fc_fcoe.c:765: error: 'NETDEV_FCOE_WWNN'
> > undeclared (first use in this function)
> > drivers/scsi/bnx2fc/bnx2fc_fcoe.c:771: error: 'NETDEV_FCOE_WWPN'
> > undeclared (first use in this function)
> >
> >
> > Maybe this driver should select FCOE?
> bnx2fc does not depend on FCOE. Instead both fcoe and bnx2fc drivers
> depend on LIBFCOE. So, I'll modify to access
> NETDEV_FCOE_WWNN/NETDEV_FCOE_WWPN when CONFIG_LIBFCOE is enabled.
>
Yes, both these two flags and ndo_fcoe_get_wwn() should be wrapped by
CONFIG_LIBFCOE || CONFIG_LIBFCOE_MODULE as bnx2fc is also using the get_wwn
hook I believe. Historically on fcoe module was using them.
> Patch will be submitted soon.
Thanks,
yi
>
> Thanks,
> Bhanu
> >
> > ~Randy
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: Tree for Aug 25
From: Bhanu Prakash Gollapudi @ 2011-08-26 16:42 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-scsi@vger.kernel.org,
linux-next@vger.kernel.org, LKML, robert.w.love@intel.com,
devel@open-fcoe.org
In-Reply-To: <885a6d6210a7d4c56601380f146e7ba9.squirrel@xenotime.net>
On 8/26/2011 12:26 AM, Randy Dunlap wrote:
>
> On Wed, August 24, 2011 11:35 pm, Stephen Rothwell wrote:
>> Hi all,
>>
>> The powerpc allyesconfig build still fails today.
>
>
> CONFIG_FCOE is not enabled:
>
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function 'bnx2fc_net_config':
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c:765: error: 'NETDEV_FCOE_WWNN'
> undeclared (first use in this function)
> drivers/scsi/bnx2fc/bnx2fc_fcoe.c:771: error: 'NETDEV_FCOE_WWPN'
> undeclared (first use in this function)
>
>
> Maybe this driver should select FCOE?
bnx2fc does not depend on FCOE. Instead both fcoe and bnx2fc drivers
depend on LIBFCOE. So, I'll modify to access
NETDEV_FCOE_WWNN/NETDEV_FCOE_WWPN when CONFIG_LIBFCOE is enabled.
Patch will be submitted soon.
Thanks,
Bhanu
>
> ~Randy
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Arnaud Lacombe @ 2011-08-26 15:47 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel
In-Reply-To: <20110826103932.1626f1c5542b660bcd1b24aa@canb.auug.org.au>
Hi,
[Removed PPC folks from the CC list, the conversation drifted.]
On Thu, Aug 25, 2011 at 8:39 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Arnaud,
>
> On Thu, 25 Aug 2011 12:09:20 -0400 Arnaud Lacombe <lacombar@gmail.com> wrote:
>>
>> If you could provide an exhaustive list of them, I'd be interested. Do
>> you account/reference them in the report you make on each new -next
>> tree ?
>
> I don't refer to them at all :-(
>
> If you are not just referring to powerpc ones, then an x86_64
> allmodconfig is a good place to start, there are several in there.
>
> Otherwise, I will send you the results of some of my builds this evening.
>
Couldn't all the error log be public, rotated over a 7 iteration
period ? That would be fair to everyone.
Thanks,
- Arnaud
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Borislav Petkov @ 2011-08-26 14:48 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: Randy Dunlap, Stephen Rothwell, Mauro Carvalho Chehab,
linux-next@vger.kernel.org, LKML, linux-edac@vger.kernel.org
In-Reply-To: <CA+icZUX1zaw7xxka8yP4B0tFt7XgXe=8faw8vBnNWm+6teJVaA@mail.gmail.com>
On Fri, Aug 26, 2011 at 10:16:11AM -0400, Sedat Dilek wrote:
> ( UNTESTED, just followed patches like "[PATCH] p54: Use do_div for
> 64-bit division to fix 32-bit kernels" or "[PATCH v1] carl9170: Use
> do_div for 64-bit division to fix 32-bit kernels" )
>
> Regards,
> - Sedat -
> diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
> index 7cb68de..4d4f3a5 100644
> --- a/drivers/edac/i7core_edac.c
> +++ b/drivers/edac/i7core_edac.c
> @@ -37,6 +37,7 @@
> #include <linux/smp.h>
> #include <asm/mce.h>
> #include <asm/processor.h>
> +#include <asm/div64.h>
>
> #include "edac_core.h"
>
> @@ -2102,7 +2103,8 @@ static int set_sdram_scrub_rate(struct mem_ctl_info *mci, u32 new_bw)
> * program the corresponding register value.
> */
> scrub_interval = (unsigned long long)freq_dclk_mhz *
> - cache_line_size * 1000000 / new_bw;
> + cache_line_size * 1000000);
> + do_div(scrub_interval, new_bw);
This has been an issue pretty often lately on lkml. Instead of doing
64-bit division on 32-bit (which is really slow), you could try to use
the commutative property of integer multiplication and thus reorder the
operations so that the division is 32-bit only. Maybe
((freq_dclk_mhz * cache_line_size) / new_bw) * 1000000
for example. You have to make sure though that new_bw as divisor can
never be bigger than the dividend because otherwise you get the 0. One
question would be what is the interval of freq_dclk_mhz and can (new_bw >> 6)
be ever bigger than it.
And while at it, the cache_line_size is pretty solidly staying 64 Byte
in the short-term future so no need for a local variable. Also, shifting
left by 6 should be a faster equivalent than multiplying by 64.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Sedat Dilek @ 2011-08-26 14:16 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Mauro Carvalho Chehab, linux-next, LKML,
linux-edac
In-Reply-To: <205ae102ed038641e32cf38c48334f9e.squirrel@xenotime.net>
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On Fri, Aug 26, 2011 at 10:07 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> On Thu, August 25, 2011 10:00 pm, Stephen Rothwell wrote:
>> Hi all,
>>
>> The powerpc allyesconfig build still fails today.
>>
>> Changes since 20110825:
>
>
> on i386:
>
> ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!
>
> in both get_sdram_scrub_rate()
> and set_sdram_scrub_rate()
>
> --
> ~Randy
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi Randy,
can you test with the patch attached, please?
( UNTESTED, just followed patches like "[PATCH] p54: Use do_div for
64-bit division to fix 32-bit kernels" or "[PATCH v1] carl9170: Use
do_div for 64-bit division to fix 32-bit kernels" )
Regards,
- Sedat -
[-- Attachment #2: i7core_edac.c.diff --]
[-- Type: text/x-patch, Size: 1032 bytes --]
diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index 7cb68de..4d4f3a5 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -37,6 +37,7 @@
#include <linux/smp.h>
#include <asm/mce.h>
#include <asm/processor.h>
+#include <asm/div64.h>
#include "edac_core.h"
@@ -2102,7 +2103,8 @@ static int set_sdram_scrub_rate(struct mem_ctl_info *mci, u32 new_bw)
* program the corresponding register value.
*/
scrub_interval = (unsigned long long)freq_dclk_mhz *
- cache_line_size * 1000000 / new_bw;
+ cache_line_size * 1000000);
+ do_div(scrub_interval, new_bw);
if (!scrub_interval || scrub_interval > SCRUBINTERVAL_MASK)
return -EINVAL;
@@ -2153,7 +2155,8 @@ static int get_sdram_scrub_rate(struct mem_ctl_info *mci)
/* Calculate scrub rate value into byte/sec bandwidth */
scrub_rate = (unsigned long long)freq_dclk_mhz *
- 1000000 * cache_line_size / scrubval;
+ 1000000 * cache_line_size);
+ do_div(scrub_rate, scrubval);
return (int)scrub_rate;
}
^ permalink raw reply related
* Re: linux-next: Tree for Aug 22 (evm)
From: Mimi Zohar @ 2011-08-26 12:39 UTC (permalink / raw)
To: Arnaud Lacombe
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
In-Reply-To: <CACqU3MWfKji5BcGRmwO_Y4_15oOq7Trw3u6j1g2meFAaG-s9-w@mail.gmail.com>
On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > I think that you are going to need to do something like Arnaud suggested
> > and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> > unless you can convince someone that this is a kconfig bug.
> >
> dammit... I guess there is...
>
> If you consider the following Kconfig:
>
> config MOD
> bool
> default y
> option modules
>
> config EXPERIMENTAL
> bool
> default y
>
> menuconfig A
> tristate "A"
> depends on EXPERIMENTAL
>
> config B
> bool "B"
>
> config B0
> bool
>
> config C
> tristate "C"
> depends on B
>
> config C0
> tristate
>
> config D
> boolean "D"
> depends on A && B
> select C
> select C0
>
> config E
> tristate "E"
>
> config F
> tristate "F"
> select E
>
> B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
> (TCG_TPM) allows to set D (EVM), which will select (C). Now,
> menuconfig highlight the problem very well. Proceeding as following
> A=m, B=y, C=m, E=y, F=y, we ends up having:
>
> <M> A --->
> [*] B
> {M} C
> [*] D
> -*- E
> <*> F
>
> which translate in the following config:
>
> CONFIG_MOD=y
> CONFIG_EXPERIMENTAL=y
> CONFIG_A=m
> CONFIG_B=y
> CONFIG_C=m
> CONFIG_C0=m
> CONFIG_D=y
> CONFIG_E=y
> CONFIG_F=y
>
> I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
> If you remove D's dependency on 'A', everything works as expected. So
> it would seem direct dependency state influence the state of reverse
> dependencies...
>
> Will have a look...
>
> - Arnaud
Thanks for looking into this! Instead of changing 'TCG_TPM' to
'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'. Then when
I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
TRUSTED_KEYS=n)'. Do you want a temporary fix for now?
thanks,
Mimi
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (i7core_edac)
From: Randy Dunlap @ 2011-08-26 8:07 UTC (permalink / raw)
To: Stephen Rothwell, Mauro Carvalho Chehab; +Cc: linux-next, LKML, linux-edac
In-Reply-To: <20110826150000.302334d0b86c17cd9b89b590@canb.auug.org.au>
On Thu, August 25, 2011 10:00 pm, Stephen Rothwell wrote:
> Hi all,
>
> The powerpc allyesconfig build still fails today.
>
> Changes since 20110825:
on i386:
ERROR: "__udivdi3" [drivers/edac/i7core_edac.ko] undefined!
in both get_sdram_scrub_rate()
and set_sdram_scrub_rate()
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for Aug 25
From: Randy Dunlap @ 2011-08-26 7:26 UTC (permalink / raw)
To: Stephen Rothwell, linux-scsi; +Cc: linux-next, LKML
In-Reply-To: <20110825163515.0ed2cf354f61a3e9c53564b2@canb.auug.org.au>
On Wed, August 24, 2011 11:35 pm, Stephen Rothwell wrote:
> Hi all,
>
> The powerpc allyesconfig build still fails today.
CONFIG_FCOE is not enabled:
drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function 'bnx2fc_net_config':
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:765: error: 'NETDEV_FCOE_WWNN'
undeclared (first use in this function)
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:771: error: 'NETDEV_FCOE_WWPN'
undeclared (first use in this function)
Maybe this driver should select FCOE?
~Randy
^ permalink raw reply
* Re: mmotm 2011-08-24-14-08 uploaded
From: Michal Hocko @ 2011-08-26 7:21 UTC (permalink / raw)
To: Johannes Weiner
Cc: Stephen Rothwell, akpm, mm-commits, linux-kernel, linux-mm,
linux-fsdevel, linux-next
In-Reply-To: <20110825154538.GA5860@redhat.com>
On Thu 25-08-11 17:45:38, Johannes Weiner wrote:
> On Fri, Aug 26, 2011 at 01:09:38AM +1000, Stephen Rothwell wrote:
> > Hi,
> >
> > On Thu, 25 Aug 2011 16:07:01 +0200 Michal Hocko <mhocko@suse.cz> wrote:
> > >
> > > On Thu 25-08-11 15:51:03, Michal Hocko wrote:
> > > >
> > > > On Wed 24-08-11 14:09:05, Andrew Morton wrote:
> > > > > The mm-of-the-moment snapshot 2011-08-24-14-08 has been uploaded to
> > > > >
> > > > > http://userweb.kernel.org/~akpm/mmotm/
> > > >
> > > > I have just downloaded your tree and cannot quilt it up. I am getting:
> > > > [...]
> > > > patching file tools/power/cpupower/debug/x86_64/centrino-decode.c
> > > > Hunk #1 FAILED at 1.
> > > > File tools/power/cpupower/debug/x86_64/centrino-decode.c is not empty after patch, as expected
> > > > 1 out of 1 hunk FAILED -- rejects in file tools/power/cpupower/debug/x86_64/centrino-decode.c
> > > > patching file tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
> > > > Hunk #1 FAILED at 1.
> > > > File tools/power/cpupower/debug/x86_64/powernow-k8-decode.c is not empty after patch, as expected
> > > > 1 out of 1 hunk FAILED -- rejects in file tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
> > > > [...]
> > > > patching file virt/kvm/iommu.c
> > > > Patch linux-next.patch does not apply (enforce with -f)
> > > >
> > > > Is this a patch (I am using 2.6.1) issue? The failing hunk looks as
> > > > follows:
> > > > --- a/tools/power/cpupower/debug/x86_64/centrino-decode.c
> > > > +++ /dev/null
> > > > @@ -1 +0,0 @@
> > > > -../i386/centrino-decode.c
> > > > \ No newline at end of file
> > >
> > > Isn't this just a special form of git (clever) diff to spare some lines
> > > when the file deleted? Or is the patch simply corrupted?
> > > Anyway, my patch doesn't cope with that. Any hint what to do about it?
> >
> > Those files were symlinks and were removed by a commit in linux-next.
> > diff/patch does not cope with that.
Ahh, symlinks. I had a feeling that I had already seen a diff like that.
> You can probably replace `patch' in your $PATH by a wrapper that uses
> git-apply, which can deal with them.
>
> Or you could use git-quiltimport, which uses git-apply, to prepare the
> -mmotm base tree in git, on top of which you can continue to work with
> quilt.
Thanks for hints!
>
> I do this with a cron-job automatically, you can find the result here:
>
> http://git.kernel.org/?p=linux/kernel/git/hannes/linux-mmotm.git;a=summary
I was more interested in integration to our SuSE kernel tree to have
easier life with rpm creation and stuff (and we use quilt to build the
source tree). Anyway the above should be suffiecient to go on.
>
> If you want to do it manually, there is sometimes confusing binary
> file patch sections in -mmotm, which in turn git-apply can not deal
> with, so I use the following uncrapdiff.awk filter on the patches
> before import.
>
> ---
>
> # Filter out sections that feature an index line but
> # no real diff part that would start with '--- file'
>
> {
> if (HEADER ~ /^diff --git /) {
> if ($0 ~ /^index /) {
> INDEX=$0
> } else if ($0 ~ /^diff --git /) {
> print(HEADER)
> HEADER=$0
> } else if (INDEX ~ /^index /) {
> if ($0 ~ /^--- /) {
> print(HEADER)
> print(INDEX)
> print($0)
> }
> HEADER=""
> INDEX=""
> } else {
> HEADER=HEADER "\n" $0
> }
> } else if ($0 ~ /^diff --git /) {
> HEADER=$0
> } else {
> print($0)
> }
> }
>
> ---
>
> HTH
Definitely did.
Thanks
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree with the net tree
From: Larry Finger @ 2011-08-26 5:35 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, linux-next, linux-kernel, Jiri Pirko,
David Miller, netdev
In-Reply-To: <20110826043357.GA17686@kroah.com>
On 08/25/2011 11:33 PM, Greg KH wrote:
> On Fri, Aug 26, 2011 at 01:47:05PM +1000, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> Today's linux-next merge of the staging tree got a conflict in
>> drivers/staging/rtl8192e/r8192E_core.c between commit afc4b13df143 ("net:
>> remove use of ndo_set_multicast_list in drivers") from the net tree and
>> commit 09505184ec3d ("staging: rtl8192e: Remove files that are not used")
>> from the staging tree.
>>
>> The latter removed the file, so I did that.
>
> Thanks, that should be the correct thing :)
I'm a little confused. The files deleted in 09505184ec3d are not used at all in
the new rtl8192e. The only way it makes sense is you did not have the new
version when the the error with r8192E_core.c occurred.
The error that was reported to me was
"drivers/staging/rtl8192e/rtl_core.c:2917:2: error: unknown field
'ndo_set_multicast_list' specified in initializer". The file rtl_core.c is
needed with the new version. Yes, the names are quite confusing, which is part
of the reason it took so long to delete the unused ones.
I have tested Stephan's patch and will send it to Greg with my SOB.
Larry
^ permalink raw reply
* linux-next: Tree for Aug 26
From: Stephen Rothwell @ 2011-08-26 5:00 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 23862 bytes --]
Hi all,
The powerpc allyesconfig build still fails today.
Changes since 20110825:
The slave-dma tree gained a conflict against Linus' tree.
I have reverted the x86/spinlocks branch from the tip tree for today.
The ptrace tree lost its build failure.
The xen tree lost its conflict since I reveretd the version of the same
patches in the tip tree..
The tty tree still has its build failure but I applied a supplied test
patch for it.
The staging tree lost its build failures and gained a conflict against
the net tree.
The moduleh tree lost a conflict.
The akpm tree lost its build failure.
----------------------------------------------------------------------------
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 199 trees (counting Linus' and 28 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 fbdev-current/fbdev-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/pgalloc.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/mm/dma-mapping.c
CONFLICT (content): Merge conflict in arch/arm/mm/mmu.c
Merging arm-soc/for-next
Merging at91/at91-next
Merging davinci/davinci-next
Merging i.MX/for-next
Merging linux-spec/for-next
Merging msm/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-msm/io.c
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
Merging tegra/for-next
Merging ux500-core/ux500-core
Merging xilinx/arm-next
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging openrisc/for-upstream
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
Merging ubifs/linux-next
Merging xfs/master
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
CONFLICT (content): Merge conflict in drivers/dma/amba-pl08x.c
Merging async_tx/next
Merging net/master
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.
CONFLICT (content): Merge conflict in drivers/net/Kconfig
CONFLICT (content): Merge conflict in drivers/net/Makefile
$ git rm -f arch/powerpc/configs/40x/hcu4_defconfig
Applying: powerpc: update ppc64_defconfig for net device movement
Applying: sparc: update sparc32_defconfig for net device movement
Applying: sparc: update sparc64_defconfig for net device movement
Merging wireless/master
Merging bluetooth/master
Merging mtd/master
Merging l2-mtd/master
CONFLICT (content): Merge conflict in drivers/mtd/maps/lantiq-flash.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
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/master
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 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 2dfbfee] 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
Merging tty/tty-next
Applying: tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
Merging usb/usb-next
CONFLICT (content): Merge conflict in drivers/usb/host/xhci-ring.c
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
Applying: rtl8192e: update for ndo_set_multicast_list removal.
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): Recorded preimage for 'drivers/staging/iio/gyro/adis16060_core.c'
CONFLICT (content): Merge conflict in drivers/staging/iio/gyro/adis16060_core.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: Found on allmodconfig build (ARCH=alpha)
Applying: The bug was accidentally found by the following program:
Applying: WARNING: line over 80 characters
Applying: The for loop was looking for i <= 0 instead of i >= 0 so this function
Applying: Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net>
Applying: Commit d1a05b6 ("memcg do not try to drain per-cpu caches without pages")
Applying: Change to new git tree -
Applying: The test for bad usage of min_t() and max_t() is missing the --ignore
Applying: The various basic memory allocation function return NULL, not an ERR_PTR.
Applying: I get below warnning:
Applying: Paul said: I left Google at the end of last week - if it's not bouncing
Applying: It seems that 7bf693951a8e ("console: allow to retain boot console via
Applying: ZONE_CONGESTED is only cleared in kswapd, but pages can be freed in any
Applying: Replace/remove use of RIO v.1.2 registers/bits that are not
Applying: ep93xx_bl.c uses interfaces from linux/module.h,
Applying: Add missing include of linux/module.h for drivers that use interfaces from
Applying: Commit 79dfdac ("memcg: make oom_lock 0 and 1 based rather than counter")
Applying: We need a callback to do some things after pwm_enable, pwm_disable
Applying: This is a i2c driver, not a platform driver, thus use "i2c" prefix for the
Applying: Make sure we are passing the same cookie in all calls to
Applying: Since 43cc71eed1250 ("platform: prefix MODALIAS with "platform:""), the
Applying: Fix the following build errors:
Applying: bd2802_unregister_led_classdev() should unregister all registered
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: Fix the following memory leak:
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: The RETE bit in IECSR is cleared by writing a 1 to it.
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: kernel/rtmutex.c: In function '__rt_mutex_slowlock':
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: Signed-off-by: WANG Cong <amwang@redhat.com>
Applying: Signed-off-by: WANG Cong <amwang@redhat.com>
Applying: Signed-off-by: WANG Cong <amwang@redhat.com>
Applying: This is only an error, no need to use KERN_CRIT log level.
Applying: Signed-off-by: WANG Cong <amwang@redhat.com>
Applying: ERROR: code indent should use tabs where possible
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: linux-next: manual merge of the staging tree with the net tree
From: Greg KH @ 2011-08-26 4:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Jiri Pirko, David Miller, netdev,
Larry Finger
In-Reply-To: <20110826134705.0d5b6767777f0af2f8667731@canb.auug.org.au>
On Fri, Aug 26, 2011 at 01:47:05PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/rtl8192e/r8192E_core.c between commit afc4b13df143 ("net:
> remove use of ndo_set_multicast_list in drivers") from the net tree and
> commit 09505184ec3d ("staging: rtl8192e: Remove files that are not used")
> from the staging tree.
>
> The latter removed the file, so I did that.
Thanks, that should be the correct thing :)
greg k-h
^ permalink raw reply
* linux-next: manual merge of the staging tree with the net tree
From: Stephen Rothwell @ 2011-08-26 3:47 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Jiri Pirko, David Miller, netdev,
Larry Finger
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/rtl8192e/r8192E_core.c between commit afc4b13df143 ("net:
remove use of ndo_set_multicast_list in drivers") from the net tree and
commit 09505184ec3d ("staging: rtl8192e: Remove files that are not used")
from the staging tree.
The latter removed the file, so I did that.
--
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: [PATCH] [v2] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Stephen Rothwell @ 2011-08-26 3:33 UTC (permalink / raw)
To: Timur Tabi; +Cc: greg, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <1314295617-2953-1-git-send-email-timur@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
Hi all,
On Thu, 25 Aug 2011 13:06:57 -0500 Timur Tabi <timur@freescale.com> wrote:
>
> The ePAPR hypervisor byte channel driver is supposed to work on all
> ePAPR-compliant embedded PowerPC systems, but it had a reference to the MSR_GS
> bit, which is available only on Book-E systems.
>
> Also fix a couple integer-to-pointer typecast problems.
I applied this to linux-next today.
--
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: Stephen Rothwell @ 2011-08-26 2:54 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: <4E56D6E1.6030405@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
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.
--
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 slave-dma tree with Linus' tree
From: Stephen Rothwell @ 2011-08-26 1:46 UTC (permalink / raw)
To: Vinod Koul; +Cc: linux-next, linux-kernel, Viresh Kumar, Russell King
Hi Vinod,
Today's linux-next merge of the slave-dma tree got a conflict in
drivers/dma/amba-pl08x.c between commit 4d66164e997e ("dmaengine: PL08x:
Fix trivial build error") from Linus' tree and commit 0c38d7013913
("dmaengine/amba-pl08x: Rearrange inclusion of header files in ascending
order") from the slave-dma tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/dma/amba-pl08x.c
index be21e3f,849eab8..0000000
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@@ -77,17 -72,16 +72,17 @@@
#include <linux/amba/bus.h>
#include <linux/amba/pl08x.h>
#include <linux/debugfs.h>
+ #include <linux/delay.h>
+ #include <linux/device.h>
+ #include <linux/dmaengine.h>
+ #include <linux/dmapool.h>
++#include <linux/dma-mapping.h>
+ #include <linux/init.h>
+ #include <linux/interrupt.h>
+ #include <linux/module.h>
+ #include <linux/pm_runtime.h>
#include <linux/seq_file.h>
-
+ #include <linux/slab.h>
#include <asm/hardware/pl080.h>
#define DRIVER_NAME "pl08xdmac"
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Stephen Rothwell @ 2011-08-26 0:39 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Timur Tabi, Greg KH, linux-next, linux-kernel, ppc-dev
In-Reply-To: <CACqU3MUs_97=MuuKAjr-LeUT7kSRxtzSntwUeKeeH4n8s7SSGg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
Hi Arnaud,
On Thu, 25 Aug 2011 12:09:20 -0400 Arnaud Lacombe <lacombar@gmail.com> wrote:
>
> If you could provide an exhaustive list of them, I'd be interested. Do
> you account/reference them in the report you make on each new -next
> tree ?
I don't refer to them at all :-(
If you are not just referring to powerpc ones, then an x86_64
allmodconfig is a good place to start, there are several in there.
Otherwise, I will send you the results of some of my builds this evening.
--
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: H. Peter Anvin @ 2011-08-25 23:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jeremy Fitzhardinge, Xen Devel, linux-next, linux-kernel,
Thomas Gleixner, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110826090619.7588d424798f53a6f3621eb2@canb.auug.org.au>
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.
-hpa
^ permalink raw reply
* Re: linux-next: manual merge of the moduleh tree with the arm tree
From: Stephen Rothwell @ 2011-08-25 23:11 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Russell King, linux-next, linux-kernel, Jon Medhurst
In-Reply-To: <4E56CF76.70201@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
Hi Paul,
On Thu, 25 Aug 2011 18:40:54 -0400 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> OK. I was entertaining feeding some of the really obvious and simple
> parts of the moduleh branch out to the various maintainers just to
> reduce its overall size, but in the end I guess that just makes work
> for me and them -- vs. a single pull request to Linus for addition to
> v3.2-rc1. I'll just stay the course and Stephen will have to rerere
> the merge conflict resolution for a while -- something I'm certain
> that he has automated long long ago.
Yeah, that's fine.
--
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: Stephen Rothwell @ 2011-08-25 23:06 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: <4E5693DD.2010307@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
Hi,
On Thu, 25 Aug 2011 11:26:37 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On 08/25/2011 11:13 AM, Jeremy Fitzhardinge wrote:
> > On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
> >>
> >> Today's linux-next merge of the xen tree got a conflict in
> >> arch/x86/include/asm/spinlock.h between a series of commits from the tip
> >> tree and a smaller series of similar commits from the xen tree.
> >>
> >> I see that Linus is commenting on these patches at the moment, and its
> >> not easy to resolve the conflicts, so I will just use the xen tree from
> >> next-20110824 for today.
> >>
> >
> > Thanks Stephen; the xen tree ones are more current, and I want to make
> > sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.
> >
>
> 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).
--
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 moduleh tree with the arm tree
From: Paul Gortmaker @ 2011-08-25 22:40 UTC (permalink / raw)
To: Russell King; +Cc: Stephen Rothwell, linux-next, linux-kernel, Jon Medhurst
In-Reply-To: <20110825163901.GA467@flint.arm.linux.org.uk>
On 11-08-25 12:39 PM, Russell King wrote:
> On Thu, Aug 25, 2011 at 12:33:51PM -0400, Paul Gortmaker wrote:
>> On 11-08-25 01:17 AM, Stephen Rothwell wrote:
>>> Hi Paul,
>>>
>>> Today's linux-next merge of the moduleh tree got a conflict in
>>> arch/arm/mach-bcmring/mm.c between commit 2d5e975b2194 ("ARM:
>>> mach-bcmring: Setup consistent dma size at boot time") from the arm tree
>>> and commit 9bc7d81e271e ("arm: fix implicit use of page.h in
>>> mach-bcmring/mach-jornada") from the moduleh tree.
>>
>> I can't really relocate the page.h inclusion in a trivial way to
>> make this conflict go away. But since the implicit header use fixes
>> for arm are independent and don't actually depend on anything in the
>> rest of the module.h tree, I can set about to giving these to Russell
>> for his arm-next branch anytime. I'll do that shortly.
>
> For such a trivial conflict, I don't think we need to do anything. Linus
> has said publically that he likes to sort out conflicts as it allows him
> to have a wider knowledge of what's going on in the kernel tree.
>
> So, given that the fixup is soo obvious, I don't think we need to play
> games redistributing patches - we just need to be aware of the conflict
> and mention it to Linus when we merge.
OK. I was entertaining feeding some of the really obvious and simple
parts of the moduleh branch out to the various maintainers just to
reduce its overall size, but in the end I guess that just makes work
for me and them -- vs. a single pull request to Linus for addition to
v3.2-rc1. I'll just stay the course and Stephen will have to rerere
the merge conflict resolution for a while -- something I'm certain
that he has automated long long ago.
Thanks,
Paul.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox