-
-
Notifications
You must be signed in to change notification settings - Fork 508
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
Port Sage to SUSE Linux Power 7 (ppc64). #11705
Comments
This comment has been minimized.
This comment has been minimized.
comment:2
I am actually in the process of commissioning such hardware and suse will be on some nodes (Aix 6.1 on the other nodes). |
This comment has been minimized.
This comment has been minimized.
comment:4
fbissey -- do you want an account on skynet, so you can help us with porting to SUSE on a nice new "IBM Power 750 Express server" that we have? |
comment:5
This is the computer we have access to: http://www-03.ibm.com/systems/power/hardware/750/index.html |
comment:7
We are getting 13 power755 locally but they'll go live at the end of September - I am currently installing a power720 that is meant to be a deployment server. Got a BlueGene/L and BlueGene/P as well but that would be another exercise :) The big pity as far as I am concerned is that there is no Gentoo-prefix for linux-ppc otherwise I could have been up and running faster. We currently have some power5 575 some of which are running suse 9 and that's awful, the latest gcc I have been able to compile is 4.2.4. |
comment:8
I notice in the build logs that you have gcc-4.6.1 on that box. Is it a manual install of gcc? |
comment:9
Replying to @kiwifb:
Yes. Here is some info about the machine. If you want an account on it, send me an email and I can arrange it.
|
comment:10
See http://www.math.utexas.edu/pipermail/maxima/2011/025874.html |
Changed keywords from none to sd32 |
comment:13
I was trying to find a way to run the install of maxima through gdb and I got this
I have created a spkg with the latest maxima in case that would make a difference but unsurprisingly it doesn't. |
comment:14
Benjamin posted a test log in #11708, let's analyse it:
Rather large numerical noise and some formatting noise which is more curious. There are multiples instances of these errors in that test:
Two potentially separate issues in mpfi and qqbar.py
picklejar failure should be checked against the same error on arm. Possibly a deeper python problem.
That's more than large numerical noise, that has to be wrong.
Some numerical noise but something else is badly wrong in the first one.
That one is not that worrying, I just wish we could easily deal with 0.0 sign flipping.
That looks bad we obviously have stuff wrong in scipy.
Something miscompiled in mpfr?
And we have a repeat of errors from qqbar.py in that test too.
more qqbar.py failuresalong with mpfr/mpfi like in elliptic_curves.rst and some wrong results:
again and again in that one
There are other errors in that last one but I think they are consequences of previous failures. Same error in
again some other errors that are probably consequences of this particular failure. We get some qqbar.py errors too in that one.
some more of the same with qqbar.py and mpfi/mpfr.
mpfr troubles with one backtrace
Also
sympow...
come from sympow So big trouble coming from mpfr or possibly mpir underneath. Once we isolate that most of these will disapear. |
comment:16
I was hoping the mpir upgrade would deal with some of these. |
comment:17
Replying to @jhpalmieri:
FWIW, I previously managed to reduce the doctest errors to 7 files IIRC; from sage-release (Sage 4.7.2.alpha3 thread):
I unfortunately cannot tell (at least at the moment) how I exactly built that version since I had trouble with various things like GCC 4.4.6 not recognizing |
This comment has been minimized.
This comment has been minimized.
comment:19
I have built 5.0.prealpha on one of the power7 box I have access too (not silius). I get the following after running the tests (not in parallel)
I cannot really post many details right now but the errors are similar to before. Problems with mpfr and scipy are the main culprits.
and the end of /proc/cpuinfo:
|
comment:20
I can supply gdb output for the test that got killed, "devel/sage/sage/rings/number_field/number_field.py":
I may try to upgrade mpfi/mpfr to see if it improve things. |
comment:21
I have updated mpfi and mpfr using #12171 and #11666 and now I am getting a backtrace going back to mpir:
|
comment:22
Just one more detail on the crash running the test with -verbose to get the failing bit:
So we are expecting to catch some failure here in the first place and it doesn't go according to plan. Also I forgot to mention I used the compiler fron SLES rather than compiling a newer version:
|
comment:23
I am doing a complete test run with the new mpfi/mpfr combo but so far the results don't look any different. I looked a little bit more into the test that timed out (devel/sage/sage/rings/real_mpfi.pyx) with verbose and it stops dead there:
I'll look at the other killed test (libecm.pyx) a bit later. |
comment:24
libecm.pyx doesn't seem to work at all
and from gdb
|
comment:25
ecm passed its test suite so it is quite strange. |
comment:26
Strangely enough I now get the following backtrace for real_mpfi.pyx, I have installed texlive in the mean time which may have made a difference.
I will move to 5.0.prealpha1 soon. |
comment:27
did someone try to compile MPFR 3.1.0 outside from Sage, and run its test suite (make check)? Paul Zimmermann |
comment:173
|
comment:175
5.12.beta1 on SLES11SP1 with gcc 4.8.1 and binutils 2.22. Still problems in functions/special.py - there is one more failure there. I also got two timeout but I haven't checked yet increasing the time limit. |
This comment has been minimized.
This comment has been minimized.
comment:176
On gcc110, no problems at all with current git develop (6.1.beta2) :) |
comment:177
I spoke too fast, it seems it was with 6.0. |
comment:178
I'm getting noisy, in fact it was the converse, the problem was with 6.0, not 6.1 betas. |
comment:179
I still got the failures in special.py on sles11sp1. I have another amusing one that I can produce at will:
For a little bit of background, I used a compute node to build/run the test suite. Which means that the testing was submitted as a batch job using loadleveler (a batch queue manager from IBM). loadleveler starts jobs without a tty which cause these errors. testing from the command line proper the failures just disappear. |
comment:180
Did someone try to build pillow (included in latest betas)? |
comment:181
Usually because you try to link a 64 bit object with a 32bit library. Yes it probably find the wrong version of one of the libraries (ziplib, png, jpeg) the setup script is not very smart but I thought we had ourselves covered. Would you by any chance have some of the aforementioned libraries installed in 32bit but not 64? |
comment:182
I'll have a look. |
comment:183
I have 6.1 beta3 built here with pillow and without a hitch. I honestly don't think it is a power7 issue per see. setup.py is not very smart at detecting stuff so you have to consider all corners. I have been in the latest gentoo bug concerning building pillow as well as the pillow ticket here. This stuff is fragile. |
comment:184
Ok, the problem is simply with liblcms install on gcc110. |
comment:185
That probably mean that there is a 64bit dev rpm not installed. But that's what I suspected. |
comment:187
So I finally pointed the finger to glibc/kernel headers. To build sage on SLES11SP1 and probably some other "enterprise distro" that are far behind in their toolchain stack on power7 I recommend IBM advance toolchain 7.0.3 and later. |
comment:188
It passes all long tests on a Red Hat Power 7 (gcc110) as well. |
comment:191
I still have no issue at all on a RedHad POWER7. |
Reviewer: Jean-Pierre Flori, François Bissey |
comment:192
Yes. |
Port Sage so that it builds and passes its full test suite on the new IBM Power 7 architecture running SUSE Linux.
This is the only test failure with sage-5.12.beta1:
Depends on #12829
Depends on #12832
Depends on #14098
Depends on #14151
CC: @nexttime @benjaminfjones @zimmermann6 @sagetrac-mariah @jpflori
Component: porting
Keywords: sd32 sd35.5
Author: Paul Zimmermann, Jeroen Demeyer
Reviewer: Jean-Pierre Flori, François Bissey
Issue created by migration from https://trac.sagemath.org/ticket/11705
The text was updated successfully, but these errors were encountered: