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
[0.8.2] General protection fault in user access. Non-canonical address? #9417
Comments
|
Getting something similar here on Arch Linux, kernel-5.3.4, zfs-0.8.2. Happens on every boot: |
|
This blows up trying to dereference RDI, which indeed points somewhere into invalid address space on a x64 arch. |
|
I'm also reproducing this every boot. This started only (and immediately) after I upgraded firmware on my X470 Taichi Ultimate (with Ryzen 7 3700X) from P3.2 to P3.4 (addressing an issue unrelated to ZFS). Can anyone comment if this is safe to use? |
|
I'm getting a similiar errormessage on an X270 I also have issues with my system rebooting insead of resuming after suspending after an update might this be related? journalctl -b: |
|
I have the same issue.
Although my data looks fine. |
|
More info: The GPF problem from 0.8.2-1 never occurred on my home server (at least for last 5 reboots), which is a dual E5-2648L v2 machine with kernel 5.2.11. Edit: The mobo is Supermicro X9DRI-F with latest BIOS. |
|
@ReimuNotMoe What CPU/motherboard/firmware revision do you have? I didn't start experiencing this until I did a firmware upgrade. |
It's a less-known Chinese brand laptop with AMI BIOS & Intel i7 9750H CPU / Cannon Lake PCH. The BIOS says version Edit:
|
|
You should be able to avoid this issue by setting the If you need to set a custom scheduler you'll want to do so via the standard |
|
So here are the configurations I've tested so far:
All machines have latest BIOS & microcode, and have all CPU bug (meltdown, etc) mitigations disabled. |
|
Thanks for the additional information. I should have included a little more information in my previous comment. This issue was introduced by PR #9321 which resolved a deadlock which could occur when scrubbing root pools. The original fix for this was to remove the PR #9422 contains a fix for this as long as you're not using a root pool. Setting the module option |
|
Also hit this on fresh boot: |
As described in commit f81d5ef the zfs_vdev_elevator module option is being removed. Users who require this functionality should update their systems to set the disk scheduler using a udev rule. Reviewed-by: Richard Laager <rlaager@wiktel.com> Reviewed-by: loli10K <ezomori.nozomu@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#8664 Closes openzfs#9417 Closes openzfs#9609
As described in commit f81d5ef the zfs_vdev_elevator module option is being removed. Users who require this functionality should update their systems to set the disk scheduler using a udev rule. Reviewed-by: Richard Laager <rlaager@wiktel.com> Reviewed-by: loli10K <ezomori.nozomu@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#8664 Closes openzfs#9417 Closes openzfs#9609
As described in commit f81d5ef the zfs_vdev_elevator module option is being removed. Users who require this functionality should update their systems to set the disk scheduler using a udev rule. Reviewed-by: Richard Laager <rlaager@wiktel.com> Reviewed-by: loli10K <ezomori.nozomu@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #8664 Closes #9417 Closes #9609
System information
Describe the problem you're observing
After updating to 0.8.2 I onlined a drive and got the following kernel BUG.
Resilver completed and everything works as expected, system looks stable.
Describe how to reproduce the problem
Unable to reproduce.
Include any warning/errors/backtraces from the system logs
The text was updated successfully, but these errors were encountered: