Linus,
Please pull the latest smp-hotplug-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
smp-hotplug-for-linus
HEAD: 14e568e78f6f80ca1e27256641ddf524c7dbdc51 stop_machine: Use smpboot
threads
Some early preparatory changes for the WIP hotplug rework b
Linus,
Please pull the latest timers-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-core-for-linus
HEAD: 36dfbbf136db0d645bacfd42ce7d9d6928ea532d timers/x86/hpet: Use
HPET_COUNTER to specify the hpet counter in vread_hpet()
Main changes:
e Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * You should have received a copy of the GNU General Public License
+ * (for example /usr/src/linux/COPYING); if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
Linus,
Please pull the latest x86-boot-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-boot-for-linus
HEAD: 5dcd14ecd41ea2b3ae3295a9b30d98769d52165f x86, boot: Sanitize
boot_params if not zeroed on creation
Deal with bootloaders which fail to initia
Linus,
Please pull the latest x86-build-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-build-for-linus
HEAD: 63a3f603413ffe82ad775f2d62a5afff87fd94a0 timeconst.pl: Eliminate Perl
warning
The first change modifies how 'make oldconfig' works on
cros
Linus,
Please pull the latest x86-cleanups-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-cleanups-for-linus
HEAD: 19348e749e9515c429f5d561d2f2c724862a4bee x86: ptrace.c only needs
export.h and not the full module.h
Misc smaller cleanups.
Thanks
Linus,
Please pull the latest x86-cpu-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cpu-for-linus
HEAD: f0322bd341fd63261527bf84afd3272bcc2e8dd3 x86, AMD: Enable WC+ memory
type on family 10 processors
The biggest change is the enabling of the WC+
Linus,
Please pull the latest x86-debug-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-debug-for-linus
HEAD: 20bf062c6575e162ede00308ca3a5714ca112009 x86/memtest: Shorten time for
tests
Two init annotations and a built-in memtest speedup.
Thanks,
Linus,
Please pull the latest x86-hyperv-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-hyperv-for-linus
HEAD: cb20e5f2c8d6ba7440a32f4d70c0755bceb36e78 x86, hyperv: HYPERV depends
on X86_LOCAL_APIC
The biggest change is support for Windows 8's imp
Linus,
Please pull the latest x86-platform-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-platform-for-linus
HEAD: 7d0291256ca99cbb6124f63228003329e7a64b21 x86: Add TS-5500 platform
support
* Support for the Technologic Systems TS-5500 platform,
* Borislav Petkov wrote:
> On Tue, Feb 19, 2013 at 04:25:03PM +0100, Ingo Molnar wrote:
> > Linus,
> >
> > Please pull the latest x86-cpu-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>
* Linus Torvalds wrote:
> On Tue, Feb 19, 2013 at 7:41 AM, Ingo Molnar wrote:
> >
> > Please pull the latest x86-platform-for-linus git tree from:
>
> Hmm.
>
> My main desktop just had a reboot failure - it just got stuck
> at the end, not powering down, and n
> * Linus Torvalds wrote:
>
> > My main desktop just had a reboot failure - it just got
> > stuck at the end, not powering down, and not rebooting like
> > it should have.
if it matters: I have test machines of various x86 vintage, most
of which test booted these trees before sending, and no
* Linus Torvalds wrote:
> On Tue, Feb 19, 2013 at 6:16 AM, Ingo Molnar wrote:
> >
> > Please pull the latest perf-urgent-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > perf
* Alex Shi wrote:
> Current scheduler behavior is just consider for larger
> performance of system. So it try to spread tasks on more cpu
> sockets and cpu cores
>
> To adding the consideration of power awareness, the patchset
> adds 2 kinds of scheduler policy: powersaving and balance.
> T
Nesterov
> * Avoid unnecessary PF_NOFREEZE check when !CONFIG_LOCKDEP.
> * Mandeep Singh Baines
> * Generalize an exit specific printk.
>
> Signed-off-by: Mandeep Singh Baines
> CC: Oleg Nesterov
> CC: Tejun Heo
> CC: Andrew Morton
> CC: Rafael J. Wysocki
> CC: In
* Alex Shi wrote:
> > Alex, could you go through my patch and see if there is
> > anything you find objectionable ? (if not about the details,
> > at least about the general approach of enabling writer lock
> > stealing on the fast path)
>
> I did a quick review on the patchset and tested th
* Michael Wang wrote:
> v3 change log:
> Fix small logical issues (Thanks to Mike Galbraith).
> Change the way of handling WAKE.
>
> This patch set is trying to simplify the select_task_rq_fair()
> with schedule balance map.
>
> After get rid of the complex code and reorganize the
* Rafael J. Wysocki wrote:
> On Wednesday, February 20, 2013 11:37:19 AM Ingo Molnar wrote:
> >
> > * Mandeep Singh Baines wrote:
> >
> > > We shouldn't try_to_freeze if locks are held. Verified that
> > > I get no lockdep warnings after
* Alex Shi wrote:
> Now there is just 2 types policy: performance and
> powersaving(with 2 degrees, powersaving and balance).
I don't think we really want to have 'degrees' to the policies
at this point - we want each policy to be extremely good at what
it aims to do:
- 'performance' shoul
* Sasha Levin wrote:
> On 02/19/2013 02:58 AM, Ingo Molnar wrote:
> >
> > * Sasha Levin wrote:
> >
> >> Use a constructor in the library instead of making the user manually
> >> call liblockdep_init().
> >>
> >> Signed-off-b
ESLICE' undeclared here
> (not in a function)
>
> So I'd be happy if it got applied directly to Linus tree before I get too big
> of
> a bisection gap.
Hm, didn't it get fixed via the commit below?
Thanks,
Ingo
----->
commit 77852fea6e2442a0e6
f950155a9e54d
> > Parent: e0a79f529d5ba2507486d498b25da40911d95cf6
> > Author: Dan Carpenter
> > AuthorDate: Tue Feb 5 14:37:51 2013 +0300
> > Committer: Ingo Molnar
> > CommitDate: Tue Feb 5 12:59:29 2013 +0100
> >
> > sched: Fix signedness bug in yield_to()
>
* Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 10:21 AM, Thomas Gleixner wrote:
> >
> > This was a draft patch. I made it a WARN_ON_ONCE() already.
>
> Ok, good.
>
> I really wish we could just get rid of BUG_ON(). It was a bad
> idea, and it makes it easy for people to do the wrong thing
* Marcelo Tosatti wrote:
> On Thu, Feb 21, 2013 at 09:56:54AM +0100, Ingo Molnar wrote:
> >
> > * Shuah Khan wrote:
> >
> > > On Tue, Feb 19, 2013 at 7:27 PM, Linux Kernel Mailing List
> > > wrote:
> > > > Gitweb:
* Mike Galbraith wrote:
> On Fri, 2013-02-22 at 09:36 +0100, Peter Zijlstra wrote:
> > On Fri, 2013-02-22 at 10:37 +0800, Michael Wang wrote:
> > > But that's really some benefit hardly to be estimate, especially when
> > > the workload is heavy, the cost of wake_affine() is very high to
> > >
* Mike Galbraith wrote:
> On Fri, 2013-02-22 at 10:54 +0100, Ingo Molnar wrote:
> > * Mike Galbraith wrote:
> >
> > > On Fri, 2013-02-22 at 09:36 +0100, Peter Zijlstra wrote:
> > > > On Fri, 2013-02-22 at 10:37 +0800, Michael Wang wrote:
> > > &g
* Mike Galbraith wrote:
> > > No, that's too high, you loose too much of the pretty
> > > face. [...]
> >
> > Then a logical proportion of it - such as half of it?
>
> Hm. Better would maybe be a quick boot time benchmark, and
> use some multiple of your cross core pipe ping-pong time?
>
changes.
Thanks,
Ingo
-->
Alex Shi (1):
rwsem: Implement writer lock-stealing for better scalability
Ben Greear (1):
lockdep: Print more info when MAX_LOCK_DEPTH is exceeded
Ingo Molnar (1):
generic: Use raw local irq variant for generic cmpxchg
M
* Andi Kleen wrote:
> From: Andi Kleen
>
> Recent Intel CPUs like Haswell and IvyBridge have a new
> alternative MSR range for perfctrs that allows writing the
> full counter width. Enable this range if the hardware reports
> it using a new capability bit.
>
> This lowers the overhead of p
* Peter Zijlstra wrote:
> On Fri, 2013-02-22 at 13:50 +0100, Frederic Weisbecker wrote:
> > atomic64_read() and atomic64_set() are supposed to take care
> > of that, without even the need for _inc() or _add() parts
> > that use LOCK.
>
> Are you sure? Generally atomic*_set() is not actually
* Peter Zijlstra wrote:
> On Fri, 2013-02-22 at 14:54 +0100, Ingo Molnar wrote:
> > * Peter Zijlstra wrote:
> >
> > > On Fri, 2013-02-22 at 13:50 +0100, Frederic Weisbecker wrote:
> >
> > > > atomic64_read() and atomic64_set() are supposed to take ca
* Peter Zijlstra wrote:
> On Fri, 2013-02-22 at 13:50 +0100, Frederic Weisbecker wrote:
> > > Argh!! at what cost? 64bit atomics are like expensive. Wouldn't
> > adding
> > > a seqlock be saner?
> >
> > Not sure. This requires a spinlock in the write side which is called
> > from
> > fast path
* Masami Hiramatsu wrote:
> > The only complication is that __kprobes is now present in 600+ places,
> > which will create merge conflicts. If you remind me during the next
> > merge window I can generate the rename on the spot and send it to
> > Linus without anyone having to carry the patch
* Stephane Eranian wrote:
> Hi,
>
> I am not seeing those patches in tip.git tree as of today.
> What is still wrong with those patches? I think they
> are good for providing the basic enablement for HSW.
There were still problems with them so they didn't make it
into v3.9 - now that the devel
* Steven Rostedt wrote:
> Ingo,
>
> While testing my new code I stumbled upon this bug. This is a real
> bug and has been in the kernel forever. Luckily, it's in a feature
> that is seldom used. But it can cause a crash if the race is hit.
>
> I based this off of my last pull request of tip/pe
* Frederic Weisbecker wrote:
> Ingo,
>
> Please pull the latest cputime accounting updates that can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> sched/core
>
> HEAD: d9a3c9823a2e6a543eb7807fb3d15d8233817ec5
>
> Some users are complaining
* Mike Travis wrote:
>
> There is an exception where the NMI_LOCAL notifier chain is used. When
> the perf tools are in use, it's possible that our NMI was captured by
> some other NMI handler and then ignored. We set a per_cpu flag for
> those CPUs that ignored the initial NMI, and then se
h/numa.c:341: error: ???MADV_NOHUGEPAGE??? undeclared (first use in this
> function)
> make: *** [bench/numa.o] Error 1
>
> Signed-off-by: Vinson Lee
> Cc: Arnaldo Carvalho de Melo
> Cc: Ingo Molnar
> Cc: Irina Tirdea
> Cc: Paul Mackerras
> Cc: Pekka Enbe
* Oleg Nesterov wrote:
> On 08/27, Oleg Nesterov wrote:
> >
> > Srikar, this is still waiting for your review ;)
>
> I was informed that Srikar is travelling and can't review this seris.
>
> So I think it doesn't make sense to delay the already acked patches,
> the more testing the better ;) Y
* Yan, Zheng wrote:
> From: "Yan, Zheng"
>
> Initializing uncore PMU on virtualized CPU may hang the kernel.
> This is because kvm does not emulate the entire hardware. Thers
> are lots of uncore related MSRs, making kvm enumerate them all
> is a non-trival task. So just disable uncore on virt
* Robert Richter wrote:
> Ingo,
>
> one patch each for perf/urgent and perf/core, please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git urgent
Pulled into tip:perf/urgent,
>
> and
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git core
Pu
* Peter Zijlstra wrote:
> On Wed, 2012-09-05 at 08:35 +0200, Ingo Molnar wrote:
> > * Yan, Zheng wrote:
> >
> > > From: "Yan, Zheng"
> > >
> > > Initializing uncore PMU on virtualized CPU may hang the kernel.
> > > This is beca
Linus,
Please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
HEAD: 15674868d6c5985466835c56dd89d39235f16302 mm/memblock: Use NULL instead
of 0 for pointers
Fixes a Sparse warning.
Thanks,
In
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
HEAD: e4390fa632d7c592e68e8106b7daea923ac995f5 Merge branch 'urgent' of
git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile into perf
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
HEAD: 9450d57eab5cad36774c297da123062744472588 sched: Fix kernel-doc
warnings in kernel/sched/fair.c
Smaller fixlets.
Thanks,
I
* Robert Richter wrote:
> Only report
>
> No CONFIG_PERF_EVENTS=y kernel support configured?
>
> if the syscall fails with ENOSYS. In other cases CONFIG_PERF_EVENTS is
> set and might confuse users. The default message is now:
>
> Not all events could be opened.
Indeed, and it would be nic
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> Best Regards,
>
> - Arnaldo
>
> The following changes since commit d5cb2aef4fda355fbafe8db4f425b73ea94d2019:
>
> Merge tag 'perf-core-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/lin
* Steven Rostedt wrote:
> Ingo,
>
> Josh made a change to the tracing code that affects both the
> work Paul McKenney and I are currently doing. At the last
> Kernel Summit back in August, Linus said when such a case
> exists, it is best to make a separate branch based off of his
> tree and
* Robert Richter wrote:
> On 13.09.12 17:07:20, Ingo Molnar wrote:
> >
> > * Robert Richter wrote:
> >
> > > Only report
> > >
> > > No CONFIG_PERF_EVENTS=y kernel support configured?
> > >
> > > if the syscall fails wit
* Irina Tirdea wrote:
> From: Irina Tirdea
>
> In printf's format, ' is used to group the output with thousands' grouping
> characters for decimal conversion. Bionic does not support ' for printf.
Please try to solve compatibility without affecting the default
output and big num is the defau
* David Ahern wrote:
> Platforms (e.g., VM's) without support for precise mode get a confusing
> error message. e.g.,
> $ perf record -e cycles:p -a -- sleep 1
>
> Error: sys_perf_event_open() syscall returned with 95 (Operation not
> supported). /bin/dmesg may provide additional informati
* Andrew Morton wrote:
> On Mon, 20 Aug 2012 16:52:29 +0300
> "Kirill A. Shutemov" wrote:
>
> > Clearing a 2MB huge page will typically blow away several levels of CPU
> > caches. To avoid this only cache clear the 4K area around the fault
> > address and use a cache avoiding clears for the r
* Cliff Wickman wrote:
> On Thu, Sep 13, 2012 at 05:53:10PM +0200, Ingo Molnar wrote:
> >
> > Ack?
> >
> > Thanks,
> >
> > Ingo
>
> Ack.
> But with the adjustment below. The 'end' argument was not declared long.
Ok, great -
* Steven Rostedt wrote:
> Ingo,
>
> As I believe the -pg removal from perf was holding up the patch
> set, although Frederic and I are working that out, I rebased my
> patch set to remove that change, for a later time.
>
> The rest holds fixes to bugs that are in your queue for 3.7.
>
> Pleas
* David Ahern wrote:
> On 9/13/12 11:43 PM, Ingo Molnar wrote:
> >>v2: softened message to 'may not be' supported per Robert's suggestion
> >
> > Well, either it's supported on this machine or it's not -
> > why does the text have to be
* Peter Zijlstra wrote:
> On Fri, 2012-09-14 at 11:00 -0700, Arnaldo Carvalho de Melo wrote:
> > > Understood and there have been suggestions on how to definitely state
> > > what the kernel side did not like. I like Peter's last suggestion --
> > > something along the lines of clearing attr on
* Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
> > On Fri, 2012-09-14 at 11:00 -0700, Arnaldo Carvalho de Melo wrote:
> > > > Understood and there have been suggestions on how to definitely state
> > > > what the kernel side did not like. I like Peter&#x
dency between arch/ia64/kernel/mca_asm.S and the
position of the percpu data.
Is my analysis correct? Do you like my fix and does the patch build and
boot on your system? Thanks,
Ingo
--->
Subject: ia64: on UP percpu variables are not small memory model
From: Ingo Molnar <
* Luck, Tony <[EMAIL PROTECTED]> wrote:
> I'll start digging on why this doesn't boot ... but you might as well
> send the fixes so far upstream to Linus so that the SMP fix is
> available (which is all anyone really cares about ... there are very,
> very few UP ia64 systems in existence).
>
_64).
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Cc: Geert Uytterhoeven <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
include/asm-powerpc/percpu.h | 22 +++---
1 file changed, 3 inserti
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Change:
> config ARCH_SETS_UP_PER_CPU_AREA
> to:
> config HAVE_SETUP_PER_CPU_AREA
undocumented change:
> config ARCH_NO_VIRT_TO_BUS
> --- a/init/main.c
> +++ b/init/main.c
> @@ -380,6 +380,8 @@ static void __init setup_per_cpu_areas(
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Sparc64 has a way of providing the base address for the per cpu area
> of the currently executing processor in a global register.
>
> Sparc64 also provides a way to calculate the address of a per cpu area
> from a base address instead of perform
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Change s390 percpu.h to use asm-generic/percpu.h
do the s390 maintainer agree with this change (Acks please), and has it
been tested on s390?
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
* Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-01-30 at 22:53 +0100, Ingo Molnar wrote:
> > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > > Change s390 percpu.h to use asm-generic/percpu.h
> >
> > do the s390 maintainer
* Luck, Tony <[EMAIL PROTECTED]> wrote:
> > I'll start digging on why this doesn't boot ... but you might as well
> > send the fixes so far upstream to Linus so that the SMP fix is available
>
> Well a pure 2.6.24 version compiled with CONFIG_SMP=n booted just
> fine, so the breakage is recent
* Rusty Russell <[EMAIL PROTECTED]> wrote:
> --- a/drivers/lguest/x86/core.c Thu Jan 31 14:50:43 2008 +1100
> +++ b/drivers/lguest/x86/core.c Thu Jan 31 17:58:44 2008 +1100
> @@ -94,7 +94,7 @@ static void copy_in_guest_info(struct lg
> /* Set up the two "TSS" members which tell
> * Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > --- a/drivers/lguest/x86/core.c Thu Jan 31 14:50:43 2008 +1100
> > +++ b/drivers/lguest/x86/core.c Thu Jan 31 17:58:44 2008 +1100
> > @@ -94,7 +94,7 @@ static void copy_in_guest_info(struct lg
> > /* Set up the two "TSS" members which
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> why not rename relocs.c to relocs_32.c?
>
> it is only used for 32 bit, even it is host app.
during the big first phase of unification we generally kept file names
untouched if they were only present in one of the previous
architectures. I.e. pure 32-
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
> > during the big first phase of unification we generally kept file
> > names untouched if they were only present in one of the previous
> > architectures. I.e. pure 32-bit and pure 64-bit files were not
> > renamed to _32/_64.
> >
> > Now that we
* Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-01-31 at 02:33 +0200, Adrian Bunk wrote:
> > <-- snip -->
> >
> > ...
> > CC arch/s390/kernel/asm-offsets.s
> > In file included from
> > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/s390/kernel/asm-offsets.c:7:
> > /home
* Lukas Hejtmanek <[EMAIL PROTECTED]> wrote:
> I noticed short thread in LKM regarding "sched: add vslice" causes
> horrible interactivity under load.
>
> I can see similar behavior. If I stress both CPU cores, even typing on
> keyboard suffers from huge latencies, I can see letters appearing
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
> arch/x86/kernel/cpu/intel_cacheinfo.c:355:7: warning: symbol 'i' shadows an
> earlier one
> arch/x86/kernel/cpu/intel_cacheinfo.c:296:39: originally declared here
> arch/x86/kernel/cpu/intel_cacheinfo.c:367:18: warning: incorrect type in
> argument
* Huang, Ying <[EMAIL PROTECTED]> wrote:
> - if (!*pte & _PAGE_PRESENT) {
> + if (*pte & _PAGE_PRESENT) {
btw., the usual form for that is pte_present(*pte). (i've fixed this up
in the patch)
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linu
* Huang, Ying <[EMAIL PROTECTED]> wrote:
> + /* Assume pages are mapped as WB */
> + if (mode == IOR_MODE_UNCACHED)
> + set_memory_uc(md->virt_addr, md->num_pages);
> + /* Assume pages are mapped as unexecutab
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> As for the Makefiles - I looked at them last time and only issue that
> kept me away for unifying them was that I did not understand the
> linking order requirments and I did not see enough benefit at that
> time to invest the time to unify them. Eac
* Huang, Ying <[EMAIL PROTECTED]> wrote:
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -274,8 +274,10 @@ void __init cpu_detect(struct cpuinfo_x8
> if (c->x86 >= 0x6)
> c->x86_model += ((tfms >> 16) & 0xF) << 4;
> c->x86_mask = tfms & 15;
> -
* Huang, Ying <[EMAIL PROTECTED]> wrote:
> This patch replaces __change_page_attr_set_clr() with
> change_page_attr_set_clr() in change_page_attr_clear() to flush the
> TLB/cache properly.
thanks, applied. Thomas just found this bug today too :-)
Ingo
--
To unsubscribe from this list:
* Huang, Ying <[EMAIL PROTECTED]> wrote:
> This patch fixes a bug of early_ioremap_reset(), which had been fixed
> before by "convert the boot time page table to the kernels native
> format" patch. But that patch has been reverted now.
thanks, applied. (The native-pagetables patch is in x86.gi
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> ENTRY(startup_64)
> SECTIONS
> {
> - /* Be careful parts of head_64.S assume startup_64 is at
> + /* Be careful parts of head_64.S assume startup_32 is at
>* address 0.
>*/
> . = 0;
but this linker script rule is about st
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH] x86_64: make bootmap_start page align v3
>
> boot oops when system get 64g or 128 installed
> +++ linux-2.6/arch/x86/mm/numa_64.c
> @@ -224,6 +224,14 @@ void __init setup_node_bootmem(int nodei
> }
> bootmap_start = __pa(bootmap);
>
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH 1/4] print out node_data addr and bootmap_start addr
thanks, applied.
> nodedata_phys = __pa(node_data[nodeid]);
> + printk(KERN_INFO " NODE_DATA [%016lx - %016lx]\n", nodedata_phys,
> + nodedata_phys + pgdat_size - 1);
>
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> ok, discard 3, and 4.
>
> how about 2 v2?
i'm leaning towards v4, but the more fundamental breakage is in the
early_node_mem() ad-hoc allocator that got butchered into this code a
year ago:
commit a8062231d80239cf3405982858c02aea21a6066a
Author:
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 29 Jan 2008 19:40:19 +0300
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > With CONFIG_PREEMPT_RCU read_lock(tasklist_lock) doesn't imply
> > rcu_read_lock(),
>
> I'm suspecting that we have other code which assumes that read_lock,
> write
* Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> Are you going to pick this patch up via the x86 tree, or shall I
> forward it to Andrew or [EMAIL PROTECTED]
>
> Do you want me to re-send with Venki's ack?
no need, we merged your improvement via x86.git and it is now in Linus's
latest tr
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
> arch/x86/kernel/scx200_32.c:68:72: warning: Using plain integer as
> NULL pointer
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
* Patrick McHardy <[EMAIL PROTECTED]> wrote:
>> config attached.
>
> Thanks, the reason is CONFIG_SYSCTL=n. I've queued this patch (might
> not apply to Linus' tree due to local changes) to fix the build error
> and a runtime error with CONFIG_PROC_FS=n.
it applied fine here and it resolved th
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
> arch/x86/kernel/ds.c:226:9: warning: Using plain integer as NULL
> pointer
> kfree(*dsp);
> - *dsp = 0;
> + *dsp = NULL;
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
> Other than the defconfigs, remove the entry in compiler-gcc4.h,
> Kconfig.debug and feature-removal-schedule.txt.
i've queued up the generic and x86 bits (the arch changes are really
just to avoid spurious kconfig warnings so it doesnt hurt much),
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
* Pekka Paalanen <[EMAIL PROTECTED]> wrote:
> > static inline int notify_page_fault(struct pt_regs *regs)
> > {
> > #ifdef CONFIG_KPROBES
> > @@ -588,6 +636,9 @@ void __kprobes do_page_fault(struct pt_regs *regs,
> > unsigned long error_code)
> > if (notify_page_fault(regs))
> >
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> arch/x86/kernel/tsc_32.c | 14 +-
> arch/x86/kernel/tsc_64.c | 14 +-
> 2 files changed, 10 insertions(+), 18 deletions(-)
> static void set_cyc2ns_scale(unsigned long cpu_khz, int cpu)
> {
> - unsigned long fl
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Note that all known breakages are fixed in current -git, except for
> the s390 problem that Martin/Nick posted the fix.
find below the s390 fix.
Ingo
Index: linux/arch/
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> You tested x86 but broke more than half a dozen other archtectures,
> with at least 3 different commits breaking other architectures.
Note that all known breakages are fixed in current -git, except for the
s390 problem that Martin/Nick posted the fix.
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 31, 2008 at 05:00:33PM +0100, Ingo Molnar wrote:
> >
> > * Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > You tested x86 but broke more than half a dozen other archtectures,
> > &g
asm-generic/tlb.h revert/fix).
Ingo
->
Subject: x86: uninline __pte_free_tlb() and __pmd_free_tlb()
From: Ingo Molnar <[EMAIL PROTECTED]>
this also removes an include file dependency.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86
FYI, automated testing found the following build breakage:
drivers/scsi/NCR53C9x.c: In function 'esp_get_dmabufs':
drivers/scsi/NCR53C9x.c:913: error: 'Scsi_Cmnd' has no member named 'use_sg'
drivers/scsi/NCR53C9x.c:914: error: 'Scsi_Cmnd' has no member named
'request_bufflen'
config attached.
p_a clflush_cache_range fix
x86: early_ioremap_reset fix 2
Ingo Molnar (2):
x86: uninline __pte_free_tlb() and __pmd_free_tlb()
asm-generic/tlb.h: build fix
arch/x86/kernel/cpu/common.c |5 -
arch/x86/kernel/cpu/intel_cacheinfo.c |6 +++---
arch/x86/kernel/d
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Linus,
>
> please pull:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>
> most importantly this fixes/reverts the include/asm-generic/tlb.h
> change from yesterday that broke the avr32, b
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> But I guess I overlooked the comment...
>
> I guess the fix is to scatter linux/pagemap.h into the appropriate
> places where these macros are used (asm-generic/tlb.h, for a start).
no. The fix is always to undo the damage ASAP, to keep the win
201 - 300 of 16826 matches
Mail list logo
