-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: unable to handle kernel paging request #6334
Comments
I can confirm this issue on CentOS 7 with Linux 3.10.0-514.26.2.el7.x86_64 and ZFS 0.7.1. I'd be happy to send a kernel crash dump to someone interested. In the interest of full disclosure, I am also running a proprietary FusionIO storage driver on an ioDrive Octal, but that does not seem to be causing any issues here—correct me if I'm wrong. This occurs when receiving a stream created by the same system from a different pool named the same as the pool I'm receiving to ("octal"). The crash is very reliable and almost immediate. I am receiving pretty fast, saturating gigabit ethernet from a stream saved on a different machine, although the same thing happens when I rate-limit it to 40MB/s. Here's my log:
Again, let me know if someone wants kdump files. |
I've hit this in 0.7.1 on It triggers consistently on receipt of a deduplicated compressed stream (from Unlike @thirtythreeforty, I'm sending and receiving on the same pool and am not using any unusual hardware or proprietary drivers. |
Additional info:
panic log from pstore
|
Getting a similar error: https://gist.github.com/chris13524/440fdcd810895cdfbc3ea233d43d3ce5 Seems to have been caused by a MariaDB Docker container hanging. (using the ZFS storage driver for Docker) Also now my system no longer sleeps. On Ubuntu 17.10. uname -a |
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
System information
Describe the problem you're observing
I'm observing the following stack trace on the receiving side of zfs send but this time receiving a regular dataset.
I don't know if this is related to #6330
Describe how to reproduce the problem
Setup a regular send to remote system (1/hour)
Include any warning/errors/backtraces from the system logs
The text was updated successfully, but these errors were encountered: