make another one handling all.
Signed-off-by: Xunlei Pang
---
kexec/arch/x86_64/kexec-bzImage64.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kexec/arch/x86_64/kexec-bzImage64.c
b/kexec/arch/x86_64/kexec-bzImage64.c
index 8edb3e4..929f7af 100644
--- a/kexec/arch
Move the stuff currently only used by the kexec file code within
CONFIG_KEXEC_FILE (and CONFIG_KEXEC_VERIFY_SIG).
Also move internal "struct kexec_sha_region" and "struct kexec_buf"
into "kexec_internal.h".
Signed-off-by: Xunlei Pang
---
arch/x86/kernel/machi
On 12/22/2015 at 06:47 PM, Minfei Huang wrote:
> On 12/21/15 at 02:09pm, Xunlei Pang wrote:
>> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
>> index 7b68d27..2cc643c 100644
>> --- a/include/linux/kexec.h
>> +++ b/include/linux/kexec.h
>
architecture can make its specific implementation by overriding
arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres().
Signed-off-by: Xunlei Pang
---
include/linux/kexec.h | 2 ++
kernel/kexec.c| 9 -
kernel/kexec_core.c | 6 ++
kernel/kexec_file.c | 8 +++-
4
Implement the protection method for the crash kernel memory
reservation for the 64-bit x86 kdump.
Signed-off-by: Xunlei Pang
---
Only provided x86_64 implementation, as I've only tested on x86_64 so far.
arch/x86/kernel/machine_kexec_64.c | 43 ++
1
On 12/24/2015 at 01:54 PM, Dave Young wrote:
> Ccing Vivek
>
> On 12/23/15 at 07:12pm, Xunlei Pang wrote:
>> Implement the protection method for the crash kernel memory
>> reservation for the 64-bit x86 kdump.
>>
>> Signed-off-by: Xunlei Pang
>> ---
>>
On 12/24/2015 at 02:16 PM, Dave Young wrote:
> Hi, Xunlei
>
> On 12/24/15 at 02:05pm, Xunlei Pang wrote:
>> On 12/24/2015 at 01:54 PM, Dave Young wrote:
>>> Ccing Vivek
>>>
>>> On 12/23/15 at 07:12pm, Xunlei Pang wrote:
>>>> Imple
On 12/26/2015 at 11:21 PM, Minfei Huang wrote:
> On 12/23/15 at 07:12pm, Xunlei Pang wrote:
>> Implement the protection method for the crash kernel memory
>> reservation for the 64-bit x86 kdump.
>>
>> Signed-off-by: Xunlei Pang
>> ---
>> Only provided x86
On 12/24/2015 at 02:44 PM, Xunlei Pang wrote:
> On 12/24/2015 at 02:16 PM, Dave Young wrote:
>> Hi, Xunlei
>>
>> On 12/24/15 at 02:05pm, Xunlei Pang wrote:
>>> On 12/24/2015 at 01:54 PM, Dave Young wrote:
>>>> Ccing Vivek
>>>>
>>>&
On 12/28/2015 at 08:14 PM, Minfei Huang wrote:
> On 12/28/15 at 02:32pm, Xunlei Pang wrote:
>> On 12/24/2015 at 02:44 PM, Xunlei Pang wrote:
>>>>>>> +static void kexec_mark_crashkres(bool protect)
>>>>>>> +{
>>>>>>> +
Implement the protection method for the crash kernel memory
reservation for the 64-bit x86 kdump.
Signed-off-by: Xunlei Pang
---
arch/x86/kernel/machine_kexec_64.c | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/x86/kernel/machine_kexec_64.c
b
architecture can make its specific implementation by overriding
arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres().
Signed-off-by: Xunlei Pang
---
include/linux/kexec.h | 2 ++
kernel/kexec.c| 9 -
kernel/kexec_core.c | 6 ++
kernel/kexec_file.c | 8 +++-
4
On 01/07/2016 at 01:08 AM, Minfei Huang wrote:
> On 01/06/16 at 05:50pm, Xunlei Pang wrote:
>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>> b/arch/x86/kernel/machine_kexec_64.c
>> index 819ab3f..cda867d 100644
>> --- a/arch/x86/kernel/machine_kexec_64
On 01/07/2016 at 10:14 AM, Xunlei Pang wrote:
> On 01/07/2016 at 01:08 AM, Minfei Huang wrote:
>> On 01/06/16 at 05:50pm, Xunlei Pang wrote:
>>> diff --git a/arch/x86/kernel/machine_kexec_64.c
>>> b/arch/x86/kernel/machine_kexec_64.c
>>> index 819ab3f..cda8
On 01/07/2016 at 10:36 AM, Minfei Huang wrote:
> On 01/07/16 at 10:14am, Xunlei Pang wrote:
>>>> +static int
>>>> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
>>>> +{
>>>> + struct page *page;
>>>> + unsi
Implement the protection method for the crash kernel memory
reservation for the 64-bit x86 kdump.
Signed-off-by: Xunlei Pang
---
v2->v3:
1) Make kexec_mark_range() more robust.
2) In kexec_mark_crashkres(), use Macro KEXEC_CONTROL_PAGE_SIZE
instead of 2*PAGE_SIZE
arch/x86/ker
architecture can make its specific implementation by overriding
arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres().
Signed-off-by: Xunlei Pang
---
v2->v3:
No changes.
include/linux/kexec.h | 2 ++
kernel/kexec.c| 9 -
kernel/kexec_core.c | 6 ++
ker
On 01/08/2016 at 04:47 PM, Minfei Huang wrote:
> On 01/08/16 at 10:33am, Xunlei Pang wrote:
>> +
>> +static int
>> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
>> +{
>> +struct page *page;
>> +unsigned int nr_pages;
>>
architecture can make its specific implementation by overriding
arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres().
Signed-off-by: Xunlei Pang
---
v3->v4:
No changes.
include/linux/kexec.h | 2 ++
kernel/kexec.c| 9 -
kernel/kexec_core.c | 6 ++
ker
Implement the protection method for the crash kernel memory
reservation for the 64-bit x86 kdump.
Signed-off-by: Xunlei Pang
---
v3->v4:
Add some comments according to Minfei's suggestion.
arch/x86/kernel/machine_kexec_64.c | 45 ++
1 file cha
On 2016/01/27 at 19:48, Dmitry Safonov wrote:
> For allocation of kimage failure or kexec_prepare or load segments
> errors there is no need to keep crashkernel memory mapped.
> It will affect only s390 as map/unmap hook defined only for it.
> As on unmap s390 also changes os_info structure let's c
On 2016/01/28 at 18:32, Michael Holzheu wrote:
> On Wed, 27 Jan 2016 11:15:46 -0800
> Andrew Morton wrote:
>
>> On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov
>> wrote:
>>
>>> For allocation of kimage failure or kexec_prepare or load segments
>>> errors there is no need to keep crashkernel me
On 2016/01/28 at 20:44, Michael Holzheu wrote:
> On Thu, 28 Jan 2016 19:56:56 +0800
> Xunlei Pang wrote:
>
>> On 2016/01/28 at 18:32, Michael Holzheu wrote:
>>> On Wed, 27 Jan 2016 11:15:46 -0800
>>> Andrew Morton wrote:
>>>
>>>> On Wed,
On 2016/01/28 at 17:02, Dmitry Safonov wrote:
> On 01/28/2016 05:58 AM, Xunlei Pang wrote:
>> Hi Dmitry,
>>
>> On 2016/01/28 at 03:15, Andrew Morton wrote:
>>> On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov
>>> wrote:
>>>
>>>&g
This is a bug fix.
After this, I will try to do a cleanup for crash_unmap/map_reserved_pages()
(only used by S390) to consolidate it with
arch_kexec_unprotect/protect_crashkres().
Regards,
Xunlei
On 03/01/2016 at 04:02 PM, Minfei Huang wrote:
> v1:
> - Bisect the patch according to Andrew Morto
On 03/02/2016 at 10:58 PM, Joerg Roedel wrote:
> On Wed, Mar 02, 2016 at 06:02:28PM +0800, Xunlei Pang wrote:
>> Currently, the kernel copies the old irt entries during iommu
>> initialization for kdump, so old vectors in the first kernel are
>> used but having no related ke
On 2016/03/12 at 12:49, Dave Young wrote:
> Hi, Andrew
>
> On 03/11/16 at 12:27pm, Andrew Morton wrote:
>> On Fri, 11 Mar 2016 16:42:48 +0800 Dave Young wrote:
>>
>>> On i686 PAE enabled machine the contiguous physical area could be large
>>> and it can cause trimming down variables in below calcu
On 2016/03/12 at 21:59, Baoquan He wrote:
> On 03/12/16 at 08:43pm, Xunlei Pang wrote:
>> On 2016/03/12 at 12:49, Dave Young wrote:
>>> Hi, Andrew
>>>
>>> On 03/11/16 at 12:27pm, Andrew Morton wrote:
>>>> On Fri, 11 Mar 2016 16:42:48 +0800 Dave Youn
On 2016/03/23 at 10:48, Baoquan He wrote:
> On 03/01/16 at 05:53pm, Xunlei Pang wrote:
>> This is a bug fix.
>>
>> After this, I will try to do a cleanup for crash_unmap/map_reserved_pages()
>> (only used by S390) to consolidate it with
>> arch_kexec_unprotect
On 2016/03/23 at 16:23, Baoquan He wrote:
> On 03/23/16 at 11:32am, Xunlei Pang wrote:
>> On 2016/03/23 at 10:48, Baoquan He wrote:
>>> On 03/01/16 at 05:53pm, Xunlei Pang wrote:
>>>> This is a bug fix.
>>>>
>>>> After this, I will
On 2016/03/23 at 20:32, Baoquan He wrote:
> On 03/23/16 at 05:59pm, Xunlei Pang wrote:
>> On 2016/03/23 at 16:23, Baoquan He wrote:
>>> On 03/23/16 at 11:32am, Xunlei Pang wrote:
>>>> On 2016/03/23 at 10:48, Baoquan He wrote:
>>>>> On 03/01/16 at 05:
d0)
([<0063067c>] system_call+0x244/0x264)
Cc: Michael Holzheu
Signed-off-by: Xunlei Pang
---
Tested kexec/kdump on S390x
arch/s390/kernel/machine_kexec.c | 86 ++--
arch/s390/kernel/setup.c | 7 ++--
include/linux/kexec.h
On 2016/03/30 at 20:30, Baoquan He wrote:
> Hi Xunlei,
>
> I have two questions.
>
> One is do we still need Minfei's patch if this patch is applied since
> you have completely delete crash_map/unmap_reserved_pages in
> kernel/kexec.c ?
>
> On 03/30/16 at 07:47
ap/unmap_reserved_pages() and
arch_kexec_protect(unprotect)_crashkres()
[Patch03(x86_64)] kexec: provide arch_kexec_protect(unprotect)_crashkres()
I don't know if it is possible to reorder that since they are already in
"linux-next", ask Andrew for help :-)
Regards,
Xunlei
>&
On 2016/04/02 at 01:41, Michael Holzheu wrote:
> Hello Xunlei again,
>
> Some initial comments below...
>
> On Wed, 30 Mar 2016 19:47:21 +0800
> Xunlei Pang wrote:
>
>> Commit 3f625002581b ("kexec: introduce a protection mechanism
>> for the crashkernel re
On 2016/04/04 at 22:58, Michael Holzheu wrote:
> Hello Xunlei,
>
> On Sat, 2 Apr 2016 09:23:50 +0800
> Xunlei Pang wrote:
>
>> On 2016/04/02 at 01:41, Michael Holzheu wrote:
>>> Hello Xunlei again,
>>>
>>> Some initial comments below...
>>&g
mory to be mapped
initially, so get rid of S390 crash kernel memblock removal
in reserve_crashkernel(). Once kdump kernel is loaded, the
new arch_kexec_protect_crashkres() implemented for S390 will
actually unmap the pgtable like before.
Cc: Heiko Carstens
Signed-off-by: Xunlei Pang
Signed-off-b
On 2016/04/05 at 17:13, Michael Holzheu wrote:
> Hello Xunlei,
>
> On Tue, 5 Apr 2016 15:09:59 +0800
> Xunlei Pang wrote:
>> Commit 3f625002581b ("kexec: introduce a protection mechanism
>> for the crashkernel reserved memory") is a similar mechanism
>>
On 2016/03/31 at 11:52, Xunlei Pang wrote:
> Hi Bao,
>
> On 2016/03/31 at 10:52, Baoquan He wrote:
>> On 03/31/16 at 10:43am, Minfei Huang wrote:
>>> On 03/30/16 at 08:30pm, Baoquan He wrote:
>>>> Hi Xunlei,
>>>>
>>>> I have two questio
mory to be mapped
initially, this is done in machine_kdump_pm_init() which is
after reserve_crashkernel(). Once kdump kernel is loaded, the
new arch_kexec_protect_crashkres() implemented for S390 will
actually unmap the pgtable like before.
Acked-by: Michael Holzheu
Cc: Heiko Carstens
Signed-off-
On 2016/07/07 at 18:17, Wei Jiangang wrote:
> If we specify the 'notsc' boot parameter for the dump-capture kernel,
> and then trigger a crash(panic) by using "ALT-SysRq-c" or "echo c >
> /proc/sysrq-trigger",
> the dump-capture kernel will hang in calibrate_delay_converge():
>
> /* wait for "s
On 2016/07/05 at 19:33, Hidehiro Kawai wrote:
> This patch fixes one of the problems reported by Daniel Walker
> (https://lkml.org/lkml/2015/6/24/44).
>
> If crash_kexec_post_notifiers boot option is specified, other CPUs
> are stopped by smp_send_stop() instead of machine_crash_shutdown()
> in cra
On 2016/07/12 at 15:12, 河合英宏 / KAWAI，HIDEHIRO wrote:
>> From: linux-kernel-ow...@vger.kernel.org
>> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Xunlei Pang
>> Sent: Tuesday, July 12, 2016 3:57 PM
>> On 2016/07/12 at 11:56, 河合英宏 / KAWAI，HIDEHIRO wrote:
>&
On 2016/07/12 at 11:56, 河合英宏 / KAWAI，HIDEHIRO wrote:
> Hi Xunlei,
>
> Thanks for the review.
>
>> From: Xunlei Pang [mailto:xp...@redhat.com]
>> Sent: Tuesday, July 12, 2016 12:12 PM
>> On 2016/07/05 at 19:33, Hidehiro Kawai wrote:
>>> This patch fixes one of
On 2016/07/25 at 11:04, Wei, Jiangang wrote:
> Hi He,
>
> Thanks for your response firstly.
>
> On Fri, 2016-07-22 at 18:40 +0800, Baoquan He wrote:
>> Hi Jiangang,
>>
>> This is very nice, should be the stuff Eric and Ingo would like to see.
>> But I have several questions:
>>
>> 1) Are you not go
ays should stay consistent.
Note that write to "/sys/kernel/kexec_crash_size" is to shrink
the reserved memory, and we want to shrink crashk_res only.
So we add some additional check in crash_shrink_memory() since
crashk_low_res now is involved.
Signed-off-by: Xunlei Pang
---
kernel/
On 2016/08/15 at 15:17, Dave Young wrote:
> Hi Xunlei,
>
> On 08/13/16 at 04:26pm, Xunlei Pang wrote:
>> "/sys/kernel/kexec_crash_size" only includes crashk_res, it
>> is fine in most cases, but sometimes we have crashk_low_res.
>> For example, when "
x27;t fail it as a memory violation in these cases.
Thus, we add the case to regard the segment as valid if it is
within crashk_low_res.
Signed-off-by: Xunlei Pang
---
kernel/kexec_core.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/kexec_core.c b/kernel/k
corresponding sysfs file
"/sys/kernel/kexec_crash_low_size" for crashk_low_res.
So, the exact total reserved memory is the sum of the two.
crashk_low_res can also be shrunk via this new interface,
and users should be aware of what they are doing.
Suggested-by: Dave Young
Signed-off-by:
On 2016/08/17 at 15:24, Dave Young wrote:
> Hi, Xunlei,
>
> On 08/17/16 at 09:50am, Xunlei Pang wrote:
>> We have crashk_res only in most cases, but sometimes we have
>> crashk_low_res.
>>
>> For example, on 64-bit x86 systems, when "crashkernel=32M,high"
On 2016/08/18 at 09:50, Zhou Wenjian wrote:
> multi-cpu support is useful to improve the performance of kdump in
> some cases. So add the description of enable multi-cpu support in
> dump-capture kernel.
>
> Signed-off-by: Zhou Wenjian
> Acked-by: Baoquan He
> ---
> Documentation/kdump/kdump.txt
On 2016/08/22 at 18:59, Pratyush Anand wrote:
> On 12/08/2016:07:48:38 PM, Ronit Halder wrote:
>> Currenty linux kernel reserves memory at the boot time for crash kernel.
>> It will be very useful if we can reserve memory in run time. The user can
>> reserve the memory whenerver needed instead of
On 2016/08/24 at 16:20, Dave Young wrote:
> On 08/23/16 at 06:11pm, Yinghai Lu wrote:
>> On Wed, Aug 17, 2016 at 1:20 AM, Dave Young wrote:
>>> On 08/17/16 at 09:50am, Xunlei Pang wrote:
>>>> "/sys/kernel/kexec_crash_size" only handles crashk_res, it
>
PV kernel
>>>
>>> Changes in V3:
>>> - Revise comments, description, and symbol names
>>>
>>> Changes in V2:
>>> - Replace smp_send_stop() call with crash_kexec version which
>>> saves cpu states and cleans up VMX/SVM
>>> - Dr
On 2016/11/12 at 06:21, Sameer Goel wrote:
> On a newer UEFI based Qualcomm target the number of system ram regions
> retrieved from /proc/iomem are ~40. So increasing the current hardcoded
> values to 64 from 16.
I am a little confused, memory regions from /proc/iomem should be
MAX_MEMORY_RANGES
can survive the kdump tests.
CC: Myron Stowe
CC: Don Brace
CC: Baoquan He
CC: Dave Young
Tested-by: Joseph Szczypek
Signed-off-by: Xunlei Pang
---
drivers/iommu/intel-iommu.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers
Ccing David
On 2016/11/16 at 17:02, Xunlei Pang wrote:
> We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
> under kdump, it can be steadily reproduced on several different machines,
> the dmesg log is like:
> HP HPSA Driver (v 3.4.16-0)
> hpsa :02:00.0:
On 2016/11/16 at 22:58, Myron Stowe wrote:
> On Wed, Nov 16, 2016 at 2:13 AM, Xunlei Pang wrote:
>> Ccing David
>> On 2016/11/16 at 17:02, Xunlei Pang wrote:
>>> We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
>>> under kdump, it can
ff-by: Xunlei Pang
---
v1 -> v2:
Flush caches using old domain id.
drivers/iommu/intel-iommu.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3965e73..653304d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b
Ping Joerg/David, do you have any comment on it?
On 2016/11/19 at 00:23, Xunlei Pang wrote:
> We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
> under kdump, it can be steadily reproduced on several different machines,
> the dmesg log is like(running on 4.9.0-rc
On 11/29/2016 at 10:35 PM, Joerg Roedel wrote:
> On Thu, Nov 17, 2016 at 10:47:28AM +0800, Xunlei Pang wrote:
>> As per the comment, the code here only needs to flush context caches
>> for the special domain 0 which is used to tag the
>> non-present/erroneous caches, seems we
On 11/30/2016 at 10:26 PM, Joerg Roedel wrote:
> On Wed, Nov 30, 2016 at 06:23:34PM +0800, Baoquan He wrote:
>> OK, talked with Xunlei. The old cache could be entry with present bit
>> set.
> -EPARSE
>
> Anyway, what I was trying to say is, that the IOMMU TLB is tagged with
> domain-ids, and that t
On 12/01/2016 at 06:33 PM, Joerg Roedel wrote:
> On Thu, Dec 01, 2016 at 10:15:45AM +0800, Xunlei Pang wrote:
>> index 3965e73..624eac9 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -2024,6 +2024,25 @@ static int domain
On 12/08/2016 at 10:37 AM, zhongjiang wrote:
> From: zhong jiang
>
> A soft lookup will occur when I run trinity in syscall kexec_load.
> the corresponding stack information is as follows.
>
> [ 237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
> [ 237.242699] Kernel panic -
On 12/09/2016 at 01:13 PM, zhong jiang wrote:
> On 2016/12/8 17:41, Xunlei Pang wrote:
>> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
>>> From: zhong jiang
>>>
>>> A soft lookup will occur when I run trinity in syscall kexec_load.
>>> the
On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote:
> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote:
>> On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
>>> When trying to configure crashkernel greater than about 800 MB, the
>>> kernel fails to allocate memory on x86 and x86_64. This is due to an
>>>
On 12/14/2016 at 11:08 AM, Xunlei Pang wrote:
> On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote:
>> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote:
>>> On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
>>>> When trying to configure crashkernel greater than about 80
On 12/14/2016 at 02:11 PM, Pingfan Liu wrote:
> kexec-tools always allocates program headers for each possible cpu. This
> incurs zero PT_NOTE for offline cpu. We mark this case so that later,
> the capture kernel can distinguish it from the mistake of allocated
> program header.
> The counterpart
On 12/14/2016 at 04:56 PM, Liu ping fan wrote:
> On Wed, Dec 14, 2016 at 4:48 PM, Xunlei Pang wrote:
>> On 12/14/2016 at 02:11 PM, Pingfan Liu wrote:
>>> kexec-tools always allocates program headers for each possible cpu. This
>>> incurs zero PT_NOTE for offline cpu
On 12/15/2016 at 01:50 AM, Robert LeBlanc wrote:
> On Tue, Dec 13, 2016 at 8:08 PM, Xunlei Pang wrote:
>> On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote:
>>> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote:
>>>> On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
On 12/14/2016 at 05:13 PM, Liu ping fan wrote:
> [...]
>>> No. This patch just place a mark on these offline cpu. The next patch
>>> for capture kernel will recognize this case, and ignore this kind of
>>> pt_note by the code:
>>> real_sz = 0; // although the size of this kind of PT_NOTE is not zer
On 12/14/2016 at 02:11 PM, Pingfan Liu wrote:
> kexec-tools always allocates program headers for possible cpus. But
> when crashing, offline cpus have dummy headers. We do not copy these
> dummy notes into ELF file, also have no need of warning on them.
>
> Signed-off-by: Pingfan Liu
> ---
> fs/p
CRASH_KERNEL_ADDR_MAX was missing for a long time, update it
with more detailed explanation.
Cc: Robert LeBlanc
Cc: Baoquan He
Signed-off-by: Xunlei Pang
---
arch/x86/kernel/setup.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86
On 12/20/2016 at 11:38 PM, Pratyush Anand wrote:
>
>
> On Monday 19 December 2016 08:10 AM, Dave Young wrote:
>> Hi, Pingfan
>>
>> On 12/19/16 at 10:08am, Pingfan Liu wrote:
>>> > kexec-tools always allocates program headers for present cpus. But
>>> > when crashing, offline cpus have dummy headers
On 12/21/2016 at 11:57 AM, Pratyush Anand wrote:
>
>
> On Wednesday 21 December 2016 08:56 AM, Xunlei Pang wrote:
>> On 12/20/2016 at 11:38 PM, Pratyush Anand wrote:
>>>
>>>
>>> On Monday 19 December 2016 08:10 AM, Dave Young wrote:
>>>> Hi,
On 12/19/2016 at 11:23 AM, Baoquan He wrote:
> On 12/09/16 at 03:16pm, Xunlei Pang wrote:
>> On 12/09/2016 at 01:13 PM, zhong jiang wrote:
>>> On 2016/12/8 17:41, Xunlei Pang wrote:
>>>> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
>>>>> From: zhong jia
On 12/22/2016 at 11:22 AM, Baoquan He wrote:
> On 12/15/16 at 11:30am, Xunlei Pang wrote:
>> CRASH_KERNEL_ADDR_MAX was missing for a long time, update it
>> with more detailed explanation.
>>
>> Cc: Robert LeBlanc
>> Cc: Baoquan He
>> Signed-off-by:
On 01/12/2017 at 03:35 AM, Robert LeBlanc wrote:
> On Wed, Dec 14, 2016 at 4:17 PM, Xunlei Pang wrote:
>> As I replied in another post, if you really want to detail the behaviour,
>> should mention
>> "crashkernel=size[KMG][@offset[KMG]]" with @offset[KMG] specifi
CRASH_KERNEL_ADDR_MAX has been missing for a long time,
update it with more detailed explanation.
Cc: Robert LeBlanc
Cc: Baoquan He
Signed-off-by: Xunlei Pang
---
arch/x86/kernel/setup.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86
/patch/6167631/
https://lists.gt.net/linux/kernel/2146557
Cc: Naoya Horiguchi
Signed-off-by: Xunlei Pang
---
arch/x86/kernel/cpu/mcheck/mce.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck
On 01/23/2017 at 04:48 PM, Dave Young wrote:
> Hi, Xunlei
>
> On 01/23/17 at 02:48pm, Xunlei Pang wrote:
>> CRASH_KERNEL_ADDR_MAX has been missing for a long time,
>> update it with more detailed explanation.
>>
>> Cc: Robert LeBlanc
>> Cc: Ba
On 01/23/2017 at 08:51 PM, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 04:01:51PM +0800, Xunlei Pang wrote:
>> We met an issue for kdump: after kdump kernel boots up,
>> and there comes a broadcasted mce in first kernel, the
> How does that even happen?
>
> Lemm
On 01/24/2017 at 01:51 AM, Borislav Petkov wrote:
> Hey Tony,
>
> a "welcome back" is in order? :-)
>
> On Mon, Jan 23, 2017 at 09:40:09AM -0800, Luck, Tony wrote:
>> If the system had experienced some memory corruption, but
>> recovered ... then there would be some pages sitting around
>> that the
On 01/24/2017 at 09:46 AM, Xunlei Pang wrote:
> On 01/24/2017 at 01:51 AM, Borislav Petkov wrote:
>> Hey Tony,
>>
>> a "welcome back" is in order? :-)
>>
>> On Mon, Jan 23, 2017 at 09:40:09AM -0800, Luck, Tony wrote:
>>> If the system had e
On 01/24/2017 at 02:14 AM, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 10:01:53AM -0800, Luck, Tony wrote:
>> will ignore the machine check on the other cpus ... assuming
>> that "cpu_is_offline(smp_processor_id())" does the right thing
>> in the kexec case where this is an "old" cpu that isn'
On 01/23/2017 at 10:50 PM, Borislav Petkov wrote:
> On Mon, Jan 23, 2017 at 09:35:53PM +0800, Xunlei Pang wrote:
>> One possible timing sequence would be:
>> 1st kernel running on multiple cpus panicked
>> then the crash dump code starts
>> the crash dump code stops
On 01/24/2017 at 08:22 PM, Borislav Petkov wrote:
> On Tue, Jan 24, 2017 at 09:27:45AM +0800, Xunlei Pang wrote:
>> It occurred on real hardware when testing crash dump.
>>
>> 1) SysRq-c was injected for the test in 1st kernel
>> [ 49.897279] SysRq : Trigger a crash 2)
On 01/26/2017 at 02:44 PM, Borislav Petkov wrote:
> On Thu, Jan 26, 2017 at 02:30:02PM +0800, Xunlei Pang wrote:
>> The hardware machine check is hard to reproduce, but the mce code of
>> RHEL7 is quite the same as that of tip/master, anyway we are able to
>> inject softwar
On 02/16/2017 at 06:18 PM, Borislav Petkov wrote:
> On Thu, Feb 16, 2017 at 01:36:37PM +0800, Xunlei Pang wrote:
>> I tried to use qemu to inject SRAO("mce -b 0 0 0xb100 0x5 0x0
>> 0x0"),
>> it works well in 1st kernel, but it doesn't work for 1s
On 02/16/2017 at 08:22 PM, Borislav Petkov wrote:
> On Thu, Feb 16, 2017 at 07:52:09PM +0800, Xunlei Pang wrote:
>> then mce will be broadcast to the other cpus which are still running
>> in the first kernel(i.e. looping in crash_nmi_callback).
> Simple: the crash code
On 02/17/2017 at 05:07 PM, Borislav Petkov wrote:
> On Fri, Feb 17, 2017 at 09:53:21AM +0800, Xunlei Pang wrote:
>> It changes the value of cpu_online_mask/etc which will cause confusion to
>> vmcore analysis.
> Then export the crashing_cpu variable, initialize it to somethin
://patchwork.kernel.org/patch/6167631/
https://lists.gt.net/linux/kernel/2146557
Cc: Naoya Horiguchi
Suggested-by: Borislav Petkov
Signed-off-by: Xunlei Pang
---
v1->v2:
Using crashing_cpu according to Borislav's suggestion.
arch/x86/include/asm/reboot.h| 1 +
arch/x86/kernel/cpu/mcheck/mc
On 02/20/2017 at 07:09 PM, Borislav Petkov wrote:
> On Mon, Feb 20, 2017 at 02:10:37PM +0800, Xunlei Pang wrote:
>> @@ -1128,8 +1129,9 @@ void do_machine_check(struct pt_regs *regs, long
>> error_code)
>> */
>> int lmce = 1;
>>
>> -/
On 02/20/2017 at 09:29 PM, Xunlei Pang wrote:
> On 02/20/2017 at 07:09 PM, Borislav Petkov wrote:
>> On Mon, Feb 20, 2017 at 02:10:37PM +0800, Xunlei Pang wrote:
>>> @@ -1128,8 +1129,9 @@ void do_machine_check(struct pt_regs *regs, long
>>> error_code)
>&
On 02/21/2017 at 04:26 AM, Borislav Petkov wrote:
> On Mon, Feb 20, 2017 at 09:29:24PM +0800, Xunlei Pang wrote:
>> There is a small window between crash and kdump kernel boot, so
>> if a SRAO comes within this window it will also cause the mce
>> synchronization problem on t
On 02/20/2017 at 07:09 PM, Borislav Petkov wrote:
> On Mon, Feb 20, 2017 at 02:10:37PM +0800, Xunlei Pang wrote:
>> @@ -1128,8 +1129,9 @@ void do_machine_check(struct pt_regs *regs, long
>> error_code)
>> */
>> int lmce = 1;
>>
>> -/
/linux/kernel/2146557
Cc: Naoya Horiguchi
Suggested-by: Borislav Petkov
Signed-off-by: Xunlei Pang
---
v1->v2:
Using crashing_cpu according to Borislav's suggestion.
v2->v3:
- Used crashing_cpu in mce.c explicitly, not skip crashing_cpu.
- Added some comments.
arch/x86/include/a
On 02/22/2017 at 02:20 AM, Luck, Tony wrote:
>> It's from my understanding, I didn't get the explicit description from the
>> intel SDM on this point.
>> If a broadcast SRAO comes on real hardware, will MSR_IA32_MCG_STATUS of each
>> cpu have MCG_STATUS_RIPV bit set?
> MCG_STATUS is a per-thread
On 02/23/2017 at 02:50 AM, Luck, Tony wrote:
> On Wed, Feb 22, 2017 at 12:11:14PM +0800, Xunlei Pang wrote:
>> +/*
>> + * Cases to bail out to avoid rendezvous process timeout:
>> + * 1)If this CPU is offline.
>> + * 2)If crashing_cpu was set, e.g. ente
/linux/kernel/2146557
Cc: Naoya Horiguchi
Suggested-by: Borislav Petkov
Signed-off-by: Xunlei Pang
---
v1->v2:
- Using crashing_cpu according to Borislav's suggestion.
v2->v3:
- Used crashing_cpu in mce.c explicitly, not skip crashing_cpu.
- Added some comments.
v3->v4:
- A
1 - 100 of 160 matches
Mail list logo
