ppc64le - GU_PAGE_SIZE(4096) does not maptch real system page size(65536)

Bug #1606102 reported by Edwin Wang
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
galera-3 (Ubuntu)
Fix Released
Undecided
Unassigned
percona-galera-3 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04 LTS
Release: 16.04
Codename: xenial
# version
galera-3 (25.3.14-1 version, ppc64el)
# Expected
Work smoothly.
# Happened
150302 10:23:26 [ERROR] WSREP: galerautils/src/gu_init.c:gu_init():20: GU_PAGE_SIZE(4096) does not maptch real system page size(65536)
Reported: https://jira.mariadb.org/browse/MDEV-7654
Fixed: https://github.com/MariaDB/galera/commit/0e815d9f12af74e3e94bcb39a913d26bdfd946b8

The issue has been fixed in latest mariadb/galera release.

Tags: oil
Revision history for this message
huhaoran (vennie1988) wrote :

I am facing the same issue, please patch the code fix to solve this defect. Thanks.
https://github.com/MariaDB/galera/commit/0e815d9f12af74e3e94bcb39a913d26bdfd946b8

huhaoran (vennie1988)
Changed in galera-3 (Ubuntu):
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in percona-galera-3 (Ubuntu):
status: New → Confirmed
tags: added: oil
Revision history for this message
Robie Basak (racb) wrote :

It looks to me like the version of galera-3 in Xenial, Zesty and Debian sid has architecture-specific code/configure paths and has never supported ppc64le. Is this correct?

The upstream patch does not apply cleanly - neither to sid nor to Xenial (but differently). So we don't have a fix available right now.

The conflict in sid looks like it'll take more rework. The conflict in Xenial is simpler, which seems odd. It may be that the automatic conflict resolution is not sufficient and it will be more involved to fix properly.

Revision history for this message
Robie Basak (racb) wrote :

Additionally galera-3 is FTBFS on armhf in zesty-proposed right now, so it's an additional pain to resolve to get this fixed in Zesty.

Revision history for this message
Robie Basak (racb) wrote :

Has this package ever worked on ppc64le, or is this an enablement request rather than a defect?

Revision history for this message
Jason Hobbs (jason-hobbs) wrote :

I think it's always been broken for us in OIL, I don't know if it ever worked on ppc64le.

Revision history for this message
Robie Basak (racb) wrote :

I have done a preliminary backport. Please can you test on ppc64el to see if this fixes the problem? My backport is at ppa:racb/experimental.

Note that armhf FTBFS for some reason, so this will need further investigation since it did work in Xenial previously. It's not clear to me from the build log whether this is something I introduced in my backport, or there is some other reason for the failure.

Also, I haven't looked at addressed the situation in Zesty at all, and this will need resolving before any SRU.

Backport notes:

There are two upstream branches: codership's 3.x and mariadb-3.x.
mariadb-3.x regularly merges in codership's 3.x branch. This merging
happens in only one direction; effectively codership's branch is
mariadb-3.x's upstream. mariadb-3.x's branch is what is packaged in this
source.

Two relevant commits are 0e815d9 and 22c4a52. 0e815d9 adds ppc64el
support, only exists in the mariadb-3.x branch, and is what is
backported here. 22c4a52 adds s390x support and exists in both branches.
The changes introduced by the two commits first appear together in
6896615.

Cherry-picking 0e815d9 on its own results in a merge conflict because of
the changes introduced by 22c4a52. Since this conflict was already
resolved by mariadb-3.x upstream in 6896615, this backport resolves the
conflict in exactly the same way.

Revision history for this message
Larry Michel (lmic) wrote :

I tried to test but percona-galera-3 is what actually gets installed in our deployment. We'd need this package built as well in order to be able to verify the fix.

Will it be possible to have that built as well please?

Revision history for this message
Robie Basak (racb) wrote :

@Larry,

I've patched and built percona-galera-3 in my PPA now too. Please try this. Note that I'm still just throwing patches at it to see what sticks. If it works, then I'll need to do it properly before we can land a fix in Ubuntu.

Revision history for this message
Mario Splivalo (mariosplivalo) wrote :

@robbie, this might be related:

https://bugs.launchpad.net/ubuntu/+source/percona-xtradb-cluster-5.5/+bug/1657256

I have run an hour-long sysbench oltp test against percona built form my ppa, and haven't had issues, nor ones that are mentioned in #1657256 or from this bug.

Revision history for this message
Mario Splivalo (mariosplivalo) wrote :

That is, Robie, not Robbie :)

Revision history for this message
Otto Kekäläinen (otto) wrote :

Tests are run as part of the build. In Debian galere-3 builds fine on ppc64el: https://buildd.debian.org/status/package.php?p=galera-3

Is this issue still valid?

Current galera-3 in Xenial is 25.3.14-1. Should we backport and upload the 25.3.22-1 from Debian Sid to Xenial?

Revision history for this message
Otto Kekäläinen (otto) wrote :

There are no reports that this would affect galera-3 anymore, so marking it solved now.

Changed in galera-3 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.