Hi,
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Lianbo Jiang
> Sent: Monday, January 7, 2019 10:48 AM
> To: linux-kernel@vger.kernel.org
> Cc: ke...@lists.infradead.org; t...@linutronix.de; mi...@redhat.com;
> b
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Tuesday, June 5, 2018 11:03 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.k
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Monday, June 4, 2018 11:45 PM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshiyuki
> ; linux-kernel@vger.k
> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of 't...@kernel.org'
> Sent: Saturday, June 2, 2018 2:07 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ; Okajima,
> Toshiyuki ;
> linux-kernel@vger
Hello,
Thanks for this patch, Eric.
> -Original Message-
> From: Eric W. Biederman [mailto:ebied...@xmission.com]
> Sent: Monday, June 4, 2018 3:51 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ;
> 't...@kernel.org' ; Okajima, Toshi
> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of 't...@kernel.org'
> Sent: Wednesday, May 30, 2018 1:26 AM
> To: Hatayama, Daisuke
> Cc: 'gre...@linuxfoundation.org' ; Okajima,
> Toshiyuki ;
> linux-kernel@vger
/kernfs/dirs.c,
contained in repro.tar.gz like:
# ./kernfshash
AtvbAC0jwH U1cN9ZbARQ 6b2609c5
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hatayama, Daisuke
> Sent: Monday, May 28, 2018 9:54 P
case where nodes with the same hash but with the name
larger than the original node could still be skipped. Use
kernfs_sd_compare() to compare kernfs_node objects. Imporove patch
description.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Toshiyuki Okajima
Cc: Eric W. Biederman
---
fs
case where nodes with the same hash but with the name
larger than the original node could still be skipped. Use
kernfs_sd_compare() to compare kernfs_node objects. Imporove patch
description.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Toshiyuki Okajima
Cc: Eric W. Biederman
---
fs
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hatayama, Daisuke
> Sent: Saturday, May 19, 2018 12:43 AM
> To: 'gre...@linuxfoundation.org'
> Cc: Okajima, Toshiyuki/岡嶋 寿行 ;
> linux
kernfs_dir_pos(). As a result, the dentry returned by
kernfs_dir_pos() is skipped.
To fix this issue, try to find a next node only when the returned
object has a hash value equal to or smaller than the original one.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Toshiyuki Okajima
Cc: Eric W. Biederman
kernfs_dir_pos(). As a result, the dentry returned by
kernfs_dir_pos() is skipped.
To fix this issue, try to find a next node only when the returned
object has a hash value equal to or smaller than the original one.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Toshiyuki Okajima
Cc: Eric W. Biederman
Marc-Andre,
It looks to me that the 4th and 5th patches somehow has not been sent.
Could you send them, too?
I'd like them to actually build and run the kernel for testing.
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Beh
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Michael S. Tsirkin
> Sent: Tuesday, October 31, 2017 1:19 AM
> To: Hatayama, Daisuke
> Cc: 'marcandre.lur...@redhat.com' ;
>
= "raw", .mode = S_IRUSR },
> + .attr = { .name = "raw", .mode = S_IRUSR | S_IWUSR },
> .read = fw_cfg_sysfs_read_raw,
> + .write = fw_cfg_sysfs_write_raw,
> };
>
> /*
> --
> 2.14.1.146.gd35faa819
Thanks.
HATAYAMA, Daisuke
From: Baoquan He
Subject: Re: [PATCH V2] proc-vmcore: wrong data type casting fix
Date: Mon, 14 Mar 2016 11:50:53 +0800
> On 03/14/16 at 11:47am, Baoquan He wrote:
>> On 03/14/16 at 12:25pm, HATAYAMA Daisuke wrote:
>> > From: Dave Young
>> > Subject: [PATCH V2] p
ze - start, size);
> + tsz = (size_t)min_t(unsigned long long,
> + m->offset + m->size - start, size);
> paddr = m->paddr + start - m->offset;
> if (vmcore_remap_oldmem_pfn(vma, vma->vm_start + len,
> paddr >> PAGE_SHIFT, tsz,
>
--
Thanks.
HATAYAMA, Daisuke
This patch set fixes a bug introduced in the commit
f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45.
For the v2 discussion, please follow the following thread:
http://thread.gmane.org/gmane.linux.kernel/1902488
The v3 patch newly adds a patch suggested by Ingo Molnar.
---
HATAYAMA Daisuke (2
this patch.
Signed-off-by: HATAYAMA Daisuke
Acked-by: Baoquan He
Tested-by: Hidehiro Kawai
Reviewed-by: Masami Hiramatsu
---
include/linux/kernel.h |3 +++
kernel/kexec.c | 11 +++
kernel/panic.c |2 +-
3 files changed, 15 insertions(+), 1 deletion(-)
diff -
no functionality change,
but the point is to make it explicit, from the caller panic() side,
that the 2nd crash_kexec() does nothing.
Signed-off-by: HATAYAMA Daisuke
Suggested-by: Ingo Molnar
---
kernel/panic.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel
this patch.
Signed-off-by: HATAYAMA Daisuke
Acked-by: Baoquan He
Tested-by: Hidehiro Kawai
Reviewed-by: Masami Hiramatsu
---
include/linux/kernel.h | 3 +++
kernel/kexec.c | 11 +++
kernel/panic.c | 2 +-
3 files changed, 15 insertions(+), 1 deletion(-)
diff -
From: Vivek Goyal
Subject: Re: [RESEND PATCH] kernel/panic/kexec: fix
"crash_kexec_post_notifiers" option issue in oops path
Date: Thu, 5 Mar 2015 17:22:04 -0500
> On Thu, Mar 05, 2015 at 05:19:30PM -0500, Vivek Goyal wrote:
>> On Wed, Mar 04, 2015 at 05:56:48PM +0900, HAT
. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.
To fix this issue, this patch adds a check to
"crash_kexec_post_notifiers" in the condition of kexec_should_crash().
Signed-off-by: HATAYAMA Daisuke
Acked-by: Baoquan He
Tested-by: Hidehiro
Hello Eric, Vivek,
Do you have any comment to this patch?
On 2015/02/05 17:59, HATAYAMA Daisuke wrote:
The commit f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 introduced
"crash_kexec_post_notifiers" kernel boot option, which toggles
wheather panic() calls crash_kexec() befor
Hello,
From: Baoquan He
Subject: Re: [PATCH] kernel/panic/kexec: fix "crash_kexec_post_notifiers"
option issue in oops path
Date: Mon, 9 Feb 2015 10:40:30 +0800
> On 02/05/15 at 05:59pm, HATAYAMA Daisuke wrote:
>> The commit f06e5153f4ae2e2f3b0300f0e260e40c
. If it is enabled, crash_kexec() is called directly without
going through panic() in oops path.
To fix this issue, this patch adds a check to
"crash_kexec_post_notifiers" in the condition of kexec_should_crash().
Signed-off-by: HATAYAMA Daisuke
---
include/linux/kernel.h | 3 +++
kernel
From: Petr Tesarik
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Fri, 14 Nov 2014 13:36:10 +0100
> On Fri, 14 Nov 2014 18:54:23 +0900 (JST)
> HATAYAMA Daisuke wrote:
>
>> From: Petr Tesarik
>> Subject: Re: [PATCH] kdump, x86: r
From: Petr Tesarik
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Fri, 14 Nov 2014 09:31:45 +0100
> On Fri, 14 Nov 2014 10:42:35 +0900 (JST)
> HATAYAMA Daisuke wrote:
>
>> From: Petr Tesarik
>> Subject: Re: [PATCH] kdump, x86: r
From: Petr Tesarik
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Thu, 13 Nov 2014 15:48:10 +0100
> On Thu, 13 Nov 2014 09:25:48 -0500
> Vivek Goyal wrote:
>
>> On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote:
>> &
From: Vivek Goyal
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Thu, 13 Nov 2014 09:25:48 -0500
> On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote:
>>
>>
>> (2014/11/13 17:06), Petr Tesarik wrote:
>> >On T
(2014/11/13 17:06), Petr Tesarik wrote:
On Thu, 13 Nov 2014 09:17:09 +0900 (JST)
HATAYAMA Daisuke wrote:
From: Vivek Goyal
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Wed, 12 Nov 2014 17:12:05 -0500
On Wed, Nov 12, 2014 at 03:40:42PM +0900
e because
makedumpfile refers to it and if removing it, old versions
makedumpfile doesn't work well.
ChangeLog:
v2:
- Introduce VMCOREINFO_PHYS_BASE().
- Correct patch description: this work is primarily for mechanisms
running outside (kdump 1st) Linux kernel.
Signed-off-by: HATAYAMA Daisuke
From: Petr Tesarik
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Wed, 12 Nov 2014 09:14:34 +0100
> On Wed, 12 Nov 2014 15:40:42 +0900 (JST)
> HATAYAMA Daisuke wrote:
>
>> Currently, VMCOREINFO note information reports the virtual address
From: Vivek Goyal
Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in VMCOREINFO
Date: Wed, 12 Nov 2014 17:12:05 -0500
> On Wed, Nov 12, 2014 at 03:40:42PM +0900, HATAYAMA Daisuke wrote:
>> Currently, VMCOREINFO note information reports the virtual address of
>>
2nd
kernel contained in vmcore using the above-mentioned external crash
dump mechanism; kdump 2nd kernel is an inherently relocated kernel.
This commit doesn't remove VMCOREINFO_SYMBOL(phys_base) line because
makedumpfile refers to it and if removing it, old versions
makedumpfile doesn't wor
ange(vma, vma->vm_start + len,
> - paddr >> PAGE_SHIFT, tsz,
> -vma->vm_page_prot))
> + if (vmcore_remap_oldmem_pfn(vma, vma->vm_start + len,
> +
;size - start, size);
> paddr = m->paddr + start - m->offset;
> - if (remap_oldmem_pfn_range(vma, vma->vm_start + len,
> -paddr >> PAGE_SHIFT, tsz,
> -
Commit-ID: b292d7a10487aee6e74b1c18b8d95b92f40d4a4f
Gitweb: http://git.kernel.org/tip/b292d7a10487aee6e74b1c18b8d95b92f40d4a4f
Author: HATAYAMA Daisuke
AuthorDate: Wed, 25 Jun 2014 10:09:07 +0900
Committer: Ingo Molnar
CommitDate: Wed, 2 Jul 2014 08:35:55 +0200
perf/x86/intel: ignore
could stop using the PMU, but if some BIOS set it it would
> completely disable perf there. So better to just ignore it.
>
I'll reflect this information in the patch description.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linu
Hello,
(2014/06/17 0:30), Don Zickus wrote:
On Fri, Jun 13, 2014 at 05:44:37PM +0900, HATAYAMA Daisuke wrote:
Currently, a NMI handler for NMI watchdog may falsely handle any NMI
signaled for different purpose if CondChgd bit in
MSR_CORE_PERF_GLOBAL_STATUS MSR is set.
This commit deals with
gd in patch description
From 63d6fa2a3dfa9ff7d1710c85d8d020cdc37f3b49 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
Date: Wed, 25 Jun 2014 10:09:07 +0900
Subject: [PATCH] perf/x86/intel: ignore CondChgd bit to avoid false NMI
handling
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Conte
Table 35-2 IA-32 Architectural MSRs
63 CondChg: status bits of this register has changed.
These are different from the bahviour I see on the actual system as I
explained above.
At least, I think ignoring CondChgd bit should be enough for NMI
watchdog perspective.
Signed-off-by: HATAYAM
fine, just needs a better
> changelog.
>
I see.
I'll write that the problem is that any NMI could be robbed by NMI
watchdog explicitly. Now only patch title says this explicitly. This
is your first comment.
About CondChgd bit, I cannot write more than I see on actual
system. If it&#x
From: Peter Zijlstra
Subject: Re: [PATCH] perf/x86/intel: ignore CondChgd bit to avoid false NMI
handling
Date: Wed, 11 Jun 2014 10:54:48 +0200
> On Wed, Jun 11, 2014 at 04:30:28PM +0900, HATAYAMA Daisuke wrote:
>> Currently, a NMI handler for NMI watchdog may falsely handle any NMI
&g
, in particular when
this bit is set. Although I read Intel System Programmer's Manual to
figure out but I have yet completed that. At least, I think ignoring
CondChgd bit should be enough for NMI watchdog perspective.
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/kernel/cpu/perf_event_intel.c
(2014/01/26 13:02), David Rientjes wrote:
> On Thu, 16 Jan 2014, HATAYAMA Daisuke wrote:
>
>> Hello,
>>
>> This patch deals with the issue of handling boot_cpu_physical_apicid
>> in boot process I avoided in disable_cpu_apicid patch because I
>> cannot gue
sh is 5b4d1dbc24bb6fd7179ada0f47be34e27e64decb
I tested this patch in each combination of the following table:
BIOS tableboot cpu
-+--
ACPI MADT AP
MP Table BSP
>From 10946038252fc91f3ae2740953b2484ea0076ed4 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisu
(2014/01/16 14:53), H. Peter Anvin wrote:
On 01/15/2014 08:44 PM, HATAYAMA Daisuke wrote:
This is not typo in my intention.
generic_processor_info() has two more cases where it ignores cpus.
In either cases, printed messages are tagged with "ACPI" because this
function is called wh
Cc: HATAYAMA Daisuke
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e78ab8c..7f26c9a 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -79,7 +79,7
Commit-ID: 151e0c7de616310f95393d9306903900fcd8b277
Gitweb: http://git.kernel.org/tip/151e0c7de616310f95393d9306903900fcd8b277
Author: HATAYAMA Daisuke
AuthorDate: Wed, 15 Jan 2014 15:44:58 +0900
Committer: H. Peter Anvin
CommitDate: Wed, 15 Jan 2014 09:19:20 -0800
x86, apic, kexec
, disabled_cpu_apicid kernel
parameter doesn't work well for apicids of APs.
Fixing the wrong handling of boot_cpu_physical_apicid requires some
reviews and tests beyond some platforms and it could take some
time. The fix here is a kind of workaround to focus on the main topic
of this patch.
Signed-off-by: HAT
(2013/12/10 23:49), Vivek Goyal wrote:
On Wed, Dec 04, 2013 at 05:10:58PM +0900, HATAYAMA Daisuke wrote:
This patch set is to allow kdump 2nd kernel to wake up multiple CPUs,
a continueing work from:
[PATCH v3 0/2] x86, apic, kdump: Disable BSP if boot cpu is AP
https://lkml.org/lkml
(2013/12/13 1:42), Vivek Goyal wrote:
On Mon, Dec 09, 2013 at 05:06:06PM +0900, HATAYAMA Daisuke wrote:
This is a patch for fixing mmap failure due to fractional page issue.
This patch might be still a bit too large as a single patch and might need to
split.
If you think patch refactoring is
t;From fd6b0aca54caf7f0b5fd3841ef9e5ff081121ab8 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
Date: Mon, 9 Dec 2013 09:12:32 +0900
Subject: [PATCH] vmcore: copy fractional pages into buffers in the kdump 2nd
kernel
As Vivek reported in https://lkml.org/lkml/2013/11/13/439, in real
world there's platform that allocates
(2013/12/04 0:12), Vivek Goyal wrote:
On Tue, Dec 03, 2013 at 02:16:35PM +0900, HATAYAMA Daisuke wrote:
[..]
Even if copying partial pages into the 2nd kernel, we need to use ioremap()
once on them, and I think the ioremap() is exactly similar to
remap_pfn_range() for a single page. There
d03e159d9479755b36ac7d4a7d323b3ce95481be Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
Date: Tue, 3 Dec 2013 09:21:56 +0900
Subject: [PATCH] x86, apic, kexec, Documentation: Add disable_cpu_apicid
kernel parameter
Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
specify
(2013/12/04 12:08), HATAYAMA Daisuke wrote:
(2013/12/04 0:25), Vivek Goyal wrote:
On Tue, Dec 03, 2013 at 10:32:26AM +0900, HATAYAMA Daisuke wrote:
[..]
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 50680a5..dd77bec 100644
--- a/Documentation
(2013/12/04 0:25), Vivek Goyal wrote:
On Tue, Dec 03, 2013 at 10:32:26AM +0900, HATAYAMA Daisuke wrote:
[..]
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 50680a5..dd77bec 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation
ity check ?
> Certain standard values are necessary for sanity check, how will
> you prepare such values ?
> (Get them from kernel source and hard-code them in makedumpfile ?)
>
>> Unlike diskdump, we no longer need to care about kernel/hardware level data
>> integrity
>&
(2013/12/03 10:18), HATAYAMA Daisuke wrote:
(2013/12/03 0:27), Vivek Goyal wrote:
On Thu, Nov 28, 2013 at 05:48:02PM +0900, HATAYAMA Daisuke wrote:
Hello Vivek,
Here is a patch set for mmap failure for /proc/vmcore.
Could you try to use this on the problematic system?
This patch doesn't
AL_APIC
- tested x86_64 in case of acpi and MP table
- tested disable_cpu_apicid= to disable both AP and BSP
>From 2cd100eb618a36a82bae2db98f0f4b7d3c1dfe89 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
Date: Tue, 3 Dec 2013 09:21:56 +0900
Subject: [PATCH] x86, apic, kexec, Documentat
(2013/12/03 0:27), Vivek Goyal wrote:
On Thu, Nov 28, 2013 at 05:48:02PM +0900, HATAYAMA Daisuke wrote:
Hello Vivek,
Here is a patch set for mmap failure for /proc/vmcore.
Could you try to use this on the problematic system?
This patch doesn't copy partial pages to the 2nd kernel,
e
descriptor can also be corrupted. For example, if the corrupted value were a
huge
number, wide range of pages after buddy page would be filtered falsely.
So, actually we should sanity check data in crash dump before using them for
application
level feature. I've picked up order contained in page descriptor, so there
would be other
data used in makedumpfile that are not checked.
Unlike diskdump, we no longer need to care about kernel/hardware level data
integrity
outside of user-land, but we still care about data its own integrity.
On the other hand, if we do it, we might face some difficulty, for example,
hardness of
maintenance or performance bottleneck; it might be the reason why we don't see
sanity
check in makedumpfile now.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
gt; order of
>> huge page is hard in some way, right?
>
> The maximum order will be gotten from HUGETLB_PAGE_ORDER or HPAGE_PMD_ORDER,
> so I don't say it's hard. However, the carrying over method doesn't depend on
> such kernel symbols, so I think it's robuster.
pages.
>From c8323be2a2972dcb3f252598c39abfa23078 Mon Sep 17 00:00:00 2001
From: HATAYAMA Daisuke
Date: Thu, 28 Nov 2013 14:51:22 +0900
Subject: [PATCH] vmcore: call remap_pfn_range() separately for respective
partial pages
Acording to the report by Vivek in
https://lkml.org/lkml/2013/11/13
(2013/11/28 16:08), Atsushi Kumagai wrote:
> On 2013/11/22 16:18:20, kexec wrote:
>> (2013/11/07 9:54), HATAYAMA Daisuke wrote:
>>> (2013/11/06 11:21), Atsushi Kumagai wrote:
>>>> (2013/11/06 5:27), Vivek Goyal wrote:
>>>>> On Tue, Nov 05, 2013 at 09
apic-present case only; I don't have any
x86 processor without local apic.
- Add __init annotation to boot_cpu_is_bsp_init().
Test
- tested x86_64 in case of acpi and MP table
- tested disable_cpu_apicid= to disable both AP and BSP
>From a8bd546408ca06d844eda1af9ed1b34d12519eab Mon
(2013/11/28 0:10), Vivek Goyal wrote:
On Wed, Nov 27, 2013 at 11:00:48AM +0900, HATAYAMA Daisuke wrote:
Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
specify an initial APIC ID of the corresponding CPU you want to
disable.
This is mostly used for the kdump 2nd kernel
: I've checked local apic-present case only; I don't have any
x86 processor without local apic.
- Add __init annotation to boot_cpu_is_bsp_init().
Test
- built with and without CONFIG_LOCAL_APIC
- tested x86_64 in case of acpi and MP table
- tested disable_cpu_apicid= to disabl
tform are required. As a
workaround, we directly update boot_cpu_physical_apicid by
read_apic_id().
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/kernel/apic/apic.c | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arc
Add disable_cpu_apicid kernel parameter to disable the CPU with the
specified number of initial APIC ID, mostly used for the kdump 2nd
kernel to disable BSP to wake up multiple CPUs without causing system
reset or hang due to sending INIT from AP to BSP.
Signed-off-by: HATAYAMA Daisuke
(2013/11/25 23:41), Vivek Goyal wrote:
On Mon, Nov 25, 2013 at 06:01:37PM +0900, HATAYAMA Daisuke wrote:
[..]
I agree to avoid this issue by fixing makedumpfile as workaround while to
fix kernel is so tough and risky. However, it sounds strange to me to fix
userspace side elaborately for such
(2013/11/25 17:10), Atsushi Kumagai wrote:
> On 2013/11/22 1:53:14, kexec wrote:
>> On Thu, Nov 21, 2013 at 05:31:46PM +0900, HATAYAMA Daisuke wrote:
>>
>> [..]
>>>> So I think the patch I sent is enough, the policy will be simpler as
>>>> "Don
(2013/11/07 9:54), HATAYAMA Daisuke wrote:
(2013/11/06 11:21), Atsushi Kumagai wrote:
(2013/11/06 5:27), Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma wrote:
This patch set intend to exclude unnecessary hugepages from vmcore dump file.
This patch requires the kernel
Add disable_cpu_apicid kernel parameter to disable the CPU with the
specified number of initial APIC ID, mostly used for the kdump 2nd
kernel to disable BSP to wake up multiple CPUs without causing system
reset or hang due to sending INIT from AP to BSP.
Signed-off-by: HATAYAMA Daisuke
-off-by: HATAYAMA Daisuke
---
arch/x86/kernel/apic/apic.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index cff8d71..77fd68d 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
sted disable_cpu_apicid= to disable both AP and BSP
---
HATAYAMA Daisuke (3):
x86, apic: add bios_bsp_physical_apicid
x86, apic: Add disable_cpu_apicid kernel parameter
Documentation, x86, apic, kexec: Add disable_cpu_apicid kernel parameter
Documentation/kernel-parameters.txt
work well even if it exists on some system, e.g. some
cluster system.
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/include/asm/mpspec.h |1 +
arch/x86/kernel/acpi/boot.c|8
arch/x86/kernel/apic/apic.c|9 +
arch/x86/kernel
(2013/11/20 14:27), Atsushi Kumagai wrote:
> On 2013/11/19 18:56:21, kexec wrote:
>> (2013/11/18 9:51), Atsushi Kumagai wrote:
>>> (2013/11/15 23:26), Vivek Goyal wrote:
>>>> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote:
>>>>
>>
(2013/11/18 9:51), Atsushi Kumagai wrote:
> (2013/11/15 23:26), Vivek Goyal wrote:
>> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote:
>>
>> [..]
>>>> Given the fact that hpa does not like fixing it in kernel. We are left
>>>>
00 00 00 00 01 00 00 00 ...@
00A0: 00 00 00 00 00 00 00 00
Signed-off-by: HATAYAMA Daisuke
---
drivers/acpi/sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 05306a5
(2013/11/15 0:13), Vivek Goyal wrote:
On Thu, Nov 14, 2013 at 07:31:37PM +0900, HATAYAMA Daisuke wrote:
[..]
BTW, I previously found a part of makedumpfile that truncates the first and
last pages if they are not aligned in page size. Discussing with Kumagai-san,
the truncation is performed on
Hello HPA,
I have another question relevant to http://lkml.org/lkml/2013/11/12/311.
(2013/11/12 18:51), HATAYAMA Daisuke wrote:
@@ -2589,3 +2593,14 @@ static int __init lapic_insert_resource(void)
* that is using request_resource
*/
late_initcall(lapic_insert_resource);
+
+void __init
(2013/11/12 19:44), Borislav Petkov wrote:
On Tue, Nov 12, 2013 at 06:51:58PM +0900, HATAYAMA Daisuke wrote:
Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
specify an initial APIC ID of the corresponding CPU you want to
disable.
This is mostly used for the kdump 2nd
evert the above
commit or not since makedumpfile fails on some kind of system as you reported.
--
Thanks.
HATAYAMA, Daisuke
--
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://vge
(2013/11/12 4:54), H. Peter Anvin wrote:
On 10/12/2013 10:42 AM, Ingo Molnar wrote:
* H. Peter Anvin wrote:
On 10/09/2013 04:16 PM, tip-bot for HATAYAMA Daisuke wrote:
Commit-ID: 1d79e607332d67d9132c176d99b5e7fabe1b6b7f
Gitweb: http://git.kernel.org/tip
(2013/11/12 9:40), HATAYAMA Daisuke wrote:
(2013/11/12 1:52), Vivek Goyal wrote:
On Mon, Nov 11, 2013 at 11:52:30AM +0900, HATAYAMA Daisuke wrote:
[..]
Looking at my past investigation, kernel/mpparse.c, mm/amdtopology.c and
platform/visws/visws_quirks.c assumes that boot_cpu_physical_apicid
-off-by: HATAYAMA Daisuke
---
arch/x86/kernel/apic/apic.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index b60ad92..075bf23 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
nly; I don't have any
x86 processor without local apic.
- Add __init annotation to boot_cpu_is_bsp_init().
Test
- built with and without CONFIG_LOCAL_APIC, CONFIG_SMP and CONFIG_X86_UP_APIC.
- tested x86_64 in case of acpi and MP table
- tested disable_cpu_apicid= to disable both AP and BSP
---
Add disable_cpu_apicid kernel parameter to disable the CPU with the
specified number of initial APIC ID, mostly used for the kdump 2nd
kernel to disable BSP to wake up multiple CPUs without causing system
reset or hang due to sending INIT from AP to BSP.
Signed-off-by: HATAYAMA Daisuke
from MP
table or MADT. This covers the above MP table related codes with no
functional change.
Initialize boot_cpu_data.initial_apicid in early_identify_cpu() since
currently it is initialized after logical cpu number assignment is
performed.
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/include
(2013/11/12 1:52), Vivek Goyal wrote:
On Mon, Nov 11, 2013 at 11:52:30AM +0900, HATAYAMA Daisuke wrote:
[..]
Looking at my past investigation, kernel/mpparse.c, mm/amdtopology.c and
platform/visws/visws_quirks.c assumes that boot_cpu_physical_apicid
has initial apicid of the BSP, not the
(2013/11/07 4:02), jerry.hoem...@hp.com wrote:
On Wed, Oct 23, 2013 at 12:01:18AM +0900, HATAYAMA Daisuke wrote:
This patch set is to allow kdump 2nd kernel to wake up multiple CPUs
even if 1st kernel crashs on some AP, a continueing work from:
[PATCH v3 0/2] x86, apic, kdump: Disable BSP
(2013/11/09 1:08), Vivek Goyal wrote:
On Wed, Oct 23, 2013 at 12:01:24AM +0900, HATAYAMA Daisuke wrote:
If crash occurs on some AP, then kdump 2nd kernel is booted up on the
AP. Therefore, it is not always correct that the CPU that is currently
booting up the kernel is BSP. It's wro
nly.
>>
>> Kumagai-san, please correct me, if I'm wrong.
>
> Yes, my patch treats all allocated hugetlbfs pages as user pages,
> doesn't distinguish whether the pages are actually used or not.
> I made so because I guess it's enough for almost all users.
>
> We can introduce new dump level after it's needed actually,
> but I don't think now is the time. To introduce it without
> demand will make this tool just more complex.
>
Typically, users would allocate huge pages as much as actually they use only,
in order not to waste system memory. So, this design seems reasonable.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
could no longer
work. Tables for interrupts can be broken. The other cpus except for the
crashing cpu are no longer guaranteed to be running sanely. Migrating cpu
from the crashing cpu to cpu0 reduces reliability of kdump.
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line &
's necessary to align info->bufsize_cyclic with larger one in
check_cyclic_buffer_overrun().
--
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Commit-ID: a477c8594bee3bff639739c48258a8c737ab721e
Gitweb: http://git.kernel.org/tip/a477c8594bee3bff639739c48258a8c737ab721e
Author: HATAYAMA Daisuke
AuthorDate: Tue, 5 Nov 2013 02:15:48 +0900
Committer: Ingo Molnar
CommitDate: Wed, 6 Nov 2013 08:13:56 +0100
x86/cpu: Always print
est machine, on which guest, MP
information is not displayed in /proc/cpuinfo.
I saw this situation on VMWare guest environment, too.
To fix this issue, this patch simply removes the condition because
this information is useful even if there's only 1 thread.
Signed-off-by: HATAYAMA Daisuke
---
's scripts really a little bit only. I'd like anyone to post patches
if necessary...
BTW, what's the status of this patch set? I've redesigned this so as to
be done with kernel parameter in order not to depend on platform specific
BIOS table. Due to the redesign, I think now ACK is
1 - 100 of 360 matches
Mail list logo
