RE: [PATCH] x86/PAT: priority the PAT warn to error to highlight the developer

2019-09-30 Thread Zhang, Jun
Please see my comments. Thanks, Jun -Original Message- From: Borislav Petkov Sent: Monday, September 30, 2019 8:03 PM To: Zhang, Jun Cc: dave.han...@linux.intel.com; l...@kernel.org; pet...@infradead.org; t...@linutronix.de; mi...@redhat.com; h...@zytor.com; He, Bo ; x...@kernel.org

RE: [PATCH 3.18 132/134] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt

2019-03-27 Thread Zhang, Jun
connect the network. This make me not to work with terminal, because system very slowly. So I don’t use V3.18.136+patch to test. -Original Message- From: Paul E. McKenney [mailto:paul...@linux.ibm.com] Sent: Wednesday, March 27, 2019 23:10 To: Zhang, Jun Cc: He, Bo ; Greg Kroah-Hartman

RE: [PATCH 3.18 132/134] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt

2019-03-26 Thread Zhang, Jun
...@linux.ibm.com] Sent: Tuesday, March 26, 2019 23:56 To: He, Bo Cc: Greg Kroah-Hartman ; linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Zhang, Jun ; Xiao, Jin ; Bai, Jie A Subject: Re: [PATCH 3.18 132/134] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt On Tue, Mar 26

[tip:core/rcu] rcu: Do RCU GP kthread self-wakeup from softirq and interrupt

2019-02-13 Thread tip-bot for Zhang, Jun
Commit-ID: 1d1f898df6586c5ea9aeaf349f13089c6fa37903 Gitweb: https://git.kernel.org/tip/1d1f898df6586c5ea9aeaf349f13089c6fa37903 Author: Zhang, Jun AuthorDate: Tue, 18 Dec 2018 06:55:01 -0800 Committer: Paul E. McKenney CommitDate: Fri, 25 Jan 2019 15:29:59 -0800 rcu: Do RCU GP kthread

[tip:core/rcu] rcu: Prevent needless ->gp_seq_needed update in __note_gp_changes()

2019-02-13 Thread tip-bot for Zhang, Jun
Commit-ID: 13dc7d0c7a2ed438f0ec8e9fb365a1256d87cf87 Gitweb: https://git.kernel.org/tip/13dc7d0c7a2ed438f0ec8e9fb365a1256d87cf87 Author: Zhang, Jun AuthorDate: Wed, 19 Dec 2018 10:37:34 -0800 Committer: Paul E. McKenney CommitDate: Fri, 25 Jan 2019 15:30:00 -0800 rcu: Prevent needless

RE: rcu_preempt caused oom

2018-12-17 Thread Zhang, Jun
ember 18, 2018 07:16 To: paul...@linux.ibm.com Cc: Zhang, Jun ; Steven Rostedt ; linux-kernel@vger.kernel.org; j...@joshtriplett.org; mathieu.desnoy...@efficios.com; jiangshan...@gmail.com; Xiao, Jin ; Zhang, Yanmin ; Bai, Jie A ; Sun, Yi J ; Chang, Junxiao ; Mei, Paul Subject: RE: rcu_preemp

RE: rcu_preempt caused oom

2018-12-12 Thread Zhang, Jun
-Original Message- From: Paul E. McKenney [mailto:paul...@linux.ibm.com] Sent: Thursday, December 13, 2018 08:12 To: He, Bo Cc: Steven Rostedt ; linux-kernel@vger.kernel.org; j...@joshtriplett.org; mathieu.desnoy...@efficios.com; jiangshan...@gmail.com; Zhang, Jun ; Xiao, Jin ; Zhang,

RE: [PATCH] ALSA: core: fix unsigned int pages overflow when comapred

2018-07-19 Thread Zhang, Jun
.@suse.de] Sent: Wednesday, July 18, 2018 20:34 To: He, Bo Cc: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.org; Zhang, Jun ; Zhang, Yanmin Subject: Re: [PATCH] ALSA: core: fix unsigned int pages overflow when comapred On Wed, 18 Jul 2018 13:52:45 +0200, He, Bo wrote: &g

RE: [PATCH] ALSA: core: fix unsigned int pages overflow when comapred

2018-07-19 Thread Zhang, Jun
.@suse.de] Sent: Wednesday, July 18, 2018 20:34 To: He, Bo Cc: alsa-de...@alsa-project.org; pe...@perex.cz; linux-kernel@vger.kernel.org; Zhang, Jun ; Zhang, Yanmin Subject: Re: [PATCH] ALSA: core: fix unsigned int pages overflow when comapred On Wed, 18 Jul 2018 13:52:45 +0200, He, Bo wrote: &g

RE: [PATCH] sched/fair: fix select_task_rq_fair return -1

2014-12-04 Thread Zhang, Jun
Hello, Hillf This issue happened in 3.14.25. Do you know which patch to fix it in 3.18-rc7? We can try it. -Original Message- From: Hillf Danton [mailto:hillf...@alibaba-inc.com] Sent: Thursday, December 04, 2014 5:05 PM To: Zhang, Jun Cc: Ingo Molnar; Peter Zijlstra; linux-kernel; Liu

RE: [PATCH] sched/fair: fix select_task_rq_fair return -1

2014-12-04 Thread Zhang, Jun
Hello, Hillf This issue happened in 3.14.25. Do you know which patch to fix it in 3.18-rc7? We can try it. -Original Message- From: Hillf Danton [mailto:hillf...@alibaba-inc.com] Sent: Thursday, December 04, 2014 5:05 PM To: Zhang, Jun Cc: Ingo Molnar; Peter Zijlstra; linux-kernel; Liu

[PATCH] firmware: give a protection when map page failed

2014-01-28 Thread Zhang, Jun
ing_store); @@ -916,6 +921,8 @@ err_del_dev: device_del(f_dev); err_put_dev: put_device(f_dev); + if (!buf->data) + return -ENOMEM; return retval; } -- 1.7.9.5 ----------- Best Regards Zhang, Jun Android System I

[PATCH] firmware: give a protection when map page failed

2014-01-28 Thread Zhang, Jun
); err_put_dev: put_device(f_dev); + if (!buf-data) + return -ENOMEM; return retval; } -- 1.7.9.5 --- Best Regards Zhang, Jun Android System Integration Shanghai Tel: +86 (0)21 6116 4273 Mob:+86 (0)15821507662

[PATCH] At present, function sched_clock_idle_wakeup_event input parameter is not necessary, we can remove it.

2013-02-27 Thread Zhang, Jun
Signed-off-by: jzha144 --- arch/x86/kernel/tsc.c |2 +- drivers/acpi/processor_idle.c |4 ++-- include/linux/sched.h |6 +++--- kernel/sched/clock.c |4 ++-- kernel/time/tick-sched.c |2 +- 5 files changed, 9 insertions(+), 9 deletions(-) diff

[PATCH] At present, function sched_clock_idle_wakeup_event input parameter is not necessary, we can remove it.

2013-02-27 Thread Zhang, Jun
Signed-off-by: jzha144 jun.zh...@intel.com --- arch/x86/kernel/tsc.c |2 +- drivers/acpi/processor_idle.c |4 ++-- include/linux/sched.h |6 +++--- kernel/sched/clock.c |4 ++-- kernel/time/tick-sched.c |2 +- 5 files changed, 9 insertions(+), 9

RE: [PATCH] crash dump: don't delete non-E820_RAM during init

2012-11-04 Thread Zhang, Jun
atch. Best Regards! Jun Zhang Inet: 8821-4273 Dir.Tel: 86-21-6116-4273 Email: jun.zh...@intel.com -Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] Sent: Monday, November 05, 2012 10:39 AM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton;

RE: [PATCH] crash dump: don't delete non-E820_RAM during init

2012-11-04 Thread Zhang, Jun
, November 03, 2012 12:38 AM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware

RE: [PATCH] crash dump: don't delete non-E820_RAM during init

2012-11-04 Thread Zhang, Jun
, November 03, 2012 12:38 AM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware

RE: [PATCH] crash dump: don't delete non-E820_RAM during init

2012-11-04 Thread Zhang, Jun
! Jun Zhang Inet: 8821-4273 Dir.Tel: 86-21-6116-4273 Email: jun.zh...@intel.com -Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] Sent: Monday, November 05, 2012 10:39 AM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming, Matt; Paul

RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-11-01 Thread Zhang, Jun
_setup_data(); +#ifdef CONFIG_CRASH_DUMP + e820_crashdump_remove_ram(); +#endif copy_edd(); -- 1.7.6 Best Regards! Jun Zhang Inet: 8821-4273 Dir.Tel: 86-21-6116-4273 Email: jun.zh...@intel.com -Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] Sent: Thursday, N

RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-11-01 Thread Zhang, Jun
PM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code

RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-10-31 Thread Zhang, Jun
...@intel.com -Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] Sent: Wednesday, October 31, 2012 1:39 PM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] To crash

RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-10-31 Thread Zhang, Jun
...@intel.com -Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] Sent: Wednesday, October 31, 2012 1:39 PM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] To crash

RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-10-30 Thread Zhang, Jun
0; #endif e820.nr_map = 0; userdef = 1; -- 1.7.6 Best Regards! Zhang, jun -Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] Sent: Wednesday, October 31, 2012 12:38 PM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew

RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-10-30 Thread Zhang, Jun
dif e820.nr_map = 0; userdef = 1; -- 1.7.6 Best Regards! Jun Zhang Inet: 8821-4273 Dir.Tel: 86-21-6116-4273 Email: jun.zh...@intel.com -Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] Sent: Wednesday, October 31, 2012 10:47 AM To: Zhang, Jun

[PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-10-30 Thread Zhang, Jun
>From aebc336baa7ec2d4ccb6f21166770c7d2ee26cba Mon Sep 17 00:00:00 2001 From: jzha144 Date: Wed, 31 Oct 2012 08:51:18 +0800 Subject: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example:

[PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-10-30 Thread Zhang, Jun
From aebc336baa7ec2d4ccb6f21166770c7d2ee26cba Mon Sep 17 00:00:00 2001 From: jzha144 jun.zh...@intel.com Date: Wed, 31 Oct 2012 08:51:18 +0800 Subject: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for

RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-10-30 Thread Zhang, Jun
, 2012 10:47 AM To: Zhang, Jun Cc: Thomas Gleixner; Ingo Molnar; x...@kernel.org; Andrew Morton; Fleming, Matt; Paul Gortmaker; linux-kernel@vger.kernel.org Subject: Re: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used

RE: [PATCH] To crash dump, we need keep other memory type except E820_RAM, because other type come from BIOS or firmware is used by other code(for example: PCI_MMCONFIG).

2012-10-30 Thread Zhang, Jun
); + userdef = 1; + return 0; #endif e820.nr_map = 0; userdef = 1; -- 1.7.6 Best Regards! Zhang, jun -Original Message- From: H. Peter Anvin [mailto:h...@zytor.com] Sent: Wednesday, October 31, 2012 12:38 PM To: Zhang, Jun Cc: Thomas Gleixner

[PATCH] Sometimes, there is OOPS happened when we use oprofile.

2012-10-28 Thread Zhang, Jun
>From fff479313342940372444797814edee996b18fc9 Mon Sep 17 00:00:00 2001 From: jzha144 Date: Mon, 29 Oct 2012 09:07:22 +0800 Subject: [PATCH] Sometimes, there is OOPS happened when we use oprofile. next is the call stack. From call stack, we find in call_on_stack if there is a nmi interrupt

[PATCH] Sometimes, there is OOPS happened when we use oprofile.

2012-10-28 Thread Zhang, Jun
From fff479313342940372444797814edee996b18fc9 Mon Sep 17 00:00:00 2001 From: jzha144 jun.zh...@intel.com Date: Mon, 29 Oct 2012 09:07:22 +0800 Subject: [PATCH] Sometimes, there is OOPS happened when we use oprofile. next is the call stack. From call stack, we find in call_on_stack if there is a