Bug 459436
Summary: | ext4 assembly bitops failures on s390 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Eric Sandeen <esandeen> |
Component: | kernel | Assignee: | Eric Sandeen <esandeen> |
Status: | CLOSED ERRATA | QA Contact: | Martin Jenner <mjenner> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 5.3 | CC: | dzickus, hpicht, jglauber, lwang, mgahagan |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-01-20 20:10:49 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 447797 |
Description
Eric Sandeen
2008-08-18 20:41:39 UTC
Eric, the first version of ext4 that compiled on s390 after we had the bitops support implemented should have been working. Maybe you could try that and do a bisect search for the change that broke ext4? Jan, which version was that, out of curiosity? FWIW, this sort of change: Index: linux-2.6/arch/s390/include/asm/bitops.h =================================================================== --- linux-2.6.orig/arch/s390/include/asm/bitops.h 2008-08-11 16:23:58.000000000 -0500 +++ linux-2.6/arch/s390/include/asm/bitops.h 2008-08-20 22:43:55.516165589 -0500 @@ -865,7 +865,7 @@ static inline int ext2_find_next_bit(voi * s390 version of ffz returns __BITOPS_WORDSIZE * if no zero bit is present in the word. */ - set = ffs(__load_ulong_le(p, 0) >> bit) + bit; + set = __ffs(__load_ulong_le(p, 0) >> bit) + bit; if (set >= size) return size + offset; if (set < __BITOPS_WORDSIZE) at least gets the "copy /lib/modules to an ext4 filesystem" test working; however, when I run fsstress I'm running into other trouble. The above changes the semantics of counting bits from starting at 1 to starting at 0; IOW, for a bitmap of all 1's, the original code did this: find next set bit starting at 0: 0 find next set bit starting at 1: 2 with the change, it's (properly, I think): find next set bit starting at 0: 0 find next set bit starting at 1: 1 -Eric Ok, posted that a bit too soon. I think this gets it going: Index: linux-2.6/arch/s390/include/asm/bitops.h =================================================================== --- linux-2.6.orig/arch/s390/include/asm/bitops.h 2008-08-11 16:23:58.000000000 -0500 +++ linux-2.6/arch/s390/include/asm/bitops.h 2008-08-21 00:49:40.950176518 -0500 @@ -862,10 +862,10 @@ static inline int ext2_find_next_bit(voi p = addr + offset / __BITOPS_WORDSIZE; if (bit) { /* - * s390 version of ffz returns __BITOPS_WORDSIZE - * if no zero bit is present in the word. + * s390 version of ffs returns __BITOPS_WORDSIZE + * if no set bit is present in the word. */ - set = ffs(__load_ulong_le(p, 0) >> bit) + bit; + set = __ffs(__load_ulong_le(p, 0) & (~0UL << bit)); if (set >= size) return size + offset; if (set < __BITOPS_WORDSIZE) -Eric Committed upstream: http://git390.osdl.marist.edu/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=commitdiff;h=152382af4056aadc0c2ea2e8e8258b277be085bf Patch is in Linus' git tree now. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=152382af4056aadc0c2ea2e8e8258b277be085bf in kernel-2.6.18-110.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-0225.html |