Re: Test atomic operations on SPARC 32-bit

2017-12-08 Thread Romain Dolbeau
2017-12-09 0:45 GMT+01:00 Petr Vorel : > Nice, thanks a lot! I might use kernel implementation, but this is handy. > (...) > I need threads only, no shmem... The lib was designed to support GCC 4.8 (IIRC) and some C++11 threading on S7 and S8. If that's what you need

Re: Test atomic operations on SPARC 32-bit

2017-12-08 Thread Petr Vorel
Hello, > >> In any case, the Gentoo people are still on 32-Bit SPARC. You might ask > >> there > >> first (see #gentoo-sparc on Freenode). Otherwise, we will have to create a > >> 32-Bit chroot for you but that would probably take a bit longer. > > OK, I'll ask them and if not works I'll come

Re: Test atomic operations on SPARC 32-bit

2017-12-08 Thread Petr Vorel
Hi Romain, > As mentioned by someone else, v7 and v8 do not have them as hardware > instruction. They were introduced in v9 and its 32 bits sibling, v8+. As I wrote, yep v8 => I need to emulate implementation. > You can emulate them in many ways, including with a trivial global > lock using the

Re: Test atomic operations on SPARC 32-bit

2017-12-08 Thread Petr Vorel
Hi Adrian, > On 12/09/2017 12:21 AM, Petr Vorel wrote: > >> I'm asking because atomic operations were only added with SPARCv8+ and > >> later. > > SPARCv8 would be enough as SPARCv7 is dead. So still no hw support. > From what I have heard, SPARCv7 should actually work since people added >

Re: Test atomic operations on SPARC 32-bit

2017-12-08 Thread John Paul Adrian Glaubitz
On 12/09/2017 12:21 AM, Petr Vorel wrote: >> I'm asking because atomic operations were only added with SPARCv8+ and later. > SPARCv8 would be enough as SPARCv7 is dead. So still no hw support. >From what I have heard, SPARCv7 should actually work since people added kernel helpers to the Linux

Re: Test atomic operations on SPARC 32-bit

2017-12-08 Thread Petr Vorel
Hi Adrian, > On 12/08/2017 10:32 PM, Petr Vorel wrote: > > I'm sorry to ask a question here which is not directly related to Debian, > > it just about > > SPARC 32-bit. > > Does anyone have SPARC 32-bit machine and would be willing to allow to give > > me SSH account > > for some testing? > >

Re: Test atomic operations on SPARC 32-bit

2017-12-08 Thread Romain Dolbeau
2017-12-08 22:32 GMT+01:00 Petr Vorel : > I'm trying to implement __sync_add_and_fetch(), as according to buildroot > investigation > [1] it's not available on SPARC 32-bit As mentioned by someone else, v7 and v8 do not have them as hardware instruction. They were

Re: Test atomic operations on SPARC 32-bit

2017-12-08 Thread John Paul Adrian Glaubitz
On 12/08/2017 10:32 PM, Petr Vorel wrote: > I'm sorry to ask a question here which is not directly related to Debian, it > just about > SPARC 32-bit. > > Does anyone have SPARC 32-bit machine and would be willing to allow to give > me SSH account > for some testing? > They used to have them at

Re: GRUB testers on SPARC needed

2017-12-08 Thread John Paul Adrian Glaubitz
There is no separate ISO. You can just choose to install GRUB instead of SILO when you install your machine with the current ISO. Just go back to the main menu instead of finishing the installation at the last installation step. Then choose „Install GRUB boot loader“, ignore the two errors

Re: GRUB testers on SPARC needed

2017-12-08 Thread Tony Rodriguez
Please provide a link to the latest ISO with grub support for sparc64. I will happy to test if it works on my t5120, t5140, and T4-2 systems. Tony On 12/08/2017 05:27 AM, Frans van Berckel wrote: Hi Adrian, On Fri, 2017-12-08 at 13:24 +0100, John Paul Adrian Glaubitz wrote: Hi! We're in

Re: GRUB testers on SPARC needed

2017-12-08 Thread Frans van Berckel
On Fri, 2017-12-08 at 14:28 +0100, John Paul Adrian Glaubitz wrote: > On 12/08/2017 02:27 PM, Frans van Berckel wrote: > > Sun Fire V440, No Keyboard > > Copyright 2010 Sun Microsystems, Inc. All rights reserved. > > OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521. > > Ethernet

Re: GRUB testers on SPARC needed

2017-12-08 Thread John Paul Adrian Glaubitz
On 12/08/2017 02:27 PM, Frans van Berckel wrote: Sun Fire V440, No Keyboard Copyright 2010 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521. Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9. booting with command: boot Boot device:

Re: GRUB testers on SPARC needed

2017-12-08 Thread Frans van Berckel
Hi Adrian, On Fri, 2017-12-08 at 13:24 +0100, John Paul Adrian Glaubitz wrote: > Hi! > > We're in the process of migrating Debian for sparc64 from SILO to > GRUB as GRUB upstream is adding support for modern SPARC machines > thanks to the work of Eric Snowberg from Oracle. > > In order to make

Re: Bug#876147: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)

2017-12-08 Thread James Clarke
On Fri, Dec 08, 2017 at 09:49:05AM +0100, Andreas Tille wrote: > Hi Flavien, > > I have put the porter lists of the affected architectures in CC whether > there is somebody who has a hint for a better solution than removing > these architectures from the supported architectures. This kind of >

GRUB testers on SPARC needed

2017-12-08 Thread John Paul Adrian Glaubitz
Hi! We're in the process of migrating Debian for sparc64 from SILO to GRUB as GRUB upstream is adding support for modern SPARC machines thanks to the work of Eric Snowberg from Oracle. In order to make sure GRUB works on all machines supported by the sparc64 port, we need your help to test GRUB

Re: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)

2017-12-08 Thread John Paul Adrian Glaubitz
We have a new sparc64 porterbox called sakharov.debian.net. Feel free to test your code there. Adrian > On Dec 8, 2017, at 9:49 AM, Andreas Tille wrote: > > Hi Flavien, > > I have put the porter lists of the affected architectures in CC whether > there is somebody who has a

Re: camp frequently FTBFS on 64bit big endian: camptest-qt (Failed)

2017-12-08 Thread Andreas Tille
Hi Flavien, I have put the porter lists of the affected architectures in CC whether there is somebody who has a hint for a better solution than removing these architectures from the supported architectures. This kind of "random failure"[1] is quite hard to debug for somebody who is not familiar