Search results

I have a similar situation with 6.14.8 when passing through a SATA (AHCI) controller: kvm: -device vfio-pci,host=0000:00:1f.0,id=hostpci0.0,bus=ich9-pcie-port-1,addr=0x0.0,multifunction=on: vfio 0000:00:1f.0: error getting device from group 24: Permission denied Verify all devices in group 24...

Do you have the “firmware-ast” package installed?

Disabling the `nmi_watchdog` seems to have returned things to stability after a few days of testing. I admittedly do not have deep knowledge of the workings of the kernel, but that appears to be what I needed to disable to prevent the igb driver instability as I posted in my first post.

Not yet, if it's a definite fix I'd be happy to give that a try. I'd rather be keen to find what changed between 6.8 / 6.11 and 6.14 to cause the issue... given the rock solid stability of the older kernels.

I am having serious issues with the igb driver on 6.14 that I did not experience on 6.8 or 6.11. I tested on the first release of 6.14 and the subsequent patch release -2. Computer is a Compulab Fitlet2 Celeron J3455 with 4x Intel i211 adapters. Only VM is opnsense with no PCIe passthrough...

Installed kernel 6.11 across a few different hosts without issues, but I am not doing anything too fancy beyond the callouts below: Compulab Fitlet2 J3455 -- running opnsense as a VM Supermicro X10SDV-4C+-TLN4F -- SATA controller passththrough to Openmediavalut VM Supermicro A2SDi-2C-HLN4F --...

Hi All - I decided to give btrfs a try as my root FS on a single mSATA SSD. Everything seems fine aside from boot times - for some reason, GRUB hangs on the "welcome to Grub!" message for a solid 20 seconds. Grub's also seems slow to respond. Once the kernel is loaded and the initrd is...

I had a weird crash overnight with 5.15.12-1-pve #1 SMP PVE 5.15.12-3. NMI watchdog caught it and restarted the host. Relevant info follows: I've attached the dmsg output from the boot after the crash. I've blacklisted the intel i915 drivers and pnd2_edac since I am not using ECC ram...

I'll mark this as solved. 3 days of solid uptime with nopti set at boot time. @mira could you confirm if the kernel is supposed to disable the kernel-level PTI mitigations for meltdown if the microcode / CPU being used already is safe? A thread on the intel community site seems to claim such.

I'm now running stable only with nopti; mitigations=off has been disabeld. Per Intel, the Apollo Lake series chips are microcode-protected from Meltdown, making kernel PTI redundant. I'll post a final update in a few days should this fix stick.

Jumping in on my own thread here: Based on the stability with the mitigations=off and nopti, I've moved my routing traffic back to the (formerly?) crash-prone box. This is in an effort to stress the environment and make it do _something_ naughty, if possible. I'm still keen to provide...

Some good news. turning off the Specter etc. mitigations and setting nopti resulted in my first 24h uptime since these issues started. I’ll continue to let things run as long as they can before I fall back to the 5.4 kernel. If the mitigations or nopti are the issue, what data would be useful...

Happy to do this if my mitigations=off test fails. Given past crashes, I should know by tomorrow. Is there any way to force the 5.4 kernel to install on 7.0 by chance?

BIOS is 100% up to date with the latest from Compulab (as of my post yesterday). The other install is, OS package and partitioning-wise 100% identical. The other install, however, is on a Supermicro Xeon-D-based motherboard on an NVME boot drive. More or less apples to oranges with the...

Hi everyone, First post; I'll try to provide as much as I can. A stock install of 7.0, fresh off the ISO, was running stable for me for a few weeks. I then did the usual process of updating packages and a reboot. Now my prox host has random crashes about once every 6-18 hours even with...