On Thu, 2015-02-19 at 19:12 +0100, Sylvain Rochet wrote:
> Or use a 1-wire or I2C EEPROM to store your board information.
no, you don't reduce the human error probability.
eeprom needs to be preprogrammed, factory will at some point have a lot
of eeprom with different version, and will
perf_time_to_tsc and tsc_to_perf_time are only used for x86. Make
inclusion of tsc.c dependent on x86 as well.
Signed-off-by: David Ahern
Cc: Adrian Hunter
Cc: Jiri Olsa
---
tools/perf/util/Build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/Build
On Thu, 2015-02-19 at 20:07 +0900, Tetsuo Handa wrote:
> Why do we need to let the caller call path_put() ?
> There is no need to do like proc_exe_link() does, for
> tomoyo_get_exe() returns pathname as "char *".
Having the pathname doesn't guarantee anything later, and thus doesn't
seem very
On Thu, 2015-02-19 at 17:05 +0200, Mathias Nyman wrote:
> On 19.02.2015 02:34, Tim Chen wrote:
> >
> > Commit d92ef66c4f8f ("x86: make dma_alloc_coherent() return zeroed memory
> > if CMA is enabled") changed the dma_alloc_coherent page clearance from
> > using an __GFP_ZERO in page allocation to
On Thu, Feb 19, 2015 at 11:06 AM, wrote:
> From: Dinh Nguyen
>
> By not having bit 22 set in the PL310 Auxiliary Control register (shared
> attribute override enable) has the side effect of transforming Normal
> Shared Non-cacheable reads into Cacheable no-allocate reads.
>
> Coherent DMA
On Thu, Feb 19, 2015 at 12:01:14PM -0600, Rob Herring wrote:
> On Wed, Feb 18, 2015 at 8:08 PM, Frank Rowand wrote:
> > On 2/18/2015 6:59 AM, Pantelis Antoniou wrote:
> >> Implement a method of applying DT quirks early in the boot sequence.
> >>
> >> A DT quirk is a subtree of the boot DT that
On Thu, Feb 19, 2015 at 05:08:28PM +, Srinivas Kandagatla wrote:
> From: Maxime Ripard
>
> Up until now, EEPROM drivers were stored in drivers/misc, where they all had
> to
> duplicate pretty much the same code to register a sysfs file, allow in-kernel
> users to access the content of the
On 18/02/2015 06:51, Juergen Gross wrote:
xen_set_identity_and_remap() is used to prepare remapping of memory
conflicting with the E820 map. It is tracking the pfn where to remap
new memory via a local variable which is passed to a subfunction
which in turn returns the new value for that
Hello,
On Thu, Feb 19, 2015 at 07:01:59PM +0100, Maxime Bizon wrote:
> On Thu, 2015-02-19 at 19:38 +0200, Pantelis Antoniou wrote:
>
> > Having to boot and tweak the bootloader settings to select the correct
> > dtb (even if it’s present on the flash medium) takes time and is
> > error-prone.
>
On Thu, 2015-02-19 at 19:38 +0200, Pantelis Antoniou wrote:
> Having to boot and tweak the bootloader settings to select the correct
> dtb (even if it’s present on the flash medium) takes time and is
> error-prone.
Dedicate a set of GPIO for board/PCB revision detection (it only costs a
few
On 18/02/2015 06:51, Juergen Gross wrote:
Currently especially for dom0 guest memory with guest pfns not
matching host areas populated with RAM are remapped to areas which
are RAM native as well. This is done to be able to use identity
mappings (pfn == mfn) for I/O areas.
Up to now it is not
On Thu, 2015-02-19 at 17:58 +, Pawel Moll wrote:
> and what Adrian did, explicitly
> defining possible timestamps at perf_event_attr level instead of
> relating them to to posix clock ids is the way to go. No strong opinion
> here.
One note here: I'd rather make it "processor trace clock",
On Wed, Feb 18, 2015 at 8:08 PM, Frank Rowand wrote:
> On 2/18/2015 6:59 AM, Pantelis Antoniou wrote:
>> Implement a method of applying DT quirks early in the boot sequence.
>>
>> A DT quirk is a subtree of the boot DT that can be applied to
>> a target in the base DT resulting in a modification
On Thu, 2015-02-19 at 17:50 +, John Stultz wrote:
> On Thu, Feb 19, 2015 at 9:40 AM, Adrian Hunter
> wrote:
> > On 19/02/2015 7:24 p.m., John Stultz wrote:
> >>
> >> On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter
> >> wrote:
> >>>
> >>> Hi
> >>>
> >>> With the advent of switching perf_clock
Am 19.02.2015 um 18:44 schrieb Doug Anderson:
> On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown wrote:
>> On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote:
>>
>>> static const struct of_device_id snow_of_match[] = {
>>> + { .compatible = "google,snow-audio-max98089", },
>>> {
On Wed, Feb 18, 2015 at 1:14 PM, Alexey Dobriyan wrote:
> On Tue, Feb 17, 2015 at 04:17:24PM -0800, Andrew Morton wrote:
>> ?
>>
>> Begin forwarded message:
>>
>> Date: Mon, 16 Feb 2015 10:48:50 -0800
>> From: Anshul Garg
>> To: linux-kernel@vger.kernel.org
>> Cc: aksgarg1...@gmail.com,
On Mon, 16 Feb 2015, Peter Zijlstra wrote:
> From: Thomas Gleixner
>
> Preeti reported a cpu down race with hrtimer based broadcasting:
>
> Assume CPU1 is the CPU which holds the hrtimer broadcasting duty
> before it is taken down.
>
> CPU0 CPU1
> cpu_down()
>
Andreas,
On Thu, Feb 19, 2015 at 6:13 AM, Andreas Färber wrote:
>> I see that a master clock (mclk) is added in patch 6/6 but the
>> max98088 codec driver does handle this clock.
>>
>> If the SoC XCLKOUT provides the master clock to the max98089
>> codec in Spring like is the case for the
On Thu, Feb 19, 2015 at 9:40 AM, Adrian Hunter wrote:
> On 19/02/2015 7:24 p.m., John Stultz wrote:
>>
>> On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter
>> wrote:
>>>
>>> Hi
>>>
>>> With the advent of switching perf_clock to CLOCK_MONOTONIC,
>>> it will not be possible to convert perf_clock
On February 19, 2015 6:32:55 PM CET, Josh Poimboeuf wrote:
>> Yes. I'm saying that rather than guaranteeing they don't enter the
>> kernel (by having them spin) you can flip them in case they try to do
>> that instead. That solves the race condition just as well.
>
>Ok, gotcha.
>
>We'd still
On 18/02/2015 06:52, Juergen Gross wrote:
With adapting the memory layout of dom0 to that of the host care must
be taken not to remap the initial p2m list supported by the hypervisor.
"...supplied by the hypervisor" ?
If the p2m map is detected to be in a region which is going to be
Mark,
On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown wrote:
> On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote:
>
>> static const struct of_device_id snow_of_match[] = {
>> + { .compatible = "google,snow-audio-max98089", },
>> { .compatible = "google,snow-audio-max98090",
> Great. Thanks for fixing this.
Not great.
This still leaves all the other drivers which may be affected by similar
problems.
IMHO Tim's original patch is still needed.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe
> > And NTP limits the slew rate to 500 PPM, so even if you would get a
Assuming you run NTP
>
> Assuming it is not broken.
It could also easily switch to HPET if the kernel decides the TSC has some
issues (which may be true or not).
The switching of the perf clock to MONOTONIC is a bad idea
On 19/02/2015 7:24 p.m., John Stultz wrote:
On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter wrote:
Hi
With the advent of switching perf_clock to CLOCK_MONOTONIC,
it will not be possible to convert perf_clock directly to/from
TSC. So add the ability to sample TSC instead.
Adrian Hunter (2):
spear13xx_pcie_driver.driver is allocated in text.init section
and then the pointer to it is passed futher. This patch is to avoid
crashes like the following, when freed memory is used.
Also, __init has been dropped from the probe() function referred from the struct
and all called functions.
#0
On Thu, 2015-02-19 at 18:33 +0100, Borislav Petkov wrote:
> On Thu, Feb 19, 2015 at 10:21:53AM -0700, Ross Zwisler wrote:
> > Interesting, it looks like I need to include explicitly for
> > UML. New patch on the way.
>
> You'd need to do an incremental fix ontop, though.
Oh, instead of just
On Thu, Feb 19, 2015 at 8:59 AM, Linus Torvalds
wrote:
>
> Are there known errata for the x2apic?
.. and in particular, do we still have to worry about the traditional
local apic "if there are more than two pending interrupts per priority
level, things get lost" problem?
I forget the exact
On 18/02/2015 06:52, Juergen Gross wrote:
When adapting the dom0 memory layout to that of the host make sure
the initrd isn't moved to another pfn range, as it won't be found
there any more.
The easiest way to accomplish that is by copying the initrd to an
area which is RAM according to the
> On Feb 19, 2015, at 19:30 , Frank Rowand wrote:
>
> On 2/19/2015 9:00 AM, Pantelis Antoniou wrote:
>> Hi Frank,
>>
>>> On Feb 19, 2015, at 18:48 , Frank Rowand wrote:
>>>
>>> On 2/19/2015 6:29 AM, Pantelis Antoniou wrote:
Hi Mark,
> On Feb 18, 2015, at 19:31 , Mark Rutland
Add support for the new pcommit (persistent commit) instruction.
This instruction was announced in the document "Intel
Architecture Instruction Set Extensions Programming Reference"
with reference number 319433-022.
https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
The
On 18/02/2015 06:52, Juergen Gross wrote:
Check whether the page tables built by the domain builder are at
memory addresses which are in conflict with the target memory map.
If this is the case just panic instead of running into problems
later.
Again, what ensures this never actually
Hi,
On 13/02/15 01:26, Sasha Levin wrote:
> Provides a userspace interface to trigger a CMA allocation.
>
> Usage:
>
> echo [pages] > alloc
>
> This would provide testing/fuzzing access to the CMA allocation paths.
>
> Signed-off-by: Sasha Levin
> ---
> mm/cma.c |6 ++
>
On 18/02/2015 06:52, Juergen Gross wrote:
In case a pre-allocated memory area is to be moved in order to avoid
a conflict with the target E820 map we need a way to copy data between
physical addresses.
Add a function doing this via early_memremap().
[...]
--- a/arch/x86/xen/setup.c
+++
On 18/02/2015 06:52, Juergen Gross wrote:
Checks whether the pre-allocated memory of the loaded kernel is in
conflict with the target memory map. If this is the case, just panic
instead of run into problems later.
What ensures this doesn't actually happen?
David
--
To unsubscribe from this
On Thu, Feb 19, 2015 at 10:21:53AM -0700, Ross Zwisler wrote:
> Interesting, it looks like I need to include explicitly for
> UML. New patch on the way.
You'd need to do an incremental fix ontop, though.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To
On Thu, Feb 19, 2015 at 06:19:29PM +0100, Vojtech Pavlik wrote:
> On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> > On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> > > On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
> > >
> > > > > No, these
On 18/02/2015 06:52, Juergen Gross wrote:
For being able to relocate pre-allocated data areas like initrd or
p2m list it is mandatory to find a contiguous memory area which is
not yet in use and doesn't conflict with the memory map we want to
be in effect.
In case such an area is found reserve
On 2/19/2015 9:00 AM, Pantelis Antoniou wrote:
> Hi Frank,
>
>> On Feb 19, 2015, at 18:48 , Frank Rowand wrote:
>>
>> On 2/19/2015 6:29 AM, Pantelis Antoniou wrote:
>>> Hi Mark,
>>>
On Feb 18, 2015, at 19:31 , Mark Rutland wrote:
>>> +While this may in theory work, in practice it
I could only find an advisory (regarding sr-iov and irq remaps) from
HP to RHEL6.2 users stating that Gen8 firmware does not enable it by
default.
http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c03645796
"""
The interrupt remapping capability depends on x2apic enabled in the
BIOS
Hi Josh,
Thank you for the review.
On Wed, 18 Feb 2015 09:34:46 -0600
Josh Cartwright wrote:
> Hey Gilad-
>
> On Mon, Feb 09, 2015 at 03:51:12PM -0700, Gilad Avidov wrote:
> > Qualcomm PMIC Arbiter version-2 changes from version-1 are:
> >
> > - Some different register offsets.
> > - New
From: Dinh Nguyen
By not having bit 22 set in the PL310 Auxiliary Control register (shared
attribute override enable) has the side effect of transforming Normal
Shared Non-cacheable reads into Cacheable no-allocate reads.
Coherent DMA buffers in Linux always have a Cacheable alias via the
On 15/02/2015 08:19, Bob Liu wrote:
Move the request complete logic out of blkif_interrupt() to a work queue,
after that we can replace 'spin_lock_irq' with 'spin_lock' so that irq won't
be disabled too long in blk_mq_queue_rq().
I think using a threaded interrupt (like scsifront) is better
On Thu, 19 Feb 2015, Vince Weaver wrote:
> I have to take that back, it turns out the Cortex-A9 machine was wedged
> for over a day, I just hadn't noticed because it hadn't dumped any kind
> of message about the problem. Hmm.
This turns out to be the find_get_context() bug that has been fixed
On 18/02/2015 06:51, Juergen Gross wrote:
Instead of using a function local static e820 map in xen_memory_setup()
and calling various functions in the same source with the map as a
parameter use a map directly accessible by all functions in the source.
Reviewed-by: David Vrabel
David
--
To
On 19/02/2015 6:22 p.m., David Ahern wrote:
On 2/19/15 9:17 AM, Adrian Hunter wrote:
Yes, I am sorry it is a pain. I don't know why I didn't add a comment
to the code :-(. Using -1 for the pid is a workaround to avoid gratuitous
jump label changes. If pid=0 is used and then a system-wide trace
From: Dinh Nguyen
Enabling D and I prefetch bits helps improve SDRAM performance on the
platform.
Signed-off-by: Dinh Nguyen
---
arch/arm/mach-socfpga/socfpga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-socfpga/socfpga.c
On Thu, Feb 19, 2015 at 4:11 AM, Adrian Hunter wrote:
> Hi
>
> With the advent of switching perf_clock to CLOCK_MONOTONIC,
> it will not be possible to convert perf_clock directly to/from
> TSC. So add the ability to sample TSC instead.
>
>
> Adrian Hunter (2):
> perf: Sample additional
On Wed, 11 Feb 2015, Vince Bridgers wrote:
> Correct SCU virtual mapping that was causing this BUG message:
>
> "BUG: mapping for 0xfffec000 at 0xfffec000 out of vmalloc space"
>
> Signed-off-by: Vince Bridgers
> ---
> arch/arm/mach-socfpga/core.h | 2 +-
> 1 file changed, 1 insertion(+), 1
On Thu, 2015-02-19 at 02:15 +0100, Ingo Molnar wrote:
> * tip-bot for Ross Zwisler wrote:
>
> > Commit-ID: a71ef01336f2228dc9d47320492360d6848e591e
> > Gitweb:
> > http://git.kernel.org/tip/a71ef01336f2228dc9d47320492360d6848e591e
> > Author: Ross Zwisler
> > AuthorDate: Tue, 27 Jan
On Thu, 19 Feb 2015, Vince Weaver wrote:
> I also have a core2 and a Cortex-A9 machine fuzzing
> away and they've been at it a week now without turning up anything.
I have to take that back, it turns out the Cortex-A9 machine was wedged
for over a day, I just hadn't noticed because it hadn't
On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> > On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
> >
> > > > No, these tasks will _never_ make syscalls. So you need to guarantee
> > > > they don't
I've noticed significant locking contention in memory reclaimer around
sb_lock inside grab_super_passive(). Grab_super_passive() is called from
two places: in icache/dcache shrinkers (function super_cache_scan) and
from writeback (function __writeback_inodes_wb). Both are required for
progress in
On Thu, Feb 19, 2015 at 04:52:41PM +, Peter Zijlstra wrote:
> On Thu, Jan 15, 2015 at 11:09:25AM +0100, Vincent Guittot wrote:
> > The average running time of RT tasks is used to estimate the remaining
> > compute
> > capacity for CFS tasks. This remaining capacity is the original capacity
>
Hi Mario,
On Wed, Feb 18, 2015 at 07:43:00PM -0600, Mario Limonciello wrote:
> When the touchpad for the Dell XPS 13 is running in PS/2 mode the
> EC has a tendency to glitch causing the driver to receive bad data.
> This doesn't affect the usage of the touchpad until enough bad data
> is
From: Torsten Fleischer
This patch fixes the following issues regarding to the calculation of the
residue:
1. The residue is always calculated for the current transfer even if the
cookie is associated to a pending transfer.
2. For scatter/gather DMA the calculation of the residue for the
This patchset adds a new simple EEPROM framework to kernel.
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.
This
This patch adds QFPROM support driver which is used by other drivers
like thermal sensor and cpufreq.
On MSM parts there are some efuses (called qfprom) these fuses store things like
calibration data, speed bins.. etc. Drivers like cpufreq, thermal sensors would
read out this data for configuring
From: Maxime Ripard
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel
On Thu, 19 Feb 2015, Josh Poimboeuf wrote:
> > > > No, these tasks will _never_ make syscalls. So you need to guarantee
> > > > they don't accidentally enter the kernel while you flip them. Something
> > > > like so should do.
> > > >
> > > > You set TIF_ENTER_WAIT on them, check they're still
From: Torsten Fleischer
This series fixes the calculation of the residual bytes and adds support for
memory to memory scatter-gather transfers.
Changes from V1:
* Fixed coding style of the multi-line comments.
* Improved accuracy of the residue calculation.
Torsten Fleischer (2):
dma:
From: Maxime Ripard
Now that we have the EEPROM framework, we can consolidate the common driver
code. Move the driver to the framework, and hopefully, it will fix the sysfs
file creation race.
Signed-off-by: Maxime Ripard
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
From: Torsten Fleischer
This patch adds support for memory to memory scatter-gather transfers.
Changes from V1:
* Fixed coding style of the multi-line comments.
Signed-off-by: Torsten Fleischer
---
drivers/dma/at_hdmac.c | 169 +
1 file
On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
> On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
>
> > > No, these tasks will _never_ make syscalls. So you need to guarantee
> > > they don't accidentally enter the kernel while you flip them. Something
> > > like
On Thu, Feb 19, 2015 at 05:02:36PM +, Morten Rasmussen wrote:
> > There is no actual function definition in this patch; this would hinder
> > linking, no?
>
> The function definition already lives further down in fair.c. I can move
> it up here if you prefer?
argh.. ok.
With previous
On Thu, Feb 19, 2015 at 04:34:42PM +, Peter Zijlstra wrote:
> On Thu, Jan 15, 2015 at 11:09:24AM +0100, Vincent Guittot wrote:
> > From: Morten Rasmussen
> >
> > Apply frequency scale-invariance correction factor to usage tracking.
> > Each segment of the running_load_avg geometric series is
On Thu, Feb 19, 2015 at 11:54:40AM -0500, Vince Weaver wrote:
> [ 7938.802139] [] perf_tp_event+0xc4/0x210
> [ 7938.861174] [] perf_trace_lock+0x12a/0x160
> [ 7938.882197] [] lock_release+0x130/0x260
> [ 7938.888754] [] _raw_spin_unlock_irqrestore+0x24/0x40
> [ 7938.896510] []
On Thu, 19 Feb 2015, Peter Zijlstra wrote:
> On Thu, Feb 19, 2015 at 11:54:40AM -0500, Vince Weaver wrote:
> >
> > Another bug found by the perf_fuzzer(). I think this one is different
> > than the one I sent the other day, it looks like something is going
> > very wrong in perf_callchain().
>
On Thu, Feb 19, 2015 at 01:06:53PM +, David Vrabel wrote:
> Mel,
>
> The NUMA_BALANCING series beginning with 5d833062139d (mm: numa: do not
> dereference pmd outside of the lock during NUMA hinting fault) and
> specifically 8a0516ed8b90 (mm: convert p[te|md]_numa users to
>
Hi,
I'm trying to understand what exactly is going on here...
On Thu, Feb 12, 2015 at 08:58:19AM -0500, Prarit Bhargava wrote:
> The test did the following in userspace:
>
> tx.modes = ADJ_STATUS;
> tx.status = STA_INS;
>
> /* send leap second request */
> ret =
Hi Frank,
> On Feb 19, 2015, at 18:48 , Frank Rowand wrote:
>
> On 2/19/2015 6:29 AM, Pantelis Antoniou wrote:
>> Hi Mark,
>>
>>> On Feb 18, 2015, at 19:31 , Mark Rutland wrote:
>>>
>> +While this may in theory work, in practice it is very cumbersome
>> +for the following reasons:
Hi All,
We've had a few bug reports with the stack trace below. It looks like
the ms_read_bytes and ms_write_bytes functions in
drivers/memstick/host/rtsx_usb_mc.c are using a stack variable when
calling rtsx_usb_ep0_read_register. That eventually gets to the
DMA-API debugging checks, which
On Thu, Feb 19, 2015 at 8:32 AM, Rafael David Tinoco wrote:
> Feb 19 08:21:28 derain kernel: [3.637682] Switched APIC routing to
> cluster x2apic.
Ok. That "cluster x2apic" mode is just about the nastiest mode when it
comes to sending a single ipi. We do that insane dance where we
- turn
On 15/02/2015 08:19, Bob Liu wrote:
Prepare patch for multi hardware queues, the ring number was mandatory set to 1.
[...]
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -107,21 +110,108 @@ static void xen_update_blkif_status(struct xen_blkif
*blkif)
On Thu, Feb 19, 2015 at 11:54:40AM -0500, Vince Weaver wrote:
>
> Another bug found by the perf_fuzzer(). I think this one is different
> than the one I sent the other day, it looks like something is going
> very wrong in perf_callchain().
>
> This one is reasonably reproducible, if there's any
On Thu, 2015-02-19 at 17:05 +0200, Mathias Nyman wrote:
> On 19.02.2015 02:34, Tim Chen wrote:
> >
> > Commit d92ef66c4f8f ("x86: make dma_alloc_coherent() return zeroed memory
> > if CMA is enabled") changed the dma_alloc_coherent page clearance from
> > using an __GFP_ZERO in page allocation to
On Thu, Jan 15, 2015 at 11:09:25AM +0100, Vincent Guittot wrote:
> The average running time of RT tasks is used to estimate the remaining compute
> capacity for CFS tasks. This remaining capacity is the original capacity
> scaled
> down by a factor (aka scale_rt_capacity). This estimation of
On 2/19/2015 8:40 AM, Frank Rowand wrote:
> On 2/19/2015 6:41 AM, Pantelis Antoniou wrote:
>> Hi Frank,
>>
>>> On Feb 19, 2015, at 04:08 , Frank Rowand wrote:
>>>
>>> On 2/18/2015 6:59 AM, Pantelis Antoniou wrote:
Implement a method of applying DT quirks early in the boot sequence.
Another bug found by the perf_fuzzer(). I think this one is different
than the one I sent the other day, it looks like something is going
very wrong in perf_callchain().
This one is reasonably reproducible, if there's any extra debugging that I
can add. This is on a Haswell machine with git
Offset for smc91x must be zero otherwise smc91x linux kernel driver does not
detect smc91x ethernet hardware in qemu N900 machine.
Signed-off-by: Pali Rohár
---
arch/arm/boot/dts/omap3-n900.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 2/19/2015 6:29 AM, Pantelis Antoniou wrote:
> Hi Mark,
>
>> On Feb 18, 2015, at 19:31 , Mark Rutland wrote:
>>
> +While this may in theory work, in practice it is very cumbersome
> +for the following reasons:
> +
> +1. The act of selecting a different boot device tree blob
On Wednesday 18 February 2015 23:42:06 Tony Lindgren wrote:
> * Pali Rohár [150218 11:07]:
> > On Wednesday 18 February 2015 17:33:53 Tony Lindgren wrote:
> > > > */ +// reg = <1 0x300 0xf>;/* 16 byte IO range at
> >
> > offset
> >
> > > > 0x300 */ + reg = <1
The commit fb93f520e (dmaengine: qcom_bam_dma: Generalize BAM
register offset calculations) wrongly populated base offsets
for event registers for bam v1.4.
Signed-off-by: Stanimir Varbanov
---
drivers/dma/qcom_bam_dma.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff
On to, 2015-02-19 at 15:42 +, Dave Gordon wrote:
> On 19/02/15 11:08, Deak, Imre wrote:
> > On Thu, 2015-02-19 at 10:47 +, Dave Gordon wrote:
> >> On 18/02/15 16:24, Imre Deak wrote:
> >>> On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
> On Tue, 17 Feb 2015, Klaus Ethgen wrote:
On 2/19/2015 6:41 AM, Pantelis Antoniou wrote:
> Hi Frank,
>
>> On Feb 19, 2015, at 04:08 , Frank Rowand wrote:
>>
>> On 2/18/2015 6:59 AM, Pantelis Antoniou wrote:
>>> Implement a method of applying DT quirks early in the boot sequence.
>>>
>>> A DT quirk is a subtree of the boot DT that can be
On Thu, Feb 19, 2015 at 10:13 AM, Maxime Coquelin
wrote:
> Hi Rob,
>
> 2015-02-15 23:42 GMT+01:00 Rob Herring :
>> On Fri, Feb 13, 2015 at 2:42 AM, Maxime Coquelin
>> wrote:
>>> Hi Geert,
>>>
>>> 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven :
On Thu, Feb 12, 2015 at 6:45 PM, Maxime
On Thu, Jan 15, 2015 at 11:09:24AM +0100, Vincent Guittot wrote:
> From: Morten Rasmussen
>
> Apply frequency scale-invariance correction factor to usage tracking.
> Each segment of the running_load_avg geometric series is now scaled by the
> current frequency so the utilization_avg_contrib of
On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
> > No, these tasks will _never_ make syscalls. So you need to guarantee
> > they don't accidentally enter the kernel while you flip them. Something
> > like so should do.
> >
> > You set TIF_ENTER_WAIT on them, check they're still
For the host, we are using "intremap=no_x2apic_optout
intel_idle.max_cstate=0" for cmdline. It looks like that DL360/DL380
Gen8 firmware still asks to optout from x2apic but HP engineering team
said that using x2apic for Gen8 would be ok (intel_idle causes these
servers to generate NMIs when
On 2/19/15 9:17 AM, Adrian Hunter wrote:
Yes, I am sorry it is a pain. I don't know why I didn't add a comment
to the code :-(. Using -1 for the pid is a workaround to avoid gratuitous
jump label changes. If pid=0 is used and then a system-wide trace is done
with Intel PT, there will be a jump
When hot-added memory pages are not brought online or when some memory blocks
are sent offline the subsequent ballooning process kills the guest with OOM
killer. This happens as we don't report these pages as neither used nor free
and apparently host algorythm considers them as being unused. Keep
When host asks us to balloon up we need to be sure we're not committing suicide
by overballooning. Use already existent 'floor' metric as our lowest possible
value for free ram.
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/hv_balloon.c | 11 +++
1 file changed, 11 insertions(+)
diff
In some cases host asks us to overballoon and this triggers OOM killer which
eventually kills everyone. The easiest way to get into such situation is to
avoid onlining memory-hotplugged blocks. Address the issue twice:
- Report offline pages as used to the host so it won't ask us to overballoon;
-
On Thu, Feb 19, 2015 at 7:42 AM, Rafael David Tinoco wrote:
>
> Same environment as before: Nested KVM (2 vcpus) on top of Proliant
> DL380G8 with acpi_idle and no x2apic optout.
Btw, which apic model does that end up using? Does "no x2apic optout"
mean you're using the x2apic?
What does "dmesg
On Thu, Feb 19, 2015 at 11:16:07AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 18, 2015 at 10:17:53PM -0600, Josh Poimboeuf wrote:
> > On Thu, Feb 19, 2015 at 01:20:58AM +0100, Peter Zijlstra wrote:
> > > On Wed, Feb 18, 2015 at 11:12:56AM -0600, Josh Poimboeuf wrote:
>
> > > > The next line of
Back from a HDD crash...
> The "test-for-zero-clock-rate" method I showed in my previous email
> will work for you - and will avoid using this hateful macro while
> still giving the behaviour you desire, and you won't be caring about
> the detail of the clk API implementation either.
The resume
On 19/02/2015 4:55 p.m., David Ahern wrote:
On 2/19/15 12:06 AM, Adrian Hunter wrote:
/* not supported, confirm error related to PERF_FLAG_FD_CLOEXEC */
-fd = sys_perf_event_open(, pid, cpu, -1, 0);
+fd = sys_perf_event_open(, 0, cpu, -1, 0);
I would prefer to avoid pid = 0
On Thu, Feb 19, 2015 at 7:42 AM, Rafael David Tinoco wrote:
>
> Just a quick feedback, We were able to reproduce the lockup with this
> proposed patch (3.19 + patch). Unfortunately we had problems with the
> core file and I have only the stack trace for now but I think we are
> able to reproduce
On Thu, Feb 19, 2015 at 01:42:39PM -0200, Rafael David Tinoco wrote:
> Linus, Peter, Thomas
>
> Just a quick feedback, We were able to reproduce the lockup with this
> proposed patch (3.19 + patch). Unfortunately we had problems with the
> core file and I have only the stack trace for now but I
Hi Rob,
2015-02-15 23:42 GMT+01:00 Rob Herring :
> On Fri, Feb 13, 2015 at 2:42 AM, Maxime Coquelin
> wrote:
>> Hi Geert,
>>
>> 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven :
>>> On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin
>>> wrote:
From Cortex-M4 and M7 reference manuals, the nvic
201 - 300 of 1092 matches
Mail list logo
