Opt-in Linux Kernel 5.15 for Proxmox VE 7.x available

Maybe some peopel ignored that but after the Upgrade today my iSCSI is broken again.
Even a reinstall can´t fix that issue.
Can someone help me?

Kind regards,
---
Update: Old kernel and its working again:
Code: 
May 05 15:59:17 NucMox01 iscsiadm[634]: Logging in to [iface: default, target: iqn.2004-04.com.qnap:ts-251plus:iscsi.lun.147903, portal: 172.16.24.199,3260]
May 05 15:59:17 NucMox01 iscsiadm[634]: Logging in to [iface: default, target: iqn.2004-04.com.qnap:ts-251plus:iscsi.lun.147903, portal: 253.253.253.253,3260]
May 05 15:59:17 NucMox01 iscsiadm[634]: Login to [iface: default, target: iqn.2004-04.com.qnap:ts-251plus:iscsi.lun.147903, portal: 172.16.24.199,3260] successful.
 
Last edited:
I don't know if this is a good place to continue this discussion, but as it seems most of the previous discussion of the issues relating to the efifb change is in this thread it might make sense to continue here even though the affected kernels are no longer opt-in.


Just ran into the 5.15 kernel resulting in no display issue after upgrading to a 7.1 system to 7.2:
pve-kernel-5.15.30-2-pve 5.15.30-3
pve-kernel-helper 7.2-2

This is on a machine with an Asrock Rack motherboard with ASPEED graphics.

It appears that "simplefb" is indeed loaded early on, as intended, but that does not result in any display output during early boot (initramfs etc)

[ 11.456186] simple-framebuffer simple-framebuffer.0: framebuffer at 0xfb000000, 0x1d5000 bytes
[ 11.456191] simple-framebuffer simple-framebuffer.0: format=a8r8g8b8, mode=800x600x32, linelength=3200
[ 11.456256] Console: switching to colour frame buffer device 100x37
[ 11.485771] simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!


However later in the boot process "ast" is loaded and display is restored (I assume that is what does it, anyway).

[ 30.872558] ast 0000:29:00.0: [drm] Using P2A bridge for configuration
[ 30.890569] ast 0000:29:00.0: [drm] AST 2500 detected
[ 30.908147] ast 0000:29:00.0: [drm] Analog VGA only
[ 30.925632] ast 0000:29:00.0: [drm] dram MCLK=800 Mhz type=7 bus_width=16
[ 30.943543] [drm] Initialized ast 0.1.0 20120228 for 0000:29:00.0 on minor 0

This is as it appears over IPMI/ipkvm, I have no idea what it looks like on the local console (that is rather pointless, anyway).
I do know, however, that with the 5.13 / efifb setup this problem did not occur.

I hope there is some way to get this sorted.
I suppose one could get ast (and I guess it's firmware?) into initramfs, but that seems a bit messy, and I assume the intention is that simplefb should be able to work anywhere?
 
I've had to downgrade to 5.13 to get any kind of gpu passthrough working to my guest VMs again. On 5.15 the error messages below flood syslog *rapidly* to the point of filling the root partition with a multi-gigabyte sized /var/log/syslog

nb: this is with simplefb disabled as well as all other previously disabled frame buffer drivers that would init the device before vfio-pci bound to it

Code: 
May  5 17:11:56 monolith QEMU[11486]: kvm: vfio_region_write(0000:41:00.0:region1+0xff8, 0x0,8) failed: Device or resource busy
May  5 17:11:56 monolith QEMU[11486]: kvm: vfio_region_write(0000:41:00.0:region1+0xff0, 0x0,8) failed: Device or resource busy
May  5 17:11:56 monolith QEMU[11486]: kvm: vfio_region_write(0000:41:00.0:region1+0xfe8, 0x0,8) failed: Device or resource busy
May  5 17:11:56 monolith QEMU[11486]: kvm: vfio_region_write(0000:41:00.0:region1+0xfe0, 0x0,8) failed: Device or resource busy
May  5 17:11:56 monolith kernel: [  238.896601] vfio-pci 0000:41:00.0: BAR 1: can't reserve [mem 0x80000000-0x8fffffff 64bit pref]
May  5 17:11:56 monolith QEMU[11486]: kvm: vfio_region_write(0000:41:00.0:region1+0xfd8, 0x0,8) failed: Device or resource busy
May  5 17:11:56 monolith kernel: [  238.896682] vfio-pci 0000:41:00.0: BAR 1: can't reserve [mem 0x80000000-0x8fffffff 64bit pref]
May  5 17:11:56 monolith kernel: [  238.896692] vfio-pci 0000:41:00.0: BAR 1: can't reserve [mem 0x80000000-0x8fffffff 64bit pref]
May  5 17:11:56 monolith kernel: [  238.896702] vfio-pci 0000:41:00.0: BAR 1: can't reserve [mem 0x80000000-0x8fffffff 64bit pref]
 
Besides my issues on my home lab with gpu passthrough issues, this 5.15.30 kernel has now caused 2 of 4 of our commercial hosting dual socket EPYC servers to crash and dump kernel stracktraces repeatedly and we are forced to downgrade to restore any kind of working hosting environment on these hosts. The remaining 2 had not been upgraded yet. 5.15 is simply not ready for prime time and needs to go back into the oven.
 
  • Like
Reactions: Lefuneste
WesC said:
Besides my issues on my home lab with gpu passthrough issues, this 5.15.30 kernel has now caused 2 of 4 of our commercial hosting dual socket EPYC servers to crash and dump kernel stracktraces repeatedly and we are forced to downgrade to restore any kind of working hosting environment on these hosts. The remaining 2 had not been upgraded yet. 5.15 is simply not ready for prime time and needs to go back into the oven.
Click to expand...
Our dual socket 2x EPYC 7351 and single socket EPYC 7302P work just fine here, and we got positive feedback for other EPYC models and generation, so there rather seems something else off in your setup. Is the bios/efi up do date? What vendor do you use there?
 
t.lamprecht said:
Our dual socket 2x EPYC 7351 and single socket EPYC 7302P work just fine here, and we got positive feedback for other EPYC models and generation, so there rather seems something else off in your setup. Is the bios/efi up do date? What vendor do you use there?
Click to expand...
Supermicro, 4 near-identical hosts though one was purchased much more recently. They should all be on latest bios or near to it, particularly the more recent purchase. Today was coincidentally my last day with this company though so don't have screenshots of the kernel stack trace on hand but I'm sure one of my colleagues will file a bug about it soon.
 
hawk said:
I don't know if this is a good place to continue this discussion, but as it seems most of the previous discussion of the issues relating to the efifb change is in this thread it might make sense to continue here even though the affected kernels are no longer opt-in.


Just ran into the 5.15 kernel resulting in no display issue after upgrading to a 7.1 system to 7.2:
pve-kernel-5.15.30-2-pve 5.15.30-3
pve-kernel-helper 7.2-2

This is on a machine with an Asrock Rack motherboard with ASPEED graphics.

It appears that "simplefb" is indeed loaded early on, as intended, but that does not result in any display output during early boot (initramfs etc)

[ 11.456186] simple-framebuffer simple-framebuffer.0: framebuffer at 0xfb000000, 0x1d5000 bytes
[ 11.456191] simple-framebuffer simple-framebuffer.0: format=a8r8g8b8, mode=800x600x32, linelength=3200
[ 11.456256] Console: switching to colour frame buffer device 100x37
[ 11.485771] simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!


However later in the boot process "ast" is loaded and display is restored (I assume that is what does it, anyway).

[ 30.872558] ast 0000:29:00.0: [drm] Using P2A bridge for configuration
[ 30.890569] ast 0000:29:00.0: [drm] AST 2500 detected
[ 30.908147] ast 0000:29:00.0: [drm] Analog VGA only
[ 30.925632] ast 0000:29:00.0: [drm] dram MCLK=800 Mhz type=7 bus_width=16
[ 30.943543] [drm] Initialized ast 0.1.0 20120228 for 0000:29:00.0 on minor 0

This is as it appears over IPMI/ipkvm, I have no idea what it looks like on the local console (that is rather pointless, anyway).
I do know, however, that with the 5.13 / efifb setup this problem did not occur.

I hope there is some way to get this sorted.
I suppose one could get ast (and I guess it's firmware?) into initramfs, but that seems a bit messy, and I assume the intention is that simplefb should be able to work anywhere?
Click to expand...

Just as a quick update, the problem remains unchanged with:
pve-kernel-5.15.35-1-pve 5.15.35-2
pve-kernel-helper 7.2-3

And for completeness I have also connected a monitor and verified that it looks the same there, not somehow limited to the display capture for the IPMI console.
("Same" being the "efi stub loaded initrd from command line option" message and then nothing more.)
 
I just wanted to add, like others, hawk and WesC, I am experiencing issues on kernel 5.15 while passing through a GTX 1070 (on amd x570/3700x) to a VM.
This works flawlessly on kernel 5.13, but breaks when I upgrade to kernel 5.15. I have tried messing with simplefb:off but that still is not working either.

Is there any solution to this? I would like to update to kernel 5.15 but am currently unable to.
 
It is a little bit of a hack, but this post solved my issues. I haven't seen any other methods that worked for me, seems to be a little bit of a dead end for now.
 
t.lamprecht said:
What vendor do you use there?
Click to expand...
WesC said:
Supermicro,
Click to expand...
Same here. I just upgraded to 7.2-3 and GPU passthrough started to cause problems.
Mainboard is a Supermicro H12SSL-i and CPU is Epyc 7282.

I'd blame the BIOS. Despite all setting the kernel always picks the add-on GPU a RX6700XT as Bios output. The previous kernel did that as well, but it somehow managed to stop using it, and allowing the passthrough. Generally PCIe stuff on servers seem to be very "flacky", compared to consumer MB. Where flacky probably mean that this use case is much less tested.
 
After upgrading the kernel from version 5.13.19-6 to 5.15.30-2 or 5.15.35-1, there was a problem on several identical Dell T140 computers with PERC H330 controller (megaraid_sas module).
Message appears:
DMAR: DRHD: handling fault status reg3
DMAR: [DMA Read NO_PASID] requests device [01: 00.0] fault addr 0x3831f000 [fault reason 0x06] PTE Read access is not set
megaraid_sas 0000: 01: 00.0: init cmd return status FAILED for SCSI host 0
Cannot process volume group pve
Volume group 'pve "not fount
(initramfs)

The system is not using UEFI and the disks are not configured as RAID
I temporarily resolved the problem as follows
I connected to the iDRAC virtual console, booted from kernel 5.13.19-6, used proxmox-boot-tool and pinned kernel 5.13.19-6 with which everything works fine.
 
pablo70 said:
After upgrading the kernel from version 5.13.19-6 to 5.15.30-2 or 5.15.35-1, there was a problem on several identical Dell T140 computers with PERC H330 controller (megaraid_sas module).
Message appears:
DMAR: DRHD: handling fault status reg3
DMAR: [DMA Read NO_PASID] requests device [01: 00.0] fault addr 0x3831f000 [fault reason 0x06] PTE Read access is not set
megaraid_sas 0000: 01: 00.0: init cmd return status FAILED for SCSI host 0
Cannot process volume group pve
Volume group 'pve "not fount
(initramfs)

The system is not using UEFI and the disks are not configured as RAID
I temporarily resolved the problem as follows
I connected to the iDRAC virtual console, booted from kernel 5.13.19-6, used proxmox-boot-tool and pinned kernel 5.13.19-6 with which everything works fine.
Click to expand...
I’ve been having issues since 5.15. I have a Dell R720 with SAS drives and a flashed PERC H710P for IT mode (ZFS). I tried the latest kernel update yesterday, but same issue. Seems related to iSCSI. I see timeout errors in my VM’s, and less activity on my SAS drives. I downgraded to 5.13.19-6, and everything works again.
 
Thomas Stone said:
Hello Tom. Thanks, I could try this shortly. Can you give me the brief instructions of how to download and install it, and then once that kernel is released as stable, how to ensure I'm back tracking stable kernel updates?
Click to expand...
1. Add the pvetest repository (can also be done through the GUI) as extra repo:
https://pve.proxmox.com/wiki/Package_Repositories#sysadmin_test_repo

2. Refresh the package index: apt update

3. Only pull in the new kernel package: apt install pve-kernel-5.15.35-1-pve

4. Remove, or disable the pvetest repository again.

FYI, for relatively easily booting an older kernel see:
https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#sysboot_kernel_pin
 
  • Like
Reactions: janssensm and Stoiko Ivanov
t.lamprecht said:
1. Add the pvetest repository (can also be done through the GUI) as extra repo:
https://pve.proxmox.com/wiki/Package_Repositories#sysadmin_test_repo

2. Refresh the package index: apt update

3. Only pull in the new kernel package: apt install pve-kernel-5.15.35-1-pve

4. Remove, or disable the pvetest repository again.

FYI, for relatively easily booting an older kernel see:
https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#sysboot_kernel_pin
Click to expand...

Thanks for the step-by-step!

So far, no change for me. Anyone kind enough to continue helping, perhaps we should take it to the thread I started about this NIC and Proxmox 7.2 over here: https://forum.proxmox.com/threads/7-2-update-aquantia-nic-not-working-anymore.109191/

I'll check the error messages I'm now receiving, if they have changed at all, and post over there!
 
hawk said:
I don't know if this is a good place to continue this discussion, but as it seems most of the previous discussion of the issues relating to the efifb change is in this thread it might make sense to continue here even though the affected kernels are no longer opt-in.


Just ran into the 5.15 kernel resulting in no display issue after upgrading to a 7.1 system to 7.2:
pve-kernel-5.15.30-2-pve 5.15.30-3
pve-kernel-helper 7.2-2

This is on a machine with an Asrock Rack motherboard with ASPEED graphics.

It appears that "simplefb" is indeed loaded early on, as intended, but that does not result in any display output during early boot (initramfs etc)

[ 11.456186] simple-framebuffer simple-framebuffer.0: framebuffer at 0xfb000000, 0x1d5000 bytes
[ 11.456191] simple-framebuffer simple-framebuffer.0: format=a8r8g8b8, mode=800x600x32, linelength=3200
[ 11.456256] Console: switching to colour frame buffer device 100x37
[ 11.485771] simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!


However later in the boot process "ast" is loaded and display is restored (I assume that is what does it, anyway).

[ 30.872558] ast 0000:29:00.0: [drm] Using P2A bridge for configuration
[ 30.890569] ast 0000:29:00.0: [drm] AST 2500 detected
[ 30.908147] ast 0000:29:00.0: [drm] Analog VGA only
[ 30.925632] ast 0000:29:00.0: [drm] dram MCLK=800 Mhz type=7 bus_width=16
[ 30.943543] [drm] Initialized ast 0.1.0 20120228 for 0000:29:00.0 on minor 0

This is as it appears over IPMI/ipkvm, I have no idea what it looks like on the local console (that is rather pointless, anyway).
I do know, however, that with the 5.13 / efifb setup this problem did not occur.

I hope there is some way to get this sorted.
I suppose one could get ast (and I guess it's firmware?) into initramfs, but that seems a bit messy, and I assume the intention is that simplefb should be able to work anywhere?
Click to expand...
hawk said:
Just as a quick update, the problem remains unchanged with:
pve-kernel-5.15.35-1-pve 5.15.35-2
pve-kernel-helper 7.2-3

And for completeness I have also connected a monitor and verified that it looks the same there, not somehow limited to the display capture for the IPMI console.
("Same" being the "efi stub loaded initrd from command line option" message and then nothing more.)
Click to expand...

For what it's worth, the problem remains with:
pve-kernel-5.15.35-1-pve 5.15.35-3
pve-kernel-helper 7.2-3


Is there a way to somehow revert to an efifb-based setup as that seemed to Just Work™, while I have no idea if there even is a way to make simplefb work?
Otherwise, what is a possible way forward?
 
Last edited:
  • Like
Reactions: marcosscriven
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom