Thread: Third call for platform testing
We've got most platforms ironed out, with just a few left to get a definitive report. It looks like we'll end up dropping a few platforms for this release (the first time in several years that the number of supported platforms decreased!). The problem platforms with comments and questions are: Linux/arm Mark Knox Obsolete platform? gcc no longer supported? Linux/s390 Neale Ferguson Likely small user base. Anyone actively running on S390? NetBSD/arm32 Patrick Welche NetBSD/m68k Bill Studenmund Bill, you thought you might get the old iron tested. Any luck? NetBSD/VAX Tom I. Helbekkmo Any VAXen out there nowadays? QNX Bernd Tegge, Igor Kovalenko Anyone tested 4.x with 7.2, or are we stuck with QNX6 needingpatches? SunOS Tatsuo Ishii Are we giving up on this one? Still relevant? Windows/Cygwin Daniel Horak OK in serial test, trouble with parallel test? Showstopper?? Windows/native Magnus Hagander (clients only) Any reports? And those reported as successful: AIX Andreas Zeugswetter (Tatsuo working on 5L?) BeOS Cyril Velter BSD/OS Bruce FreeBSD Chris Kings-Lynne HPUX Tom (anyone tested 11.0 or higher?) IRIX Luis Amigo Linux/Alpha Tom Linux/MIPS Hisao Shibuya Linux/PPC Tom Linux/sparc Doug McNaught Linux/x86 Thomas (and many others ;) MacOS-X Gavin Sherry NetBSD/Alpha Thomas Thai NetBSD/PPC Bill Studenmund NetBSD/sparc Matthew Green NetBSD/x86 Bill Studenmund OpenBSD/sparc Brandon Palmer OpenBSD/x86 Brandon Palmer SCO OpenUnix Larry Rosenman Solaris/sparc Andrew Sullivan Solaris/x86 Martin Renters Tru64 Alessio Bragadini (trouble with 5.1?)
> > HPUX Tom (anyone tested 11.0 or higher?)
> I thought we had a success report from someone for HPUX 11.
Yup. I have it in my (uncommitted) sgml list, but have been cutting and
pasting from previous emails and forgot to update this one.
> BTW, I'm hoping to help Tatsuo look into the reported instability
> on AIX 5L. I'm guessing it's some unportable assumption in the
> new LWLock code about behavior of semaphores. If we're really
> lucky this might also extend to the reported Cygwin problem...
Great. Do we have other folks looking at cygwin too, or is it dead in
the water unless you come up with something?
- Thomas
Thomas Lockhart <lockhart@fourpalms.org> writes:
> HPUX Tom (anyone tested 11.0 or higher?)
I thought we had a success report from someone for HPUX 11.
BTW, I'm hoping to help Tatsuo look into the reported instability
on AIX 5L. I'm guessing it's some unportable assumption in the
new LWLock code about behavior of semaphores. If we're really
lucky this might also extend to the reported Cygwin problem...
regards, tom lane
> -----Original Message----- > From: Thomas Lockhart [mailto:lockhart@fourpalms.org] > Sent: 07 December 2001 16:15 > To: Hackers List; Bill Studenmund; tegge@repas-aeg.de; Mark > Knox; Neale.Ferguson@softwareAG-usa.com; prlw1@cam.ac.uk; Tatsuo Ishii > Subject: Third call for platform testing > > > We've got most platforms ironed out, with just a few left to > get a definitive report. It looks like we'll end up dropping > a few platforms for this release (the first time in several > years that the number of supported platforms decreased!). > > Windows/native Magnus Hagander (clients only) > Any reports? Compiled OK with a few warnings using M$ VC++ 6, Service Pack 5. Randomly tested psql/libpq with 7.2b3 on Slackware Linux 8.0 - no problems found. NOTE: I'm not able to test libpq++ as I don't know C++ or have any apps to compile/test it with - it compiled OK though :-). Regards, Dave.
Thomas Lockhart writes: > QNX Bernd Tegge, Igor Kovalenko > Anyone tested 4.x with 7.2, > or are we stuck with QNX6 needing patches? Please note that QNX 4 and QNX 6 are completely different operating systems that happen to come from the same company. So you don't want to have one entry for both of them. -- Peter Eisentraut peter_e@gmx.net
...
> Please note that QNX 4 and QNX 6 are completely different operating
> systems that happen to come from the same company. So you don't want to
> have one entry for both of them.
Oh, of course. Don't know why one would assume that they are versions of
the *same* OS ;)
From recent emails, it looks like QNX 4 should be listed as supported,
and QNX 6 could/should be listed as "supported with patches". Or should
the status for 6 be something different?
- Thomas
> SunOS Tatsuo Ishii > Are we giving up on this one? Still relevant? What should we do? The only remaining issue is a non-8-bit-clean memcmp, which seems pretty easy to fix it. -- Tatsuo Ishii
Dave Page wrote:
>
> > Windows/native Magnus Hagander (clients only)
> Compiled OK with a few warnings using M$ VC++ 6, Service Pack 5.
> Randomly tested psql/libpq with 7.2b3 on Slackware Linux 8.0 - no problems
> found.
Great! Thanks for testing and reporting...
- Thomas
> > SunOS Tatsuo Ishii > > Are we giving up on this one? Still relevant? > > What should we do? The only remaining issue is a non-8-bit-clean > memcmp, which seems pretty easy to fix it. Yes, seems we could go a few directions with SunOS: Leave bit types broken on that platform, document itHard-code in a memcmp() in C for just that platform in varbit.cAdd configuretest and real memcmp() function for bad platforms Anyone want to vote on these? Personally, SunOS seems like the granddaddy of ports and I would hate to see it leave, especially when we are so close. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> ... > > Please note that QNX 4 and QNX 6 are completely different operating > > systems that happen to come from the same company. So you don't want to > > have one entry for both of them. > > Oh, of course. Don't know why one would assume that they are versions of > the *same* OS ;) > > >From recent emails, it looks like QNX 4 should be listed as supported, > and QNX 6 could/should be listed as "supported with patches". Or should > the status for 6 be something different? That seems right to me. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Build and test run sucessfully on Linux/390 and Linux/PlayStation2 with low-order-digit diffs in geometry. Permaine
> Build and test run sucessfully on Linux/390 and
> Linux/PlayStation2 with low-order-digit diffs in
> geometry.
Oooh, too cool. Thanks for the report! Could you post results (the
regression.out file etc) on the developer's web site? Especially for the
new platform: we probably need more details on how easy or hard it was
to get the new platform working...
- Thomas
Sure, I'll post the results. Actually, on S/390, there's no need to change anything, but on the PS/2, the test-and-set code doesn't work on that CPU, Tom Lane suggested a workaround - undefine HAS_TEST_AND_SET and remove slock_t type definition in the port include file. With those modifications, both the build and tests work fine. Permaine ----- Original Message ----- From: Thomas Lockhart <lockhart@fourpalms.org> To: Permaine Cheung <pcheung@redhat.com> Cc: <pgsql-hackers@postgresql.org> Sent: Wednesday, December 12, 2001 5:38 PM Subject: Re: Third call for platform testing > > Build and test run sucessfully on Linux/390 and > > Linux/PlayStation2 with low-order-digit diffs in > > geometry. > > Oooh, too cool. Thanks for the report! Could you post results (the > regression.out file etc) on the developer's web site? Especially for the > new platform: we probably need more details on how easy or hard it was > to get the new platform working... > > - Thomas
> Build and test run sucessfully on Linux/390 and > Linux/PlayStation2 with low-order-digit diffs in > geometry. Cool - Postgres on a PlayStation 2!!! Chris
> Sure, I'll post the results. Actually, on S/390, there's no need
> to change anything, but on the PS/2, the test-and-set code
> doesn't work on that CPU, Tom Lane suggested a workaround -
> undefine HAS_TEST_AND_SET and remove slock_t type
> definition in the port include file. With those modifications,
> both the build and tests work fine.
OK, S/390 is easy.
For PS/2, how does the CPU identify itself? If you have to remove the
slock_t definition from the port include file then presumably it does
identify itself as one of the already supported CPUs (alpha, arm, ia64,
i386, mips, ppc, sparc, s390), right? Or does some other default setting
get used that you then #undef in that include file?
A few more details would probably let someone reproduce your result,
which would be enough to consider this as a supported platform. That is,
as long as you aren't running the only PlayStation 2 in the world with
Linux?? Heck, on second thought we'd consider it supported even so ;)
- Thomas
> > OK, S/390 is easy. > > For PS/2, how does the CPU identify itself? If you have to remove the > slock_t definition from the port include file then presumably it does > identify itself as one of the already supported CPUs (alpha, arm, ia64, > i386, mips, ppc, sparc, s390), right? Or does some other default setting > get used that you then #undef in that include file? I specified --template=linux. :) > A few more details would probably let someone reproduce your result, > which would be enough to consider this as a supported platform. That is, > as long as you aren't running the only PlayStation 2 in the world with > Linux?? Heck, on second thought we'd consider it supported even so ;) > I'm trying to submit the report, however, I've been getting a PostgreSQL query failure saying regresstests does not exist in /usr/local/www/developer/regress/regress.php. Permaine
On Thu, 13 Dec 2001, Permaine Cheung wrote: > > > > OK, S/390 is easy. > > > > For PS/2, how does the CPU identify itself? If you have to remove the > > slock_t definition from the port include file then presumably it does > > identify itself as one of the already supported CPUs (alpha, arm, ia64, > > i386, mips, ppc, sparc, s390), right? Or does some other default setting > > get used that you then #undef in that include file? > > I specified --template=linux. :) > > > A few more details would probably let someone reproduce your result, > > which would be enough to consider this as a supported platform. That is, > > as long as you aren't running the only PlayStation 2 in the world with > > Linux?? Heck, on second thought we'd consider it supported even so ;) > > > > I'm trying to submit the report, however, I've been getting a > PostgreSQL query failure saying regresstests does not exist in > /usr/local/www/developer/regress/regress.php. Marc moved the database yesterday to another machine. The database I use for mirroring, regression tests, the website, and a bunch of other things has yet to be restored. I can't do it myself because the other machine is no longer listening. So I'm just about 100% out of business. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
...
> Marc moved the database yesterday to another machine. The database
> I use for mirroring, regression tests, the website, and a bunch of
> other things has yet to be restored. I can't do it myself because
> the other machine is no longer listening. So I'm just about 100%
> out of business.
Whoops. Marc, can we help with something here?
- Thomas
> > For PS/2, how does the CPU identify itself? If you have to remove the
> > slock_t definition from the port include file then presumably it does
> > identify itself as one of the already supported CPUs (alpha, arm, ia64,
> > i386, mips, ppc, sparc, s390), right? Or does some other default setting
> > get used that you then #undef in that include file?
> I specified --template=linux. :)
And it is an x86 CPU?
> > A few more details would probably let someone reproduce your result,
> > which would be enough to consider this as a supported platform. That is,
> > as long as you aren't running the only PlayStation 2 in the world with
> > Linux?? Heck, on second thought we'd consider it supported even so ;)
> I'm trying to submit the report, however, I've been getting a
> PostgreSQL query failure saying regresstests does not exist in
> /usr/local/www/developer/regress/regress.php.
Yeah, something apparently broke on the server. Vince?
In the meantime, you can post those results to this mailing list (or to
the -ports mailing list).
- Thomas
> And it is an x86 CPU? It's a mips CPU. Permaine
On Thu, 13 Dec 2001, Permaine Cheung wrote: > > And it is an x86 CPU? > > It's a mips CPU. Is there some way of connecting a hard disk to the PS/2? My kid has one but I never looked at it that close. BTW, regression tests are back up. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Thu, Dec 13, 2001 at 12:51:42PM -0500, Vince Vielhaber wrote: > On Thu, 13 Dec 2001, Permaine Cheung wrote: > > > > And it is an x86 CPU? > > > > It's a mips CPU. > > Is there some way of connecting a hard disk to the PS/2? My kid has > one but I never looked at it that close. http://www.linuxworld.com/ic_717468_6995_1-3133.html Linux for PS2 came out of Sony/UK, apparently. It consists of: * DVD-ROM for all the software * USB keyboard * USB wheel mouse * 10/100 Ethernet adapter * 40GB hard drive w/PCMCIA connector * PlayStation2->VGA adapter Can't seem to _find_ it for the US ones though. Seems early Japanese version of the PS@ had a PCMCIA slot. Ross
> NetBSD/arm32 Patrick Welche Not too good: CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops); + ERROR: cannot read block 3 of hash_i4_index: Bad address CREATE INDEX hash_name_index ON hash_name_heap USING hash (randomname_ops); + ERROR: cannot read block 3 of hash_name_index: Bad address CREATE INDEX hash_txt_index ON hash_txt_heap USING hash (randomtext_ops); + ERROR: cannot read block 3 of hash_txt_index: Bad address CREATE INDEX hash_f8_index ON hash_f8_heap USING hash (randomfloat8_ops); + ERROR: cannot read block 3 of hash_f8_index: Bad address -- CREATE INDEX hash_ovfl_index ON hash_ovfl_heap USING hash(x int4_ops); so create_index failed in a runcheck. (leading to sanity_check failing too) Patrick
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
>> NetBSD/arm32 Patrick Welche
> Not too good:
> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> + ERROR: cannot read block 3 of hash_i4_index: Bad address
IIRC there was a similar report awhile back --- try searching the
archives. I don't recall the resolution, and since I'm on a very slow
dialup link at the moment, I'm not eager to do the search myself.
regards, tom lane
On Thu, Dec 13, 2001 at 06:11:26PM -0500, Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: > >> NetBSD/arm32 Patrick Welche > > Not too good: > > > CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops); > > + ERROR: cannot read block 3 of hash_i4_index: Bad address > > IIRC there was a similar report awhile back --- try searching the > archives. I don't recall the resolution, and since I'm on a very slow > dialup link at the moment, I'm not eager to do the search myself. Yes - 13 Apr 2001 - that was reported against NetBSD-1.5T/vax. I was trying NetBSD-1.5U/arm32 - I'll try upgrading to NetBSD-1.5Z/arm32 and see if it changes anything.. (Will take a few days though..) Cheers, Patrick
What are we doing with the SunOS port? It is failing the 'bit' regression test. I can easily do the work if people tell me how they want this handled. --------------------------------------------------------------------------- > > > SunOS Tatsuo Ishii > > > Are we giving up on this one? Still relevant? > > > > What should we do? The only remaining issue is a non-8-bit-clean > > memcmp, which seems pretty easy to fix it. > > Yes, seems we could go a few directions with SunOS: > > Leave bit types broken on that platform, document it > Hard-code in a memcmp() in C for just that platform in varbit.c > Add configure test and real memcmp() function for bad platforms > > Anyone want to vote on these? Personally, SunOS seems like the > granddaddy of ports and I would hate to see it leave, especially when we > are so close. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What are we doing with the SunOS port? It is failing the 'bit'
> regression test. I can easily do the work if people tell me how they
> want this handled.
Including the necessary testing? How will you manage that?
IMHO, this will not and should not get dealt with unless some SunOS
users step up to the plate to do it. Tatsuo evidently doesn't care
enough to do the work himself, and we haven't seen any other respondents
for SunOS in a long time. It may be a granddaddy platform, but it's
looking a lot like a granddaddy that's passed on.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > What are we doing with the SunOS port? It is failing the 'bit' > > regression test. I can easily do the work if people tell me how they > > want this handled. > > Including the necessary testing? How will you manage that? > > IMHO, this will not and should not get dealt with unless some SunOS > users step up to the plate to do it. Tatsuo evidently doesn't care > enough to do the work himself, and we haven't seen any other respondents > for SunOS in a long time. It may be a granddaddy platform, but it's > looking a lot like a granddaddy that's passed on. I assume I would do the patch, Tatsuo would test it, and it would then be applied. I work for Tatsuo now, so he doesn't have to do the work. I can do it for him. :-) SRA has clients running SunOS, so even though there aren't people on the mailing list, there are users. I can do the work and get it tested. I just want to know how people want it fixed. Seeing as no one is saying anything, I will go ahead with my best guess, have Tatsuo test it, and post the patch for review. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026