Kernel Panic after resuming from suspension #60
Comments
mingww64
changed the title
|
Hi @felicia-wen: Could you please help me to see how is this report related to #11? The cited issue talks about 14.0-CURRENT and the use of Based on the stack trace you included here, this might be a bug in the base system. It might also make sense to take a chance with 13-STABLE. The logs show a system with an AMD CPU which may have not received that much attention as for the Intel CPUs. |
|
The contents of |
I just upgraded the system to 14.0-CURRENT without bhyve+ installed, according to #11
When I run |
Sorry for the inconvenience. This is the new log between a normal boot and a restart after |
I do not think that #11 is relevant in this case. As you can see in the last comment, that issue was resolved by switching to the
Wifibox attempts to clear the |
|
I'm seeing similar behavior on my system. I would believe that indeed, it is either a problem with the FreeBSD base system or with the wifi device itself (BCM43602 in my case). I'm also seeing that "The PPT device could not be destroyed" warning. But at least I can explain that. Take for example the attaching,detatching,clearing, of the driver: The message |
|
@mingww64 and @pgj: The issue is either in how bhyve destroys the VM, or in how FreeBSD's pci kernel code handles destruction. Possibly also the firmware itself (highly likely). Anyways, You can successfully suspend if you connect to the VM work out the in-vm pci number ( Three weeks of debugging FreeBSD's kernel and all it took was a one-liner😬 I'll open a proper bug report soon, and I would imagine a proper bug report to FreeBSD-src soon. I would imagine a solution for wifibox would be to include an option to automatically "remove" the device from the VM when wifibox is stopped. That way, the sequence can be suspend->remove from vm->stop wifibox->unload vmm->resume->start wifibox. |
|
I've written-up the issue here: https://joshua.hu/brcmfmac-bcm43602-suspension-shutdown-hanging-freeze-linux-freebsd-wifi-bug-pci-passthru The tl;dr is that the upon shutdown of the VM, the pcie device is not properly reset, leaving it in an inconsistent state. I will submit a patch to Linux with the very big patch: |
|
Nice work @MegaManSec, thank you for tracking down this issue! Since we can control all the packages for Wifibox/Alpine, the guest image that is shipped for Wifibox by default, I could include your patch to the Linux kernel until it is merged upstream. Do I understand it right that if this is done, we would not need to do anything else on the Wifibox (script) side? |
|
Yes, the patch should be sufficient in of itself. The only issue I can see is if the "kill -SIGTERM" to the VM does not complete before the VM is forcefully stopped. If we want extra protection, when the VM is stopped, we could somehow signal to the VM to directly "remove" the pci device from inside the Linux VM (rather than it be part of the shutdown sequence). |
- Update to Alpine Linux 3.20.2 - Update Linux to 6.6.47 (LTS) - Update Linux to 6.10.6 (edge) - Update linux-firmware to 20240811 - Update mt76 firmware to 4e8167b9 - Update rtl8821ce to 20240326 - Update rtw88 to 20240811 - Update rtw89 to 20240819 - Mitigate the issue with shutting down BRCM43602 chips [1] [1] pgj/freebsd-wifibox#60
- Update to Alpine Linux 3.20.2 - Update Linux to 6.6.47 (LTS) - Update Linux to 6.10.6 (edge) - Update linux-firmware to 20240811 - Update mt76 firmware to 4e8167b9 - Update rtl8821ce to 20240326 - Update rtw88 to 20240811 - Update rtw89 to 20240819 - Mitigate the issue with shutting down BRCM43602 chips [1] [1] pgj/freebsd-wifibox#60
- Update to Alpine Linux 3.20.2 - Update Linux to 6.6.47 (LTS) - Update Linux to 6.10.6 (edge) - Update linux-firmware to 20240811 - Update mt76 firmware to 4e8167b9 - Update rtl8821ce to 20240326 - Update rtw88 to 20240811 - Update rtw89 to 20240819 - Mitigate the issue with shutting down BRCM43602 chips [1] [1] pgj/freebsd-wifibox#60
The guest operating system has to release the devices that were shared via PCI pass-through otherwise they might get stuck and can eventually bring down the entire host. Relates to pgj/freebsd-wifibox#60
The guest operating system has to release the devices that were shared via PCI pass-through otherwise they might get stuck and can eventually bring down the entire host. Relates to pgj/freebsd-wifibox#60
- Explicitly remove PCI wireless devices on shutdown [1] [1] pgj/freebsd-wifibox#60
- Explicitly remove PCI wireless devices on shutdown [1] [1] pgj/freebsd-wifibox#60
The guest operating system has to release the devices that were shared via PCI pass-through otherwise they might get stuck and can eventually bring down the entire host. Relates to pgj/freebsd-wifibox#60
- Explicitly remove PCI wireless devices on shutdown [1] [1] pgj/freebsd-wifibox#60
The guest operating system has to release the devices that were shared via PCI pass-through otherwise they might get stuck and can eventually bring down the entire host. Relates to pgj/freebsd-wifibox#60
The guest operating system has to release the devices that were shared via PCI pass-through otherwise they might get stuck and can eventually bring down the entire host. Relates to pgj/freebsd-wifibox#60
The guest operating system has to release the devices that were shared via PCI pass-through otherwise they might get stuck and can eventually bring down the entire host. Relates to pgj/freebsd-wifibox#60
The guest operating system has to release the devices that were shared via PCI pass-through otherwise they might get stuck and can eventually bring down the entire host. Relates to pgj/freebsd-wifibox#60
- Explicitly remove PCI wireless devices on shutdown [1] [1] pgj/freebsd-wifibox#60
|
Version You can test this version by checking out the https://github.com/pgj/freebsd-wifibox-port/tree/chore/net/wifibox-alpine/20240823 |
|
It works with some changes. From bhyve manpage: However, vm_stop() kills the vm_stop kills But the shell script does not forward the signal to bhyve. Fixed in #110 |
|
And the only case I can tell where the fix does not work, is if the VM is killed while it is starting up -- it seems that Linux will not perform an ACPI poweroff while it is starting up. I assume there's nothing we can do about that, though. |
|
Yes, that is an acknowledged risk. |
The guest operating system has to release the devices that were shared via PCI pass-through otherwise they might get stuck and can eventually bring down the entire host. Relates to pgj/freebsd-wifibox#60
- Update to Alpine Linux 3.20.3 - Update Linux LTS to 6.6.50 - Update Linux edge to 6.10.9 - Update linux-firmware to 20240909 - Update mt76 firmware to bec8cb85 - Update rtw88 to 20240822 - Update rtw89 to 20240825 - Mitigate the issue with shutting down BRCM43602 chips [1] which was missed out in the 20240821 update [1] pgj/freebsd-wifibox#60
- Update to Alpine Linux 3.20.3 - Update Linux LTS to 6.6.50 - Update Linux edge to 6.10.9 - Update linux-firmware to 20240909 - Update mt76 firmware to bec8cb85 - Update rtw88 to 20240822 - Update rtw89 to 20240825 - Mitigate the issue with shutting down BRCM43602 chips [1] which was missed out in the 20240821 update [1] pgj/freebsd-wifibox#60
Description
As described in #11 (comment), the ppt device must be detached before unloading
vmm. However, more is needed.Steps to reproduce:
Suspend and resume
or
wifibox restart vmmor
wifibox stop guestklmunload vmmHost operating system
Wireless NIC
ppt0@pci0:1:0:0: class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2723 subvendor=0x8086 subdevice=0x0084 vendor = 'Intel Corporation' device = 'Wi-Fi 6 AX200' class = networkWifibox version
Disk image type and version
The kind of VM image in use, e.g. Wifibox/Alpine, and its version.
Changes to the default configuration files
Logs
Additional context
Crash dump
Have you tried to turn it on and off?
The text was updated successfully, but these errors were encountered: