Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several people have reproduced

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 17/02/2020 19:19, Jason Andryuk wrote:
> enabling vecOn Tue, Dec 31, 2019 at 5:43 AM Aaron Janse <aaron@xxxxxxxxx> 
> wrote:
>> On Tue, Dec 31, 2019, at 12:27 AM, Andrew Cooper wrote:
>>> Is there any full boot log in the bad case?  Debugging via divination
>>> isn't an effective way to get things done.
>> Agreed. I included some more verbose logs towards the end of the email 
>> (typed up by hand).
>>
>> Attached are pictures from a slow-motion video of my laptop booting. Note 
>> that I also included a picture of a stack trace that happens immediately 
>> before reboot. It doesn't look related, but I wanted to include it anyway.
>>
>> I think the original email should have said "4.8.5" instead of "4.0.5." 
>> Regardless, everyone on this mailing list can now see all the boot logs that 
>> I've seen.
>>
>> Attaching a serial console seems like it would be difficult to do on this 
>> laptop, otherwise I would have sent the logs as a txt file.
> I'm seeing Xen panic: "IO-APIC + timer doesn't work" on a Dell
> Latitude 7200 2-in-1.  Fedora 31 Live USB image boots successfully.
> No way to get serial output.  I manually recreated the output before
> from the vga display.

We have multiple bugs.

First and foremost, Xen seems totally broken when running in ExtINT
mode.  This needs addressing, and ought to be sufficient to let Xen
boot, at which point we can try to figure out why it is trying to fall
back into 486(ish) compatibility mode.

> I tested Linux with intel_iommu=on and that booted successfully.
> Under Xen, this system sets iommu_x2apic_enabled = true, so
> force_iommu is set and iommu=0 cannot disable the iommu.
> fails.  Oh, I can disable x2apic and then disable iommu
>
> x2apic=1 -> failure above
> x2apic=0 iommu=0 -> failure above
> clocksource=acpi -> doesn't help
> clocksource=pit -> hangs after "load tracking window length 1073741824 ns"

None of these are surprising, given that Xen can't make any interrupts
work at all.

> noapic -> BUG in init_bsp_APIC

This is a surprise.  Its clearly a bug in Xen.  (OTOH, I've been
threatening to rip all of that logic out, because there is no such thing
as a 64bit capable system without an integrated APIC.)

> One other thing that might be noteworthy.  Linux only prints ACPI IRQ0
> and IRQ9 used by override where Xen lists IRQ 0, 2 & 9.

Huh - this is supposed to come directly from the ACPI tables, so Linux
and Xen should be using the same source of information.

>
> Below is the re-constructed Xen console output.  The SMBIOS line is
> the first thing displayed on the VGA output.

Yes - it is the first thing printed after vesa_init() which I think is a
manifestation of a previous EFI bug I've reported.  Does booting with
-basevideo help?  (No need to transcribe the output, manually.  Just
need to know if it lets you see the full log.)

>   I skipped the full EFI
> memory map dump since it is quite long.
>
> I've also attached the Linux dmesg output.  Any pointers or
> suggestions are most welcome.

Lets start with getting Xen able to limp along to a full boot.  After
that, we can figure out how to stop it making silly decisions during boot.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel