Re: Test atomic operations on SPARC 32-bit

[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 (except for the Solaris
bit), it should be directly usable.

> It looks to me that this is used in kernel (if I understand the code 
> correctly).

Didn't realize the Linux kernel was already doing something about it.
I don't know any distribution that still run (let alone support) on v7/v8,
so I never thought of looking at the kernel. Debian only goes up to Debian 5.

Re-compiling a recent GCC on a dual SM51 is an exercise in patience
nowadays :-)

Cordially,

-- 
Romain Dolbeau

Re: Test atomic operations on SPARC 32-bit

[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 back.
I just got an advice from jrtc27 on IRC that there is already sparc 32-bit 
wheezy V8+
chroot on deb4g. I didn't realize that for developing software only solution 
(no hw
support, like for v7) it should be enough.

Thank you all for help!

Kind regards,
Petr

Re: Test atomic operations on SPARC 32-bit

[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 existing test-and-set instruction.
> I did that a while ago for some recompilation in S7 and S8:
> 
Nice, thanks a lot! I might use kernel implementation, but this is handy.
I'll see, what will be easier to port to my specific use-case.

> Beware that it's not a universal solution.
> 
> 1) The lock variable is defined in the library, so it's not shared
> between processes. Atomic won't work between processes in shared
> memory such as SysV shmem, only for threads. Going multi-process
> transparently (w/o changing the function signature) is non-trivial.
I need threads only, no shmem...

> 2) The lock variable is one big contention point that will slow things
> down, by forcing mutual exclusion for all atomic accesses including
> those to different variables. In theory it could be replaced by an
> array of variables (in different cache lines) using some sort of hash
> function based on the address of the protected variable. If that
> matters... use v8+ hardware instead would be my advice :-) v7 and v8
> are not suitable for modern parallelism.
It looks to me that this is used in kernel (if I understand the code correctly).

Kind regards,
Petr

Re: Test atomic operations on SPARC 32-bit

[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
> kernel helpers to the Linux kernel to emulate the atomics for v7 hardware.
Oh yes, I've heard that as well. I'm looking into kernel source
arch/sparc/lib/atomic32.c
arch/sparc/include/asm/atomic_32.h

According to the sources they implemented it by hashing the object address and 
indexing
into an array of spinlocks.

Also LWN is talking about it
https://lwn.net/Articles/695257/

> SPARCv8 doesn't have Compare-And-Swap either, SPARCv8+ does which is what
> most people run these days when they run 32-Bit-SPARC.

> >> 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 back.

> They just started working on their SPARC port again.
Good to know, thanks!

> Adrian


Kind regards,
Petr

Re: Test atomic operations on SPARC 32-bit

[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 kernel to emulate the atomics for v7 hardware.

SPARCv8 doesn't have Compare-And-Swap either, SPARCv8+ does which is what
most people run these days when they run 32-Bit-SPARC.

>> 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 back.

They just started working on their SPARC port again.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Test atomic operations on SPARC 32-bit

[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?
> > They used to have them at GCC Compile Farm Project [2], but not any more.

> Do you need SPARCv7, SPARCv8 or SPARCv8+ aka SPARCv9 with 32 bits?

> 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.

> 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 back.

Thank you!


Kind regards,
Petr

> Adrian

Re: Test atomic operations on SPARC 32-bit

[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 introduced in v9 and its 32 bits sibling, v8+.

You can emulate them in many ways, including with a trivial global
lock using the existing test-and-set instruction.
I did that a while ago for some recompilation in S7 and S8:


Beware that it's not a universal solution.

1) The lock variable is defined in the library, so it's not shared
between processes. Atomic won't work between processes in shared
memory such as SysV shmem, only for threads. Going multi-process
transparently (w/o changing the function signature) is non-trivial.

2) The lock variable is one big contention point that will slow things
down, by forcing mutual exclusion for all atomic accesses including
those to different variables. In theory it could be replaced by an
array of variables (in different cache lines) using some sort of hash
function based on the address of the protected variable. If that
matters... use v8+ hardware instead would be my advice :-) v7 and v8
are not suitable for modern parallelism.

Cordially,

-- 
Romain Dolbeau

Re: Test atomic operations on SPARC 32-bit

[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 GCC Compile Farm Project [2], but not any more.

Do you need SPARCv7, SPARCv8 or SPARCv8+ aka SPARCv9 with 32 bits?

I'm asking because atomic operations were only added with SPARCv8+ and later.

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.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[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 about missing packages and install into /dev/BOOTDISK1 where BOOTDISK is 
your boot disk (e.g. sda or vdiska).

Adrian

> On Dec 8, 2017, at 4:27 PM, Tony Rodriguez  wrote:
> 
> 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 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 on your particular
>>> hardware, the older your machine, the better.
>>> 7. Report back to the list and include your hardware and partition
>>> setup
>> Probing system devices
>> Probing memory
>> Probing I/O buses
>> screen not found.
>> keyboard not found.
>> Keyboard not present.  Using ttya for input and output.
>> Probing system devices
>> Probing memory
>> Probing I/O buses
>> 
>> 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: disk  File and args:
>> 
>> GRUB Loading kernel...
>> screen not found.
>> error: out of memory.
>> error: no suitable video mode found.
>> 
>> GNU GRUB  version 2.02-2+sparc64.3
>> 
>> Loading Linux 4.13.0-1-sparc64-smp ...
>> 
>> # lsblk
>> 
>> NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
>> sda   8:00 136.7G  0 disk
>> ├─sda18:10 902.1M  0 part  /boot
>> ├─sda28:20 135.9G  0 part
>> │ └─md0   9:00 135.7G  0 raid1 /
>> └─sda38:30 136.7G  0 part
>> sdb   8:16   0 136.7G  0 disk
>> ├─sdb18:17   0 902.1M  0 part
>> ├─sdb28:18   0 135.9G  0 part
>> │ └─md0   9:00 135.7G  0 raid1 /
>> └─sdb38:19   0 136.7G  0 part
>> sdc   8:32   0  33.9G  0 disk
>> ├─sdc18:33   030G  0 part
>> │ └─md1   9:1030G  0 raid1 /home
>> └─sdc28:34   0   3.9G  0 part  [SWAP]
>> sdd   8:48   0  33.9G  0 disk
>> ├─sdd18:49   030G  0 part
>> │ └─md1   9:1030G  0 raid1 /home
>> └─sdd28:50   0   3.9G  0 part  [SWAP]
>> sr0  11:01 197.2M  0 rom
>> 
>> The sda and sdb are Sun, sdc and sdd are GTP.
>> 
>> # uname -a
>> 
>> Linux deblnxsrv211 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017-
>> 10-15) sparc64 GNU/Linux
>> 
>> Thanks,
>> 
>> 
>> Frans van Berckel
>> 

Re: GRUB testers on SPARC needed

[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 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 on your particular
hardware, the older your machine, the better.
7. Report back to the list and include your hardware and partition
setup

Probing system devices
Probing memory
Probing I/O buses
screen not found.
keyboard not found.
Keyboard not present.  Using ttya for input and output.
Probing system devices
Probing memory
Probing I/O buses

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: disk  File and args:

GRUB Loading kernel...
screen not found.
error: out of memory.
error: no suitable video mode found.

GNU GRUB  version 2.02-2+sparc64.3

Loading Linux 4.13.0-1-sparc64-smp ...

# lsblk

NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda   8:00 136.7G  0 disk
├─sda18:10 902.1M  0 part  /boot
├─sda28:20 135.9G  0 part
│ └─md0   9:00 135.7G  0 raid1 /
└─sda38:30 136.7G  0 part
sdb   8:16   0 136.7G  0 disk
├─sdb18:17   0 902.1M  0 part
├─sdb28:18   0 135.9G  0 part
│ └─md0   9:00 135.7G  0 raid1 /
└─sdb38:19   0 136.7G  0 part
sdc   8:32   0  33.9G  0 disk
├─sdc18:33   030G  0 part
│ └─md1   9:1030G  0 raid1 /home
└─sdc28:34   0   3.9G  0 part  [SWAP]
sdd   8:48   0  33.9G  0 disk
├─sdd18:49   030G  0 part
│ └─md1   9:1030G  0 raid1 /home
└─sdd28:50   0   3.9G  0 part  [SWAP]
sr0  11:01 197.2M  0 rom

The sda and sdb are Sun, sdc and sdd are GTP.

# uname -a

Linux deblnxsrv211 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017-
10-15) sparc64 GNU/Linux

Thanks,


Frans van Berckel

Re: GRUB testers on SPARC needed

[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 address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9.
> > 
> > booting with command: boot
> > Boot device: disk  File and args:
> > 
> > GRUB Loading kernel...
> > screen not found.
> > error: out of memory.
> > error: no suitable video mode found.
> > 
> > GNU GRUB  version 2.02-2+sparc64.3
> > 
> > Loading Linux 4.13.0-1-sparc64-smp ...
> 
> So, I assume this means GRUB works as expected?
> 
> Do you get the normal boot menu? Does everything work?

Yes, yes and yes.

Thanks,


Frans van Berckel

Re: GRUB testers on SPARC needed

[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: disk  File and args:

GRUB Loading kernel...
screen not found.
error: out of memory.
error: no suitable video mode found.

GNU GRUB  version 2.02-2+sparc64.3

Loading Linux 4.13.0-1-sparc64-smp ...


So, I assume this means GRUB works as expected?

Do you get the normal boot menu? Does everything work?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GRUB testers on SPARC needed

[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 sure GRUB works on all machines supported by the
> sparc64 port, we need your help to test GRUB on your particular
> hardware, the older your machine, the better.

> 7. Report back to the list and include your hardware and partition
> setup

Probing system devices
Probing memory
Probing I/O buses
screen not found.
keyboard not found.
Keyboard not present.  Using ttya for input and output.
Probing system devices
Probing memory
Probing I/O buses

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: disk  File and args: 

GRUB Loading kernel...
screen not found.
error: out of memory.
error: no suitable video mode found.

GNU GRUB  version 2.02-2+sparc64.3

Loading Linux 4.13.0-1-sparc64-smp ...

# lsblk

NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda   8:00 136.7G  0 disk  
├─sda18:10 902.1M  0 part  /boot
├─sda28:20 135.9G  0 part  
│ └─md0   9:00 135.7G  0 raid1 /
└─sda38:30 136.7G  0 part  
sdb   8:16   0 136.7G  0 disk  
├─sdb18:17   0 902.1M  0 part  
├─sdb28:18   0 135.9G  0 part  
│ └─md0   9:00 135.7G  0 raid1 /
└─sdb38:19   0 136.7G  0 part  
sdc   8:32   0  33.9G  0 disk  
├─sdc18:33   030G  0 part  
│ └─md1   9:1030G  0 raid1 /home
└─sdc28:34   0   3.9G  0 part  [SWAP]
sdd   8:48   0  33.9G  0 disk  
├─sdd18:49   030G  0 part  
│ └─md1   9:1030G  0 raid1 /home
└─sdd28:50   0   3.9G  0 part  [SWAP]
sr0  11:01 197.2M  0 rom   

The sda and sdb are Sun, sdc and sdd are GTP. 

# uname -a

Linux deblnxsrv211 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017-
10-15) sparc64 GNU/Linux

Thanks,


Frans van Berckel

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

[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
> "random failure"[1] is quite hard to debug for somebody who is not
> familiar for the said architectures.

f4 is (long, long, long) -> long, and so the generated Qt metacall magic
wrapper around f4 treats its arguments as an array of long*,
dereferences them, passes them to f4 and stores the return value for the
caller.

However, camp's own Value class only has camp::intType; it has no type
for long or long long. This means that valueToVariant always gives a
QVariant storing an int, so QtFunction::execute invokes the meta method
with QGenericArgument's pointing to ints. Therefore, when the metacall
wrapper reads them, it reads too much, and gets 32 bits of garbage after
them in memory. Normally in C arguments are promoted automatically, but
because of all these levels of indirection it has to be done manually
(as you can see for example with the double tests, which must use the
double literal 1. rather than the int literal 1).

Now, as to why it only affects 64-bit big-endian. Obviously, 32-bit is
unaffected, as sizeof(int) == sizeof(long) there. On 64-bit
little-endian, reading too much data puts the garbage in the *higher*
bits in the registers; if you then add values with garbage in the higher
half, the lower half will remain correct, and it gets stored as a 64-bit
value. Then eventually it gets read as an int (variantType sees that the
function returns a QMetaType::Long, which is mapped to a return
QVariant::Int), so the higher 32 bits get dropped, and all appears fine
(despite the horrendous out-of-bounds memory accesses).

On 64-bit big-endian systems, though, it's not quite so forgiving. When
it reads the 32-bit value as a 64-bit value, the endianness means that
the 32 bits of garbage are the *lower* 32 bits in the registers, and so
when adding three numbers together, the sum of these garbage halves
could overflow (up to twice) into the higher 32 bits, which store the
desired values, causing the upper half to non-deterministically be 20,
21 or 22. This gets stored as a 64-bit quantity again, and then later
re-read as a 32-bit quantity, and again due to the endianness it only
reads what was the higher half in the register, i.e. either 20, 21 or
22.

I don't have a patch, because fixing this requires a fairly involved
trawl through the source. I haven't tried using it, but valgrind might
catch these out-of-bounds reads regardless of the system's endianness.

TL;DR camp needs to stop treating longs like ints.

Regards,
James

GRUB testers on SPARC needed

[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 on your particular hardware, the older
your machine, the better.

So, in order to help us, please follow the guide below to install GRUB to
replace SILO as your boot loader.

NOTE: If your system doesn't boot after installing GRUB, don't panic. Use
  the current Debian sparc64 installation image and boot into rescue
  mode by typing "rescue". Then chroot into your installed system and
  just run "silo -t -f" to restore SILO on your machine.

1. Install the grub2 package:

root@andi:~# apt install grub2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  grub-common grub-ieee1275 grub-ieee1275-bin grub2-common libfreetype6 
libfuse2 libpng16-16 os-prober
Suggested packages:
  multiboot-doc xorriso desktop-base console-setup fuse
The following NEW packages will be installed:
  grub-common grub-ieee1275 grub-ieee1275-bin grub2 grub2-common libfreetype6 
libfuse2 libpng16-16 os-prober
0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 4,556 kB of archives.
After this operation, 23.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.ports.debian.org/debian-ports unstable/main sparc64 
libpng16-16 sparc64 1.6.34-1 [271 kB]
(...)

Creating config file /etc/default/grub with new version
Setting up grub2 (2.02-2+sparc64.3) ...
root@andi:~#

2. Make sure you have version 2.02-2+sparc64.3

root@andi:~# apt-cache show grub2 |grep Version
Version: 2.02-2+sparc64.3
root@andi:~#

3. Find your boot partition:

root@andi:~# mount |grep /boot
/dev/sda1 on /boot type ext3 (rw,relatime,data=ordered)
root@andi:~#

If you don't have one but just one root file system, grep for " / " instead

4. Install grub into your boot partition:

root@andi:~# grub-install --force --skip-fs-probe /dev/sda1
Installing for sparc64-ieee1275 platform.
grub-install: warning: Discarding improperly nested partition 
(hostdisk//dev/sda,sun1,sun2).
grub-install: warning: Discarding improperly nested partition 
(hostdisk//dev/sda,sun1,sun4).
grub-install: warning: Attempting to install GRUB to a disk with multiple 
partition labels.  This is not supported yet..
grub-install: warning: Embedding is not possible.  GRUB can only be installed 
in this setup by using blocklists.  However, blocklists are UNRELIABLE and 
their use is discouraged..
Installation finished. No error reported.
root@andi:~#

Note: If you are using GPT partition tables instead of Sun partition
  tables, you need to install GRUB into /dev/sda
  (see: https://github.com/esnowberg/grub2-sparc/wiki)

5. Run update-grub:

root@andi:~# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.14.0-1-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-1-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-trunk-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-rc7-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-rc7-sparc64-smp
Found linux image: /boot/vmlinuz-4.14.0-rc5-sparc64-smp
Found initrd image: /boot/initrd.img-4.14.0-rc5-sparc64-smp
Found linux image: /boot/vmlinuz-4.12.0-rc1-sparc64-smp
Found initrd image: /boot/initrd.img-4.12.0-rc1-sparc64-smp
Found linux image: /boot/vmlinuz-4.11.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.11.0-trunk-sparc64-smp
Found linux image: /boot/vmlinuz-4.10.0-trunk-sparc64-smp
Found initrd image: /boot/initrd.img-4.10.0-trunk-sparc64-smp
Found Debian GNU/Linux buster/sid on /dev/md0p1
done
root@andi:~#

6. Reboot:

root@andi:~#

7. Report back to the list and include your hardware and partition setup

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[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 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 for the said architectures.
> 
> Kind regards
> 
>   Andreas.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876147#20
> 
> -- 
> http://fam-tille.de

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

[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 for the said architectures.

Kind regards

   Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876147#20

-- 
http://fam-tille.de