* Re: linux-next: tip tree build warning
From: Steven Rostedt @ 2009-08-04 16:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel
In-Reply-To: <20090804161640.70817ee6.sfr@canb.auug.org.au>
On Tue, 2009-08-04 at 16:16 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next build (powerpc ppc64_defconfig) produced these warnings:
>
> kernel/trace/ring_buffer.c: In function 'rb_head_page_set':
> kernel/trace/ring_buffer.c:704: warning: initialization makes pointer from integer without a cast
> kernel/trace/ring_buffer.c:704: warning: initialization makes pointer from integer without a cast
> kernel/trace/ring_buffer.c: In function 'rb_head_page_replace':
> kernel/trace/ring_buffer.c:797: warning: initialization makes integer from pointer without a cast
>
> Introduced by commit 77ae365eca895061c8bf2b2e3ae1d9ea62869739
> ("ring-buffer: make lockless").
>
Thanks, I'll take a look at it.
-- Steve
^ permalink raw reply
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )
From: Borislav Petkov @ 2009-08-04 15:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant,
Stephen Rothwell, linux-next, LKML, Ingo Molnar
In-Reply-To: <20090804144741.GL7746@elte.hu>
On Tue, Aug 04, 2009 at 04:47:41PM +0200, Ingo Molnar wrote:
>
> * Borislav Petkov <borislav.petkov@amd.com> wrote:
>
> > On Tue, Aug 04, 2009 at 03:50:29PM +0200, Ingo Molnar wrote:
> > > > > Mind preparing a separate branch for it (.31-rc5 based) and send me
> > > > > a pull request so that we can share the commit between the EDAC tree
> > > > > and the x86 tree?
> > > >
> > > > Well, Andreas says the patches need a little polishing and he'll
> > > > be sending updated versions soon so you can pick them up. And
> > > > since the EDAC MCE stuff might still change before .32 merge
> > > > window opens, let's synchronize our pull requests instead. In the
> > > > meantime, I'll be rediffing the EDAC stuff against -tip for
> > > > linux-next.
> > >
> > > Would you rebase just due to this commit?
> >
> > No, I wanted to keep the opportunity to be able to rebase the
> > whole series until the very last minute before the merge window,
> > should anything need to be changed...
>
> Note that's the wrong workflow. We dont rebase Git trees really just
> because 'something needs to be changed' - we make sure all commits
> make sense, we fix bugs and append new changes to the end. That
> results in a far better end result than a constant rebasing
> workflow. See various mails from Linus on lkml about this topic. (i
> have no handy URL for this now - maybe someone else has)
Yep, that I know and I agree with completely, I'm simply waiting in case
there are more comments on the subject (looka here, the last one was
from you :o)). Also, considering that some aspects to the design aren't
final, I'd like to be able to rebase. However, I'll make sure I switch
to incremental workflow after the majority of the issues are agreed
upon.
> > > No need for that, feel free to carry it until Andreas sends an
> > > updated version. Then i can put it into a separate .31-rc5 based
> > > topic that you can pull into the EDAC tree.
> >
> > ... and this is basically what I had in mind: After you pull them
> > in, I'll rebase my branch against yours for linux-next. I see
> > that Stephen pulls edac before -tip in linux-next so I'll ask him
> > nicely to reorder those. This approach makes most sense anyways
> > since edac relies on a bunch of x86 facilities (topology bits,
> > rd/wrmsr_on_cpus, mcheck etc) and it is only natural that it goes
> > second in linux-next, right?
> >
> > Then the pull requests will go out in the same order during the
> > merge window and we should be fine.
>
> ok. I'll wait for Andreas's next version of the patch. Feel free to
> carry the interim version - just please dont crash the x86 bootup ;-)
/me going to kick him to work faster :).
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
^ permalink raw reply
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )
From: Ingo Molnar @ 2009-08-04 14:47 UTC (permalink / raw)
To: Borislav Petkov
Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant,
Stephen Rothwell, linux-next, LKML, Ingo Molnar
In-Reply-To: <20090804143150.GC1870@aftab>
* Borislav Petkov <borislav.petkov@amd.com> wrote:
> On Tue, Aug 04, 2009 at 03:50:29PM +0200, Ingo Molnar wrote:
> > > > Mind preparing a separate branch for it (.31-rc5 based) and send me
> > > > a pull request so that we can share the commit between the EDAC tree
> > > > and the x86 tree?
> > >
> > > Well, Andreas says the patches need a little polishing and he'll
> > > be sending updated versions soon so you can pick them up. And
> > > since the EDAC MCE stuff might still change before .32 merge
> > > window opens, let's synchronize our pull requests instead. In the
> > > meantime, I'll be rediffing the EDAC stuff against -tip for
> > > linux-next.
> >
> > Would you rebase just due to this commit?
>
> No, I wanted to keep the opportunity to be able to rebase the
> whole series until the very last minute before the merge window,
> should anything need to be changed...
Note that's the wrong workflow. We dont rebase Git trees really just
because 'something needs to be changed' - we make sure all commits
make sense, we fix bugs and append new changes to the end. That
results in a far better end result than a constant rebasing
workflow. See various mails from Linus on lkml about this topic. (i
have no handy URL for this now - maybe someone else has)
> > No need for that, feel free to carry it until Andreas sends an
> > updated version. Then i can put it into a separate .31-rc5 based
> > topic that you can pull into the EDAC tree.
>
> ... and this is basically what I had in mind: After you pull them
> in, I'll rebase my branch against yours for linux-next. I see that
> Stephen pulls edac before -tip in linux-next so I'll ask him
> nicely to reorder those. This approach makes most sense anyways
> since edac relies on a bunch of x86 facilities (topology bits,
> rd/wrmsr_on_cpus, mcheck etc) and it is only natural that it goes
> second in linux-next, right?
>
> Then the pull requests will go out in the same order during the
> merge window and we should be fine.
ok. I'll wait for Andreas's next version of the patch. Feel free to
carry the interim version - just please dont crash the x86 bootup
;-)
Ingo
^ permalink raw reply
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )
From: Borislav Petkov @ 2009-08-04 14:31 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant,
Stephen Rothwell, linux-next, LKML, Ingo Molnar
In-Reply-To: <20090804135029.GA6775@elte.hu>
On Tue, Aug 04, 2009 at 03:50:29PM +0200, Ingo Molnar wrote:
> > > Mind preparing a separate branch for it (.31-rc5 based) and send me
> > > a pull request so that we can share the commit between the EDAC tree
> > > and the x86 tree?
> >
> > Well, Andreas says the patches need a little polishing and he'll
> > be sending updated versions soon so you can pick them up. And
> > since the EDAC MCE stuff might still change before .32 merge
> > window opens, let's synchronize our pull requests instead. In the
> > meantime, I'll be rediffing the EDAC stuff against -tip for
> > linux-next.
>
> Would you rebase just due to this commit?
No, I wanted to keep the opportunity to be able to rebase the whole
series until the very last minute before the merge window, should
anything need to be changed...
> No need for that, feel free to carry it until Andreas sends an updated
> version. Then i can put it into a separate .31-rc5 based topic that
> you can pull into the EDAC tree.
... and this is basically what I had in mind: After you pull them in,
I'll rebase my branch against yours for linux-next. I see that Stephen
pulls edac before -tip in linux-next so I'll ask him nicely to reorder
those. This approach makes most sense anyways since edac relies on a
bunch of x86 facilities (topology bits, rd/wrmsr_on_cpus, mcheck etc)
and it is only natural that it goes second in linux-next, right?
Then the pull requests will go out in the same order during the merge
window and we should be fine.
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
^ permalink raw reply
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )
From: Ingo Molnar @ 2009-08-04 13:50 UTC (permalink / raw)
To: Borislav Petkov
Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant,
Stephen Rothwell, linux-next, LKML, Ingo Molnar
In-Reply-To: <20090803125059.GB14442@aftab>
* Borislav Petkov <borislav.petkov@amd.com> wrote:
> Hi Ingo,
>
> On Mon, Aug 03, 2009 at 02:07:39PM +0200, Ingo Molnar wrote:
> > The thing that was blocking this commit is really the insufficient
> > sched-domains integration of said NUMA bits. I think the NUMA bits
> > look good and if the EDAC tree makes use of it we can merge it in
> > .32.
> >
> > Mind preparing a separate branch for it (.31-rc5 based) and send me
> > a pull request so that we can share the commit between the EDAC tree
> > and the x86 tree?
>
> Well, Andreas says the patches need a little polishing and he'll
> be sending updated versions soon so you can pick them up. And
> since the EDAC MCE stuff might still change before .32 merge
> window opens, let's synchronize our pull requests instead. In the
> meantime, I'll be rediffing the EDAC stuff against -tip for
> linux-next.
Would you rebase just due to this commit? No need for that, feel
free to carry it until Andreas sends an updated version. Then i can
put it into a separate .31-rc5 based topic that you can pull into
the EDAC tree.
That way there are no rebases really and no dependencies.
Ingo
^ permalink raw reply
* linux-next: Tree for August 4
From: Stephen Rothwell @ 2009-08-04 8:01 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8032 bytes --]
Hi all,
Changes since 20090803:
This tree fails to build for powerpc allyesconfig (final link problem).
The md-current tree lost its build failure.
The cpufreq tree lost its build failure.
The tip tree lost a conflict.
The oprofile tree lost its conflict.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-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 138 trees (counting Linus' and 20 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 dwmw2/master
Merging arm/devel
CONFLICT (content): Merge conflict in MAINTAINERS
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
CONFLICT (content): Merge conflict in arch/mips/cavium-octeon/dma-octeon.c
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
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
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
CONFLICT (content): Merge conflict in arch/x86/lguest/boot.c
CONFLICT (content): Merge conflict in drivers/lguest/page_tables.c
CONFLICT (content): Merge conflict in drivers/virtio/virtio_pci.c
[master 75c0da4] Revert "cpumask:remove-set_cpus_allowed"
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
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
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
CONFLICT (content): Merge conflict in MAINTAINERS
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Applying: drbd: fix for removal of blk_queue_stack_limits
Merging kmemleak/kmemleak
Merging tip/auto-latest
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
CONFLICT (content): Merge conflict in kernel/fork.c
Merging oprofile/for-next
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/perf_counter.c
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq_ondemand.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging quilt/driver-core
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
CONFLICT (content): Merge conflict in drivers/usb/gadget/m66592-udc.c
CONFLICT (content): Merge conflict in drivers/usb/host/r8a66597-hcd.c
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
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: tip tree build warning
From: Stephen Rothwell @ 2009-08-04 6:16 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, linux-kernel, Steven Rostedt
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
Hi all,
Today's linux-next build (powerpc ppc64_defconfig) produced these warnings:
kernel/trace/ring_buffer.c: In function 'rb_head_page_set':
kernel/trace/ring_buffer.c:704: warning: initialization makes pointer from integer without a cast
kernel/trace/ring_buffer.c:704: warning: initialization makes pointer from integer without a cast
kernel/trace/ring_buffer.c: In function 'rb_head_page_replace':
kernel/trace/ring_buffer.c:797: warning: initialization makes integer from pointer without a cast
Introduced by commit 77ae365eca895061c8bf2b2e3ae1d9ea62869739
("ring-buffer: make lockless").
--
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: cpufreq tree build failure
From: Dave Jones @ 2009-08-03 23:44 UTC (permalink / raw)
To: Thomas Renninger; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <200908040122.15733.trenn@suse.de>
On Tue, Aug 04, 2009 at 01:22:14AM +0200, Thomas Renninger wrote:
> On Monday 03 August 2009 04:28:19 am Stephen Rothwell wrote:
> > Hi Dave,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > ERROR: "cpufreq_global_kobject" [drivers/cpufreq/cpufreq_ondemand.ko]
> > undefined!
> >
> > Caused by commit 35b104d88338e5eddb36c670fea4752f6c10c82f ("[CPUFREQ]
> > ondemand - Use global sysfs dir for tuning settings"). Presumably
> > cpufreq_global_kobject needs an EXPORT_SYMBOL.
>
> Yep, that's it. Below is a fix.
>
> Thanks a lot,
I'll roll this in with the previous patch, so as not to introduce
a bisect-regression, and rebase the tree. Will push something out
soon.
thanks.
Dave
^ permalink raw reply
* Re: linux-next: cpufreq tree build failure
From: Thomas Renninger @ 2009-08-03 23:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Dave Jones, linux-next, linux-kernel
In-Reply-To: <20090803122819.6b738cad.sfr@canb.auug.org.au>
On Monday 03 August 2009 04:28:19 am Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> ERROR: "cpufreq_global_kobject" [drivers/cpufreq/cpufreq_ondemand.ko]
> undefined!
>
> Caused by commit 35b104d88338e5eddb36c670fea4752f6c10c82f ("[CPUFREQ]
> ondemand - Use global sysfs dir for tuning settings"). Presumably
> cpufreq_global_kobject needs an EXPORT_SYMBOL.
Yep, that's it. Below is a fix.
Thanks a lot,
Thomas
---------
CPUFREQ: fix build if ondemand is compiled as module
struct kobject *cpufreq_global_kobject must be exported
CC: Stephen Rothwell <sfr@canb.auug.org.au>
CC: Dave Jones <davej@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 9bb2c4a..9d9251f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -778,6 +778,7 @@ define_one_global_ro(scaling_driver);
define_one_global_rw(scaling_governor);
struct kobject *cpufreq_global_kobject;
+EXPORT_SYMBOL(cpufreq_global_kobject);
#define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
#define to_attr(a) container_of(a, struct freq_attr, attr)
^ permalink raw reply related
* Re: [PATCH] next-20090730 lguest build breaks with pfn_pmd()
From: Rusty Russell @ 2009-08-03 23:21 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Kamalesh Babulal, linux-next, LKML, lguest, sfr
In-Reply-To: <20090731110356.cd0bc550.randy.dunlap@oracle.com>
On Sat, 1 Aug 2009 03:33:56 am Randy Dunlap wrote:
> On Thu, 30 Jul 2009 17:35:33 +0530 Kamalesh Babulal wrote:
> > @@ -984,14 +984,14 @@ static unsigned long setup_pagetables(struct lguest *lg,
> > for (i = j = 0; i < mapped_pages && j < PTRS_PER_PMD;
> > i += PTRS_PER_PTE, j++) {
> > pmd = pfn_pmd(((unsigned long)&linear[i] - mem_base)/PAGE_SIZE,
> > - _PAGE_PRESENT | _PAGE_RW | _PAGE_USER);
> > + __pgrot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER));
>
> s/__pgrot/__pgprot/
Damn, sorry. I threw this patch in linux-next and went skiing.
Kamalesh said:
"I have tested the patch for the build failure only."
This was clearly untrue. Don't do that again, or I'll just ignore your
emails.
Rusty.
^ permalink raw reply
* Re: linux-next: rr tree build failure
From: Rusty Russell @ 2009-08-03 23:18 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Stephen Rothwell, linux-next, linux-kernel, Len Brown
In-Reply-To: <200908031422.28171.bjorn.helgaas@hp.com>
On Tue, 4 Aug 2009 05:52:27 am Bjorn Helgaas wrote:
> On Sunday 02 August 2009 09:32:03 pm Stephen Rothwell wrote:
> > Hi Rusty,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > drivers/acpi/osl.c: In function 'bind_to_cpu0':
> > drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'
> >
> > Caused by commit 74b5820808215f65b70b05a099d6d3c969b82689 ("ACPI: bind
> > workqueues to CPU 0 to avoid SMI corruption") (from the acpi tree but now
> > in Linus' tree) interacting with commit
> > 17e249fb40c814a72f08c1356cb47ec9f87f81a8
> > ("cpumask:remove-set_cpus_allowed") from the rr tree.
> >
> > I have reverted that rr tree commit for today.
>
> Here's a patch to fix this. Since Linus' tree still contains instances
> of set_cpus_allowed(), I'm guessing this patch should be added to the rr
> tree?
>
> Bjorn
Yep, my series removes it, at least for CONFIG_CPUMASK_OFFSTACK=y.
Thanks!
Rusty.
^ permalink raw reply
* Re: linux-next: rr tree build failure
From: Bjorn Helgaas @ 2009-08-03 20:22 UTC (permalink / raw)
To: Stephen Rothwell, Rusty Russell; +Cc: linux-next, linux-kernel, Len Brown
In-Reply-To: <20090803133203.81174a8e.sfr@canb.auug.org.au>
On Sunday 02 August 2009 09:32:03 pm Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/acpi/osl.c: In function 'bind_to_cpu0':
> drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'
>
> Caused by commit 74b5820808215f65b70b05a099d6d3c969b82689 ("ACPI: bind
> workqueues to CPU 0 to avoid SMI corruption") (from the acpi tree but now
> in Linus' tree) interacting with commit
> 17e249fb40c814a72f08c1356cb47ec9f87f81a8
> ("cpumask:remove-set_cpus_allowed") from the rr tree.
>
> I have reverted that rr tree commit for today.
Here's a patch to fix this. Since Linus' tree still contains instances
of set_cpus_allowed(), I'm guessing this patch should be added to the rr
tree?
Bjorn
ACPI: remove cpumask_t usage
set_cpus_allowed() is on the way out; replace it with
set_cpus_allowed_ptr().
Reference: http://lkml.org/lkml/2008/11/6/448
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 5691f16..e196a75 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -191,7 +191,7 @@ acpi_status __init acpi_os_initialize(void)
static void bind_to_cpu0(struct work_struct *work)
{
- set_cpus_allowed(current, cpumask_of_cpu(0));
+ set_cpus_allowed_ptr(current, cpumask_of(0));
kfree(work);
}
^ permalink raw reply related
* Re: linux-next: rr tree build failure
From: Bjorn Helgaas @ 2009-08-03 17:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Rusty Russell, linux-next, linux-kernel, Len Brown
In-Reply-To: <20090803133203.81174a8e.sfr@canb.auug.org.au>
On Sunday 02 August 2009 09:32:03 pm Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/acpi/osl.c: In function 'bind_to_cpu0':
> drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'
>
> Caused by commit 74b5820808215f65b70b05a099d6d3c969b82689 ("ACPI: bind
> workqueues to CPU 0 to avoid SMI corruption") (from the acpi tree but now
> in Linus' tree) interacting with commit
> 17e249fb40c814a72f08c1356cb47ec9f87f81a8
> ("cpumask:remove-set_cpus_allowed") from the rr tree.
>
> I have reverted that rr tree commit for today.
Looks like I'm doing this the wrong way (by passing a cpumask on the
stack). I'll try to figure out the approved way of doing this and
send a followup patch.
Bjorn
^ permalink raw reply
* Re: linux-next: Tree for August 3 (xfrm4)
From: Randy Dunlap @ 2009-08-03 15:49 UTC (permalink / raw)
To: Stephen Rothwell, netdev; +Cc: linux-next, LKML
In-Reply-To: <20090803185203.a96063fd.sfr@canb.auug.org.au>
On Mon, 3 Aug 2009 18:52:03 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20090731:
when PROC_FS=n, PROC_SYSCTL=n:
(.init.text+0x41ed): undefined reference to `net_ipv4_ctl_path'
(.init.text+0x420b): undefined reference to `register_net_sysctl_table'
xfrm4_policy.c:(.exit.text+0x3c3): undefined reference to `unregister_net_sysctl_table'
---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* Re: linux-next: manual merge of the pxa tree with Linus' tree
From: Eric Miao @ 2009-08-03 13:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Eric Miao, linux-next, linux-kernel, Marek Vasut, Joe Perches,
Andrew Morton
In-Reply-To: <20090803110314.1c2c3cca.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Eric,
>
> Today's linux-next merge of the pxa tree got a conflict in MAINTAINERS
> between commit 8b58be884a9fd650abb7f7adf3f885fb9cecd79d ("MAINTAINERS:
> coalesce name and email address lines") from Linus' tree and commit
> 4ad9febe53347962225169c5bde2ec030e46ab1d ("Palm Tungsten|C initial
> support") from the pxa tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Stephen,
Thanks for the fix.
^ permalink raw reply
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )
From: Borislav Petkov @ 2009-08-03 12:50 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andreas Herrmann, H. Peter Anvin, Thomas Gleixner, Sachin Sant,
Stephen Rothwell, linux-next, LKML, Ingo Molnar
In-Reply-To: <20090803120739.GA29156@elte.hu>
Hi Ingo,
On Mon, Aug 03, 2009 at 02:07:39PM +0200, Ingo Molnar wrote:
> The thing that was blocking this commit is really the insufficient
> sched-domains integration of said NUMA bits. I think the NUMA bits
> look good and if the EDAC tree makes use of it we can merge it in
> .32.
>
> Mind preparing a separate branch for it (.31-rc5 based) and send me
> a pull request so that we can share the commit between the EDAC tree
> and the x86 tree?
Well, Andreas says the patches need a little polishing and he'll be
sending updated versions soon so you can pick them up. And since the
EDAC MCE stuff might still change before .32 merge window opens,
let's synchronize our pull requests instead. In the meantime, I'll be
rediffing the EDAC stuff against -tip for linux-next.
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
^ permalink raw reply
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )
From: Ingo Molnar @ 2009-08-03 12:07 UTC (permalink / raw)
To: Borislav Petkov, Andreas Herrmann
Cc: H. Peter Anvin, Thomas Gleixner, Sachin Sant, Stephen Rothwell,
linux-next, LKML, Ingo Molnar
In-Reply-To: <20090803101401.GA14442@aftab>
* Borislav Petkov <borislav.petkov@amd.com> wrote:
> Hi Ingo,
>
> On Mon, Aug 03, 2009 at 11:31:44AM +0200, Ingo Molnar wrote:
> > Borislav, this patch:
> >
> > From 4581c6313c16a38ffcef8bccd6ffbe9598d585b0 Mon Sep 17 00:00:00 2001
> > From: Andreas Herrmann <andreas.herrmann3@amd.com>
> > Date: Fri, 24 Jul 2009 10:21:06 +0200
> > Subject: [PATCH] x86: provide CPU topology information for multi-node processors
> >
> > arch/x86/include/asm/processor.h | 2 ++
> > arch/x86/include/asm/smp.h | 6 ++++++
> > arch/x86/include/asm/topology.h | 2 ++
> > arch/x86/kernel/cpu/common.c | 2 ++
> > arch/x86/kernel/cpu/proc.c | 1 +
> > arch/x86/kernel/smpboot.c | 20 ++++++++++++++++----
> > 6 files changed, 29 insertions(+), 4 deletions(-)
> >
> > has absolutely _ZERO_ place in the EDAC tree. It was submitted to
> > the x86 tree and was under discussion - i requested changes to it so
> > this current form has my NAK.
>
> I know that, I'm following the discussion. I needed the
> functionality in EDAC and that's why I added them _temporarily_ to
> the mix so that the whole series (esp. the MCE bits) can see some
> testing. Which obviously caught some issues :).
>
> But I'm very well aware that the patches are not final and they
> will go through x86 when done. This is what I told Stephen when
> upping them for linux-next.
Next time please tell the x86 maintainers too ;-)
The thing that was blocking this commit is really the insufficient
sched-domains integration of said NUMA bits. I think the NUMA bits
look good and if the EDAC tree makes use of it we can merge it in
.32.
Mind preparing a separate branch for it (.31-rc5 based) and send me
a pull request so that we can share the commit between the EDAC tree
and the x86 tree?
Thanks,
Ingo
^ permalink raw reply
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )
From: Borislav Petkov @ 2009-08-03 10:14 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, Thomas Gleixner, Sachin Sant, Stephen Rothwell,
linux-next, LKML, Ingo Molnar
In-Reply-To: <20090803093144.GC9074@elte.hu>
Hi Ingo,
On Mon, Aug 03, 2009 at 11:31:44AM +0200, Ingo Molnar wrote:
> Borislav, this patch:
>
> From 4581c6313c16a38ffcef8bccd6ffbe9598d585b0 Mon Sep 17 00:00:00 2001
> From: Andreas Herrmann <andreas.herrmann3@amd.com>
> Date: Fri, 24 Jul 2009 10:21:06 +0200
> Subject: [PATCH] x86: provide CPU topology information for multi-node processors
>
> arch/x86/include/asm/processor.h | 2 ++
> arch/x86/include/asm/smp.h | 6 ++++++
> arch/x86/include/asm/topology.h | 2 ++
> arch/x86/kernel/cpu/common.c | 2 ++
> arch/x86/kernel/cpu/proc.c | 1 +
> arch/x86/kernel/smpboot.c | 20 ++++++++++++++++----
> 6 files changed, 29 insertions(+), 4 deletions(-)
>
> has absolutely _ZERO_ place in the EDAC tree. It was submitted to
> the x86 tree and was under discussion - i requested changes to it so
> this current form has my NAK.
I know that, I'm following the discussion. I needed the functionality in
EDAC and that's why I added them _temporarily_ to the mix so that the
whole series (esp. the MCE bits) can see some testing. Which obviously
caught some issues :).
But I'm very well aware that the patches are not final and they will go
through x86 when done. This is what I told Stephen when upping them for
linux-next.
Sorry if I've caused any misunderstanding.
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
^ permalink raw reply
* Re: Boot failure on x86_64 (OOPS set_cpu_sibling_map() )
From: Ingo Molnar @ 2009-08-03 9:31 UTC (permalink / raw)
To: Borislav Petkov, H. Peter Anvin, Thomas Gleixner
Cc: Sachin Sant, Stephen Rothwell, linux-next, LKML, Ingo Molnar
In-Reply-To: <20090730135623.GB16659@aftab>
* Borislav Petkov <borislav.petkov@amd.com> wrote:
> Hi,
>
> On Thu, Jul 30, 2009 at 04:55:44PM +0530, Sachin Sant wrote:
> > Today's Next failed to boot on a x86_64 box with following traces
> >
> > ACPI: Core revision 20090625
> > BUG: unable to handle kernel NULL pointer dereference at (null)
> > IP: [<ffffffff81328c7b>] set_cpu_sibling_map+0x24f/0x353
>
> I can't trigger it here, please send me your .config. In the meantime,
> you could try the following:
>
> --
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 3ede593..5fd57fe 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1070,6 +1070,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
> for_each_possible_cpu(i) {
> zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i), GFP_KERNEL);
> zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL);
> + zalloc_cpumask_var(&per_cpu(cpu_node_map, i), GFP_KERNEL);
> zalloc_cpumask_var(&cpu_data(i).llc_shared_map, GFP_KERNEL);
> }
Borislav, this patch:
From 4581c6313c16a38ffcef8bccd6ffbe9598d585b0 Mon Sep 17 00:00:00 2001
From: Andreas Herrmann <andreas.herrmann3@amd.com>
Date: Fri, 24 Jul 2009 10:21:06 +0200
Subject: [PATCH] x86: provide CPU topology information for multi-node processors
arch/x86/include/asm/processor.h | 2 ++
arch/x86/include/asm/smp.h | 6 ++++++
arch/x86/include/asm/topology.h | 2 ++
arch/x86/kernel/cpu/common.c | 2 ++
arch/x86/kernel/cpu/proc.c | 1 +
arch/x86/kernel/smpboot.c | 20 ++++++++++++++++----
6 files changed, 29 insertions(+), 4 deletions(-)
has absolutely _ZERO_ place in the EDAC tree. It was submitted to
the x86 tree and was under discussion - i requested changes to it so
this current form has my NAK.
Please remove it from your tree and generally require your
contributors to submit all arch/x86 patches to the x86 maintainers.
Thanks,
Ingo
^ permalink raw reply
* linux-next: Tree for August 3
From: Stephen Rothwell @ 2009-08-03 8:52 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8529 bytes --]
Hi all,
Changes since 20090731:
New trees: tty.current, tty
This tree fails to build for powerpc allyesconfig (final link problem).
The md-current tree gained a build failure so I used the version from
next-20090731.
The pxa tree gained a conflict against Linus' tree.
The reiserfs-bkl tree lost its conflicts.
The v4l-dvb tree lost a conflict.
The net tree lost its conflicts.
The cpufreq tree gained a build failure so I used the version from
next-20090731.
The rr tree gained a build failure so I reverted a commit.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-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 138 trees (counting Linus' and 20 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 dwmw2/master
$ git reset --hard HEAD^
Merging refs/next/20090731/md-current
Merging arm/devel
CONFLICT (content): Merge conflict in MAINTAINERS
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
CONFLICT (content): Merge conflict in arch/mips/cavium-octeon/dma-octeon.c
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
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
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
$ git reset --hard HEAD^
Merging refs/next/20090731/cpufreq
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/x86/lguest/boot.c
CONFLICT (content): Merge conflict in drivers/lguest/page_tables.c
CONFLICT (content): Merge conflict in drivers/virtio/virtio_pci.c
[master b0ca2ff] Revert "cpumask:remove-set_cpus_allowed"
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
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging agp/agp-next
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
CONFLICT (content): Merge conflict in MAINTAINERS
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging drbd/drbd
Applying: drbd: fix for removal of blk_queue_stack_limits
Merging kmemleak/kmemleak
Merging tip/auto-latest
CONFLICT (content): Merge conflict in drivers/oprofile/oprofile_stats.c
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
Merging oprofile/for-next
CONFLICT (content): Merge conflict in drivers/oprofile/oprofile_stats.c
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/sh/kernel/vmlinux.lds.S
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/perf_counter.c
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq_ondemand.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging quilt/driver-core
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
CONFLICT (content): Merge conflict in drivers/usb/gadget/m66592-udc.c
CONFLICT (content): Merge conflict in drivers/usb/host/r8a66597-hcd.c
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
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [RESEND-PATCH] next-20090730 lguest build breaks with pfn_pmd()
From: Kamalesh Babulal @ 2009-08-03 8:28 UTC (permalink / raw)
To: rusty; +Cc: linux-next, LKML, lguest, sfr, Randy Dunlap
In-Reply-To: <20090731110356.cd0bc550.randy.dunlap@oracle.com>
* Randy Dunlap <randy.dunlap@oracle.com> [2009-07-31 11:03:56]:
> On Thu, 30 Jul 2009 17:35:33 +0530 Kamalesh Babulal wrote:
>
> > Hi Rusty,
> >
> > next-20090729 allmodconfig build breaks at
> >
> > drivers/lguest/page_tables.c: In function 'setup_pagetables':
> > drivers/lguest/page_tables.c:987: error: incompatible type for argument 2 of 'pfn_pmd'
> > drivers/lguest/page_tables.c:994: error: expected ';' before ')' token
> > drivers/lguest/page_tables.c:994: error: expected statement before ')' token
> > make[2]: *** [drivers/lguest/page_tables.o] Error 1
> >
> > build failure is introduced by commit e07dd6220a4bf81a2549e7e37523a2557547d9d7
> > I have tested the patch for the build failure only.
> >
> > Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> > --
> > drivers/lguest/page_tables.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/lguest/page_tables.c b/drivers/lguest/page_tables.c
> > index 8c86446..c610b82 100644
> > --- a/drivers/lguest/page_tables.c
> > +++ b/drivers/lguest/page_tables.c
> > @@ -984,14 +984,14 @@ static unsigned long setup_pagetables(struct lguest *lg,
> > for (i = j = 0; i < mapped_pages && j < PTRS_PER_PMD;
> > i += PTRS_PER_PTE, j++) {
> > pmd = pfn_pmd(((unsigned long)&linear[i] - mem_base)/PAGE_SIZE,
> > - _PAGE_PRESENT | _PAGE_RW | _PAGE_USER);
> > + __pgrot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER));
>
> s/__pgrot/__pgprot/
>
Thanks randy, resending the patch after correcting the typo
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
drivers/lguest/page_tables.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/lguest/page_tables.c b/drivers/lguest/page_tables.c
index 8c86446..cf94326 100644
--- a/drivers/lguest/page_tables.c
+++ b/drivers/lguest/page_tables.c
@@ -984,14 +984,14 @@ static unsigned long setup_pagetables(struct lguest *lg,
for (i = j = 0; i < mapped_pages && j < PTRS_PER_PMD;
i += PTRS_PER_PTE, j++) {
pmd = pfn_pmd(((unsigned long)&linear[i] - mem_base)/PAGE_SIZE,
- _PAGE_PRESENT | _PAGE_RW | _PAGE_USER);
+ __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER));
if (copy_to_user(&pmds[j], &pmd, sizeof(pmd)) != 0)
return -EFAULT;
}
/* One PGD entry, pointing to that PMD page. */
- pgd = __pgd(((unsigned long)pmds - mem_base) | _PAGE_PRESENT));
+ pgd = __pgd(((unsigned long)pmds - mem_base) | _PAGE_PRESENT);
/* Copy it in as the first PGD entry (ie. addresses 0-1G). */
if (copy_to_user(&pgdir[0], &pgd, sizeof(pgd)) != 0)
return -EFAULT;
Kamalesh
^ permalink raw reply related
* linux-next: rr tree build failure
From: Stephen Rothwell @ 2009-08-03 3:32 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, linux-kernel, Bjorn Helgaas, Len Brown
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
Hi Rusty,
Today's linux-next build (x86_64 allmodconfig) failed like this:
drivers/acpi/osl.c: In function 'bind_to_cpu0':
drivers/acpi/osl.c:194: error: implicit declaration of function 'set_cpus_allowed'
Caused by commit 74b5820808215f65b70b05a099d6d3c969b82689 ("ACPI: bind
workqueues to CPU 0 to avoid SMI corruption") (from the acpi tree but now
in Linus' tree) interacting with commit
17e249fb40c814a72f08c1356cb47ec9f87f81a8
("cpumask:remove-set_cpus_allowed") from the rr tree.
I have reverted that rr tree commit 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: cpufreq tree build failure
From: Stephen Rothwell @ 2009-08-03 2:28 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-next, linux-kernel, Thomas Renninger
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig) failed like this:
ERROR: "cpufreq_global_kobject" [drivers/cpufreq/cpufreq_ondemand.ko] undefined!
Caused by commit 35b104d88338e5eddb36c670fea4752f6c10c82f ("[CPUFREQ]
ondemand - Use global sysfs dir for tuning settings"). Presumably
cpufreq_global_kobject needs an EXPORT_SYMBOL.
I have used the cpufreq tree from next-20090731 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
* Re: linux-next: tree build failure
From: Stephen Rothwell @ 2009-08-03 1:30 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-next, linux-kernel, Andre Noll
In-Reply-To: <7f7d2d5828c15f1fe8221554f661903e.squirrel@neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
Hi Neil,
On Mon, 3 Aug 2009 11:01:24 +1000 (EST) "NeilBrown" <neilb@suse.de> wrote:
>
> On Mon, August 3, 2009 10:35 am, Stephen Rothwell wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > ERROR: ".md_integrity_add_rdev" [drivers/md/multipath.ko] undefined!
> >
> > Caused by commit 66f4f3f41f5c334f399e920b2aaad9b82514acda ("md: Push down
> > data integrity code to personalities") from the md-current and md trees.
> > Looks like md_integrity_add_rdev needs an EXPORT_SYMBOL.
>
> Yes, of course...
> Thanks!
> Fixed.
OK, so I refetched the md tree and will use it 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
* Re: FW: next-20090724: null pointer dereference from ibm_find_acpi_device
From: Lin Ming @ 2009-08-03 1:17 UTC (permalink / raw)
To: Thomas Meyer; +Cc: Moore, Robert, Brown, Len, linux-next@vger.kernel.org
In-Reply-To: <1248972952.23004.0.camel@localhost>
On Fri, 2009-07-31 at 00:55 +0800, Thomas Meyer wrote:
> Am Montag, den 27.07.2009, 17:03 +0800 schrieb Lin Ming:
> > Hi, Thomas
> >
> > Would you please try below patch?
>
> Yes. The patch below makes the NULL pointer dereference go away. Is the
> hardware_id.string accessibly thru sysfs?
It's shown thru sysfs if it's not NULL.
See acpi_device_setup_files.
static int acpi_device_setup_files(struct acpi_device *dev)
{
....
if (dev->flags.hardware_id) {
result = device_create_file(&dev->dev, &dev_attr_hid);
if (result)
goto end;
}
....
}
Lin Ming
>
> >
> > info->hardware_id.string[sizeof(info->hardware_id.length) - 1] = '\0' is
> > not needed anymore because acpi_get_object_info already handles it.
> >
> > /* Allocate a buffer for the HID */
> >
> > hid =
> > ACPI_ALLOCATE_ZEROED(sizeof(struct acpica_device_id) +
> > (acpi_size) length);
> >
> > And it would cause null pointer deference if info->hardware_id.string is
> > NULL.
> >
> > So delete it.
> >
> > diff --git a/drivers/pci/hotplug/acpiphp_ibm.c b/drivers/pci/hotplug/acpiphp_ibm.c
> > index a9d926b..e7be66d 100644
> > --- a/drivers/pci/hotplug/acpiphp_ibm.c
> > +++ b/drivers/pci/hotplug/acpiphp_ibm.c
> > @@ -406,7 +406,6 @@ static acpi_status __init ibm_find_acpi_device(acpi_handle handle,
> > __func__, status);
> > return retval;
> > }
> > - info->hardware_id.string[sizeof(info->hardware_id.length) - 1] = '\0';
> >
> > if (info->current_status && (info->valid & ACPI_VALID_HID) &&
> > (!strcmp(info->hardware_id.string, IBM_HARDWARE_ID1) ||
> >
> >
> > On Mon, 2009-07-27 at 13:09 +0800, Moore, Robert wrote:
> > > Lin Ming,
> > >
> > > Can you take a look at this?
> > >
> > > Thanks
> > > Bob
> > >
> > >
> > > -----Original Message-----
> > > From: Thomas Meyer [mailto:thomas@m3y3r.de]
> > > Sent: Sunday, July 26, 2009 3:15 AM
> > > To: Moore, Robert; Brown, Len; linux-next@vger.kernel.org
> > > Subject: next-20090724: null pointer dereference from ibm_find_acpi_device
> > >
> > > Hi.
> > >
> > > Probably caused by commit fbe8cddd2d85979d273d7937a2b8a47498694d91.
> > >
> > > See attached screenshot.
> > >
> >
>
^ 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