lkml.org 
[lkml]   [2017]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [LKP] [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid
On Wed, Feb 22, 2017 at 09:56:51AM +0800, Dou Liyang wrote:
> Hi, Xiaolong
>
> At 02/21/2017 03:10 PM, Ye Xiaolong wrote:
> > On 02/21, Ye Xiaolong wrote:
> > > On 02/20, Dou Liyang wrote:
> > > > Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time.
> > > > It keeps consistent with the WorkQueue and avoids some bugs which may be caused
> > > > by the dynamic assignment.
> > > > As we know, It is implemented by the patches as follows: 2532fc318d, f7c28833c2,
> > > > 8f54969dc8, 8ad893faf2, dc6db24d24, which depend on ACPI table. Simply speaking:
> > > >
> > > > Step 1. Make the "Logical CPU ID <-> Processor ID/UID" fixed Using MADT:
> > > > We generate the logical CPU IDs by the Local APIC/x2APIC IDs orderly and
> > > > get the mapping of Processor ID/UID <-> Local Apic ID directly in MADT.
> > > > So, we get the mapping of
> > > > *Processor ID/UID <-> Local Apic ID <-> Logical CPU ID*
> > > >
> > > > Step 2. Make the "Processor ID/UID <-> Node ID(_PXM)" fixed Using DSDT:
> > > > The maaping of "Processor ID/UID <-> Node ID(_PXM)" is ready-made in
> > > > each entities. we just use it directly.
> > > >
> > > > So, at last we get the maaping of *Node ID <-> Logical CPU ID* according to
> > > > step1 and step2:
> > > > *Node ID(_PXM) <-> Processor ID/UID <-> Local Apic ID <-> Logical CPU ID*
> > > >
> > > > But, The ACPI table is unreliable and it is very risky that we use the entity
> > > > which isn't related to a physical device at booting time. Here has already two
> > > > bugs we found.
> > > > 1. Duplicated Processor IDs in DSDT.
> > > > It has been fixed by commit 8e089eaa19, fd74da217d.
> > > > 2. The _PXM in DSDT is inconsistent with the one in MADT.
> > > > It may cause the bug, which is shown in:
> > > > https://lkml.org/lkml/2017/2/12/200
> > > > There may be more later. We shouldn't just only fix them everytime, we should
> > > > solve this problem from the source to avoid such problems happend again and
> > > > again.
> > > >
> > > > Now, a simple and easy way is found, we revert our patches. Do the Step 2
> > > > at hot-plug time, not at booting time where we did some useless work.
> > > >
> > > > It also can make the mapping of "cpuid <-> nodeid" fixed and avoid excessive
> > > > use of the ACPI table.
> > > >
> > > > We have tested them in our box: Fujitsu PQ2000 with 2 nodes for hot-plug.
> > > > To Xiaolong:
> > > > Please help me to test it in the special machine.
> > >
> > > Got it, I'll queue the tests on the previous machine and let you know the result
> > > once I get it.
> >
> > Previous kernel panic and incomplete run issue (described in [1]) in 0day
> > system is gone with this series.
> >
>
> Thanks very much, I am glad to hear that!
>
> > Tested-by: Xiaolong Ye <xiaolong.ye@intel.com>
> >
>
> I will add it in my next version.

What is the status of the patch?

I still get oops during boot on a EP machine with today's Linus tree's
head commit 69eea5a4ab9c("Merge branch 'for-linus' of git://git.kernel.dk/linux-block")

The first oops call trace:

... ...
[ 8.599850] pci_bus 0000:80: on NUMA node 2
[ 8.605611] ACPI: Enabled 4 GPEs in block 00 to 3F
[ 8.645521] BUG: unable to handle kernel paging request at 000000000001f768
[ 8.653585] IP: get_partial_node+0x2c/0x1f0
[ 8.659302] PGD 0
[ 8.659303]
[ 8.663724] Oops: 0000 [#1] SMP
[ 8.667499] Modules linked in:
[ 8.671181] CPU: 60 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc1 #1
[ 8.678554] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
[ 8.690672] task: ffff88202bc10000 task.stack: ffffc9000002c000
[ 8.697542] RIP: 0010:get_partial_node+0x2c/0x1f0
[ 8.703844] RSP: 0000:ffffc9000002fb20 EFLAGS: 00010006
[ 8.709944] RAX: 0000000000000002 RBX: 0000000000000000 RCX: 00000000014080c0
[ 8.718184] RDX: ffff88203281f740 RSI: 000000000001f760 RDI: ffff88202e548280
[ 8.726422] RBP: ffffc9000002fbc0 R08: 0000000000000000 R09: 0000000100220022
[ 8.734661] R10: ffffea0080a99600 R11: 0000000000000000 R12: ffff88202e548280
[ 8.742896] R13: ffffea0080a991c0 R14: ffff88202e548280 R15: ffff88203281f730
[ 8.751144] FS: 0000000000000000(0000) GS:ffff882032800000(0000) knlGS:0000000000000000
[ 8.760633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8.767312] CR2: 000000000001f768 CR3: 0000000001e09000 CR4: 00000000001406e0
[ 8.775550] Call Trace:
[ 8.778548] ? acpi_os_release_lock+0xe/0x10
[ 8.783590] ? acpi_ut_update_ref_count+0x5a/0x6b3
[ 8.789210] ___slab_alloc+0x28a/0x4b0
[ 8.793660] ? __kernfs_new_node+0x41/0xc0
[ 8.798505] ? __kernfs_new_node+0x41/0xc0
[ 8.803348] __slab_alloc+0x20/0x40
[ 8.807501] kmem_cache_alloc+0x17f/0x1c0
[ 8.812231] __kernfs_new_node+0x41/0xc0
[ 8.816882] kernfs_new_node+0x26/0x50
[ 8.821338] __kernfs_create_file+0x2c/0xa0
[ 8.826269] sysfs_add_file_mode_ns+0x99/0x180
[ 8.831500] sysfs_create_file_ns+0x2a/0x30
[ 8.836433] bus_create_file+0x47/0x70
[ 8.840893] bus_register+0xe4/0x280
[ 8.845157] ? sfi_init+0x1b0/0x1b0
[ 8.849321] ? set_debug_rodata+0x12/0x12
[ 8.854064] pnp_init+0x10/0x12
[ 8.857829] do_one_initcall+0x43/0x180
[ 8.862383] ? set_debug_rodata+0x12/0x12
[ 8.867118] kernel_init_freeable+0x19d/0x22a
[ 8.872259] ? rest_init+0x90/0x90
[ 8.876324] kernel_init+0xe/0x100
[ 8.880389] ret_from_fork+0x2c/0x40
[ 8.884643] Code: 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 e4 f0 48 83 ec 70 48 85 f6 48 c7 44 24 20 00 00 00 00 0f 84 87 01 00 00 <48> 83 7e 08 00 0f 84 7c 01 00 00 48 89 f3 49 89 fd 48 89 f7 89
[ 8.906422] RIP: get_partial_node+0x2c/0x1f0 RSP: ffffc9000002fb20
[ 8.914356] CR2: 000000000001f768
... ...

Thanks,
Aaron

\
 
 \ /
  Last update: 2017-03-16 09:16    [W:1.085 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site