On 2019/1/17 下午11:17, Dave Hansen wrote:
On 1/17/19 12:19 AM, Yanmin Zhang wrote:
I didn't try pmem and I am wondering it's slower than DRAM.
Should a flag, such like _GFP_PMEM, be added to distinguish it from
DRAM?
Absolutely not. :)
Agree.
We already have performance-differentiated
On 2019/1/17 上午2:19, Dave Hansen wrote:
From: Dave Hansen
Currently, a persistent memory region is "owned" by a device driver,
either the "Direct DAX" or "Filesystem DAX" drivers. These drivers
allow applications to explicitly use persistent memory, generally
by being modified to use special,
On 二, 2013-12-24 at 09:35 +0800, shuox@intel.com wrote:
> From: Zhang Yanmin
>
> pnp pnp_bus_suspend/_resume have an issue.
> pnp_bus_suspend calls pnp_stop_dev to disable the device. With ACPI,
> pnp_stop_dev turns off the dev usually. Then,
> pnp_bus_suspend=>pnp_dev->protocol->suspend
On 二, 2013-12-24 at 09:35 +0800, shuox@intel.com wrote:
From: Zhang Yanmin yanmin.zh...@intel.com
pnp pnp_bus_suspend/_resume have an issue.
pnp_bus_suspend calls pnp_stop_dev to disable the device. With ACPI,
pnp_stop_dev turns off the dev usually. Then,
On Sat, 2013-07-13 at 13:56 +0200, Pavel Machek wrote:
> On Fri 2013-07-12 10:37:33, Alan Stern wrote:
> > On Fri, 12 Jul 2013, Yanmin Zhang wrote:
> >
> > > On Thu, 2013-07-11 at 16:03 +0800, shuox@intel.com wrote:
> > > > From: Liu ShuoX
> >
On Sat, 2013-07-13 at 13:56 +0200, Pavel Machek wrote:
On Fri 2013-07-12 10:37:33, Alan Stern wrote:
On Fri, 12 Jul 2013, Yanmin Zhang wrote:
On Thu, 2013-07-11 at 16:03 +0800, shuox@intel.com wrote:
From: Liu ShuoX shuox@intel.com
In shutdown progress, system
On Thu, 2013-07-11 at 16:03 +0800, shuox@intel.com wrote:
> From: Liu ShuoX
>
> In shutdown progress, system is possible to do power transition
> (such as suspend-to-ram) in parallel. It is unreasonable. So,
> fixes it by adding a system_state checking and queue try_to_suspend
> again when
On Thu, 2013-07-11 at 16:03 +0800, shuox@intel.com wrote:
From: Liu ShuoX shuox@intel.com
In shutdown progress, system is possible to do power transition
(such as suspend-to-ram) in parallel. It is unreasonable. So,
fixes it by adding a system_state checking and queue try_to_suspend
On Sat, 2013-06-08 at 03:52 +0200, Rafael J. Wysocki wrote:
> On Saturday, June 08, 2013 09:36:03 AM Yanmin Zhang wrote:
> > On Sat, 2013-06-08 at 03:30 +0200, Rafael J. Wysocki wrote:
> > > On Friday, June 07, 2013 06:16:25 PM Greg KH wrote:
> > > > On Sat, Ju
On Fri, 2013-06-07 at 08:08 -0700, Greg KH wrote:
> On Fri, Jun 07, 2013 at 12:54:55PM +0800, Yanmin Zhang wrote:
> > On Thu, 2013-06-06 at 21:19 -0700, Greg KH wrote:
> > > On Fri, Jun 07, 2013 at 11:18:06AM +0800, Yanmin Zhang wrote:
> > > > On Thu, 2013-06-06
On Sat, 2013-06-08 at 03:30 +0200, Rafael J. Wysocki wrote:
> On Friday, June 07, 2013 06:16:25 PM Greg KH wrote:
> > On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
> > > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > > On Friday, J
On Fri, 2013-06-07 at 18:16 -0700, Greg KH wrote:
> On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
> > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > > dpm_run_ca
On Fri, 2013-06-07 at 18:15 -0700, Greg KH wrote:
> On Sat, Jun 08, 2013 at 08:43:55AM +0800, Yanmin Zhang wrote:
> > On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote:
> > > On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote:
>
On Sat, 2013-06-08 at 02:54 +0200, Rafael J. Wysocki wrote:
> On Saturday, June 08, 2013 08:42:12 AM Yanmin Zhang wrote:
> > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > > dpm
On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote:
> On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote:
> > From: ShuoX Liu
> >
> > dpm_run_callback could show more debug info around prepare stage.
>
> Why? Who needs this? What problem does it solve?
>
> Without answers to
On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > dpm_run_callback is used in other stages of power states changing.
> > It provides debug info message and time measurement when call these
> > callback. We also want to
On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
dpm_run_callback is used in other stages of power states changing.
It provides debug info message and time measurement when call these
callback. We also want to
On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote:
From: ShuoX Liu shuox@intel.com
dpm_run_callback could show more debug info around prepare stage.
Why? Who needs this? What problem does it solve?
Without
On Sat, 2013-06-08 at 02:54 +0200, Rafael J. Wysocki wrote:
On Saturday, June 08, 2013 08:42:12 AM Yanmin Zhang wrote:
On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
dpm_run_callback is used in other stages
On Fri, 2013-06-07 at 18:15 -0700, Greg KH wrote:
On Sat, Jun 08, 2013 at 08:43:55AM +0800, Yanmin Zhang wrote:
On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote:
From: ShuoX Liu shuox@intel.com
On Fri, 2013-06-07 at 18:16 -0700, Greg KH wrote:
On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
dpm_run_callback is used in other stages of power
On Sat, 2013-06-08 at 03:30 +0200, Rafael J. Wysocki wrote:
On Friday, June 07, 2013 06:16:25 PM Greg KH wrote:
On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
On Friday, June 07, 2013 04:20:30 PM shuox
On Fri, 2013-06-07 at 08:08 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 12:54:55PM +0800, Yanmin Zhang wrote:
On Thu, 2013-06-06 at 21:19 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 11:18:06AM +0800, Yanmin Zhang wrote:
On Thu, 2013-06-06 at 20:08 -0700, Greg KH wrote:
On Fri
On Sat, 2013-06-08 at 03:52 +0200, Rafael J. Wysocki wrote:
On Saturday, June 08, 2013 09:36:03 AM Yanmin Zhang wrote:
On Sat, 2013-06-08 at 03:30 +0200, Rafael J. Wysocki wrote:
On Friday, June 07, 2013 06:16:25 PM Greg KH wrote:
On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang
On Thu, 2013-06-06 at 21:19 -0700, Greg KH wrote:
> On Fri, Jun 07, 2013 at 11:18:06AM +0800, Yanmin Zhang wrote:
> > On Thu, 2013-06-06 at 20:08 -0700, Greg KH wrote:
> > > On Fri, Jun 07, 2013 at 10:37:52AM +0800, Yanmin Zhang wrote:
> > > > On Thu, 2013-06-06
On Thu, 2013-06-06 at 20:08 -0700, Greg KH wrote:
> On Fri, Jun 07, 2013 at 10:37:52AM +0800, Yanmin Zhang wrote:
> > On Thu, 2013-06-06 at 18:02 -0700, Greg KH wrote:
> > > On Fri, Jun 07, 2013 at 08:53:29AM +0800, Yanmin Zhang wrote:
> > > > On Thu, 2013-06-06 a
On Thu, 2013-06-06 at 18:02 -0700, Greg KH wrote:
> On Fri, Jun 07, 2013 at 08:53:29AM +0800, Yanmin Zhang wrote:
> > On Thu, 2013-06-06 at 15:18 +0200, Thomas Gleixner wrote:
> > > On Thu, 6 Jun 2013, shuox@intel.com wrote:
> > > > From: Zhang Yanmin
> >
On Thu, 2013-06-06 at 15:18 +0200, Thomas Gleixner wrote:
> On Thu, 6 Jun 2013, shuox@intel.com wrote:
> > From: Zhang Yanmin
> >
> > synchronize_irq waits pending IRQ handlers to be finished. If using this
> > function while holding a resource, the IRQ handler may cause deadlock.
> >
> >
On Wed, 2013-06-05 at 07:30 -0600, Bjorn Helgaas wrote:
> On Tue, Jun 4, 2013 at 6:38 PM, Yanmin Zhang
> wrote:
> > On Tue, 2013-06-04 at 12:04 -0600, Bjorn Helgaas wrote:
> >> I'm not sure where we are with this patch. I think Joseph initially
> >> reported a prob
On Wed, 2013-06-05 at 07:30 -0600, Bjorn Helgaas wrote:
On Tue, Jun 4, 2013 at 6:38 PM, Yanmin Zhang
yanmin_zh...@linux.intel.com wrote:
On Tue, 2013-06-04 at 12:04 -0600, Bjorn Helgaas wrote:
I'm not sure where we are with this patch. I think Joseph initially
reported a problem (though I
On Thu, 2013-06-06 at 15:18 +0200, Thomas Gleixner wrote:
On Thu, 6 Jun 2013, shuox@intel.com wrote:
From: Zhang Yanmin yanmin.zh...@intel.com
synchronize_irq waits pending IRQ handlers to be finished. If using this
function while holding a resource, the IRQ handler may cause
On Thu, 2013-06-06 at 18:02 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 08:53:29AM +0800, Yanmin Zhang wrote:
On Thu, 2013-06-06 at 15:18 +0200, Thomas Gleixner wrote:
On Thu, 6 Jun 2013, shuox@intel.com wrote:
From: Zhang Yanmin yanmin.zh...@intel.com
synchronize_irq
On Thu, 2013-06-06 at 20:08 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 10:37:52AM +0800, Yanmin Zhang wrote:
On Thu, 2013-06-06 at 18:02 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 08:53:29AM +0800, Yanmin Zhang wrote:
On Thu, 2013-06-06 at 15:18 +0200, Thomas Gleixner wrote
On Thu, 2013-06-06 at 21:19 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 11:18:06AM +0800, Yanmin Zhang wrote:
On Thu, 2013-06-06 at 20:08 -0700, Greg KH wrote:
On Fri, Jun 07, 2013 at 10:37:52AM +0800, Yanmin Zhang wrote:
On Thu, 2013-06-06 at 18:02 -0700, Greg KH wrote:
On Fri
On Tue, 2013-06-04 at 12:04 -0600, Bjorn Helgaas wrote:
> I'm not sure where we are with this patch. I think Joseph initially
> reported a problem (though I haven't actually seen that), and this
> patch fixed it, so it seems like there's something we want to do here.
Yes, indeed. We checked
On Tue, 2013-06-04 at 12:04 -0600, Bjorn Helgaas wrote:
I'm not sure where we are with this patch. I think Joseph initially
reported a problem (though I haven't actually seen that), and this
patch fixed it, so it seems like there's something we want to do here.
Yes, indeed. We checked Powerpc
On Mon, 2013-05-20 at 10:37 -0500, Linas Vepstas wrote:
> I think Joe Liu has it right. I'm going to top-post because things
> are a bit tangled below. I urge a review of
> /Documentation/PCI/pci-error-recovery.txt, as that gives the details.
>
> The intended sequence is that, after an error,
On Mon, 2013-05-20 at 16:48 -0600, Bjorn Helgaas wrote:
> On Fri, Apr 26, 2013 at 06:28:59AM +, Zhang, LongX wrote:
> > From: Zhang Long
> >
> > Specific pci device drivers might have many functions to call
> > pci_channel_offline to check device states. When slot_reset happens,
> > drivers'
On Mon, 2013-05-20 at 16:48 -0600, Bjorn Helgaas wrote:
On Fri, Apr 26, 2013 at 06:28:59AM +, Zhang, LongX wrote:
From: Zhang Long longx.zh...@intel.com
Specific pci device drivers might have many functions to call
pci_channel_offline to check device states. When slot_reset happens,
On Mon, 2013-05-20 at 10:37 -0500, Linas Vepstas wrote:
I think Joe Liu has it right. I'm going to top-post because things
are a bit tangled below. I urge a review of
/Documentation/PCI/pci-error-recovery.txt, as that gives the details.
The intended sequence is that, after an error, the
nas
>
> p.s. you didn't see my earlier reply because I forgot to hit 'plain text
> reply'
>
>
> On 2 May 2013 22:13, Yanmin Zhang wrote:
> >
> > On Thu, 2013-05-02 at 19:00 -0700, Greg Kroah-Hartman wrote:
> > > On Fri, May 03, 2013 at 08:33:00AM +0800, Ya
'plain text
reply'
On 2 May 2013 22:13, Yanmin Zhang yanmin_zh...@linux.intel.com wrote:
On Thu, 2013-05-02 at 19:00 -0700, Greg Kroah-Hartman wrote:
On Fri, May 03, 2013 at 08:33:00AM +0800, Yanmin Zhang wrote:
On Wed, 2013-05-01 at 20:20 -0500, Linas Vepstas wrote:
Hi
On Thu, 2013-05-02 at 19:00 -0700, Greg Kroah-Hartman wrote:
> On Fri, May 03, 2013 at 08:33:00AM +0800, Yanmin Zhang wrote:
> > On Wed, 2013-05-01 at 20:20 -0500, Linas Vepstas wrote:
> > > Hi,
> > >
> > > On 1 May 2013 19:30, Yanmin Zhang
> > > wro
On Wed, 2013-05-01 at 20:20 -0500, Linas Vepstas wrote:
> Hi,
>
> On 1 May 2013 19:30, Yanmin Zhang
> wrote:
> On Fri, 2013-04-26 at 06:28 +, Zhang, LongX wrote:
> > From: Zhang Long
> >
> > Specific pci device
On Wed, 2013-05-01 at 20:20 -0500, Linas Vepstas wrote:
Hi,
On 1 May 2013 19:30, Yanmin Zhang yanmin_zh...@linux.intel.com
wrote:
On Fri, 2013-04-26 at 06:28 +, Zhang, LongX wrote:
From: Zhang Long longx.zh...@intel.com
Specific pci device drivers
On Thu, 2013-05-02 at 19:00 -0700, Greg Kroah-Hartman wrote:
On Fri, May 03, 2013 at 08:33:00AM +0800, Yanmin Zhang wrote:
On Wed, 2013-05-01 at 20:20 -0500, Linas Vepstas wrote:
Hi,
On 1 May 2013 19:30, Yanmin Zhang yanmin_zh...@linux.intel.com
wrote:
On Fri, 2013-04-26
On Fri, 2013-04-26 at 06:28 +, Zhang, LongX wrote:
> From: Zhang Long
>
> Specific pci device drivers might have many functions to call
> pci_channel_offline to check device states. When slot_reset happens,
> drivers' slot_reset callback might call such functions and eventually
> abort the
On Fri, 2013-04-26 at 06:28 +, Zhang, LongX wrote:
From: Zhang Long longx.zh...@intel.com
Specific pci device drivers might have many functions to call
pci_channel_offline to check device states. When slot_reset happens,
drivers' slot_reset callback might call such functions and
On Mon, 2012-12-24 at 09:55 -0800, Greg KH wrote:
> On Mon, Dec 24, 2012 at 01:01:55PM +0800, he, bo wrote:
> > From: "he, bo"
> >
> > We often hit kernel panic issues on SMP machines because processes race
> > on multiple cpu. By adding a new parameter printk.cpu, kernel prints
> > cpu number
On Mon, 2012-12-24 at 09:55 -0800, Greg KH wrote:
On Mon, Dec 24, 2012 at 01:01:55PM +0800, he, bo wrote:
From: he, bo bo...@intel.com
We often hit kernel panic issues on SMP machines because processes race
on multiple cpu. By adding a new parameter printk.cpu, kernel prints
cpu number
On Tue, 2012-10-30 at 18:27 +0800, Chuansheng Liu wrote:
> We encounted one BUG_ON() issue at function __run_hrtimer(),
> but the panic info is not enough to find out which hrtimer
> users use the hrtimer wrongly.
> (in this BUG_ON case, it is callback running at the same time
> hrtimer_start() is
On Tue, 2012-10-30 at 18:27 +0800, Chuansheng Liu wrote:
We encounted one BUG_ON() issue at function __run_hrtimer(),
but the panic info is not enough to find out which hrtimer
users use the hrtimer wrongly.
(in this BUG_ON case, it is callback running at the same time
hrtimer_start() is
On Fri, 2012-10-26 at 14:09 +0200, Thomas Gleixner wrote:
> On Fri, 26 Oct 2012, Zhang, Yanmin wrote:
> > >From: Thomas Gleixner [mailto:t...@linutronix.de]
> > >Your code is returning HRTIMER_RESTART from the timer callback and at
> > >the same time it starts the timer from some other context.
On Fri, 2012-10-26 at 14:09 +0200, Thomas Gleixner wrote:
On Fri, 26 Oct 2012, Zhang, Yanmin wrote:
From: Thomas Gleixner [mailto:t...@linutronix.de]
Your code is returning HRTIMER_RESTART from the timer callback and at
the same time it starts the timer from some other context. That's what
RTIMER_STATE_ENQUEUED,
which causes the BUG_ON(timer->state != HRTIMER_STATE_CALLBACK) checking fails.
The patch fixes it by checking only bit HRTIMER_STATE_CALLBACK and also bypass
enqueue_hrtimer when the timer is queued.
Signed-off-by: Yanmin Zhang
Signed-off-by: He Bo
---
kernel/hrtimer.c |
On Fri, 2012-10-26 at 10:51 +0800, he, bo wrote:
> From: Yanmin Zhang
>
> We hit a kernel panic at __run_hrtimer=>BUG_ON(timer->state !=
> HRTIMER_STATE_CALLBACK).
> <2>[ 10.226053, 3] kernel BUG at
> /home/android/xiaobing/ymz/r4/hardware/intel/linux-2
On Fri, 2012-10-26 at 10:51 +0800, he, bo wrote:
From: Yanmin Zhang yanmin.zh...@intel.com
We hit a kernel panic at __run_hrtimer=BUG_ON(timer-state !=
HRTIMER_STATE_CALLBACK).
2[ 10.226053, 3] kernel BUG at
/home/android/xiaobing/ymz/r4/hardware/intel/linux-2.6/kernel/hrtimer.c:1228
HRTIMER_STATE_CALLBACK and also bypass
enqueue_hrtimer when the timer is queued.
Signed-off-by: Yanmin Zhang yanmin_zh...@linux.intel.com
Signed-off-by: He Bo bo...@intel.com
---
kernel/hrtimer.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel
On Thu, 2012-10-25 at 00:33 +0200, Rafael J. Wysocki wrote:
> On Wednesday 24 of October 2012 15:13:27 Greg Kroah-Hartman wrote:
> > On Wed, Oct 24, 2012 at 09:46:19PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday 16 of October 2012 23:28:08 zhanglong wrote:
> > > > We hit an hang issue when
On Thu, 2012-10-25 at 00:33 +0200, Rafael J. Wysocki wrote:
On Wednesday 24 of October 2012 15:13:27 Greg Kroah-Hartman wrote:
On Wed, Oct 24, 2012 at 09:46:19PM +0200, Rafael J. Wysocki wrote:
On Tuesday 16 of October 2012 23:28:08 zhanglong wrote:
We hit an hang issue when removing a
On Tue, 2012-10-16 at 23:28 +0800, zhanglong wrote:
> We hit an hang issue when removing a mmc device on Medfield Android phone by
> sysfs interface.
>
> device_pm_remove will call pm_runtime_remove which would disable
> runtime PM of the device. After that pm_runtime_get* or
> pm_runtime_put*
On Tue, 2012-10-16 at 23:28 +0800, zhanglong wrote:
We hit an hang issue when removing a mmc device on Medfield Android phone by
sysfs interface.
device_pm_remove will call pm_runtime_remove which would disable
runtime PM of the device. After that pm_runtime_get* or
pm_runtime_put* will be
On Mon, 2012-10-15 at 22:59 +0200, Rafael J. Wysocki wrote:
> On Monday 15 of October 2012 15:39:49 Yanmin Zhang wrote:
> > On Fri, 2012-09-21 at 01:58 +, Zhang, LongX wrote:
> > > From: LongX Zhang
> > >
> > > device_pm_remove will call pm_runtime_remove
On Mon, 2012-10-15 at 22:59 +0200, Rafael J. Wysocki wrote:
On Monday 15 of October 2012 15:39:49 Yanmin Zhang wrote:
On Fri, 2012-09-21 at 01:58 +, Zhang, LongX wrote:
From: LongX Zhang longx.zh...@intel.com
device_pm_remove will call pm_runtime_remove which would disable
On Fri, 2012-09-21 at 01:58 +, Zhang, LongX wrote:
> From: LongX Zhang
>
> device_pm_remove will call pm_runtime_remove which would disable
> runtime PM of the device. After that pm_runtime_get* or
> pm_runtime_put* will be ingored. So if we disable the runtime PM
> before device really be
On Fri, 2012-09-21 at 01:58 +, Zhang, LongX wrote:
From: LongX Zhang longx.zh...@intel.com
device_pm_remove will call pm_runtime_remove which would disable
runtime PM of the device. After that pm_runtime_get* or
pm_runtime_put* will be ingored. So if we disable the runtime PM
before
On Tue, 2012-08-14 at 06:55 +, Liu, Chuansheng wrote:
> From: liu chuansheng
> Subject: [PATCH] x86/fixup_irq: using the cpu_online_mask instead of
> cpu_all_mask
>
> When one CPU is going down, and this CPU is the last one in irq affinity,
> current code is setting cpu_all_mask as the new
On Tue, 2012-08-14 at 06:55 +, Liu, Chuansheng wrote:
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] x86/fixup_irq: using the cpu_online_mask instead of
cpu_all_mask
When one CPU is going down, and this CPU is the last one in irq affinity,
current code is setting
; AP busy wait for it. At present, AP will wait for 2 seconds then panic.
>
> This patch let AP waits until BSP finish the startup sequence and gives
> WARNING when BSP is preempted more than 2 seconds.
>
> Signed-off-by: Yanmin Zhang
> Signed-off-by: Lin Chen
> ---
>
.
This patch let AP waits until BSP finish the startup sequence and gives
WARNING when BSP is preempted more than 2 seconds.
Signed-off-by: Yanmin Zhang yanmin_zh...@linux.intel.com
Signed-off-by: Lin Chen linx.z.c...@intel.com
---
arch/x86/kernel/smpboot.c | 11 ++-
1 files
seconds then panic.
> >
> > This patch let AP waits until BSP finish the startup sequence and gives
> > WARNING when BSP is preempted more than 2 seconds.
> >
> > Signed-off-by: Yanmin Zhang
> > Signed-off-by: Lin Chen
> > ---
> > arch/x86/
than 2 seconds.
Signed-off-by: Yanmin Zhang yanmin_zh...@linux.intel.com
Signed-off-by: Lin Chen linx.z.c...@intel.com
---
arch/x86/kernel/smpboot.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel
72 matches
Mail list logo
