Carsten Schiers
2010-Sep-08 12:15 UTC
[Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
Hi, I repeat to report this issue, because Jeremy thinks it might be more a Xen related issue. Also I missed to provide the comunity with an excerpt of the log, for those only able to read quickly through their mails: Xen 4.0.1 self compiled on Debian Lenny 5.0.5 64 Bit, 2.6.32.18 and 2.6.32.21 pvops kernel boots well w/o Xen, but reports the following error (complete log attached): [ 3.478270] ACPI: Power Button [PWRB] [ 3.549779] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 3.550689] ACPI: Power Button [PWRF] [ 3.617753] ACPI: SSDT 00000000bbfb00b0 00235 (v01 DpgPmm P001Ist 00000011 INTL 20051117) [ 3.668512] ACPI: SSDT 00000000bbfb02f0 00235 (v01 DpgPmm P002Ist 00000012 INTL 20051117) (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 5555555555555555) from L1 entry 8000000080000473 for l1e_owner=0, pg_owner=32753 [ 3.719125] BUG: unable to handle kernel paging request at ffffc90000062000 [ 3.719125] IP: [<ffffffff81223d03>] acpi_ex_system_memory_space_handler+0x16e/0x1cf [ 3.719125] PGD 1f80f067 PUD 1f854067 PMD 1f855067 PTE 0 [ 3.719125] Oops: 0000 [#1] SMP [ 3.719125] last sysfs file: [ 3.719125] CPU 0 [ 3.719125] Modules linked in: [ 3.719125] Pid: 1, comm: swapper Not tainted 2.6.32.21 #2 To Be Filled By O.E.M. [ 3.719125] RIP: e030:[<ffffffff81223d03>] [<ffffffff81223d03>] acpi_ex_system_memory_space_handler+0x16e/0x1cf [ 3.719125] RSP: e02b:ffff88001f86b9a0 EFLAGS: 00010246 [ 3.719125] RAX: ffffc90000062000 RBX: 0000000000001000 RCX: 0000000000000040 [ 3.719125] RDX: ffffc90000062000 RSI: 0000000000000001 RDI: 8000000080000273 [ 3.719125] RBP: ffff88001f86b9d0 R08: ffffffff8165a270 R09: 0000000000000068 [ 3.719125] R10: 0000000000080000 R11: 0000000000000001 R12: 0000000080000000 [ 3.719125] R13: ffff88001f9a6a40 R14: 0000000000000008 R15: ffff88001f86ba88 [ 3.719125] FS: 0000000000000000(0000) GS:ffff880002120000(0000) knlGS:0000000000000000 [ 3.719125] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 3.719125] CR2: ffffc90000062000 CR3: 0000000001001000 CR4: 0000000000000660 [ 3.719125] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.719125] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 3.719125] Process swapper (pid: 1, threadinfo ffff88001f86a000, task ffff88001f870000) [ 3.719125] Stack: [ 3.719125] 0000000000000000 ffffffff81223b95 ffff88001ee22288 ffff88001f8624c8 [ 3.719125] <0> ffff88001ee22048 0000000000000000 ffff88001f86ba30 ffffffff8121c7a1 [ 3.719125] <0> 0000000000000024 ffff88001f86ba88 0000000000000008 0000000000000000 [ 3.719125] Call Trace: [ 3.719125] [<ffffffff81223b95>] ? acpi_ex_system_memory_space_handler+0x0/0x1cf [ 3.719125] [<ffffffff8121c7a1>] acpi_ev_address_space_dispatch+0x176/0x1c3 [ 3.719125] [<ffffffff8121f6ac>] acpi_ex_load_op+0x93/0x254 [ 3.719125] [<ffffffff812226a7>] ? acpi_ex_resolve_operands+0x1e5/0x4e2 [ 3.719125] [<ffffffff81221fcf>] acpi_ex_opcode_1A_1T_0R+0x28/0x4e Would be glad if anybody has an idea, even if it is only how to proceed. BR, Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Sep-08 12:51 UTC
Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>> On 08.09.10 at 14:15, Carsten Schiers <carsten@schiers.de> wrote: > (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 5555555555555555) from L1 > entry 8000000080000473 for l1e_owner=0, pg_owner=32753DOMID_IO seen here generally means that Dom0 tried to map a page it doesn''t own (likely because of your use of dom0_mem=). As the page really is a RAM one, Xen doesn''t allow the access. Given that this apparently happens in the context of acpi_ex_system_memory_space_handler() you''d have to look at (or provide) your DSDT and SSDT(s) to see where this reference comes from. Very likely this is just a bogus reference, that you get away with on native, perhaps because this code in ioremap.c last_pfn = last_addr >> PAGE_SHIFT; for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) { int is_ram = page_is_ram(pfn); if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn))) return NULL; WARN_ON_ONCE(is_ram); } should result in returning NULL there, while it wouldn''t cover the situation under Xen. (While the code is meaningless under Xen in its current shape anyway, using dom0_mem= with a value above 2G should get you around the issue, as then PFN 0x80000 would be considered RAM there too.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Sep-08 20:15 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
Hi, no change when I set e.g. to dom0_mem=3000M (see below and in log. In log, I also tried 196M, same result).> you''d have to look at (or > provide) your DSDT and SSDT(s) to see where this reference comes > from.Sorry, my OS knowledge is on Andrew''s Minix book niveau: how to provide? BR, Carsten. [ 3.830424] ACPI: Power Button [PWRF] [ 3.897249] ACPI: SSDT 00000000bbfb00b0 00235 (v01 DpgPmm P001Ist 00000011 INTL 20051117) [ 3.947683] ACPI: SSDT 00000000bbfb02f0 00235 (v01 DpgPmm P002Ist 00000012 INTL 20051117) (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 7c9ec) from L1 entry 8000000080000473 for l1e_owner=0, pg_owner=32753 [ 3.998293] BUG: unable to handle kernel paging request at ffffc90000062000 [ 3.998293] IP: [<ffffffff81258492>] acpi_ex_system_memory_space_handler+0x16d/0x1df [ 3.998293] PGD bb80d067 PUD bb80e067 PMD bb80f067 PTE 0 [ 3.998293] Oops: 0000 [#1] SMP [ 3.998293] last sysfs file: [ 3.998293] CPU 0 [ 3.998293] Modules linked in: [ 3.998293] Pid: 1, comm: swapper Not tainted 2.6.32.21 #1 To Be Filled By O.E.M. [ 3.998293] RIP: e030:[<ffffffff81258492>] [<ffffffff81258492>] acpi_ex_system_memory_space_handler+0x16d/0x1df [ 3.998293] RSP: e02b:ffff8800bb871970 EFLAGS: 00010246 [ 3.998293] RAX: ffffc90000062000 RBX: ffff8800bb89c040 RCX: 0000000000000000 [ 3.998293] RDX: ffff880002de90a0 RSI: 0000000000000001 RDI: ffffffff8100f22f [ 3.998293] RBP: ffff8800bb8719b0 R08: ffffffff8169e270 R09: 0000000000001000 [ 3.998293] R10: dead000000100100 R11: ffffffff8100f22f R12: ffffc90000062000 [ 3.998293] R13: 0000000000000000 R14: 0000000000000008 R15: ffff8800bb871a68 [ 3.998293] FS: 0000000000000000(0000) GS:ffff880002dde000(0000) knlGS:0000000000000000 [ 3.998293] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 3.998293] CR2: ffffc90000062000 CR3: 0000000001001000 CR4: 0000000000000660 [ 3.998293] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.998293] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 3.998293] Process swapper (pid: 1, threadinfo ffff8800bb870000, task ffff8800bb868000) [ 3.998293] Stack: [ 3.998293] ffff8800bb8719a0 0000000000001000 ffff880000000000 ffff8800ba29b5a0 [ 3.998293] <0> ffffffff81258325 ffff8800bb864b88 ffff8800ba29b240 0000000000000000 [ 3.998293] <0> ffff8800bb871a20 ffffffff81250f08 ffff8800ba32b800 ffffffff81253f53 [ 3.998293] Call Trace: [ 3.998293] [<ffffffff81258325>] ? acpi_ex_system_memory_space_handler+0x0/0x1df [ 3.998293] [<ffffffff81250f08>] acpi_ev_address_space_dispatch+0x16b/0x1b9 [ 3.998293] [<ffffffff81253f53>] ? acpi_os_allocate+0x33/0x35 -----Ursprüngliche Nachricht----- Von: Jan Beulich [mailto:JBeulich@novell.com] Gesendet: Mittwoch, 8. September 2010 14:51 An: Carsten Schiers Cc: xen-devel@lists.xensource.com Betreff: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?>>> On 08.09.10 at 14:15, Carsten Schiers <carsten@schiers.de> wrote: > (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 5555555555555555) fromL1> entry 8000000080000473 for l1e_owner=0, pg_owner=32753DOMID_IO seen here generally means that Dom0 tried to map a page it doesn''t own (likely because of your use of dom0_mem=). As the page really is a RAM one, Xen doesn''t allow the access. Given that this apparently happens in the context of acpi_ex_system_memory_space_handler() you''d have to look at (or provide) your DSDT and SSDT(s) to see where this reference comes from. Very likely this is just a bogus reference, that you get away with on native, perhaps because this code in ioremap.c last_pfn = last_addr >> PAGE_SHIFT; for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) { int is_ram = page_is_ram(pfn); if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn))) return NULL; WARN_ON_ONCE(is_ram); } should result in returning NULL there, while it wouldn''t cover the situation under Xen. (While the code is meaningless under Xen in its current shape anyway, using dom0_mem= with a value above 2G should get you around the issue, as then PFN 0x80000 would be considered RAM there too.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Sep-08 20:16 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
Forgot to attach the log, here it is: BR, Carsten. -----Ursprüngliche Nachricht----- Von: Jan Beulich [mailto:JBeulich@novell.com] Gesendet: Mittwoch, 8. September 2010 14:51 An: Carsten Schiers Cc: xen-devel@lists.xensource.com Betreff: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?>>> On 08.09.10 at 14:15, Carsten Schiers <carsten@schiers.de> wrote: > (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 5555555555555555) fromL1> entry 8000000080000473 for l1e_owner=0, pg_owner=32753DOMID_IO seen here generally means that Dom0 tried to map a page it doesn''t own (likely because of your use of dom0_mem=). As the page really is a RAM one, Xen doesn''t allow the access. Given that this apparently happens in the context of acpi_ex_system_memory_space_handler() you''d have to look at (or provide) your DSDT and SSDT(s) to see where this reference comes from. Very likely this is just a bogus reference, that you get away with on native, perhaps because this code in ioremap.c last_pfn = last_addr >> PAGE_SHIFT; for (pfn = phys_addr >> PAGE_SHIFT; pfn <= last_pfn; pfn++) { int is_ram = page_is_ram(pfn); if (is_ram && pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn))) return NULL; WARN_ON_ONCE(is_ram); } should result in returning NULL there, while it wouldn''t cover the situation under Xen. (While the code is meaningless under Xen in its current shape anyway, using dom0_mem= with a value above 2G should get you around the issue, as then PFN 0x80000 would be considered RAM there too.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Sep-09 09:57 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>> On 08.09.10 at 22:15, "Carsten Schiers" <carsten@schiers.de> wrote: > Hi, > > no change when I set e.g. to dom0_mem=3000M (see below and in log. In > log, I also tried 196M, same result).You spell it right here, but the logs in the other mail say you used "dom_mem="... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Sep-09 18:27 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
Ups. My fault. But this won''t make a difference. Find log for 3840MB, 1024MB, and 256MB in attached log. (XEN) Command line: dom0_mem=3840M loglvl=all guest_loglvl=all sync_console console_to_ring com1=19200,8n1 console=com1 ... [ 3.579906] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 3.580827] ACPI: Power Button [PWRF] [ 3.647887] ACPI: SSDT 00000000bbfb00b0 00235 (v01 DpgPmm P001Ist 00000011 INTL 20051117) [ 3.698280] ACPI: SSDT 00000000bbfb02f0 00235 (v01 DpgPmm P002Ist 00000012 INTL 20051117) (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 7c9ec) from L1 entry 8000000080000473 for l1e_owner=0, pg_owner=32753 [ 3.749005] BUG: unable to handle kernel paging request at ffffc90000062000 [ 3.749005] IP: [<ffffffff81258492>] acpi_ex_system_memory_space_handler+0x16d/0x1df [ 3.749005] PGD bb80d067 PUD bb80e067 PMD bb80f067 PTE 0 [ 3.749005] Oops: 0000 [#1] SMP I did a cp /proc/acpi/dsdt > DSDT iasl -d DSDT and provided the output, just in case it is what you needed. I will for sure need some time to understand that. Is the hypothesis that a) the BIOS is wrong, and b) Xen is checking more extreme than bare metal, so we need to make the Xen Code a bit more relaxed (error message instead of crash)? How to extract SSDT I don''t know. Are they in this file also? BR, Carsten. -----Ursprüngliche Nachricht----- Von: Jan Beulich [mailto:JBeulich@novell.com] Gesendet: Donnerstag, 9. September 2010 11:58 An: Carsten Schiers Cc: xen-devel Betreff: AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?>>> On 08.09.10 at 22:15, "Carsten Schiers" <carsten@schiers.de> wrote: > Hi, > > no change when I set e.g. to dom0_mem=3000M (see below and in log. In > log, I also tried 196M, same result).You spell it right here, but the logs in the other mail say you used "dom_mem="... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Sep-09 18:40 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
OK, here are the three SSDT''s that I seem to have. BR, Carsten. -----Ursprüngliche Nachricht----- Von: Carsten Schiers Gesendet: Donnerstag, 9. September 2010 20:27 An: JBeulich Cc: xen-devel Betreff: AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel? Ups. My fault. But this won''t make a difference. Find log for 3840MB, 1024MB, and 256MB in attached log. (XEN) Command line: dom0_mem=3840M loglvl=all guest_loglvl=all sync_console console_to_ring com1=19200,8n1 console=com1 ... [ 3.579906] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 3.580827] ACPI: Power Button [PWRF] [ 3.647887] ACPI: SSDT 00000000bbfb00b0 00235 (v01 DpgPmm P001Ist 00000011 INTL 20051117) [ 3.698280] ACPI: SSDT 00000000bbfb02f0 00235 (v01 DpgPmm P002Ist 00000012 INTL 20051117) (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 7c9ec) from L1 entry 8000000080000473 for l1e_owner=0, pg_owner=32753 [ 3.749005] BUG: unable to handle kernel paging request at ffffc90000062000 [ 3.749005] IP: [<ffffffff81258492>] acpi_ex_system_memory_space_handler+0x16d/0x1df [ 3.749005] PGD bb80d067 PUD bb80e067 PMD bb80f067 PTE 0 [ 3.749005] Oops: 0000 [#1] SMP I did a cp /proc/acpi/dsdt > DSDT iasl -d DSDT and provided the output, just in case it is what you needed. I will for sure need some time to understand that. Is the hypothesis that a) the BIOS is wrong, and b) Xen is checking more extreme than bare metal, so we need to make the Xen Code a bit more relaxed (error message instead of crash)? How to extract SSDT I don''t know. Are they in this file also? BR, Carsten. -----Ursprüngliche Nachricht----- Von: Jan Beulich [mailto:JBeulich@novell.com] Gesendet: Donnerstag, 9. September 2010 11:58 An: Carsten Schiers Cc: xen-devel Betreff: AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?>>> On 08.09.10 at 22:15, "Carsten Schiers" <carsten@schiers.de> wrote: > Hi, > > no change when I set e.g. to dom0_mem=3000M (see below and in log. In > log, I also tried 196M, same result).You spell it right here, but the logs in the other mail say you used "dom_mem="... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Sep-09 19:04 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
OK, I took out 2GB of memory to be at 2GB now. It will come up, but says now: [ 3.470518] ACPI: Power Button [PWRB] [ 3.542045] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 3.543005] ACPI: Power Button [PWRF] [ 3.609966] ACPI: SSDT 000000007ffb00b0 00235 (v01 DpgPmm P001Ist 00000011 INTL 20051117) [ 3.660356] ACPI: SSDT 000000007ffb02f0 00235 (v01 DpgPmm P002Ist 00000012 INTL 20051117) [ 3.710648] ------------[ cut here ]------------ [ 3.711073] WARNING: at mm/page_alloc.c:1820 __alloc_pages_nodemask+0x1b5/0x603() [ 3.711073] Hardware name: To Be Filled By O.E.M. [ 3.711073] Modules linked in: [ 3.711073] Pid: 1, comm: swapper Not tainted 2.6.32.21 #1 [ 3.711073] Call Trace: [ 3.711073] [<ffffffff810478da>] warn_slowpath_common+0x77/0x8f [ 3.711073] [<ffffffff81047901>] warn_slowpath_null+0xf/0x11 [ 3.711073] [<ffffffff810afcae>] __alloc_pages_nodemask+0x1b5/0x603 [ 3.711073] [<ffffffff81030e41>] ? __ioremap_caller+0x291/0x2f7 [ 3.711073] [<ffffffff8146bed2>] ? _spin_unlock_irqrestore+0x48/0x4b [ 3.711073] [<ffffffff81459bc1>] ? acpi_os_map_memory+0x12/0x1b [ 3.711073] [<ffffffff810b010e>] __get_free_pages+0x12/0x4f [ 3.711073] [<ffffffff810daae5>] __kmalloc+0x42/0x180 [ 3.711073] [<ffffffff81253f53>] acpi_os_allocate+0x33/0x35 [ 3.711073] [<ffffffff8125402d>] acpi_ex_load_op+0xd8/0x263 [ 3.711073] [<ffffffff812567ae>] acpi_ex_opcode_1A_1T_0R+0x25/0x4b [ 3.711073] [<ffffffff8124e020>] acpi_ds_exec_end_op+0xea/0x3d6 [ 3.711073] [<ffffffff8125feef>] acpi_ps_parse_loop+0x7bb/0x940 [ 3.711073] [<ffffffff8124e8f5>] ? acpi_ds_call_control_method+0x174/0x1e3 [ 3.711073] [<ffffffff8125eff5>] acpi_ps_parse_aml+0x9a/0x2d9 [ 3.711073] [<ffffffff8126073a>] acpi_ps_execute_method+0x1e4/0x2b6 [ 3.711073] [<ffffffff8125bec9>] acpi_ns_evaluate+0xe1/0x1a8 [ 3.711073] [<ffffffff8125b910>] acpi_evaluate_object+0xf9/0x1f2 [ 3.711073] [<ffffffff81023da1>] ? init_intel_pdc+0xd1/0x191 [ 3.711073] [<ffffffff81269ec7>] acpi_processor_set_pdc+0x3c/0x3e [ 3.711073] [<ffffffff8146988d>] xen_acpi_processor_add+0x303/0x43a [ 3.711073] [<ffffffff812453a7>] acpi_device_probe+0x4b/0x11d [ 3.711073] [<ffffffff812f7f70>] driver_probe_device+0x9a/0x11f [ 3.711073] [<ffffffff812f804d>] __driver_attach+0x58/0x7c [ 3.711073] [<ffffffff812f7ff5>] ? __driver_attach+0x0/0x7c [ 3.711073] [<ffffffff812f75ce>] bus_for_each_dev+0x4e/0x83 [ 3.711073] [<ffffffff812f7def>] driver_attach+0x19/0x1b [ 3.711073] [<ffffffff812f7a47>] bus_add_driver+0xb1/0x1fe [ 3.711073] [<ffffffff812f8311>] driver_register+0x99/0x10a [ 3.711073] [<ffffffff8173c1c1>] ? acpi_processor_init+0x0/0x128 [ 3.711073] [<ffffffff81245de0>] acpi_bus_register_driver+0x3e/0x40 [ 3.711073] [<ffffffff8126cd2a>] xen_acpi_processor_init+0x10/0x12 [ 3.711073] [<ffffffff8173c26f>] acpi_processor_init+0xae/0x128 [ 3.711073] [<ffffffff81245de0>] ? acpi_bus_register_driver+0x3e/0x40 [ 3.711073] [<ffffffff8173c14b>] ? acpi_video_init+0x0/0x76 [ 3.711073] [<ffffffff8100a05f>] do_one_initcall+0x59/0x170 [ 3.711073] [<ffffffff817176fe>] kernel_init+0x153/0x1a9 [ 3.711073] [<ffffffff81013caa>] child_rip+0xa/0x20 [ 3.711073] [<ffffffff81012e61>] ? int_ret_from_sys_call+0x7/0x1b [ 3.711073] [<ffffffff8101361d>] ? retint_restore_args+0x5/0x6 [ 3.711073] [<ffffffff81013ca0>] ? child_rip+0x0/0x20 [ 3.711073] ---[ end trace a7919e7f17c0a725 ]--- [ 3.711073] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.P003._OSC] (Node ffff88001f865640), AE_NO_MEMORY [ 5.440328] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.P003._PDC] (Node ffff88001f865620), AE_NO_MEMORY [ 5.508528] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.P004._OSC] (Node ffff88001f8656c0), AE_NO_MEMORY [ 5.575663] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.P004._PDC] (Node ffff88001f8656a0), AE_NO_MEMORY [ 5.648962] Event-channel device installed. BR, Carsten. -----Ursprüngliche Nachricht----- Von: Carsten Schiers Gesendet: Donnerstag, 9. September 2010 20:41 An: JBeulich@novell.com; Carsten Schiers Cc: xen-devel@lists.xensource.com Betreff: AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel? OK, here are the three SSDT''s that I seem to have. BR, Carsten. -----Ursprüngliche Nachricht----- Von: Carsten Schiers Gesendet: Donnerstag, 9. September 2010 20:27 An: JBeulich Cc: xen-devel Betreff: AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel? Ups. My fault. But this won''t make a difference. Find log for 3840MB, 1024MB, and 256MB in attached log. (XEN) Command line: dom0_mem=3840M loglvl=all guest_loglvl=all sync_console console_to_ring com1=19200,8n1 console=com1 ... [ 3.579906] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 3.580827] ACPI: Power Button [PWRF] [ 3.647887] ACPI: SSDT 00000000bbfb00b0 00235 (v01 DpgPmm P001Ist 00000011 INTL 20051117) [ 3.698280] ACPI: SSDT 00000000bbfb02f0 00235 (v01 DpgPmm P002Ist 00000012 INTL 20051117) (XEN) mm.c:860:d0 Error getting mfn 80000 (pfn 7c9ec) from L1 entry 8000000080000473 for l1e_owner=0, pg_owner=32753 [ 3.749005] BUG: unable to handle kernel paging request at ffffc90000062000 [ 3.749005] IP: [<ffffffff81258492>] acpi_ex_system_memory_space_handler+0x16d/0x1df [ 3.749005] PGD bb80d067 PUD bb80e067 PMD bb80f067 PTE 0 [ 3.749005] Oops: 0000 [#1] SMP I did a cp /proc/acpi/dsdt > DSDT iasl -d DSDT and provided the output, just in case it is what you needed. I will for sure need some time to understand that. Is the hypothesis that a) the BIOS is wrong, and b) Xen is checking more extreme than bare metal, so we need to make the Xen Code a bit more relaxed (error message instead of crash)? How to extract SSDT I don''t know. Are they in this file also? BR, Carsten. -----Ursprüngliche Nachricht----- Von: Jan Beulich [mailto:JBeulich@novell.com] Gesendet: Donnerstag, 9. September 2010 11:58 An: Carsten Schiers Cc: xen-devel Betreff: AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?>>> On 08.09.10 at 22:15, "Carsten Schiers" <carsten@schiers.de> wrote: > Hi, > > no change when I set e.g. to dom0_mem=3000M (see below and in log. In > log, I also tried 196M, same result).You spell it right here, but the logs in the other mail say you used "dom_mem="... Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Sep-10 08:22 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>> On 09.09.10 at 21:04, "Carsten Schiers" <carsten@schiers.de> wrote: > [ 3.711073] WARNING: at mm/page_alloc.c:1820 > __alloc_pages_nodemask+0x1b5/0x603()Is it this warning if (order >= MAX_ORDER) { WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)); return NULL; } according to your sources? And do you not see it with a native kernel? Jan> [ 3.711073] Hardware name: To Be Filled By O.E.M. > [ 3.711073] Modules linked in: > [ 3.711073] Pid: 1, comm: swapper Not tainted 2.6.32.21 #1 > [ 3.711073] Call Trace: > [ 3.711073] [<ffffffff810478da>] warn_slowpath_common+0x77/0x8f > [ 3.711073] [<ffffffff81047901>] warn_slowpath_null+0xf/0x11 > [ 3.711073] [<ffffffff810afcae>] __alloc_pages_nodemask+0x1b5/0x603 > [ 3.711073] [<ffffffff81030e41>] ? __ioremap_caller+0x291/0x2f7 > [ 3.711073] [<ffffffff8146bed2>] ? _spin_unlock_irqrestore+0x48/0x4b > [ 3.711073] [<ffffffff81459bc1>] ? acpi_os_map_memory+0x12/0x1b > [ 3.711073] [<ffffffff810b010e>] __get_free_pages+0x12/0x4f > [ 3.711073] [<ffffffff810daae5>] __kmalloc+0x42/0x180 > [ 3.711073] [<ffffffff81253f53>] acpi_os_allocate+0x33/0x35 > [ 3.711073] [<ffffffff8125402d>] acpi_ex_load_op+0xd8/0x263 > [ 3.711073] [<ffffffff812567ae>] acpi_ex_opcode_1A_1T_0R+0x25/0x4b > [ 3.711073] [<ffffffff8124e020>] acpi_ds_exec_end_op+0xea/0x3d6 > [ 3.711073] [<ffffffff8125feef>] acpi_ps_parse_loop+0x7bb/0x940 > [ 3.711073] [<ffffffff8124e8f5>] ? > acpi_ds_call_control_method+0x174/0x1e3 > [ 3.711073] [<ffffffff8125eff5>] acpi_ps_parse_aml+0x9a/0x2d9 > [ 3.711073] [<ffffffff8126073a>] acpi_ps_execute_method+0x1e4/0x2b6 > [ 3.711073] [<ffffffff8125bec9>] acpi_ns_evaluate+0xe1/0x1a8 > [ 3.711073] [<ffffffff8125b910>] acpi_evaluate_object+0xf9/0x1f2 > [ 3.711073] [<ffffffff81023da1>] ? init_intel_pdc+0xd1/0x191 > [ 3.711073] [<ffffffff81269ec7>] acpi_processor_set_pdc+0x3c/0x3e > [ 3.711073] [<ffffffff8146988d>] xen_acpi_processor_add+0x303/0x43a > [ 3.711073] [<ffffffff812453a7>] acpi_device_probe+0x4b/0x11d > [ 3.711073] [<ffffffff812f7f70>] driver_probe_device+0x9a/0x11f > [ 3.711073] [<ffffffff812f804d>] __driver_attach+0x58/0x7c > [ 3.711073] [<ffffffff812f7ff5>] ? __driver_attach+0x0/0x7c > [ 3.711073] [<ffffffff812f75ce>] bus_for_each_dev+0x4e/0x83 > [ 3.711073] [<ffffffff812f7def>] driver_attach+0x19/0x1b > [ 3.711073] [<ffffffff812f7a47>] bus_add_driver+0xb1/0x1fe > [ 3.711073] [<ffffffff812f8311>] driver_register+0x99/0x10a > [ 3.711073] [<ffffffff8173c1c1>] ? acpi_processor_init+0x0/0x128 > [ 3.711073] [<ffffffff81245de0>] acpi_bus_register_driver+0x3e/0x40 > [ 3.711073] [<ffffffff8126cd2a>] xen_acpi_processor_init+0x10/0x12 > [ 3.711073] [<ffffffff8173c26f>] acpi_processor_init+0xae/0x128 > [ 3.711073] [<ffffffff81245de0>] ? > acpi_bus_register_driver+0x3e/0x40 > [ 3.711073] [<ffffffff8173c14b>] ? acpi_video_init+0x0/0x76 > [ 3.711073] [<ffffffff8100a05f>] do_one_initcall+0x59/0x170 > [ 3.711073] [<ffffffff817176fe>] kernel_init+0x153/0x1a9 > [ 3.711073] [<ffffffff81013caa>] child_rip+0xa/0x20 > [ 3.711073] [<ffffffff81012e61>] ? int_ret_from_sys_call+0x7/0x1b > [ 3.711073] [<ffffffff8101361d>] ? retint_restore_args+0x5/0x6 > [ 3.711073] [<ffffffff81013ca0>] ? child_rip+0x0/0x20 > [ 3.711073] ---[ end trace a7919e7f17c0a725 ]---_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Sep-10 08:45 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>> On 09.09.10 at 20:40, "Carsten Schiers" <carsten@schiers.de> wrote: > OK, here are the three SSDT''s that I seem to have. BR, Carsten.SSDT1.dsl seems to be the bad one: While the SSDT package defined at the top is reasonable (having invalid entries only for CPUs 2 and up), the CSDT package is bogus, and gets referenced later in the same file in \_PR.P001._OSC: If (LAnd (LAnd (LEqual (And (PDC0, 0x18), 0x18), LEqual ( CTB0, Zero)), LEqual (And (CFGD, 0x20), 0x20))) { Or (CTB0, 0x01, CTB0) OperationRegion (CT00, SystemMemory, DerefOf (Index (CSDT, 0x01)), DerefOf (Index (CSDT, 0x02 ))) Load (CT00, HC0) } Hence, at least if the condition is true (not sure how the ACPI interpreter works wrt mapping memory in the body of false conditionals) a memory range of 0x80000000 bytes at address 0x80000000 will be attempted to be created and accessed, no matter how much memory the system has (and the variable the initialize with the memory access doesn''t appear to be used at all). I''m really surprised you (they) get away with this on a native kernel... Did you try to compare control flow of Xen and native kernels? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Sep-10 08:48 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>> On 09.09.10 at 20:27, "Carsten Schiers" <carsten@schiers.de> wrote: > and provided the output, just in case it is what you needed. I will for > sure need some time to understand that. > Is the hypothesis that a) the BIOS is wrong, and b) Xen is checking more > extreme than bare metal, so we need to > make the Xen Code a bit more relaxed (error message instead of crash)?I think the underlying problem was pointed out before: The page table accessor functions can''t currently propagate errors, and hence ioremap() can''t be forced to fail if Xen refused a mapping. And then, as I wrote in an earlier reply, the check for not trying to map RAM from ioremap() is pretty pointless (and hence no help) currently for the Xen case. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Sep-14 09:10 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
Hi, I am still trying to solve this issue.> I''m really surprised you (they) get away with this on a nativekernel... I think I now know. I found the BIOS option that causes the problem: SpeedStep. The buggy table is the description of the C-States. But there is a different behavior between native and Xen. See native here with acpi debug enabled: [ 0.358790] Table [SSDT](id 000C) - 6 Objects with 0 Devices 4 Methods 0 Regions [ 0.358793] nsload-0136 [10] ns_load_table : **** Completed Table Method Parsing and Object Initialization [ 0.358944] processor_throttling-1143 [00] processor_get_throttli: pblk_address[0x00000810] duty_offset[1] duty_width[0] [ 0.358952] processor_throttling-0893 [00] processor_get_fadt_inf: No throttling states [ 0.358959] processor_idle-0361 [00] processor_get_power_in: No _CST, giving up [ 0.358963] processor_idle-0317 [00] processor_get_power_in: C2 latency too large [101] [ 0.358967] processor_idle-0325 [00] processor_get_power_in: lvl2[0x00000000] lvl3[0x00000815] [ 0.358972] processor_idle-0548 [00] processor_power_verify: latency too large [1001] No _CST, giving up, C2 too large (0x80000000, I guess), giving up. Xen doesn''t give up. I did not manage to create the same with Xen, as it will not appear in the serial log. It will show in dmesg, if it comes up, but unfortunately, it will crash with SpeedStep enabled, but not interpret SSDT1 if disabled, thus no information. BR, Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Sep-14 09:33 UTC
AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>> On 14.09.10 at 11:10, "Carsten Schiers" <carsten@schiers.de> wrote: > I think I now know. I found the BIOS option that causes the problem: > SpeedStep. The buggy table > is the description of the C-States. But there is a different behavior > between native and Xen. > See native here with acpi debug enabled: > > [ 0.358790] Table [SSDT](id 000C) - 6 Objects with 0 Devices 4 > Methods 0 Regions > [ 0.358793] nsload-0136 [10] ns_load_table : **** Completed > Table Method Parsing and Object Initialization > [ 0.358944] processor_throttling-1143 [00] processor_get_throttli: > pblk_address[0x00000810] duty_offset[1] duty_width[0] > [ 0.358952] processor_throttling-0893 [00] processor_get_fadt_inf: No > throttling states > [ 0.358959] processor_idle-0361 [00] processor_get_power_in: No _CST, > giving up > [ 0.358963] processor_idle-0317 [00] processor_get_power_in: C2 > latency too large [101] > [ 0.358967] processor_idle-0325 [00] processor_get_power_in: > lvl2[0x00000000] lvl3[0x00000815] > [ 0.358972] processor_idle-0548 [00] processor_power_verify: latency > too large [1001] > > No _CST, giving up, C2 too large (0x80000000, I guess), giving up. Xen > doesn''t give up.Hmm, I wouldn''t think it''s the 0x80000000 value, but more likely some random value they happen to read. The question really is what ioremap()s the native kernel executes, and how that compares to the Xen case.> I did not manage to create the same with Xen, as it will not appear in > the serial log. It will show in dmesg, if it comes > up, but unfortunately, it will crash with SpeedStep enabled, but not > interpret SSDT1 if disabled, thus no information.Sure. I have to admit that I don''t know much about pv-ops'' C-state handling. Did you try a non-pv-ops kernel (e.g. XCP''s or SLE11SP1''s or OpenSuSE 11.3''s)? But in any case - the root cause is broken firmware. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Sep-14 21:19 UTC
AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
> But in any case - the root cause is broken firmware.Getting deeper into it. The faulty entries seems not to be the CPUxCST, but CPUxIST for CPU2 and up. For a reason I don''t know, native booting the kernel doesn''t run into this issue. I have managed to get a veeeeery detailed ACPI debug output now from the Xen/Dom0 kernel, will try to do the same with native booted Kernel tomorrow. I know already that the natively booting kernel will also run through 4 CPUs, even though my CPU has only 2 cores. So it must be something different. There is special code in the acpi driver section for xen in the pvops kernel... Jeremy, did you do it? Who could possibly help? I am not a real specialist... Did not attached the log, in case anybody is interested...it''s 31MB. BR, Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Sep-14 22:05 UTC
Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
On 09/14/2010 02:19 PM, Carsten Schiers wrote:>> But in any case - the root cause is broken firmware. > Getting deeper into it. The faulty entries seems not to be the CPUxCST, > but CPUxIST > for CPU2 and up. For a reason I don''t know, native booting the kernel > doesn''t run > into this issue. I have managed to get a veeeeery detailed ACPI debug > output now > from the Xen/Dom0 kernel, will try to do the same with native booted > Kernel tomorrow. > > I know already that the natively booting kernel will also run through 4 > CPUs, even > though my CPU has only 2 cores. So it must be something different. There > is special > code in the acpi driver section for xen in the pvops kernel... > > Jeremy, did you do it? Who could possibly help? I am not a real > specialist... > > Did not attached the log, in case anybody is interested...it''s 31MB.I''m not really an expert on ACPI at all. I''ve cc:d some of the Intel folks who''ve been very helpful in contributing ACPI changes. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yu, Ke
2010-Sep-15 01:20 UTC
RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
CC Winston, who has is working on the Xen ACPI stuff. Regards Ke> -----Original Message----- > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > Sent: Wednesday, September 15, 2010 6:05 AM > To: Carsten Schiers > Cc: JBeulich; xen-devel; Yu, Ke; Jiang, Yunhong > Subject: Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen > 4.0.1 with 2.6.32.18/21 pvops Kernel? > > On 09/14/2010 02:19 PM, Carsten Schiers wrote: > >> But in any case - the root cause is broken firmware. > > Getting deeper into it. The faulty entries seems not to be the CPUxCST, > > but CPUxIST > > for CPU2 and up. For a reason I don''t know, native booting the kernel > > doesn''t run > > into this issue. I have managed to get a veeeeery detailed ACPI debug > > output now > > from the Xen/Dom0 kernel, will try to do the same with native booted > > Kernel tomorrow. > > > > I know already that the natively booting kernel will also run through 4 > > CPUs, even > > though my CPU has only 2 cores. So it must be something different. There > > is special > > code in the acpi driver section for xen in the pvops kernel... > > > > Jeremy, did you do it? Who could possibly help? I am not a real > > specialist... > > > > Did not attached the log, in case anybody is interested...it''s 31MB. > > I''m not really an expert on ACPI at all. I''ve cc:d some of the Intel > folks who''ve been very helpful in contributing ACPI changes. > > J_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Wang, Winston L
2010-Sep-15 02:02 UTC
RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
I am forward this to Jimmy, he is currently working on Xen acpi4.0 support. I know ACPI 4.0 on native 2.6.32 is buggy besides possible BIOS firmware bug, would you check if native has the similar issue? if you can provide acpi error dump, that will be helpful. By the way, what platform are you using? Regards, Winston,> -----Original Message----- > From: Yu, Ke > Sent: Tuesday, September 14, 2010 6:20 PM > To: Jeremy Fitzhardinge; Carsten Schiers; Wang, Winston L > Cc: JBeulich; xen-devel; Jiang, Yunhong > Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen > 4.0.1 with 2.6.32.18/21 pvops Kernel? > > CC Winston, who has is working on the Xen ACPI stuff. > > Regards > Ke > > > -----Original Message----- > > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > > Sent: Wednesday, September 15, 2010 6:05 AM > > To: Carsten Schiers > > Cc: JBeulich; xen-devel; Yu, Ke; Jiang, Yunhong > > Subject: Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / > Xen > > 4.0.1 with 2.6.32.18/21 pvops Kernel? > > > > On 09/14/2010 02:19 PM, Carsten Schiers wrote: > > >> But in any case - the root cause is broken firmware. > > > Getting deeper into it. The faulty entries seems not to be the > CPUxCST, > > > but CPUxIST > > > for CPU2 and up. For a reason I don''t know, native booting the > kernel > > > doesn''t run > > > into this issue. I have managed to get a veeeeery detailed ACPI > debug > > > output now > > > from the Xen/Dom0 kernel, will try to do the same with native > booted > > > Kernel tomorrow. > > > > > > I know already that the natively booting kernel will also run > through 4 > > > CPUs, even > > > though my CPU has only 2 cores. So it must be something different. > There > > > is special > > > code in the acpi driver section for xen in the pvops kernel... > > > > > > Jeremy, did you do it? Who could possibly help? I am not a real > > > specialist... > > > > > > Did not attached the log, in case anybody is interested...it''s 31MB. > > > > I''m not really an expert on ACPI at all. I''ve cc:d some of the Intel > > folks who''ve been very helpful in contributing ACPI changes. > > > > J_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-Sep-15 05:37 UTC
RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
Jimmy and I checked the log and the SSDT table, since it is caused by a
workaround in Xen PVops dom0. Currently PVOPS dom0 will try to get all
CPU''s information in the system, no matter it is populated or not,
while native Linux will get the CPU information only if it is enabled. During
this process, following SSDT code cause trouble:
The followed SSDT code try to load region
OperationRegion (GV03, SystemMemory, DerefOf (Index (SSDT,
0x0A)), DerefOf (Index (SSDT, 0x0B
)))
Load (GV03, HI3)
While the region is defined as:
Name (SSDT, Package (0x18)
{
"CPU0IST ",
0xBBFB00B0,
0x00000235,
"CPU1IST ",
0xBBFB02F0,
0x00000235,
"CPU2IST ",
0x80000000,
0x80000000,
"CPU3IST ",
0x80000000,
0x80000000,
"CPU4IST ",
0x80000000,
0x80000000,
That seems try to load to 0x80000000.
Can you please try to apply the attached patch to see if it has any help? This
patch should enable dom0 to only scan enabled CPUs.
Thanks
--jyh
>-----Original Message-----
>From: Wang, Winston L
>Sent: Wednesday, September 15, 2010 10:03 AM
>To: Wei, Gang; Jeremy Fitzhardinge; Carsten Schiers
>Cc: JBeulich; xen-devel; Jiang, Yunhong
>Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1
with
>2.6.32.18/21 pvops Kernel?
>
>I am forward this to Jimmy, he is currently working on Xen acpi4.0 support.
>I know ACPI 4.0 on native 2.6.32 is buggy besides possible BIOS firmware
bug, would
>you check if native has the similar issue? if you can provide acpi error
dump, that will
>be helpful.
>By the way, what platform are you using?
>
>Regards,
>
>Winston,
>
>> -----Original Message-----
>> From: Yu, Ke
>> Sent: Tuesday, September 14, 2010 6:20 PM
>> To: Jeremy Fitzhardinge; Carsten Schiers; Wang, Winston L
>> Cc: JBeulich; xen-devel; Jiang, Yunhong
>> Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen
>> 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>
>> CC Winston, who has is working on the Xen ACPI stuff.
>>
>> Regards
>> Ke
>>
>> > -----Original Message-----
>> > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org]
>> > Sent: Wednesday, September 15, 2010 6:05 AM
>> > To: Carsten Schiers
>> > Cc: JBeulich; xen-devel; Yu, Ke; Jiang, Yunhong
>> > Subject: Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm /
>> Xen
>> > 4.0.1 with 2.6.32.18/21 pvops Kernel?
>> >
>> > On 09/14/2010 02:19 PM, Carsten Schiers wrote:
>> > >> But in any case - the root cause is broken firmware.
>> > > Getting deeper into it. The faulty entries seems not to be
the
>> CPUxCST,
>> > > but CPUxIST
>> > > for CPU2 and up. For a reason I don''t know, native
booting the
>> kernel
>> > > doesn''t run
>> > > into this issue. I have managed to get a veeeeery detailed
ACPI
>> debug
>> > > output now
>> > > from the Xen/Dom0 kernel, will try to do the same with native
>> booted
>> > > Kernel tomorrow.
>> > >
>> > > I know already that the natively booting kernel will also run
>> through 4
>> > > CPUs, even
>> > > though my CPU has only 2 cores. So it must be something
different.
>> There
>> > > is special
>> > > code in the acpi driver section for xen in the pvops
kernel...
>> > >
>> > > Jeremy, did you do it? Who could possibly help? I am not a
real
>> > > specialist...
>> > >
>> > > Did not attached the log, in case anybody is
interested...it''s 31MB.
>> >
>> > I''m not really an expert on ACPI at all. I''ve
cc:d some of the Intel
>> > folks who''ve been very helpful in contributing ACPI
changes.
>> >
>> > J
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Sep-15 07:22 UTC
AW: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
Thank you very much, this will solve the issue. acpi_avaluate_object on
_PDC is now only called
twice.
For the records: we spoke about an Asrock P5B-DE BIOS 1.10 board
equipped with an Intel E2200
and 4GB of RAM. The problem will not occur, if Speedstep is disabled, or
only 2 GB RAM is used.
As I am not such an expert (although through this experience, I now know
much more about ACPI),
can we now assume that the BIOS is ok? It''s because I mailed the Asrock
guys already and either
need to give them the latest info, or I would explain them everything is
settled.
BR & Thanks again,
Carsten.
-----Ursprüngliche Nachricht-----
Von: Jiang, Yunhong [mailto:yunhong.jiang@intel.com]
Gesendet: Mittwoch, 15. September 2010 07:37
An: Wang, Winston L; Wei, Gang; Jeremy Fitzhardinge; Carsten Schiers
Cc: JBeulich; xen-devel
Betreff: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen
4.0.1 with 2.6.32.18/21 pvops Kernel?
Jimmy and I checked the log and the SSDT table, since it is caused by a
workaround in Xen PVops dom0. Currently PVOPS dom0 will try to get all
CPU''s information in the system, no matter it is populated or not,
while
native Linux will get the CPU information only if it is enabled. During
this process, following SSDT code cause trouble:
The followed SSDT code try to load region
OperationRegion (GV03, SystemMemory, DerefOf (Index
(SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B
)))
Load (GV03, HI3)
While the region is defined as:
Name (SSDT, Package (0x18)
{
"CPU0IST ",
0xBBFB00B0,
0x00000235,
"CPU1IST ",
0xBBFB02F0,
0x00000235,
"CPU2IST ",
0x80000000,
0x80000000,
"CPU3IST ",
0x80000000,
0x80000000,
"CPU4IST ",
0x80000000,
0x80000000,
That seems try to load to 0x80000000.
Can you please try to apply the attached patch to see if it has any
help? This patch should enable dom0 to only scan enabled CPUs.
Thanks
--jyh
>-----Original Message-----
>From: Wang, Winston L
>Sent: Wednesday, September 15, 2010 10:03 AM
>To: Wei, Gang; Jeremy Fitzhardinge; Carsten Schiers
>Cc: JBeulich; xen-devel; Jiang, Yunhong
>Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen
>4.0.1 with
>2.6.32.18/21 pvops Kernel?
>
>I am forward this to Jimmy, he is currently working on Xen acpi4.0
support.>I know ACPI 4.0 on native 2.6.32 is buggy besides possible BIOS
>firmware bug, would you check if native has the similar issue? if you
>can provide acpi error dump, that will be helpful.
>By the way, what platform are you using?
>
>Regards,
>
>Winston,
>
>> -----Original Message-----
>> From: Yu, Ke
>> Sent: Tuesday, September 14, 2010 6:20 PM
>> To: Jeremy Fitzhardinge; Carsten Schiers; Wang, Winston L
>> Cc: JBeulich; xen-devel; Jiang, Yunhong
>> Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm /
>> Xen
>> 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>
>> CC Winston, who has is working on the Xen ACPI stuff.
>>
>> Regards
>> Ke
>>
>> > -----Original Message-----
>> > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org]
>> > Sent: Wednesday, September 15, 2010 6:05 AM
>> > To: Carsten Schiers
>> > Cc: JBeulich; xen-devel; Yu, Ke; Jiang, Yunhong
>> > Subject: Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm /
>> Xen
>> > 4.0.1 with 2.6.32.18/21 pvops Kernel?
>> >
>> > On 09/14/2010 02:19 PM, Carsten Schiers wrote:
>> > >> But in any case - the root cause is broken firmware.
>> > > Getting deeper into it. The faulty entries seems not to be
the
>> CPUxCST,
>> > > but CPUxIST
>> > > for CPU2 and up. For a reason I don''t know, native
booting the
>> kernel
>> > > doesn''t run
>> > > into this issue. I have managed to get a veeeeery detailed
ACPI
>> debug
>> > > output now
>> > > from the Xen/Dom0 kernel, will try to do the same with native
>> booted
>> > > Kernel tomorrow.
>> > >
>> > > I know already that the natively booting kernel will also run
>> through 4
>> > > CPUs, even
>> > > though my CPU has only 2 cores. So it must be something
different.>> There
>> > > is special
>> > > code in the acpi driver section for xen in the pvops
kernel...
>> > >
>> > > Jeremy, did you do it? Who could possibly help? I am not a
real
>> > > specialist...
>> > >
>> > > Did not attached the log, in case anybody is
interested...it''s
31MB.>> >
>> > I''m not really an expert on ACPI at all. I''ve
cc:d some of the
>> > Intel folks who''ve been very helpful in contributing ACPI
changes.
>> >
>> > J
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-Sep-15 07:38 UTC
RE: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>-----Original Message----- >From: Carsten Schiers [mailto:carsten@schiers.de] >Sent: Wednesday, September 15, 2010 3:23 PM >To: Wei, Gang; jeremy; Wang, Winston L; Jiang, Yunhong >Cc: JBeulich; xen-devel >Subject: AW: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 >with 2.6.32.18/21 pvops Kernel? > >Thank you very much, this will solve the issue. acpi_avaluate_object on >_PDC is now only called >twice.Glad to knows about this.> >For the records: we spoke about an Asrock P5B-DE BIOS 1.10 board >equipped with an Intel E2200 >and 4GB of RAM. The problem will not occur, if Speedstep is disabled, or >only 2 GB RAM is used.Yes, 2GB RAM is ok because the 0x80000000 is above 2G, thus hypervisor think it is MMIO in such situation and avoid such situation.> >As I am not such an expert (although through this experience, I now know >much more about ACPI), >can we now assume that the BIOS is ok? It''s because I mailed the Asrock >guys already and either >need to give them the latest info, or I would explain them everything is >settled.I think BIOS is ok. Sorry for the issue caused. Thanks --jyh> >BR & Thanks again, >Carsten. > > >-----Ursprüngliche Nachricht----- >Von: Jiang, Yunhong [mailto:yunhong.jiang@intel.com] >Gesendet: Mittwoch, 15. September 2010 07:37 >An: Wang, Winston L; Wei, Gang; Jeremy Fitzhardinge; Carsten Schiers >Cc: JBeulich; xen-devel >Betreff: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen >4.0.1 with 2.6.32.18/21 pvops Kernel? > >Jimmy and I checked the log and the SSDT table, since it is caused by a >workaround in Xen PVops dom0. Currently PVOPS dom0 will try to get all >CPU''s information in the system, no matter it is populated or not, while >native Linux will get the CPU information only if it is enabled. During >this process, following SSDT code cause trouble: > >The followed SSDT code try to load region > OperationRegion (GV03, SystemMemory, DerefOf (Index >(SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B > ))) > Load (GV03, HI3) > >While the region is defined as: > Name (SSDT, Package (0x18) > { > "CPU0IST ", > 0xBBFB00B0, > 0x00000235, > "CPU1IST ", > 0xBBFB02F0, > 0x00000235, > "CPU2IST ", > 0x80000000, > 0x80000000, > "CPU3IST ", > 0x80000000, > 0x80000000, > "CPU4IST ", > 0x80000000, > 0x80000000, >That seems try to load to 0x80000000. > >Can you please try to apply the attached patch to see if it has any >help? This patch should enable dom0 to only scan enabled CPUs. > >Thanks >--jyh > > >>-----Original Message----- >>From: Wang, Winston L >>Sent: Wednesday, September 15, 2010 10:03 AM >>To: Wei, Gang; Jeremy Fitzhardinge; Carsten Schiers >>Cc: JBeulich; xen-devel; Jiang, Yunhong >>Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen >>4.0.1 with >>2.6.32.18/21 pvops Kernel? >> >>I am forward this to Jimmy, he is currently working on Xen acpi4.0 >support. >>I know ACPI 4.0 on native 2.6.32 is buggy besides possible BIOS >>firmware bug, would you check if native has the similar issue? if you >>can provide acpi error dump, that will be helpful. >>By the way, what platform are you using? >> >>Regards, >> >>Winston, >> >>> -----Original Message----- >>> From: Yu, Ke >>> Sent: Tuesday, September 14, 2010 6:20 PM >>> To: Jeremy Fitzhardinge; Carsten Schiers; Wang, Winston L >>> Cc: JBeulich; xen-devel; Jiang, Yunhong >>> Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / >>> Xen >>> 4.0.1 with 2.6.32.18/21 pvops Kernel? >>> >>> CC Winston, who has is working on the Xen ACPI stuff. >>> >>> Regards >>> Ke >>> >>> > -----Original Message----- >>> > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] >>> > Sent: Wednesday, September 15, 2010 6:05 AM >>> > To: Carsten Schiers >>> > Cc: JBeulich; xen-devel; Yu, Ke; Jiang, Yunhong >>> > Subject: Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / >>> Xen >>> > 4.0.1 with 2.6.32.18/21 pvops Kernel? >>> > >>> > On 09/14/2010 02:19 PM, Carsten Schiers wrote: >>> > >> But in any case - the root cause is broken firmware. >>> > > Getting deeper into it. The faulty entries seems not to be the >>> CPUxCST, >>> > > but CPUxIST >>> > > for CPU2 and up. For a reason I don''t know, native booting the >>> kernel >>> > > doesn''t run >>> > > into this issue. I have managed to get a veeeeery detailed ACPI >>> debug >>> > > output now >>> > > from the Xen/Dom0 kernel, will try to do the same with native >>> booted >>> > > Kernel tomorrow. >>> > > >>> > > I know already that the natively booting kernel will also run >>> through 4 >>> > > CPUs, even >>> > > though my CPU has only 2 cores. So it must be something >different. >>> There >>> > > is special >>> > > code in the acpi driver section for xen in the pvops kernel... >>> > > >>> > > Jeremy, did you do it? Who could possibly help? I am not a real >>> > > specialist... >>> > > >>> > > Did not attached the log, in case anybody is interested...it''s >31MB. >>> > >>> > I''m not really an expert on ACPI at all. I''ve cc:d some of the >>> > Intel folks who''ve been very helpful in contributing ACPI changes. >>> > >>> > J > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-Sep-15 08:15 UTC
AW: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>> On 15.09.10 at 09:22, "Carsten Schiers" <carsten@schiers.de> wrote: > As I am not such an expert (although through this experience, I now know > much more about ACPI), > can we now assume that the BIOS is ok? It''s because I mailed the Asrock > guys already and either > need to give them the latest info, or I would explain them everything is > settled.Based on even the native kernel complaining (just not dying) the BIOS certainly isn''t fully correct. This particularly includes (but isn''t necessarily limited to) Name (CSDT, Package (0x18) { "CPU0CST ", 0x80000000, 0x80000000, "CPU1CST ", 0x80000000, 0x80000000, "CPU2CST ", 0x80000000, 0x80000000, "CPU3CST ", 0x80000000, 0x80000000, "CPU4CST ", 0x80000000, 0x80000000, "CPU5CST ", 0x80000000, 0x80000000, "CPU6CST ", 0x80000000, 0x80000000, "CPU7CST ", 0x80000000, 0x80000000 }) listing invalid addressed for *all* CPUs (not just the ones actually not present). Another point is that currently you may be luck in that they may not get evaluated. If they can guarantee that this will never get accessed, imo they should just leave it (and the dead access) out. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Sep-15 08:28 UTC
AW: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
So let''s wait what they tell me. Issue has been passed to their BIOS group. BR, Carsten. -----Ursprüngliche Nachricht----- Von: Jan Beulich [mailto:JBeulich@novell.com] Gesendet: Mittwoch, 15. September 2010 10:15 An: Carsten Schiers Cc: jeremy; gang.wei; winston.l.wang; yunhong.jiang; xen-devel Betreff: AW: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?>>> On 15.09.10 at 09:22, "Carsten Schiers" <carsten@schiers.de> wrote: > As I am not such an expert (although through this experience, I nowknow> much more about ACPI), > can we now assume that the BIOS is ok? It''s because I mailed theAsrock> guys already and either > need to give them the latest info, or I would explain them everythingis> settled.Based on even the native kernel complaining (just not dying) the BIOS certainly isn''t fully correct. This particularly includes (but isn''t necessarily limited to) Name (CSDT, Package (0x18) { "CPU0CST ", 0x80000000, 0x80000000, "CPU1CST ", 0x80000000, 0x80000000, "CPU2CST ", 0x80000000, 0x80000000, "CPU3CST ", 0x80000000, 0x80000000, "CPU4CST ", 0x80000000, 0x80000000, "CPU5CST ", 0x80000000, 0x80000000, "CPU6CST ", 0x80000000, 0x80000000, "CPU7CST ", 0x80000000, 0x80000000 }) listing invalid addressed for *all* CPUs (not just the ones actually not present). Another point is that currently you may be luck in that they may not get evaluated. If they can guarantee that this will never get accessed, imo they should just leave it (and the dead access) out. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-Sep-15 08:36 UTC
RE: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
One potential reality is, the BIOS populate the CSDT definition based on the same condition as the evaluatioin of the _OSC method. (i.e. Initially all is 0x80000000, BIOS initialization code check the same condition, and only malloc memory and update it if the condition meet, later the _OSC method check the same condition also). It is said BIOS does not change the DSDT/SSDT table dynamically, but just create it, and if needed, update several field. But yes, it will be helpful to get confirmation from OEM. BTW, Jan, where did you get the native kernel complaining? I didn''t find it in Carsten''s mail. Thanks --jyh>-----Original Message----- >From: Jan Beulich [mailto:JBeulich@novell.com] >Sent: Wednesday, September 15, 2010 4:15 PM >To: Carsten Schiers >Cc: jeremy; Wei, Gang; Wang, Winston L; Jiang, Yunhong; xen-devel >Subject: AW: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 >with 2.6.32.18/21 pvops Kernel? > >>>> On 15.09.10 at 09:22, "Carsten Schiers" <carsten@schiers.de> wrote: >> As I am not such an expert (although through this experience, I now know >> much more about ACPI), >> can we now assume that the BIOS is ok? It''s because I mailed the Asrock >> guys already and either >> need to give them the latest info, or I would explain them everything is >> settled. > >Based on even the native kernel complaining (just not dying) the >BIOS certainly isn''t fully correct. This particularly includes (but isn''t >necessarily limited to) > > Name (CSDT, Package (0x18) > { > "CPU0CST ", > 0x80000000, > 0x80000000, > "CPU1CST ", > 0x80000000, > 0x80000000, > "CPU2CST ", > 0x80000000, > 0x80000000, > "CPU3CST ", > 0x80000000, > 0x80000000, > "CPU4CST ", > 0x80000000, > 0x80000000, > "CPU5CST ", > 0x80000000, > 0x80000000, > "CPU6CST ", > 0x80000000, > 0x80000000, > "CPU7CST ", > 0x80000000, > 0x80000000 > }) > >listing invalid addressed for *all* CPUs (not just the ones actually >not present). Another point is that currently you may be luck in that >they may not get evaluated. If they can guarantee that this will >never get accessed, imo they should just leave it (and the dead >access) out. > >Jan_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-Sep-15 08:50 UTC
RE: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>BTW, Jan, where did you get the native kernel complaining? I didn''t find it in >Carsten''s mail.I find the log in the end. Before that, I just checked the attachment :$ This warning should be ok since it is only printed in debug level, when the system does not support _CST. status = acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer); if (ACPI_FAILURE(status)) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No _CST, giving up\n")); return -ENODEV; } Thanks --jyh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2010-Sep-15 17:01 UTC
Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
On 09/14/2010 10:37 PM, Jiang, Yunhong wrote:> Jimmy and I checked the log and the SSDT table, since it is caused by a workaround in Xen PVops dom0. Currently PVOPS dom0 will try to get all CPU''s information in the system, no matter it is populated or not, while native Linux will get the CPU information only if it is enabled. During this process, following SSDT code cause trouble: > > The followed SSDT code try to load region > OperationRegion (GV03, SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B > ))) > Load (GV03, HI3) > > While the region is defined as: > Name (SSDT, Package (0x18) > { > "CPU0IST ", > 0xBBFB00B0, > 0x00000235, > "CPU1IST ", > 0xBBFB02F0, > 0x00000235, > "CPU2IST ", > 0x80000000, > 0x80000000, > "CPU3IST ", > 0x80000000, > 0x80000000, > "CPU4IST ", > 0x80000000, > 0x80000000, > That seems try to load to 0x80000000. > > Can you please try to apply the attached patch to see if it has any help? This patch should enable dom0 to only scan enabled CPUs.BTW, I got around to applying this yesterday, so it should be in xen/stable-2.6.32.x soon (it''s currently in xen/next-2.6.32). J> Thanks > --jyh > > >> -----Original Message----- >> From: Wang, Winston L >> Sent: Wednesday, September 15, 2010 10:03 AM >> To: Wei, Gang; Jeremy Fitzhardinge; Carsten Schiers >> Cc: JBeulich; xen-devel; Jiang, Yunhong >> Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with >> 2.6.32.18/21 pvops Kernel? >> >> I am forward this to Jimmy, he is currently working on Xen acpi4.0 support. >> I know ACPI 4.0 on native 2.6.32 is buggy besides possible BIOS firmware bug, would >> you check if native has the similar issue? if you can provide acpi error dump, that will >> be helpful. >> By the way, what platform are you using? >> >> Regards, >> >> Winston, >> >>> -----Original Message----- >>> From: Yu, Ke >>> Sent: Tuesday, September 14, 2010 6:20 PM >>> To: Jeremy Fitzhardinge; Carsten Schiers; Wang, Winston L >>> Cc: JBeulich; xen-devel; Jiang, Yunhong >>> Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen >>> 4.0.1 with 2.6.32.18/21 pvops Kernel? >>> >>> CC Winston, who has is working on the Xen ACPI stuff. >>> >>> Regards >>> Ke >>> >>>> -----Original Message----- >>>> From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] >>>> Sent: Wednesday, September 15, 2010 6:05 AM >>>> To: Carsten Schiers >>>> Cc: JBeulich; xen-devel; Yu, Ke; Jiang, Yunhong >>>> Subject: Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / >>> Xen >>>> 4.0.1 with 2.6.32.18/21 pvops Kernel? >>>> >>>> On 09/14/2010 02:19 PM, Carsten Schiers wrote: >>>>>> But in any case - the root cause is broken firmware. >>>>> Getting deeper into it. The faulty entries seems not to be the >>> CPUxCST, >>>>> but CPUxIST >>>>> for CPU2 and up. For a reason I don''t know, native booting the >>> kernel >>>>> doesn''t run >>>>> into this issue. I have managed to get a veeeeery detailed ACPI >>> debug >>>>> output now >>>>> from the Xen/Dom0 kernel, will try to do the same with native >>> booted >>>>> Kernel tomorrow. >>>>> >>>>> I know already that the natively booting kernel will also run >>> through 4 >>>>> CPUs, even >>>>> though my CPU has only 2 cores. So it must be something different. >>> There >>>>> is special >>>>> code in the acpi driver section for xen in the pvops kernel... >>>>> >>>>> Jeremy, did you do it? Who could possibly help? I am not a real >>>>> specialist... >>>>> >>>>> Did not attached the log, in case anybody is interested...it''s 31MB. >>>> I''m not really an expert on ACPI at all. I''ve cc:d some of the Intel >>>> folks who''ve been very helpful in contributing ACPI changes. >>>> >>>> J_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2010-Oct-19 09:59 UTC
[Xen-devel] 2.6.34.7 with SUSE patches: Invalid Kernel
Hi, any idea what i configured wrong with my 2.6.34.7 32 Bit kernel? I get: VmError: (2, ''Invalid kernel'', ''elf_xen_note_check: ERROR: Will only load images built for the generic loader or Linux images'')PAE is enabled... BR, Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2010-Oct-19 10:09 UTC
[Xen-users] Re: [Xen-devel] 2.6.34.7 with SUSE patches: Invalid Kernel
I have 2.6.34.7 xenified aka Suse running under Xen 4.0.1 on top of Ubuntu 10.10
Desktop. But , it is 64-bit system.
Boris.
--- On Tue, 10/19/10, Carsten Schiers <carsten@schiers.de> wrote:
From: Carsten Schiers <carsten@schiers.de>
Subject: [Xen-devel] 2.6.34.7 with SUSE patches: Invalid Kernel
To: "xen-devel" <xen-devel@lists.xensource.com>
Date: Tuesday, October 19, 2010, 5:59 AM
Hi,
any idea what i configured wrong with my 2.6.34.7 32 Bit kernel? I get:
VmError: (2, ''Invalid kernel'', ''elf_xen_note_check:
ERROR: Will only
load images built for the generic loader or Linux images'')PAE is
enabled...
BR,
Carsten.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Jeremy Fitzhardinge
2010-Oct-20 16:54 UTC
Re: [Xen-devel] 2.6.34.7 with SUSE patches: Invalid Kernel
On 10/19/2010 02:59 AM, Carsten Schiers wrote:> Hi, > > any idea what i configured wrong with my 2.6.34.7 32 Bit kernel? I get: > VmError: (2, ''Invalid kernel'', ''elf_xen_note_check: ERROR: Will only > load images built for the generic loader or Linux images'')PAE is enabled...Is CONFIG_XEN enabled? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel