A rescue thread exiting TASK_INTERRUPTIBLE can lead to a task scheduling
off, never to be seen again. In the case where this occurred, an exiting
thread hit reiserfs homebrew conditional resched while holding a mutex,
bringing the box to it's knees.
PID: 18105 TASK: 8807fd412180 CPU: 5 C
Hi Bob, Liu Jiang,
About CMA, could you give me more info ?
Thanks for your patent and nice advice. :)
1) I saw the following on http://lwn.net/Articles/447405/:
The "CMA" type is sticky; pages which are marked as being for CMA
should never have their migration type changed by the kernel.
As
These drivers do not need to select PINCONF.
Signed-off-by: Axel Lin
---
This patch was sent on https://lkml.org/lkml/2012/11/12/12.
Resend to Haojian's correct email address.
drivers/pinctrl/Kconfig |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinc
On Tue, Nov 27, 2012 at 02:47:54PM -0800, Andrew Morton wrote:
> On Fri, 23 Nov 2012 01:15:26 +0400
> Cyrill Gorcunov wrote:
>
> > Documentation/filesystems/proc.txt | 81
> > +
>
> Looks good to me. Here's a small tune-up:
Thanks a lot, Andrew!
This makes PINCTRL related config options visible.
Otherwise there is no way to build pinctrl drivers for MMP2, PXA168 and PXA910.
Signed-off-by: Axel Lin
---
This patch was sent on https://lkml.org/lkml/2012/11/12/10
Resend to Haojian's correct email address.
arch/arm/Kconfig |1 +
1 file
On 11/28/2012 12:49 AM, Stephen Hemminger wrote:
On Tue, 27 Nov 2012 14:45:13 +0800
Jason Wang wrote:
On 11/27/2012 01:37 AM, Stephen Hemminger wrote:
On Mon, 26 Nov 2012 15:56:52 +0800
Jason Wang wrote:
Some deivces do not free the old tx skbs immediately after it has been sent
(usually i
If dmaengine driver's .device_alloc_chan_resources() method returns -ENODEV,
dma_request_channel() will decide, that the driver has been removed and will
remove the device from its list. To prevent this use ENXIO if a slave lookup
fails.
Reported-by: Kuninori Morimoto
Signed-off-by: Guennadi Liak
Add driver for support max77686 rtc.
MAX77686 rtc support smpl and wtsr mode. It has two alarm register
which can be used for alarming to wake system up. This drvier uses regmap
to access its register.
Signed-off-by: Chiwoong Byun
Signed-off-by: Jonghwa Lee
Signed-off-by: Myugnjoo Ham
Signed-of
Hi all,
Changes since 20121127:
The ia64 tree lost its conflict.
The powerpc tree still had its build failure for which I applied a patch.
The modules tree still had its build failure so I used the version from
next-20121115.
The mfd tree gained a conflict against Linus' tree.
The pm
Hi Lee,
On Tue, Nov 27, 2012 at 01:13:10PM +, Lee Jones wrote:
> Now we can register the BU21013_ts touch screen when booting with
> Device Tree enabled. Here we parse all the necessary components
> previously expected to be passed from platform data.
I applied these 3 patches, but for DT we
Hi Chen,
If a pageblock's migration type is movable, it may be converted to
reclaimable under memory pressure. CMA is introduced to guarantee
that pages of CMA won't be converted to other migratetypes.
And we are trying to avoid allocating kernel/DMA memory from specific
memory ranges, so we coul
On 11/27/2012 07:34 PM, Andrew Theurer wrote:
On Tue, 2012-11-27 at 16:00 +0530, Raghavendra K T wrote:
On 11/26/2012 07:05 PM, Andrew Jones wrote:
On Mon, Nov 26, 2012 at 05:37:54PM +0530, Raghavendra K T wrote:
From: Peter Zijlstra
In case of undercomitted scenarios, especially in large gu
Hi Sebastian & Co,
On Tue, 2012-11-27 at 16:20 +0100, Sebastian Andrzej Siewior wrote:
> On 11/26/2012 06:54 PM, Michal Nazarewicz wrote:
> > On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
> >> Wouldn't say that. It may adds complexity on another level. The target
> >> subsystem has the sam
On Tue, Nov 27, 2012 at 03:43:05PM -0800, Christopher Heiny wrote:
> On 11/27/2012 01:21 AM, Dmitry Torokhov wrote:
> >To save my old fingers...
> >
> >Signed-off-by: Dmitry Torokhov
> >---
> >
> >It looks like this driver(s) need some love and I might have some time so I
> >will refresh my "synapt
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also implements an API for mapping/unmapping pages for
guest PCI drivers and
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.
The platform dependent part includes IOMMU initialization
and handling. This patch implements an IOMMU driver for VFIO
which does map
Now we have limit kdump reseved under 896M, because kexec has the limitation.
and also bzImage need to stay under 4g.
To make kexec/kdump could use range above 4g, we need to make bzImage and
ramdisk could be loaded above 4g.
During booting bzImage will be unpacked on same postion and stay high.
ext_ramdisk_image/size will record high 32bits for ramdisk info.
xloadflags bit0 will be set if relocatable with 64bit.
Let get_ramdisk_image/size to use ext_ramdisk_image/size to get
right positon for ramdisk.
bootloader will fill value to ext_ramdisk_image/size when it load
ramdisk above 4G.
later will check ext_cmd_line_ptr at the same time.
Signed-off-by: Yinghai Lu
---
arch/x86/boot/compressed/cmdline.c | 10 --
arch/x86/kernel/head64.c | 13 +++--
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/x86/boot/compressed/cmdline.c
b/a
During debug load kernel above 4G, found one page if is not used in BRK
and it should be with early page allocation.
Fix that checking and also add print out for every allocation from BRK
page table allocation.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init.c |4 +++-
1 files changed, 3 ins
When we get x86_64_start_kernel from arch/x86/kernel/head_64.S,
We have
1. kernel highmap 512M (KERNEL_IMAGE_SIZE) from kernel loaded address.
2. kernel lowmap: [0, 1024M), and size (_end - _text) from kernel
loaded address.
for example, if the kernel bzImage is loaded high from 8G, will get:
We are short of space before 0x200 that is entry for startup_64.
According to hpa, we can not change startup_64 to other offset and
that become ABI now.
We could move function verify_cpu down, and that could avoid extra
code of jmp back and forth if we would move other lines.
Signed-off-by: Ying
Now 64bit kernel supports more than 1T ram and kexec tools
could find buffer above 1T, remove that obsolete limitation.
and use MAXMEM instead.
Tested on system more than 1024G ram.
Signed-off-by: Yinghai Lu
Cc: "Eric W. Biederman"
---
arch/x86/include/asm/kexec.h |6 +++---
1 files change
commit 08da5a2ca
x86_64: Early segment setup for VT
add lldt/ltr to clean more segments.
Those code are put in code64, and it is using gdt that is only
loaded from code32 path.
That breaks booting with 64bit bootloader that does not go through
code32 path. It get at startup_64 directly, an
boot/compressed/misc.c could be with 64 bit, and cmd_line_ptr could
above 4g.
So change to unsigned long instead, that will be 64bit in 64bit path
and 32bit in 32bit path.
Signed-off-by: Yinghai Lu
---
arch/x86/boot/boot.h|8
arch/x86/boot/cmdline.c |4 ++--
2 files changed
There several places to find ramdisk information early for reserving
and relocating.
Use functions to make code more readable and consistent.
Later will add ext_ramdisk_image/size in those functions to support
loading ramdisk above 4g.
Signed-off-by: Yinghai Lu
---
arch/x86/kernel/setup.c |
Current when kernel is loaded above 1G, only [_text, _text+2M] is set
up with extra ident page table.
That is not enough, some variables that could be used early are out of
that range, like BRK for early page table.
Need to set map for [_text, _end] include text/data/bss/brk...
Also current kernel
cmdline.c::__cmdline_find_option... are shared between
16-bit setup code and 32/64 bit decompressor code.
for 32/64 only path via kexec, we should not check if ptr less 1M.
as those cmdline could be put above 1M, or even 4G.
Move out accessible checking out of __cmdline_find_option()
So decompres
When 64bit bootloader put real mode data above 4g, We can not
access real mode data directly yet.
because in arch/x86/kernel/head_64.S, only set ident mapping
for 0-1g, and kernel code/data/bss.
So need to move early_ioremap_init() calling early from setup_arch()
to x86_64_start_kernel().
Also u
They are the same, could move them out from head32/64.c to setup.c.
We are using memblock, and it could handle overlapping properly, so
we don't need to reserve some at first to hold the location, and just
need to make sure we reserve them before we are using memblock to find
free mem to use.
Sig
601 - 630 of 630 matches
Mail list logo
