Problem with firmware FC adapter Emulex LightPulse LPe31002-M6-D

There is a server and a storage system that are connected directly (without an FC switch) via an FC adapter
LUNs are configured on the storage system and presented in the FC network.
Problem: visibility of LUNs from the server is possible only with ESXi 6.7.0
Any other versions of ESXi, as well as any distributions and versions of Linux do not see published LUNs of the storage system.

The problem was partially solved by updating the firmware of the FC adapter on the server... via manual from LPe32002 FC Host Bus Adapter

However, after rebooting the server, the problem returned: LUNs from the storage system are again not available for viewing...
That is, the firmware version was not updated after rebooting the server and returned to the previous one! (((
How to update the firmware correctly so that the changes take effect after rebooting??!

I would agree that the likely cause of your problems is the Emulex (Dell) HBA firmware and/or the driver used for the Emulex within ESXi.

So upgrading the HBA firmware (for which the compatibility issues especially with ESXi are well known) is, at least, the initial way to go.

It is also not unknown for such a firmware upgrade to fail to be persistent.

https://www.google.com/search?q=Emulex+LPe31002+firmware+upgrade+not+persistent

I think that you're on the right track.

P.S. If you have another machine that will take that Emulex you could use that, and a completely different O/S, just to get the firmware upgrade onto the HBA

Indeed, this problem occurs not only for me..
In my case, the problem is solved after sending the reset command to the FC adapter according to the vendor's recommendations (п.4.3.1.2 Resetting an Adapter)
oslpcfg reset n=all
and restarting the kernel module lpfc.ko
I tried to insert the line calling the reset command of the FC adapter into the source code of the kernel module, but the compilation failed with an error..
I'm sure it's due to an incorrect system call.

Help me how to make a system call from the core module of the FC adapter reset command?..

I ask for help in assembling a kernel module.. please... :sob:

Seems like a bad idea. In the kernel you should do everything witin the kernel.

I think so too, but I don't see any other options to disenchant this controller... ((((

Get the source code of the oslpcfg
Or run
strace -f oslpcfg ...
and see what it does.

This is a good idea, but it can only help me understand why scsi bus rescanning does not work

on the operating system

/usr/bin/rescan-scsi-bus.sh
echo "- - -" > /sys/class/scsi_host/host0/scan

In addition, the result may not be obvious.

I wanted to solve the problem in a "simpler way" by running

this command

oslpcfg reset n=all

from the kernel module with a "guaranteed successful result"...