* Re: linux-next: manual merge of the omap tree with the arm tree
From: Tony Lindgren @ 2009-08-20 13:55 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: Stephen Rothwell, linux-omap@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Syed, Rafiuddin, Russell King, Kalle Valo
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02BA29B961@dbde02.ent.ti.com>
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [090820 16:13]:
> (Resending with a correction)
>
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> > Sent: Thursday, August 20, 2009 6:33 PM
> > To: Tony Lindgren; Stephen Rothwell
> > Cc: linux-omap@vger.kernel.org; linux-next@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Syed, Rafiuddin; Russell King; Kalle Valo
> > Subject: RE: linux-next: manual merge of the omap tree with the arm tree
> >
> > > > Today's linux-next merge of the omap tree got a conflict in
> > > > arch/arm/mach-omap2/board-4430sdp.c between commit
> > > > 085b54d99b8ee999e7905b8f16e201e0da8ba369 ("ARM: OMAP4: Add UART4
> > > > support") from the arm tree and commit
> > > > 4c29fa3e47342666e12e46f35f40dd90b12cd1a4 ("OMAP: remove
> > OMAP_TAG_UART")
> > > > from the omap tree.
> > > >
> > > > Just context changes (I think). I fixed it up (see below) and can
> > carry
> > > > the fix as necessary.
> > >
> > > Thanks yeh the fix looks right. I'll take a look if I can squeeze
> > > something
> > > like that into my queue so the merge conflict disappears.
> >
> > There is another issue with the same merge I noticed which not seems to be
> > correct.
> > http://git.kernel.org/?p=linux/kernel/git/sfr/linux-
> > next.git;a=commit;h=a11128de5baf523cf73176170659902fe1335527
> >
> > < Code snippet >
> >
> > 102 static struct plat_serial8250_port serial_platform_data2[] = {
> > 103 {
> > 104 .membase = OMAP2_IO_ADDRESS(OMAP_UART3_BASE),
> > 105 .mapbase = OMAP_UART3_BASE,
> > 106 .irq = 74,
> > 107 .flags = UPF_BOOT_AUTOCONF,
> > 108 .iotype = UPIO_MEM,
> > 109 .regshift = 2,
> > 110 .uartclk = OMAP24XX_BASE_BAUD * 16,
> > 111 }, {
> > 112 #ifdef CONFIG_ARCH_OMAP4
> > 113 .membase = IO_ADDRESS(OMAP_UART4_BASE),
> > 114 .mapbase = OMAP_UART4_BASE,
> > 115 .irq = 70,
> > 116 .flags = UPF_BOOT_AUTOCONF,
> > 117 .iotype = UPIO_MEM,
> > 118 .regshift = 2,
> > 119 .uartclk = OMAP24XX_BASE_BAUD * 16,
> > 120 }, {
> > 121 #endif
> > 122 .flags = 0
> > 123 }
> > 124 };
> >
> > This patch (ARM: OMAP4: Add UART4) was generated when there was single
> > structure holding all three UARTs and fourth UART was added accordingly.
> > And now it's been merged with serial.c which has UART's structures
> > separated already.
> > Below patch fixes the same but don't know what is the way to get merged in
> > such cases.
> >
> > Tony,
> > Could you please review it?
Looks OK, except the OMAP_IO_ADDRESS() has been split to OMAP1_IO_ADDRESS()
and OMAP2_IO_ADDRESS in omap for-next tree.
Regards,
Tony
>
> From c8be9f1b5d4fe1dce06b6f33be33fe57f376ea7f Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Thu, 20 Aug 2009 18:33:43 +0530
> Subject: [PATCH] OMAP4: UART4 : Reworked patch to fix merge conflicts.
>
> This patch adds UART4 support on OMAP4430 development platform.
> The serial omap patches has split the UART platform
> data into separate structure hence needs rework.
>
> Without this patch omap_serial_init() would produce kernel crash
> on OMAP4430 platform while looping for the 4 th UART platform
> data.
>
> Signed-off-by: Syed Rafiuddin <rafiuddin.syed@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/board-4430sdp.c | 2 +-
> arch/arm/mach-omap2/serial.c | 27 ++++++++++++++++++++++++++-
> 2 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index b0c7402..1b22307 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -39,7 +39,7 @@ static struct platform_device *sdp4430_devices[] __initdata = {
> };
>
> static struct omap_uart_config sdp4430_uart_config __initdata = {
> - .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2),
> + .enabled_uarts = (1 << 0) | (1 << 1) | (1 << 2) | (1 << 3),
> };
>
> static struct omap_lcd_config sdp4430_lcd_config __initdata = {
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index a7421a5..b96cac4 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -112,7 +112,21 @@ static struct plat_serial8250_port serial_platform_data2[] = {
> .flags = 0
> }
> };
> -
> +#ifdef CONFIG_ARCH_OMAP4
> +static struct plat_serial8250_port serial_platform_data3[] = {
> + {
> + .membase = IO_ADDRESS(OMAP_UART4_BASE),
> + .mapbase = OMAP_UART4_BASE,
> + .irq = 70,
> + .flags = UPF_BOOT_AUTOCONF,
> + .iotype = UPIO_MEM,
> + .regshift = 2,
> + .uartclk = OMAP24XX_BASE_BAUD * 16,
> + }, {
> + .flags = 0
> + }
> +};
> +#endif
> static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
> int offset)
> {
> @@ -550,6 +564,17 @@ static struct omap_uart_state omap_uart[OMAP_MAX_NR_PORTS] = {
> },
> },
> },
> +#ifdef CONFIG_ARCH_OMAP4
> + {
> + .pdev = {
> + .name = "serial8250",
> + .id = PLAT8250_DEV_PLATFORM2,
> + .dev = {
> + .platform_data = serial_platform_data3,
> + },
> + },
> + },
> +#endif
> };
>
> void __init omap_serial_init(void)
> --
> 1.5.4.7
>
> Regards,
> Santosh
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the tip tree
From: Jason Wessel @ 2009-08-20 19:31 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Greg KH, Stephen Rothwell, linux-next, linux-kernel, Robin Getz,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
In-Reply-To: <1250747857.8282.114.camel@twins>
Peter Zijlstra wrote:
> On Wed, 2009-08-19 at 19:48 -0700, Greg KH wrote:
>
>> On Wed, Aug 19, 2009 at 09:37:03PM -0500, Jason Wessel wrote:
>>
>>> Greg KH wrote:
>>>
>>>> On Wed, Aug 19, 2009 at 05:59:01PM +1000, Stephen Rothwell wrote:
>>>>
>>>>
>>>>> Hi Greg,
>>>>>
>>>>> Today's linux-next merge of the usb tree got a conflict in
>>>>> kernel/printk.c between commit 4d09161196c9a836eacea4b36e2f217bc34894cf
>>>>> ("printk: Enable the use of more than one CON_BOOT (early console)") from
>>>>> the tip tree and commit e289e7dc72eb6bfce70e2722d97a00f5e02893e8 ("USB:
>>>>> printk: early_printk,console: Allow more than one early console") from
>>>>> the usb tree.
>>>>>
>>>>> I assume that these are trying to do (more or less) the same thing. I
>>>>> have dropped the one from the usb tree for today. Please sort this out -
>>>>> at least remove the usb tree one until you have done so, thanks.
>>>>>
>>>>>
>>>> Jason, any thoughts? I'm going to drop your printk stuff from my tree
>>>> now, care to sort it out and resend your whole series?
>>>>
>>>>
>>>>
>>> I will investigate, re-test and send a new series to Greg KH later in
>>> the week. The preliminary result shows the problem is a result of a
>>> clash with two different patches in the tip tree. My patch set and the
>>> two patches it collides with context wise fix different things.
>>>
>>> In order to resolve this it appears that the series will need to get
>>> split into something for the tip tree and something for the USB tree, or
>>> we wait for the next pull of the tip branch into the Linus's tree.
>>>
>> Hm, I'd prefer to get this in before that :)
>>
>> Let me know what you find. If there are conflicts, we can work it out.
>>
>
> Maybe Robin can help out, since he authored one of the conflicting
> patches?
>
No need. I have adjusted the context and removed the sections which
stepped on each other.
I'll post a new usb dbgp patch series off to Greg KH shortly. Now that
nothing collides we can leave the USB dbgp / early_printk patch series
in the usb branch. The new series touches nothing in the kernel core,
and only files in the usb tree.
The only file in the x86 tree which is touched is
drivers/usb/early/ehci-dbgp.c and it is for 2 reasons.
1) Remove the limit of 1 on earlyprintk devices
2) Move the usb dbgp device out of the this tree and into the usb early
driver area
Thanks,
Jason.
^ permalink raw reply
* Re: [PATCH 00/14] kconfig: streamline distro configs for testers
From: Andrew Morton @ 2009-08-20 22:13 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, mingo, tglx, peterz, torvalds, tytso, arjan, greg,
mcgrof, zippel, linux-kbuild, sam, corbet, sourcejedi.lkml, andi,
Stephen Rothwell, linux-next
In-Reply-To: <alpine.DEB.2.00.0908201741370.16405@gandalf.stny.rr.com>
On Thu, 20 Aug 2009 17:43:38 -0400 (EDT)
Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > > The following patches are in:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> > >
> > > branch: kconfig
> >
> > Sam's been quiet lately. I suggest that you add this to linux-next
> > now so people get a chance to poke at it.
>
> I have no means of pushing into next. Would someone like to do a pull for
> me?
If suitably bribed, Stephen will add you tree directly to the linux-nxt
lineup.
^ permalink raw reply
* linux-next: noot failure for next-20090820
From: Stephen Rothwell @ 2009-08-20 23:42 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-next, LKML, linux-nfs
[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]
Hi Trond,
Booting next-20090820 on three different PowerPC machines get the
following OOPS:
calling .init_nfs_fs+0x0/0x184 @ 1
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc00000000013be00
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in:
NIP: c00000000013be00 LR: c00000000013bd00 CTR: c00000000056f098
REGS: c00000007d2db5c0 TRAP: 0300 Not tainted (2.6.31-rc6-autokern1)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 48000028 XER: 00000005
DAR: 0000000000000000, DSISR: 0000000040000000
TASK = c0000000410ca000[1] 'swapper' THREAD: c00000007d2d8000 CPU: 1
GPR00: c00000000013bd00 c00000007d2db840 c000000000b84e98 0000000000000001
GPR04: c000000000a831e8 c0000000410ca948 0000000000000002 c0000000410ca948
GPR08: 0000000000000025 0000000000000000 ef7bdef7bdef7bdf 0000000009ac4000
GPR12: 0000000088000084 c000000000bd4400 0000000000000000 0000000003000000
GPR16: c000000000720608 c00000000071ed80 0000000000000000 00000000003e7800
GPR20: 000000000382de28 c00000000082de28 000000000382e098 c00000000082e098
GPR24: 0000000000000000 c000000000b25c58 c000000000b25c40 c000000000ac9d18
GPR28: c000000000b7ba40 fffffffffffffe10 c000000000ae5e70 0000000000000000
NIP [c00000000013be00] .sget+0x14c/0x418
LR [c00000000013bd00] .sget+0x4c/0x418
Call Trace:
[c00000007d2db840] [c00000000013bd00] .sget+0x4c/0x418 (unreliable)
[c00000007d2db8f0] [c00000000013cca8] .get_sb_single+0x4c/0x114
[c00000007d2db9a0] [c00000000056f0b8] .rpc_get_sb+0x20/0x38
[c00000007d2dba20] [c00000000013c54c] .vfs_kern_mount+0x80/0xf8
[c00000007d2dbac0] [c00000000015d434] .simple_pin_fs+0x74/0x130
[c00000007d2dbb60] [c000000000570734] .rpc_get_mount+0x2c/0x54
[c00000007d2dbbe0] [c00000000023ffec] .nfs_cache_register+0x28/0xc0
[c00000007d2dbd10] [c00000000023fa78] .nfs_dns_resolver_init+0x1c/0x34
[c00000007d2dbd90] [c000000000813fac] .init_nfs_fs+0x1c/0x184
[c00000007d2dbe10] [c0000000000094bc] .do_one_initcall+0x90/0x1b0
[c00000007d2dbf00] [c0000000007f3c98] .kernel_init+0x1f4/0x270
[c00000007d2dbf90] [c0000000000268f0] .kernel_thread+0x54/0x70
Instruction dump:
48445fad 60000000 387d0070 4bf4f7a9 60000000 7fa3eb78 4bfff911 48442e89
60000000 4bffff04 e93d01f0 3ba9fe10 <e81d01f0> 2fa00000 419e0008 7c00022c
---[ end trace 561bb236c800851f ]---
Kernel panic - not syncing: Attempted to kill init!
Call Trace:
[c00000007d2db220] [c000000000010228] .show_stack+0x70/0x184 (unreliable)
[c00000007d2db2d0] [c000000000067c40] .panic+0x80/0x1b4
[c00000007d2db370] [c00000000006c3cc] .do_exit+0x84/0x6fc
[c00000007d2db430] [c000000000024950] .die+0x24c/0x27c
[c00000007d2db4d0] [c0000000000328e0] .bad_page_fault+0xb8/0xd4
[c00000007d2db550] [c0000000000051dc] handle_page_fault+0x3c/0x74
--- Exception: 300 at .sget+0x14c/0x418
LR = .sget+0x4c/0x418
[c00000007d2db8f0] [c00000000013cca8] .get_sb_single+0x4c/0x114
[c00000007d2db9a0] [c00000000056f0b8] .rpc_get_sb+0x20/0x38
[c00000007d2dba20] [c00000000013c54c] .vfs_kern_mount+0x80/0xf8
[c00000007d2dbac0] [c00000000015d434] .simple_pin_fs+0x74/0x130
[c00000007d2dbb60] [c000000000570734] .rpc_get_mount+0x2c/0x54
[c00000007d2dbbe0] [c00000000023ffec] .nfs_cache_register+0x28/0xc0
[c00000007d2dbd10] [c00000000023fa78] .nfs_dns_resolver_init+0x1c/0x34
[c00000007d2dbd90] [c000000000813fac] .init_nfs_fs+0x1c/0x184
[c00000007d2dbe10] [c0000000000094bc] .do_one_initcall+0x90/0x1b0
[c00000007d2dbf00] [c0000000007f3c98] .kernel_init+0x1f4/0x270
[c00000007d2dbf90] [c0000000000268f0] .kernel_thread+0x54/0x70
Rebooting in 180 seconds..-- 0:conmux-control -- time-stamp -- Aug/20/09 19:25:14 --
It may not be NFS changes ... there were just a few changes in the nfs
tree between next-20090819 and next-20090820.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: noot failure for next-20090820
From: Trond Myklebust @ 2009-08-21 2:30 UTC (permalink / raw)
To: Stephen Rothwell, Dr. J. Bruce Fields; +Cc: linux-next, LKML, linux-nfs
In-Reply-To: <20090821094226.286faa67.sfr@canb.auug.org.au>
On Fri, 2009-08-21 at 09:42 +1000, Stephen Rothwell wrote:
> Hi Trond,
>
> Booting next-20090820 on three different PowerPC machines get the
> following OOPS:
>
> calling .init_nfs_fs+0x0/0x184 @ 1
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc00000000013be00
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=128 NUMA pSeries
> Modules linked in:
> NIP: c00000000013be00 LR: c00000000013bd00 CTR: c00000000056f098
> REGS: c00000007d2db5c0 TRAP: 0300 Not tainted (2.6.31-rc6-autokern1)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 48000028 XER: 00000005
> DAR: 0000000000000000, DSISR: 0000000040000000
> TASK = c0000000410ca000[1] 'swapper' THREAD: c00000007d2d8000 CPU: 1
> GPR00: c00000000013bd00 c00000007d2db840 c000000000b84e98 0000000000000001
> GPR04: c000000000a831e8 c0000000410ca948 0000000000000002 c0000000410ca948
> GPR08: 0000000000000025 0000000000000000 ef7bdef7bdef7bdf 0000000009ac4000
> GPR12: 0000000088000084 c000000000bd4400 0000000000000000 0000000003000000
> GPR16: c000000000720608 c00000000071ed80 0000000000000000 00000000003e7800
> GPR20: 000000000382de28 c00000000082de28 000000000382e098 c00000000082e098
> GPR24: 0000000000000000 c000000000b25c58 c000000000b25c40 c000000000ac9d18
> GPR28: c000000000b7ba40 fffffffffffffe10 c000000000ae5e70 0000000000000000
> NIP [c00000000013be00] .sget+0x14c/0x418
> LR [c00000000013bd00] .sget+0x4c/0x418
> Call Trace:
> [c00000007d2db840] [c00000000013bd00] .sget+0x4c/0x418 (unreliable)
> [c00000007d2db8f0] [c00000000013cca8] .get_sb_single+0x4c/0x114
> [c00000007d2db9a0] [c00000000056f0b8] .rpc_get_sb+0x20/0x38
> [c00000007d2dba20] [c00000000013c54c] .vfs_kern_mount+0x80/0xf8
> [c00000007d2dbac0] [c00000000015d434] .simple_pin_fs+0x74/0x130
> [c00000007d2dbb60] [c000000000570734] .rpc_get_mount+0x2c/0x54
> [c00000007d2dbbe0] [c00000000023ffec] .nfs_cache_register+0x28/0xc0
> [c00000007d2dbd10] [c00000000023fa78] .nfs_dns_resolver_init+0x1c/0x34
> [c00000007d2dbd90] [c000000000813fac] .init_nfs_fs+0x1c/0x184
> [c00000007d2dbe10] [c0000000000094bc] .do_one_initcall+0x90/0x1b0
> [c00000007d2dbf00] [c0000000007f3c98] .kernel_init+0x1f4/0x270
> [c00000007d2dbf90] [c0000000000268f0] .kernel_thread+0x54/0x70
> Instruction dump:
> 48445fad 60000000 387d0070 4bf4f7a9 60000000 7fa3eb78 4bfff911 48442e89
> 60000000 4bffff04 e93d01f0 3ba9fe10 <e81d01f0> 2fa00000 419e0008 7c00022c
> ---[ end trace 561bb236c800851f ]---
> Kernel panic - not syncing: Attempted to kill init!
> Call Trace:
> [c00000007d2db220] [c000000000010228] .show_stack+0x70/0x184 (unreliable)
> [c00000007d2db2d0] [c000000000067c40] .panic+0x80/0x1b4
> [c00000007d2db370] [c00000000006c3cc] .do_exit+0x84/0x6fc
> [c00000007d2db430] [c000000000024950] .die+0x24c/0x27c
> [c00000007d2db4d0] [c0000000000328e0] .bad_page_fault+0xb8/0xd4
> [c00000007d2db550] [c0000000000051dc] handle_page_fault+0x3c/0x74
> --- Exception: 300 at .sget+0x14c/0x418
> LR = .sget+0x4c/0x418
> [c00000007d2db8f0] [c00000000013cca8] .get_sb_single+0x4c/0x114
> [c00000007d2db9a0] [c00000000056f0b8] .rpc_get_sb+0x20/0x38
> [c00000007d2dba20] [c00000000013c54c] .vfs_kern_mount+0x80/0xf8
> [c00000007d2dbac0] [c00000000015d434] .simple_pin_fs+0x74/0x130
> [c00000007d2dbb60] [c000000000570734] .rpc_get_mount+0x2c/0x54
> [c00000007d2dbbe0] [c00000000023ffec] .nfs_cache_register+0x28/0xc0
> [c00000007d2dbd10] [c00000000023fa78] .nfs_dns_resolver_init+0x1c/0x34
> [c00000007d2dbd90] [c000000000813fac] .init_nfs_fs+0x1c/0x184
> [c00000007d2dbe10] [c0000000000094bc] .do_one_initcall+0x90/0x1b0
> [c00000007d2dbf00] [c0000000007f3c98] .kernel_init+0x1f4/0x270
> [c00000007d2dbf90] [c0000000000268f0] .kernel_thread+0x54/0x70
> Rebooting in 180 seconds..-- 0:conmux-control -- time-stamp -- Aug/20/09 19:25:14 --
>
> It may not be NFS changes ... there were just a few changes in the nfs
> tree between next-20090819 and next-20090820.
>
Hi Stephen,
Yes, that sounds like the bug that Bruce hit earlier today. I strongly
suspect that it is due to the fact that you both compiled NFS+sunrpc
into the main kernel, and that the NFS init routine is being called
before the sunrpc init routine.
Could both you and Bruce check if the following patch fixes the problem?
Cheers
Trond
----------------------------------------------------------------
From: Trond Myklebust <Trond.Myklebust@netapp.com>
SUNRPC: Ensure that sunrpc gets initialised before nfs, lockd, etc...
We can oops if rpc_pipefs isn't properly initialised before we start to set
up objects that depend upon it.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
net/sunrpc/sunrpc_syms.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/sunrpc/sunrpc_syms.c b/net/sunrpc/sunrpc_syms.c
index adaa819..8cce921 100644
--- a/net/sunrpc/sunrpc_syms.c
+++ b/net/sunrpc/sunrpc_syms.c
@@ -69,5 +69,5 @@ cleanup_sunrpc(void)
rcu_barrier(); /* Wait for completion of call_rcu()'s */
}
MODULE_LICENSE("GPL");
-module_init(init_sunrpc);
+fs_initcall(init_sunrpc); /* Ensure we're initialised before nfs */
module_exit(cleanup_sunrpc);
^ permalink raw reply related
* Re: linux-next: noot failure for next-20090820
From: J. Bruce Fields @ 2009-08-21 2:44 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Stephen Rothwell, linux-next, LKML, linux-nfs
In-Reply-To: <1250821846.6514.23.camel@heimdal.trondhjem.org>
On Thu, Aug 20, 2009 at 10:30:46PM -0400, Trond Myklebust wrote:
> On Fri, 2009-08-21 at 09:42 +1000, Stephen Rothwell wrote:
> > Hi Trond,
> >
> > Booting next-20090820 on three different PowerPC machines get the
> > following OOPS:
> >
> > calling .init_nfs_fs+0x0/0x184 @ 1
> > Unable to handle kernel paging request for data at address 0x00000000
> > Faulting instruction address: 0xc00000000013be00
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > SMP NR_CPUS=128 NUMA pSeries
> > Modules linked in:
> > NIP: c00000000013be00 LR: c00000000013bd00 CTR: c00000000056f098
> > REGS: c00000007d2db5c0 TRAP: 0300 Not tainted (2.6.31-rc6-autokern1)
> > MSR: 8000000000009032 <EE,ME,IR,DR> CR: 48000028 XER: 00000005
> > DAR: 0000000000000000, DSISR: 0000000040000000
> > TASK = c0000000410ca000[1] 'swapper' THREAD: c00000007d2d8000 CPU: 1
> > GPR00: c00000000013bd00 c00000007d2db840 c000000000b84e98 0000000000000001
> > GPR04: c000000000a831e8 c0000000410ca948 0000000000000002 c0000000410ca948
> > GPR08: 0000000000000025 0000000000000000 ef7bdef7bdef7bdf 0000000009ac4000
> > GPR12: 0000000088000084 c000000000bd4400 0000000000000000 0000000003000000
> > GPR16: c000000000720608 c00000000071ed80 0000000000000000 00000000003e7800
> > GPR20: 000000000382de28 c00000000082de28 000000000382e098 c00000000082e098
> > GPR24: 0000000000000000 c000000000b25c58 c000000000b25c40 c000000000ac9d18
> > GPR28: c000000000b7ba40 fffffffffffffe10 c000000000ae5e70 0000000000000000
> > NIP [c00000000013be00] .sget+0x14c/0x418
> > LR [c00000000013bd00] .sget+0x4c/0x418
> > Call Trace:
> > [c00000007d2db840] [c00000000013bd00] .sget+0x4c/0x418 (unreliable)
> > [c00000007d2db8f0] [c00000000013cca8] .get_sb_single+0x4c/0x114
> > [c00000007d2db9a0] [c00000000056f0b8] .rpc_get_sb+0x20/0x38
> > [c00000007d2dba20] [c00000000013c54c] .vfs_kern_mount+0x80/0xf8
> > [c00000007d2dbac0] [c00000000015d434] .simple_pin_fs+0x74/0x130
> > [c00000007d2dbb60] [c000000000570734] .rpc_get_mount+0x2c/0x54
> > [c00000007d2dbbe0] [c00000000023ffec] .nfs_cache_register+0x28/0xc0
> > [c00000007d2dbd10] [c00000000023fa78] .nfs_dns_resolver_init+0x1c/0x34
> > [c00000007d2dbd90] [c000000000813fac] .init_nfs_fs+0x1c/0x184
> > [c00000007d2dbe10] [c0000000000094bc] .do_one_initcall+0x90/0x1b0
> > [c00000007d2dbf00] [c0000000007f3c98] .kernel_init+0x1f4/0x270
> > [c00000007d2dbf90] [c0000000000268f0] .kernel_thread+0x54/0x70
> > Instruction dump:
> > 48445fad 60000000 387d0070 4bf4f7a9 60000000 7fa3eb78 4bfff911 48442e89
> > 60000000 4bffff04 e93d01f0 3ba9fe10 <e81d01f0> 2fa00000 419e0008 7c00022c
> > ---[ end trace 561bb236c800851f ]---
> > Kernel panic - not syncing: Attempted to kill init!
> > Call Trace:
> > [c00000007d2db220] [c000000000010228] .show_stack+0x70/0x184 (unreliable)
> > [c00000007d2db2d0] [c000000000067c40] .panic+0x80/0x1b4
> > [c00000007d2db370] [c00000000006c3cc] .do_exit+0x84/0x6fc
> > [c00000007d2db430] [c000000000024950] .die+0x24c/0x27c
> > [c00000007d2db4d0] [c0000000000328e0] .bad_page_fault+0xb8/0xd4
> > [c00000007d2db550] [c0000000000051dc] handle_page_fault+0x3c/0x74
> > --- Exception: 300 at .sget+0x14c/0x418
> > LR = .sget+0x4c/0x418
> > [c00000007d2db8f0] [c00000000013cca8] .get_sb_single+0x4c/0x114
> > [c00000007d2db9a0] [c00000000056f0b8] .rpc_get_sb+0x20/0x38
> > [c00000007d2dba20] [c00000000013c54c] .vfs_kern_mount+0x80/0xf8
> > [c00000007d2dbac0] [c00000000015d434] .simple_pin_fs+0x74/0x130
> > [c00000007d2dbb60] [c000000000570734] .rpc_get_mount+0x2c/0x54
> > [c00000007d2dbbe0] [c00000000023ffec] .nfs_cache_register+0x28/0xc0
> > [c00000007d2dbd10] [c00000000023fa78] .nfs_dns_resolver_init+0x1c/0x34
> > [c00000007d2dbd90] [c000000000813fac] .init_nfs_fs+0x1c/0x184
> > [c00000007d2dbe10] [c0000000000094bc] .do_one_initcall+0x90/0x1b0
> > [c00000007d2dbf00] [c0000000007f3c98] .kernel_init+0x1f4/0x270
> > [c00000007d2dbf90] [c0000000000268f0] .kernel_thread+0x54/0x70
> > Rebooting in 180 seconds..-- 0:conmux-control -- time-stamp -- Aug/20/09 19:25:14 --
> >
> > It may not be NFS changes ... there were just a few changes in the nfs
> > tree between next-20090819 and next-20090820.
> >
> Hi Stephen,
>
> Yes, that sounds like the bug that Bruce hit earlier today. I strongly
> suspect that it is due to the fact that you both compiled NFS+sunrpc
> into the main kernel, and that the NFS init routine is being called
> before the sunrpc init routine.
>
> Could both you and Bruce check if the following patch fixes the problem?
Yep, that boots for me, thanks.
--b.
>
> Cheers
> Trond
> ----------------------------------------------------------------
> From: Trond Myklebust <Trond.Myklebust@netapp.com>
> SUNRPC: Ensure that sunrpc gets initialised before nfs, lockd, etc...
>
> We can oops if rpc_pipefs isn't properly initialised before we start to set
> up objects that depend upon it.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> ---
>
> net/sunrpc/sunrpc_syms.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> diff --git a/net/sunrpc/sunrpc_syms.c b/net/sunrpc/sunrpc_syms.c
> index adaa819..8cce921 100644
> --- a/net/sunrpc/sunrpc_syms.c
> +++ b/net/sunrpc/sunrpc_syms.c
> @@ -69,5 +69,5 @@ cleanup_sunrpc(void)
> rcu_barrier(); /* Wait for completion of call_rcu()'s */
> }
> MODULE_LICENSE("GPL");
> -module_init(init_sunrpc);
> +fs_initcall(init_sunrpc); /* Ensure we're initialised before nfs */
> module_exit(cleanup_sunrpc);
>
>
^ permalink raw reply
* Re: linux-next: noot failure for next-20090820
From: Stephen Rothwell @ 2009-08-21 3:56 UTC (permalink / raw)
To: Trond Myklebust; +Cc: J. Bruce Fields, linux-next, LKML, linux-nfs
In-Reply-To: <20090821024454.GA8786@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
Hi Trond,
On Thu, 20 Aug 2009 22:44:54 -0400 "J. Bruce Fields" <bfields@fieldses.org> wrote:
>
> > Could both you and Bruce check if the following patch fixes the problem?
>
> Yep, that boots for me, thanks.
Works for me as well. I will add it at the end of linux-next today and
hope to see it in your tree tomorrow.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the agp tree with the powerpc tree
From: Stephen Rothwell @ 2009-08-21 3:56 UTC (permalink / raw)
To: Dave Airlie
Cc: David Woodhouse, linux-kernel, Michel Dänzer, linuxppc-dev,
linux-next, Paul Mackerras
Hi Dave,
Today's linux-next merge of the agp tree got a conflict in
drivers/char/agp/uninorth-agp.c between commit uninorth_create_gatt_table
("agp/uninorth: Simplify cache flushing") from the powerpc tree and
commit 6a12235c7d2d75c7d94b9afcaaecd422ff845ce0 ("agp: kill phys_to_gart
() and gart_to_phys()") from the agp 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/char/agp/uninorth-agp.c
index bba29ab,4317a55..0000000
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@@ -424,28 -424,14 +424,28 @@@ static int uninorth_create_gatt_table(s
if (table == NULL)
return -ENOMEM;
+ pages = kmalloc((1 << page_order) * sizeof(struct page*), GFP_KERNEL);
+ if (pages == NULL)
+ goto enomem;
+
table_end = table + ((PAGE_SIZE * (1 << page_order)) - 1);
- for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
+ for (page = virt_to_page(table), i = 0; page <= virt_to_page(table_end);
+ page++, i++) {
SetPageReserved(page);
+ pages[i] = page;
+ }
bridge->gatt_table_real = (u32 *) table;
- bridge->gatt_table = (u32 *)table;
+ /* Need to clear out any dirty data still sitting in caches */
+ flush_dcache_range((unsigned long)table,
+ (unsigned long)(table_end + PAGE_SIZE));
+ bridge->gatt_table = vmap(pages, (1 << page_order), 0, PAGE_KERNEL_NCG);
+
+ if (bridge->gatt_table == NULL)
+ goto enomem;
+
- bridge->gatt_bus_addr = virt_to_gart(table);
+ bridge->gatt_bus_addr = virt_to_phys(table);
for (i = 0; i < num_entries; i++)
bridge->gatt_table[i] = 0;
^ permalink raw reply
* linux-next: Tree for August 21
From: Stephen Rothwell @ 2009-08-21 6:41 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8187 bytes --]
Hi all,
Changes since 20090820:
This tree fails to build for powerpc allyesconfig (due to a TOC overflow
problem in the final link).
The nfs tree gained a build failure yesterday for which I have applied a
patch today.
The drm tree lost all its conflicts.
The agp tree gained a conflict against the powerpc tree.
----------------------------------------------------------------------------
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) 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 140 trees (counting Linus' and 21 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 Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and 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 arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/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 kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
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 arm/devel
Merging davinci/for-next
Merging pxa/for-next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging thumb-2/thumb-2
Merging avr32/avr32-arch
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 parisc/next
Merging powerpc/next
Merging 4xx/next
CONFLICT (content): Merge conflict in arch/powerpc/include/asm/tlb.h
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_sync.h
Merging reiserfs-bkl/reiserfs/kill-bkl
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/board-dm646x-evm.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm355.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm644x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/dm646x.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm355.h
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/include/mach/dm644x.h
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
Merging mmc/next
Merging input/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
Merging backlight/for-mm
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/input/misc/Kconfig
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
CONFLICT (content): Merge conflict in drivers/char/agp/uninorth-agp.c
Merging uwb/for-upstream
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 omap/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-4430sdp.c
Merging quilt/aoe
Merging suspend/linux-next
CONFLICT (content): Merge conflict in drivers/base/platform.c
Merging bluetooth/master
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Merging kmemleak/kmemleak
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/socket.h
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
CONFLICT (content): Merge conflict in kernel/fork.c
CONFLICT (content): Merge conflict in kernel/trace/trace.h
Merging oprofile/for-next
CONFLICT (content): Merge conflict in kernel/trace/ring_buffer.c
Merging edac-amd/for-next
CONFLICT (content): Merge conflict in arch/x86/kernel/smpboot.c
CONFLICT (content): Merge conflict in include/linux/topology.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
Merging sfi/sfi-test
CONFLICT (content): Merge conflict in arch/x86/include/asm/io_apic.h
CONFLICT (content): Merge conflict in arch/x86/kernel/acpi/boot.c
CONFLICT (content): Merge conflict in arch/x86/kernel/apic/io_apic.c
CONFLICT (content): Merge conflict in drivers/acpi/internal.h
CONFLICT (content): Merge conflict in drivers/acpi/tables.c
CONFLICT (content): Merge conflict in include/linux/acpi.h
Merging asm-generic/next
Merging hwpoison/hwpoison
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/base/class.c
CONFLICT (content): Merge conflict in init/main.c
Merging quilt/tty
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging quilt/usb
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/epl/VirtualEthernetLinux.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/epl/VirtualEthernetLinux.c left in tree.
$ git rm -f drivers/staging/epl/VirtualEthernetLinux.c
Merging scsi-post-merge/master
Applying: SUNRPC: Ensure that sunrpc gets initialised before nfs, lockd, etc...
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH -next] block: blk-iopoll sysctl iff CONFIG_BLOCK
From: Kamalesh Babulal @ 2009-08-21 11:11 UTC (permalink / raw)
To: Jens Axboe; +Cc: Randy Dunlap, Stephen Rothwell, akpm, linux-next, LKML
In-Reply-To: <20090807192144.GZ12579@kernel.dk>
* Jens Axboe <jens.axboe@oracle.com> [2009-08-07 21:21:44]:
> On Fri, Aug 07 2009, Randy Dunlap wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> >
> > New block-iopoll sysctl should be surrounded by CONFIG_BLOCK to
> > prevent build error:
> >
> > kernel/built-in.o:(.data+0x2990): undefined reference to `blk_iopoll_enabled'
>
> Thanks, I'll just kill off this sysctl, it should be driver controller
> anyway. Was just easier for testing :-)
Hi Jens,
This build failure is still seen with next-20090820 kernel, removing
the sysctl helps. Attaching the patch based on your recommendation.
Please drop the patch if you already have in queue.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
kernel/sysctl.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 40f2d2c..6e67ec2 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -991,14 +991,6 @@ static struct ctl_table kern_table[] = {
.proc_handler = &proc_dointvec,
},
#endif
- {
- .ctl_name = CTL_UNNUMBERED,
- .procname = "blk_iopoll",
- .data = &blk_iopoll_enabled,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = &proc_dointvec,
- },
/*
* NOTE: do not add new entries to this table unless you have read
* Documentation/sysctl/ctl_unnumbered.txt
Kamalesh
^ permalink raw reply related
* Re: linux-next: noot failure for next-20090820
From: Trond Myklebust @ 2009-08-21 12:34 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: J. Bruce Fields, linux-next, LKML, linux-nfs
In-Reply-To: <20090821135617.8b255a5a.sfr@canb.auug.org.au>
On Fri, 2009-08-21 at 13:56 +1000, Stephen Rothwell wrote:
> Hi Trond,
>
> On Thu, 20 Aug 2009 22:44:54 -0400 "J. Bruce Fields" <bfields@fieldses.org> wrote:
> >
> > > Could both you and Bruce check if the following patch fixes the problem?
> >
> > Yep, that boots for me, thanks.
>
> Works for me as well. I will add it at the end of linux-next today and
> hope to see it in your tree tomorrow.
>
> Thanks.
Thanks to you both for testing. The fix is now in my tree.
Cheers
Trond
^ permalink raw reply
* Re: [PATCH 00/14] kconfig: streamline distro configs for testers
From: Ingo Molnar @ 2009-08-21 13:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Steven Rostedt, linux-kernel, tglx, peterz, torvalds, tytso,
arjan, greg, mcgrof, zippel, linux-kbuild, sam, corbet,
sourcejedi.lkml, andi, Stephen Rothwell, linux-next
In-Reply-To: <20090820151326.b43038ce.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 20 Aug 2009 17:43:38 -0400 (EDT)
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > >
> > > > The following patches are in:
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> > > >
> > > > branch: kconfig
> > >
> > > Sam's been quiet lately. I suggest that you add this to linux-next
> > > now so people get a chance to poke at it.
> >
> > I have no means of pushing into next. Would someone like to do a pull for
> > me?
>
> If suitably bribed, Stephen will add you tree directly to the
> linux-nxt lineup.
Yep, we always needed another kconfig maintainer (Sam's being mostly
busy with kbuild), and it's nice to see that Steve volunteered for
that job now! ;-)
Ingo
^ permalink raw reply
* Re: [PATCH 00/14] kconfig: streamline distro configs for testers
From: Steven Rostedt @ 2009-08-21 15:08 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, linux-kernel, tglx, peterz, torvalds, tytso, arjan,
greg, mcgrof, zippel, linux-kbuild, sam, corbet, sourcejedi.lkml,
andi, Stephen Rothwell, linux-next
In-Reply-To: <20090821135249.GB30346@elte.hu>
On Fri, 21 Aug 2009, Ingo Molnar wrote:
>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Thu, 20 Aug 2009 17:43:38 -0400 (EDT)
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > > >
> > > > > The following patches are in:
> > > > >
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> > > > >
> > > > > branch: kconfig
> > > >
> > > > Sam's been quiet lately. I suggest that you add this to linux-next
> > > > now so people get a chance to poke at it.
> > >
> > > I have no means of pushing into next. Would someone like to do a pull for
> > > me?
> >
> > If suitably bribed, Stephen will add you tree directly to the
> > linux-nxt lineup.
>
> Yep, we always needed another kconfig maintainer (Sam's being mostly
> busy with kbuild), and it's nice to see that Steve volunteered for
> that job now! ;-)
Sure why not?
I've created a new repo:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-kconfig.git
and the same changes are in the branch: for-next
I still need to do the testing.
-- Steve
^ permalink raw reply
* Re: [PATCH 00/14] kconfig: streamline distro configs for testers
From: Ingo Molnar @ 2009-08-21 16:32 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, linux-kernel, tglx, peterz, torvalds, tytso, arjan,
greg, mcgrof, zippel, linux-kbuild, sam, corbet, sourcejedi.lkml,
andi, Stephen Rothwell, linux-next
In-Reply-To: <alpine.DEB.2.00.0908211106560.16405@gandalf.stny.rr.com>
* Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 21 Aug 2009, Ingo Molnar wrote:
>
> >
> > * Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > On Thu, 20 Aug 2009 17:43:38 -0400 (EDT)
> > > Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > > >
> > > > > > The following patches are in:
> > > > > >
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> > > > > >
> > > > > > branch: kconfig
> > > > >
> > > > > Sam's been quiet lately. I suggest that you add this to linux-next
> > > > > now so people get a chance to poke at it.
> > > >
> > > > I have no means of pushing into next. Would someone like to do a pull for
> > > > me?
> > >
> > > If suitably bribed, Stephen will add you tree directly to the
> > > linux-nxt lineup.
> >
> > Yep, we always needed another kconfig maintainer (Sam's being mostly
> > busy with kbuild), and it's nice to see that Steve volunteered for
> > that job now! ;-)
>
> Sure why not?
>
> I've created a new repo:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-kconfig.git
>
> and the same changes are in the branch: for-next
Cool!
I'm wondering, what do you think about Vegard's 'warn about complex
selects' feature for kconfig which he submitted some time ago:
http://lkml.org/lkml/2008/5/4/13
That's a really sore kconfig spot we have. It's not a bug, but it
sure bites people again and again, and it would be nice to have some
built-in mechanism that gently nudges us away from complex selects.
(many of which are inadvertent or become complex after the fact)
Ingo
^ permalink raw reply
* Re: [PATCH 00/14] kconfig: streamline distro configs for testers
From: Steven Rostedt @ 2009-08-21 17:39 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, linux-kernel, tglx, peterz, torvalds, tytso, arjan,
greg, mcgrof, zippel, linux-kbuild, sam, corbet, sourcejedi.lkml,
andi, Stephen Rothwell, linux-next
In-Reply-To: <20090821163220.GB20898@elte.hu>
On Fri, 21 Aug 2009, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I'm wondering, what do you think about Vegard's 'warn about complex
> selects' feature for kconfig which he submitted some time ago:
>
> http://lkml.org/lkml/2008/5/4/13
>
> That's a really sore kconfig spot we have. It's not a bug, but it
> sure bites people again and again, and it would be nice to have some
> built-in mechanism that gently nudges us away from complex selects.
> (many of which are inadvertent or become complex after the fact)
I'll take a look at that too. We need to be careful about kicking out too
many warnings. Perhaps a "make configcheck" is in order that will do
various checks. This is very similar to my check for select dependency
error patch:
http://lkml.org/lkml/2009/2/21/2
I may take a look at getting both of these in (or a merge of the two).
-- Steve
^ permalink raw reply
* [PATCH -next] tracing/syscalls: fix printk formats
From: Randy Dunlap @ 2009-08-21 21:00 UTC (permalink / raw)
To: Stephen Rothwell, Steven Rostedt; +Cc: linux-next, LKML, akpm
In-Reply-To: <20090821164140.71968b47.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix printk format warnings:
kernel/trace/trace_syscalls.c:113: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
kernel/trace/trace_syscalls.c:123: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
kernel/trace/trace_syscalls.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20090821.orig/kernel/trace/trace_syscalls.c
+++ linux-next-20090821/kernel/trace/trace_syscalls.c
@@ -109,7 +109,7 @@ int ftrace_format_syscall(struct ftrace_
entry->args[i]);
if (!ret)
return 0;
- ret = trace_seq_printf(s, "\toffset:%d;\tsize:%lu;\n", offset,
+ ret = trace_seq_printf(s, "\toffset:%d;\tsize:%zu;\n", offset,
sizeof(unsigned long));
if (!ret)
return 0;
@@ -118,7 +118,7 @@ int ftrace_format_syscall(struct ftrace_
trace_seq_printf(s, "\nprint fmt: \"");
for (i = 0; i < entry->nb_args; i++) {
- ret = trace_seq_printf(s, "%s: 0x%%0%lulx%s", entry->args[i],
+ ret = trace_seq_printf(s, "%s: 0x%%0%zulx%s", entry->args[i],
sizeof(unsigned long),
i == entry->nb_args - 1 ? "\", " : ", ");
if (!ret)
---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* [PATCH -next] staging/iio: fix duplicate dev_attr_name
From: Randy Dunlap @ 2009-08-21 20:59 UTC (permalink / raw)
To: Stephen Rothwell, gregkh; +Cc: linux-next, LKML, akpm
In-Reply-To: <20090821164140.71968b47.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
device attr's should be static, otherwise duplicate identifiers are
created:
drivers/staging/iio/trigger/iio-trig-gpio.o:(.data+0x1c): multiple definition of `dev_attr_name'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/staging/iio/accel/lis3l02dq_ring.c | 2 +-
drivers/staging/iio/trigger/iio-trig-gpio.c | 2 +-
drivers/staging/iio/trigger/iio-trig-periodic-rtc.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
--- linux-next-20090821.orig/drivers/staging/iio/accel/lis3l02dq_ring.c
+++ linux-next-20090821/drivers/staging/iio/accel/lis3l02dq_ring.c
@@ -441,7 +441,7 @@ static int lis3l02dq_data_rdy_trigger_se
&t);
return ret;
}
-DEVICE_ATTR(name, S_IRUGO, iio_trigger_read_name, NULL);
+static DEVICE_ATTR(name, S_IRUGO, iio_trigger_read_name, NULL);
static struct attribute *lis3l02dq_trigger_attrs[] = {
&dev_attr_name.attr,
--- linux-next-20090821.orig/drivers/staging/iio/trigger/iio-trig-gpio.c
+++ linux-next-20090821/drivers/staging/iio/trigger/iio-trig-gpio.c
@@ -46,7 +46,7 @@ static irqreturn_t iio_gpio_trigger_poll
return IRQ_HANDLED;
}
-DEVICE_ATTR(name, S_IRUGO, iio_trigger_read_name, NULL);
+static DEVICE_ATTR(name, S_IRUGO, iio_trigger_read_name, NULL);
static struct attribute *iio_gpio_trigger_attrs[] = {
&dev_attr_name.attr,
--- linux-next-20090821.orig/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
+++ linux-next-20090821/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
@@ -81,10 +81,10 @@ static ssize_t iio_trig_periodic_read_na
return sprintf(buf, "%s\n", trig_info->name);
}
-DEVICE_ATTR(name, S_IRUGO,
+static DEVICE_ATTR(name, S_IRUGO,
iio_trig_periodic_read_name,
NULL);
-DEVICE_ATTR(frequency, S_IRUGO | S_IWUSR,
+static DEVICE_ATTR(frequency, S_IRUGO | S_IWUSR,
iio_trig_periodic_read_freq,
iio_trig_periodic_write_freq);
---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* Re: [PATCH -next] tracing/syscalls: fix printk formats
From: Ingo Molnar @ 2009-08-21 21:04 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, Steven Rostedt, linux-next, LKML, akpm
In-Reply-To: <20090821140020.c4140ca9.randy.dunlap@oracle.com>
* Randy Dunlap <randy.dunlap@oracle.com> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix printk format warnings:
>
> kernel/trace/trace_syscalls.c:113: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
> kernel/trace/trace_syscalls.c:123: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'
thanks, this (and other) bugs were already fixed by Li Zefan via:
4539f07: tracing/syscalls: Fix the output of syscalls with no arguments
Ingo
^ permalink raw reply
* Re: next tree request
From: Stephen Rothwell @ 2009-08-22 0:48 UTC (permalink / raw)
To: Steven Rostedt
In-Reply-To: <alpine.DEB.2.00.0908212030140.604@gandalf.stny.rr.com>
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]
Hi Steve,
On Fri, 21 Aug 2009 20:33:19 -0400 (EDT) Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Here's my request for getting a tree into next.
>
> Git repo:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-kconfig.git
>
> Branch: for-next
>
> Name: Kconfig
>
> Contact: rostedt@goodmis.org
That looks fine. I'll ad it Monday unless you tell me otherwise. Here
is the boilerplate:
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: powerpc tree build warning
From: Stephen Rothwell @ 2009-08-24 0:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: linux-next, linux-kernel, Christoph Hellwig
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Hi all,
Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
kernel/time/tick-sched.c: In function 'tick_nohz_stop_sched_tick':
kernel/time/tick-sched.c:261: warning: format '%02x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
Introduced by commit 6826a57d1abc8ac9f59b24f1a008554c6560a995 ("powerpc:
Switch to asm-generic/hardirq.h") which changed
irq_cpustat_t::__softirq_pending from "unsigned int" to "unsigned long"
on powerpc.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: powerpc tree build warning
From: Christoph Hellwig @ 2009-08-24 1:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Arnd Bergmann, linux-kernel, kyle, linuxppc-dev, linux-next,
Paul Mackerras, ink, rth
In-Reply-To: <20090824102256.3e8d69b6.sfr@canb.auug.org.au>
On Mon, Aug 24, 2009 at 10:22:56AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
>
> kernel/time/tick-sched.c: In function 'tick_nohz_stop_sched_tick':
> kernel/time/tick-sched.c:261: warning: format '%02x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
>
> Introduced by commit 6826a57d1abc8ac9f59b24f1a008554c6560a995 ("powerpc:
> Switch to asm-generic/hardirq.h") which changed
> irq_cpustat_t::__softirq_pending from "unsigned int" to "unsigned long"
> on powerpc.
Hah, that's an interesting one. In currently mainline the following
architectures have it as unsigned long:
alpha, parisc and blackfin/microblaze via asm-generic
and all others have it as unsigned int. For blackfin and microblaze
it obviously doesn't matter, so the question is why alpha and parisc
have it as usinged long. We defintively should standardize on one,
and unless alpha and parisc have good reasons for needing a long
value that would be unsigned int.
^ permalink raw reply
* linux-next: manual merge of the kconfig tree with the kbuild tree
From: Stephen Rothwell @ 2009-08-24 1:32 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-next, linux-kernel, Dick Streefland, Sam Ravnborg
[-- Attachment #1: Type: text/plain, Size: 741 bytes --]
Hi Steven,
Today's linux-next merge of the kconfig tree got conflicts in
scripts/extract-ikconfig between commit
692d21e03cfc740684639b019ce9ad708930eb47 ("kconfig: simplification of
scripts/extract-ikconfig") from the kbuild tree and commits
fd3132d5815bf72aeec7d5ad87161b4831f8e48c ("kconfig: add check if end
exists in extract-ikconfig") and 6be51ffc1791b72d11cef9bb0a578fe8c5d64c6a
("kconfig: have extract-ikconfig read ELF files") from the kconfig tree.
It looks like the kbuild patch obsoletes the first of the kconfig patches
and may obsolete the second. I used the kbuild version for now, but
invite advice.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the rr tree with Linus' tree
From: Stephen Rothwell @ 2009-08-24 3:07 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, linux-kernel
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
include/linux/cpumask.h between commit
f4b0373b26567cafd421d91101852ed7a34e9e94 ("Make bitmask 'and' operators
return a result code") from Linus' tree and commits
de1cb441e0bc1be491e25d3968d0448c0ea0e5eb
("cpumask:remove-unused-deprecated-functions") and
6a795cf86742749ebf01efbe53baa7023bebc7c6
("cpumask:move-obsolete-functions-to-end-of-header") from the rr tree.
I fixed it up (see below) and can carry the fix for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/cpumask.h
index 796df12,5b44e9f..0000000
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@@ -1088,4 -646,241 +646,241 @@@ void set_cpu_active(unsigned int cpu, b
void init_cpu_present(const struct cpumask *src);
void init_cpu_possible(const struct cpumask *src);
void init_cpu_online(const struct cpumask *src);
+
+ /**
+ * to_cpumask - convert an NR_CPUS bitmap to a struct cpumask *
+ * @bitmap: the bitmap
+ *
+ * There are a few places where cpumask_var_t isn't appropriate and
+ * static cpumasks must be used (eg. very early boot), yet we don't
+ * expose the definition of 'struct cpumask'.
+ *
+ * This does the conversion, and can be used as a constant initializer.
+ */
+ #define to_cpumask(bitmap) \
+ ((struct cpumask *)(1 ? (bitmap) \
+ : (void *)sizeof(__check_is_bitmap(bitmap))))
+
+ static inline int __check_is_bitmap(const unsigned long *bitmap)
+ {
+ return 1;
+ }
+
+ /*
+ * Special-case data structure for "single bit set only" constant CPU masks.
+ *
+ * We pre-generate all the 64 (or 32) possible bit positions, with enough
+ * padding to the left and the right, and return the constant pointer
+ * appropriately offset.
+ */
+ extern const unsigned long
+ cpu_bit_bitmap[BITS_PER_LONG+1][BITS_TO_LONGS(NR_CPUS)];
+
+ static inline const struct cpumask *get_cpu_mask(unsigned int cpu)
+ {
+ const unsigned long *p = cpu_bit_bitmap[1 + cpu % BITS_PER_LONG];
+ p -= cpu / BITS_PER_LONG;
+ return to_cpumask(p);
+ }
+
+ #define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
+
+ #if NR_CPUS <= BITS_PER_LONG
+ #define CPU_BITS_ALL \
+ { \
+ [BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD \
+ }
+
+ #else /* NR_CPUS > BITS_PER_LONG */
+
+ #define CPU_BITS_ALL \
+ { \
+ [0 ... BITS_TO_LONGS(NR_CPUS)-2] = ~0UL, \
+ [BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD \
+ }
+ #endif /* NR_CPUS > BITS_PER_LONG */
+
+ /*
+ *
+ * From here down, all obsolete. Use cpumask_ variants!
+ *
+ */
+ #ifndef CONFIG_DISABLE_OBSOLETE_CPUMASK_FUNCTIONS
+ /* These strip const, as traditionally they weren't const. */
+ #define cpu_possible_map (*(cpumask_t *)cpu_possible_mask)
+ #define cpu_online_map (*(cpumask_t *)cpu_online_mask)
+ #define cpu_present_map (*(cpumask_t *)cpu_present_mask)
+ #define cpu_active_map (*(cpumask_t *)cpu_active_mask)
+
+ #define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
+
+ #define CPU_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(NR_CPUS)
+
+ #if NR_CPUS <= BITS_PER_LONG
+
+ #define CPU_MASK_ALL \
+ (cpumask_t) { { \
+ [BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD \
+ } }
+
+ #else
+
+ #define CPU_MASK_ALL \
+ (cpumask_t) { { \
+ [0 ... BITS_TO_LONGS(NR_CPUS)-2] = ~0UL, \
+ [BITS_TO_LONGS(NR_CPUS)-1] = CPU_MASK_LAST_WORD \
+ } }
+
+ #endif
+
+ #define CPU_MASK_NONE \
+ (cpumask_t) { { \
+ [0 ... BITS_TO_LONGS(NR_CPUS)-1] = 0UL \
+ } }
+
+ #define CPU_MASK_CPU0 \
+ (cpumask_t) { { \
+ [0] = 1UL \
+ } }
+
+ #if NR_CPUS == 1
+ #define first_cpu(src) ({ (void)(src); 0; })
+ #define next_cpu(n, src) ({ (void)(src); 1; })
+ #define any_online_cpu(mask) 0
+ #define for_each_cpu_mask(cpu, mask) \
+ for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
+ #else /* NR_CPUS > 1 */
+ int __first_cpu(const cpumask_t *srcp);
+ int __next_cpu(int n, const cpumask_t *srcp);
+ int __any_online_cpu(const cpumask_t *mask);
+
+ #define first_cpu(src) __first_cpu(&(src))
+ #define next_cpu(n, src) __next_cpu((n), &(src))
+ #define any_online_cpu(mask) __any_online_cpu(&(mask))
+ #define for_each_cpu_mask(cpu, mask) \
+ for ((cpu) = -1; \
+ (cpu) = next_cpu((cpu), (mask)), \
+ (cpu) < NR_CPUS; )
+ #endif /* SMP */
+
+ #if NR_CPUS <= 64
+
+ #define for_each_cpu_mask_nr(cpu, mask) for_each_cpu_mask(cpu, mask)
+
+ #else /* NR_CPUS > 64 */
+
+ int __next_cpu_nr(int n, const cpumask_t *srcp);
+ #define for_each_cpu_mask_nr(cpu, mask) \
+ for ((cpu) = -1; \
+ (cpu) = __next_cpu_nr((cpu), &(mask)), \
+ (cpu) < nr_cpu_ids; )
+
+ #endif /* NR_CPUS > 64 */
+
+ #define cpus_addr(src) ((src).bits)
+
+ #define cpu_set(cpu, dst) __cpu_set((cpu), &(dst))
+ static inline void __cpu_set(int cpu, volatile cpumask_t *dstp)
+ {
+ set_bit(cpu, dstp->bits);
+ }
+
+ #define cpu_clear(cpu, dst) __cpu_clear((cpu), &(dst))
+ static inline void __cpu_clear(int cpu, volatile cpumask_t *dstp)
+ {
+ clear_bit(cpu, dstp->bits);
+ }
+
+ #define cpus_setall(dst) __cpus_setall(&(dst), NR_CPUS)
+ static inline void __cpus_setall(cpumask_t *dstp, int nbits)
+ {
+ bitmap_fill(dstp->bits, nbits);
+ }
+
+ #define cpus_clear(dst) __cpus_clear(&(dst), NR_CPUS)
+ static inline void __cpus_clear(cpumask_t *dstp, int nbits)
+ {
+ bitmap_zero(dstp->bits, nbits);
+ }
+
+ /* No static inline type checking - see Subtlety (1) above. */
+ #define cpu_isset(cpu, cpumask) test_bit((cpu), (cpumask).bits)
+
+ #define cpu_test_and_set(cpu, cpumask) __cpu_test_and_set((cpu), &(cpumask))
+ static inline int __cpu_test_and_set(int cpu, cpumask_t *addr)
+ {
+ return test_and_set_bit(cpu, addr->bits);
+ }
+
+ #define cpus_and(dst, src1, src2) __cpus_and(&(dst), &(src1), &(src2), NR_CPUS)
-static inline void __cpus_and(cpumask_t *dstp, const cpumask_t *src1p,
++static inline int __cpus_and(cpumask_t *dstp, const cpumask_t *src1p,
+ const cpumask_t *src2p, int nbits)
+ {
- bitmap_and(dstp->bits, src1p->bits, src2p->bits, nbits);
++ return bitmap_and(dstp->bits, src1p->bits, src2p->bits, nbits);
+ }
+
+ #define cpus_or(dst, src1, src2) __cpus_or(&(dst), &(src1), &(src2), NR_CPUS)
+ static inline void __cpus_or(cpumask_t *dstp, const cpumask_t *src1p,
+ const cpumask_t *src2p, int nbits)
+ {
+ bitmap_or(dstp->bits, src1p->bits, src2p->bits, nbits);
+ }
+
+ #define cpus_xor(dst, src1, src2) __cpus_xor(&(dst), &(src1), &(src2), NR_CPUS)
+ static inline void __cpus_xor(cpumask_t *dstp, const cpumask_t *src1p,
+ const cpumask_t *src2p, int nbits)
+ {
+ bitmap_xor(dstp->bits, src1p->bits, src2p->bits, nbits);
+ }
+
+ #define cpus_andnot(dst, src1, src2) \
+ __cpus_andnot(&(dst), &(src1), &(src2), NR_CPUS)
-static inline void __cpus_andnot(cpumask_t *dstp, const cpumask_t *src1p,
++static inline int __cpus_andnot(cpumask_t *dstp, const cpumask_t *src1p,
+ const cpumask_t *src2p, int nbits)
+ {
- bitmap_andnot(dstp->bits, src1p->bits, src2p->bits, nbits);
++ return bitmap_andnot(dstp->bits, src1p->bits, src2p->bits, nbits);
+ }
+
+ #define cpus_equal(src1, src2) __cpus_equal(&(src1), &(src2), NR_CPUS)
+ static inline int __cpus_equal(const cpumask_t *src1p,
+ const cpumask_t *src2p, int nbits)
+ {
+ return bitmap_equal(src1p->bits, src2p->bits, nbits);
+ }
+
+ #define cpus_intersects(src1, src2) __cpus_intersects(&(src1), &(src2), NR_CPUS)
+ static inline int __cpus_intersects(const cpumask_t *src1p,
+ const cpumask_t *src2p, int nbits)
+ {
+ return bitmap_intersects(src1p->bits, src2p->bits, nbits);
+ }
+
+ #define cpus_subset(src1, src2) __cpus_subset(&(src1), &(src2), NR_CPUS)
+ static inline int __cpus_subset(const cpumask_t *src1p,
+ const cpumask_t *src2p, int nbits)
+ {
+ return bitmap_subset(src1p->bits, src2p->bits, nbits);
+ }
+
+ #define cpus_empty(src) __cpus_empty(&(src), NR_CPUS)
+ static inline int __cpus_empty(const cpumask_t *srcp, int nbits)
+ {
+ return bitmap_empty(srcp->bits, nbits);
+ }
+
+ #define cpus_weight(cpumask) __cpus_weight(&(cpumask), NR_CPUS)
+ static inline int __cpus_weight(const cpumask_t *srcp, int nbits)
+ {
+ return bitmap_weight(srcp->bits, nbits);
+ }
+
+ #define cpus_shift_left(dst, src, n) \
+ __cpus_shift_left(&(dst), &(src), (n), NR_CPUS)
+ static inline void __cpus_shift_left(cpumask_t *dstp,
+ const cpumask_t *srcp, int n, int nbits)
+ {
+ bitmap_shift_left(dstp->bits, srcp->bits, n, nbits);
+ }
+ #endif /* !CONFIG_DISABLE_OBSOLETE_CPUMASK_FUNCTIONS */
+
#endif /* __LINUX_CPUMASK_H */
^ permalink raw reply
* linux-next: voltage tree build failure
From: Stephen Rothwell @ 2009-08-24 4:40 UTC (permalink / raw)
To: Liam Girdwood; +Cc: linux-next, linux-kernel, Anuj Aggarwal
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
Hi Liam,
Today's linux-next build (x86_64 allmodconfig) failed like this:
drivers/regulator/tps65023-regulator: struct i2c_device_id is 32 bytes. The last of 1 is:
0x74 0x70 0x73 0x36 0x35 0x30 0x32 0x33 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
FATAL: drivers/regulator/tps65023-regulator: struct i2c_device_id is not terminated with a NULL entry!
Caused by commit 9cfd343f14bf4bd95f8bfc6a1d411d2002bf94d8 ("Regulator:
Add TPS65023 regulator driver").
I have used the version of the voltage tree from next-20090821 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: tip tree build failure
From: Stephen Rothwell @ 2009-08-24 6:54 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
Hi all,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/kernel/perf_callchain.c: In function 'perf_callchain_kernel':
arch/powerpc/kernel/perf_callchain.c:73: error: implicit declaration of function 'perf_paranoid_anon_ip'
Caused by commit 512cec5d6f2a71e04464bf4fd76a50571bd0dea1 ("perf_counter:
powerpc: Support the anonimized kernel callchain bits") which I have
reverted for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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