Thread: Q: spinlock on Alpha? (PG7.0.2)

Q: spinlock on Alpha? (PG7.0.2)

From
"Emils Klotins"
Date:
RedHat Linux 6.2 on Alphaserver DS10 (egcs-1.1.2, glibc-2.1.3, 
libstdc++-2.9.0).
Postgresql-7.0.2 source

Compiles and installs just fine. However, both the regular initdb and 
parallel regression testing's initdb stage fails with a core file and 
message:

FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.


I fished around in the mailing lists and as I understand there has 
been some problems with spinlock on Alpha, which have been 
resolved? 

Any ideas what could I check/do about that greatly appreciated ( 
especially as I need to move the production server to alpha ASAP 
:(( )!

TIA, 
Emils



Re: Q: spinlock on Alpha? (PG7.0.2)

From
Tom Lane
Date:
"Emils Klotins" <emils@grafton.lv> writes:
> RedHat Linux 6.2 on Alphaserver DS10 (egcs-1.1.2, glibc-2.1.3, 
> libstdc++-2.9.0).
> Postgresql-7.0.2 source

> Compiles and installs just fine. However, both the regular initdb and 
> parallel regression testing's initdb stage fails with a core file and 
> message:

> FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
> FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.

I was just fooling with PG on a RedHat Alpha box that DEC kindly
loaned to the project.  It looks like the above problem is caused
by compiler optimization; although src/template/linux_alpha
optimistically sets CFLAGS=-O2, I had to back off to -O1 to avoid
that same spinlock complaint, and I couldn't get 7.0.* to pass
regression tests with anything but -O0.  (And even there, there
were a bunch of failures in the datetime-related tests; it looks
like our abstime datatype breaks rather badly on this platform.)

I haven't had time yet to try current sources on that box, but
I'm optimistic that the new function manager will solve a lot of
portability problems on Alphas.  Still, I don't understand why -O2
breaks spinlocks --- maybe egcs is misoptimizing around the inline
assembly code of tas() ?
        regards, tom lane


Re: Q: spinlock on Alpha? (PG7.0.2)

From
Fabrice Scemama
Date:
Try this:
http://www.rkirkpat.net/software/

Emils Klotins wrote:
> 
> RedHat Linux 6.2 on Alphaserver DS10 (egcs-1.1.2, glibc-2.1.3,
> libstdc++-2.9.0).
> Postgresql-7.0.2 source
> 
> Compiles and installs just fine. However, both the regular initdb and
> parallel regression testing's initdb stage fails with a core file and
> message:
> 
> FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
> FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
> 
> I fished around in the mailing lists and as I understand there has
> been some problems with spinlock on Alpha, which have been
> resolved?
> 
> Any ideas what could I check/do about that greatly appreciated (
> especially as I need to move the production server to alpha ASAP
> :(( )!
> 
> TIA,
> Emils


Re: Q: spinlock on Alpha? (PG7.0.2)

From
Ryan Kirkpatrick
Date:
On Mon, 2 Oct 2000, Tom Lane wrote:

> "Emils Klotins" <emils@grafton.lv> writes:
> > RedHat Linux 6.2 on Alphaserver DS10 (egcs-1.1.2, glibc-2.1.3,
> > libstdc++-2.9.0).
> > Postgresql-7.0.2 source
>
> > Compiles and installs just fine. However, both the regular initdb and
> > parallel regression testing's initdb stage fails with a core file and
> > message:
>
> > FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
> > FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
>
> I was just fooling with PG on a RedHat Alpha box that DEC kindly
> loaned to the project.  It looks like the above problem is caused
> by compiler optimization; although src/template/linux_alpha
> optimistically sets CFLAGS=-O2, I had to back off to -O1 to avoid
> that same spinlock complaint, and I couldn't get 7.0.* to pass
> regression tests with anything but -O0.  (And even there, there
> were a bunch of failures in the datetime-related tests; it looks
> like our abstime datatype breaks rather badly on this platform.)

    To get pgsql running correctly (spinlocks and regression tests) on
Linux/Alpha, one needs the patches off of my web site (as someone already
pointed out in another response to this thread). You can reduce the
optimization levels on the compiler and make some progress, but w/o the
patches, you get nowhere in the end.
    Also, some versions of egcs have been known to have problems on
Linux/Alpha, especially when it comes to optimization levels beyond the
default (none). I do know that gcc 2.95.2 (as distributed w/Debian 2.2)
works just fine with -O2. I seem to remember someone mentioning the
compiler with RedHat 6.2 does not work, and they had to upgrade to the
2.95.2 version before the optimization flags were safe.
    Of course, there is no release of RH7 for alpha yet (that I know
of), but on the Intel side there are some rumblings that RedHat used a
somewhat broken version of gcc. On top of that, I never quite figured out
the alignment between the egcs and the gcc version numbers (i.e. how does
egcs 1.1.2 relate to gcc 2.95.2?).
    I can tell you that with the patches on my web site and the gcc
2.95.2 compiler, everything works great with pgsql. Beyond that, I can not
promise you anything. If anyone wants to test on other compilers, I am
more than glad to help in anyway that I can. And if they report back to me
the results, I will add them to my web page.

> I haven't had time yet to try current sources on that box, but
> I'm optimistic that the new function manager will solve a lot of
> portability problems on Alphas.  Still, I don't understand why -O2
> breaks spinlocks --- maybe egcs is misoptimizing around the inline
> assembly code of tas() ?

    The last current sources I tested, about a month ago (8/15),
compiled w/o a single problem on my system (Debian 2.2, gcc 2.95.2), w/o
any patches and w/-O2. In other words, the need for special patches for
Linux/Alpha was removed, and now compiles out of the box. Once I get a bit
of time I plan to test more current snapshots, and will of course report
my results.
    And yes, the new function manager made about 90% of the 7.0.2
Linux/Alpha patches unneeded. The rest I '#ifdef {linux-alpha}'ed and
submitted a patch (quite short if I remember), which was accepted. Even
patched the regression tests results for geometry to match the Linux/Alpha
output (which actually matched a few other platforms as well). So now even
all regression tests as well. :)
    As for the spinlock, it is a compiler problem. At one time it had
non-local labels and therefore could not be inlined (i.e. multiple labels
w/the same name resulteD), but I fixed it by replacing all the labels with
local ones about a year or more ago. Compilers on Linux/Alpha have a
history of misbehaving when it came to the more aggressive optimization.
Only recently has most of the wrinkles been ironed out.
    That is my two cents, hope they are of use. TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------