Re: [Xen-devel] 3.16-rc2 WARNING: CPU: 0 PID: 0 at arch/x86/xen/multicalls.c:129 xen_mc_flush+0x1ab/0x1c0()

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Monday, June 30, 2014, 6:29:30 PM, you wrote:

> On 06/29/2014 05:53 AM, Sander Eikelenboom wrote:
>> Friday, June 27, 2014, 4:15:30 PM, you wrote:
>>
>>> On Thu, Jun 26, 2014 at 12:16:43PM -0400, Boris Ostrovsky wrote:
>>>> On 06/26/2014 07:57 AM, Sander Eikelenboom wrote:
>>>>> Hi,
>>>>>
>>>>> Got the warning below on dom0 boot with a 3.16-rc2 kernel, doesn't seem 
>>>>> to do
>>>>> much immediate harm:
>>>>>
>>>>> [   12.723393] Calibrating delay loop (skipped), value calculated using 
>>>>> timer frequency.. 6402.05 BogoMIPS (lpj=10667280)
>>>>> [   12.723414] pid_max: default: 32768 minimum: 301
>>>>> [   12.723433] ACPI: Core revision 20140424
>>>>> [   12.740681] ACPI: All ACPI Tables successfully acquired
>>>>> [   12.743145] ------------[ cut here ]------------
>>>>> [   12.743170] WARNING: CPU: 0 PID: 0 at arch/x86/xen/multicalls.c:129 
>>>>> xen_mc_flush+0x1ab/0x1c0()
>>>>> [   12.743186] Modules linked in:
>>>>> [   12.743196] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
>>>>> 3.16.0-rc2-20140626+ #1
>>>>> [   12.743209] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
>>>>> V1.8B1 09/13/2010
>>>>> [   12.743223]  0000000000000009 ffffffff82203d88 ffffffff81afdba7 
>>>>> ffffffff822184e0
>>>>> [   12.743242]  0000000000000000 ffffffff82203dc8 ffffffff810bfdb2 
>>>>> ffffffff81007858
>>>>> [   12.743261]  0000000000000000 0000000000000001 0000000000000000 
>>>>> ffff88005f60b120
>>>>> [   12.743280] Call Trace:
>>>>> [   12.743290]  [<ffffffff81afdba7>] dump_stack+0x46/0x58
>>>>> [   12.743302]  [<ffffffff810bfdb2>] warn_slowpath_common+0x82/0xb0
>>>>> [   12.743316]  [<ffffffff81007858>] ? pte_pfn_to_mfn+0x88/0xa0
>>>>> [   12.743328]  [<ffffffff810bfdf5>] warn_slowpath_null+0x15/0x20
>>>>> [   12.743341]  [<ffffffff81004b6b>] xen_mc_flush+0x1ab/0x1c0
>>>>> [   12.743353]  [<ffffffff810072fd>] xen_alloc_pte+0x1ad/0x220
>>>>> [   12.743364]  [<ffffffff8100886b>] ? xen_make_pte+0x1b/0x70
>>>>> [   12.743378]  [<ffffffff81014a6f>] init_espfix_ap+0x22f/0x3f0
>>>>> [   12.743392]  [<ffffffff8232079d>] init_espfix_bsp+0xee/0xf3
>>>>> [   12.743404]  [<ffffffff82317ffe>] start_kernel+0x3d6/0x441
>>>>> [   12.743416]  [<ffffffff82317a27>] ? set_init_arg+0x58/0x58
>>>>> [   12.743428]  [<ffffffff82317608>] x86_64_start_reservations+0x2a/0x2c
>>>>> [   12.743441]  [<ffffffff8231af8e>] xen_start_kernel+0x59b/0x59d
>>>>> [   12.743468] ---[ end trace 20d3292a87f35842 ]---
>>>>> [   12.743943] Dentry cache hash table entries: 262144 (order: 9, 2097152 
>>>>> bytes)
>>>>> [   12.744726] Inode-cache hash table entries: 131072 (order: 8, 1048576 
>>>>> bytes)
>>>>> [   12.745043] Mount-cache hash table entries: 4096 (order: 3, 32768 
>>>>> bytes)
>>>>> [   12.745064] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 
>>>>> bytes)
>>>>> [   12.745709] Initializing cgroup subsys freezer
>>>>> [   12.745733] Initializing cgroup subsys blkio
>>>>>
>>>>> If you need more info / complete logs, give me a call.
>>>> This is caused by hpa's ESP fix for 16-bit programs leaking SP bits from
>>>> 64-bit kernels (commit 3891a04aafd668686239349ea58f3314ea2af86b).
>>>>
>>>> It's harmless in the sense that the only effect is that the workaround 
>>>> won't
>>>> get enabled.
>>> But oddly enough it only shows up on certain machines. I am wondering
>>> if the issue is some E820 is not rounded up to a page size and we allocate
>>> for the ESPFIX an not-4KB (ie, we cross-over) page. Hopefully the E820
>>> will shed the light.
>> I think it could be related to this in xl dmesg (sorry .. somehow didn't 
>> notice
>> it before):
>>
>> (XEN) [2014-06-29 09:43:48.956] mm.c:1215:d0v0 Global bit is set to kernel 
>> page 7fe8d2ffb9
>> (XEN) [2014-06-29 09:43:48.956] mm.c:766:d0v0 Bad L1 flags 400000
>> (XEN) [2014-06-29 09:43:48.956] mm.c:1222:d0v0 Failure in alloc_l1_table: 
>> entry 3
>> (XEN) [2014-06-29 09:43:48.956] mm.c:2100:d0v0 Error while validating mfn 
>> 5469ad (pfn 59850) for type 1000000000000000: caf=8000000000000003 
>> taf=1000000000000001
>> (XEN) [2014-06-29 09:43:48.956] mm.c:2996:d0v0 Error while pinning mfn 5469ad

> It almost certainly is related. Most likely result of espfix code 
> creating translations for the page that it allocates. At least that's 
> what it was last time I looked at this.

Any proposed way to get it fixed ?

--
Sander

> -boris
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel