WiFi PCI issues on Thinkpad L14 AMD Gen 3

User Support Hardware Issues
1

I have a new Thinkpad L14 AMD Gen 3 with Ryzen 5875U and WiFi is AMD RZ616(Apparently a rebranded MediaTek MT7922).
With some troubleshooting I was able to install Qubes 4.1.1 and it is now mostly functional.
I applied clocksource=tsc tsc=unstable hpetbroadcast=0 parameters to Grub and the system is now nice and fast. However, I noticed that when only the Ethernet PCI device is attached to sys-net, sys-net boots very fast, but when the WiFi PCI device is attached as well, it takes a long time to boot. Additionally, even though the Grub parameters solved performance issues, the system takes about 80 seconds to reach the disk encryption password screen after Grub.
I removed the quiet line from Grub I noticed the WiFi PCI device is the culprit:

pciback 0000:06:00.0: xen_pciback: seizing device
pciback 0000:06:00.0: enabling device (0000 -> 0002)
pciback 0000:06:00.0: not ready 1023ms after FLR: waiting

There are a lot of “not ready X ms after FLR: waiting” messages after that.

After installing kernel-latest, kernel-latest-qubes-vm and setting sys-net to use kernel 6.0, WiFi is now working, however sys-net is still slow to start and Grub to Password screen still takes about 80 seconds with the same “not ready” messages.

Here is a list of my PCI devices:

Screenshot-2023-01-10-10-41-41
Screenshot-2023-01-10-10-41-411801Ă—524 34.6 KB

I hope someone can help me resolve this issue.

2 Likes
2

Do you detach all USB device before poweron?
Also, check journalctl.

3

Yes, no USB devices were attached to the laptop during poweron/boot.

I grepped journalctl for pci:

Jan 11 14:25:52 dom0 kernel: [mem 0xd0000000-0xf7ffffff] available for PCI devices
Jan 11 14:25:52 dom0 kernel: ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
Jan 11 14:25:52 dom0 kernel: PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
Jan 11 14:25:52 dom0 kernel: PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820
Jan 11 14:25:52 dom0 kernel: PCI: Using configuration type 1 for base access
Jan 11 14:25:52 dom0 kernel: ACPI: \_SB_.PCI0.LPC0.EC0_: Boot DSDT EC used to handle transactions
Jan 11 14:25:52 dom0 kernel: PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
Jan 11 14:25:52 dom0 kernel: PCI: Using E820 reservations for host bridge windows
Jan 11 14:25:52 dom0 kernel: ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
Jan 11 14:25:52 dom0 kernel: acpi PNP0A08:00: _OSC: OS now controls [PME AER PCIeCapability]
Jan 11 14:25:52 dom0 kernel: PCI host bridge to bus 0000:00
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000effff window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: root bus resource [mem 0xfc000000-0xfdffffff window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: root bus resource [bus 00-ff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:00.0: [1022:1630] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:00.2: [1022:1631] type 00 class 0x080600
Jan 11 14:25:52 dom0 kernel: pci 0000:00:01.0: [1022:1632] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.0: [1022:1632] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.1: [1022:1634] type 01 class 0x060400
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.1: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.3: [1022:1634] type 01 class 0x060400
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.3: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.4: [1022:1634] type 01 class 0x060400
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.4: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.6: [1022:1634] type 01 class 0x060400
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.6: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.0: [1022:1632] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1: [1022:1635] type 01 class 0x060400
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1: enabling Extended Tags
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:00:14.0: [1022:790b] type 00 class 0x0c0500
Jan 11 14:25:52 dom0 kernel: pci 0000:00:14.3: [1022:790e] type 00 class 0x060100
Jan 11 14:25:52 dom0 kernel: pci 0000:00:18.0: [1022:166a] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:18.1: [1022:166b] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:18.2: [1022:166c] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:18.3: [1022:166d] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:18.4: [1022:166e] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:18.5: [1022:166f] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:18.6: [1022:1670] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:00:18.7: [1022:1671] type 00 class 0x060000
Jan 11 14:25:52 dom0 kernel: pci 0000:01:00.0: [1344:5411] type 00 class 0x010802
Jan 11 14:25:52 dom0 kernel: pci 0000:01:00.0: reg 0x10: [mem 0xfd700000-0xfd703fff 64bit]
Jan 11 14:25:52 dom0 kernel: pci 0000:01:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:00:02.1 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link)
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.1: PCI bridge to [bus 01]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.1:   bridge window [mem 0xfd700000-0xfd7fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:03:00.0: [10ec:8168] type 00 class 0x020000
Jan 11 14:25:52 dom0 kernel: pci 0000:03:00.0: reg 0x10: [io  0x2000-0x20ff]
Jan 11 14:25:52 dom0 kernel: pci 0000:03:00.0: reg 0x18: [mem 0xfd604000-0xfd604fff 64bit]
Jan 11 14:25:52 dom0 kernel: pci 0000:03:00.0: reg 0x20: [mem 0xfd600000-0xfd603fff 64bit]
Jan 11 14:25:52 dom0 kernel: pci 0000:03:00.0: supports D1 D2
Jan 11 14:25:52 dom0 kernel: pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.3: PCI bridge to [bus 03]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.3:   bridge window [io  0x2000-0x2fff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.3:   bridge window [mem 0xfd600000-0xfd6fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:04:00.0: [1217:8621] type 00 class 0x080501
Jan 11 14:25:52 dom0 kernel: pci 0000:04:00.0: reg 0x10: [mem 0xfd501000-0xfd501fff]
Jan 11 14:25:52 dom0 kernel: pci 0000:04:00.0: reg 0x14: [mem 0xfd500000-0xfd5007ff]
Jan 11 14:25:52 dom0 kernel: pci 0000:04:00.0: PME# supported from D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.4: PCI bridge to [bus 04]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.4:   bridge window [mem 0xfd500000-0xfd5fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:06:00.0: [14c3:0616] type 00 class 0x028000
Jan 11 14:25:52 dom0 kernel: pci 0000:06:00.0: reg 0x10: [mem 0xe0200000-0xe02fffff 64bit pref]
Jan 11 14:25:52 dom0 kernel: pci 0000:06:00.0: reg 0x18: [mem 0xfd400000-0xfd407fff 64bit]
Jan 11 14:25:52 dom0 kernel: pci 0000:06:00.0: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.6: PCI bridge to [bus 06]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.6:   bridge window [mem 0xfd400000-0xfd4fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.6:   bridge window [mem 0xe0200000-0xe02fffff 64bit pref]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: [1002:15e7] type 00 class 0x030000
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: reg 0x10: [mem 0xd0000000-0xdfffffff 64bit pref]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: reg 0x18: [mem 0xe0000000-0xe01fffff 64bit pref]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: reg 0x20: [io  0x1000-0x10ff]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: reg 0x24: [mem 0xfd300000-0xfd37ffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: enabling Extended Tags
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: BAR 0: assigned to efifb
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: PME# supported from D1 D2 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: 126.016 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x16 link at 0000:00:08.1 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link)
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.1: [1002:1637] type 00 class 0x040300
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.1: reg 0x10: [mem 0xfd3c8000-0xfd3cbfff]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.1: enabling Extended Tags
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.1: PME# supported from D1 D2 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.2: [1022:15df] type 00 class 0x108000
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.2: reg 0x18: [mem 0xfd200000-0xfd2fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.2: reg 0x24: [mem 0xfd3cc000-0xfd3cdfff]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.2: enabling Extended Tags
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.3: [1022:1639] type 00 class 0x0c0330
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.3: reg 0x10: [mem 0xfd000000-0xfd0fffff 64bit]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.3: enabling Extended Tags
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.3: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.4: [1022:1639] type 00 class 0x0c0330
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.4: reg 0x10: [mem 0xfd100000-0xfd1fffff 64bit]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.4: enabling Extended Tags
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.4: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.5: [1022:15e2] type 00 class 0x048000
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.5: reg 0x10: [mem 0xfd380000-0xfd3bffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.5: enabling Extended Tags
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.5: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.6: [1022:15e3] type 00 class 0x040300
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.6: reg 0x10: [mem 0xfd3c0000-0xfd3c7fff]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.6: enabling Extended Tags
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.6: PME# supported from D0 D3hot D3cold
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1: PCI bridge to [bus 07]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1:   bridge window [io  0x1000-0x1fff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1:   bridge window [mem 0xfd000000-0xfd3fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1:   bridge window [mem 0xd0000000-0xe01fffff 64bit pref]
Jan 11 14:25:52 dom0 kernel: ACPI: PCI: Interrupt link LNKA configured for IRQ 0
Jan 11 14:25:52 dom0 kernel: ACPI: PCI: Interrupt link LNKB configured for IRQ 0
Jan 11 14:25:52 dom0 kernel: ACPI: PCI: Interrupt link LNKC configured for IRQ 0
Jan 11 14:25:52 dom0 kernel: ACPI: PCI: Interrupt link LNKD configured for IRQ 0
Jan 11 14:25:52 dom0 kernel: ACPI: PCI: Interrupt link LNKE configured for IRQ 0
Jan 11 14:25:52 dom0 kernel: ACPI: PCI: Interrupt link LNKF configured for IRQ 0
Jan 11 14:25:52 dom0 kernel: ACPI: PCI: Interrupt link LNKG configured for IRQ 0
Jan 11 14:25:52 dom0 kernel: ACPI: PCI: Interrupt link LNKH configured for IRQ 0
Jan 11 14:25:52 dom0 kernel: ACPI: \_SB_.PCI0.LPC0.EC0_: Boot DSDT EC initialization complete
Jan 11 14:25:52 dom0 kernel: ACPI: \_SB_.PCI0.LPC0.EC0_: EC: Used to handle transactions and events
Jan 11 14:25:52 dom0 kernel: PCI: Using ACPI for IRQ routing
Jan 11 14:25:52 dom0 kernel: PCI: pci_cache_line_size set to 64 bytes
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: vgaarb: setting as boot VGA device
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: vgaarb: bridge control possible
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.1: PCI bridge to [bus 01]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.1:   bridge window [mem 0xfd700000-0xfd7fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.3: PCI bridge to [bus 03]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.3:   bridge window [io  0x2000-0x2fff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.3:   bridge window [mem 0xfd600000-0xfd6fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.4: PCI bridge to [bus 04]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.4:   bridge window [mem 0xfd500000-0xfd5fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.6: PCI bridge to [bus 06]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.6:   bridge window [mem 0xfd400000-0xfd4fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:02.6:   bridge window [mem 0xe0200000-0xe02fffff 64bit pref]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1: PCI bridge to [bus 07]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1:   bridge window [io  0x1000-0x1fff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1:   bridge window [mem 0xfd000000-0xfd3fffff]
Jan 11 14:25:52 dom0 kernel: pci 0000:00:08.1:   bridge window [mem 0xd0000000-0xe01fffff 64bit pref]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: resource 4 [mem 0x000a0000-0x000effff window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: resource 5 [mem 0xd0000000-0xf7ffffff window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: resource 6 [mem 0xfc000000-0xfdffffff window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: resource 7 [io  0x0000-0x0cf7 window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:00: resource 8 [io  0x0d00-0xffff window]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:01: resource 1 [mem 0xfd700000-0xfd7fffff]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:03: resource 1 [mem 0xfd600000-0xfd6fffff]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:04: resource 1 [mem 0xfd500000-0xfd5fffff]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:06: resource 1 [mem 0xfd400000-0xfd4fffff]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:06: resource 2 [mem 0xe0200000-0xe02fffff 64bit pref]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:07: resource 0 [io  0x1000-0x1fff]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:07: resource 1 [mem 0xfd000000-0xfd3fffff]
Jan 11 14:25:52 dom0 kernel: pci_bus 0000:07: resource 2 [mem 0xd0000000-0xe01fffff 64bit pref]
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.1: D0 power state depends on 0000:07:00.0
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.3: extending delay after power-on from D3hot to 20 msec
Jan 11 14:25:52 dom0 kernel: pci 0000:07:00.4: extending delay after power-on from D3hot to 20 msec
Jan 11 14:25:52 dom0 kernel: PCI: CLS 32 bytes, default 64
Jan 11 14:25:52 dom0 kernel: PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Jan 11 14:25:52 dom0 kernel: pcieport 0000:00:02.1: PME: Signaling with IRQ 106
Jan 11 14:25:52 dom0 kernel: pcieport 0000:00:02.3: PME: Signaling with IRQ 107
Jan 11 14:25:52 dom0 kernel: pcieport 0000:00:02.4: PME: Signaling with IRQ 108
Jan 11 14:25:52 dom0 kernel: pcieport 0000:00:02.6: PME: Signaling with IRQ 109
Jan 11 14:25:52 dom0 kernel: pcieport 0000:00:08.1: PME: Signaling with IRQ 110
Jan 11 14:25:52 dom0 kernel: pci 0000:04:00.0: hash matches
Jan 11 14:25:52 dom0 kernel: xen_pciback: backend is vpci
Jan 11 14:25:52 dom0 systemd-modules-load[269]: Inserted module 'xen_pciback'
Jan 11 14:25:53 dom0 kernel: pciback 0000:03:00.0: xen_pciback: seizing device
Jan 11 14:25:54 dom0 kernel: pciback 0000:06:00.0: xen_pciback: seizing device
Jan 11 14:25:54 dom0 kernel: pciback 0000:06:00.0: enabling device (0000 -> 0002)
Jan 11 14:25:55 dom0 kernel: pciback 0000:06:00.0: not ready 1023ms after FLR; waiting
Jan 11 14:25:56 dom0 kernel: pciback 0000:06:00.0: not ready 2047ms after FLR; waiting
Jan 11 14:25:58 dom0 kernel: pciback 0000:06:00.0: not ready 4095ms after FLR; waiting
Jan 11 14:26:03 dom0 kernel: pciback 0000:06:00.0: not ready 8191ms after FLR; waiting
Jan 11 14:26:11 dom0 kernel: pciback 0000:06:00.0: not ready 16383ms after FLR; waiting
Jan 11 14:26:28 dom0 kernel: pciback 0000:06:00.0: not ready 32767ms after FLR; waiting
Jan 11 14:27:02 dom0 kernel: pciback 0000:06:00.0: not ready 65535ms after FLR; giving up
Jan 11 14:27:03 dom0 kernel: pciback 0000:07:00.3: xen_pciback: seizing device
Jan 11 14:27:03 dom0 kernel: pciback 0000:07:00.4: xen_pciback: seizing device
Jan 11 14:27:03 dom0 kernel: nvme nvme0: pci function 0000:01:00.0
Jan 11 14:27:03 dom0 kernel: sdhci-pci 0000:04:00.0: SDHCI controller found [1217:8621] (rev 1)
Jan 11 14:27:03 dom0 kernel: sdhci-pci 0000:04:00.0: enabling device (0000 -> 0002)
Jan 11 14:27:03 dom0 kernel: mmc0: SDHCI controller on PCI [0000:04:00.0] using ADMA
Jan 11 14:27:05 dom0 kernel: amdgpu 0000:07:00.0: amdgpu: PCIE atomic ops is not supported
Jan 11 14:27:05 dom0 kernel: [drm] PCIE GART of 1024M enabled.
Jan 11 13:29:06 dom0 kernel: snd_rn_pci_acp3x 0000:07:00.5: enabling device (0000 -> 0002)
Jan 11 13:29:06 dom0 kernel: input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:08.1/0000:07:00.1/sound/card0/input15
Jan 11 13:29:06 dom0 kernel: input: HD-Audio Generic HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:08.1/0000:07:00.1/sound/card0/input16
Jan 11 13:29:06 dom0 kernel: input: HD-Audio Generic HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:08.1/0000:07:00.1/sound/card0/input17
Jan 11 13:29:07 dom0 kernel: input: HD-Audio Generic Mic as /devices/pci0000:00/0000:00:08.1/0000:07:00.6/sound/card1/input18
Jan 11 13:29:07 dom0 kernel: input: HD-Audio Generic Headphone as /devices/pci0000:00/0000:00:08.1/0000:07:00.6/sound/card1/input19
Jan 11 13:29:19 dom0 kernel: pciback 0000:06:00.0: not ready 1023ms after FLR; waiting
Jan 11 13:29:20 dom0 kernel: pciback 0000:06:00.0: not ready 2047ms after FLR; waiting
Jan 11 13:29:22 dom0 kernel: pciback 0000:06:00.0: not ready 4095ms after FLR; waiting
Jan 11 13:29:27 dom0 kernel: pciback 0000:06:00.0: not ready 8191ms after FLR; waiting
Jan 11 13:29:36 dom0 kernel: pciback 0000:06:00.0: not ready 16383ms after FLR; waiting
Jan 11 13:29:52 dom0 kernel: pciback 0000:06:00.0: not ready 32767ms after FLR; waiting
Jan 11 13:30:27 dom0 kernel: pciback 0000:06:00.0: not ready 65535ms after FLR; giving up
Jan 11 13:30:29 dom0 kernel: pciback 0000:06:00.0: xen_pciback: vpci: assign to virtual slot 0
Jan 11 13:30:29 dom0 kernel: pciback 0000:06:00.0: registering for 2
Jan 11 13:30:29 dom0 kernel: pciback 0000:03:00.0: xen_pciback: vpci: assign to virtual slot 1
Jan 11 13:30:29 dom0 kernel: pciback 0000:03:00.0: registering for 2
Jan 11 13:30:31 dom0 kernel: pciback 0000:07:00.3: xen_pciback: vpci: assign to virtual slot 0
Jan 11 13:30:31 dom0 kernel: pciback 0000:07:00.3: registering for 4
Jan 11 13:30:31 dom0 kernel: pciback 0000:07:00.4: xen_pciback: vpci: assign to virtual slot 0 func 4
Jan 11 13:30:31 dom0 kernel: pciback 0000:07:00.4: registering for 4
Jan 11 13:30:31 dom0 kernel: pciback 0000:06:00.0: xen-pciback: Driver tried to write to a read-only configuration space field at offset 0x6, size 2. This may be harmless, but if you have problems with your device:
                             2) report problems to the xen-devel mailing list along with details of your device obtained from lspci.
Jan 11 13:30:31 dom0 kernel: pciback 0000:03:00.0: xen-pciback: Driver tried to write to a read-only configuration space field at offset 0x6, size 2. This may be harmless, but if you have problems with your device:
                             2) report problems to the xen-devel mailing list along with details of your device obtained from lspci.
Jan 11 13:30:31 dom0 kernel: pciback 0000:07:00.3: xen-pciback: Driver tried to write to a read-only configuration space field at offset 0x2a6, size 2. This may be harmless, but if you have problems with your device:
                             2) report problems to the xen-devel mailing list along with details of your device obtained from lspci.
Jan 11 13:30:31 dom0 kernel: pciback 0000:07:00.4: xen-pciback: Driver tried to write to a read-only configuration space field at offset 0x2a6, size 2. This may be harmless, but if you have problems with your device:
                             2) report problems to the xen-devel mailing list along with details of your device obtained from lspci.
4

Ok. Here’s what I would do. Actually I did it. Considering symptoms there are slight chances it is related to issue, but you should do that in regular circumstances anyway. Create separate sys-net for each controller. Then check if you’d need strict reset for any of it, set it if so, then test boot.

Other then that, I can only guess. Try to hide it from dom0 in grub, but first disable it in bios and test boot.

Check this also regarding (disabling) FLR

If you don’t come up with some new info after this, I am pretty much out of ideas, so please apologize. But, there’s plenty and will be more info after testing this so others could jump in with ideas.

5

Oh, and I don’t think it is necessary to set this manually anymore. Remove it from grub and test with

cat /sys/devices/system/clocksource//clocksource0/current_clocksource

in dom0.
It should show tsc anyway.

6

Thanks for the help!
clocksource=tsc is indeed default

I also noticed that the wireless card shows up as a device in sys-usb in the Devices Widget:
Sys-usb:4-3 – Mediatek_Inc._Wireless_Device_000000000
That seems to be the Bluetooth part of the wireless card, as it does not appear when Bluetooth is disabled in Bios.

It looks like my WiFi pci device doesn’t support strict reset. Anyway, I created a separate sys-net-wifi for the WiFi in addition to sys-net for the ethernet. I enabled no-strict-reset for both of them. That does not make a difference. I then also enabled permissive mode for the WiFi pci device, but that does not also make a difference.

I also noticed that in addition to the
pciback 0000:06:00.0: not ready X ms after FLR: waiting
messages after Grub and before the password screen, these same messages also appear later in the boot process during VM start jobs. This was the case before and is still the case now.
I copied the messages from journalctl and included more messages after those:

Jan 12 19:30:45 dom0 systemd[1]: Started Qubes memory information reporter.
Jan 12 19:30:45 dom0 systemd[1]: Starting Start Qubes VM sys-firewall...
Jan 12 19:30:45 dom0 systemd[1]: Starting Start Qubes VM sys-net-wifi...
Jan 12 19:30:45 dom0 systemd[1]: Starting Start Qubes VM sys-net...
Jan 12 19:30:45 dom0 systemd[1]: Starting Start Qubes VM sys-usb...
Jan 12 19:30:45 dom0 systemd[1]: Starting Start Qubes VM sys-whonix...
Jan 12 19:30:45 dom0 qubesd[3021]: vm.sys-firewall: Starting sys-firewall
Jan 12 19:30:45 dom0 qubesd[3021]: vm.sys-net-wifi: Starting sys-net-wifi
Jan 12 19:30:45 dom0 qubesd[3021]: vm.sys-usb: Starting sys-usb
Jan 12 19:30:45 dom0 qubesd[3021]: vm.sys-whonix: Starting sys-whonix
Jan 12 19:30:45 dom0 qubesd[3021]: vm.sys-net: Starting sys-net
Jan 12 19:30:45 dom0 lvm[2002]: No longer monitoring thin pool qubes_dom0-vm--pool-tpool.
Jan 12 19:30:45 dom0 lvm[2002]: Monitoring thin pool qubes_dom0-vm--pool-tpool.
Jan 12 19:30:45 dom0 lvm[2002]: No longer monitoring thin pool qubes_dom0-vm--pool-tpool.
Jan 12 19:30:45 dom0 lvm[2002]: Monitoring thin pool qubes_dom0-vm--pool-tpool.
Jan 12 19:30:46 dom0 kernel: memmap_init_zone_device initialised 32768 pages in 0ms
Jan 12 19:30:46 dom0 root[3914]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51728
Jan 12 19:30:46 dom0 root[3913]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51712
Jan 12 19:30:46 dom0 root[3921]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51744
Jan 12 19:30:46 dom0 root[3924]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51760
Jan 12 19:30:46 dom0 root[4036]: /etc/xen/scripts/block: Writing backend/vbd/1/51712/physical-device fd:67 to xenstore.
Jan 12 19:30:46 dom0 root[4038]: /etc/xen/scripts/block: Writing backend/vbd/1/51712/physical-device-path /dev/dm-103 to xenstore.
Jan 12 19:30:46 dom0 root[4040]: /etc/xen/scripts/block: Writing backend/vbd/1/51712/hotplug-status connected to xenstore.
Jan 12 19:30:46 dom0 root[4088]: /etc/xen/scripts/block: Writing backend/vbd/1/51728/physical-device fd:66 to xenstore.
Jan 12 19:30:46 dom0 root[4090]: /etc/xen/scripts/block: Writing backend/vbd/1/51728/physical-device-path /dev/dm-102 to xenstore.
Jan 12 19:30:46 dom0 root[4092]: /etc/xen/scripts/block: Writing backend/vbd/1/51728/hotplug-status connected to xenstore.
Jan 12 19:30:46 dom0 root[4137]: /etc/xen/scripts/block: Writing backend/vbd/1/51744/physical-device fd:68 to xenstore.
Jan 12 19:30:46 dom0 root[4139]: /etc/xen/scripts/block: Writing backend/vbd/1/51744/physical-device-path /dev/dm-104 to xenstore.
Jan 12 19:30:46 dom0 root[4141]: /etc/xen/scripts/block: Writing backend/vbd/1/51744/hotplug-status connected to xenstore.
Jan 12 19:30:46 dom0 kernel: loop: module loaded
Jan 12 19:30:46 dom0 kernel: loop0: detected capacity change from 0 to 1071840
Jan 12 19:30:46 dom0 root[4167]: /etc/xen/scripts/block: Writing backend/vbd/1/51760/node /dev/loop0 to xenstore.
Jan 12 19:30:46 dom0 root[4171]: /etc/xen/scripts/block: Writing backend/vbd/1/51760/physical-device 7:0 to xenstore.
Jan 12 19:30:46 dom0 root[4173]: /etc/xen/scripts/block: Writing backend/vbd/1/51760/physical-device-path /dev/loop0 to xenstore.
Jan 12 19:30:46 dom0 root[4175]: /etc/xen/scripts/block: Writing backend/vbd/1/51760/hotplug-status connected to xenstore.
Jan 12 19:30:46 dom0 root[4202]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/51712
Jan 12 19:30:46 dom0 root[4207]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/51728
Jan 12 19:30:46 dom0 root[4213]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/51744
Jan 12 19:30:46 dom0 root[4217]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/51760
Jan 12 19:30:46 dom0 root[4346]: /etc/xen/scripts/block: Writing backend/vbd/2/51712/physical-device fd:67 to xenstore.
Jan 12 19:30:46 dom0 root[4348]: /etc/xen/scripts/block: Writing backend/vbd/2/51712/physical-device-path /dev/dm-103 to xenstore.
Jan 12 19:30:46 dom0 root[4350]: /etc/xen/scripts/block: Writing backend/vbd/2/51712/hotplug-status connected to xenstore.
Jan 12 19:30:46 dom0 root[4417]: /etc/xen/scripts/block: Writing backend/vbd/2/51728/physical-device fd:66 to xenstore.
Jan 12 19:30:46 dom0 root[4419]: /etc/xen/scripts/block: Writing backend/vbd/2/51728/physical-device-path /dev/dm-102 to xenstore.
Jan 12 19:30:46 dom0 root[4421]: /etc/xen/scripts/block: Writing backend/vbd/2/51728/hotplug-status connected to xenstore.
Jan 12 19:30:46 dom0 root[4485]: /etc/xen/scripts/block: Writing backend/vbd/2/51744/physical-device fd:68 to xenstore.
Jan 12 19:30:46 dom0 root[4487]: /etc/xen/scripts/block: Writing backend/vbd/2/51744/physical-device-path /dev/dm-104 to xenstore.
Jan 12 19:30:46 dom0 root[4489]: /etc/xen/scripts/block: Writing backend/vbd/2/51744/hotplug-status connected to xenstore.
Jan 12 19:30:46 dom0 kernel: loop1: detected capacity change from 0 to 1071840
Jan 12 19:30:46 dom0 root[4514]: /etc/xen/scripts/block: Writing backend/vbd/2/51760/node /dev/loop1 to xenstore.
Jan 12 19:30:46 dom0 root[4518]: /etc/xen/scripts/block: Writing backend/vbd/2/51760/physical-device 7:1 to xenstore.
Jan 12 19:30:46 dom0 root[4520]: /etc/xen/scripts/block: Writing backend/vbd/2/51760/physical-device-path /dev/loop1 to xenstore.
Jan 12 19:30:46 dom0 root[4522]: /etc/xen/scripts/block: Writing backend/vbd/2/51760/hotplug-status connected to xenstore.
Jan 12 19:30:48 dom0 kernel: pciback 0000:06:00.0: not ready 1023ms after FLR; waiting
Jan 12 19:30:49 dom0 kernel: pciback 0000:06:00.0: not ready 2047ms after FLR; waiting
Jan 12 19:30:51 dom0 kernel: pciback 0000:06:00.0: not ready 4095ms after FLR; waiting
Jan 12 19:30:55 dom0 kernel: pciback 0000:06:00.0: not ready 8191ms after FLR; waiting
Jan 12 19:31:04 dom0 kernel: pciback 0000:06:00.0: not ready 16383ms after FLR; waiting
Jan 12 19:31:21 dom0 kernel: pciback 0000:06:00.0: not ready 32767ms after FLR; waiting
Jan 12 19:31:54 dom0 kernel: pciback 0000:06:00.0: not ready 65535ms after FLR; giving up
Jan 12 19:31:55 dom0 kernel: pciback 0000:06:00.0: xen_pciback: vpci: assign to virtual slot 0
Jan 12 19:31:55 dom0 kernel: pciback 0000:06:00.0: registering for 2
Jan 12 19:31:55 dom0 kernel: xen-blkback: backend/vbd/2/51712: using 1 queues, protocol 1 (x86_64-abi) persistent grants
Jan 12 19:31:55 dom0 kernel: xen-blkback: backend/vbd/2/51728: using 1 queues, protocol 1 (x86_64-abi) persistent grants
Jan 12 19:31:55 dom0 kernel: xen-blkback: backend/vbd/2/51744: using 1 queues, protocol 1 (x86_64-abi) persistent grants
Jan 12 19:31:55 dom0 kernel: xen-blkback: backend/vbd/2/51760: using 1 queues, protocol 1 (x86_64-abi) persistent grants
Jan 12 19:31:56 dom0 kernel: xen: registering gsi 40 triggering 0 polarity 1
Jan 12 19:31:56 dom0 kernel: Already setup the GSI :40
Jan 12 19:31:56 dom0 qubesd[3021]: vm.sys-net-wifi: Setting Qubes DB info for the VM
Jan 12 19:31:56 dom0 qubesd[3021]: vm.sys-net-wifi: Starting Qubes DB
Jan 12 19:31:56 dom0 audit[4534]: CRED_ACQ pid=4534 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_rootok acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 kernel: kauditd_printk_skb: 25 callbacks suppressed
Jan 12 19:31:56 dom0 kernel: audit: type=1103 audit(1673548316.401:137): pid=4534 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_rootok acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 runuser[4534]: pam_unix(runuser:session): session opened for user User by (uid=0)
Jan 12 19:31:56 dom0 audit[4534]: USER_START pid=4534 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_unix acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 kernel: audit: type=1105 audit(1673548316.403:138): pid=4534 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_unix acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 runuser[4534]: pam_unix(runuser:session): session closed for user User
Jan 12 19:31:56 dom0 audit[4534]: USER_END pid=4534 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_unix acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 audit[4534]: CRED_DISP pid=4534 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_rootok acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 kernel: audit: type=1106 audit(1673548316.409:139): pid=4534 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_unix acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 kernel: audit: type=1104 audit(1673548316.409:140): pid=4534 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_rootok acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 qubesd[3021]: vm.sys-net-wifi: Activating the sys-net-wifi VM
Jan 12 19:31:56 dom0 audit[4544]: CRED_ACQ pid=4544 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_rootok acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 runuser[4544]: pam_unix(runuser:session): session opened for user User by (uid=0)
Jan 12 19:31:56 dom0 audit[4544]: USER_START pid=4544 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_unix acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 kernel: audit: type=1103 audit(1673548316.426:141): pid=4544 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_rootok acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 kernel: audit: type=1105 audit(1673548316.426:142): pid=4544 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_unix acct="User" exe="/usr/sbin/runuser" hostname=? addr=? terminal=? res=success'
Jan 12 19:31:56 dom0 lvm[2002]: No longer monitoring thin pool qubes_dom0-vm--pool-tpool.
Jan 12 19:31:56 dom0 lvm[2002]: Monitoring thin pool qubes_dom0-vm--pool-tpool.
Jan 12 19:31:56 dom0 lvm[2002]: No longer monitoring thin pool qubes_dom0-vm--pool-tpool.
Jan 12 19:31:56 dom0 lvm[2002]: Monitoring thin pool qubes_dom0-vm--pool-tpool.
Jan 12 19:31:56 dom0 root[4732]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/3/51712
Jan 12 19:31:56 dom0 root[4742]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/3/51728
Jan 12 19:31:56 dom0 root[4746]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/3/51744
Jan 12 19:31:56 dom0 root[4749]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/3/51760
Jan 12 19:31:56 dom0 root[4878]: /etc/xen/scripts/block: Writing backend/vbd/3/51712/physical-device fd:6b to xenstore.
Jan 12 19:31:57 dom0 root[4880]: /etc/xen/scripts/block: Writing backend/vbd/3/51712/physical-device-path /dev/dm-107 to xenstore.
Jan 12 19:31:57 dom0 root[4882]: /etc/xen/scripts/block: Writing backend/vbd/3/51712/hotplug-status connected to xenstore.
Jan 12 19:31:57 dom0 root[4948]: /etc/xen/scripts/block: Writing backend/vbd/3/51728/physical-device fd:69 to xenstore.
Jan 12 19:31:57 dom0 root[4950]: /etc/xen/scripts/block: Writing backend/vbd/3/51728/physical-device-path /dev/dm-105 to xenstore.
Jan 12 19:31:57 dom0 root[4952]: /etc/xen/scripts/block: Writing backend/vbd/3/51728/hotplug-status connected to xenstore.
Jan 12 19:31:57 dom0 root[5015]: /etc/xen/scripts/block: Writing backend/vbd/3/51744/physical-device fd:6a to xenstore.
Jan 12 19:31:57 dom0 root[5017]: /etc/xen/scripts/block: Writing backend/vbd/3/51744/physical-device-path /dev/dm-106 to xenstore.
Jan 12 19:31:57 dom0 root[5019]: /etc/xen/scripts/block: Writing backend/vbd/3/51744/hotplug-status connected to xenstore.
Jan 12 19:31:57 dom0 kernel: loop2: detected capacity change from 0 to 957384
Jan 12 19:31:57 dom0 root[5044]: /etc/xen/scripts/block: Writing backend/vbd/3/51760/node /dev/loop2 to xenstore.
Jan 12 19:31:57 dom0 root[5048]: /etc/xen/scripts/block: Writing backend/vbd/3/51760/physical-device 7:2 to xenstore.
Jan 12 19:31:57 dom0 root[5050]: /etc/xen/scripts/block: Writing backend/vbd/3/51760/physical-device-path /dev/loop2 to xenstore.
Jan 12 19:31:57 dom0 root[5052]: /etc/xen/scripts/block: Writing backend/vbd/3/51760/hotplug-status connected to xenstore.
Jan 12 19:31:57 dom0 root[5076]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/51712
Jan 12 19:31:57 dom0 root[5081]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/51728
Jan 12 19:31:57 dom0 root[5088]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/51744
Jan 12 19:31:57 dom0 root[5097]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/51760
Jan 12 19:31:57 dom0 root[5241]: /etc/xen/scripts/block: Writing backend/vbd/4/51712/physical-device fd:6b to xenstore.
Jan 12 19:31:57 dom0 root[5243]: /etc/xen/scripts/block: Writing backend/vbd/4/51712/physical-device-path /dev/dm-107 to xenstore.
Jan 12 19:31:57 dom0 root[5245]: /etc/xen/scripts/block: Writing backend/vbd/4/51712/hotplug-status connected to xenstore.
Jan 12 19:31:57 dom0 root[5330]: /etc/xen/scripts/block: Writing backend/vbd/4/51728/physical-device fd:69 to xenstore.
Jan 12 19:31:57 dom0 root[5332]: /etc/xen/scripts/block: Writing backend/vbd/4/51728/physical-device-path /dev/dm-105 to xenstore.
Jan 12 19:31:57 dom0 root[5334]: /etc/xen/scripts/block: Writing backend/vbd/4/51728/hotplug-status connected to xenstore.
Jan 12 19:31:57 dom0 root[5416]: /etc/xen/scripts/block: Writing backend/vbd/4/51744/physical-device fd:6a to xenstore.
Jan 12 19:31:57 dom0 root[5418]: /etc/xen/scripts/block: Writing backend/vbd/4/51744/physical-device-path /dev/dm-106 to xenstore.
Jan 12 19:31:57 dom0 root[5420]: /etc/xen/scripts/block: Writing backend/vbd/4/51744/hotplug-status connected to xenstore.
Jan 12 19:31:57 dom0 kernel: loop3: detected capacity change from 0 to 957384
Jan 12 19:31:57 dom0 root[5445]: /etc/xen/scripts/block: Writing backend/vbd/4/51760/node /dev/loop3 to xenstore.
Jan 12 19:31:57 dom0 root[5449]: /etc/xen/scripts/block: Writing backend/vbd/4/51760/physical-device 7:3 to xenstore.
Jan 12 19:31:57 dom0 root[5451]: /etc/xen/scripts/block: Writing backend/vbd/4/51760/physical-device-path /dev/loop3 to xenstore.
Jan 12 19:31:57 dom0 root[5453]: /etc/xen/scripts/block: Writing backend/vbd/4/51760/hotplug-status connected to xenstore.
Jan 12 19:31:57 dom0 kernel: pciback 0000:06:00.0: xen-pciback: Driver tried to write to a read-only configuration space field at offset 0x6, size 2. This may be harmless, but if you have problems with your device:
                             1) see permissive attribute in sysfs
                             2) report problems to the xen-devel mailing list along with details of your device obtained from lspci.
Jan 12 19:31:57 dom0 kernel: pciback 0000:07:00.3: xen_pciback: vpci: assign to virtual slot 0
Jan 12 19:31:57 dom0 kernel: pciback 0000:07:00.3: registering for 4
Jan 12 19:31:57 dom0 kernel: pciback 0000:07:00.4: xen_pciback: vpci: assign to virtual slot 0 func 4
Jan 12 19:31:57 dom0 kernel: pciback 0000:07:00.4: registering for 4

I had to shorten the journalctl messages, as I exceeded the maximum character limit of 32000 for a post by 19275 :upside_down_face:
I posted the full length here:

When I disable WiFi in Bios, going from Grub to disk password screen only takes a few seconds. No messages about the pci device. The VM start jobs at the end of the boot process are then also a lot faster.
However, of course WiFi won’t work then.

Since it is a WiFi+Bluetooth card, I was thinking I might enable WiFi in bios but disable Bluethooth in bios.
Then the pci device is visible again, but with the same problems as before.

I also tried hiding it from dom0 with:
rd.qubes.hide_pci=06:00.0
The pciback 0000:06:00.0: not ready X ms after FLR: waiting messages will then still appear. After some messages, the “waiting” will change to “giving up” like usual, however it will just start trying again then. After a while the "waiting for device /dev/diskby-uuid/*id/ will time out and the depencies for Cryptography Setup for luks-id and Local Encrypted Volumes will fail. The messages “not ready X ms after FLR: Waiting” will continue. After some time, the boot screen finally appears, however there is no possibility to enter the password due to the failed dependencies.

If I can supply more logs please let me know. I’m not an expert user.

7

What is the reason to do that in regular circumstances? Just to reduce attack surface and compartmentalize more in case on of the network controllers gets compromised? I’m using WiFi most of the time, rarely on ethernet. I guess if you use both more or connect to untrusted networks, it would be more benificial to have 2 sys-nets.

8

Exactly.

I’m practicing exactly the opposite, hopefully reducing surface attack via wifi.

Not as I see it. You don’t have to use both controllers in the same sys-net in order both to be compromised. It is enough one to be compromised to poison everything found in such a sys-net.

So, isolating from each other in order to spare the other one is the point.

I am sorry I couldn’t be of a greater help, but I’m pretty much out of ideas, except I’d try with BIOS update, kernel-latest and weekly kernel builds, as well as some quirks like this one to disable FLR, for example

Anyway, I think there’s enough info now so other, more skilled users could jump in with an idea.

9

Ah thanks for explaining.

Hmm, compiling my own kernel to disable FLR is a bit too advanced for me.
BIOS is already on the latest version. I already used kernel-latest but that was 6.0.x from the stable repo. I just enabled the testing repo to get a Xen update for fixing suspend, which also got me the 6.1.x kernel, however that does not make a difference.

Maybe other users do indeed have ideas.

Do you think this could be fixed by getting another WiFi card or do you think the problem is with the PCI controller rather than with the WiFi card?

1 Like
10

If it’s replaceable, I’d try anyway. Or, I’d use cheapest USB dongle. But I’d first use ethernet as I said, and wouldn’t bother with wifi at all, but that’s only me, haha.

As the guy there said…

finally I found the inner strength to try

ain’t gonna hurt, and it’s not you that will compile it, but your computer, hahha. I would and will once needed definitely.

My suggestion would be to leave the topic for a week or so, and then to bump it, so to more other users would read it. I guess that many that open topics and see a lot of posts think it is resolved or it cannot be resolved, but after a while when they see and open the last message saying “Bump?” only, would more likely jump in.

I did it so a few times to my favor.

1 Like
12

Hahaha. Well, maybe in the future, never say never :slight_smile:
I reported the issue to Lenovo as well and ordered another WiFi card as it is replacable, so maybe that won’t suffer from the same problems.

1 Like
13

I just switched the AMD RZ616 for an Intel AX200. No more PCI issues now, so it is definitely related to the card itself.
If anyone else has any ideas how to fix the issues with the AMD RZ616, it would still be appreciated.

14

Bump?

15

I ran into the same issue right now and finally know why my new laptop is booting so awfully slow. I have not tried it out yet, but in this askubuntu thread someone without qubes has the same issue and claims the culprit is your former Windows installation which leaves the WiFi card in some weird state the linux driver cannot handle. The solution their was to pull out the CMOS battery, I guess to clear all BIOS settings. Will try this soon.

16

So… I cannot recommend to update UEFI using a USB thumb drive and the non-Windows installer. The UEFI update completed without issues, but afterwards, the laptop refused to boot both Qubes from internal NVMe as well as any Linux live system from a thumb drive. I tried resetting the BIOS settings via the menu and pressing the emergency reset button in the hole on the bottom side. Nothing changed anything. Btw. I am using an L15 AMD Gen 3, but I doubt 15" vs. 14" makes any difference.

Fortunately, I still had the original NVMe with the original Windows. So I opened up the laptop again and swapped this one in. Windows booted instantly. So I restarted the laptop to look into the BIOS setting. Suddenly there was an option that has not been there before. Something about “Internal storage protection” which said it will block boot after the NVMe has been replaced. It must have been introduced when I update from 1.08 to 1.26 UEIF and was on by default. So I switched it off… and Windows failed to boot. It was now stuck in a boot loop where the Windows boot loader blue screened with “INACCESSIBLE_BOOT_DEVICE”. Switching this internal storage protection on again was not possible, the BIOS setting was gone again. I then googled that error and followed the the first three steps of this German Windows 10 repair guide. It took some minutes, but fortunately Windows booted again, eventually. I then let Windows install dozens of updates over the course of two hours, including five or more reboots. This included Lenovo firmware updates, so it might be that updating the UEFI alone – though the update claimed it also flashed the embedded controller – might have cause incompatible firmware versions among all the controllers and modules inside the laptop.

Once all this has finished and Windows is happy and up-to-date, I will kindly ask the laptop to boot the other NVMe with Qubes and see what happens. I did not expect my Sunday to be that scary.

17

Hmm, updating BIOS from USB thumb drive never gave me those issues. I just use DD command to put the iso on the thumb drive. Works everytime for me.
Then again, I never had the old 1.08 version. When I got my L14, it was already on 1.14.

18

I don’t think the issue was using a thumb drive. I used dd to copy and compared with sha256sum afterwards. If that were the issue, I would have expected an error during the update. I guess it was more some “security settings” that got introduced with the update.

19

Ah I’ve never switched the internal drive, so that may be it. Afaik there is a general issue with UEFI where the boot entry dissappears when you switch drives. Combining that with BIOS updates in between may make it worse.