Project

General

Profile

Bug #23199

vm_page kernel panics when rsyncing or copying

Added by Scott Finlon over 3 years ago. Updated about 3 years ago.

Status:
Closed: User Config Issue
Priority:
No priority
Assignee:
Alexander Motin
Category:
Middleware
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

I get kernel panics frequently. I've tried enabling autotune to no avail, and I've recently tried running the debug kernel to get better info.

They are almost all related to vm_page_xxxx

I did a full clean reinstall of 9.10 this afternoon, and I've had 3 panics already:
info.0: Panic String: vm_page_free: freeing busy page 0xfffff8080be06660
info.1: Panic String:
info.2: Panic String: vm_page_insert_after: page already inserted
info.last: Panic String: vm_page_insert_after: page already inserted

I've been able to trigger the panic by doing a rsync and also a cp -R on a ~260 GB of video files.

History

#1 Updated by Scott Finlon over 3 years ago

  • File debug-nas-20170407205001.txz added

#2 Updated by Sean Fagan over 3 years ago

Do you have ECC memory?

I'd try running a memory tester, e.g http://www.memtest86.com

#3 Updated by Scott Finlon over 3 years ago

It's non-ECC, it's an Asus Maximus V Formula consumer grade mother board, which isn't ECC compatible.
The Ram is G.SKILL Ripjaws Z Series 32GB (4 x 8GB) 240-Pin DDR3 SDRAM DDR3 1600.

I've had this machine for 5 years with no problems. I had FreeNAS in a smaller system, and moved my drives and installed in this one.

Running memtest86+ now, no errors yet, but I did realize that I recently updated my BIOS and it reset my settings including my RAM timings. That may have been part of the issue.
I've put in the correct timings, and the RAM is running at 1600 MHz instead of 1333, I will let it run overnight and update the status tomorrow.

#4 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

  • Status changed from Unscreened to 15
  • Target version set to N/A
  • Seen in changed from Unspecified to 9.10.2-U2

#5 Updated by Bonnie Follweiler over 3 years ago

  • Assignee set to Alexander Motin

#6 Updated by Alexander Motin over 3 years ago

I don't see any relation between four crash dumps in debug data you provided. I tend to agree with Sean that it can be a bad RAM or incorrect RAM timings. I just want to add that sometimes memory test had to run for few days straight to detect transient glitches.

#7 Updated by Scott Finlon over 3 years ago

Aye, sorry guys, one of my 8GB DIMMS was starting to flake out. I've isolated the memory errors, and removed it and its counterpart. Running on 16 GB RAM now, let's see if it's any more stable now.

#8 Updated by Alexander Motin over 3 years ago

  • Status changed from 15 to Closed: User Config Issue

Closing this for now.

#9 Updated by Dru Lavigne about 3 years ago

  • File deleted (debug-nas-20170407205001.txz)

#10 Updated by Dru Lavigne about 3 years ago

  • Private changed from Yes to No

Also available in: Atom PDF