|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Crash in acpi_ps_peek_opcode when booting kernel 3.19 as Xen dom0
On 05.02.2015 15:33, Stefan Bader wrote:
> While experimenting/testing various kernel versions I discovered that trying
> to
> boot a Haswell based hosts will always crash when booting as Xen dom0
> (Xen-4.4.1). The same crash happens since v3.19-rc1 and still does happen with
> v3.19-rc7. A bare metal boot is having no issues and also an Opteron based
> host
> is having no issues (dom0 and bare metal).
> Could be a table that the other host does not have and since its only
> happening
> in dom0 maybe some cpu capability that needs to be passed on?
I think I may have some more data here. I tried some patches which Juergen sent
me, but those were not changing much. I found that the problem is related on
that host to the use of dom0_mem= and may be a crash like below or a hang or
"weird state" in general.
When not using dom0_mem, I can boot with a 3.19 kernel, otherwise (trying 512M
and 1G) there is trouble. What is special about this host is that is has more
"holes" than the other machine I usually use.
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009a400 (usable)
(XEN) 000000000009a400 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
The first hole is common
(XEN) 0000000000100000 - 0000000030a48000 (usable)
(XEN) 0000000030a48000 - 0000000030a49000 (reserved)
(XEN) 0000000030a49000 - 00000000a27f4000 (usable)
But then normally there is only one usable area up to
around ACPI_NVS
(XEN) 00000000a27f4000 - 00000000a2ab4000 (reserved)
(XEN) 00000000a2ab4000 - 00000000a2fb4000 (ACPI NVS)
(XEN) 00000000a2fb4000 - 00000000a2feb000 (ACPI data)
(XEN) 00000000a2feb000 - 00000000a3000000 (usable)
(XEN) 00000000a3000000 - 00000000afa00000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fec00000 - 00000000fec01000 (reserved)
(XEN) 00000000fed00000 - 00000000fed04000 (reserved)
(XEN) 00000000fed10000 - 00000000fed1a000 (reserved)
(XEN) 00000000fed1c000 - 00000000fed20000 (reserved)
(XEN) 00000000fed84000 - 00000000fed85000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffc00000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 000000024e600000 (usable)
Also after ACPI data there is some usable, and then another
hole (area) which is unuasual.
So I added a bit more debug printk's: Here a boot with dom0_mem=512M:max=512M:
[ 0.000000] SMB: remap 154(0x9A)-256(0x100) -> 131072(0x20000)
==> 0x09A000-0x100000 -> 0x20000000 (@512M+)
==> 0x09A000-0x09A3FF was usable but partial
The first hole is supposed to be remapped as it is below the 512M which are in
the initial MFN list. I suppose this works but Juergen, I really would love to
understand how and I am not sure I grasp things. To me it looks like the remap
info is stored in the memory area to be mapped... which is reserved(?!)
I think the problem comes from these other holes (which are beyond 512M). When
not using dom0_mem those are remapped (like the first one), while with the clamp
they supposedly should be identity mapped...
[ 0.000000] SMB: prange id 199240(0x30A48) - 199241(0x30A49)
==> 0x30A48000(~778M)
[ 0.000000] SMB: prange id 665588(0xA27F4) - 667627(0xA2FEB)
==> 0xA27F4000(~2599M)
[ 0.000000] SMB: prange id 667648(0xA3000) - 1048576(0x100000)
==> 0xA3000000(~2608M)-0x100000000(=4G) id mapped
[ 0.000000] Released 0 page(s)
[ 0.000000] Remapped 102 page(s)
So here is xen_set_identity_and_remap_chunk():
...
while (i < n) {
...
/* Do not remap pages beyond the current allocation */
if (cur_pfn >= nr_pages) {
/* Identity map remaining pages */
set_phys_range_identity(cur_pfn, cur_pfn + size);
break;
}
...
Now, I think the call to set_phys_range_identity() is really doing nothing
because nr_pages really is the same (or mostly beside of an 512 alignment) as
xen_p2m_size, so it just returns 0.
...
/*
* If the PFNs are currently mapped, the VA mapping also needs
* to be updated to be 1:1.
*/
for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
(void)HYPERVISOR_update_va_mapping(
(unsigned long)__va(pfn << PAGE_SHIFT),
mfn_pte(pfn, PAGE_KERNEL_IO), 0);
I cannot make my head up about this one. Before this all changed, there was code
that resembled this loop but was rather clearing the mapping (except for a range
below 1M). Ok, that was done then in a different order which set identity
mapping after...
My feeling is that the problem comes from assuming identity mapping for holes
after the initial mapping. I might miss something but I cannot really see where
this could be recovered.
-Stefan
>
> [ 2.108038] ACPI: Core revision 20141107
> [ 2.108153] ACPI Warning: Unsupported module-level executable opcode 0x91
> at
> table offset 0x002B (20141107/psloop-225)
> [ 2.108264] ACPI Warning: Unsupported module-level executable opcode 0x91
> at
> table offset 0x0033 (20141107/psloop-225)
> [ 2.108375] ACPI Warning: Unsupported module-level executable opcode 0x95
> at
> table offset 0x0038 (20141107/psloop-225)
> [ 2.108489] ACPI Warning: Unsupported module-level executable opcode 0x95
> at
> table offset 0x0041 (20141107/psloop-225)
> [ 2.108613] ACPI Warning: Unsupported module-level executable opcode 0x7D
> at
> table offset 0x040D (20141107/psloop-225)
> [ 2.108751] BUG: unable to handle kernel paging request at ffffc90000ee74e0
> [ 2.108835] IP: [<ffffffff814573db>] acpi_ps_peek_opcode+0xd/0x1f
> [ 2.108902] PGD 1f4be067 PUD 1f4bd067 PMD 1488f067 PTE 0
> [ 2.109018] Oops: 0000 [#1] SMP
> [ 2.109094] Modules linked in:
> [ 2.109153] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 3.19.0-031900rc7-generi
> c #201502020035
> [ 2.109220] Hardware name: Intel Corporation Shark Bay Client
> platform/Flathe
> ad Creek Crb, BIOS HSWLPTU1.86C.0109.R03.1301282055 01/28/2013
> [ 2.109295] task: ffffffff81c1c500 ti: ffffffff81c00000 task.ti:
> ffffffff81c0
> 0000
> [ 2.109360] RIP: e030:[<ffffffff814573db>] [<ffffffff814573db>]
> acpi_ps_peek
> _opcode+0xd/0x1f
> [ 2.109445] RSP: e02b:ffffffff81c03ce8 EFLAGS: 00010283
> [ 2.109490] RAX: 000000000000000c RBX: ffff880014887000 RCX:
> ffffffff81c03d50
> [ 2.109539] RDX: ffffc90000ee74e0 RSI: ffff880014887030 RDI:
> ffff880014887030
> [ 2.109587] RBP: ffffffff81c03ce8 R08: ffffea0000522600 R09:
> ffffffff81432c4f
> [ 2.109635] R10: ffff880014899090 R11: 00000000000000ba R12:
> ffff880014887030
> [ 2.109684] R13: ffff880014887000 R14: ffffffff81c03d50 R15:
> 000000000000000d
> [ 2.109735] FS: 0000000000000000(0000) GS:ffff880018c00000(0000)
> knlGS:00000
> 00000000000
> [ 2.109836] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 2.109881] CR2: ffffc90000ee74e0 CR3: 0000000001c15000 CR4:
> 0000000000042660
> [ 2.109930] Stack:
> [ 2.109968] ffffffff81c03d38 ffffffff81456537 ffffffff81c03d28
> ffffffff81457
> a40
> [ 2.110104] ffff880014887000 ffff880014887000 ffff8800148990c0
> ffffc90000ee7
> 4e0
> [ 2.110238] ffff880014887030 0000000000000000 ffffffff81c03d78
> ffffffff81456
> 760
> [ 2.110373] Call Trace:
> [ 2.110413] [<ffffffff81456537>] acpi_ps_get_next_arg+0x114/0x1f9
> [ 2.110461] [<ffffffff81457a40>] ? acpi_ps_pop_scope+0x54/0x72
> [ 2.110508] [<ffffffff81456760>] acpi_ps_get_arguments+0x91/0x228
> [ 2.110555] [<ffffffff81456ad2>] acpi_ps_parse_loop+0x1db/0x311
> [ 2.110602] [<ffffffff81457705>] acpi_ps_parse_aml+0x96/0x275
> [ 2.110649] [<ffffffff8145322f>] acpi_ns_one_complete_parse+0xf7/0x114
> [ 2.110698] [<ffffffff817d149a>] ? _raw_spin_lock_irqsave+0x1a/0x60
> [ 2.110746] [<ffffffff8145326c>] acpi_ns_parse_table+0x20/0x38
> [ 2.110792] [<ffffffff81452c20>] acpi_ns_load_table+0x4c/0x90
> [ 2.110840] [<ffffffff817c50b5>] acpi_tb_load_namespace+0xa6/0x14a
> [ 2.110889] [<ffffffff81d83269>] acpi_load_tables+0xc/0x35
> [ 2.110935] [<ffffffff81454bf6>] ? acpi_ns_get_node+0xb7/0xc9
> [ 2.110982] [<ffffffff81d825cf>] acpi_early_init+0x73/0x105
> [ 2.111029] [<ffffffff81d3b083>] start_kernel+0x348/0x3f0
> [ 2.111075] [<ffffffff81d3abcd>] ? set_init_arg+0x56/0x56
> [ 2.111121] [<ffffffff81d3a5f8>] x86_64_start_reservations+0x2a/0x2c
> [ 2.111169] [<ffffffff81d3e88c>] xen_start_kernel+0x4f5/0x4f7
> [ 2.111215] Code: 8a 87 60 05 87 81 5d c3 e8 73 cc 37 00 55 81 ff 00 01 00
> 00
> 19 c0 48 89 e5 83 c0 02 5d c3 e8 5d cc 3
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
>
Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |