Hello, I’ve got a shiny new laptop here and I’d like to get Qubes 4.2.3 running on it, but I’ve run into some snags. Here’s a list of problems I’ve encountered, and solutions where I’ve been able to find them:
Installer kernel panics on boot
Solution: Edit bootloader options, add module_blacklist=ucsi_acpi to the line containing vmlinuz
Trackpad does not work on installer boot
Additional issues in the installed Qubes environment includes screen blanking on FDE Password screen, screen brightness controls not responding correctly
Solution: Edit bootloader options, add ioapic_ack=new to line starting with multiboot2
To permanently fix the above at install-time:
Install as normal until you get to the end with the “Reboot Now” button
Press Ctrl-Alt-F2 to switch to another console
run nano /mnt/sysimage/boot/grub2/grub.cfg
add ioapic_ack=new to line starting with multiboot2
run nano /mnt/sysimage/etc/default/grub
add ioapic_ack=new to the quoted portion of the line beginning GRUB_CMDLINE_XEN_DEFAULT
Qubes does not seem to be able to turn off the internal display - It’ll blank it, but the backlight stays on no matter what power management settings I select.
Panel power-off is somewhat counter-intuitively (For a Windows user like me, at least) configured in XScreenSaver, not in Power Options.
I’ve so far discovered two issues which I haven’t been able to find solutions to:
Disconnecting the USB-C power-supply causes the machine to lock up and reboot - I presume this is a kernel panic that I’m just not able to see the text of.
Qualcomm QCNFA765 wifi does not work
The machine is running the latest BIOS published by Lenovo, version 1.39.
I went and installed kernel-latest for both dom0 and domU, and increased the memory allocation for sys-net to 1024MB
This also changed the USB-C power disconnect behavior - Qubes now manages to live for long enough to display a notification that the power supply has been disconnected, before freezing up and rebooting.
[ 0.000000] Linux version 6.11.10-1.qubes.fc37.x86_64 (mockbuild@98260ff37ee0473287dfc4b33934ad19) (gcc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1), GNU ld version 2.38-27.fc37) #1 SMP PREEMPT_DYNAMIC Sun Nov 24 02:21:12 GMT 2024
...
[ 3.573492] ath11k_pci 0000:00:07.0: BAR 0 [mem 0xf2000000-0xf21fffff 64bit]: assigned
[ 3.576373] ath11k_pci 0000:00:07.0: MSI vectors: 1
[ 3.577043] ath11k_pci 0000:00:07.0: wcn6855 hw2.1
...
[ 3.772613] mhi mhi0: Requested to power ON
[ 3.772694] mhi mhi0: Power on setup success
[ 4.226394] mhi mhi0: Wait for device to enter SBL or Mission mode
...
[ 4.854340] ath11k_pci 0000:00:07.0: chip_id 0x12 chip_family 0xb board_id 0xff soc_id 0x400c1211
[ 4.854366] ath11k_pci 0000:00:07.0: fw_version 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
[ 4.992797] ath11k_pci 0000:00:07.0: leaving PCI ASPM disabled to avoid MHI M2 problems
...
[ 6.018430] ath11k_pci 0000:00:07.0: failed to receive control response completion, polling..
[ 7.042458] ath11k_pci 0000:00:07.0: Service connect timeout
[ 7.042502] ath11k_pci 0000:00:07.0: failed to connect to HTT: -110
[ 7.043331] ath11k_pci 0000:00:07.0: failed to start core: -110
[ 7.173499] vif vif-8-0 vif8.0: Guest Rx ready
[ 7.252546] ath11k_pci 0000:00:07.0: firmware crashed: MHI_CB_EE_RDDM
[ 7.252594] ath11k_pci 0000:00:07.0: ignore reset dev flags 0x4000
[ 7.360063] ath11k_pci 0000:00:07.0: firmware crashed: MHI_CB_EE_RDDM
...
[ 17.538497] ath11k_pci 0000:00:07.0: failed to wait wlan mode request (mode 4): -110
[ 17.538577] ath11k_pci 0000:00:07.0: qmi failed to send wlan mode off: -110
Tried swiotlb=8192, 16384, and soft. No difference.
Digging through the logs, I did notice
[2024-12-07 20:02:19] [2024-12-07 20:02:19] [00:07.0] xen_pt_realize: Assigning real physical device 02:00.0 to devfn 0x38
[2024-12-07 20:02:19] [00:07.0] xen_pt_register_regions: IO region 0 registered (size=0x00200000 base_addr=0x78600000 type: 0x4)
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x000e mismatch! Emulated=0x0080, host=0x0000, syncing to 0x0000.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x0010 mismatch! Emulated=0x0000, host=0x78600004, syncing to 0x78600004.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x0042 mismatch! Emulated=0x0000, host=0x0003, syncing to 0x0003.
[2024-12-07 20:02:19] [00:07.0] xen_pt_pm_ctrl_reg_init_off: PCI power management control passthrough is off.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x0074 mismatch! Emulated=0x0000, host=0x12c8fc0, syncing to 0x12c8fc0.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x007a mismatch! Emulated=0x0000, host=0x0010, syncing to 0x0010.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x0082 mismatch! Emulated=0x0000, host=0x1013, syncing to 0x1013.
[2024-12-07 20:02:19] [00:07.0] xen_pt_realize: no pin interrupt
[2024-12-07 20:02:19] [00:07.0] xen_pt_realize: Real physical device 02:00.0 registered successfully
Note the Linux kernel is making logs about “Disabling ASPM to avoid problems with MHI.” Is Xen not letting the kernel do that, therefore causing MHI to fail?
What’s the device 0000:00:07.0? Your QCNFA765 wireless adapter is 02:00.0, but ath11k_pci fails to interact with 00:07.0. Sorry if I missed it somewhere in the logs.
I think that’s Xen’s remapping - 02:00.0 is the physical hardware, but Xen remaps it over to 0000:00:07.0 in the virtual hardware space of sys-net. You can see that in the first line of the logs I just posted.