Crash on heavy iSCSI...assume same as post 39433

[dansthunder]

I have a FreeNAS server in production using iSCSI mounts, that's been running on FreeNAS-9.3-STABLE-201509282017. The FreeNAS server as of late November has been randomly rebooting itself. Nothing shows in dmesg or /var/log/messages. It has 3 ESXi v6 hosts attached to it, and it's running on a supermicro single Xeon cpu MB, w/32G, and 10 1TB SSDs as its array, thru an LSI card in jbod mode.

While the server was on the bench and hooked to inet, I always let it update itself. Now that it's behind a vlan, in prod, it can't reach out to grab updates.

The MB only has 1gig nics on it, we've spun up a DB vm over the iscsi. It's a slave, chews for some time and all is well -- usually. IO can reach 600-800mbits for 8-10 hours. We've crashed/rebooted now 6 times since September. It appears to be exactly like: https://forums.freenas.org/index.php?threads/spontaneous-system-crashes-with-iscsi-luns.39433/

I'm in process of migrating all VMs to local storage, and off of iSCSI before messing any further with the FreeNAS box. I haven't attempted a GUI update, and I don't want to risk live VMs if it fails.

All info.xxx are exaxtly the same. invalid serialization.

Dump header from device /dev/dumpdev
Architecture: amd64
Architecture Version: 1
Dump Length: 122368B (0 MB)
Blocksize: 512
Dumptime: Fri Feb 26 11:39:34 2016
Hostname: freenas.local
Magic: FreeBSD Text Dump
Version String: FreeBSD 9.3-RELEASE-p26 #0 r281084+93c5885: Mon Sep 28 13:25:20 PDT 2015
root@build3.ixsystems.com:/tank/home/stable-builds/FN/objs/os-base/amd64/tank/home/stable-builds/FN/FreeBSD/src/sysinvalid seria
lization value -2126892144 Panic String: invalid serialization value -2126892144
Dump Parity: 1016976703
Bounds: 0
Dump Status: good

Am I on the right track by updating to the latest, and assuming that should fix this invalid serialization issue? Just upload the latest stable 9.3 and let it update?

Thanks in advance!

 

[jgreco]

Yes, try updating to a more recent FreeNAS version. There was an issue around that timeframe that has been since corrected. I don't have a link offhand but you should be easily able to find further discussion of this.