Project

General

Profile

Bug #8150

OmniOS kernel panic

Added by Dan Thomson over 2 years ago. Updated over 2 years ago.

Status:
New
Priority:
High
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2017-05-03
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

I had an OmniOS box kernel panic and I figured I'd submit a bug report about it.

Please let me know if this isn't the appropriate place to send this information, I'm just not sure of what a more appropriate location would be.

I'm not sure that there is very much in the way of specific information or events surrounding the actual panic itself, but I'll see if I can help by giving a rundown of the setup:

We have two OmniOS boxes acting as ZFS controllers for 4 ZFS pools. Each pool has 24 SAS drives. They're configured as 7 3-drive mirrors, all striped together and then one SSD for ZFS logs, one SSD for ZFS cache and one spare.
These boxes are running RSF-1 and acting as a cluster controlling those 4 pools. Thankfully the redundant server took over the crashed server's ZFS pools.

These ZFS pools are being served out over NFS and are used as shared storage for a VMWare setup. The load from this would've been relatively low as the VMs typically get used during the work day and the crash happened at 2:00am.

I'm attaching a crash.0 dump per https://wiki.illumos.org/display/illumos/How+To+Report+Problems

Please let me know if I can help provide more information.

Any help is greatly appreciated. I'm not knowledgeable enough to know if this a legitimate bug or a problem with my setup.


Files

1.txt (1.16 KB) 1.txt Dan Thomson, 2017-05-03 05:47 PM
2.txt (8.04 KB) 2.txt Dan Thomson, 2017-05-03 05:47 PM
3.txt (753 KB) 3.txt Dan Thomson, 2017-05-03 05:47 PM

History

#1

Updated by Dan McDonald over 2 years ago

1.) Which revision of OmniOS? ("uname -a", and possibly the contents of /etc/release).

2.) I don't see vmdump.0 crash.0, or any other attachment yet (may still be uploading to be fair).

#2

Updated by Igor Kozhukhov over 2 years ago

Dan McDonald wrote:

1.) Which revision of OmniOS? ("uname -a", and possibly the contents of /etc/release).

2.) I don't see vmdump.0 crash.0, or any other attachment yet (may still be uploading to be fair).

also panic info can be useful like this example:
https://dilos-dev.atlassian.net/wiki/display/DS/Parse+panic+dump

#3

Updated by Dan Thomson over 2 years ago

uname -a output: SunOS van-wf375-zfs-1a 5.11 omnios-f79e06d i86pc i386 i86pc

I thought I had uploaded the crash.0 (should've been quick). Let me try to attach it here again.

#4

Updated by Dan Thomson over 2 years ago

Trying to add attachments (this time including the 1.txt, 2.txt and 3.txt from https://dilos-dev.atlassian.net/wiki/display/DS/Parse+panic+dump) in another browser.

Also, the output of my /etc/release is:

OmniOS v11 r151018
Copyright 2016 OmniTI Computer Consulting, Inc. All rights reserved.
Use is subject to license terms.

... and actually I see a "Request Entity Too Large" for the crash.0. Is there somewhere else it can be uploaded, or would you be able to grab it if I made it available via HTTP somewhere?

#5

Updated by Dan McDonald over 2 years ago

You're running r151018, which was EOSL'ed over a month ago. You should've upgraded to r151020 already.

This panic doesn't look familar, but there are related ZFS fixes that went in after r151018. You really should upgrade to at least r151020, or wait another week or two until r151022 is released.

#6

Updated by Dan McDonald over 2 years ago

Issue #7086 mentions the function you have panicking, BTW.

#7

Updated by Dan Thomson over 2 years ago

Great! Thanks so much for your help!

I'd do the upgrade and follow up if I still see the issue crop up.

Also available in: Atom PDF