Обсуждение: beta 1 failed on linux mipsel

Поиск
Список
Период
Сортировка

beta 1 failed on linux mipsel

От
"Jim Buttafuoco"
Дата:
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



Re: beta 1 failed on linux mipsel

От
Tom Lane
Дата:
"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


Re: beta 1 failed on linux mipsel

От
"Jim Buttafuoco"
Дата:
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 -------



Re: beta 1 failed on linux mipsel

От
Tom Lane
Дата:
"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


Re: beta 1 failed on linux mipsel

От
"Jim Buttafuoco"
Дата:
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 -------



Re: beta 1 failed on linux mipsel

От
"Jim Buttafuoco"
Дата:
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 -------



Re: beta 1 failed on linux mipsel

От
Tom Lane
Дата:
"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


Re: beta 1 failed on linux mipsel

От
"Jim Buttafuoco"
Дата:
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 -------



Re: beta 1 failed on linux mipsel

От
"Jim Buttafuoco"
Дата:
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 -------