hi,
i am running a 64bit vm (elf64 / x86_64) linux, no i have no 32bit compat x11 libs and i dont want to have them... the vm crashes on any network operation, any clues?
Program received signal SIGSEGV, Segmentation fault. 0x0000000000416711 in byteSizeOf (oop=-1398317376) at gnu-interp.c:2902 2902 header = longAt(oop); (gdb) bt #0 0x0000000000416711 in byteSizeOf (oop=-1398317376) at gnu-interp.c:2902 #1 0x00000000004a376d in primitiveResolverStartNameLookup () at .../platforms/unix/src/vm/intplugins/SocketPlugin/SocketPlugin.c:318 #2 0x0000000000416e76 in dispatchFunctionPointer (aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953 #3 0x0000000000416e76 in dispatchFunctionPointer (aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953 #4 0x000000000042abb1 in interpret () at gnu-interp.c:7761 #5 0x0000000000415609 in main (argc=<value optimized out>, argv=0x7fff3fd1cce8, envp=<value optimized out>) ...platforms/unix/vm/sqUnixMain.c:1379
Segmentation fault
23308044 [] in >addressForName:timeout: 23308136 [] in Semaphore>critical: 23307768 BlockContext>ensure: 23307676 Semaphore>critical: 23306908 >addressForName:timeout: 23299436 >httpGetDocument:args:accept:request: 23303844 >httpGet:args:accept:request: 23303380 >httpGet:args:user:passwd: 23303012 MCHttpRepository>allFileNames 23302896 MCFileBasedRepository>allFileNamesOrCache 23302788 MCFileBasedRepository>readableFileNames 23302696 MCFileRepositoryInspector>refresh 23302540 MCFileRepositoryInspector>setRepository:workingCopy: 23302356 >repository:workingCopy: 23302264 MCFileBasedRepository>morphicOpen: 23302448 [] in MCWorkingCopyBrowser>openRepository 23302172 Object>ifNotNilDo: 23302080 MCWorkingCopyBrowser>openRepository 23301620 PluggableButtonMorph>performAction 23301436 PluggableButtonMorphPlus>performAction 23301528 [] in PluggableButtonMorph>mouseUp: 23301344 SequenceableCollection>do: 23301252 PluggableButtonMorph>mouseUp: 23301120 PluggableButtonMorphPlus>mouseUp: 23301028 Morph>handleMouseUp: 23300936 MouseButtonEvent>sentTo: 23300568 Morph>handleEvent: 23300476 Morph>handleFocusEvent: 23300660 [] in HandMorph>sendFocusEvent:to:clear: 23300752 [] in PasteUpMorph>becomeActiveDuring: 23300384 BlockContext>on:do: 23300292 PasteUpMorph>becomeActiveDuring: 23300016 HandMorph>sendFocusEvent:to:clear: 23299924 HandMorph>sendEvent:focus:clear: 23299832 HandMorph>sendMouseEvent: 23299344 HandMorph>handleEvent: 23293552 HandMorph>processEvents 23293668 [] in WorldState>doOneCycleNowFor: 23293460 SequenceableCollection>do: 23293368 WorldState>handsDo: 23293276 WorldState>doOneCycleNowFor: 23291300 WorldState>doOneCycleFor: 23291208 PasteUpMorph>doOneCycle 14434012 [] in >spawnNewProcess 14434196 [] in BlockContext>newProcess
thanks in andvance ;)
__________________________________ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever
Hi Tom,
you could try using the appended version of SocketPlugin.c. Copy it to plattform/unix/src/vm/intplugins/SocketPlugin and build the vm. If you use a different src-folder for the VMMaker stuff change the path acordingly.
I reported that bug some time ago on this list. But I failed to create a mantis entry, though. Shame on me.
Martin
Am Tuesday 29 May 2007 schrieb tom:
hi,
i am running a 64bit vm (elf64 / x86_64) linux, no i have no 32bit compat x11 libs and i dont want to have them... the vm crashes on any network operation, any clues?
Program received signal SIGSEGV, Segmentation fault. 0x0000000000416711 in byteSizeOf (oop=-1398317376) at gnu-interp.c:2902 2902 header = longAt(oop); (gdb) bt #0 0x0000000000416711 in byteSizeOf (oop=-1398317376) at gnu-interp.c:2902 #1 0x00000000004a376d in primitiveResolverStartNameLookup () at .../platforms/unix/src/vm/intplugins/SocketPlugin/SocketPlugin.c:318 #2 0x0000000000416e76 in dispatchFunctionPointer (aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953 #3 0x0000000000416e76 in dispatchFunctionPointer (aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953 #4 0x000000000042abb1 in interpret () at gnu-interp.c:7761 #5 0x0000000000415609 in main (argc=<value optimized out>, argv=0x7fff3fd1cce8, envp=<value optimized out>) ...platforms/unix/vm/sqUnixMain.c:1379
Segmentation fault
23308044 [] in >addressForName:timeout: 23308136 [] in Semaphore>critical: 23307768 BlockContext>ensure: 23307676 Semaphore>critical: 23306908 >addressForName:timeout: 23299436 >httpGetDocument:args:accept:request: 23303844 >httpGet:args:accept:request: 23303380 >httpGet:args:user:passwd: 23303012 MCHttpRepository>allFileNames 23302896 MCFileBasedRepository>allFileNamesOrCache 23302788 MCFileBasedRepository>readableFileNames 23302696 MCFileRepositoryInspector>refresh 23302540 MCFileRepositoryInspector>setRepository:workingCopy: 23302356 >repository:workingCopy: 23302264 MCFileBasedRepository>morphicOpen: 23302448 [] in MCWorkingCopyBrowser>openRepository 23302172 Object>ifNotNilDo: 23302080 MCWorkingCopyBrowser>openRepository 23301620 PluggableButtonMorph>performAction 23301436 PluggableButtonMorphPlus>performAction 23301528 [] in PluggableButtonMorph>mouseUp: 23301344 SequenceableCollection>do: 23301252 PluggableButtonMorph>mouseUp: 23301120 PluggableButtonMorphPlus>mouseUp: 23301028 Morph>handleMouseUp: 23300936 MouseButtonEvent>sentTo: 23300568 Morph>handleEvent: 23300476 Morph>handleFocusEvent: 23300660 [] in HandMorph>sendFocusEvent:to:clear: 23300752 [] in PasteUpMorph>becomeActiveDuring: 23300384 BlockContext>on:do: 23300292 PasteUpMorph>becomeActiveDuring: 23300016 HandMorph>sendFocusEvent:to:clear: 23299924 HandMorph>sendEvent:focus:clear: 23299832 HandMorph>sendMouseEvent: 23299344 HandMorph>handleEvent: 23293552 HandMorph>processEvents 23293668 [] in WorldState>doOneCycleNowFor: 23293460 SequenceableCollection>do: 23293368 WorldState>handsDo: 23293276 WorldState>doOneCycleNowFor: 23291300 WorldState>doOneCycleFor: 23291208 PasteUpMorph>doOneCycle 14434012 [] in >spawnNewProcess 14434196 [] in BlockContext>newProcess
thanks in andvance ;)
__________________________________ Kennt man wirklich jeden über3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever
On Tue, May 29, 2007 at 12:50:45PM +0200, tom wrote:
i am running a 64bit vm (elf64 / x86_64) linux, no i have no 32bit compat x11 libs and i dont want to have them... the vm crashes on any network operation, any clues?
In your platforms directory (the one you got from Subversion), the sqMemoryAccess.h file needs a patch. This is in Mantis bug report #4608 http://bugs.squeak.org/view.php?id=4608, and the actual patched file is http://bugs.squeak.org/file_download.php?file_id=2809&type=bug.
Also apply the fix in Mantis #5688. You don't need this to get a running VM, but you will not be able to connect to SqueakMap until you have included this fix in your VM.
See also the reply from Martin Kuball. I'm not sure if the patch on Mantix #5688 addresses the same issue, but possible it does. In any case, #4608 and #5688 are sufficient to give you a working VM on 64-bit Linux systems.
There are some other issues listed in the Mantis "Squeak 64 bit" category, but I don't think you need to worry about them if you are just running 32 bit images.
Dave
2007/5/30, David T. Lewis lewis@mail.msen.com:
On Tue, May 29, 2007 at 12:50:45PM +0200, tom wrote:
i am running a 64bit vm (elf64 / x86_64) linux, no i have no 32bit compat x11 libs and i dont want to have them... the vm crashes on any network operation, any clues?
In your platforms directory (the one you got from Subversion), the sqMemoryAccess.h file needs a patch. This is in Mantis bug report #4608 http://bugs.squeak.org/view.php?id=4608, and the actual patched file is http://bugs.squeak.org/file_download.php?file_id=2809&type=bug.
Also apply the fix in Mantis #5688. You don't need this to get a running VM, but you will not be able to connect to SqueakMap until you have included this fix in your VM.
See also the reply from Martin Kuball. I'm not sure if the patch on Mantix #5688 addresses the same issue, but possible it does. In any case, #4608 and #5688 are sufficient to give you a working VM on 64-bit Linux systems.
There are some other issues listed in the Mantis "Squeak 64 bit" category, but I don't think you need to worry about them if you are just running 32 bit images.
Why are these patches not included if you need them to get a working VM?
Cheers Philippe
Dave
Philippe Marschall wrote:
Why are these patches not included if you need them to get a working VM?
Because people are busy and there has been a (to me) astonishing lack of interest in 64 bit VMs.
Cheers, - Andreas
2007/5/30, Andreas Raab andreas.raab@gmx.de:
Philippe Marschall wrote:
Why are these patches not included if you need them to get a working VM?
Because people are busy and there has been a (to me) astonishing lack of interest in 64 bit VMs.
I know several people how have a 64bit system and don't run 64bit VMs exactly because of all these issues to get them working.
Cheers Philippe
Cheers,
- Andreas
Am Wednesday 30 May 2007 schrieb Philippe Marschall:
2007/5/30, Andreas Raab andreas.raab@gmx.de:
Philippe Marschall wrote:
Why are these patches not included if you need them to get a working VM?
Because people are busy and there has been a (to me) astonishing lack of interest in 64 bit VMs.
I know several people how have a 64bit system and don't run 64bit VMs exactly because of all these issues to get them working.
Please keep trying. I'm really interested in making this work and getting the fixes into svn and VMMaker (although I wasn't really active in this regard lately).
Martin
Martin - and others of course - what exactly do you want a 64bit vm for? Do you really need more than 4gb sized object memory spaces? What benefit is there to running a 64bit integer baesed vm with a 32bit oop based image? Perhaps I'm forgetting something but it doesn't seem like anything terribly useful.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SSAN: Stop, and See if Anyone Notices
I don't want a 4GB image, but I may want a lot of normal-sized Squeak images running on a piece of "big-iron". But I guess the current VM's have some problem where the oop was defined as signed, so images cannot even *reside* above 1GB (or whatever it is).
So even if that was fixed, that would take 32-bit Squeak up to 4GB boundary, only if all 32-bits were for the oop.
... I saw this ad on the back of InfoRag earlier today. Some IBM blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at $2K. Cool, this could probably run a lot of images simultaneously, but how far could you go with 32-bit Squeak on this?
On 5/30/07, tim Rowledge tim@rowledge.org wrote:
Martin - and others of course - what exactly do you want a 64bit vm for? Do you really need more than 4gb sized object memory spaces? What benefit is there to running a 64bit integer baesed vm with a 32bit oop based image? Perhaps I'm forgetting something but it doesn't seem like anything terribly useful.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SSAN: Stop, and See if Anyone Notices
On May 30, 2007, at 6:17 PM, Chris Muller wrote:
I don't want a 4GB image, but I may want a lot of normal-sized Squeak images running on a piece of "big-iron". But I guess the current VM's have some problem where the oop was defined as signed, so images cannot even *reside* above 1GB (or whatever it is).
2GB, and lurking are changes to fix that issue, but someone has to buckle down and do testing, then mmm say oh yes should be fixed. But how would you know?
So even if that was fixed, that would take 32-bit Squeak up to 4GB boundary, only if all 32-bits were for the oop.
... I saw this ad on the back of InfoRag earlier today. Some IBM blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at $2K. Cool, this could probably run a lot of images simultaneously, but how far could you go with 32-bit Squeak on this?
Depends on the image footprint, 3GB images then what 15 or so Plus then one cpu needed for each Squeak VM, plus a couple of spares to do operating system I/O, housekeeping etc. etc.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Cool, I think you're saying, once the signed oop is fixed, there should be no problem with memory locations beyond 4GB. Curious though, why the signed-oop bug also affects where images *start* in memory instead of only how large they could be.. Given (theoretical) unlimited memory, then, does the signed-oop fix allow an unlimited number of running Squeak images?
I wasn't sure because of the image being referred as "direct-pointer"; thought that might mean hard-referenced memory locations limited to 32 bits.
thanks.
On 5/30/07, John M McIntosh johnmci@smalltalkconsulting.com wrote:
On May 30, 2007, at 6:17 PM, Chris Muller wrote:
I don't want a 4GB image, but I may want a lot of normal-sized Squeak images running on a piece of "big-iron". But I guess the current VM's have some problem where the oop was defined as signed, so images cannot even *reside* above 1GB (or whatever it is).
2GB, and lurking are changes to fix that issue, but someone has to buckle down and do testing, then mmm say oh yes should be fixed. But how would you know?
So even if that was fixed, that would take 32-bit Squeak up to 4GB boundary, only if all 32-bits were for the oop.
... I saw this ad on the back of InfoRag earlier today. Some IBM blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at $2K. Cool, this could probably run a lot of images simultaneously, but how far could you go with 32-bit Squeak on this?
Depends on the image footprint, 3GB images then what 15 or so Plus then one cpu needed for each Squeak VM, plus a couple of spares to do operating system I/O, housekeeping etc. etc.
--
=== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On May 30, 2007, at 8:22 PM, Chris Muller wrote:
Cool, I think you're saying, once the signed oop is fixed, there should be no problem with memory locations beyond 4GB. Curious though, why the signed-oop bug also affects where images *start* in memory instead of only how large they could be.. Given (theoretical) unlimited memory, then, does the signed-oop fix allow an unlimited number of running Squeak images?
I wasn't sure because of the image being referred as "direct-pointer"; thought that might mean hard-referenced memory locations limited to 32 bits.
thanks.
This issue is if the oops value becomes negative. A image is located in memory at point X, if image size + X > 2GB, you'll die. The direct object reference pointer *IS* a memory address, all references are swizzled at image load time so that the object reference value becomes the memory address. It's still a object reference, don't forget, however at some point people do compares on it, and signed versus unsigned compares have different meanings.
There should be no problem with memory in the 2GB to 4GB range for 32bits. images once the fix is done, tested, and given the VM good housekeeping seal of approval.
For 64bit images right now you have no problems with the range 0-2^63 which is a lot.... Can you even assemble a disk farm that will provide that backing store?
The fix will double that to 2^64.
Note of course you can't get *all* the address space, most operating system maps out large chunks for memory mapped devices, ROM, etc etc.
The number of squeak images you can run is limited by the combined total of memory and Virtual Memory swapping store. Some operating system take an optimistic viewpoint (BSD) and just pretend to give you the memory, and you pretend to use it. If you do and exceed all nooks and crannies of the storage system, then some Process will die...
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On May 31, 2007, at 5:22 , Chris Muller wrote:
Cool, I think you're saying, once the signed oop is fixed, there should be no problem with memory locations beyond 4GB.
No - each process in the operating system gets their own virtual memory space. As long as your image is not larger than 4 GB you can run the 32-bit version, but as many copies of it as RAM+Swap allows. Each one will see its address space starting at 0 going up to 4 GB. There is no "memory locations beyond 4GB" for a 32 bit process, but the big irons can run many of them.
- Bert -
On Thursday 31 May 2007 1:48 pm, Bert Freudenberg wrote:
On May 31, 2007, at 5:22 , Chris Muller wrote:
Cool, I think you're saying, once the signed oop is fixed, there should be no problem with memory locations beyond 4GB.
No - each process in the operating system gets their own virtual memory space. As long as your image is not larger than 4 GB you can run the 32-bit version, but as many copies of it as RAM+Swap allows.
4GB limit applies to the total per-process virtual space. If the space taken up per-process kernel structures and internal fragmentation etc. are accounted for, the limit on image size may work out somewhere between 3 to 3.5GB.
Regards .. Subbu
On Thursday 31 May 2007 6:47 am, Chris Muller wrote:
... I saw this ad on the back of InfoRag earlier today. Some IBM blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at $2K. Cool, this could probably run a lot of images simultaneously, but how far could you go with 32-bit Squeak on this?
Chris,
Look at it this way - given the huge test cycles and the number of bugs that leak past into processes with 20MB footprint, would you trust processes that need a 100x footprint? or would you settle for a bunch of co-operating processes (like Croquet) ? Those 48GB RAM continue to consume energy even when your memory usage drops to 1GB. 2K looks cheap till you get the power bill :-).
The 32-bit to 64-bit transition is going to be much painful and much more longer than the 16-32b transition.
Regards .. Subbu
Am Thursday 31 May 2007 schrieb tim Rowledge:
Martin - and others of course - what exactly do you want a 64bit vm for? Do you really need more than 4gb sized object memory spaces? What benefit is there to running a 64bit integer baesed vm with a 32bit oop based image? Perhaps I'm forgetting something but it doesn't seem like anything terribly useful.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SSAN: Stop, and See if Anyone Notices
Well, I'm running a 64bit Linux and I don't want to change into a 32bit environment to run squeak. That's all. And it works for me. The memory access bug is fixed. And if I get some positive feedback from Philippe about the network bug I will post a CS for VMMaker.
From my point of view it's just a matter of having the choice. And I think people should have the choice If we can provide it.
Martin
On 31-May-07, at 9:39 AM, Martin Kuball wrote:
Well, I'm running a 64bit Linux and I don't want to change into a 32bit environment to run squeak. That's all.
Somebody is going to have to explain this to me. Why would you have to "change into a 32bit environment" ?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Oblitus sum perpolire clepsydras! = I forgot to polish the clocks!
On Thu, May 31, 2007 at 12:44:01PM -0700, tim Rowledge wrote:
On 31-May-07, at 9:39 AM, Martin Kuball wrote:
Well, I'm running a 64bit Linux and I don't want to change into a 32bit environment to run squeak. That's all.
Somebody is going to have to explain this to me. Why would you have to "change into a 32bit environment" ?
On a 64-bit machine, a 32-bit VM has to use the appropriate runtime libraries. If you build a 32-bit VM on a 64-bit system, you have to link to the right libraries. Google "linux 64-bit 32-bit" for the annoying details. This is really not a big deal, but who wants to figure out that kind of stuff, especially if you are building your own VM and you are already running on a perfectly good 64-bit machine.
Hmmm, even more especially if you are building an application that is supposed to be portable across a wide variety of target machines. It works on RISC OS, but not on AMD64? Go figure.
Dave
On 31-May-07, at 5:41 PM, David T. Lewis wrote:
On Thu, May 31, 2007 at 12:44:01PM -0700, tim Rowledge wrote:
On 31-May-07, at 9:39 AM, Martin Kuball wrote:
Well, I'm running a 64bit Linux and I don't want to change into a 32bit environment to run squeak. That's all.
Somebody is going to have to explain this to me. Why would you have to "change into a 32bit environment" ?
On a 64-bit machine, a 32-bit VM has to use the appropriate runtime libraries.
Oh, duh. '64 bit' makes noises in my head about 64 bit OOPs. Never mind.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim <-------- The information went data way -------->
tim Rowledge writes:
Somebody is going to have to explain this to me. Why would you have to "change into a 32bit environment" ?
On a 64-bit machine, a 32-bit VM has to use the appropriate runtime libraries.
Oh, duh. '64 bit' makes noises in my head about 64 bit OOPs. Never mind.
There's also the possibility that the AMD64 instruction set is faster than AMD32 especially if you're using a 32 bit image so are not paying for extra memory bandwidth for each oop. The reason is increasing the number of registers from 8 (6-7 usable) to 16.
This may not matter for the interpreter given branch mispredicts due to decoding.
Bryce
2007/5/31, Martin Kuball martinkuball@web.de:
Am Thursday 31 May 2007 schrieb tim Rowledge:
Martin - and others of course - what exactly do you want a 64bit vm for? Do you really need more than 4gb sized object memory spaces? What benefit is there to running a 64bit integer baesed vm with a 32bit oop based image? Perhaps I'm forgetting something but it doesn't seem like anything terribly useful.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SSAN: Stop, and See if Anyone Notices
Well, I'm running a 64bit Linux and I don't want to change into a 32bit environment to run squeak. That's all. And it works for me. The memory access bug is fixed. And if I get some positive feedback from Philippe about the network bug I will post a CS for VMMaker.
Sorry it took me so long. Seaside works (did before), Monticello crashes no more. So I'd say it works for me so far.
There are of course a lot of plugins who don't work (cast from pointer to integer of different size). Many of them I don't miss (graphic, sound, ...). Among those I miss cUrl, could anybody get this to compile? But UUID works.
Cheers Philippe
From my point of view it's just a matter of having the choice. And I think people should have the choice If we can provide it.
Martin
Philippe Marschall wrote:
2007/5/30, Andreas Raab andreas.raab@gmx.de:
Philippe Marschall wrote:
Why are these patches not included if you need them to get a working
VM?
Because people are busy and there has been a (to me) astonishing lack of interest in 64 bit VMs.
I know several people how have a 64bit system and don't run 64bit VMs exactly because of all these issues to get them working.
But you seem to be the first person to show any reaction in a couple of months (check the list archives).
Cheers, - Andreas
2007/5/30, Andreas Raab andreas.raab@gmx.de:
Philippe Marschall wrote:
2007/5/30, Andreas Raab andreas.raab@gmx.de:
Philippe Marschall wrote:
Why are these patches not included if you need them to get a working
VM?
Because people are busy and there has been a (to me) astonishing lack of interest in 64 bit VMs.
I know several people how have a 64bit system and don't run 64bit VMs exactly because of all these issues to get them working.
But you seem to be the first person to show any reaction in a couple of months (check the list archives).
Just by checking the mailing list posts you would guess that Seaside has about a dozen of users. It's sometimes amazing to find out what users you have that you never heard about or didn't even subscribe to the mailing list.
Cheers Philippe
--- Andreas Raab andreas.raab@gmx.de schrieb:
Philippe Marschall wrote:
Why are these patches not included if you need
them to get a working VM?
Because people are busy and there has been a (to me) astonishing lack of interest in 64 bit VMs.
Cheers,
- Andreas
well, in case someone else wants to use a 64bit vm with an 32bit image attached there is an unified patch against vanilla 3.9-9 vm to fix sqMemoryAccess and SocketPlugin, should be fixed at the right place but at least this way you get a working vm + working socket plugin ...
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
bryce＠kampjes.demon.co.uk -
Chris Muller -
David T. Lewis -
John M McIntosh -
Martin Kuball -
Philippe Marschall -
subbukk -
tim Rowledge -
tom