On Tue, 2015-04-07 at 18:22 -0400, Dan Lane wrote:
The working system is running: Linux dracosan 3.5.0-26-generic
#42-Ubuntu SMP Fri Mar 8 23:18:20 UTC 2013 x86_64 x86_64 x86_64
GNU/Linux
With that said, the hardware is substantially different between the
two, in the working system I'm using a QLE2462 (I thought it was a
QLA2462 but I just confirmed it's not).
Working storage: Arima NM461 board, dual opteron 2214HE, 8x 1GB RAM,
QLE2462 HBA, LSI 8888ELP SAS RAID card, Kernel 3.5.0-26 (Ubuntu FUBAR)
To clarify, v3.5.x does not have support for VAAI primitives
(COMPARE_AND_WRITE + EXTENDED_COPY).
Support for these where added in v3.12 code.
Crashy storage #1: IBM HS21 (8853) blade, dual Xeon 5148, 4x 1GB
RAM,
2x QLA2462 HBA, 4x 1GB RAM, ServeRaid 8k SAS RAID card, IBM BSE3
expander, Kernel 3.19.3-200 (Fedora 21)
Crashy storage #2: IBM HS21 (8853) blade, dual Xeon 5148, 4x 1GB RAM,
1x QLA2462 HBA, 4x 1GB RAM, LSI 1064E SAS card, Kernel 4.0.0.rc2
(Fedora 22) (Server was built just for testing)
Please verify which FC initiator you're using on the ESX side as well.
So based on your original logs it's still unclear to me if it's a
regression specific to qla2xxx + COMPARE_AND_WRITE, or some other manner
of qla2xxx target regression, or a bug specific to 24xx hardware.
One thing you can try is setting emulate_caw=0 for each backend device
that is used by ESX. This will disable COMPARE_AND_WRITE, and force it
to use the pre-VAAI locking mechanisms. This would be helpful to
determine if it's really something specific to COMPARE_AND_WRITE +
qla2xxx.
Note that this will NOT work for existing VMFS volumes, as there is no
way to convert them from VAAI to pre-VAAI locking mechanisms.
I have a friend running a QLA2462 (PCI-X) in a PowerEdge 2850
successfully, he's going to check it later and see what kernel he's
on, all he could remember is that it's Ubuntu.
^^
Ok, I'm verifying v4.0 COMPARE_AND_WRITE + qla2xxx on 25xx based
hardware shortly.
Thanks for reporting.
--nab