On Fri, Jun 27, 2014 at 1:10 AM, Russell King - ARM Linux
wrote:
> On Thu, Jun 26, 2014 at 11:53:20PM +0900, Alexandre Courbot wrote:
>> We don't plan to rely on CMA for too long. IOMMU support is on the way
>> and should make our life easier, although no matter the source of
>> memory, we will
On Thu, Jun 26, 2014 at 02:41:17PM -0700, Andrew Morton wrote:
> On Tue, 24 Jun 2014 03:05:54 +0200 "Luis R. Rodriguez"
> wrote:
>
> > > > Ah, because its cpu_extra, not total_cpu_space that is being
> > > > computed, the goal was to see how much extra junk on the
> > > > worst case a CPU might
On Thu, Jun 26, 2014 at 3:58 PM, Dave Hansen wrote:
> On 06/26/2014 03:19 PM, Andy Lutomirski wrote:
>> On Wed, Jun 25, 2014 at 2:45 PM, Dave Hansen wrote:
>>> On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
Hmm. the memfd_create thing may be able to do this for you. If you
created a
On 27/06/2014 00:56, Rob Herring wrote:
> On Thu, Jun 26, 2014 at 5:43 PM, Gregory CLEMENT
> wrote:
>> Hello,
>>
>> Following the feedback I go on the patch "ARM: mvebu: Enable SCU
>> Speculative linefills to L2 for Armada 375/38x" :
>>
On 06/26/2014 03:19 PM, Andy Lutomirski wrote:
> On Wed, Jun 25, 2014 at 2:45 PM, Dave Hansen wrote:
>> On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
>>> Hmm. the memfd_create thing may be able to do this for you. If you
>>> created a per-mm memfd and mapped it, it all just might work.
>>
>>
On Thu, Jun 26, 2014 at 5:43 PM, Gregory CLEMENT
wrote:
> Hello,
>
> Following the feedback I go on the patch "ARM: mvebu: Enable SCU
> Speculative linefills to L2 for Armada 375/38x" :
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/335961/focus=335993
>
> I take the opportunity of adding
On 27/06/2014 00:43, Gregory CLEMENT wrote:
> The first bit of the SCU control register is actually the enable
> it. So let's name it instead of using literal constant.
>
> Signed-off-by: Gregory CLEMENT
> ---
> arch/arm/kernel/smp_scu.c | 10 ++
> 1 file changed, 6 insertions(+), 4
Signed-off-by: Alexey Khoroshilov
---
drivers/net/wireless/rsi/rsi_91x_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c
b/drivers/net/wireless/rsi/rsi_91x_usb.c
index 4c46e5631e2f..2e0254606e3d 100644
---
The patch fixes a couple of issues:
- absence of deallocation of rsi_dev->rx_usb_urb[0] in the driver;
- potential NULL pointer dereference because of lack of checks for memory
allocation success in rsi_init_usb_interface().
By the way, it makes rsi_probe() returning error code instead of 1
and
This patch got rejected by lkml:
>>> linux-kernel@vger.kernel.org (reading confirmation): 550 5.7.1
>>> Content-Policy reject msg: Wrong MIME labeling on 8-bit character texts.
>>> BF:; S1751405AbaFZWBb
I guess quilt couldn't handle Petr's last name (I changed it to 'a'
here).
-- Steve
On
Peter,
A blast from the past. I'm cleaning out my INBOX and I found this patch
under the rug. I know I had a holiday when it was sent (date is July 4th,
Yay! fireworks).
Anyway, there was no comments to it. What do you think.
I haven't reviewed it much but I have a small comment by doing a
Quoting the ARM datasheet: "When set, SCU CLK is turned off when all
processors are in WFI mode, there is no pending request on the ACP, if
implemented, and there is no remaining activity in the SCU.
When SCU CLK is off, ARREADYS, AWREADYS and WREADYS on the ACP are
forced LOW. The clock is
The first bit of the SCU control register is actually the enable
it. So let's name it instead of using literal constant.
Signed-off-by: Gregory CLEMENT
---
arch/arm/kernel/smp_scu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/smp_scu.c
Hello,
Following the feedback I go on the patch "ARM: mvebu: Enable SCU
Speculative linefills to L2 for Armada 375/38x" :
http://thread.gmane.org/gmane.linux.ports.arm.kernel/335961/focus=335993
I take the opportunity of adding new functions in smp_scu.c to
centralize the other access done on
Quotin the ARM datasheet "When set, coherent linefill requests are
sent speculatively to the L2C-310 in parallel with the tag look-up. If
the tag look-up misses, the confirmed linefill is sent to the L2C-310
and gets RDATA earlier because the data request was already initiated
by the speculative
Enabling the SCU standby is now done in smp_scu.c. We don't need
anymore to manipulate the SCU register outside of this file.
Signed-off-by: Gregory CLEMENT
---
arch/arm/mach-imx/platsmp.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/mach-imx/platsmp.c
From: Nadav Haklai
For Armada 375 and Armada 38x SoCs, enable the SCU Speculative
linefills.
This feature may improve overall system performance.
[Gregory: modify the title of the patch and no more copy the defintion
of the bit here]
[Gregory: use the new function scu_spec_linefills_enable
On Thu, 26 Jun 2014, Austin Schuh wrote:
> On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
> wrote:
> > CC'ing RT folks
> >
> > On Wed, May 21, 2014 at 8:23 AM, Austin Schuh
> > wrote:
> >> On Tue, May 13, 2014 at 7:29 PM, Austin Schuh
> >> wrote:
> >>> Hi,
> >>>
> >>> I am observing a
On Thu, 26 Jun 2014, Himangi Saraogi wrote:
> This patch removes the cast on data of type void* as it is not needed.
> The following Coccinelle semantic patch was used for making the change:
>
> @r@
> expression x;
> void* e;
> type T;
> identifier f;
> @@
>
> (
> *((T *)e)
> |
> ((T
On Wed, Jun 25, 2014 at 2:45 PM, Dave Hansen wrote:
> On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
>> Hmm. the memfd_create thing may be able to do this for you. If you
>> created a per-mm memfd and mapped it, it all just might work.
>
> memfd_create() seems to bring a fair amount of baggage
On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
> Hmm. the memfd_create thing may be able to do this for you. If you
> created a per-mm memfd and mapped it, it all just might work.
memfd_create() seems to bring a fair amount of baggage along (the fd
part :) if all we want is a marker. Really,
On Thu, Jun 26, 2014 at 12:37 AM, Tomeu Vizoso
wrote:
> On 25 June 2014 20:23, Mike Turquette wrote:
>>
>> Peter,
>>
>> Just FYI, I'm trying to reverse the trend of prepending double
>> underscores for functions that are used by clock providers. That stuff
>> started out small and sort of grew
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Wednesday, 25 June, 2014 11:51 PM
> To: Christoph Hellwig; James Bottomley
> Cc: Bart Van Assche; Elliott, Robert (Server Storage); linux-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: scsi-mq
On Wed, Jun 25, 2014 at 12:02:25PM -0700, Stephen Boyd wrote:
> I don't think this driver should be using regulator_get_optional() (Mark
> B. please correct me if I'm wrong). I doubt a supply is actually
> optional for CPUs, just some DTs aren't specifying them. In those cases,
> the regulator
This is version 2:
This is my proposal to print the NMI stack traces from an RCU stall safely.
Here's the gist of it.
Patch 1: add trace_seq_buffer_ptr() helper function to clean up
open coded trace_seq code. This is already in my 3.17 queue.
Patch 2: Add a new layer to trace_seq called
From: "Steven Rostedt (Red Hat)"
The seq_buf functions are rather useful outside of tracing. Instead
of having it be dependent on CONFIG_TRACING, move the code into lib/
and allow other users to have access to it even when tracing is not
configured.
The seq_buf utility is similar to the
From: "Steven Rostedt (Red Hat)"
Create a seq_buf layer that trace_seq sits on. The seq_buf will not
be limited to page size. This will allow other usages of seq_buf
instead of a hard set PAGE_SIZE one that trace_seq has.
Signed-off-by: Steven Rostedt
---
include/linux/seq_buf.h
From: "Steven Rostedt (Red Hat)"
There's several locations in the kernel that open code the calculation
of the next location in the trace_seq buffer. This is usually done with
p->buffer + p->len
Instead of having this open coded, supply a helper function in the
header to do it for them. This
From: "Steven Rostedt (Red Hat)"
Being able to divert printk to call another function besides the normal
logging is useful for such things like NMI handling. If some functions
are to be called from NMI that does printk() it is possible to lock up
the box if the nmi handler triggers when another
Hi,
Add support for memory errors for the Intel E3-1200 DRAM controllers.
While testing the driver, I found that doing a readq() on the
memory mapped memory controller hub registers caused a hard lockup
on my x86_64 system. It turns out that a read across a DW boundary
is a no no here.
"
Add 'ie31200_edac' driver for the E3-1200 series of Intel DRAM controllers.
Driver is based on the following E3-1200 specs:
http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html
Convert to the generic API.
Signed-off-by: Jason Baron
---
drivers/edac/x38_edac.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/x38_edac.c b/drivers/edac/x38_edac.c
index 4891b45..e644b52 100644
--- a/drivers/edac/x38_edac.c
+++
Even on x86-64, I've found the need to break up a readq() into 2 readl()
calls. According to the Intel datasheet for the E3-1200 processor:
"
Software must not access B0/D0/F0 32-bit memory-mapped registers with
requests that cross a DW boundary.
"
On Thu, 26 Jun 2014, Chen Gang wrote:
> 'COUNTER' and other same kind macros are too common to use, and easy to
> get conflict with other modules.
>
> At present, they are not used, so it is OK to simply remove them. And the
> related warning (allmodconfig with score):
>
> CC [M]
After the switch to the MMC core regulator infrastucture, we already
have a local "mmc" pointer in various functions. There is no longer a
need to access the data structure via host->mmc.
Signed-off-by: Markus Mayer
Reviewed-by: Matt Porter
---
This patch was posted before as part 2/2 of a
On Thu, 26 Jun 2014 14:33:56 -0600 Shuah Khan wrote:
> On some systems, hotplug tests could hang forever waiting for cpu and
> memory to be ready to be offlined. A special hotplug target is created,
> which will help run non-hotplug tests and run hotplug tests as a special
> case. Individual
On Tue, 24 Jun 2014 03:05:54 +0200 "Luis R. Rodriguez" wrote:
> > > Ah, because its cpu_extra, not total_cpu_space that is being
> > > computed, the goal was to see how much extra junk on the
> > > worst case a CPU might contribute. The __LOG_BUF_LEN is the
> > > default size, so we combine
On Thu, 26 Jun 2014 13:44:12 +0200 Sebastien Buisson
wrote:
>
> Le 26/06/2014 00:16, Andrew Morton a __crit :
> > On Tue, 24 Jun 2014 17:52:00 +0200 Sebastien Buisson
> > wrote:
> >
> >> Allow increasing the buffer-head per-CPU LRU size to allow efficient
> >> filesystem operations that
Quoting Peter De Schrijver (2014-06-26 09:39:06)
> On Fri, Jun 13, 2014 at 10:02:39AM +0200, Peter De Schrijver wrote:
> > On Fri, May 30, 2014 at 05:03:57PM +0200, Peter De Schrijver wrote:
> > > This patch flattens the clk tree in CCF debugfs. Instead of representing
> > > the
> > > clocks and
> 3. unblank & disable blanking on any oops? (probably problematic)
We already try to do that.
Alan
--
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
On 06/25/14 17:43, Thomas Gleixner wrote:
The kthread park/unpark logic has the following issue:
Task CPU 0CPU 1
T1 unplug cpu1
kthread_park(T2)
set_bit(KTHREAD_SHOULD_PARK);
wait_for_completion()
T2
On Thu, Jun 26, 2014 at 01:58:11PM -0700, Andrew Morton wrote:
> Well, this is an absolute ton of new code, much of it pretty complex.
> And I believe the entire point of this work is to enable image
> signature checking, but that hasn't been implemented yet?
>
> In which case I'm thinking it
Hi all
We have a couple Ubuntu 10.04 hosts with kernel version 3.14.5 which
are experiencing TCP payload corruption when using IPSec in NAT-T
transport mode. All are running under Xen at third party providers.
When communicating with other hosts using IPSec, we see that these
corrupt TCP PDUs are
This patch adds DMA capabilities to the spi-qup driver. If DMA channels are
present, the QUP will use DMA instead of block mode for transfers to/from SPI
peripherals for transactions larger than the length of a block.
Signed-off-by: Andy Gross
---
.../devicetree/bindings/spi/qcom,spi-qup.txt
From: Stanislav Fomichev
This patch adds optional pagefault tracing support to 'perf trace'.
Using -F/--pf option user can specify whether he wants minor, major or
all pagefault events to be traced. This patch adds only live mode,
record and replace will come in a separate patch.
Example
On Thu, Jun 26, 2014 at 1:43 PM, Vivek Goyal wrote:
> On Thu, Jun 26, 2014 at 04:33:37PM -0400, Vivek Goyal wrote:
>> This is the new syscall kexec_file_load() declaration/interface. I have
>> reserved the syscall number only for x86_64 so far. Other architectures
>> (including i386) can reserve
From: Stanislav Fomichev
It will be used by next pagefault tracing patches in the series.
Signed-off-by: Stanislav Fomichev
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
From: Stanislav Fomichev
Previous commit added live pagefault trace support, this one adds record
and replay support.
Example:
[root@zoo /]# echo 1 > /proc/sys/vm/drop_caches ; trace -F all record -a
sleep 10
[ perf record: Woken up 0 times to write data ]
[ perf record: Captured and
From: Daniel Bristot de Oliveira
Older kernels (e.g., RHEL6) do system call tracing via the
syscalls:sys_{enter,exit} tracepoints rather than using raw_syscalls:*.
Update perf python and perl scripts to fallback to syscalls:* when
raw_syscalls:* isn't available.
Signed-off-by: Daniel Bristot
From: Stanislav Fomichev
Currently, we may either trace syscalls or syscalls+pagefaults.
We'd like to be able to trace *only* pagefaults and this commit
implements this feature.
Example:
[root@zoo /]# echo 1 > /proc/sys/vm/drop_caches ; trace --no-syscalls -F -p
`pidof xchat`
0.000
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit 1c92f88542faa3ae4f970c548b4fe8275a45201b:
Merge tag 'perf-core-for-mingo' of
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf into perf/core
(2014-06-25 07:44:19 +0200)
are available in the git
> -Original Message-
> From: KY Srinivasan
> > -Original Message-
> > From: Yue Zhang [mailto:yue...@microsoft.com]
> > hv_fcopy_daemon fails to overwrite a file if the target file already exits.
> >
> > Add O_TRUNC flag on opening.
> >
> > Signed-off-by: Yue Zhang
> > ---
> >
On Thu, 26 Jun 2014 16:33:38 -0400 Vivek Goyal wrote:
> Previous patch provided the interface definition and this patch prvides
> implementation of new syscall.
>
> Previously segment list was prepared in user space. Now user space just
> passes kernel fd, initrd fd and command line and kernel
On Thu, 26 Jun 2014 16:33:29 -0400 Vivek Goyal wrote:
> This patch series does not do kernel signature verification yet. I plan
> to post another patch series for that. Now distributions are already signing
> PE/COFF bzImage with PKCS7 signature I plan to parse and verify those
> signatures.
>
On Thursday 26 June 2014 21:48:54 zhangfei wrote:
>
> On 06/25/2014 09:32 PM, Arnd Bergmann wrote:
> > On Wednesday 25 June 2014 20:41:26 zhangfei wrote:
> >> On 06/25/2014 08:16 PM, Arnd Bergmann wrote:
> >>> On Wednesday 25 June 2014, Zhangfei Gao wrote:
> From: Jiancheng Xue
>
>
From: Thierry Reding
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed here:
https://lkml.org/lkml/2014/4/27/346
From: Thierry Reding
This series adds support for the IOMMU found on Tegra124 SoCs. The SMMU
groups memory clients into SWGROUPs and each SWGROUP can be assigned to
one I/O virtual address space. Translation of virtual addresses can be
enabled per memory client.
Patch 1 adds an IOMMU device
From: Thierry Reding
Add the memory controller and wire up the interrupt that is used to
report errors. Also add an #iommu-cells property to make the device
as an IOMMU.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra124.dtsi | 9 +
1 file changed, 9 insertions(+)
diff
From: Thierry Reding
The memory controller on NVIDIA Tegra124 exposes various knobs that can
be used to tune the behaviour of the clients attached to it.
Currently this driver sets up the latency allowance registers to the HW
defaults. Eventually an API should be exported by this driver (via a
From: Thierry Reding
This enables IOMMU interoperation with the DMA mapping API so that
clients that use the DMA mapping API can seemlessly make use of an
existing IOMMU.
Signed-off-by: Thierry Reding
---
arch/arm/mach-tegra/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Thierry Reding
Add an iommus property to each of the display controllers and encode the
SWGROUP in the specifier.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra124.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi
From: Thierry Reding
The memory controller on NVIDIA Tegra124 exposes various knobs that can
be used to tune the behaviour of the clients attached to it.
In addition, the memory controller implements an SMMU (IOMMU) which can
translate I/O virtual addresses to physical addresses for clients.
From: Thierry Reding
The SDMMC controllers can use the IOMMU to avoid the need for bounce
buffers.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra124.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index
On Thu 2014-06-26 22:30:52, Pavel Machek wrote:
> Hi!
>
> > Ok, this ext4 filesystem does _not_ have easy life: it is in usb envelope,
> > I wanted
> > to use it as a root filesystem, and it is connected to OLPC-1.75, running
> > some kind
> > of linux-3.0 kernels.
> >
> > So power disconnects
From: Thierry Reding
When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display controllers to it. The display controllers
can then scan out non-contiguous buffers by mapping them through the
IOMMU.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
Add an IOMMU device registry for drivers to register with and implement
a method for users of the IOMMU API to attach to an IOMMU device. This
allows to support deferred probing and gives the IOMMU API a convenient
hook to perform early initialization of a device if
From: Thierry Reding
Attach to the device's master interface of the IOMMU at .probe() time.
IOMMU support becomes available via the DMA mapping API interoperation
code, but this explicit attachment is necessary to ensure proper probe
order.
Signed-off-by: Thierry Reding
---
On Thu, Jun 26, 2014 at 1:12 PM, H. Peter Anvin wrote:
> The real question is if we care that sysret and iter don't match. On 32 bits
> the situation is even more complex.
At least for 64 bits, iret vs sysret is purely a kernel implementation
detail (except where a tracer modifies things that
> -Original Message-
> From: Yue Zhang [mailto:yue...@microsoft.com]
> Sent: Thursday, June 26, 2014 2:09 PM
> To: KY Srinivasan; Haiyang Zhang; driverdev-de...@linuxdriverproject.org;
> linux-kernel@vger.kernel.org; o...@aepfle.de; jasow...@redhat.com;
> a...@canonical.com
> Cc: Dexuan
On Thu, Jun 26, 2014 at 04:33:37PM -0400, Vivek Goyal wrote:
> This is the new syscall kexec_file_load() declaration/interface. I have
> reserved the syscall number only for x86_64 so far. Other architectures
> (including i386) can reserve syscall number when they enable the support
> for this new
This patch fixes the error detection limits for the used
eccsize of the 1, 4 and 8 bit eccmode.
Signed-off-by: Michael Grzeschik
---
drivers/mtd/nand/mxc_nand.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/mxc_nand.c
The current approach of the read_page function is to iterate over all
subpages and call the correct_data function. The correct_data function
currently does the same. It iterates over all subpages and checks for
correctable and uncorrectable data. This redundant call for each
subpage leads to
On Thu, Jun 26, 2014 at 03:09:13PM -0400, Greg Kroah-Hartman wrote:
> On Tue, Jun 24, 2014 at 04:31:00PM -0700, Guenter Roeck wrote:
> > On 06/24/2014 08:50 AM, Greg Kroah-Hartman wrote:
> > >This is the start of the stable review cycle for the 3.15.2 release.
> > >There are 61 patches in this
On Thu, Jun 26, 2014 at 04:33:29PM -0400, Vivek Goyal wrote:
> Hi,
>
> This is V4 of the patchset. Previous versions were posted here.
>
> V1: https://lkml.org/lkml/2013/11/20/540
> V2: https://lkml.org/lkml/2014/1/27/331
> V3: https://lkml.org/lkml/2014/6/3/432
>
I used following kexec-tools
Previously do_kimage_alloc() will allocate a kimage structure, copy
segment list from user space and then do the segment list sanity verification.
Break down this function in 3 parts. do_kimage_alloc_init() to do actual
allocation and basic initialization of kimage structure.
So far kexec_segment->buf was always a user space pointer as user space
passed the array of kexec_segment structures and kernel copied it.
But with new system call, list of kexec segments will be prepared by
kernel and kexec_segment->buf will point to a kernel memory.
So while I was adding code
Load purgatory code in RAM and relocate it based on the location. Relocation
code has been inspired by module relocation code and purgatory relocation
code in kexec-tools.
Also compute the checksums of loaded kexec segments and store them in
purgatory.
Arch independent code provides this
kimage_normal_alloc() and kimage_crash_alloc() are doing lot of similar
things and differ only little. So instead of having two separate functions
create a common function kimage_alloc_init() and pass it the "flags"
argument which tells whether it is normal kexec or kexec_on_panic. And
this
currently bin2c builds only if CONFIG_IKCONFIG=y. But bin2c will now be
used by kexec too. So make it compilation dependent on CONFIG_BUILD_BIN2C
and this config option can be selected by CONFIG_KEXEC and CONFIG_IKCONFIG.
Signed-off-by: Vivek Goyal
---
arch/x86/Kconfig | 1 +
This is loader specific code which can load bzImage and set it up for
64bit entry. This does not take care of 32bit entry or real mode entry.
32bit mode entry can be implemented if somebody needs it.
Signed-off-by: Vivek Goyal
---
arch/x86/include/asm/kexec-bzimage64.h | 6 +
Previous patch provided the interface definition and this patch prvides
implementation of new syscall.
Previously segment list was prepared in user space. Now user space just
passes kernel fd, initrd fd and command line and kernel will create a
segment list internally.
This patch contains
Create a stand alone relocatable object purgatory which runs between two
kernels. This name, concept and some code has been taken from kexec-tools.
Idea is that this code runs after a crash and it runs in minimal environment.
So keep it separate from rest of the kernel and in long term we will
Next two patches provide code for purgatory. This is a code which does
not link against the kernel and runs stand alone. This code runs between
two kernels. One of the primary purpose of this code is to verify the
digest of newly loaded kernel and making sure it matches the digest
computed at
Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
panic because the notification work is done in a workqueue, and in panic() the
kernel typically ends up in an infinite loop, and a typical kernel config has
CONFIG_PREEMPT_VOLUNTARY=y and CONFIG_PREEMPT is not set, so a
I have added two more functions to walk through resources.
Currently walk_system_ram_range() deals with pfn and /proc/iomem can contain
partial pages. By dealing in pfn, callback function loses the info that
last page of a memory range is a partial page and not the full page. So
I implemented
This is the new syscall kexec_file_load() declaration/interface. I have
reserved the syscall number only for x86_64 so far. Other architectures
(including i386) can reserve syscall number when they enable the support
for this new syscall.
Signed-off-by: Vivek Goyal
CC: linux-...@vger.kernel.org
This patch adds support for loading a kexec on panic (kdump) kernel usning
new system call.
It prepares ELF headers for memory areas to be dumped and for saved cpu
registers. Also prepares the memory map for second kernel and limits its
boot to reserved areas only.
Signed-off-by: Vivek Goyal
Let's use the more common "unusable".
This patch was originally written and posted by Boris. I am including it
in this patch series.
Signed-off-by: Borislav Petkov
---
include/linux/kexec.h | 2 +-
kernel/kexec.c| 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
Kexec wants to use bin2c and it wants to use it really early in the build
process. See arch/x86/purgatory/ code in later patches.
So move bin2c in scripts/basic so that it can be built very early and
be usable by arch/x86/purgatory/
Signed-off-by: Vivek Goyal
---
kernel/Makefile | 2
Hi,
This is V4 of the patchset. Previous versions were posted here.
V1: https://lkml.org/lkml/2013/11/20/540
V2: https://lkml.org/lkml/2014/1/27/331
V3: https://lkml.org/lkml/2014/6/3/432
Changes since v3:
- Took care of most of the review comments from V3.
- Stopped building purgatory for
This patch does two thigns. It passes EFI run time mappings to second
kernel in bootparams efi_info. Second kernel parse this info and create
new mappings in second kernel. That means mappings in first and second
kernel will be same. This paves the way to enable EFI in kexec kernel.
This patch
On some systems, hotplug tests could hang forever waiting for cpu and
memory to be ready to be offlined. A special hotplug target is created,
which will help run non-hotplug tests and run hotplug tests as a special
case. Individual hotplug tests can still be run as a special target
targeted for a
> > >> MS-TFS: 157532
> >
> > > What is this line for?
> >
> > Hi Greg,
> > This line is for our internal bug repository.
> > We have an automated system to correlate bugs with fixes so that our test
> > team knows when a bug fix has been accepted upstream and they need to
> > write a new test
Hi!
> Ok, this ext4 filesystem does _not_ have easy life: it is in usb envelope, I
> wanted
> to use it as a root filesystem, and it is connected to OLPC-1.75, running
> some kind
> of linux-3.0 kernels.
>
> So power disconnects are common, and even during regular reboot, I hear disk
> doing
Add device tree binding support for the QCOM ADM DMA driver.
Signed-off-by: Andy Gross
---
Documentation/devicetree/bindings/dma/qcom_adm.txt | 60
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_adm.txt
diff --git
This patch set introduces the dmaengine driver for the Qualcomm Application
Data Mover (ADM) DMA controller present on MSM8960, APQ8064, and IPQ8064
devices.
The initial version of this driver will only support slave DMA operations
between system memory and peripherals. Flow control via the CRCI
Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA
controller found in the MSM8960 and IPQ/APQ8064 platforms.
The ADM supports both memory to memory transactions and memory
to/from peripheral device transactions. The controller also provides flow
control capabilities for
On 06/26/2014 04:00 PM, Rafael Aquini wrote:
> Historically, we exported shared pages to userspace via sysinfo(2) sharedram
> and /proc/meminfo's "MemShared" fields. With the advent of tmpfs, from kernel
> v2.4 onward, that old way for accounting shared mem was deemed inaccurate and
> we started
Hi!
Ok, this ext4 filesystem does _not_ have easy life: it is in usb envelope, I
wanted
to use it as a root filesystem, and it is connected to OLPC-1.75, running some
kind
of linux-3.0 kernels.
So power disconnects are common, and even during regular reboot, I hear disk
doing
emergency
From: Yue Zhang
hv_fcopy_daemon fails to overwrite a file if the target file already
exits.
Add O_TRUNC flag on opening.
Signed-off-by: Yue Zhang
---
tools/hv/hv_fcopy_daemon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/hv/hv_fcopy_daemon.c
101 - 200 of 1288 matches
Mail list logo
