HP DL 380 Gen 9 issues on 5.4.73 & 5.4.78 kernel
- Thread starter adamb
- Start date
If 5.4.65 is your 2nd kernel you would do the following.
vi /etc/default/grub
Change the following line from
GRUB_DEFAULT=0
to
GRUB_DEFAULT="1>1"
Now run "update-grub" then "update-initramfs -u"
Reboot and you should be good to go.
OK, thanks to both of you for your feedback.
FYI: Our gen8 works fine with 5.4.73, which is actually rather bad for us, as having a reliable reproducer here would help a lot.
FYI: Our gen8 works fine with 5.4.73, which is actually rather bad for us, as having a reliable reproducer here would help a lot.
I have done a bit more digging.
If I blacklist the be2iscsi module my issues are resolved. So far working on all the Gen9's I have updated.
Yes, the oops happens when be2iscsi is loaded, and as no other issue happens then I'd guess it's either a missing adaption to some changes to the scheduler workqueue (they had a few such fixups in the git tree) or the single patch that happened in the be2iscsi module:
That's the sole change in that whole module folder since 5.4.65 - if you could test a kernel with that reverted I can build one, it's a too cheap shot to not try first, IMO.
Git:
commit 552b270b5784dc322807df89eb359e74fc570fde
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Sep 28 12:13:00 2020 +0300
scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()
BugLink: https://bugs.launchpad.net/bugs/1902115
[ Upstream commit 38b2db564d9ab7797192ef15d7aade30633ceeae ]
The be_fill_queue() function can only fail when "eq_vaddress" is NULL and
since it's non-NULL here that means the function call can't fail. But
imagine if it could, then in that situation we would want to store the
"paddr" so that dma memory can be released.
Link: https://lore.kernel.org/r/20200928091300.GD377727@mwanda
Fixes: bfead3b2cb46 ("[SCSI] be2iscsi: Adding msix and mcc_rings V3")That's the sole change in that whole module folder since 5.4.65 - if you could test a kernel with that reverted I can build one, it's a too cheap shot to not try first, IMO.
Last edited:
FYI: http://download.proxmox.com/temp/testkernel-hp-gen9-be2scsi-oops/ (it's the same as 5.4.78 but a revert of the commit mentioned in the previous reply)
Code:
sha256sum *
47f9a85ab5517a7e3ec2c1514428c87a2b25eee5f7951af557261a96440e836f linux-tools-5.4_5.4.78-1~b1_amd64.deb
d4f1eb68d4c15ce0ba24c1290a9e1528fa17b142a827d9c7310bd481a43228dc linux-tools-5.4-dbgsym_5.4.78-1~b1_amd64.deb
c2032e2eb3d6fab4b207df922904afad52ad0f8ec89d8aace80980184647114a pve-headers-5.4.78-1-pve_5.4.78-1~b1_amd64.deb
289ee7218a8d7459966e78890be7dd7f7de77a257b26096864b25d3f67b1b920 pve-kernel-5.4.78-1-pve_5.4.78-1~b1_amd64.deb
f26a1b16205d9e093ecfb2968072672003127f36222411d1946df9a95306fcf5 pve-kernel-libc-dev_5.4.78-1~b1_amd64.deb
Thanks for testing it out and providing feedback! Then'll do a proper build and notify upstream, where applicable.
I had a similar issue on an HP Proliant BL465c G7 with Emulex10Gb UNDI card.
it was getting stuck at
scsi host5: BC_295 : MBX Cmd Completion timed out
Jan 13 16:24:41 ais-cloudhost1 kernel: [ 607.271584] INFO: task systemd-udevd:336 blocked for more than 241 seconds.
So i solved the issue by blacklisting the be2iscsi module that was causing the timeout.
you need to re run update-iniramfs -u after the blacklist, so its initrd is updated.
it was getting stuck at
scsi host5: BC_295 : MBX Cmd Completion timed out
Jan 13 16:24:41 ais-cloudhost1 kernel: [ 607.271584] INFO: task systemd-udevd:336 blocked for more than 241 seconds.
So i solved the issue by blacklisting the be2iscsi module that was causing the timeout.
you need to re run update-iniramfs -u after the blacklist, so its initrd is updated.
What do you mean?
We reverted the problematic patch which introduced this regression in our kernel package which then got released a bit later.
So yes, as with most package updates, compilation was involved.
I tried to install it last night on my HP BL460C G8 last night from the ISO off your site and it still gave me the same issue.
IIRC, the ISO was build with a kernel version that still has this problem, so you'd need to run a package update directly after installation (always a good idea).
If you have network available then follow the standard update procedure.
If not done, setup a Package Repository you have access to:
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_package_repositories
Then, you can do the update either again over CLI or the web-interface:
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_system_software_updates
If you do not have internet access then yes, you would download the kernel package update and install it manually.
(I can give directions about that if needed)
If not done, setup a Package Repository you have access to:
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_package_repositories
Then, you can do the update either again over CLI or the web-interface:
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_system_software_updates
If you do not have internet access then yes, you would download the kernel package update and install it manually.
(I can give directions about that if needed)
So let's go for manual installation then.
First prepare a USB pen drive or the like, then download the newest kernel, for example in any Linux/Unix like terminal with
wget available:
Bash:
wget http://download.proxmox.com/debian/pve/dists/buster/pve-no-subscription/binary-amd64/pve-kernel-5.4.78-2-pve_5.4.78-2_amd64.deb
# verify checksum
sha256sum pve-kernel-5.4.78-2-pve_5.4.78-2_amd64.deb
e1fc14521d5f3aeb1e631202bb11eb8c79b73580d6586a9f9be3bc38db5d2655 pve-kernel-5.4.78-2-pve_5.4.78-2_amd64.debCopy that .deb package file onto the USB pen drive, plug that into the server and mount it.
Then you can install it simply by doing
Bash:
cd /path/where/usb/is/mounted
apt install ./pve-kernel-5.4.78-2-pve_5.4.78-2_amd64.debSorry that it took so long to reply. I also did a Proxmox 6.3 upgrade on my HP BL460c G6 and it also made it the Proxmox website unreachable.