Thread: Solaris ASM problem
Kris Jurka wrote: > Bruce Momjian wrote: > > Log Message: > > ----------- > > Modify Solaris compiler build rules to use the cpp preprocessor, the the > > x86 file. > > > > Well it compiles now, but it doesn't seem to work: > > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=kudu&dt=2006-04-28%2016:30:01 > > selecting default max_connections ... Abort - core dumped > > creating template1 database in > /export/home/pgfarm/forte/HEAD/pgsql.5120/src/test/regress/./tmp_check/data/base/1 > ... PANIC: stuck spinlock (dd0000b0) detected at lwlock.c:358 OK, now that I have modified the build system to properly handle the preprocessing, it seems we have a problem with the ASM instructions. Theo? Comments? -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Fri, 28 Apr 2006, Theo Schlossnagle wrote: > What platform is that? (OS rev, architecture and word size)? I tested the > changes I submitted on Solaris 10 amd64. > $ uname -a SunOS albert 5.9 Generic_112234-03 i86pc i386 i86pc $ cc -V cc: Sun WorkShop 6 update 2 C 5.3 Patch 111680-09 2003/05/18 Kris Jurka
On Fri, 28 Apr 2006, Theo Schlossnagle wrote: > The file that uses the spinlocks: > /src/backend/storage/lmgr/s_lock.c > > can be compiled standalone with -DS_LOCK_TEST > To get the test to compile I had to link in tas.o as the attached patch shows. Unfortunately this doesn't work for platforms that don't have a tas.o, bailing out with file not found. Perhaps it's not important to fix this test, but I thought I'd mention it. Anyway the test exits with Stuck spinlock (80618e9) detected at ./s_lock.c:355. on a linux gcc build this exits with Stuck spinlock (0x5013ad) detected at ./s_lock.c:402. Kris Jurka
On Fri, 28 Apr 2006, Theo Schlossnagle wrote: > Kris Jurka wrote: > >> Anyway the test exits with >> Stuck spinlock (80618e9) detected at ./s_lock.c:355. >> >> on a linux gcc build this exits with >> Stuck spinlock (0x5013ad) detected at ./s_lock.c:402. > > This seems like a different problem, no? The patch I sent in didn't touch > any of the linux assembly bits. The linux test should pass to the end > without an issue right? > No, that's the desired ending. It prints: S_LOCK_TEST: this will print 1000 stars and then exit with a 'stuck spinlock' message if S_LOCK()and TAS() are working. The solaris version is just getting stuck before at another point before the expected stuck point. Kris Jurka
Theo Schlossnagle wrote:
> Kris Jurka wrote:
>
> >
> >
> > On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
> >
> >> Kris Jurka wrote:
> >>
> >>> Anyway the test exits with
> >>> Stuck spinlock (80618e9) detected at ./s_lock.c:355.
> >>>
> >>> on a linux gcc build this exits with
> >>> Stuck spinlock (0x5013ad) detected at ./s_lock.c:402.
> >>
> >>
> >> This seems like a different problem, no? The patch I sent in didn't
> >> touch any of the linux assembly bits. The linux test should pass to
> >> the end without an issue right?
> >>
> >
> > No, that's the desired ending. It prints:
> >
> > S_LOCK_TEST: this will print 1000 stars and then
> > exit with a 'stuck spinlock' message
> > if S_LOCK() and TAS() are working.
> >
> > The solaris version is just getting stuck before at another point before
> > the expected stuck point.
>
> I downloaded and tested this on my box. The first thing I noticed is
> that when compiling tas.s on Solaris 10 the -P flag was omitted (which
> is needed to have the #ifdef's process correctly). I did an: as -P
> tas.s by hand and then was able to repeat your problem.
You should see in backend/port/Makfile:
$(CC) $(CFLAGS) -c -P $<
Perhaps you didn't get that version yet.
> Looks like part of my patch wasn't applied (or I neglected to send it
> all). The cas operations are all word operations so the slock_t _MUST_
> be changed to a word.
Sorry, yes, that is my fault. I had to modify the macro test you
defined from __amd64 to __x86_64__, and didn't see the change in the
typedef. Fix applied.
---------------------------------------------------------------------------
>
> In src/include/storage/s_lock.h in the sun section, the slock_t must be
> an unsigned int:
>
> ; cvs diff -u src/include/storage/s_lock.h
> Index: src/include/storage/s_lock.h
> ===================================================================
> RCS file: /projects/cvsroot/pgsql/src/include/storage/s_lock.h,v
> retrieving revision 1.151
> diff -u -r1.151 s_lock.h
> --- src/include/storage/s_lock.h 28 Apr 2006 03:43:19 -0000
> 1.151
> +++ src/include/storage/s_lock.h 29 Apr 2006 02:48:45 -0000
> @@ -765,7 +765,7 @@
>
> #if defined(__sun) && (defined(__i386) || defined(__x86_64__) ||
> defined(__sparc__) || defined(__sparc))
> #define HAS_TEST_AND_SET
> -typedef unsigned char slock_t;
> +typedef unsigned int slock_t;
>
> extern slock_t pg_atomic_cas(volatile slock_t *lock, slock_t with,
>
> slock_t cmp);
>
>
-- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: >Kris Jurka wrote: > > >>Bruce Momjian wrote: >> >> >>>Log Message: >>>----------- >>>Modify Solaris compiler build rules to use the cpp preprocessor, the the >>>x86 file. >>> >>> >>> >>Well it compiles now, but it doesn't seem to work: >> >>http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=kudu&dt=2006-04-28%2016:30:01 >> >>selecting default max_connections ... Abort - core dumped >> >>creating template1 database in >>/export/home/pgfarm/forte/HEAD/pgsql.5120/src/test/regress/./tmp_check/data/base/1 >>... PANIC: stuck spinlock (dd0000b0) detected at lwlock.c:358 >> >> > >OK, now that I have modified the build system to properly handle the >preprocessing, it seems we have a problem with the ASM instructions. > >Theo? Comments? > > What platform is that? (OS rev, architecture and word size)? I tested the changes I submitted on Solaris 10 amd64. -- // Theo Schlossnagle // Principal Engineer -- http://www.omniti.com/~jesus/ // Ecelerity: Run with it. -- http://www.omniti.com/
Kris Jurka wrote: > > > On Fri, 28 Apr 2006, Theo Schlossnagle wrote: > >> Kris Jurka wrote: >> >>> Anyway the test exits with >>> Stuck spinlock (80618e9) detected at ./s_lock.c:355. >>> >>> on a linux gcc build this exits with >>> Stuck spinlock (0x5013ad) detected at ./s_lock.c:402. >> >> >> This seems like a different problem, no? The patch I sent in didn't >> touch any of the linux assembly bits. The linux test should pass to >> the end without an issue right? >> > > No, that's the desired ending. It prints: > > S_LOCK_TEST: this will print 1000 stars and then > exit with a 'stuck spinlock' message > if S_LOCK() and TAS() are working. > > The solaris version is just getting stuck before at another point before > the expected stuck point. My workstation is running 32bit solaris.. I can build and debug it here... I'll give that a spin (hehe). -- // Theo Schlossnagle // Principal Engineer -- http://www.omniti.com/~jesus/ // Ecelerity: Run with it. -- http://www.omniti.com/
Kris Jurka wrote: > > > On Fri, 28 Apr 2006, Theo Schlossnagle wrote: > >> What platform is that? (OS rev, architecture and word size)? I >> tested the changes I submitted on Solaris 10 amd64. >> > > $ uname -a > SunOS albert 5.9 Generic_112234-03 i86pc i386 i86pc > $ cc -V > cc: Sun WorkShop 6 update 2 C 5.3 Patch 111680-09 2003/05/18 > > Kris Jurka The file that uses the spinlocks: /src/backend/storage/lmgr/s_lock.c can be compiled standalone with -DS_LOCK_TEST Can you compile that and run the test. I'd be happy to troubleshoot it hands-on, but I don't have access to that box. Best regards, Theo -- // Theo Schlossnagle // Principal Engineer -- http://www.omniti.com/~jesus/ // Ecelerity: Run with it. -- http://www.omniti.com/
Kris Jurka wrote: > > > On Fri, 28 Apr 2006, Theo Schlossnagle wrote: > >> The file that uses the spinlocks: >> /src/backend/storage/lmgr/s_lock.c >> >> can be compiled standalone with -DS_LOCK_TEST >> > > To get the test to compile I had to link in tas.o as the attached > patch shows. Unfortunately this doesn't work for platforms that don't > have a tas.o, bailing out with file not found. Perhaps it's not > important to fix this test, but I thought I'd mention it. > > Anyway the test exits with > > Stuck spinlock (80618e9) detected at ./s_lock.c:355. > > on a linux gcc build this exits with > > Stuck spinlock (0x5013ad) detected at ./s_lock.c:402. This seems like a different problem, no? The patch I sent in didn't touch any of the linux assembly bits. The linux test should pass to the end without an issue right? -- // Theo Schlossnagle // Principal Engineer -- http://www.omniti.com/~jesus/ // Ecelerity: Run with it. -- http://www.omniti.com/