Re: [Xen-devel] Linux as 32-bit Dom0?
On 11/22/2017 09:40 AM, Juergen Gross wrote: > On 22/11/17 15:05, Jan Beulich wrote: >> Jürgen, Boris, >> >> am I trying something that's not allowed, but selectable via Kconfig? >> On system with multiple IO-APICs (I assume that's what triggers the >> problem) I get >> >> Kernel panic - not syncing: Max apic_id exceeded! > Generally I don't think 32 bit dom0 is forbidden, but rarely used. I > wouldn't be too sad in case we'd decide to drop that support. ;-) > > Can you please be a little bit more specific? > > How many IOAPICs? From the code I guess this is an INTEL system with not > too recent IOAPIC versions (<0x14)? > > Having a little bit more of the boot log might help, too. I just booted a 3-IOAPIC Intel box with a 32-bit 4.13 kernel. (well, it actually didn't quite boot as it hang somewhere further down the line, so that's a problem). I do see ... [0.00] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) [0.00] IOAPIC[0]: apic_id 0 already used, trying 1 [0.00] IOAPIC[0]: Unable to change apic_id! [0.00] IOAPIC[0]: apic_id 255, version 32, address 0xfec0, GSI 0-23 [0.00] IOAPIC[1]: apic_id 1 already used, trying 3 [0.00] IOAPIC[1]: Unable to change apic_id! [0.00] IOAPIC[1]: apic_id 255, version 32, address 0xfec3f000, GSI 24-47 [0.00] IOAPIC[2]: apic_id 2 already used, trying 5 [0.00] IOAPIC[2]: Unable to change apic_id! [0.00] IOAPIC[2]: apic_id 255, version 32, address 0xfec7f000, GSI 48-71 -boris > > > Juergen > >> CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.1-2017-11-21-xen0 #6 >> Hardware name: ... >> Call Trace: >> ? show_stack+0x20/0x50 >> ? dump_stack+0x7e/0xc0 >> ? panic+0x99/0x220 >> ? io_apic_get_unique_id+0x207/0x210 >> ? __raw_callee_save_xen_restore_fl+0x6/0x8 >> ? xen_flush_tlb_single+0x6f/0x80 >> ? set_pte_vaddr+0xef/0x110 >> ? xen_io_apic_read+0x36/0x90 >> ? mp_register_ioapic+0x2b7/0x410 >> ? acpi_os_map_iomem+0x14d/0x210 >> ? acpi_parse_ioapic+0x6b/0x6f >> ? acpi_parse_entries_array+0xa1/0x16d >> ? acpi_tb_get_table+0x95/0x9d >> ? acpi_ut_release_mutex+0x109/0x10e >> ? acpi_table_parse_entries_array+0x98/0xa8 >> ? acpi_table_parse_entries+0x30/0x35 >> ? acpi_boot_init+0x65/0x65 >> ? acpi_table_parse_madt+0x1b/0x1f >> ? acpi_boot_init+0x65/0x65 >> ? acpi_parse_madt_ioapic_entries+0x4a/0x119 >> ? mutex_lock+0x8/0x30 >> ? acpi_process_madt+0xbe/0x105 >> ? acpi_boot_init+0x3d/0x65 >> ? setup_arch+0x67a/0x83f >> ? 0xc100 >> ? start_kernel+0x46/0x361 >> ? x86_early_init_platform_quirks+0x4d/0x90 >> ? i386_start_kernel+0x22/0x88 >> ? xen_start_kernel+0x453/0x639 >> (XEN) Hardware Dom0 crashed: 'noreboot' set - not rebooting. >> >> I admit I have a few custom patches in that tree, but I'm reasonably >> certain that none of them comes even close to having such an effect. >> >> Jan >> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Linux as 32-bit Dom0?
>>> On 22.11.17 at 15:40, wrote: > On 22/11/17 15:05, Jan Beulich wrote: >> Jürgen, Boris, >> >> am I trying something that's not allowed, but selectable via Kconfig? >> On system with multiple IO-APICs (I assume that's what triggers the >> problem) I get >> >> Kernel panic - not syncing: Max apic_id exceeded! > > Generally I don't think 32 bit dom0 is forbidden, but rarely used. I > wouldn't be too sad in case we'd decide to drop that support. ;-) > > Can you please be a little bit more specific? > > How many IOAPICs? From the code I guess this is an INTEL system with not > too recent IOAPIC versions (<0x14)? > > Having a little bit more of the boot log might help, too. Full log attached, which should answer all questions. This is a Haswell system, so not too old an IO-APIC flavor I would say. Jan minicom.Linux-4.14 Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Linux as 32-bit Dom0?
On 22/11/17 15:05, Jan Beulich wrote: > Jürgen, Boris, > > am I trying something that's not allowed, but selectable via Kconfig? > On system with multiple IO-APICs (I assume that's what triggers the > problem) I get > > Kernel panic - not syncing: Max apic_id exceeded! Generally I don't think 32 bit dom0 is forbidden, but rarely used. I wouldn't be too sad in case we'd decide to drop that support. ;-) Can you please be a little bit more specific? How many IOAPICs? From the code I guess this is an INTEL system with not too recent IOAPIC versions (<0x14)? Having a little bit more of the boot log might help, too. Juergen > > CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.1-2017-11-21-xen0 #6 > Hardware name: ... > Call Trace: > ? show_stack+0x20/0x50 > ? dump_stack+0x7e/0xc0 > ? panic+0x99/0x220 > ? io_apic_get_unique_id+0x207/0x210 > ? __raw_callee_save_xen_restore_fl+0x6/0x8 > ? xen_flush_tlb_single+0x6f/0x80 > ? set_pte_vaddr+0xef/0x110 > ? xen_io_apic_read+0x36/0x90 > ? mp_register_ioapic+0x2b7/0x410 > ? acpi_os_map_iomem+0x14d/0x210 > ? acpi_parse_ioapic+0x6b/0x6f > ? acpi_parse_entries_array+0xa1/0x16d > ? acpi_tb_get_table+0x95/0x9d > ? acpi_ut_release_mutex+0x109/0x10e > ? acpi_table_parse_entries_array+0x98/0xa8 > ? acpi_table_parse_entries+0x30/0x35 > ? acpi_boot_init+0x65/0x65 > ? acpi_table_parse_madt+0x1b/0x1f > ? acpi_boot_init+0x65/0x65 > ? acpi_parse_madt_ioapic_entries+0x4a/0x119 > ? mutex_lock+0x8/0x30 > ? acpi_process_madt+0xbe/0x105 > ? acpi_boot_init+0x3d/0x65 > ? setup_arch+0x67a/0x83f > ? 0xc100 > ? start_kernel+0x46/0x361 > ? x86_early_init_platform_quirks+0x4d/0x90 > ? i386_start_kernel+0x22/0x88 > ? xen_start_kernel+0x453/0x639 > (XEN) Hardware Dom0 crashed: 'noreboot' set - not rebooting. > > I admit I have a few custom patches in that tree, but I'm reasonably > certain that none of them comes even close to having such an effect. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Linux as 32-bit Dom0?
Jürgen, Boris, am I trying something that's not allowed, but selectable via Kconfig? On system with multiple IO-APICs (I assume that's what triggers the problem) I get Kernel panic - not syncing: Max apic_id exceeded! CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.1-2017-11-21-xen0 #6 Hardware name: ... Call Trace: ? show_stack+0x20/0x50 ? dump_stack+0x7e/0xc0 ? panic+0x99/0x220 ? io_apic_get_unique_id+0x207/0x210 ? __raw_callee_save_xen_restore_fl+0x6/0x8 ? xen_flush_tlb_single+0x6f/0x80 ? set_pte_vaddr+0xef/0x110 ? xen_io_apic_read+0x36/0x90 ? mp_register_ioapic+0x2b7/0x410 ? acpi_os_map_iomem+0x14d/0x210 ? acpi_parse_ioapic+0x6b/0x6f ? acpi_parse_entries_array+0xa1/0x16d ? acpi_tb_get_table+0x95/0x9d ? acpi_ut_release_mutex+0x109/0x10e ? acpi_table_parse_entries_array+0x98/0xa8 ? acpi_table_parse_entries+0x30/0x35 ? acpi_boot_init+0x65/0x65 ? acpi_table_parse_madt+0x1b/0x1f ? acpi_boot_init+0x65/0x65 ? acpi_parse_madt_ioapic_entries+0x4a/0x119 ? mutex_lock+0x8/0x30 ? acpi_process_madt+0xbe/0x105 ? acpi_boot_init+0x3d/0x65 ? setup_arch+0x67a/0x83f ? 0xc100 ? start_kernel+0x46/0x361 ? x86_early_init_platform_quirks+0x4d/0x90 ? i386_start_kernel+0x22/0x88 ? xen_start_kernel+0x453/0x639 (XEN) Hardware Dom0 crashed: 'noreboot' set - not rebooting. I admit I have a few custom patches in that tree, but I'm reasonably certain that none of them comes even close to having such an effect. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
