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

["Aaron Janse" <aaron@xxxxxxxxx>]

On Fri, Jan 3, 2020, at 4:51 AM, Jan Beulich wrote:
> On 31.12.2019 08:52,  Aaron Janse  wrote:
> > I'd like to note that Ubuntu, unlike Qubes, doesn't need to try
> > any `MP-BIOS bug` fallbacks.
> 
> "Doesn't need to try" is supposed to mean what? That it gets past
> the timer interrupt initialization, meaning if it crashes another
> way, it's a different problem? Or instead meaning it works
> (contrary to information found elsewhere), suggesting there's a
> Qubes side change involved?

I originally thought that the problem was the timer specifically, but
based on what you and Andrew Cooper have said, it sounds like the root
cause is somewhere else.

Andrew Cooper wrote:
> (Irrespective, I'm pretty sure this is a Grub2+EFI issue failing to pass
> the ACPI tables to Xen, and this eventual panic is just cascade fallout.)

I tried to get Xen working via legacy boot, but I haven't been able to get
my laptop to boot anything but UEFI. The BIOS even states "UEFI only."

> Did you try disabling use of the IOMMU ("iommu=0" on the Xen
> command line)?

Unfortunately, Qubes requires iommu. Setting "iommu=0" results in a panic:

```
Couldn't enable IOMMU and iommu=required/force
```

I also (unsuccessfully) tried iommu=no-igfx and iommu=soft (both resulted
in the timer panic).

I couldn't find anywhere to disable the flag (even though it would break
Qubes, at least the flag could help minimize the scope of the cause of the
timer crash).

I installed Xen on Arch Linux in order to test this flag, but I'm having
the same problem I had on Ubuntu: booting to Xen hangs on loading
initramfs. [1]

> If this is as common a problem as you say, it's hard to believe
> this has never worked on any of these systems. Hence it would be
> helpful to know starting from which version this has been
> regressed.

That makes sense. I've tried to reproduce the problem on both Arch and
Ubuntu (both hang, and I'm not sure why or how to debug that). Because
Qubes is the only OS I've been able to boot verbose Xen from, I installed
a 2016 release to try out. However, I couldn't get past a hang showing
the Dell logo. I had this same issue on NixOS, described by someone else
with the same laptop on the NixOS Discourse [4]. The solution for NixOS
was to use a newer version of the distro.

If I can get past the boot hang on Ubuntu or Arch, I'd be happy to go about
bisecting the issue, comparing Ubuntu/Arch vs Qubes, compiling with new
printf statements, etc.

As a side note, the XPS 7390 2-in-1 user was able to get Xen to boot
using the acpi=noirq flag [2]. My understanding is that needing this flag
indicates that something's still wrong [3].

[1] https://lists.xenproject.org/archives/html/xen-users/2019-12/msg00031.html
[2] https://www.reddit.com/r/Qubes/comments/edqrab/qubes_and_ice_lake/fcresld/
[3] http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#acpi
[4] 
https://discourse.nixos.org/t/nixos-stable-wont-boot-from-usb-on-xps-7390/4776

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