First Installation attempt with Qubes release 4.1.2 resulted in output of 4 or 5 lines and stucks over minutes with blinking Cursor.
Second Installation attempt with release 4.2.0-rc4 produced this output.
Web search of the relevant parts “acpi_ev_address_space_dispatch” “__die_body.cold” leads me to
There was stated “Try --cpus max_phys_bits=39 or 38. We place our MMIO regions at the end of the guest physical address space - we have seen some CPUs from AMD wrongly report the address space size.”
My interpretation of ‘guest physical address-space’ ist the total cpu physical address-space of 48 bits minus the bits used for MMIO. Which is returned by the CPU microcode to the kernel function acpi_ev_address_space_dispatch().
Assuming that my amd cpu microcode contains a similar bug even it is a modern Zen 4 architecture. Is there a chance to address the bug in Xen or Linux kernel via command line arguments in Grub boot manager similar to KVM Hypervisor command line args ’ --cpu max_phys_bits= ’ ?
According to your picture, you already have the latest BIOS for your model.
(Just writing this for possible future readers:
You could try to update your BIOS to the latest version.)
In the link you posted, the acpi problem has been solved by adding the kernel option acpi=off.
The --cpus max_phys_bits= is for the next problem that this user encounter about virtio device.
Hi,
that hint is was helpful. Thanks!
My first attempt to install with the acpi=off with the ‘kernel-latest’ boot option resulted in an endless loop
‘watchdog: BUG: soft lockup -CPU#0 stuck for 25s! [init:1]’ counting +25s per loop.
The second attempt choosing the first GRUB boot option gets me to the graphical install screen.
Only the linux kernel parameter acpi=off was needed.
I’m impressed that you hit the mark. Before posting here I tried several xen and kernel params suggested in thes Qubes OS User Support forum without success.
In order to proceed I have to obtain an usb keyboard/mouse first as the internal devices are not functional…
A little pro tip: I marked @szz9pza’s post as the solution, so future folks (and our future selves!) can see that the topic includes a solution, and get a highlight of that solution in the first post.
If you want yo do that in the future, it’s something that you can do yourself by using the little “checkbox” icon at the bottom of the post that you want to mark as the solution. Welcome to the forum!
I’m encountering the same issue (same kernel logs) on 4.2.0 with the latest kernel the installer ISO has (6.7 IIRC), latest UEFI/BIOS firmware from Lenovo, on:
Thinkpad Z16 Gen 2
AMD Ryzen™ PRO 7040 H + Radeon Graphics
Same issue with Qubes 4.1.2
Blacklisting the ucsi_acpi module in the kernel params allowed me to boot, install and setup Qubes, use the keyboard and trackpoint (no touchpad), but the machine restarts intermittently when removing USB devices, its quite unstable. Also, since the Z16 has the “fake” trackpoint buttons in the touchpad, its still unusable because the clicking feel comes from haptic feedback in the touchpad, which does not work if you blacklist ucsi_acpi .
Only improvement from the posts above is that only blacklisting ucsi_acpi allowed me to use the built-in keyboard and trackpoint and the installation completed successfully.
Plain Fedora 39 works fine on these machines, installing Xen 4.18 on plain Fedora 39 from rawhide repos and booting it gives this same kernel panic, seems like a Xen issue?
@methusalix Did you manage to get a usable machine? (internal keyboard/touchpad working)
Any idea where the issue stems from exactly or an ETA? Still in the return window for the machine.
no I did not manage to get a working Qubes installation. Although the setup finished without error messages the qubes boot process fails. The kernel log shows
“pciback … can’t find IRQ for PCI INT D …
pciback … can’t find IRQ for PCI INT A …
pciback … can’t find IRQ for PCI INT B …”
Fedora 39 works fine on my machine too.
Whenever Lenovo releases new BIOS updates I’ll start new installation attempts. No progress up to now.
