On Tue, 2013-04-30 at 17:53 +, Christoph Lameter wrote:
> On Tue, 30 Apr 2013, Tim Chen wrote:
>
> > > And why is it a pointer?
> >
> > A pointer because the default percpu_counter_batch value could change
> > later when cpus come online after we initialize per cpu counter and
> > percpu_count
On 04/30, Frederic Weisbecker wrote:
>
> On Mon, Apr 29, 2013 at 06:40:38PM +0200, Oleg Nesterov wrote:
>
> > No, I think this (minor) problem is very old... At least, when I look
> > at 2.6.26 code I do not see anything which coould clear db regs on
> > detach.
>
> Ok, if so then the conversion to
>
> > Maybe the condition around the posix_cpu_timer_schedule() block inside
> > cpu_timer_fire() could even be a good candidate for 'unlikely'
> > qualifier.
>
> Well, cpu_timer_fire() is probably not a fast path. So helping branch
> prediction there probably won't have much measurable effect i
On Tue, 2013-04-30 at 17:28 +, Christoph Lameter wrote:
> On Tue, 30 Apr 2013, Tim Chen wrote:
>
> > On Tue, 2013-04-30 at 13:32 +, Christoph Lameter wrote:
> > > On Mon, 29 Apr 2013, Tim Chen wrote:
> > >
> > > > diff --git a/include/linux/percpu_counter.h
> > > > b/include/linux/percpu_
On 04/30/13 09:36, David Rientjes wrote:
> On Mon, 29 Apr 2013, Randy Dunlap wrote:
>
>> From: Randy Dunlap
>>
>> Fix build error when CONFIG_PROC_FS is not enabled:
>> (remove duplicated line)
>>
>> include/linux/proc_fs.h:58:20: error: redefinition of 'proc_set_size'
>> include/linux/proc_fs.h:
On Mon, Apr 29, 2013 at 05:22:52PM -0700, David Rientjes wrote:
> This exports the amount of anonymous transparent hugepages for each memcg
> via the new "rss_huge" stat in memory.stat. The units are in bytes.
>
> This is helpful to determine the hugepage utilization for individual jobs
> on the
> > What is this for and why does it have that alignmend?
>
> I was assuming that if batch is frequently referenced, it probably
> should not share a cache line with the counters field.
As long as they are both read-mostly it should be fine to share
(cache line will just be SHARED)
Padding would
Konrad, are you going to take care of this patch (assuming that you are
OK with it)?
On Tue, 30 Apr 2013, Julien Grall wrote:
> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> irq_startup, that is responsible f
On Tue, 30 Apr 2013, Tim Chen wrote:
> On Tue, 2013-04-30 at 13:32 +, Christoph Lameter wrote:
> > On Mon, 29 Apr 2013, Tim Chen wrote:
> >
> > > diff --git a/include/linux/percpu_counter.h
> > > b/include/linux/percpu_counter.h
> > > index d5dd465..5ca7df5 100644
> > > --- a/include/linux/pe
On Tue, Apr 30, 2013 at 1:21 AM, Bin Gao wrote:
> x86/pci/mrst: force all pci config access toward 0:0:0, 0:2:0 and 0:3:0 to
> type 1
>
> For real pci devices 0:0:0, 0:2:0 and 0:3:0, there is either no pci shim, or
> no guarantee of data correctness of offset 256-4k. So for whatever reason,
> Lin
On Tue, 2013-04-30 at 16:52 +0900, Jonghwan Choi wrote:
> This patch looks like it should be in the 3.8-stable tree, should we apply
> it?
>
I don't see this as a candidate for stable. Its just an optimization and
doesn't address any existing issue.
Thanks,
Davidlohr
--
To unsubscribe from this
Ladies and Gentlemen,
I'm glad to announce the 5th release of the checkpoint-restore tool!
This release is mostly about the tool itself. The v3.9 kernel, with which the
new CRIU tool should be used, only contains a couple of bug fixes related to
the C/R project and no new related features. As for
Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
irq_startup, that is responsible for calling irq_unmask at startup time.
As a result event channels remain masked.
The clear is already made in bind_evtchn_to_irq wit
On Wed, 1 May 2013, Tetsuo Handa wrote:
> Christoph Lameter wrote:
> > On Tue, 30 Apr 2013, Tetsuo Handa wrote:
> >
> > > The testcases still trigger BUG() at 32M:
> >
> > I thought we established that MAX_ORDER only allows a maximum of 8M sized
> > allocations? Why are you trying 32M?
>
> Only f
Hi -
> [...] How about creating trace_tick() in
> include/trace/events/timer.h and call it from tick_periodic() and
> tick_sched_handle(). [...]
Like this?
>From facee64445c0dcc717e99c474c5c7dcdd31b9a74 Mon Sep 17 00:00:00 2001
From: "Frank Ch. Eigler"
Date: Wed, 3 Apr 2013 10:35:21 -0400
Sub
On Wed, Apr 24, 2013 at 08:50:01PM -0700, Hugh Dickins wrote:
> On Wed, 24 Apr 2013, Johannes Weiner wrote:
> > On Wed, Apr 24, 2013 at 03:18:51PM +0200, Michal Hocko wrote:
> > > On Wed 24-04-13 12:42:55, Heiko Carstens wrote:
> > > > On Thu, Apr 18, 2013 at 09:13:03AM +0200, Heiko Carstens wrote:
To fix /dev/kmsg, let's compare the existing interfaces and what they allow:
- /proc/kmsg allows:
- open (SYSLOG_ACTION_OPEN) if CAP_SYSLOG since it uses a destructive
single-reader interface (SYSLOG_ACTION_READ).
- everything, after an open.
- syslog syscall allows:
- anything, if CAP_SYSL
This patch adds the device tree node for si5351 clock generator
and the corresponding oscillator connected to it. It also limits
i2c frequency to 100kHz as there are bus locks reported on higher
frequencies.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Russell King
Cc: Jason Cooper
Cc: linux-ar
On 04/30, Oleg Nesterov wrote:
>
> On 04/29, Colin Cross wrote:
> >
> > @@ -46,10 +46,10 @@ static int try_to_freeze_tasks(bool user_only)
> > todo = 0;
> > read_lock(&tasklist_lock);
> > do_each_thread(g, p) {
> > - if (p == current || !freeze_
On 04/29, Colin Cross wrote:
>
> @@ -46,10 +46,10 @@ static int try_to_freeze_tasks(bool user_only)
> todo = 0;
> read_lock(&tasklist_lock);
> do_each_thread(g, p) {
> - if (p == current || !freeze_task(p))
> + if (p
Hi Joerg,
Would you take this patchset for 3.10 merge?
Regards
Varun
> -Original Message-
> From: Sethi Varun-B16395
> Sent: Wednesday, April 24, 2013 5:06 PM
> To: j...@8bytes.org; io...@lists.linux-foundation.org; linuxppc-
> d...@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> ga...@
* Clark Williams | 2013-04-29 16:19:25 [-0500]:
>On Mon, 29 Apr 2013 22:12:02 +0200
>Sebastian Andrzej Siewior wrote:
>> - suspend / resume seems to program program the timer wrong and wait
>> ages until it continues.
>
>It has to be something we're doing when we apply RT to v3.8.x, sin
On Tue, 2013-04-30 at 12:02 +0900, Damian Hobson-Garcia wrote:
> Most architectures that define CONFIG_HAVE_DMA, have implementations for
> both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do
> not define CONFIG_HAVE_DMA also have both of these definitions provided by
> dma-mappi
On Tue, 30 Apr 2013 09:54:18 -0700 (PDT) David Rientjes
wrote:
> On Tue, 30 Apr 2013, Andrew Morton wrote:
>
> > > > diff --git a/include/linux/memory.h b/include/linux/memory.h
> > > > index 73817af..85c31a8 100644
> > > > --- a/include/linux/memory.h
> > > > +++ b/include/linux/memory.h
> > >
On 04/30, Colin Cross wrote:
> On Tue, Apr 30, 2013 at 9:38 AM, Oleg Nesterov wrote:
> > On 04/29, Colin Cross wrote:
> >>
> >> Avoid waking up every thread sleeping in a sigtimedwait call during
> >> suspend and resume by calling a freezable blocking call.
> >
> > This doesn't explain why do want
On 04/30/2013 06:57 PM, Robert Richter wrote:
From: Robert Richter
mkinitrd looks at /sys/class/scsi_host/host$hostnum/proc_name to find
the module name of a disk driver. Current name is "highbank-ahci" but
the module is "sata_highbank". Rename it to match the module name.
Cc: Rob Herring
Cc: A
On 04/30, Oleg Nesterov wrote:
>
> On 04/29, Colin Cross wrote:
> >
> > Avoid waking up every thread sleeping in a sigtimedwait call during
> > suspend and resume by calling a freezable blocking call.
>
> This doesn't explain why do want this change...
>
> OK, probably to avoid -EAGAIN from sigtime
On Tue, Apr 30, 2013 at 9:38 AM, Oleg Nesterov wrote:
> On 04/29, Colin Cross wrote:
>>
>> Avoid waking up every thread sleeping in a sigtimedwait call during
>> suspend and resume by calling a freezable blocking call.
>
> This doesn't explain why do want this change...
>
> OK, probably to avoid -
From: Robert Richter
mkinitrd looks at /sys/class/scsi_host/host$hostnum/proc_name to find
the module name of a disk driver. Current name is "highbank-ahci" but
the module is "sata_highbank". Rename it to match the module name.
Cc: Rob Herring
Cc: Alexander Graf
Cc: v3.7..
Signed-off-by: Robe
On Tue, 30 Apr 2013, Andrew Morton wrote:
> > > diff --git a/include/linux/memory.h b/include/linux/memory.h
> > > index 73817af..85c31a8 100644
> > > --- a/include/linux/memory.h
> > > +++ b/include/linux/memory.h
> > > @@ -137,7 +137,7 @@ enum mem_add_context { BOOT, HOTPLUG };
> > > #define re
On Mon, 2013-04-29 at 15:21 +0200, Jiri Kosina wrote:
> On Thu, 13 Dec 2012, Hirokazu Takata wrote:
> > Acked-by: Hirokazu Takata
Hi Jiri.
It's really not useful to cherry-pick a few patches
from this series.
You must first apply patch 1 of 26 before applying any
of the others as a new vsprintf
Commit-ID: 1b0dac2ac6debdbf1541e15f2cede03613cf4465
Gitweb: http://git.kernel.org/tip/1b0dac2ac6debdbf1541e15f2cede03613cf4465
Author: Jan-Simon Möller
AuthorDate: Tue, 30 Apr 2013 12:02:33 +0200
Committer: Ingo Molnar
CommitDate: Tue, 30 Apr 2013 13:12:47 +0200
perf/x86/intel: Fix uni
Commit-ID: 83aee67833071c7b73a83f7803388f7a9e481908
Gitweb: http://git.kernel.org/tip/83aee67833071c7b73a83f7803388f7a9e481908
Author: Borislav Petkov
AuthorDate: Fri, 26 Apr 2013 11:51:40 +0200
Committer: Ingo Molnar
CommitDate: Tue, 30 Apr 2013 11:00:11 +0200
x86/kconfig: Add a Kconf
Commit-ID: 9a6bc14350b130427725f33e371e86212fa56c85
Gitweb: http://git.kernel.org/tip/9a6bc14350b130427725f33e371e86212fa56c85
Author: Vince Weaver
AuthorDate: Mon, 29 Apr 2013 15:52:27 -0400
Committer: Ingo Molnar
CommitDate: Tue, 30 Apr 2013 10:56:45 +0200
perf/x86/intel: Add support
Commit-ID: 80e217e9ca98a99d6ee95c8f4473b7ebf6d1b8ca
Gitweb: http://git.kernel.org/tip/80e217e9ca98a99d6ee95c8f4473b7ebf6d1b8ca
Author: Vince Weaver
AuthorDate: Mon, 29 Apr 2013 15:49:28 -0400
Committer: Ingo Molnar
CommitDate: Tue, 30 Apr 2013 10:56:44 +0200
perf/x86/intel: Fix typo in
Commit-ID: f7b0e1055574ce06ab53391263b4e205bf38daf3
Gitweb: http://git.kernel.org/tip/f7b0e1055574ce06ab53391263b4e205bf38daf3
Author: Li Fei
AuthorDate: Fri, 26 Apr 2013 20:50:11 +0800
Committer: Ingo Molnar
CommitDate: Tue, 30 Apr 2013 10:56:37 +0200
x86: Eliminate irq_mis_count coun
On 04/29, Colin Cross wrote:
>
> Avoid waking up every thread sleeping in a sigtimedwait call during
> suspend and resume by calling a freezable blocking call.
This doesn't explain why do want this change...
OK, probably to avoid -EAGAIN from sigtimedwait() if the freezer wakes
up the caller.
>
On Mon, 29 Apr 2013, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix build error when CONFIG_PROC_FS is not enabled:
>
> include/linux/tty.h: In function 'proc_tty_register_driver':
> include/linux/tty.h:698:52: error: parameter name omitted
> include/linux/tty.h: In function 'proc_tty_unregis
On Mon, 29 Apr 2013, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix build error when CONFIG_PROC_FS is not enabled:
> (remove duplicated line)
>
> include/linux/proc_fs.h:58:20: error: redefinition of 'proc_set_size'
> include/linux/proc_fs.h:51:20: note: previous definition of 'proc_set_size
* Linus Torvalds wrote:
> On Tue, Apr 30, 2013 at 9:23 AM, Ingo Molnar wrote:
> >
> > Linus, would you like me to revert d9a3c9823a2e and re-send the pull
> > request?
>
> I took the pull request, but I'd like to see the non-64-bit divide
> version before the merge window ends. [...]
Yeah, w
On Tue, 30 Apr 2013 09:17:11 -0700 (PDT) David Rientjes
wrote:
> On Tue, 30 Apr 2013, Vincent Stehl__ wrote:
>
> > diff --git a/include/linux/memory.h b/include/linux/memory.h
> > index 73817af..85c31a8 100644
> > --- a/include/linux/memory.h
> > +++ b/include/linux/memory.h
> > @@ -137,7 +137,
Hi Linus,
Please pull dlm updates from tag:
git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm.git dlm-3.10
This includes a single patch to avoid fully processing a
posix unlock from close when no posix locks exist on the file.
Patch copied below.
Thanks,
Dave
dlm: avoid unnece
On Tue, Apr 30, 2013 at 9:23 AM, Ingo Molnar wrote:
>
> Linus, would you like me to revert d9a3c9823a2e and re-send the pull
> request?
I took the pull request, but I'd like to see the non-64-bit divide
version before the merge window ends. And with no more div_rem users I
think we should at leas
On Tue, 2013-04-30 at 13:32 +, Christoph Lameter wrote:
> On Mon, 29 Apr 2013, Tim Chen wrote:
>
> > diff --git a/include/linux/percpu_counter.h b/include/linux/percpu_counter.h
> > index d5dd465..5ca7df5 100644
> > --- a/include/linux/percpu_counter.h
> > +++ b/include/linux/percpu_counter.h
* Stanislaw Gruszka wrote:
> On Tue, Apr 30, 2013 at 07:49:43AM -0700, Linus Torvalds wrote:
> > On Mon, Apr 29, 2013 at 11:58 PM, Ingo Molnar wrote:
> > >
> > > Please pull the latest sched-core-for-linus git tree from:
> > >
> > > The main changes in this development cycle were:
> > >
> > >
Thanks Sitsofe; we will look into this.
Regards,
K. Y
> -Original Message-
> From: Sitsofe Wheeler [mailto:sits...@yahoo.com]
> Sent: Tuesday, April 30, 2013 12:12 PM
> To: KY Srinivasan; Haiyang Zhang
> Cc: de...@linuxdriverproject.org; James E.J. Bottomley; linux-
> ker...@vger.kernel.
From: Jon Medhurst
Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value. The hook must return true when smp_ops are initialized.
If false the static mdesc->smp_ops will be used by default.
Add the
Rename virt_smp_ops to psci_smp_ops and move them to arch/arm/kernel/psci_smp.c.
Remove mach-virt/platsmp.c, now unused.
Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
Add a cpu_die smp_op based on psci_ops.cpu_off.
Initialize PSCI before setting smp_ops in setup_arch.
If PSCI is available
Hi all,
this is the tenth version of the patch series to move virt_smp_ops out
of mach-virt and make it a generic set of reusable PSCI based smp_ops.
psci_smp_ops are preferred over the platform smp_ops. The last patch
introduces smp_init.
Changes in v10:
- add include to mach/arch.h.
Jon Med
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: 24 April 2013 14:15
> To: Opensource [Anthony Olech]
> Cc: Grant Likely; Linus Walleij; Mark Brown; LKML; David Dajun Chen; Lee Jones
> Subject: Re: [NEW DRIVER V6 5/7] drivers/gpio: DA9058 GPIO driver
> On
On Tue, 30 Apr 2013, Vincent Stehlé wrote:
> diff --git a/include/linux/memory.h b/include/linux/memory.h
> index 73817af..85c31a8 100644
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
> @@ -137,7 +137,7 @@ enum mem_add_context { BOOT, HOTPLUG };
> #define register_hotmemory_notifi
In order to reuse bits from pagemap entries gracefully, we leave the entries as
is but on pagemap open emit a warning in dmesg, that bits 55-60 are about to
change
in a couple of releases. Next, if a user issues soft-dirty clear command via the
clear_refs file (it was disabled before v3.9) we assu
The soft-dirty is a bit on a PTE which helps to track which pages a task
writes to. In order to do this tracking one should
1. Clear soft-dirty bits from PTEs ("echo 4 > /proc/PID/clear_refs)
2. Wait some time.
3. Read soft-dirty bits (55'th in /proc/PID/pagemap entries)
To do this tracking
These bits are always constant (== PAGE_SHIFT) and just occupy space in
the entry. Moreover, in next patch we will need to report one more bit in
the pagemap, but all bits are already busy on it.
That said, describe the pagemap entry that has 6 more free zero bits.
Signed-off-by: Pavel Emelyanov
In the next patch the clear-refs-type will be required in
clear_refs_pte_range funciton, so prepare the walk->private to carry this
info.
Signed-off-by: Pavel Emelyanov
Cc: Andrew Morton
Cc: Matt Mackall
Cc: Xiao Guangrong
Cc: Glauber Costa
Cc: Marcelo Tosatti
Cc: KOSAKI Motohiro
---
fs/pr
Apologies for the previous empty mail.
While testing a Windows 2012 host with a Fedora 18 guest running a 3.9
kernel I've found that Hyper-v will stall all access to
(para)virtualised disk devices when an underlying disk device returns an
error. Every ten seconds a tiny bit of I/O goes through bef
This is the implementation of the soft-dirty bit concept that should help
keep track of changes in user memory, which in turn is very-very required
by the checkpoint-restore project (http://criu.org).
To create a dump of an application(s) we save all the information about it
to files, and the bigg
This is the resend and (while the iron is hot) the request for merge of
the implementation of the soft-dirty bit concept that should help to track
changes in user memory.
This set differs from what Andrew has sent recently in a single point --
the way pagemap entries' bits are reused (patch #5, an
Hi Linus,
Please pull the arm64 patches below. Thanks.
The following changes since commit 792072066d30372772137be9ee2f4d72d77329f9:
arm64: Kconfig.debug: Remove unused CONFIG_DEBUG_ERRORS (2013-03-19 16:19:19
+)
are available in the git repository at:
git://git.kernel.org/pub/scm/linu
On Tue, 2013-04-30 at 11:06 -0400, Don Dutile wrote:
> On 04/30/2013 10:49 AM, Suravee Suthikulanit wrote:
> > On 4/29/2013 3:10 PM, Don Dutile wrote:
> >> On 04/29/2013 03:45 PM, Suravee Suthikulanit wrote:
> >>> Joerg,
> >>>
> >>> We are in the process of implementing AMD IOMMU error handling, an
Christoph Lameter wrote:
> On Tue, 30 Apr 2013, Tetsuo Handa wrote:
>
> > The testcases still trigger BUG() at 32M:
>
> I thought we established that MAX_ORDER only allows a maximum of 8M sized
> allocations? Why are you trying 32M?
Only for regression testing. At least until Linux 3.9, requesti
On Tue, 30 Apr 2013, Nicolas Pitre wrote:
> On Tue, 30 Apr 2013, Stefano Stabellini wrote:
>
> > On Tue, 30 Apr 2013, Geert Uytterhoeven wrote:
> > > On Tue, Apr 30, 2013 at 11:33 AM, Nicolas Ferre
> > > wrote:
> > > > So, I am wondering if the best correction is to add the types.h header
> > >
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 04/29/2013 07:21 PM, Andy Lutomirski wrote:
Out of curiosity, what is this driver doing?
It uses aperf/mperf magic to (I think) estimate how busy the CPU has
been recently. (This is clearly somewhat Intel-specific, but a similar
estimate could be made using knowledge of the programmed frequ
Just booted todays git tree and got the following warning:
[ cut here ]
WARNING: at kernel/cpu/idle.c:96 cpu_startup_entry+0x14d/0x160()
Hardware name: System Product Name
Pid: 0, comm: swapper/2 Not tainted 3.9.0-03462-gab86e97-dirty #424
Call Trace:
smpboot: Booting Node
Some platforms insist on obscure physical channel availability. This
information is currently passed though platform data in internal BSP
kernels. Once those platforms land, they'll need to configure them
appropriately, so we may as well add the infrastructure.
Cc: Vinod Koul
Cc: Dan Williams
Cc
Some platforms have channels which are not available for normal use.
This information is currently passed though platform data in internal
BSP kernels. Once those platforms land, they'll need to configure them
appropriately, so we may as well add the infrastructure.
Cc: Vinod Koul
Cc: Dan William
The DMA platform data is now empty due to some recent refactoring,
so there is no longer a requirement to pass it though.
Signed-off-by: Lee Jones
---
arch/arm/mach-ux500/cpu-db8500.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch
It's not possible to configure memcpy channels dynamically with DT.
We're providing them despite the fact that they're the same as the
hard-coded channels, as they will be removed once the u8500 platform
goes DT-only.
Signed-off-by: Lee Jones
---
arch/arm/boot/dts/dbx5x0.dtsi |2 ++
1 file c
At this moment in time the memcpy channels which can be used by the D40
are fixed, as each supported platform in Mainline uses the same ones.
However, platforms do exist which don't follow this convention, so
these will need to be tailored. Fortunately, these platforms will be DT
only, so this chan
On Tue, Mar 19, 2013 at 03:35:09PM +0100, Jiri Olsa wrote:
> On Tue, Mar 19, 2013 at 12:46:58PM +0100, Peter Zijlstra wrote:
> >
> > > are you going to include that, or should I repost it?
> >
> > Ah, please repost (and prettify) it, I'm still very limited in the
> > amount of work that I can do
Il 05/04/2013 09:10, Hu Tao ha scritto:
> pvpanic device is a qemu simulated device through which guest panic
> event is sent to host.
>
> Signed-off-by: Hu Tao
Ping. This will be in QEMU 1.5, is this on track for the 3.10 kernel?
Thanks,
Paolo
> ---
>
> ref: http://lists.nongnu.org/archive
On Tue, Apr 30, 2013 at 07:49:43AM -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 11:58 PM, Ingo Molnar wrote:
> >
> > Please pull the latest sched-core-for-linus git tree from:
> >
> > The main changes in this development cycle were:
> >
> > - full dynticks preparatory work by Frederic
On Tue, Apr 30, 2013 at 01:59:55PM +0200, Rafael J. Wysocki wrote:
> On Monday, April 29, 2013 04:10:19 PM Greg Kroah-Hartman wrote:
> > On Mon, Apr 29, 2013 at 02:26:56PM +0200, Rafael J. Wysocki wrote:
> > > +static inline bool device_supports_offline(struct device *dev)
> > > +{
> > > + return d
On 04/30/2013 10:54 AM, Sumner, William wrote:
I have installed your original patch set (from last November) and tested with
three platforms, each with a different IO configuration. On the first platform
crashdumps were consistently successful. On the second and third platforms,
the reset of
On Fri, Apr 26, 2013 at 11:41:32AM +0100, Stefano Stabellini wrote:
> Arnd, Olof,
> during the last few merge windows Konrad has always sent the Xen ARM
> patches to Linus via his tree, but this time (3.10 merge window), after
> consulting with Konrad I am thinking of sending to Linus the pull
> re
Subject: Fix off by one error in slab.h
We ran into some strange issues as a result of an off by one isse in slab.h
The root of the issue is the treatment of KMALLOC_SHIFT_HIGH that is confusing.
Make KMALLOC_SHIFT_HIGH the first unsupported size instead of the last
supported.
Signed-off-by: C
On Wed, Mar 27, 2013 at 03:09:32PM +0100, Peter Zijlstra wrote:
> On Wed, 2013-03-27 at 10:49 +0100, Borislav Petkov wrote:
> > Ok, just for my own understanding: how do the events on the
> > ->task_ctx->event_list relate to the current cpu in this path? I mean,
> > we're on the task exit path here
On Tue, Apr 30, 2013 at 02:01:10PM +0200, Rafael J. Wysocki wrote:
> On Monday, April 29, 2013 04:11:06 PM Greg Kroah-Hartman wrote:
> > On Mon, Apr 29, 2013 at 02:28:02PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > Rework the CPU hotplug code in drivers/base/cpu.c t
Hi guys,
This pull includes fixes for the merge window material currently sitting
in tip/x86/efi. The three patches from me fix bugs in the pstore code
paths and the two from Dan are the results of his static analysis tool,
including a fix for a locking bug.
The changes are based on my efi-for-ti
On Tue, Apr 30, 2013 at 12:43 AM, Ingo Molnar wrote:
>
> 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
Hmm.. The "Use generic idle loop" patches from the SMP/hotplug pull
conflicted with the "U
On Tue, Apr 30, 2013 at 09:56:22AM -0500, Suthikulpanit, Suravee wrote:
> This sounds more like issue with the order of how things are
> initialized in the system.
No, the problem is that almost all BIOS-provided IVRS tables are buggy
because they do not define a unity-mapped region for devices t
On Tue, 30 Apr 2013, Stefano Stabellini wrote:
> On Tue, 30 Apr 2013, Geert Uytterhoeven wrote:
> > On Tue, Apr 30, 2013 at 11:33 AM, Nicolas Ferre
> > wrote:
> > > So, I am wondering if the best correction is to add the types.h header
> > > file
> > > in the asm/mach/arch.h file, like this:
>
On 04/30/2013 04:02 PM, Stefano Stabellini wrote:
> On Mon, 29 Apr 2013, Julien Grall wrote:
>> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
>> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
>> irq_startup, that is responsible for calling irq_unmask at start
Here is patch, which add Linus cputime scaling algorithm to the kernel.
This is follow up of commit d9a3c9823a2e6a543eb7807fb3d15d8233817ec5
"sched: Lower chances of cputime scaling overflow" which try to avoid
multiplication overflow, but not guarantee that the overflow will not
happen.
Linus cr
When we fail to mutex_trylock(), we release the pool spin_lock and do
mutex_lock(). After that, we should regrab the pool spin_lock, but,
regrabbing is missed in current code. So correct it.
Cc: Lai Jiangshan
Signed-off-by: Joonsoo Kim
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index
On 04/30/2013 10:56 AM, Suravee Suthikulanit wrote:
On 4/29/2013 4:42 PM, Don Dutile wrote:
On 04/29/2013 04:34 PM, Duran, Leo wrote:
I'm wondering if resetting the IOMMU at init-time (once) would clear any BIOS
induced noise.
Leo
Well, depends what you mean by 'reset'
(a) setting it up
On 04/30/2013 10:49 AM, Suravee Suthikulanit wrote:
On 4/29/2013 3:10 PM, Don Dutile wrote:
On 04/29/2013 03:45 PM, Suravee Suthikulanit wrote:
Joerg,
We are in the process of implementing AMD IOMMU error handling, and I would
like some comments from you and the community.
Currently, the AMD
On Tue, Apr 30, 2013 at 02:02:25PM +0900, Jingoo Han wrote:
> Use devm_*() functions to make cleanup paths simpler.
>
> Signed-off-by: Jingoo Han
> ---
> No changes since v1:
>
Side note: If you make no changes, there is no need to send V2, especially not
one marked as another version. Usually,
On Mon, 29 Apr 2013, Julien Grall wrote:
> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> irq_startup, that is responsible for calling irq_unmask at startup time.
> As a result event channels remain masked.
>
On Tue, 2013-04-30 at 11:14 +0200, Tim Sander wrote:
> Hi Steve and all RT Folks
>
> > I'm pleased to announce the 3.4.41-rt55-feat3 feature release.
> >
> > Note, I first uploaded -feat2 then realized I didn't add a compile fix by
> > Mike Galbraith, and then created the -feat3 with that fix.
>
Yes, please send pull requests.
Matt Fleming wrote:
>On 30/04/13 09:47, Ingo Molnar wrote:
>> The other problem is that tip:x86/efi also conflicts with current
>-git, as
>> of v3.9 - due to interaction with an EFI fix tree ...
>>
>> This is getting ugly pretty fast, so I'd suggest to re-do the
This is update for iproute2 tools for 3.9 kernel.
In addition the usual documentation fixes, this version includes the
utilities to manage forwarding tables in bridge and vxlan.
If you have been sitting on changes to iproute2 that are in
net-next for 3.10 merge window, please submit them now.
Ipr
On 4/29/2013 4:42 PM, Don Dutile wrote:
On 04/29/2013 04:34 PM, Duran, Leo wrote:
I'm wondering if resetting the IOMMU at init-time (once) would clear
any BIOS induced noise.
Leo
Well, depends what you mean by 'reset'
(a) setting it up for OS use is effectively a reset, but doesn't
quies
I confirmed that efi_pstore_read() and efi_pstore_erase() work correctly.
Please feel free to add
Tested-by: Seiji Aguchi
> -Original Message-
> From: Matt Fleming [mailto:matt.flem...@intel.com]
> Sent: Tuesday, April 30, 2013 7:28 AM
> To: Seiji Aguchi
> Cc: linux-kernel@vger.kernel.or
I have installed your original patch set (from last November) and tested with
three platforms, each with a different IO configuration. On the first platform
crashdumps were consistently successful. On the second and third platforms,
the reset of one specific PCI device on each platform (a diff
Hi Linus,
this is my first pull request to you, Konrad decided to let me deal
with the Xen/ARM stuff myself recently.
Please pull the following tag (based on 3.9-rc3):
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
3.9-rc3-smp-6-tag
It contains a bunch of Xen/ARM specific chan
On Mon, Apr 29, 2013 at 11:58 PM, Ingo Molnar wrote:
>
> Please pull the latest sched-core-for-linus git tree from:
>
> The main changes in this development cycle were:
>
> - full dynticks preparatory work by Frederic Weisbecker
Why does this have the crappy cputime scaling overflow code, when
On 4/29/2013 3:10 PM, Don Dutile wrote:
On 04/29/2013 03:45 PM, Suravee Suthikulanit wrote:
Joerg,
We are in the process of implementing AMD IOMMU error handling, and I
would like some comments from you and the community.
Currently, the AMD IOMMU driver only reports events from the event
lo
Warlich, Christof writes:
> Mikael Pettersson writes:
> > Write to the fpstate ->mxcsr and ->swd fields in the sigaction handler's
> > uc_mcontext.
>
> To me, "sigaction handler's uc_mcontext" sounds like userspace, which really
> confuses me:
> Even in most recent glibc-2.17, uc_mcontex
201 - 300 of 459 matches
Mail list logo
