beta 1 failed on linux mipsel

Started by Jim Buttafuocoover 21 years ago9 messages
#1Jim Buttafuoco
jim@contactbda.com

trying to test beta 1 on Debian linux mipsel (sarge). I am getting the following error "PANIC: stuck spinlock
(0x2b052030) detected at lwlock.c:246" during initdb. here is the complete initdb run.

postgres@raq:~$ initdb
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /usr/local/pgsql/data ... ok
creating directory /usr/local/pgsql/data/global ... ok
creating directory /usr/local/pgsql/data/pg_xlog ... ok
creating directory /usr/local/pgsql/data/pg_xlog/archive_status ... ok
creating directory /usr/local/pgsql/data/pg_clog ... ok
creating directory /usr/local/pgsql/data/pg_subtrans ... ok
creating directory /usr/local/pgsql/data/base ... ok
creating directory /usr/local/pgsql/data/base/1 ... ok
creating directory /usr/local/pgsql/data/pg_tblspc ... ok
selecting default max_connections ... 10
selecting default shared_buffers ... 50
creating configuration files ... ok
creating template1 database in /usr/local/pgsql/data/base/1 ...

PANIC: stuck spinlock (0x2b052030) detected at lwlock.c:246
child process was terminated by signal 6
initdb: failed
initdb: removing data directory "/usr/local/pgsql/data"

let me know if this is a know issue and/or what other info you need.

Thanks
Jim

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jim Buttafuoco (#1)
Re: beta 1 failed on linux mipsel

"Jim Buttafuoco" <jim@contactbda.com> writes:

trying to test beta 1 on Debian linux mipsel (sarge).

What is that, a playstation 2? Last we heard, that chip had no spinlock
support. Did you use configure --disable-spinlocks?

regards, tom lane

#3Jim Buttafuoco
jim@contactbda.com
In reply to: Tom Lane (#2)
Re: beta 1 failed on linux mipsel

The system is a cobalt raq, I am also going to test on some decstations (also mipsel) and SGI (mips) systems.

I didn't use the disable-spinlock option. will try tomorrow. i did see some mips spinlock code in s_lock.c.
Shouldn't this also work on mipsel CPU's?

Jim

---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Sun, 29 Aug 2004 15:27:32 -0400
Subject: Re: [HACKERS] beta 1 failed on linux mipsel

"Jim Buttafuoco" <jim@contactbda.com> writes:

trying to test beta 1 on Debian linux mipsel (sarge).

What is that, a playstation 2? Last we heard, that chip had no spinlock
support. Did you use configure --disable-spinlocks?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

------- End of Original Message -------

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jim Buttafuoco (#3)
Re: beta 1 failed on linux mipsel

"Jim Buttafuoco" <jim@contactbda.com> writes:

Shouldn't this also work on mipsel CPU's?

It should work on a real MIPS CPU. The PlayStation 2 has a dumbed-down
MIPS chip without the TAS instruction :-(, but now that we've eliminated
that point I think you've found a problem. We made several
reorganizations in the spinlock code between 7.4 and 8.0 that could
possibly have broken the platforms we were not testing on --- can you
take a look at the changes in s_lock.h and s_lock.c and see where we
went wrong?

regards, tom lane

#5Jim Buttafuoco
jim@contactbda.com
In reply to: Tom Lane (#4)
Re: beta 1 failed on linux mipsel

ok, will look at it in the morning.

---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Sun, 29 Aug 2004 21:42:57 -0400
Subject: Re: [HACKERS] beta 1 failed on linux mipsel

"Jim Buttafuoco" <jim@contactbda.com> writes:

Shouldn't this also work on mipsel CPU's?

It should work on a real MIPS CPU. The PlayStation 2 has a dumbed-down
MIPS chip without the TAS instruction :-(, but now that we've eliminated
that point I think you've found a problem. We made several
reorganizations in the spinlock code between 7.4 and 8.0 that could
possibly have broken the platforms we were not testing on --- can you
take a look at the changes in s_lock.h and s_lock.c and see where we
went wrong?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

------- End of Original Message -------

#6Jim Buttafuoco
jim@contactbda.com
In reply to: Tom Lane (#4)
Re: beta 1 failed on linux mipsel

Tom,

I have confirmed that 7.4.3 works on the cobalt raq mipsel system. I have not looked at the s_lock.[ch] code as I
have not coded in C for years and don't know the backend code very well. Do you have any ideas?

Jim

---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Sun, 29 Aug 2004 21:42:57 -0400
Subject: Re: [HACKERS] beta 1 failed on linux mipsel

"Jim Buttafuoco" <jim@contactbda.com> writes:

Shouldn't this also work on mipsel CPU's?

It should work on a real MIPS CPU. The PlayStation 2 has a dumbed-down
MIPS chip without the TAS instruction :-(, but now that we've eliminated
that point I think you've found a problem. We made several
reorganizations in the spinlock code between 7.4 and 8.0 that could
possibly have broken the platforms we were not testing on --- can you
take a look at the changes in s_lock.h and s_lock.c and see where we
went wrong?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

------- End of Original Message -------

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jim Buttafuoco (#6)
Re: beta 1 failed on linux mipsel

"Jim Buttafuoco" <jim@contactbda.com> writes:

I have confirmed that 7.4.3 works on the cobalt raq mipsel system. I
have not looked at the s_lock.[ch] code as I have not coded in C for
years and don't know the backend code very well. Do you have any
ideas?

Do you want to give me or another pg-hacker a temporary account on your
machine?

regards, tom lane

#8Jim Buttafuoco
jim@contactbda.com
In reply to: Tom Lane (#7)
Re: beta 1 failed on linux mipsel

i will get ssh setup and let you know. Just a warning the system is "slow".

Also, Tom you email system is blocking my server (I do understand why), so I can't send the account info directly.

Jim

---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Mon, 30 Aug 2004 13:23:03 -0400
Subject: Re: [HACKERS] beta 1 failed on linux mipsel

"Jim Buttafuoco" <jim@contactbda.com> writes:

I have confirmed that 7.4.3 works on the cobalt raq mipsel system. I
have not looked at the s_lock.[ch] code as I have not coded in C for
years and don't know the backend code very well. Do you have any
ideas?

Do you want to give me or another pg-hacker a temporary account on your
machine?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

------- End of Original Message -------

#9Jim Buttafuoco
jim@contactbda.com
In reply to: Tom Lane (#7)
Re: beta 1 failed on linux mipsel

Tom,

Still having problems. This is the output of "make check". I am going to compile with debug symbols and try to
attach with gdb next. any other ideas?

Thanks
Jim

-------------------------------------------------------------------------------------------------

Running in noclean mode. Mistakes will not be cleaned up.
The files belonging to this database system will be owned by user "pgsql".
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data ... ok
creating directory /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data/global ... ok
creating directory /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data/pg_xlog ... ok
creating directory /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data/pg_xlog/archive_status ... ok
creating directory /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data/pg_clog ... ok
creating directory /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data/pg_subtrans ... ok
creating directory /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data/base ... ok
creating directory /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data/base/1 ... ok
creating directory /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data/pg_tblspc ... ok
selecting default max_connections ... 10
selecting default shared_buffers ... 50
creating configuration files ... ok
creating template1 database in /home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data/base/1 ... PANIC:
stuck spinlock (0x2b0
52030) detected at lwlock.c:246
child process was terminated by signal 6
initdb: failed
initdb: data directory "/home/pgsql/postgresql-8.0.0beta1/src/test/regress/./tmp_check/data" not removed at user's
request

---------- Original Message -----------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Mon, 30 Aug 2004 13:23:03 -0400
Subject: Re: [HACKERS] beta 1 failed on linux mipsel

"Jim Buttafuoco" <jim@contactbda.com> writes:

I have confirmed that 7.4.3 works on the cobalt raq mipsel system. I
have not looked at the s_lock.[ch] code as I have not coded in C for
years and don't know the backend code very well. Do you have any
ideas?

Do you want to give me or another pg-hacker a temporary account on your
machine?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

------- End of Original Message -------