The original cpu_hotplug.txt documents describing CPU hotplug support in
Linux kernel. it was moved in to core-api/ and renamed cpu_hotplug.rst.
Update it's link in other documents
Fixes: ff58fa7f556c ("Documentation: Update CPU hotplug and move it to
core-api")
Signed-off-by:
The acpi_duplicate_processor_id() is only called in acpi_processor_get_info(),
So move it in front of acpi_processor_get_info() and make it static.
Signed-off-by: Dou Liyang <douly.f...@cn.fujitsu.com>
---
drivers/acpi/acpi_processor.c | 62 +--
i
Kernel uses the possible_cpus in command line to reset the possible_cpus bits
in cpu_possible_map. It doesn't be recorded in the kernel-parameters.txt
Add its description in this document, also replace the wrong option
additional_cpus
with possible_cpus in cpu-gotplug-spec.
Signed-off-by: Dou
ux/commits/Dou-Liyang/ACPI-processor-Get-accurate-possible-CPU-count/20180316-140349
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G
caused below changes (please refer to attached dmesg/kmsg for entire
log
Hi Peter,
At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
How about:
possible_cpus= [s390,x86_64] Set the number of possible CPUs which
are determined by the ACPI tables MADT or mptables by
default
At 03/21/2018 05:34 PM, Dou Liyang wrote:
Hi Peter,
At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
How about:
possible_cpus= [s390,x86_64] Set the number of possible CPUs which
are determined by the ACPI tables MADT
Hi Peter,
At 03/20/2018 08:39 PM, Peter Zijlstra wrote:
On Tue, Mar 20, 2018 at 07:04:30PM +0800, Dou Liyang wrote:
case 1: no | no | no | --> min (setup_possible_cpus, nr_cpu_ids,
setup_max_cpus)
case 2: no | no | yes| --> min (setup_possible_cpus, nr_cpu_ids)
case 3: no
Hi Peter,
At 03/20/2018 08:37 PM, Peter Zijlstra wrote:
On Tue, Mar 20, 2018 at 07:04:28PM +0800, Dou Liyang wrote:
+ possible_cpus= [s390,x86_64] Use this to set hotpluggable cpus.
+ This option sets possible_cpus bits in cpu_possible_map
seting the affinity mask and the managed flag.
So, decouple the managed flag from the affinity mask, add a new bitmap to
differentiate between managed and unmanaged interrupts.
Reported-by: Kashyap Desai
Reported-by: Sumit Saxena
Suggested-by: Thomas Gleixner
Signed-off-by: Dou Liyang
Hi Kashyap,
On 2018/9/20 16:39, Kashyap Desai worte:
Dou - Do you want me to test your patch or shall I wait for next version
?
I'm sorry, please wait for the next version.
Thanks,
dou
be mapped as unmanaged
interrupts. So, only transfering the irq affinity assignments is not enough.
Add a new bit "is_managed" to convey the info in irq_affinity_desc and use
it in alloc_descs().
Reported-by: Kashyap Desai
Reported-by: Sumit Saxena
Signed-off-by: Dou Liyang
---
inc
of spreading managed
flags.
Suggested-by: Thomas Gleixner
Suggested-by: Bjorn Helgaas
Signed-off-by: Dou Liyang
---
drivers/pci/msi.c | 9 -
include/linux/interrupt.h | 14 --
include/linux/irq.h | 6 --
include/linux/irqdomain.h | 6 --
include/linux/msi.h
is_managed : 1; |
| }; |
| |
+--+
[1]:https://marc.info/?l=linux-kernel=153543887027997=2
Dou Liyang (3):
genirq/affinity: Add a new interrupt affinity descriptor
irq/affinity: Add
In case of irq_default_affinity != cpu_possible_mask, setting the affinity
for the pre/post vectors to irq_default_affinity is a breakage.
Just set the pre/post vectors to cpu_possible_mask and be done with it.
Suggested-by: Thomas Gleixner
Signed-off-by: Dou Liyang
---
kernel/irq/affinity.c
Hi Bjorn,
on 2018/11/29 4:00, Bjorn Helgaas wrote:
[+cc linux-pci]
Since you mention reports, are there URLs to mailing list archives you
can include?
OK, I will add it:
https://marc.info/?l=linux-kernel=153543887027997=2
- entry = alloc_msi_entry(>dev, nvec, masks);
+ entry =
Hi Thomas,
On 2018/11/29 6:03, Thomas Gleixner wrote:
+ affi_desc = kcalloc(nvec, sizeof(*affi_desc), GFP_KERNEL);
Why do you want to do that separate allocation here? Just let
I thought the irq_create_affinity_desc() also can be called by other
functions which may convert
allows to expand this in the future without touching all the
functions ever again, just modify the data irq_affinity_desc structure.
Reported-by: Kashyap Desai
Reported-by: Sumit Saxena
Suggested-by: Thomas Gleixner
Signed-off-by: Dou Liyang
---
Changelog:
v2 --> v3
- Create a
From: Dou Liyang
As Kashyap and Sumit reported, in MSI/-x subsystem, the pre/post vectors
may be used to some extra reply queues for performance. the best way to
map the pre/post vectors is map them to the local numa node.
But, current Linux can't do that, because
The pre and post vectors
At 08/10/2018 10:35 AM, Dou Liyang wrote:
When compiling kernel with SMP disabled, the build warns with:
kernel/sched/core.c: In function ‘update_rq_clock_task’:
kernel/sched/core.c:139:17: warning: unused variable ‘irq_delta’
[-Wunused-variable]
s64 steal = 0, irq_delta = 0;
Fix
Dear Thomas,
On 2018/9/17 23:32, Thomas Gleixner wrote:
[...]
I think it's still worthwhile to do that, but the changelog needs a major
overhaul as right now it's outright misleading. I'll just amend it with
something along the above lines, unless someone disagrees.
Yeah, Yes, right, I was
pu_to_logical_apicid, cpu) =
logical_smp_processor_id();
Thanks,
dou
arch/x86/kernel/apic/apic.c:1507:2: note: each undeclared identifier is
reported only once for each function it appears in
vim +/i +1507 arch/x86/kernel/apic/apic.c
2066f4d6 arch/x86/kernel/apic/apic.c Dou Liyang
This is a tiny cleanup patchset for setup_local_APIC().
Dou Liyang (3):
x86/apic: Move pending intr check code into it's own function
x86/apic: Replace common tools with new ones
x86/apic: Drop the logical_smp_processor_id()
arch/x86/include/asm/smp.h | 10 -
arch/x86/kernel/apic
The pending interrupt check code is old, update the following.
-Replace for-if pair with for_each_set_bit()
-Replace printk() with pr_err()
Also merge the printk's code in one line and make curly braces balanced
Suggested-by: Andy Shevchenko
Signed-off-by: Dou Liyang
Reviewed-by: Andy
The logical_smp_processor_id() which is only called in setup_local_APIC()
on x86_32 system looks redundant.
Drop it, then directly use GET_APIC_LOGICAL_ID() marco and more suitable
variable name for readability
Signed-off-by: Dou Liyang
---
arch/x86/include/asm/smp.h | 10 --
arch/x86
the pending interrupt check code is mixed with the local APIC setup code,
that looks messy.
Extract the related code, move it into a new function named
apic_pending_intr_clear().
Signed-off-by: Dou Liyang
Reviewed-by: Andy Shevchenko
---
changelog:
v4 --> v5:
- Fix undeclared 'i' er
Hi All,
At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy wrote:
On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote:
Then looks this issue need to fix by making possible CPU count
accurate
because there are other resources allocated according
Hi Rafael,
Thank you so much for your reply.
At 03/13/2018 05:25 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 4:11 AM, Dou Liyang wrote:
Hi Thomas,
At 03/09/2018 11:08 PM, Thomas Gleixner wrote:
[...]
I'm not sure if there is a clear indicator whether physcial hotplug
Hi Artem,
At 03/14/2018 11:29 AM, Dou Liyang wrote:
Hi All,
At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy
wrote:
On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote:
Then looks this issue need to fix by making possible CPU count
accurate
Hi Artern,
At 03/14/2018 05:07 PM, Artem Bityutskiy wrote:
On Wed, 2018-03-14 at 12:11 +0800, Dou Liyang wrote:
At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy
Longer term, yeah, I agree. Kernel's notion of possible CPU
count
should
the possible CPU count from the number of Local APIC
entries in ACPI MADT. It doesn't consider with the ACPI namespace and
reports unrealistically high numbers.
Depth-first search the namespace tree, check and collect the correct CPUs
and update the possible map
Signed-off-by: Dou Liyang
---
drivers
Hi Andy,
At 03/15/2018 01:24 AM, Andy Shevchenko wrote:
On Wed, Mar 14, 2018 at 12:28 PM, Dou Liyang wrote:
+static void __init acpi_update_possible_map(void)
+{
+ unsigned int cpu, nr = 0;
+
+ if (nr_cpu_ids <= nr_unique_ids)
+ ret
-first search the namespace tree, check and collect the correct CPUs
and update the possible map.
Signed-off-by: Dou Liyang
---
Changelog v1 --> v2:
-Optimize the code by Andy Shevchenko's suggestion
-modify the changelog
drivers/acpi/acpi_processor.c | 21 +
1 file chan
Hi Eric,
At 02/14/2018 01:40 AM, Eric W. Biederman wrote:
Dou Liyang writes:
Hi Baoquan,
At 02/12/2018 11:08 AM, Eric W. Biederman wrote:
Baoquan He writes:
This is a regression fix.
Before, to fix erratum AVR31, commit 522e66464467 ("x86/apic: Disable
I/O APIC before shu
the pending interrupt check code is mixed with the local APIC setup code,
that looks messy.
Extract the related code, move it into a new function named
apic_pending_intr_clear().
Signed-off-by: Dou Liyang
---
arch/x86/kernel/apic/apic.c | 98 -
1
This function isn't used outside of apic.c, so let's mark it static.
Signed-off-by: Dou Liyang
---
arch/x86/include/asm/apic.h | 1 -
arch/x86/kernel/apic/apic.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index
Hi Thomas,
At 03/09/2018 11:08 PM, Thomas Gleixner wrote:
[...]
I'm not sure if there is a clear indicator whether physcial hotplug is
supported or not, but the ACPI folks (x86) and architecture maintainers
+cc Rafael
should be able to answer that question. I have a machine which says:
Hi Ingo, Kees, Baoquan and Chao
At 03/12/2018 06:57 PM, Ingo Molnar wrote:
[...]
So there's apparently a mis-design here:
- KASLR needs to be done very early on during bootup: - it's not realistic to
expect KASLR to be done with a booted up kernel, because pointers to various
Kernel uses the possible_cpus in command line to reset the possible_cpus bits
in cpu_possible_map. It doesn't be recorded in the kernel-parameters.txt
Add its description in this document, also replace the wrong option
additional_cpus
with possible_cpus in cpu-gotplug-spec.
Signed-off-by: Dou
the walk break after walking pass the first processor.
Repace the value with AE_OK which is the standard acpi_status value.
Fixes 8c8cb30f49b8 ("acpi/processor: Implement DEVICE operator for processor
enumeration")
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 4 ++
),
- two cleapup work (the 3th and 5th patch)
- a bug fix for CPU hotplug(4th patch)
Dou Liyang (5):
x86/smpboot: Add the missing description of possible_cpus
x86/cpu_hotplug: Update the link of cpu_hotplug.rst
x86/smpboot: Make the check code more clear in prefill_possible_map()
acpi
The acpi_duplicate_processor_id() is only called in acpi_processor_get_info(),
So move it in front of acpi_processor_get_info() and make it static.
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 62 +--
include/linux/acpi.h | 3
The original cpu_hotplug.txt documents describing CPU hotplug support in
Linux kernel. it was moved in to core-api/ and renamed cpu_hotplug.rst.
Update it's link in other documents
Fixes: ff58fa7f556c ("Documentation: Update CPU hotplug and move it to
core-api")
Signed-off-by:
to follow.
Isolate them, and check them linearly.
No functionary change, Prepare for cutting the number of possible CPUs
Signed-off-by: Dou Liyang
---
Situations:
setup_possible_cpus == -1 | setup_max_cpus == 0 | CONFIG_HOTPLUG_CPU == y |
yes | yes
Hi Peter,
At 03/20/2018 08:37 PM, Peter Zijlstra wrote:
On Tue, Mar 20, 2018 at 07:04:28PM +0800, Dou Liyang wrote:
+ possible_cpus= [s390,x86_64] Use this to set hotpluggable cpus.
+ This option sets possible_cpus bits in cpu_possible_map
Hi Peter,
At 03/20/2018 08:39 PM, Peter Zijlstra wrote:
On Tue, Mar 20, 2018 at 07:04:30PM +0800, Dou Liyang wrote:
case 1: no | no | no | --> min (setup_possible_cpus, nr_cpu_ids,
setup_max_cpus)
case 2: no | no | yes| --> min (setup_possible_cpus, nr_cpu_ids)
case 3: no
Hi Peter,
At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
How about:
possible_cpus= [s390,x86_64] Set the number of possible CPUs which
are determined by the ACPI tables MADT or mptables by
default
At 03/21/2018 05:34 PM, Dou Liyang wrote:
Hi Peter,
At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
How about:
possible_cpus= [s390,x86_64] Set the number of possible CPUs which
are determined by the ACPI tables MADT
Hi Maintainers,
I have a question about "__ref" in Linux kernel.
When I looked into the __irq_alloc_descs(), I found it tagged a
"__ref" mark, but I didn't find that it referenced code or data
from init section.
So, I confuse why the "__ref" is needed in __irq_alloc_descs()?
any other
Hi Thomas,
At 03/15/2018 09:45 PM, Thomas Gleixner wrote:
[...]
I tested this on a machine which claims to have gazillion of hotplugable
CPUs:
I really appreciate your test.
smpboot: Allowing 152 CPUs, 120 hotplug CPUs
setup_percpu: NR_CPUS:512 nr_cpumask_bits:512
Hi Stephen,
At 03/16/2018 01:37 PM, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, yesterday's linux-next build (x86_64 allnoconfig)
produced this warning:
kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used
[-Wunused-function]
static bool
Hi Stephen,
At 03/16/2018 01:52 PM, Dou Liyang wrote:
Hi Stephen,
At 03/16/2018 01:37 PM, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, yesterday's linux-next build (x86_64
allnoconfig)
produced this warning:
kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined
n Rothwell
Signed-off-by: Dou Liyang
---
kernel/cpu.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index a1860d42aacf..db7ec7572348 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -126,15 +126,6 @@ struct cpuhp_step {
static DE
At 03/16/2018 03:59 PM, Thomas Gleixner wrote:
On Fri, 16 Mar 2018, Dou Liyang wrote:
Commit 17a2f1ced028 ("cpu/hotplug: Merge cpuhp_bp_states and cpuhp_ap_states")
removed the last use of cpuhp_is_atomic_state() in common case, that caused
Kernel produced a warning:
'cpuhp_i
,maxcpus=16,sockets=2,cores=4,threads=2
...
When a new CPU bringups a new core, for each core in package, Linux
increments the booted_cores for this new cpu in set_cpu_sibling_map().
Due to the uncleared booted_cores, this incorrect number of CPU cores
will be shown.
Tested-by: Dou Liyang
topology_sibling_cpumask() is the correct thread-related topology
information in the kernel.
S/topology_sibling_mask/topology_sibling_cpumask
Signed-off-by: Dou Liyang
---
Documentation/x86/topology.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86
.
Remove the code of the X86_LOCAL_APIC=n case to simplify it.
Signed-off-by: Dou Liyang
---
arch/x86/kernel/idt.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c
index 2c3a1b4294eb..8b4174890706 100644
--- a/arch/x86
The macro FPU_IRQ has never been used since v3.10, So remove it.
Signed-off-by: Dou Liyang
---
arch/x86/include/asm/irq_vectors.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/irq_vectors.h
b/arch/x86/include/asm/irq_vectors.h
index 57003074bd7a..548d90bbf919 100644
Hi Jan,
At 04/27/2018 03:21 PM, Jan Beulich wrote:
Hello,
I've just stumbled across this commit, and I'm wondering if that's actually
correct (I too have at least one system where such IDs are reported in
MADT): For offline/absent CPUs, the firmware may not know the APIC IDs
The MADT table
pointless.
Merge the two function to avoid this situation and make the code simplify.
Signed-off-by: Dou Liyang
---
arch/x86/kernel/apic/vector.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
At 04/27/2018 08:09 PM, Jan Beulich wrote:
On 27.04.18 at 10:32, wrote:
At 04/27/2018 03:21 PM, Jan Beulich wrote:
I've just stumbled across this commit, and I'm wondering if that's actually
correct (I too have at least one system where such IDs are reported in
MADT): For offline/absent
Hi Jan,
At 05/02/2018 02:39 PM, Jan Beulich wrote:
On 02.05.18 at 03:56, wrote:
At 04/27/2018 08:09 PM, Jan Beulich wrote:
I'm afraid I don't understand: Limiting the number of disabled CPUs is
certainly desirable when those can never be used, but why would you
want to do this when they
Before the patch, After the patch
the first processor(ID=89)
hot-addfailedsuccess
the others processor(ID=89)
hot-add failed failed
So, What's your idea about it.
Dou Liyang (1)
of the duplicate processor, the others can be ignored).
So, Remove the check code.
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 126 --
include/linux/acpi.h | 3 -
2 files changed, 129 deletions(-)
diff --git a/drivers/acpi
Commit a7be6e5a7f8d ("mm: drop useless local parameters of
__register_one_node()") removes the last user of parent_node().
The parent_node() macro in SUPERH platform is unnecessary.
Remove it for cleanup.
Reported-by: Michael Ellerman
Signed-off-by: Dou Liyang
Cc: Yoshinori Sato
Commit a7be6e5a7f8d ("mm: drop useless local parameters of
__register_one_node()") removes the last user of parent_node().
The parent_node() macro in IA64(Itanium) platform is unnecessary.
Remove it for cleanup.
Reported-by: Michael Ellerman
Signed-off-by: Dou Liyang
Cc: Ton
ato
Cc: Rich Felker
Cc: linux...@vger.kernel.org
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Chris Metcalf
Cc: Arnd Bergmann
Cc: linux-a...@vger.kernel.org
Cc: a...@linux-foundation.org
Dou Liyang (7):
ia64: topology: Remove the unused parent_node() macro
MIPS:
Commit a7be6e5a7f8d ("mm: drop useless local parameters of
__register_one_node()") removes the last user of parent_node().
The parent_node() macro in SPARC64 platform is unnecessary.
Remove it for cleanup.
Reported-by: Michael Ellerman
Signed-off-by: Dou Liyang
Acked-by: David S.
Commit a7be6e5a7f8d ("mm: drop useless local parameters of
__register_one_node()") removes the last user of parent_node().
The parent_node() macros in both IP27 and Loongson64 are unnecessary.
Remove it for cleanup.
Reported-by: Michael Ellerman
Signed-off-by: Dou Liyang
Cc: Ralf B
Commit a7be6e5a7f8d ("mm: drop useless local parameters of
__register_one_node()") removes the last user of parent_node().
The parent_node() macro in tile platform is unnecessary.
Remove it for cleanup.
Reported-by: Michael Ellerman
Signed-off-by: Dou Liyang
Acked-by: Chris Metcalf
Commit a7be6e5a7f8d ("mm: drop useless local parameters of
__register_one_node()") removes the last user of parent_node().
The parent_node() macro in S390 platform is unnecessary.
Remove it for cleanup.
Reported-by: Michael Ellerman
Signed-off-by: Dou Liyang
Acked-by: Heiko Ca
Commit a7be6e5a7f8d ("mm: drop useless local parameters of
__register_one_node()") removes the last user of parent_node().
The parent_node() macro in generic situation is unnecessary.
Remove it for cleanup.
Reported-by: Michael Ellerman
Signed-off-by: Dou Liyang
Cc: Arnd Bergmann
Hi Ralf,
At 09/01/2017 04:42 PM, Ralf Baechle wrote:
On Fri, Sep 01, 2017 at 10:56:34AM +0800, Dou Liyang wrote:
Commit a7be6e5a7f8d ("mm: drop useless local parameters of
__register_one_node()") removes the last user of parent_node().
The parent_node() macros in both IP27 and
;.
Thanks,
dou.
At 09/29/2017 11:00 PM, Dou Liyang wrote:
Hi, Pasha
At 09/28/2017 09:11 PM, Pasha Tatashin wrote:
It will be best if we can support TSC sync capability in x86, but
seems
is not easy.
Sure, your hardware achieving sync would be best, but even if it does
not, we can sti
Hi Michael,
At 07/25/2017 05:09 PM, Michael Ellerman wrote:
Dou Liyang writes:
... initializes local parameters "p_node" & "parent" for
register_node().
But, register_node() does not use them.
Remove the related code of "parent" node, cleanup __register_o
Hi,
At 07/14/2017 01:52 PM, Dou Liyang wrote:
Linux uses acpi_early_init() to put the ACPI table management into
the late stage from the early stage where the mapped ACPI tables is
temporary and should be unmapped.
But, now initializing interrupt delivery mode should map and parse the
DMAR
Hi Baoquan,
At 07/27/2017 02:08 PM, b...@redhat.com wrote:
On 07/26/17 at 08:19pm, Dou Liyang wrote:
Hi Baoquan,
[...]
I am looking for Thinkpad x121e (AMD E-450 APU) to test. I have tested
it in Thinkpad s430, It's OK.
BTY, I am confused how does the ACPI subsystem affect PIT which
Hi Peter,
At 09/28/2017 02:09 AM, Peter Zijlstra wrote:
On Wed, Sep 27, 2017 at 08:05:48PM +0200, Peter Zijlstra wrote:
On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
We do not want to do that. Because, we use "notsc" to support Dynamic
Reconfiguration[1].
AFAIK, th
Hi, Pasha
At 09/28/2017 09:11 PM, Pasha Tatashin wrote:
It will be best if we can support TSC sync capability in x86, but seems
is not easy.
Sure, your hardware achieving sync would be best, but even if it does
not, we can still use TSC. Using notsc simple because you fail to sync
TSCs is
ted.
[1] https://marc.info/?l=linux-kernel=151188084018443=2
Thanks,
dou.
--->8---
From: Ville Syrjälä
This reverts commit b371ae0d4a194b178817b0edfb6a7395c7aec37a.
Causes my P3 UP machine to hang at boot with "lapic".
Cc: Do
gone
wrong in your bisecting.
Agree.
I CC'ed Dou Liyang. He has changed the early APIC setup code and there has
been an issue reported already. Though I lost track of that. Dou, any
Is it this one?
https://marc.info/?l=linux-kernel=151188084018443
pointers
Hi Ville,
At 11/28/2017 10:53 PM, Ville Syrjala wrote:
From: Ville Syrjälä
This reverts commit b371ae0d4a194b178817b0edfb6a7395c7aec37a.
Causes my P3 UP machine to hang at boot with "lapic".
Cc: Dou Liyang
Cc: Thomas Gleixner
Cc: ying...@kernel.org
Cc: b...@redhat.com
Cc: Ingo
Hi Alexandru,
At 12/21/2017 10:23 AM, Alexandru Chirvasitu wrote:
This might be more helpful. I ran another bisect with the following
final log:
---
git bisect start
# bad: [d6ffc6ac83b1f9f12652d89b9cb5bcbfbea7796c] x86/vector: Respect affinity
mask in irq descriptor
git bisect bad
Hi Thomas,
At 12/23/2017 09:32 PM, Thomas Gleixner wrote:
[...]
The BUG_ON panic happens at line 147:
BUG_ON(!test_and_clear_bit(bit, cm->alloc_map));
I'm sure Thomas and Dou know it better than me.
I'll have a look after the holidays.
Merry Christmas! :-)
I am
replacing an legacy vector which may
not allocated in a cpumap->alloc_map[] with a system vector will trigger
the BUGON();
Remove the BUGON().
Signed-off-by: Dou Liyang
---
kernel/irq/matrix.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/irq/matrix.c b
Hi Alexandru,
Thanks for testing !
At 12/28/2017 12:18 AM, Alexandru Chirvasitu wrote:
As per instructions, I did the following:
(1)
Checked out
464e1d5 Linux 4.15-rc5
(after getting my copy up to date, fetching, pulling ,etc.) and
compiled it as-is. Config attached (the one labeled 'np'
t I am not familiar with it and have no idea.
Thanks,
dou.
-8<
>From 57d8543ea4dcf2a53b1c37757da12866a52aaf57 Mon Sep 17 00:00:00 2001
From: Dou Liyang
Date: Thu, 28 Dec 2017 16:20:48 +0800
Subject: [PATCH] x86/vector
lock_init() hook called after
jump_label_init() instead of doing the call inside of
smp_prepare_boot_cpu().
Signed-off-by: Juergen Gross
---
Based on kernel/git/tip/tip.git locking/core
Just a quick ping: what's the conclusion of the discussion, do we want this
patch
as-is?
Dou Liyang (CC-ed
us(). Make the
setup later to avoid the WARN().
Reported-by: Juergen Gross
Suggested-by: Juergen Gross
Signed-off-by: Dou Liyang
---
arch/x86/kernel/smpboot.c | 3 ++-
arch/x86/xen/smp_pv.c | 2 ++
arch/x86/xen/spinlock.c | 6 --
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git
), and set
the value in xen_init_lock_cpu() to make the setup later and avoid the
WARN().
Reported-by: Juergen Gross
Suggested-by: Juergen Gross
Signed-off-by: Dou Liyang
Reviewed-by: Juergen Gross
---
changelog:
v1-->v2: remove the native_pv_lock_init() from xen_pv_smp
Commit:
f110711a6053 ("irqdomain: Convert irqdomain-%3Eof_node to fwnode")
converted of_node field to fwnode, but didn't update its comments.
Update it.
Signed-off-by: Dou Liyang
---
include/linux/irqdomain.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Fengguang,
There are two different warning.
At 10/30/2017 03:35 PM, Fengguang Wu wrote:
On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote:
Hi Linus,
Up to now we see the below boot error/warnings when testing v4.14-rc6.
The original warning:
Hi Pavel,
At 11/03/2017 01:26 AM, Pavel Tatashin wrote:
tsc_disabled is set when notsc is passed as kernel parameter. The reason we
have notsc is to avoid timing problems on multi-preccors systems. However,
we already have a mechanism to detect and resolve these issues by invoking
tsc unstable
Hi Pavel,
At 11/03/2017 01:26 AM, Pavel Tatashin wrote:
tsc_early_init():
Determines offset, shift and multiplier for the early clock based on the
TSC frequency.
tsc_early_fini()
Implement the finish part of early tsc feature, prints message about the
offset, which can be useful to find out
Hi Pavel,
At 11/09/2017 11:01 AM, Pavel Tatashin wrote:
read_boot_clock64() returns a boot start timestamp from epoch. Some arches
may need to access the persistent clock interface in order to calculate the
epoch offset. The resolution of the persistent clock, however, might be
low. Therefore,
Hi Pavel,
At 11/09/2017 11:02 AM, Pavel Tatashin wrote:
This patch adds early clock feature to x86 platforms.
tsc_early_init():
Determines offset, shift and multiplier for the early clock based on the
TSC frequency.
tsc_early_fini()
Implement the finish part of early tsc feature, prints
path. Thus, make notsc to behave the same as tsc=unstable.
Signed-off-by: Pavel Tatashin
I am not sure if I could add the signature.
Anyway, it looks good to me.
Reviewed-by: Dou Liyang
---
arch/x86/kernel/tsc.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions
Commit:
ba26621e63ce ("time: Remove duplicated code in ktime_get_raw_and_real()")
... got rid of ktime_get_raw_and_real_ts64(), but left its declaration
behind.
Remove it.
Signed-off-by: Dou Liyang
---
include/linux/timekeeping.h | 6 --
1 file changed, 6 deletions(-)
Hi Pavel,
At 08/12/2017 02:50 AM, Pavel Tatashin wrote:
In Linux printk() can output timestamps next to every line. This is very
useful for tracking regressions, and finding places that can be optimized.
However, the timestamps are available only later in boot. On smaller
machines it is
At 09/06/2017 04:03 PM, Baoquan He wrote:
On 09/06/17 at 01:41pm, Dou Liyang wrote:
Hi Baoquan,
At 09/06/2017 01:26 PM, Baoquan He wrote:
[...]
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 4f63afc..9f8479c 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86
d
chip in our pc.
After passing the check of (1), we in (2), check whether local APIC
is detected or not, If we have a BIOS bug.
[1] Commit 8312136fa8b0("x86, apic: Fix missed handling of discrete apics")
At 09/06/2017 06:17 PM, Baoquan He wrote:
Hi Dou,
On 08/28/17 at 11:20am, Dou
501 - 600 of 1151 matches
Mail list logo
