Skip site navigation (1) Skip section navigation (2)

Re: PlayStation 2 problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PlayStation 2 problems
Date: 2003-11-02 23:25:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I've tried PG 7.4 on a PlayStation 2/Linux.  This is a kind of mips
> machine but apparently doesn't like the existing mips assembly code
> (illegal instruction errors).

Yes, that was known already --- apparently it uses a variant MIPS chip
with no spinlock instructions.  The note in the Supported Platforms list
describes what Permaine Cheung had to do to work around this in 7.3.
I'm not surprised that the details are a bit different in 7.4.

> I've also tried --disable-spinlocks to turn
> off the use of the assembly code, without success.

That is a deficiency of Bruce's --disable-spinlocks implementation that
I already knew about --- it should be possible to use the switch to
disable spinlocks on a platform that the code thinks has them, but it
isn't.  It looked not very practical to fix this until after the
spinlock code reorganization that Bruce is holding for 7.5, so I planned
to leave the issue alone until that patch is applied.

> The old report from 7.3 has the comment
> #undef HAS_TEST_AND_SET, remove slock_t typedef
> I've additionally had to disable the mips tas_dummy in s_lock.c.

Hmm, shouldn't much of that file be #ifdef HAS_TEST_AND_SET anyway?

> (How is this tas_dummy code reached anyway?)

Via the assembler label "tas:".  Not sure why these routines are coded
that way, but I'm disinclined to fool with them.

> Also, we need a newer version of config.guess to support this platform.

Yeah, I was thinking the other day that we should have updated
config.guess before starting the beta cycle.  At this point I feel it's
too late for 7.4 though --- inserting a new config.guess at this point
would risk invalidating existing port reports.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Christopher BrowneDate: 2003-11-03 00:15:07
Subject: Re: Experimental patch for inter-page delay in VACUUM
Previous:From: Tom LaneDate: 2003-11-02 23:06:45
Subject: Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group