From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Crash in acpi_ps_peek_opcode when booting kernel 3.19 as Xen dom0 Date: Fri, 27 Feb 2015 12:29:43 +0100 Message-ID: <54F05527.9010603@canonical.com> References: <54D37F1E.5060208@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6190221250755275531==" Return-path: In-Reply-To: <54D37F1E.5060208@canonical.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "xen-devel@lists.xensource.com" Cc: Juergen Gross List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============6190221250755275531== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RBpdU2nUcKx1J1frGX0LudXtWR8rn10OR" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RBpdU2nUcKx1J1frGX0LudXtWR8rn10OR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 05.02.2015 15:33, Stefan Bader wrote: > While experimenting/testing various kernel versions I discovered that t= rying 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 happ= en with > v3.19-rc7. A bare metal boot is having no issues and also an Opteron ba= sed host > is having no issues (dom0 and bare metal). > Could be a table that the other host does not have and since its only h= appening > 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 Juerge= n sent me, but those were not changing much. I found that the problem is related= on that host to the use of dom0_mem=3D and may be a crash like below or a ha= ng 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=3D512M:ma= x=3D512M: [ 0.000000] SMB: remap 154(0x9A)-256(0x100) -> 131072(0x20000) =3D=3D> 0x09A000-0x100000 -> 0x20000000 (@512M+) =3D=3D> 0x09A000-0x09A3FF was usable but partial The first hole is supposed to be remapped as it is below the 512M which a= re in the initial MFN list. I suppose this works but Juergen, I really would lo= ve 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 th= e clamp they supposedly should be identity mapped... [ 0.000000] SMB: prange id 199240(0x30A48) - 199241(0x30A49) =3D=3D> 0x30A48000(~778M) [ 0.000000] SMB: prange id 665588(0xA27F4) - 667627(0xA2FEB) =3D=3D> 0xA27F4000(~2599M) [ 0.000000] SMB: prange id 667648(0xA3000) - 1048576(0x100000) =3D=3D> 0xA3000000(~2608M)-0x100000000(=3D4G) id mapped [ 0.000000] Released 0 page(s) [ 0.000000] Remapped 102 page(s) So here is xen_set_identity_and_remap_chunk(): =2E.. while (i < n) { ... /* Do not remap pages beyond the current allocation */ if (cur_pfn >=3D 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 nothin= g 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 =3D start_pfn; pfn <=3D 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 w= as 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 h= oles after the initial mapping. I might miss something but I cannot really see= where this could be recovered. -Stefan >=20 > [ 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 ffffc9000= 0ee74e0 > [ 2.108835] IP: [] 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-031900r= c7-generi > c #201502020035 > [ 2.109220] Hardware name: Intel Corporation Shark Bay Client platfo= rm/Flathe > ad Creek Crb, BIOS HSWLPTU1.86C.0109.R03.1301282055 01/28/2013 > [ 2.109295] task: ffffffff81c1c500 ti: ffffffff81c00000 task.ti: fff= fffff81c0 > 0000 > [ 2.109360] RIP: e030:[] [] acp= i_ps_peek > _opcode+0xd/0x1f > [ 2.109445] RSP: e02b:ffffffff81c03ce8 EFLAGS: 00010283 > [ 2.109490] RAX: 000000000000000c RBX: ffff880014887000 RCX: fffffff= f81c03d50 > [ 2.109539] RDX: ffffc90000ee74e0 RSI: ffff880014887030 RDI: ffff880= 014887030 > [ 2.109587] RBP: ffffffff81c03ce8 R08: ffffea0000522600 R09: fffffff= f81432c4f > [ 2.109635] R10: ffff880014899090 R11: 00000000000000ba R12: ffff880= 014887030 > [ 2.109684] R13: ffff880014887000 R14: ffffffff81c03d50 R15: 0000000= 00000000d > [ 2.109735] FS: 0000000000000000(0000) GS:ffff880018c00000(0000) kn= lGS:00000 > 00000000000 > [ 2.109836] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 2.109881] CR2: ffffc90000ee74e0 CR3: 0000000001c15000 CR4: 0000000= 000042660 > [ 2.109930] Stack: > [ 2.109968] ffffffff81c03d38 ffffffff81456537 ffffffff81c03d28 ffff= ffff81457 > a40 > [ 2.110104] ffff880014887000 ffff880014887000 ffff8800148990c0 ffff= c90000ee7 > 4e0 > [ 2.110238] ffff880014887030 0000000000000000 ffffffff81c03d78 ffff= ffff81456 > 760 > [ 2.110373] Call Trace: > [ 2.110413] [] acpi_ps_get_next_arg+0x114/0x1f9 > [ 2.110461] [] ? acpi_ps_pop_scope+0x54/0x72 > [ 2.110508] [] acpi_ps_get_arguments+0x91/0x228 > [ 2.110555] [] acpi_ps_parse_loop+0x1db/0x311 > [ 2.110602] [] acpi_ps_parse_aml+0x96/0x275 > [ 2.110649] [] acpi_ns_one_complete_parse+0xf7/0x= 114 > [ 2.110698] [] ? _raw_spin_lock_irqsave+0x1a/0x60= > [ 2.110746] [] acpi_ns_parse_table+0x20/0x38 > [ 2.110792] [] acpi_ns_load_table+0x4c/0x90 > [ 2.110840] [] acpi_tb_load_namespace+0xa6/0x14a > [ 2.110889] [] acpi_load_tables+0xc/0x35 > [ 2.110935] [] ? acpi_ns_get_node+0xb7/0xc9 > [ 2.110982] [] acpi_early_init+0x73/0x105 > [ 2.111029] [] start_kernel+0x348/0x3f0 > [ 2.111075] [] ? set_init_arg+0x56/0x56 > [ 2.111121] [] x86_64_start_reservations+0x2a/0x2= c > [ 2.111169] [] 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 >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >=20 --RBpdU2nUcKx1J1frGX0LudXtWR8rn10OR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJU8FUuAAoJEOhnXe7L7s6jxpEP/ic1FRG5jHQErqEbPDN7t/MR Zf8MTfLolmQ3mQY/F5pNSGci812LXvMvceFmBHQ+BWg9BlnnGC4PHns/ZPHopZws eUGIU+5xgj/2xoIwzhByso+TpoiWtJzae5KahTRdWaMtF5Ar3AKyLn/BxKrg6iaN 85fQ7zFr/7KNxG9IpNRwWJsxC1W5o6MhCkDj5mfqMaD/smNqMP/g9yd0sl1TTvLk uDuCvRmxbbBaDXVswCb2eY6R0eb3hiqxr4ZrePYVVx1c2A0StcGYUbCu2A5MJ9ks b4QxNgAmBAK0SDAI8d5WUBhn1S4P4Qmncatz6GEr/yM1sdmVasPmXfyXupbyctAB WqZnQekrIzAycCZDS2ZabzszEn2vuxJBWBhuFlonDQPQsw4QGzLlR2AGJMTv1o2i W0VJnuSosP5viyNrG8mVsJOHXVYNKMreVKFEu2QQdIgcVgn4DTw86zFQOmXCnG3D B/8mg0zCyuEOCjCvEsMKm34+P3bbYcRf2Yvv1FF+hV8KUNil5ObcSppIbt4L5y1U uQ4ZNoUN6Tv0Av2iIfrMp9VIuKIzLCSKTvJYIF4O/62VBJ03e/84sjb9yvuGqrBZ 9lTgqs0vW9f1kDY+lXxRfjI4R/hbVn3ezC8UdqOa+VX6hRf1AYPjmI581PYAmPQx uLFkTSGSZpGtPQpO33M3 =GoBy -----END PGP SIGNATURE----- --RBpdU2nUcKx1J1frGX0LudXtWR8rn10OR-- --===============6190221250755275531== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6190221250755275531==--