-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Delete rw_semaphore.wait_lock configure check
Last use of wait_lock was removed in "Linux 5.3 compat: retire rw_tryupgrade()" (e7a99da). Fixes the issue reported in #11097 (comment) Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: Orivej Desh <[email protected]> Closes #11309
- Loading branch information
Showing
1 changed file
with
0 additions
and
28 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ab4fb9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I've validated that removal of those code blocks allows ZFS
2.0.0-1
to be used with RHEL 8.4's Real Time Kernel, version4.18.0-305.rt7.72.el8.x86_64
. Haven't tried with2.0.{1,2,3,4}
quite yet.Error Message
After grepping through the source and finding
config/kernel-rwsem.m4
, I commented out the same lines shown in this commit. Afterwards, returned to base dir and ran./autogen.sh
, initiated the build via DKMS from RPMs that I had compiled back when2.0.0.-1
was current, and it completed without errors. Pools are imported, things work, all is well.Prior to moving forward I wanted to check if this fix was included in an existing bug report or code commit, so searched for
openzfs rwsem_spinlock_is_raw
andopenzfs rhel realtime kernel
, finding two old SPL related PRs: openzfs/spl#622 , openzfs/spl@588d900 and finally this current commit. The original issue that reports the problem w/ real time kernel is for Arch and kernel 5.x, so someone may find this information useful when running RHEL 8.4 in current release enterprise context instead of Arch's rolling non-enterprise release method, different use cases etc.ab4fb9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@em-winterschon thanks for letting us know. For reference, this was addressed as of the 2.0.1 tag.