Re: Updated installation images for Debian Ports 2019-05-09

[James Clarke]

On 9 May 2019, at 20:31, Frank Scheiner  wrote:
> 
> Hi Adrian,
> 
> On 5/9/19 18:24, John Paul Adrian Glaubitz wrote:
>> I just uploaded updated installation images 2019-05-09 for the
>> following Debian Ports architectures:
>> [...]
>>  * sparc64
>> 
>> I uploaded both CD images [1] as well as netboot images [2].
>> 
>> Please test those images and report back over the mailing list for
>> the corresponding architecture.
>> 
>> Known issues:
>> [...]
>>  * sparc64
>>- Installation over a serial console is currently broken
>>  on sparc64 due to a bug in the rootskel package
>>  (can also be considered a kernel bug), see: #926539.
>>  Use any image before 2019-04-06 as workaround.
> 
> Looks like this doesn't affect sun4u machines, at least this ISO worked
> for my v245 using the serial console without any problems. Nice work! :-D

Yes; it's an issue with how Linux exposes sun4v hypervisor consoles.

James

Re: Any progress with grub-installer?

[James Clarke]

On 7 Jan 2019, at 20:47, John Paul Adrian Glaubitz 
 wrote:
> 
> Hi!
> 
> On 1/7/19 9:23 PM, Frank Scheiner wrote:
>>> Yes, but I know what I did. I‘m not sure why you are questioning that. Do 
>>> you see any unexpected results?
>> 
>> No, but from the `grub-install` output I didn't expect that the installation
>> worked and after comparing the versions of v1 and v2, I just wanted to be
>> sure about the details. I was not questioning what you did. :-)
> 
> Well, I was sure the installation didn't work either. But after rebooting, 
> the GRUB
> version in the boot menu was bumped. So the bootloader was most likely 
> rewritten.

Maybe. I wouldn't be surprised if sector 0 still has the old boot.img, but is
loading the newer kernel.img or whatever is the next stage from /boot. That
version number in the fancy boot menu almost certainly doesn't live in sector
0, 512 bytes (or 816 bytes) is really not very much at all.

James

Re: ZFS'ing my T5120 with Debian

[James Clarke]

On 26 May 2018, at 17:08, Chris Ross  wrote:
> On Fri, May 25, 2018 at 11:39:49PM +0200, John Paul Adrian Glaubitz wrote:
>> On 05/25/2018 09:38 PM, Chris Ross wrote:
>>> root@t5120:/var/tmp# grub-install /dev/sda
>>> Installing for sparc64-ieee1275 platform.
>>> grub-install: warning: this GPT partition label contains no BIOS Boot 
>>> Partition; embedding won't be possible.
>>> grub-install: error: filesystem `zfs' doesn't support blocklists.
>>> root@t5120:/var/tmp# 
>> 
>> That error message is quite clear: You have to set up a separate non-ZFS
>> partition which serves as a boot partition. Booting from a ZFS partition
>> using blocklists doesn't work.
> 
> Though, the conversation earlier covered that grub supports ZFS.  You say 
> above
> that booting from a ZFS partition using blocklists doesn't work.  There's
> something I'm not understanding in the space across those two statements.

I think the problem is that "grub supports ZFS" is a somewhat vague statement
with two possible interpretations:

1. Grub can be installed to a ZFS partition (i.e. the small stage 0, or 
whatever it
   is on SPARC, can locate the main grub binary when stored in a ZFS partition)

2. Grub can load kernels and initrds from a ZFS partition

Given the error message you have received, it seems that only the second of
these points is true, which is not that surprising. ZFS is a complicated file
system, and therefore likely requires a significant amount of code to parse,
which is not included in the initial loader. However, the main grub binary can
be fairly large, or even load additional modules, allowing it to include more
complicated features like ZFS support.

James

> FreeBSD has a zfsbootloader, which is what I've been using.  And, whether
> I can use ZFS or not, I don't think I want to start down the path of booting
> from magnetic media that isn't replicated onto another spindle.  If debian
> will let me boot from ZFS, how do I do it?  If it won't, are there other 
> options
> to boot from mirrored filesystems?
> 
>> Btw, I'm surprised to read that the T5120 supports GPT disk labels? I
>> thought that GPT is supported on T4 and newer only.
> 
> I believe the same, I don't know what that error message means.  I know that
> I do have sun labels, not GPT labels, on my disks.
> 
>  - Chris
> 

Re: ZFS'ing my T5120 with Debian

[James Clarke]

On 23 May 2018, at 18:48, Chris Ross  wrote:
> On Tue, May 22, 2018 at 10:56:49PM -0400, Chris Ross wrote:
>> Booting an installer may not work, though, since I need ZFS support in the
>> system I'm running.  To get a d-i with ZFS built in, I presume I'd have to
>> build my own.  Which I could, but don't know that I know how.  If I can use
>> something like debian-installer, I'd like to, but need one that can mount
>> up my ZFS filesystems.  Otherwise, I guess I need to find a guide of how to
>> do it the lower-level way.  ([1] looks valuable)
>> 
>> [1] https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS
> 
> Well, I tried running debootstrap, but I don't know how to point it somewhere
> for a ports installation.  I assume it should work, I just need the right
> URL to give it?  I tried all of:
> 
> sudo debootstrap sid /z
> sudo debootstrap sid /z http://ftp.ports.debian.org/debian-ports/
> sudo debootstrap sid /z http://ftp.ports.debian.org/debian-ports/pool-sparc64
> sudo debootstrap sid /z http://ftp.ports.debian.org/debian-ports/dists
> sudo debootstrap sid /z http://ftp.ports.debian.org/debian-ports/dists/sid
> 
> And it always fails the same way:
> 
> I: Target architecture can be executed
> I: Checking Release signature
> I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
> E: Invalid Release file, no entry for main/binary-sparc64/Packages

The second command should work. Do you have gunzip or unxz in your PATH? You
need one of them for debootstrap to let you use that Packages.?? file, and
there's no uncompressed version.

James

Re: ZFS'ing my T5120 with Debian

[James Clarke]

On 22 May 2018, at 20:40, Chris Ross  wrote:
> On Mon, May 21, 2018 at 01:54:36PM -0400, Chris Ross wrote:
>> I have a T5120 currently running on sdd, and want to install a fresh debian
>> on ZFS datasets on sda through sdc.  I want to install a fresh OS onto those
>> zvols.  How much of that process is built into just running the debian
>> installer, and how much will I need to manually set up?  I assume I need to
>> create the zfs volumes, which I'm comfortable doing. (First, does anyone know
>> if booting from RAIDZ works, or if I need to use ZFS mirror (as I did on
>> FreeBSD)?
>> 
>> After that is there a "install everything" process, or a set of steps I
>> need to take one at a time to install pieces, set up disks for booting, 
>> and/or
>> other things.
> 
>  Hello again.  Am hoping for answers to two questions:
> 
> 1) It it suspected that I can boot from a RAIDZ on sparc64? (Does zfs-linux
> and grub allow for that on any arch?)

In theory; raidz1/2/3 are listed in the GRUB manual[1], and later[2] has an 
example
FreeBSD ZFS menuentry. The Arch Wiki also has some information on ZFS[3] that 
may
prove useful.

> 2) What do I need to do after creating ZFS volumes to perform a base install
> onto those filesystems.  I have them all mounted onto an alt-root, is the next
> step getting/running debian-installer, or another "please install the whole 
> OS"
> process?

You might be able to boot d-i, skip partitioning and install to the root.
Alternatively you could install to a small ext4 partition and then copy it to 
the
ZFS volume(s). Otherwise you'll need to do a manual debootstrap and whatever 
other
required configuration steps d-i performs.

Regards,
James

[1] https://www.gnu.org/software/grub/manual/grub/grub.html#Features
[2] 
https://www.gnu.org/software/grub/manual/grub/grub.html#Multi_002dboot-manual-config
[3] https://wiki.archlinux.org/index.php/ZFS#GRUB-compatible_pool_creation

Re: Starting up Debian on a T5120

[James Clarke]

On 6 May 2018, at 04:15, Chris Ross <cross+deb...@distal.com> wrote:
> On Sat, May 05, 2018 at 01:35:06AM +0100, James Clarke wrote:
>> For building, I imagine the way to do it is:
>> 
>> 1. Add:
>>   deb [arch=all] http://deb.debian.org/debian unstable contrib non-free
>>   deb-src http://deb.debian.org/debian unstable main contrib non-free
>>   to your sources.list (or another mirror of your choice), so you can get the
>>   arch:all .debs from the main archive (note /debian rather than 
>> /debian-ports),
>>   as well as the sources. Also note that there's no "main" component listed 
>> for
>>   the first entry.
>> 
>> 2. apt update
>> 
>> 3. apt source zfs-linux
>> 
>> 4. apt build-dep zfs-linux
>> 
>> 5. cd zfs-linux-0.7.6
>> 
>> 6. dpkg-buildpackage -us -uc -B
>> 
>> You should then have all the sparc64 .debs in the parent directory which you 
>> can
>> install with "apt install /path/to/foo.deb".
> 
>  Thanks.  This worked, as you expected.  The question I have now is what to
> install.  I have 9 .deb files, but none of them is "zfs-dkms", which is one
> of the packages that zfsonlinux says to install:
> 
> https://github.com/zfsonlinux/zfs/wiki/Debian

zfs-initramfs, along with zfs-dkms and various other packages, are arch:all and
thus should be installable normally with apt if you added the sources entries
like I said.  It's only the userland tools and libraries that come as
arch-specific packages and therefore needed to be built by you.

>  I have:
> 
> -rw-r--r-- 1 cross   41444 May  5 22:50 libnvpair1linux_0.7.6-1_sparc64.deb
> -rw-r--r-- 1 cross   50680 May  5 22:50 libuutil1linux_0.7.6-1_sparc64.deb
> -rw-r--r-- 1 cross  119312 May  5 22:50 libzfs2linux_0.7.6-1_sparc64.deb
> -rw-r--r-- 1 cross  966516 May  5 22:51 libzfslinux-dev_0.7.6-1_sparc64.deb
> -rw-r--r-- 1 cross  460448 May  5 22:50 libzpool2linux_0.7.6-1_sparc64.deb
> -rw-r--r-- 1 cross 3580280 May  5 22:50 zfs-dbg_0.7.6-1_sparc64.deb
> -rw-r--r-- 1 cross 2481164 May  5 22:51 zfs-test_0.7.6-1_sparc64.deb
> -rw-r--r-- 1 cross  328128 May  5 22:50 zfsutils-linux_0.7.6-1_sparc64.deb
> -rw-r--r-- 1 cross   55252 May  5 22:50 zfs-zed_0.7.6-1_sparc64.deb
> 
>  Looking at the build logs I see some references to dkms, including:
> 
> checking for dkms.conf file... not found
> 
>  ...but I don't assume that indicates a problem.  I see it do:
> 
> make[1]: Entering directory '/home/cross/zfs-linux-0.7.6'
> dh_dkms -V 0.7.6
> make[1]: Leaving directory '/home/cross/zfs-linux-0.7.6'
> 
>  but with no other information, I don't know what happened (or didn't) there.

That looks normal; the i386 build log shows the same thing[0].

>> As far as booting goes, I have no idea. I'm almost certain you'd need to be 
>> using
>> grub not silo, but beyond that your prior experience likely means you know 
>> more
>> than me. Generating installer images is awkward, so it may just be easiest 
>> to clone
>> your system to a new ZFS volume, boot to that and then reclaim the ext4 
>> space.
>> Perhaps there's a better way that someone here knows?
> 
>  It looks like I had the same thought.  I realize now I'm running on sdd, and
> sda sdb and sdc are waiting for me to do something useful with them. So at 
> least
> I don't need to figure out the installer stuff.  I will still need to figure
> out how to boot, which the above debian page suggests I want zfs-initramfs
> package.  But I doubt that alone is enough.  And, I don't know much about
> grub vs silo vs anything else that Linux uses to boot.

Do you know which you're using? I believe switching to grub is as simple as:

1. apt install grub2
2. grub-install --skip-fs-probe --force /dev/sdX

though it's been a while since I had to deal with that process.

>  Hopefully someone else has some more pointers for me at this point.  Thank
> you much for these!

James

[0] 
https://buildd.debian.org/status/fetch.php?pkg=zfs-linux=i386=0.7.6-1=1519978073=0

Re: Starting up Debian on a T5120

[James Clarke]

On 4 May 2018, at 20:34, Chris Ross  wrote:
> On Fri, May 04, 2018 at 07:14:16PM +0200, John Paul Adrian Glaubitz wrote:
>> The problem here, again, is that sparc64 is part of Debian Ports which
>> doesn't build any packages from the "contrib" and "non-free" distributions.
> 
>  Ahh.  So the zfs-dkms is contrib or non-free, so doesn't get built?  Okay.
> There will probably be a number of other things that will fall into that,
> what's a good way to know if something is not available for that reason?

Probably to search for it on packages.debian.org and see if it says
"contrib" or "non-free".

>> I think this is an issue we can get resolved once we have replaced "mini-DAK"
>> with "DAK" in Debian Ports (the software that maintains the FTP server
>> archive contents). But that's a long-time project.
> 
>  Okay.  And one that I don't have the context to understand, but don't need
> to for now.

The details really don't matter, other than that mini-DAK is an
extremely-simplified implementation of parts of DAK and thus lacks useful
features.

>> Just apt update && apt upgrade && apt dist-upgrade should be enough.
>> 
>> Let us know if there are any issues with the dist-upgrade.
> 
>  Doing that now.  360+ packages being upgraded...
> 
>  It failed to update initramfs-tools, because it ran out of space in my /boot.
> I ran autoremove (getting rid of 4.14.0-3) and it was able to complete.
> 
>  Then, apt dist-upgrade found nothing to do.  So, I'm up to date.  Do you have
> a pointer to a guide of how to build the ZFS kernel modules, and what will 
> need
> to be done to get it into the boot system so I can boot off of a ZFS vol?
> (presumably a zmirror, which is how I've been doing it on other systems)
> Then, do I need to generate a new install CD so that I can get that all
> installed onto the disks that now have ext volumnes on them?

For building, I imagine the way to do it is:

1. Add:
   deb [arch=all] http://deb.debian.org/debian unstable contrib non-free
   deb-src http://deb.debian.org/debian unstable main contrib non-free
   to your sources.list (or another mirror of your choice), so you can get the
   arch:all .debs from the main archive (note /debian rather than 
/debian-ports),
   as well as the sources. Also note that there's no "main" component listed for
   the first entry.

2. apt update

3. apt source zfs-linux

4. apt build-dep zfs-linux

5. cd zfs-linux-0.7.6

6. dpkg-buildpackage -us -uc -B

You should then have all the sparc64 .debs in the parent directory which you can
install with "apt install /path/to/foo.deb".

As far as booting goes, I have no idea. I'm almost certain you'd need to be 
using
grub not silo, but beyond that your prior experience likely means you know more
than me. Generating installer images is awkward, so it may just be easiest to 
clone
your system to a new ZFS volume, boot to that and then reclaim the ext4 space.
Perhaps there's a better way that someone here knows?

James

Re: Bug#887494: mozjs52: FTBFS on sparc64: interpreter segfaults

[James Clarke]

On Tue, Apr 24, 2018 at 08:52:58PM +0200, John Paul Adrian Glaubitz wrote:
> On 01/17/2018 01:43 PM, John Paul Adrian Glaubitz wrote:
> > I can whip up a patch for mozjs52 to add sparc64 support if there is
> > a realistic chance for it to be merged. My m68k [3] and sh4 [4] patches for
> > mozjs52 are still without any reply, for example.
>
> Attaching said patch. I hope to get around sending a pull request on Salsa
> the next days.
>
> The patches should be applied in this order:
>
> - sh4-support.patch (#880692)
> - m68k-support.patch (#880693)
> - sparc64-support.patch (this bug report)
>
> I'll also send a clean one for alpha and ia64 (#887496).
>
> 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

> Description: Add support for sparc64
> Author: John Paul Adrian Glaubitz 
> Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
> Last-Update: 2017-06-18
>
> Index: firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
> ===
> --- firefox-esr-52.2.0esr.orig/js/src/gc/Memory.cpp
> +++ firefox-esr-52.2.0esr/js/src/gc/Memory.cpp
> @@ -501,7 +501,7 @@ static inline void*
>  MapMemoryAt(void* desired, size_t length, int prot = PROT_READ | PROT_WRITE,
>  int flags = MAP_PRIVATE | MAP_ANON, int fd = -1, off_t offset = 
> 0)
>  {
> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || 
> defined(__aarch64__)
> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && 
> (defined(__NetBSD__) || defined(__linux__)))

I don't think you meant to drop the __aarch64__ here (the real commit
upstream keeps it).

>  MOZ_ASSERT((0x8000ULL & (uintptr_t(desired) + length - 1)) 
> == 0);
>  #endif
> [...]
> Index: firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
> ===
> --- firefox-esr-52.2.0esr.orig/js/src/jsapi-tests/testGCAllocator.cpp
> +++ firefox-esr-52.2.0esr/js/src/jsapi-tests/testGCAllocator.cpp
> @@ -312,7 +312,7 @@ void unmapPages(void* p, size_t size) {
>  void*
>  mapMemoryAt(void* desired, size_t length)
>  {
> -#if defined(__ia64__) || (defined(__sparc64__) && defined(__NetBSD__)) || 
> defined(__aarch64__)
> +#if defined(__ia64__) || (defined(__sparc__) && defined(__arch64__) && 
> (defined(__NetBSD__) || defined(__linux__)))

Ditto.

>  MOZ_RELEASE_ASSERT(0x8000ULL & (uintptr_t(desired) + length 
> - 1) == 0);
>  #endif
> [...]

James

Re: [sparc64] possible to install older binutils on sakharov.debian.net

[James Clarke]

On 12 Mar 2018, at 20:18, Sebastian Andrzej Siewior <sebast...@breakpoint.cc> 
wrote:
> On 2018-03-11 22:50:16 [+0000], James Clarke wrote:
>> You can either add the directory to your PATH, or pass -B/path/goes/here. The
>> search order is prefixes (-B), then /usr{,/local}/lib/gcc, then PATH. Note 
>> that
>> ld is dynamically linked to libbfd-2.X-system.so so you'll need to modify 
>> your
>> LD_LIBRARY_PATH.
> 
> Thanks for hint. I was under impression that the LD path was hardcoded.
> Anyway. As I wrote in [0] binutils 2.30-4 works, 2.30-5 does not. Is
> this sparc porter material?
> 
> [0] https://github.com/openssl/openssl/issues/5586#issuecomment-372447324

Thanks, finally managed to reproduce the bug; it's reliant on link order.

I will follow up on the GitHub issue and file a bug against ld upstream.

James

Re: IP auto-config with DHCP on sparc64 possibly broken

[James Clarke]

On 18 Feb 2018, at 21:34, John Paul Adrian Glaubitz 
 wrote:
> On 02/18/2018 10:10 PM, John Paul Adrian Glaubitz wrote:
>> See my emphasis above. It's not that the network stack is broken, it's just 
>> that
>> the tool you are using is apparently producing unaligned accesses.
>> 
>> Did you try running systemd-networkd?
> 
> As a quick shot into the dark, I have triggered a binNMU of src:klibc, maybe
> it was broken by binutils which recently suffered from issues on sparc64.

Which will (or should) be rejected by mini-dak, as my 2.0.4-11+sparc64.1 is in
unreleased (#885852 hasn't been fixed yet or even acknowledged by anyone). I'd
be surprised if it's the binutils bug, but I guess you could do a rebuild
locally and upload a .2 to unreleased. Having said that if there are unaligned
accesses reported on alpha then those are likely to also happen on sparc64 and
be the critters we're looking for.

James

Re: Bug#889147: abyss: PairedDBG_LoadAlgorithm test fails on sparc64 due to strict alignment violation

[James Clarke]

On 2 Feb 2018, at 15:49, David Matthew Mattli <d...@mattli.us> wrote:
> 
> James Clarke <jrt...@debian.org> writes:
> 
>> user debian-sparc@lists.debian.org
>> usertags sparc64
>> thanks
>> 
>> (You missed the User: pseudoheader)
>> 
>>> On 2 Feb 2018, at 14:46, David Matthew Mattli <d...@mattli.us> wrote:
>>> 
>>> Package: abyss
>>> Severity: normal
>>> Tags: patch upstream
>>> Usertags: sparc64
>>> 
>>> Dear Maintainer,
>>> 
>>> This package currently FTBFS on sparc64 due to the
>>> PairedDBG_LoadAlgorithm test failing with a SIGBUS. The Kmer.load and
>>> Kmer.storeReverse methods in the Common/Kmer.cpp file cast a uint8_t*
>>> to a size_t* without ensuring the pointer value has the proper
>>> alignment.
>>> 
>>> To fix this I added an aligned stack allocated buffer and memcpy to
>>> that. Stack allocated is appropriate because the buffer size is
>>> small(32 bytes) and known at compile time.
>> 
>> Hi,
>> As a sparc64 porter, thanks for fixing packages! Just a couple of
>> comments on the patch.
>> 
>>> --- a/Common/Kmer.cpp
>>> +++ b/Common/Kmer.cpp
>>> @@ -188,9 +188,10 @@
>>> Seq seq;
>>> #if MAX_KMER > 96
>>> # if WORDS_BIGENDIAN
>>> -   const size_t *s = reinterpret_cast(src);
>>> +   size_t buf[Kmer::NUM_BYTES];
>> 
>> Should be divided by sizeof(size_t). Also, why not call it s? That should
>> reduce the number of changes.
>> 
>>> +   memcpy(buf, src, Kmer::NUM_BYTES);
>>> size_t *d = reinterpret_cast<size_t*>( + 1);
>>> -   copy(s, s + Kmer::NUM_BYTES/sizeof(size_t), 
>>> reverse_iterator<size_t*>(d));
>>> +   copy(buf, buf + Kmer::NUM_BYTES/sizeof(size_t), 
>>> reverse_iterator<size_t*>(d));
>>> # else
>>> uint8_t *d = reinterpret_cast<uint8_t*>();
>>> memcpy(d, src, sizeof seq);
>>> @@ -235,9 +236,10 @@
>>> #if MAX_KMER > 96
>>> # if WORDS_BIGENDIAN
>>> const size_t *s = reinterpret_cast();
>>> -   size_t *d = reinterpret_cast<size_t*>(dest);
>>> +   size_t d[Kmer::NUM_BYTES];
>> 
>> Ditto for the size (this time you used the same name as before).
>> 
>>> copy(s, s + Kmer::NUM_BYTES/sizeof(size_t),
>>> reverse_iterator<size_t*>(d +  
>>> Kmer::NUM_BYTES/sizeof(size_t)));
>>> +   memcpy(dest, d, Kmer::NUM_BYTES);
>>> reverse(dest, dest + Kmer::NUM_BYTES);
>>> # else
>>> memcpy(dest, , Kmer::NUM_BYTES);
>> 
>> Regards,
>> James
> 
> Thanks for the quick feedback! How does this revised patch look?

Looks sensible as a non-maintainer. Let's wait for a debian-med person to
review (technically I have commit rights, but I know nothing about this
package).

James

Re: Bug#889147: abyss: PairedDBG_LoadAlgorithm test fails on sparc64 due to strict alignment violation

[James Clarke]

user debian-sparc@lists.debian.org
usertags sparc64
thanks

(You missed the User: pseudoheader)

> On 2 Feb 2018, at 14:46, David Matthew Mattli  wrote:
> 
> Package: abyss
> Severity: normal
> Tags: patch upstream
> Usertags: sparc64
> 
> Dear Maintainer,
> 
> This package currently FTBFS on sparc64 due to the
> PairedDBG_LoadAlgorithm test failing with a SIGBUS. The Kmer.load and
> Kmer.storeReverse methods in the Common/Kmer.cpp file cast a uint8_t*
> to a size_t* without ensuring the pointer value has the proper
> alignment.
> 
> To fix this I added an aligned stack allocated buffer and memcpy to
> that. Stack allocated is appropriate because the buffer size is
> small(32 bytes) and known at compile time.

Hi,
As a sparc64 porter, thanks for fixing packages! Just a couple of
comments on the patch.

> --- a/Common/Kmer.cpp
> +++ b/Common/Kmer.cpp
> @@ -188,9 +188,10 @@
>   Seq seq;
>  #if MAX_KMER > 96
>  # if WORDS_BIGENDIAN
> - const size_t *s = reinterpret_cast(src);
> + size_t buf[Kmer::NUM_BYTES];

Should be divided by sizeof(size_t). Also, why not call it s? That should
reduce the number of changes.

> + memcpy(buf, src, Kmer::NUM_BYTES);
>   size_t *d = reinterpret_cast( + 1);
> - copy(s, s + Kmer::NUM_BYTES/sizeof(size_t), 
> reverse_iterator(d));
> + copy(buf, buf + Kmer::NUM_BYTES/sizeof(size_t), 
> reverse_iterator(d));
>  # else
>   uint8_t *d = reinterpret_cast();
>   memcpy(d, src, sizeof seq);
> @@ -235,9 +236,10 @@
>  #if MAX_KMER > 96
>  # if WORDS_BIGENDIAN
>   const size_t *s = reinterpret_cast();
> - size_t *d = reinterpret_cast(dest);
> + size_t d[Kmer::NUM_BYTES];

Ditto for the size (this time you used the same name as before).

>   copy(s, s + Kmer::NUM_BYTES/sizeof(size_t),
>   reverse_iterator(d +  
> Kmer::NUM_BYTES/sizeof(size_t)));
> + memcpy(dest, d, Kmer::NUM_BYTES);
>   reverse(dest, dest + Kmer::NUM_BYTES);
>  # else
>   memcpy(dest, , Kmer::NUM_BYTES);

Regards,
James

Re: The end of my Ultrasparc 5?!?

[James Clarke]

On 26 Jan 2018, at 00:10, Sean Whitney <sean.whit...@gmail.com> wrote:
> On 01/25/2018 04:03 PM, James Clarke wrote:
>> On 25 Jan 2018, at 23:58, Sean Whitney <sean.whit...@gmail.com> wrote:
>>> 
>>> I recently switched from sparc to sparc64 using the cdrom drive in 
>>> September.  Sometime in the last two weeks the server rebooted and when it 
>>> tried to restart it hung trying to find a btrfs filesystem, which I don't 
>>> have.  This seems to be a problem for PCs, but it resolves itself in 15 
>>> seconds, and is an annoyance, while my hangs indefinately.  The solution is 
>>> to remove the btrfs packages installed on your system.  But I can't do this 
>>> because I can't get it complete a boot to get a prompt. Both aliases silo 
>>> images seem to have the same btrfs packages included. I'm not sure when the 
>>> btrfs packages were installed, not knowing it was an issue, I guess I 
>>> allowed them to be installed with updates.
>>> 
>>> Here is the rub, I can't seem to boot from the cdrom anymore. When I do I 
>>> get the following error.
>>> 
>>> Rebooting with command: boot cdrom
>>> Boot device: /pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f  File and args:
>>> Can't read disk label.
>>> Can't open disk label package
>>> Evaluating: boot cdrom
>>> 
>>> Can't open boot device
>>> 
>>> 
>>> I can't boot with the net because the net install image for debian hasn't 
>>> worked for ultra 5's since lenny.
>>> 
>>> Right now I've turned off the Ultra 5 for the next 12 hours to see if it 
>>> makes any difference with the CDROM.
>>> 
>>> If anyone has any other suggestions as to any sort of recovery I'm all 
>>> ears, otherwise I guess it's time to go to recycle.
>>> 
>>> Thanks in advance,
>> No idea what's causing all your issues, unfortunately. Have you tried booting
>> with "linux init=/bin/bash" or similar? What exact error are you getting?
>> Regards,
>> James
> 
> yes, I've tried passing in init=/bin/bash but, it still trys to process the 
> btrfs filesystem before a prompt is available.
> 
> The boot process hangs here:
> 
> [   44.070355] raid6: int64x1  xor()43 MB/s
> [   44.190108] raid6: int64x2  gen()   125 MB/s
> [   44.310194] raid6: int64x2  xor()62 MB/s
> [   44.429980] raid6: int64x4  gen()   151 MB/s
> [   44.550073] raid6: int64x4  xor()80 MB/s
> [   44.669932] raid6: int64x8  gen()   133 MB/s
> [   44.790009] raid6: int64x8  xor()84 MB/s
> [   44.844728] raid6: using algorithm int64x4 gen() 151 MB/s
> [   44.912879] raid6:  xor() 80 MB/s, rmw enabled
> [   44.973689] raid6: using intx1 recovery algorithm
> [   45.101360] xor: automatically using best checksumming function   VIS 
> [   45.208607] crc32c_sparc64: sparc64 crc32c opcode not available.
> [   45.456022] Btrfs loaded, crc32c=crc32c-generic
> Scanning for Btrfs filesystems
> 
> 
> It' will stay like this for days
> 
> Actually looking back through my backups, I reinstalled sparc64 in March 
> 2017, and the btrfs packages are included in the next backup.  These have 
> been installed all along, but the timeout behavior must have changed at some 
> point.

Interesting. You should be able to stop it loading by adding
modprobe.blacklist=btrfs to the kernel command line.

James

Re: The end of my Ultrasparc 5?!?

[James Clarke]

On 25 Jan 2018, at 23:58, Sean Whitney  wrote:
> 
> I recently switched from sparc to sparc64 using the cdrom drive in September. 
>  Sometime in the last two weeks the server rebooted and when it tried to 
> restart it hung trying to find a btrfs filesystem, which I don't have.  This 
> seems to be a problem for PCs, but it resolves itself in 15 seconds, and is 
> an annoyance, while my hangs indefinately.  The solution is to remove the 
> btrfs packages installed on your system.  But I can't do this because I can't 
> get it complete a boot to get a prompt. Both aliases silo images seem to have 
> the same btrfs packages included. I'm not sure when the btrfs packages were 
> installed, not knowing it was an issue, I guess I allowed them to be 
> installed with updates.
> 
> Here is the rub, I can't seem to boot from the cdrom anymore. When I do I get 
> the following error.
> 
> Rebooting with command: boot cdrom
> Boot device: /pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f  File and args:
> Can't read disk label.
> Can't open disk label package
> Evaluating: boot cdrom
> 
> Can't open boot device
> 
> 
> I can't boot with the net because the net install image for debian hasn't 
> worked for ultra 5's since lenny.
> 
> Right now I've turned off the Ultra 5 for the next 12 hours to see if it 
> makes any difference with the CDROM.
> 
> If anyone has any other suggestions as to any sort of recovery I'm all ears, 
> otherwise I guess it's time to go to recycle.
> 
> Thanks in advance,

No idea what's causing all your issues, unfortunately. Have you tried booting
with "linux init=/bin/bash" or similar? What exact error are you getting?

Regards,
James

Re: Packages libklibc and klibc-utils missing for sparc64 on p.d.o

[James Clarke]

On 13 Jan 2018, at 16:10, Frank Scheiner  wrote:
> 
> Hi all,
> 
> I today wanted to check if a new libklibc package is available for sparc64 
> that includes the fixes by James. I'd like to get my SPARC machines into a 
> working state again. :-)
> 
> But unfortunately the libklibc and klibc-utils packages are no longer 
> available for sparc64 as per packages.debian.org (see for example [1]). I 
> believe I saw them around 2017-12-31, as I upgraded them on my Ultra 80 on 
> that date, but maybe I'm mistaken.
> 
> [1]: https://packages.debian.org/sid/libklibc
> 
> As [1] also lists the corresponding packages for the unofficial ports alpha, 
> hppa, ppc64 and others I wonder why sparc64 should be missing there. [2] 
> lists only sparc and not sparc64 but that file wasn't changed recently IIUC. 
> Hence I wonder why the packages were listed end of December 2017 but are gone 
> now.
> 
> [2]: https://anonscm.debian.org/cgit/kernel/klibc.git/tree/debian/rules
> 
> UPDATE: After checking the download path of the libklibc package for ppc64 
> and adapting it to sparc64 I was able to find the packages (on [3]), but 
> still, shouldn't the klibc packages not also be listed on packages.debian.org?
> 
> [3]: http://ftp.ports.debian.org/debian-ports/pool-sparc64/main/k/klibc/

Due to [0], I uploaded a fixed version of src:klibc for sparc64 to unreleased,
which doesn't show up on packages.debian.org, and removes the lower version
from unstable at the same time.

James

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885852

[PATCH] [klibc] Fix sparc assembly when compiled as PIC

[James Clarke]

Some distributions default to PIE for their compilers, which on sparc is passed
on to the assembler. Since the behaviour of %hi/%lo changes under PIC to become
GOT offsets, the current assembly files need adapting to not try to use a GOT
offset as an absolute address.
---
 usr/include/arch/sparc/machine/asm.h | 15 +--
 usr/include/arch/sparc64/machine/asm.h   |  1 +
 usr/include/arch/sparc64/machine/frame.h |  1 +
 usr/klibc/arch/sparc/pipe.S  |  6 +++---
 usr/klibc/arch/sparc/syscall.S   |  6 --
 usr/klibc/arch/sparc/sysfork.S   |  6 --
 usr/klibc/arch/sparc64/pipe.S|  6 +++---
 usr/klibc/arch/sparc64/syscall.S |  6 --
 usr/klibc/arch/sparc64/sysfork.S |  6 --
 9 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/usr/include/arch/sparc/machine/asm.h 
b/usr/include/arch/sparc/machine/asm.h
index 04fe9b1b..fd9ef1ef 100644
--- a/usr/include/arch/sparc/machine/asm.h
+++ b/usr/include/arch/sparc/machine/asm.h
@@ -61,7 +61,7 @@
 #endif
 #define_ASM_LABEL(name)name
 
-#ifdef PIC
+#ifdef __PIC__
 /*
  * PIC_PROLOGUE() is akin to the compiler generated function prologue for
  * PIC code. It leaves the address of the Global Offset Table in DEST,
@@ -83,12 +83,20 @@
 0: \
add dest,%o7,dest; \
mov tmp, %o7
+#define SET(var,base,dest) \
+   sethi %gdop_hix22(var), dest; \
+   xor dest, %gdop_lox10(var), dest; \
+   ldx [base + dest], dest, %gdop(var)
 #else
 #define PIC_PROLOGUE(dest,tmp) \
mov %o7,tmp; 3: call 4f; nop; 4: \
sethi %hi(_C_LABEL(_GLOBAL_OFFSET_TABLE_)-(3b-.)),dest; \
or dest,%lo(_C_LABEL(_GLOBAL_OFFSET_TABLE_)-(3b-.)),dest; \
add dest,%o7,dest; mov tmp,%o7
+#define SET(var,base,dest) \
+   sethi %gdop_hix22(var), dest; \
+   xor dest, %gdop_lox10(var), dest; \
+   ld [base + dest], dest, %gdop(var)
 #endif
 
 /*
@@ -106,7 +114,10 @@
 #endif
 #else
 #define PIC_PROLOGUE(dest,tmp)
-#define PICCY_OFFSET(var,dest,tmp)
+#define SET(var,base,dest) \
+   sethi %hi(var), dest; \
+   or dest, %lo(var), dest
+#define PICCY_SET(var,dest,tmp) SET(var,tmp,dest)
 #endif
 
 #define FTYPE(x)   .type x,@function
diff --git a/usr/include/arch/sparc64/machine/asm.h 
b/usr/include/arch/sparc64/machine/asm.h
new file mode 100644
index ..394ba865
--- /dev/null
+++ b/usr/include/arch/sparc64/machine/asm.h
@@ -0,0 +1 @@
+#include "../../sparc/machine/asm.h"
diff --git a/usr/include/arch/sparc64/machine/frame.h 
b/usr/include/arch/sparc64/machine/frame.h
new file mode 100644
index ..79beea6d
--- /dev/null
+++ b/usr/include/arch/sparc64/machine/frame.h
@@ -0,0 +1 @@
+#include "../../sparc/machine/frame.h"
diff --git a/usr/klibc/arch/sparc/pipe.S b/usr/klibc/arch/sparc/pipe.S
index a8abf3c3..7ff09074 100644
--- a/usr/klibc/arch/sparc/pipe.S
+++ b/usr/klibc/arch/sparc/pipe.S
@@ -5,6 +5,7 @@
  * they return the two file descriptors in %o0 and %o1.
  */
 
+#include 
 #include 
 
.globl  pipe
@@ -15,9 +16,8 @@ pipe:
or  %o0, 0, %g4
t   0x10
bcc 1f
- nop
-   sethi   %hi(errno), %g4
-   or  %g4, %lo(errno), %g4
+ PIC_PROLOGUE(%g1,%g4)
+   SET(errno,%g1,%g4)
st  %o0,[%g4]
retl
  mov   -1, %o0
diff --git a/usr/klibc/arch/sparc/syscall.S b/usr/klibc/arch/sparc/syscall.S
index c0273f77..52a8583b 100644
--- a/usr/klibc/arch/sparc/syscall.S
+++ b/usr/klibc/arch/sparc/syscall.S
@@ -4,14 +4,16 @@
  * Common system-call stub; %g1 already set to syscall number
  */
 
+#include 
+
.globl  __syscall_common
.type   __syscall_common,#function
.align  4
 __syscall_common:
t   0x10
bcc 1f
- sethi %hi(errno), %g4
-   or  %g4, %lo(errno), %g4
+ PIC_PROLOGUE(%g1,%g4)
+   SET(errno,%g1,%g4)
st  %o0,[%g4]
mov -1, %o0
 1:
diff --git a/usr/klibc/arch/sparc/sysfork.S b/usr/klibc/arch/sparc/sysfork.S
index a66c76e9..3787b944 100644
--- a/usr/klibc/arch/sparc/sysfork.S
+++ b/usr/klibc/arch/sparc/sysfork.S
@@ -8,6 +8,8 @@
  * Common system-call stub; %g1 already set to syscall number
  */
 
+#include 
+
.globl  __syscall_forkish
.type   __syscall_forkish,#function
.align  4
@@ -16,8 +18,8 @@ __syscall_forkish:
sub %o1, 1, %o1
bcc,a   1f
  and   %o0, %o1, %o0
-   sethi   %hi(errno), %g4
-   or  %g4, %lo(errno), %g4
+   PIC_PROLOGUE(%g1,%g4)
+   SET(errno,%g1,%g4)
st  %o0,[%g4]
mov -1, %o0
 1:
diff --git a/usr/klibc/arch/sparc64/pipe.S b/usr/klibc/arch/sparc64/pipe.S
index c63b20f7..cedc6402 100644
--- a/usr/klibc/arch/sparc64/pipe.S
+++ b/usr/klibc/arch/sparc64/pipe.S
@@ -5,6 +5,7 @@
  * they return the two file descriptors in %o0 and %o1.
  */
 
+#include 
 #include 
 
.globl  pipe
@@ -15,9 +16,8 @@ pipe:
or  

Bug#884642: libgo11: Please backport upstream sparc64 fix

[James Clarke]

Package: libgo11
Version: 7.2.0-17
Tags: upstream fixed-upstream patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,
For a while, libgo11 on sparc64 has been broken, with executables
crashing with messages like:

> runtime: lfstackpush invalid packing: node=0xfff8000102424000 cnt=1 
> packed=283958541549569 -> node=0x102424000

whenever runtime_gc is called. This is because lfstack_64bit.go has
incorrect assumptions about the virtual address space, and so clobbers
the node address when packing. Please apply the attached debdiff, which
is a backport of the upstream fix (the change to gcc/go/gofrontend/MERGE
has been dropped as it's needless noise that is likely to just cause
conflicts). In my testing it completely fixes that error with no traces
of it in the build log.

Regards,
James
diff -u gcc-7-7.2.0/debian/rules.patch gcc-7-7.2.0/debian/rules.patch
--- gcc-7-7.2.0/debian/rules.patch
+++ gcc-7-7.2.0/debian/rules.patch
@@ -75,6 +75,7 @@
pr77631 \
pr67165 \
cuda-float128 \
+   libgo-sparc64 \
libgo-ia64 \
pr82880 \
libcc1-compiler-name \
only in patch2:
unchanged:
--- gcc-7-7.2.0.orig/debian/patches/libgo-sparc64.diff
+++ gcc-7-7.2.0/debian/patches/libgo-sparc64.diff
@@ -0,0 +1,99 @@
+From c536feb42f56afd6397697f9ee9e5d8d918bef1b Mon Sep 17 00:00:00 2001
+From: ian 
+Date: Wed, 31 May 2017 21:36:42 +
+Subject: [PATCH] libgo: support for sparc64 GNU/Linux
+
+Fix lfstack code to work with sparc64 GNU/Linux address map.
+
+Force alignment of epollevent.  To make this work reliably, pass
+GOARCH explicitly to mkrsysinfo.sh.
+
+Patch by Vladimir Mezentsev.
+
+Reviewed-on: https://go-review.googlesource.com/44494
+
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248765 
138bc75d-0d04-0410-961f-82ee72b054a4
+---
+[gcc/go/gofrontend/MERGE   |  2 +-]
+ libgo/Makefile.am |  2 +-
+ libgo/Makefile.in |  2 +-
+ libgo/go/runtime/lfstack_64bit.go | 12 
+ libgo/mkrsysinfo.sh   |  6 +-
+ 5 files changed, 20 insertions(+), 4 deletions(-)
+
+diff --git a/src/libgo/Makefile.am b/src/libgo/Makefile.am
+index 8bbd43771447..0f9881ffaa4e 100644
+--- a/src/libgo/Makefile.am
 b/src/libgo/Makefile.am
+@@ -531,7 +531,7 @@ s-version: Makefile
+ 
+ runtime_sysinfo.go: s-runtime_sysinfo; @true
+ s-runtime_sysinfo: $(srcdir)/mkrsysinfo.sh gen-sysinfo.go
+-  $(SHELL) $(srcdir)/mkrsysinfo.sh
++  GOARCH=$(GOARCH) GOOS=$(GOOS) $(SHELL) $(srcdir)/mkrsysinfo.sh
+   $(SHELL) $(srcdir)/mvifdiff.sh tmp-runtime_sysinfo.go runtime_sysinfo.go
+   $(STAMP) $@
+ 
+diff --git a/src/libgo/Makefile.in b/src/libgo/Makefile.in
+index cbdd37998369..2452f967252b 100644
+--- a/src/libgo/Makefile.in
 b/src/libgo/Makefile.in
+@@ -3081,7 +3081,7 @@ s-version: Makefile
+ 
+ runtime_sysinfo.go: s-runtime_sysinfo; @true
+ s-runtime_sysinfo: $(srcdir)/mkrsysinfo.sh gen-sysinfo.go
+-  $(SHELL) $(srcdir)/mkrsysinfo.sh
++  GOARCH=$(GOARCH) GOOS=$(GOOS) $(SHELL) $(srcdir)/mkrsysinfo.sh
+   $(SHELL) $(srcdir)/mvifdiff.sh tmp-runtime_sysinfo.go runtime_sysinfo.go
+   $(STAMP) $@
+ 
+diff --git a/src/libgo/go/runtime/lfstack_64bit.go 
b/src/libgo/go/runtime/lfstack_64bit.go
+index 213efb107068..b314a3ba2169 100644
+--- a/src/libgo/go/runtime/lfstack_64bit.go
 b/src/libgo/go/runtime/lfstack_64bit.go
+@@ -32,9 +32,18 @@ const (
+   // bottom, because node must be pointer-aligned, giving a total of 19 
bits
+   // of count.
+   cntBits = 64 - addrBits + 3
++
++  // On sparc64-linux, user addresses are 52-bit numbers sign extended to 
64.
++  // We shift the address left 12 to eliminate the sign extended part and 
make
++  // room in the bottom for the count.
++  sparcLinuxAddrBits = 52
++  sparcLinuxCntBits  = 64 - sparcLinuxAddrBits + 3
+ )
+ 
+ func lfstackPack(node *lfnode, cnt uintptr) uint64 {
++  if GOARCH == "sparc64" && GOOS == "linux" {
++  return 
uint64(uintptr(unsafe.Pointer(node)))<<(64-sparcLinuxAddrBits) | 
uint64(cnt&(1<> cntBits 
<< 3)))
+   }
++  if GOARCH == "sparc64" && GOOS == "linux" {
++  return (*lfnode)(unsafe.Pointer(uintptr(int64(val) >> 
sparcLinuxCntBits << 3)))
++  }
+   return (*lfnode)(unsafe.Pointer(uintptr(val >> cntBits << 3)))
+ }
+diff --git a/src/libgo/mkrsysinfo.sh b/src/libgo/mkrsysinfo.sh
+index a86e9143bf46..6ab80e625d93 100755
+--- a/src/libgo/mkrsysinfo.sh
 b/src/libgo/mkrsysinfo.sh
+@@ -83,7 +83,11 @@ if grep '^const _epoll_data_offset ' ${OUT} >/dev/null 
2>&1; 

Re: Test atomic operations on SPARC 32-bit

[James Clarke]

On 10 Dec 2017, at 10:01, Romain Dolbeau  wrote:
> 2017-12-10 2:19 GMT+01:00 Petr Vorel :
>> I test it (in my github fork of) LTP project [1], but unfortunately some 
>> tests which heavy
>> test it fails.
> 
> With a large number of threads, the test-and-test-and-set option will
> significantly
> cut down the coherency traffic between caches. It's a much better solution 
> than
> a pure test-and-test.
> 
>> The tests just get slightly fewer incrementation than it should get (6373821 
>> instead of 640).
>> 
>> The implementation in github is for SPARC32, but I adjusted the code to test 
>> it on SPARC64
>> and (of course) it behaves the same.
>> 
>> Any idea what can be wrong?
> 
> Are you testing on true v8 hardware or on v9 ?
> On v9 (and v8+) you might be running in RMO (Relaxed Memory Order), in which
> case you probably need some extra "membar" to force the update of the
> variable [1].
> By default, the code probably only work for PSO and TSO modes (the only two
> that exist in v8)
> 
> if adding a "membar #MemIssue" before and after the update of the variable
> solve the problem, then memory ordering is the culprit. (this forces way too
> strong an ordering, but is useful for a test). "membar" is v9/v8+ only.
> 
> If you're on true v8 HW - darn. PSO still could be the problem. try with 
> "stbar"
> surrounding the variable update. "stbar" is a bit weaker that some
> variants of "membar",
> but is in v8.
> 
> You might want to take a look on how much ordering instructions the kernel
> uses, after all :-(
> 
> Low-level parallelism is hard :-)

Indeed, if the code is being compiled for V9, you will be exposed to RMO. §J.6
Spin Locks of the V9 architecture manual provides an example implementation
using LDSTUB, but the important points are:

1. Before returning from your acquire_lock function, you must perform a
   "membar #StoreLoad | #StoreStore" (#LoadLoad and #StoreLoad, and #LoadStore
   and #StoreStore are interchangeable in this context, since LDSTUB counts as
   both a load and a store; in fact the V9 manual suggests
   "membar #LoadLoad | #LoadStore", but I personally think treating LDSTUB as a
   store is clearer).  This ensures that no memory accesses inside the critical
   section are reordered with the LDSTUB.

2. Before clearing lock in release_lock, you must perform a
   "membar #LoadStore | #StoreStore" to ensure no memory accesses inside the
   critical section are reordered with the release.

That should be all that's required for V9 with RMO. For PSO, every load can be
treated as being followed by a "membar #LoadLoad | #LoadStore" (see §D.5).
Therefore, no barriers are needed in acquire_lock (LDSTUB counts as a load).
However, in release_lock, you must perform a "membar #StoreStore" (the
#LoadStore is dropped), which if you're compiling for V8 is what the
(deprecated as of V9) instruction STBAR does. For TSO, no barriers are needed,
as stores are not reordered (and the only barrier needed for PSO was a
#StoreStore).

TL;DR:

RMO (V9): "membar #StoreLoad | #StoreStore" after lock,
  "membar #LoadStore | #StoreStore" before unlock
PSO (V9): "membar #StoreStore" before unlock
PSO (V8): "stbar" before unlock
TSO (V8/V9): nothing

GCC defaults to RMO for 64-bit (V9 or above). I don't know if it defaults to
PSO or TSO for V8, and equally I don't know which of RMO, PSO and TSO it
defaults to for 32-bit V9 aka V8+. Also, this is all post-compilation; you
still need the necessary compile-time barriers to ensure the compiler doesn't
perform any unwanted reorderings, but that's the same on any architecture.

Regards,
James

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

New sparc64 porterbox

[James Clarke]

Hi,

Some of you may have noticed that the existing sparc64 porterbox,
notker.debian.net[0], has been unavailable for the past few months. As a
result, we have commissioned a new porterbox, sakharov.debian.net[1], kindly
hosted by Anatoly Pugachev, available to all DDs.

The machine is set up to closely mirror many aspects of the standard Debian
porterboxes, so you can use the usual dd-schroot-cmd workflow as described on
the Debian website[2].

Please note that this machine should be used to debug issues, and not to
perform binary uploads to the debian-ports archive in place of the build
daemons. The debian-ports archive has its own independent restricted keyring
and so any attempted uploads will be rejected.

If you have any issues or questions, please feel free to contact myself or
cbmuser on IRC (we dwell in #debian-ports), or via mail as listed in [1].

Thanks for your future porting efforts!

Regards,
James

[0] https://lists.debian.org/debian-devel/2016/07/msg00059.html
[1] https://db.debian.org/machines.cgi?host=sakharov
[2] https://dsa.debian.org/doc/schroot/

Bug#878317: pygobject: FTBFS on sparc64 due to SIGBUS in testsuite

[James Clarke]

Source: pygobject
Version: 3.24.1-3
Tags: upstream patch
Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=788894
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,
Currently, pygobject FTBFS on sparc64 due to performing an unaligned
access during test_callback_scope_call_array_inout and thus crashing
with SIGBUS. The above upstream bug report has a patch attached which
fixes this and allows the package to build.

Regards,
James

Bug#875977: libhdf5-100: Performs unaligned accesses on sparc64

[James Clarke]

Package: libhdf5-100
Version: 1.10.0-patch1+docs-3
Tags: upstream patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org, Ghislain Vaillant 

Control: affects -1 src:h5py

Hi,
Currently libhdf5-100 performs unaligned memory accesses on sparc64 in
certain cases, and this is causing the latest version of h5py to FTBFS
due to the test suite being killed with SIGBUS when doing vlen-related
tests (the tests in question being new in the latest upstream version).
On investigating, there are two issues:

 1. NO_ALIGNMENT_RESTRICTIONS is being defined on sparc64. GCC is
sufficiently smart to notice that the test program run when
configuring is performing unaligned accesses, and so instead of
using the usual multi-byte load instructions (which require the
address to be aligned), it expands it out into individual byte
loads, and therefore the test actually succeeds. This is only
because GCC can statically determine that the address is unaligned,
and therefore tries to be helpful (since it knows using multi-byte
loads will never work), whereas for a general address it will assume
the address is aligned and emit a single multi-byte load.

Adding in a few volatile qualifiers in the important places ensures
that GCC can no longer statically prove the relevant addresses are
unaligned, and therefore it uses the normal multi-byte load
instructions and the test program will crash, so configure knows not
to define NO_ALIGNMENT_RESTRICTIONS.

 2. Even with that fixed, H5T_vlen_reclaim_recurse needs fixing to
ensure it doesn't perform unaligned accesses when not supported.

With the attached patch, h5py's test suite now passes again. Please feel
free to forward this patch upstream if you deem it acceptable.

Regards,
James
--- a/config/cmake/ConversionTests.c
+++ b/config/cmake/ConversionTests.c
@@ -237,13 +237,13 @@ main ()
 
 char *chp = "beefs";
 char **chpp = malloc (2 * sizeof (char *));
-char **chpp2;
+char * volatile *chpp2;
 hvl_t vl = { 12345, (void *) chp };
 hvl_t *vlp;
-hvl_t *vlp2;
+hvl_t * volatile vlp2;
 
 memcpy ((void *) ((char *) chpp + 1), , sizeof (char *));
-chpp2 = (char **) ((char *) chpp + 1);
+chpp2 = (char * volatile *) (chpp + 1);
 if (strcmp (*chpp2, chp)) {
 free (chpp);
 return 1;
@@ -252,7 +252,7 @@ main ()
 
 vlp = malloc (2 * sizeof (hvl_t));
 memcpy ((void *) ((char *) vlp + 1), , sizeof (hvl_t));
-vlp2 = (hvl_t *) ((char *) vlp + 1);
+vlp2 = (hvl_t * volatile) ((char *) vlp + 1);
 if (vlp2->len != vl.len || vlp2->p != vl.p) {
 free (vlp);
 return 1;
--- a/configure.ac
+++ b/configure.ac
@@ -3372,13 +3372,13 @@ AC_RUN_IFELSE([
 ], [
 char *chp = "beefs";
 char **chpp = malloc (2 * sizeof (char *));
-char **chpp2;
+char * volatile *chpp2;
 hvl_t vl = { 12345, (void *) chp };
 hvl_t *vlp;
-hvl_t *vlp2;
+hvl_t * volatile vlp2;
 
 memcpy ((void *) ((char *) chpp + 1), , sizeof (char *));
-chpp2 = (char **) ((char *) chpp + 1);
+chpp2 = (char * volatile *) (chpp + 1);
 if (strcmp (*chpp2, chp)) {
 free (chpp);
 return 1;
@@ -3387,7 +3387,7 @@ AC_RUN_IFELSE([
 
 vlp = malloc (2 * sizeof (hvl_t));
 memcpy ((void *) ((char *) vlp + 1), , sizeof (hvl_t));
-vlp2 = (hvl_t *) ((char *) vlp + 1);
+vlp2 = (hvl_t * volatile) ((char *) vlp + 1);
 if (vlp2->len != vl.len || vlp2->p != vl.p) {
 free (vlp);
 return 1;
--- a/src/H5Tvlen.c
+++ b/src/H5Tvlen.c
@@ -1052,35 +1052,64 @@ H5T_vlen_reclaim_recurse(void *elem, con
 case H5T_VLEN:
 /* Recurse on the VL information if it's VL, compound, enum or 
array, then free VL sequence */
 if(dt->shared->u.vlen.type == H5T_VLEN_SEQUENCE) {
+void *p;
+size_t len;
+#ifdef H5_NO_ALIGNMENT_RESTRICTIONS
 hvl_t *vl = (hvl_t *)elem;/* Temp. ptr to the vl info */
+p = vl->p;
+len = vl->len;
+#else
+hvl_t vl; /* The vl info */
+HDmemcpy(, elem, sizeof(hvl_t));
+p = vl.p;
+len = vl.len;
+#endif
 
 /* Check if there is anything actually in this sequence */
-if(vl->len!=0) {
+if(len!=0) {
 /* Recurse if it's VL, array, enum or compound */
 if(H5T_IS_COMPLEX(dt->shared->parent->shared->type)) {
 void *off; /* offset of field */
 
 /* Calculate the offset of each array element and 
recurse on it */
-while(vl->len > 0) {
-off = ((uint8_t *)vl->p) + (vl->len - 1) * 
dt->shared->parent->shared->size;

Re: Updated debian-installer images

[James Clarke]

On 6 Sep 2017, at 11:27, Frank Scheiner <frank.schei...@web.de> wrote:
> On 09/06/2017 09:37 AM, John Paul Adrian Glaubitz wrote:
>> [...]
>> FWIW, I have found the issue and the new images are ready. I'm currently
>> waiting to get write permissions to upload them here:
>>> https://cdimage.debian.org/cdimage/ports/
> 
> Thanks, I already grabbed a copy for testing.
> 
>> [...]
>> I have never tried to install Debian sparc64 on any non-Sun/Oracle machine so
>> I can't really tell you anything.
>>> [2]: https://wiki.debian.org/Sparc64#Installing_the_Debian_SPARC64_Port
>> We should probably ask the person who wrote this wiki page.
> 
> Ah I see, I assumed that would be you because of the info related to your 
> ISOs and the installation process on different machines. Is that James Clarke 
> then (just recognized [1])?
> 
> [1]: https://wiki.debian.org/Sparc64?action=info

I only made a couple of minor changes; the edit you want is [0] by Alex
McWhirter.

James

[0] https://wiki.debian.org/Sparc64?action=diff=25=26

Re: Latest Debian SPARC64 ISO Image

[James Clarke]

> On 5 Sep 2017, at 19:47, Fedor Konstantinov  wrote:
> 
> Hi, James.
> 
> I have just tried to install Debian on my sparc64 machine, the SF V210 
> server, and found that there's no "Install SILO boot loader" option in the 
> installer. Is this a bug?
> There're also no any silo* packages on the installation media. Is this 
> correct?
> Could you help with this please?
> 
> I used this install image (downloaded today):
>  debian-9.0-sparc64-NETINST-1.iso 2017-09-03 09:50  196M
> Please see screenshot:
> 

[debian-sparc list Cc'ed as that's where this belongs]
Hi Fedor,
Thanks for the report. This is a known bug[0]; some of the latest installer
images are missing needed packages from the unreleased suite.

Regards,
James

[0] https://lists.debian.org/debian-sparc/2017/09/msg00013.html

Bug#874074: ld.so: TLS relocations against local symbols don't work on powerpc, sparc and sparc64

[James Clarke]

Package: libc6
Version: 2.24-17
Tags: upstream patch
Forwarded: https://sourceware.org/ml/libc-alpha/2017-09/msg00120.html
User: debian-sparc@lists.debian.org
Usertags: sparc sparc64
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-sparc@lists.debian.org, debian-powe...@lists.debian.org

Hi,
On the above architectures, TLS relocations against local symbols do not
work properly, crashing with SIGBUS or SIGSEGV on accessing the variable
in question. This is only a problem when using gold, as bfd will
optimise the relocations (since it knows the symbol cannot be pre-empted
by one in another object) to not refer to a symbol at all. I have
written a test script, available at [0].

The above patch has been tested on powerpc and sparc64 using my test
script, as well as on sparc64 using my local experimental GHC with
native code generation support, where the problem was first seen.

Regards,
James

[0] http://paste.debian.net/plain/984146

Bug#872483: erlang-cherly: FTBFS on sparc64 due to bad uintptr size

[James Clarke]

Source: erlang-cherly
Version: 0.12.8+dfsg-7
Severity: important
Tags: patch upstream
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,
Currently erlang-cherly FTBFS on sparc64 due to SIGBUSes in the test
suite. On investigating, I found this was because its uintptr type was
being typedef'd as 32-bit, as only amd64 and ia64 were being checked for
with the preprocessor. The attached patch switches to _LP64 as that is
the least invasive change, but perhaps it should be using the standard
uintptr_t instead. During this I also found that the indirectval was not
being set to 0 and instead being left uninitialised (for example, I saw
it have the value 'H'); I believe this could cause memory corruption if
valsize_in_hash is less than sizeof(void *), since indirectval could be
spuriously true and treating the inline value as a pointer would
overflow the allocated space. It also of course wastes time and space
over storing the value inline.

Regards,
James
diff -Nru erlang-cherly-0.12.8+dfsg/debian/patches/correct-uintptr-type.patch 
erlang-cherly-0.12.8+dfsg/debian/patches/correct-uintptr-type.patch
--- erlang-cherly-0.12.8+dfsg/debian/patches/correct-uintptr-type.patch 
1970-01-01 01:00:00.0 +0100
+++ erlang-cherly-0.12.8+dfsg/debian/patches/correct-uintptr-type.patch 
2017-08-17 20:18:41.0 +0100
@@ -0,0 +1,11 @@
+--- a/c_src/runtime.h
 b/c_src/runtime.h
+@@ -19,7 +19,7 @@ typedef  unsigned long long int  uint64;
+ typedef   float   float32;
+ typedef   double  float64;
+
+-#if defined(__ia64) || defined(__x86_64) || defined(__amd64)
++#if defined(_LP64)
+ typedef   uint64  uintptr;
+ typedef   int64   intptr;
+ #else
diff -Nru erlang-cherly-0.12.8+dfsg/debian/patches/initialize-indirectval.patch 
erlang-cherly-0.12.8+dfsg/debian/patches/initialize-indirectval.patch
--- erlang-cherly-0.12.8+dfsg/debian/patches/initialize-indirectval.patch   
1970-01-01 01:00:00.0 +0100
+++ erlang-cherly-0.12.8+dfsg/debian/patches/initialize-indirectval.patch   
2017-08-17 20:20:16.0 +0100
@@ -0,0 +1,12 @@
+--- a/c_src/hashmap.c
 b/c_src/hashmap.c
+@@ -711,7 +711,8 @@ runtime_makemap_c(MapType *typ, int64 hi
+   if (val->size > MaxValsize) {
+   h->indirectval = 1;
+   valsize_in_hash = sizeof(void*);
+-  }
++  } else
++  h->indirectval = 0;
+
+   // Align value inside data so that mark-sweep gc can find it.
+   h->valoff = key->size;
diff -Nru erlang-cherly-0.12.8+dfsg/debian/patches/series 
erlang-cherly-0.12.8+dfsg/debian/patches/series
--- erlang-cherly-0.12.8+dfsg/debian/patches/series 2016-12-20 
13:10:20.0 +
+++ erlang-cherly-0.12.8+dfsg/debian/patches/series 2017-08-17 
20:23:15.0 +0100
@@ -1,2 +1,4 @@
 add_support_r17_and_r18
 using-crypto_strong_rand_bytes
+initialize-indirectval.patch
+correct-uintptr-type.patch

Bug#870773: motif: flex now has yyleng as an int again

[James Clarke]

Source: motif
Version: 2.3.4-13
Severity: important
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,
Currently src:motif FTBFS on sparc64 due to wml crashing with SIGBUS (no
build logs available, as libfl-dev was broken on sparc64 until just
recently, masking the issue). This is because wml.c has yyleng defined
as a size_t, which was correct for versions of flex between 2.5.36 and
2.6.1, but this violated POSIX[0] and so yyleng was reverted back to an
int in 2.6.1[1]. When building on sparc64, yyleng just happens to be
aligned to a 4-byte boundary but not an 8-byte boundary, so doing an
8-byte store to it is unaligned and traps, but on other architectures
this will silently zero out the next 4 bytes in memory.

Please apply the attached debdiff to revert wml.c back to defining
yyleng as an external int, and also add a version constraint to
libfl-dev to ensure motif is not accidentally built with an older
version of flex without reinstating the hunk. With it I can successfully
build motif on sparc64.

Regards,
James

[0] http://pubs.opengroup.org/onlinepubs/7908799/xcu/lex.html
[1] 
https://github.com/westes/flex/commit/7a7c3dfe1bcb8230447ba1656f926b4b4cdfc457
diff -Nru motif-2.3.7/debian/control motif-2.3.7/debian/control
--- motif-2.3.7/debian/control  2017-08-03 11:21:00.0 +0100
+++ motif-2.3.7/debian/control  2017-08-04 22:36:10.0 +0100
@@ -5,7 +5,7 @@
debhelper (>= 10),
dh-exec,
flex (>= 2.5.36),
-   libfl-dev,
+   libfl-dev (>= 2.6.1),
libfontconfig1-dev,
libjpeg-dev,
libpng-dev,
diff -Nru motif-2.3.7/debian/patches/fix-type-inconsistencies.patch 
motif-2.3.7/debian/patches/fix-type-inconsistencies.patch
--- motif-2.3.7/debian/patches/fix-type-inconsistencies.patch   2017-08-03 
10:54:00.0 +0100
+++ motif-2.3.7/debian/patches/fix-type-inconsistencies.patch   2017-08-04 
22:36:10.0 +0100
@@ -1,12 +1,10 @@
 Description: Fix type inconsistencies
  This patch fixes various type inconsistencies reported by goto-cc
  from the cbmc package.
- .
- The yyleng fix in tools/wml/wml.c requires flex >= 2.5.36.
 Author: Graham Inggs 
 Forwarded: http://bugs.motifzone.net/show_bug.cgi?id=1641
 Bug-Debian: http://bugs.debian.org/749417
-Last-Update: 2017-08-03
+Last-Update: 2017-08-04
 --- a/lib/Xm/EditresComI.h
 +++ b/lib/Xm/EditresComI.h
 @@ -8,7 +8,7 @@
@@ -49,17 +47,6 @@
  extern int _XmTabbedStackListCount _ARGS((XmTabbedStackList));
  
  #ifndef _NO_PROTO
 a/tools/wml/wml.c
-+++ b/tools/wml/wml.c
-@@ -153,7 +153,7 @@
- /*
-  * External variables
-  */
--externint yyleng;
-+externsize_t  yyleng;
- extern  int yyparse();
- 
- 
 --- a/demos/lib/Xmd/RegEdit.c
 +++ b/demos/lib/Xmd/RegEdit.c
 @@ -252,7 +252,7 @@

Re: No login prompt after booting in LDOM on SPARC Enterprise T5120

[James Clarke]

On 19 Jul 2017, at 21:11, Gabriel Pérez-Cerezo  wrote:
> John Paul Adrian Glaubitz  writes:
> 
>> Are you sure that ttyS0 is the name of your serial device?
>> 
>> Check the kernel messages. It might be named differently.
> 
> It may be named ttyHV0, but as much as I have tried it with that name,
> it still doesn't work. However, I've been able to boot to shell
> (bypassing init) and there is no /dev/ttyHV0 in the filesystem. I'll see
> if I can try more stuff tomorrow.

There's a difference between the console name and serial device name; ttyHV
just means it's a SUN4V hypervisor console, but it will be given a ttyS[0-9]+
name (for example, the machine I am currently on also has a ttyHV0, but the
device node is /dev/ttyS0).

Regards,
James

Re: sources.list

[James Clarke]

> On 15 Jul 2017, at 21:42, Tom Demler  wrote:
> 
> On the Debian wiki page for Sparc64 I believe the sources.list entries are 
> suggested to be:
>  
> deb http://deb.debian.org/debian-ports unstable main
> deb-src http://deb.debian.org/debian unstable main
> deb http://deb.debian.org/debian-ports unreleased main
> deb-src http://deb.debian.org/debian-ports unreleased main
>  
> Is this still the proper content for that file?

Yes, that's still correct (of course, different mirrors exist, but that's the
best one to use these days unless you have a good reason).

James

Re: serial connection on debian on sun ultra10

[James Clarke]

On 12 Jul 2017, at 06:39, Frans van Berckel  wrote:
> On Tue, 2017-07-11 at 21:13 +0200, sacarde wrote:
> 
>> I did experiment: 
>> I replaced kernel+initrd (4.5.0) in deb-9-iso 
>> with kernel+initrd (3.2.0) from deb-7.11-iso
> 
> Are you able to release this iso for downloading, os i can test it?
> 
>> and running this iso I not have kernel-panic, and installation deb-9
>> starts OK
>> 
>> may be a ram problem?
>> 
>> can I install an old kernel during installation?
> 
> Good to know there a sparc 3.18.x kernel package, if i am well. Thats
> what is needed at least for systemd running well.
> 
> You always can cp the kernel and drivers from iso to disk, for testing
> purpose, if you want to. Check if firmware parts are needed. Adrian
> told me he doesn't wanne build the 3.x kernel package for sparc64.

I understand that your priority is most likely to get something working *now*,
but staying on an old kernel is not a long-term solution. Please, do listen to
us when we ask for *detailed, accurate* information about the kernel panic you
are getting, otherwise the kernel will likely remain broken for you. Otherwise,
you're welcome to download old kernels and play around with them, but please
take the discussion elsewhere; we're not supporting such things here.

Regards,
James

Bug#867987: h5py: FTBFS on sparc64 due to unaliged accesses in test suite

[James Clarke]

Source: h5py
Version: 2.7.0-1
Tags: upstream patch
Forwarded: https://github.com/h5py/h5py/pull/904
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,
Currently h5py FTBFS on sparc64 (and has done for as long as sparc64 has
been building packages without nocheck), as the test suite crashes with
SIGBUS due to unaligned memory accesses. I have submitted a fix upstream
at the above URL; please include the patch in the Debian package.

Regards,
James

Bug#866509: openblas: Please enable on sparc64

[James Clarke]

Source: openblas
Version: 0.2.19-3
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,
The upstream code supports 64-bit SPARC; please apply the attached
debdiff to enable the build.

Regards,
James
diff -Nru openblas-0.2.19/debian/control openblas-0.2.19/debian/control
--- openblas-0.2.19/debian/control  2017-01-23 14:09:05.0 +
+++ openblas-0.2.19/debian/control  2017-06-29 17:16:00.0 +0100
@@ -12,7 +12,7 @@

 Package: libopenblas-base
 Section: libs
-Architecture: amd64 arm64 armhf i386 powerpc ppc64el ppc64 kfreebsd-i386 
kfreebsd-amd64 mips64el
+Architecture: amd64 arm64 armhf i386 powerpc ppc64el ppc64 kfreebsd-i386 
kfreebsd-amd64 mips64el sparc64
 Depends: ${shlibs:Depends}, ${misc:Depends}, libblas-common
 Provides: libblas.so.3, liblapack.so.3
 Built-Using: ${Built-Using}
@@ -29,7 +29,7 @@

 Package: libopenblas-dev
 Section: libdevel
-Architecture: amd64 arm64 armhf i386 powerpc ppc64el ppc64 kfreebsd-i386 
kfreebsd-amd64 mips64el
+Architecture: amd64 arm64 armhf i386 powerpc ppc64el ppc64 kfreebsd-i386 
kfreebsd-amd64 mips64el sparc64
 Depends: libopenblas-base (= ${binary:Version}), libblas-dev, 
${shlibs:Depends},
  ${misc:Depends}
 Provides: libblas.so, liblapack.so
diff -Nru openblas-0.2.19/debian/rules openblas-0.2.19/debian/rules
--- openblas-0.2.19/debian/rules2017-01-23 14:11:43.0 +
+++ openblas-0.2.19/debian/rules2017-06-29 17:16:00.0 +0100
@@ -48,6 +48,10 @@
GENERIC_OPTIONS += TARGET=POWER8
 endif

+ifeq ($(DEB_HOST_ARCH),sparc64)
+   GENERIC_OPTIONS += TARGET=SPARC
+endif
+
 # The testsuite crashes on PowerPC. Disable it by pretending we are
 # cross-compiling.
 ifeq ($(DEB_HOST_ARCH),powerpc)

Bug#866407: alljoyn-core-1504: FTBFS on sparc64 due to missing baud rate defines

[James Clarke]

Source: alljoyn-core-1504
Version: 15.04b-8
Tags: patch upstream fixed-upstream
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Control: clone -1 -2
Control: retitle -2 alljoyn-core-1509: FTBFS on sparc64 due to missing baud 
rate defines
Control: reassign -2 src:alljoyn-core-1509 15.09a-5

Hi,
I noticed alljoyn-core-1504/1509 FTBFS on sparc64 as UARTStreamLinux.cc
assumes that B250 to B400 are defined, which is not true on
Linux/SPARC. This has been fixed upstream[1], and alljoyn-core-1604
builds fine; please backport the patch.

Regards,
James

[1] 
https://cgit.allseenalliance.org/core/alljoyn.git/commit/?id=e0756654e673be029a08240b32fe1bd553a0df43

Bug#866011: git: FTBFS on sparc64 due to unaligned access in pack-bitmap.c

[James Clarke]

Source: git
Version: 1:2.13.0+next.20170520-1
Severity: important
Tags: patch upstream
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,
New tests added upstream have been causing git to FTBFS on sparc64 due
to a not-previously-noticed unaligned access in pack-bitmap. Please find
attached the patch submitted upstream (mailing list index has not yet
updated, hence the lack of a Forwarded:).

Regards,
James
From: James Clarke <jrt...@jrtc27.com>
To: gits...@pobox.com
Cc: James Clarke <jrt...@jrtc27.com>,
g...@vger.kernel.org
Subject: [PATCH] pack-bitmap: Don't perform unaligned memory access
Date: Mon, 26 Jun 2017 16:16:12 +0100
Message-Id: <20170626151612.64019-1-jrt...@jrtc27.com>
X-Mailer: git-send-email 2.13.2

The preceding bitmap entries have a 1-byte XOR-offset and 1-byte flags,
so their size is not a multiple of 4. Thus the name-hash cache is only
guaranteed to be 2-byte aligned and so we must use get_be32 rather than
indexing the array directly.

Signed-off-by: James Clarke <jrt...@jrtc27.com>
---

This was noticed thanks to the recent tests added to t5310-pack-bitmaps.sh,
which were crashing with SIGBUS on Debian sparc64. All tests (excluding those
marked with known breakage) now pass again.

 pack-bitmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pack-bitmap.c b/pack-bitmap.c
index a3ac3dccd..327634cd7 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -627,7 +627,7 @@ static void show_objects_for_type(
sha1 = nth_packed_object_sha1(bitmap_git.pack, 
entry->nr);

if (bitmap_git.hashes)
-   hash = ntohl(bitmap_git.hashes[entry->nr]);
+   hash = get_be32(bitmap_git.hashes + entry->nr);

show_reach(sha1, object_type, 0, hash, bitmap_git.pack, 
entry->offset);
}
--
2.13.2

Bug#865908: haskell-cryptohash: FTBFS on sparc64 due to unaligned accesses

[James Clarke]

Source: haskell-cryptohash
Version: 0.11.9-3
Severity: important
Tags: patch upstream
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Forwarded: https://github.com/vincenthz/hs-cryptohash/pull/44/files

Hi,
Currently haskell-cryptohash FTBFS on sparc64 as it performs unaligned
memory accesses (and not all of these are necessarily caught by the test
suite). There is an align-reads.patch, but this diverges from the
changes I have made to cryptonite (which themselves are more consistent
with upstream). Please replace it with the attached patch, which is a
backport of the cryptonite changes.

Regards,
James
Description: Fix many cases of unaligned memory accesses
Author: James Clarke <jrt...@jrtc27.com>
Forwarded: https://github.com/vincenthz/hs-cryptohash/pull/44/files
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- /dev/null
+++ b/cbits/align.h
@@ -0,0 +1,157 @@
+#ifndef ALIGN_H
+#define ALIGN_H
+
+#include "bitfn.h"
+
+#if (defined(__i386__))
+# define UNALIGNED_ACCESS_OK
+#elif defined(__x86_64__)
+# define UNALIGNED_ACCESS_OK
+#else
+# define UNALIGNED_ACCESS_FAULT
+#endif
+
+/* n need to be power of 2.
+ * IS_ALIGNED(p,8) */
+#define IS_ALIGNED(p,alignment) (((uintptr_t) (p)) & ((alignment)-1))
+
+#ifdef WITH_ASSERT_ALIGNMENT
+#include 
+#include 
+#include 
+# define ASSERT_ALIGNMENT(up, alignment) \
+   do { if (IS_ALIGNED(up, alignment)) \
+   { printf("ALIGNMENT-ASSERT-FAILURE: %s:%d: ptr=%p alignment=%d\n", 
__FILE__, __LINE__, (void *) up, (alignment)); \
+ exit(99); \
+   }; } while (0)
+#else
+# define ASSERT_ALIGNMENT(p, n) do {} while (0)
+#endif
+
+#ifdef UNALIGNED_ACCESS_OK
+#define need_alignment(p,n) (0)
+#else
+#define need_alignment(p,n) IS_ALIGNED(p,n)
+#endif
+
+static inline uint32_t load_be32_aligned(const uint8_t *p)
+{
+   return be32_to_cpu(*((uint32_t *) p));
+}
+
+static inline uint64_t load_be64_aligned(const uint8_t *p)
+{
+   return be64_to_cpu(*((uint64_t *) p));
+}
+
+static inline void store_be32_aligned(uint8_t *p, uint32_t val)
+{
+   *((uint32_t *) p) = cpu_to_be32(val);
+}
+
+static inline void store_be64_aligned(uint8_t *p, uint64_t val)
+{
+   *((uint64_t *) p) = cpu_to_be64(val);
+}
+
+static inline uint32_t load_le32_aligned(const uint8_t *p)
+{
+   return le32_to_cpu(*((uint32_t *) p));
+}
+
+static inline uint64_t load_le64_aligned(const uint8_t *p)
+{
+   return le64_to_cpu(*((uint64_t *) p));
+}
+
+static inline void store_le32_aligned(uint8_t *p, uint32_t val)
+{
+   *((uint32_t *) p) = cpu_to_le32(val);
+}
+
+static inline void store_le64_aligned(uint8_t *p, uint64_t val)
+{
+   *((uint64_t *) p) = cpu_to_le64(val);
+}
+
+#ifdef UNALIGNED_ACCESS_OK
+
+#define load_be32(p) load_be32_aligned(p)
+#define load_be64(p) load_be64_aligned(p)
+
+#define store_be32(p, v) store_be32_aligned((p), (v))
+#define store_be64(p, v) store_be64_aligned((p), (v))
+
+#define load_le32(p) load_le32_aligned(p)
+#define load_le64(p) load_le64_aligned(p)
+
+#define store_le32(p, v) store_le32_aligned((p), (v))
+#define store_le64(p, v) store_le64_aligned((p), (v))
+
+#else
+
+static inline uint32_t load_be32(const uint8_t *p)
+{
+   return ((uint32_t)p[0] << 24) | ((uint32_t)p[1] << 16) | 
((uint32_t)p[2] <<  8) | ((uint32_t)p[3]);
+}
+
+static inline uint64_t load_be64(const uint8_t *p)
+{
+   return ((uint64_t)p[0] << 56) | ((uint64_t)p[1] << 48) | 
((uint64_t)p[2] << 40) | ((uint64_t)p[3] << 32) |
+  ((uint64_t)p[4] << 24) | ((uint64_t)p[5] << 16) | 
((uint64_t)p[6] <<  8) | ((uint64_t)p[7]);
+}
+
+static inline void store_be32(uint8_t *p, uint32_t val)
+{
+   p[0] = (val >> 24);
+   p[1] = (val >> 16) & 0xFF;
+   p[2] = (val >>  8) & 0xFF;
+   p[3] = (val  ) & 0xFF;
+}
+
+static inline void store_be64(uint8_t *p, uint64_t val)
+{
+   p[0] = (val >> 56);
+   p[1] = (val >> 48) & 0xFF;
+   p[2] = (val >> 40) & 0xFF;
+   p[3] = (val >> 32) & 0xFF;
+   p[4] = (val >> 24) & 0xFF;
+   p[5] = (val >> 16) & 0xFF;
+   p[6] = (val >>  8) & 0xFF;
+   p[7] = (val  ) & 0xFF;
+}
+
+static inline uint32_t load_le32(const uint8_t *p)
+{
+   return ((uint32_t)p[0]) | ((uint32_t)p[1] <<  8) | ((uint32_t)p[2] << 
16) | ((uint32_t)p[3] << 24);
+}
+
+static inline uint64_t load_le64(const uint8_t *p)
+{
+   return ((uint64_t)p[0]) | ((uint64_t)p[1] <<  8) | ((uint64_t)p[2] << 
16) | ((uint64_t)p[3] << 24) |
+  ((uint64_t)p[4] << 32) | ((uint64_t)p[5] << 40) | 
((uint64_t)p[6] << 48) | ((uint64_t)p[7] << 56);
+}
+
+static inline void store_le32(uint8_t *p, uint32_t val)
+{
+   p[0] = (val  ) & 0xFF;
+   p[1] = (val >

Bug#865906: haskell-cryptonite: FTBFS on sparc64 due to unaligned accesses

[James Clarke]

Source: haskell-cryptonite
Version: 0.21-2
Severity: important
Tags: patch upstream
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Forwarded: https://github.com/haskell-crypto/cryptonite/pull/175

Hi,
We've been through this once before! After the new upstream version, the
previous version of this patch was lost. This new version should
hopefully also be more acceptable to upstream, and includes fixes for
AES which I did not touch in the previous version (which meant
haskell-tls would FTBFS).

Regards,
James
Description: Fix more cases of unaligned memory accesses
Author: James Clarke <jrt...@jrtc27.com>
Forwarded: https://github.com/haskell-crypto/cryptonite/pull/175
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/cbits/cryptonite_align.h
+++ b/cbits/cryptonite_align.h
@@ -34,18 +34,124 @@
 #define need_alignment(p,n) IS_ALIGNED(p,n)
 #endif

+static inline uint32_t load_be32_aligned(const uint8_t *p)
+{
+   return be32_to_cpu(*((uint32_t *) p));
+}
+
+static inline uint64_t load_be64_aligned(const uint8_t *p)
+{
+   return be64_to_cpu(*((uint64_t *) p));
+}
+
+static inline void store_be32_aligned(uint8_t *p, uint32_t val)
+{
+   *((uint32_t *) p) = cpu_to_be32(val);
+}
+
+static inline void store_be64_aligned(uint8_t *p, uint64_t val)
+{
+   *((uint64_t *) p) = cpu_to_be64(val);
+}
+
 static inline uint32_t load_le32_aligned(const uint8_t *p)
 {
-   return le32_to_cpu(*((uint32_t *) p));
+   return le32_to_cpu(*((uint32_t *) p));
+}
+
+static inline uint64_t load_le64_aligned(const uint8_t *p)
+{
+   return le64_to_cpu(*((uint64_t *) p));
+}
+
+static inline void store_le32_aligned(uint8_t *p, uint32_t val)
+{
+   *((uint32_t *) p) = cpu_to_le32(val);
+}
+
+static inline void store_le64_aligned(uint8_t *p, uint64_t val)
+{
+   *((uint64_t *) p) = cpu_to_le64(val);
 }

 #ifdef UNALIGNED_ACCESS_OK
-#define load_le32(a) load_le32_aligned(a)
+
+#define load_be32(p) load_be32_aligned(p)
+#define load_be64(p) load_be64_aligned(p)
+
+#define store_be32(p, v) store_be32_aligned((p), (v))
+#define store_be64(p, v) store_be64_aligned((p), (v))
+
+#define load_le32(p) load_le32_aligned(p)
+#define load_le64(p) load_le64_aligned(p)
+
+#define store_le32(p, v) store_le32_aligned((p), (v))
+#define store_le64(p, v) store_le64_aligned((p), (v))
+
 #else
+
+static inline uint32_t load_be32(const uint8_t *p)
+{
+   return ((uint32_t)p[0] << 24) | ((uint32_t)p[1] << 16) | 
((uint32_t)p[2] <<  8) | ((uint32_t)p[3]);
+}
+
+static inline uint64_t load_be64(const uint8_t *p)
+{
+   return ((uint64_t)p[0] << 56) | ((uint64_t)p[1] << 48) | 
((uint64_t)p[2] << 40) | ((uint64_t)p[3] << 32) |
+  ((uint64_t)p[4] << 24) | ((uint64_t)p[5] << 16) | 
((uint64_t)p[6] <<  8) | ((uint64_t)p[7]);
+}
+
+static inline void store_be32(uint8_t *p, uint32_t val)
+{
+   p[0] = (val >> 24);
+   p[1] = (val >> 16) & 0xFF;
+   p[2] = (val >>  8) & 0xFF;
+   p[3] = (val  ) & 0xFF;
+}
+
+static inline void store_be64(uint8_t *p, uint64_t val)
+{
+   p[0] = (val >> 56);
+   p[1] = (val >> 48) & 0xFF;
+   p[2] = (val >> 40) & 0xFF;
+   p[3] = (val >> 32) & 0xFF;
+   p[4] = (val >> 24) & 0xFF;
+   p[5] = (val >> 16) & 0xFF;
+   p[6] = (val >>  8) & 0xFF;
+   p[7] = (val  ) & 0xFF;
+}
+
 static inline uint32_t load_le32(const uint8_t *p)
 {
return ((uint32_t)p[0]) | ((uint32_t)p[1] <<  8) | ((uint32_t)p[2] << 
16) | ((uint32_t)p[3] << 24);
 }
+
+static inline uint64_t load_le64(const uint8_t *p)
+{
+   return ((uint64_t)p[0]) | ((uint64_t)p[1] <<  8) | ((uint64_t)p[2] << 
16) | ((uint64_t)p[3] << 24) |
+  ((uint64_t)p[4] << 32) | ((uint64_t)p[5] << 40) | 
((uint64_t)p[6] << 48) | ((uint64_t)p[7] << 56);
+}
+
+static inline void store_le32(uint8_t *p, uint32_t val)
+{
+   p[0] = (val  ) & 0xFF;
+   p[1] = (val >>  8) & 0xFF;
+   p[2] = (val >> 16) & 0xFF;
+   p[3] = (val >> 24);
+}
+
+static inline void store_le64(uint8_t *p, uint64_t val)
+{
+   p[0] = (val  ) & 0xFF;
+   p[1] = (val >>  8) & 0xFF;
+   p[2] = (val >> 16) & 0xFF;
+   p[3] = (val >> 24) & 0xFF;
+   p[4] = (val >> 32) & 0xFF;
+   p[5] = (val >> 40) & 0xFF;
+   p[6] = (val >> 48) & 0xFF;
+   p[7] = (val >> 56);
+}
+
 #endif

 #endif
--- a/cbits/cryptonite_poly1305.c
+++ b/cbits/cryptonite_poly1305.c
@@ -37,11 +37,7 @@
 #include 
 #include "cryptonite_poly1305.h"
 #include "cryptonite_bitfn.h"
-
-static inline uint32_t load32(uint8_t *p)
-{
-   return (le32_to_cpu(*((uint

Re: How to recover from blank screen on sparc64

[James Clarke]

On 21 Jun 2017, at 14:31, Tom Demler  wrote:
> I finally was successful installing sparc64 on my old Ultra Enterprise II. I 
> had to switch the output to the ttya port and have it connected to a serial 
> port on a laptop in order to do the install from the ISO image on CD. Then 
> the install proceeded normally and I could boot normally. Aptitude was 
> working well and I used it to obtain the latest updates. I then attempted to 
> install a desktop starting with xfce (I only have 1Gb of RAM). Received 
> several “Not Found” messages for packages so the install of xfce did not 
> continue. Attempted the same with LXDE with similar results. Finally I 
> updated package lists and proceeded with the resulting upgrades. This seemed 
> to install many, many packages – possibly all that were downloaded in my 
> attempt to install a desktop. It was taking a very long time particularly 
> with building the font cache. I left it continue…
> This morning the system was at the Sun OpenBoot boot prompt so I attempted to 
> boot the system. It seemed to be booting normally but the result is a blank 
> screen and I cannot get a response to anything. What is the best way to 
> recover from this?

You could always try booting into the non-graphical multi-user mode
(systemd.unit=multi-user.target) or single-user mode
(systemd.unit=rescue.target).

Regards,
James

Bug#862062: FTBFS on sparc64 due to SIGBUS in test suite

[James Clarke]

Source: systemd
Version: 233-6
Tags: upstream patch
Forwarded: https://github.com/systemd/systemd/pull/5622
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,
Currently systemd FTBFS in experimental on sparc64 due to
journal-importer performing an unaligned access when running the test
suite. If you upload another version between now and 234, could you
please include the patch accepted upstream?

Regards,
James

Re: Bug#649241: binutils: Either gas or ld is doing the wrong thing with R_SPARC_WDISP22 relocations on sparc

[James Clarke]

Control: retitle -1 binutils: ld should give an error for WDISP relocations 
against preemptible symbols
Control: severity -1 normal

On Fri, Apr 28, 2017 at 10:21:25PM +0100, James Clarke wrote:
>  2. Perhaps new R_SPARC_WPLT{10,16,19,22} should be introduced to allow
> shorter tail-call sequences like this? Glancing at bfd it should be
> fairly straightforward, and I imagine the same is true for gold.

So I went ahead and implemented this in bfd/gas/gold, and I now see why
it hasn't been done before. The default linker script for bfd (though
not for gold) puts the PLT too far away from the .text section to be
reachable with a WPLT{10,16,19} (even with gold WPLT10 overflows). That
leaves only the deprecated V8 branches which have a hope of reaching the
PLT. I don't think it's worth doing it just for these, and in fact,
branches on other architectures can't be used to jump to preemptible
functions either, so it would be more surprising if this *did* work.
Therefore I think the only bug here is that ld does not give any errors.

Regards,
James

Re: Bug#649241: binutils: Either gas or ld is doing the wrong thing with R_SPARC_WDISP22 relocations on sparc

[James Clarke]

(Hooray for investigating long-standing bug reports?)

On Sat, Nov 19, 2011 at 09:41:21AM +0100, Mike Hommey wrote:
> Package: binutils
> Version: 2.21.90.20111025-1
> Severity: important
>
> In Iceweasel 9, there is a piece of assembly that can be simplified as
> the following:
>
> .text
> .global foo
> .type   foo, #function
> foo:
>   ba bar
>   nop
>
> .global bar
> .type   bar, #function
> bar:
>   call exit
>
> When compiling the above, the resulting binary ends up with a runtime
> R_SPARC_WDISP22 relocation that ld.so doesn't know about:
>
> $ gcc -o test.so -shared test.s
> $ LD_PRELOAD=$(pwd)/test.so cat
> cat: error while loading shared libraries: /home/glandium/test.so: unexpected 
> reloc type 0x08
>
> One would expect ld to actually care about this relocation itself at
> (static) link time. Or gas to emit a relocation that ld knows about.

So, the problem here is that you're making a shared library and thus
bar, being a global symbol, is by default preemptible (if you make it
non-global then the runtime linker is happy, but you can't preempt it).
In the case of using a normal "call" instruction for which the assembler
generates an R_SPARC_WPLT30 relocation (when given -KPIC), the linker
generates a PLT entry and everything is as you'd expect. However, none
of the branches have corresponding WPLT relocations available. Gold is
rather more helpful here, giving:

> error: /tmp/ccgupDIX.o: requires unsupported dynamic reloc; recompile with 
> -fPIC

which, while not especially informative as to *which* relocation was
bad, at least stops it from producing an output the runtime linker will
crash on (and one which has evil text relocations...).

The canonical way to perform a tail-call on SPARC like this is:

>   or %o7, %g0, %REG
>   call bar
>or %REG, %g0, %o7

where REG is whatever you have free. This obviously has to be done in
the *same* register window as the caller (otherwise when bar returns
there'll still be an extra window to pop). This saves the return
address, does a call-and-link (clobbering %o7 with PC+8) and then
restores %o7 in the handy delay slot, emulating a call-without-link.

In fact, ld is smart enough to recognise this pattern as not being a
real call, and turns it into the following:

>   or %o7, %g0, %REG
>   b bar@plt
>nop

Gold does the same but uses the V9 branch instead. Unfortunately there's
still a wasted instruction there, but it's better than it was.

So to summarise, I guess there are two issues here:

 1. bfd should give an error when trying to use an instruction other
than call to branch to a preemptible function (currently there are
no places in elfxx-sparc.c where the "recompile with -fPIC" string
appears, so there are likely other things like this).

 2. Perhaps new R_SPARC_WPLT{10,16,19,22} should be introduced to allow
shorter tail-call sequences like this? Glancing at bfd it should be
fairly straightforward, and I imagine the same is true for gold.

Regards,
James

Bug#858049: Please add ufs-modules udeb on sparc64

[James Clarke]

Source: linux
Version: 4.9.13-1
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,
Along with (more recently) ZFS, many Solaris installations use UFS for
their root file system. Therefore, it would be extremely useful if an
installer CD could mount these partitions, but at the moment there is no
ufs-modules udeb available for d-i to include. Please apply the attached
patch to create one on sparc64 so we can add it to d-i.

Thanks,
James
>From 77a8ef24e9059ae1d1c9617861b78d711ecdbd94 Mon Sep 17 00:00:00 2001
From: James Clarke <jrt...@debian.org>
Date: Fri, 17 Mar 2017 17:35:40 +
Subject: [PATCH] [sparc64] Add new ufs-modules udeb

---
 debian/installer/modules/ufs-modules | 1 +
 debian/installer/package-list| 6 ++
 debian/installer/sparc64/modules/sparc64/ufs-modules | 1 +
 3 files changed, 8 insertions(+)

diff --git a/debian/installer/modules/ufs-modules 
b/debian/installer/modules/ufs-modules
new file mode 100644
index 0..19173e9aa
--- /dev/null
+++ b/debian/installer/modules/ufs-modules
@@ -0,0 +1 @@
+ufs
diff --git a/debian/installer/package-list b/debian/installer/package-list
index a170318ac..6207e3946 100644
--- a/debian/installer/package-list
+++ b/debian/installer/package-list
@@ -129,6 +129,12 @@ Priority: extra
 Description: NTFS filesystem support
  This package contains the NTFS file system module for the kernel.
 
+Package: ufs-modules
+Depends: kernel-image
+Priority: extra
+Description: UFS filesystem support
+ This package contains the UFS filesystem module for the kernel.
+
 Package: xfs-modules
 Depends: kernel-image, crc-modules
 Priority: standard
diff --git a/debian/installer/sparc64/modules/sparc64/ufs-modules 
b/debian/installer/sparc64/modules/sparc64/ufs-modules
new file mode 100644
index 0..163ead095
--- /dev/null
+++ b/debian/installer/sparc64/modules/sparc64/ufs-modules
@@ -0,0 +1 @@
+#include 
-- 
2.11.0

Re: Missing virtio modules for sparc64

[James Clarke]

On 17 Mar 2017, at 11:42, Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> 
wrote:
> On 17/03/17 11:40, James Clarke wrote:
>> On 17 Mar 2017, at 11:36, Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> 
>> wrote:
>>> On 17/03/17 11:33, John Paul Adrian Glaubitz wrote:
>>> 
>>>> On 03/17/2017 12:22 PM, Mark Cave-Ayland wrote:
>>>>> There is one issue I've found in that the debian-installer fails to
>>>>> detect the installation CDROM hardware automatically.
>>>>> 
>>>>> I was able to workaround this by selecting the option to load an
>>>>> external driver, let that fail, then manually enter the /dev/vda device
>>>>> which allowed installation to continue but something is preventing the
>>>>> virtio-blk device being seen as a CDROM.
>>>> 
>>>> It's most likely the same issue as the one we have with the vdisk block
>>>> devices when installing inside a SPARC LDOM [1].
>>>> 
>>>> Can you post the output of "udevadm info -q env -p /sys/block/vda" if
>>>> /dev/vda is the virtual block device for your CD-ROM drive? If it
>>>> doesn't include any indication of a CD device, you know why d-i doesn't
>>>> detect the CD drive.
>>> 
>>> Yep, here she is:
>>> 
>>> ~ # udevadm info -q env -p /sys/block/vda
>>> DEVLINKS=/dev/disk/by-path/platform-ffe2d650-pci-:00:06.0
>>> /dev/disk/by-label/Debian\x209.0\x20sparc64\x201
>>> /dev/disk/by-uuid/2017-03-16-23-13-57-00
>>> DEVNAME=/dev/vda
>>> DEVPATH=/devices/root/ffe2d650/pci:00/:00:06.0/virtio0/block/vda
>>> DEVTYPE=disk
>>> ID_FS_LABEL=Debian_9.0_sparc64_1
>>> ID_FS_LABEL_ENC=Debian\x209.0\x20sparc64\x201
>>> ID_FS_TYPE=iso9660
>>> ID_FS_USAGE=filesystem
>>> ID_FS_UUID=2017-03-16-23-13-57-00
>>> ID_FS_UUID_ENC=2017-03-16-23-13-57-00
>>> ID_PART_TABLE_TYPE=sun
>>> ID_PATH=platform-ffe2d650-pci-:00:06.0
>>> ID_PATH_TAG=platform-ffe2d650-pci-_00_06_0
>>> MAJOR=254
>>> MINOR=0
>>> SUBSYSTEM=block
>>> USEC_INITIALIZED=4920671
>>> ~ #
>>> 
>>> Presumably the DEVTYPE=disk gives away that the device isn't correctly
>>> being detected as a CDROM?
>> 
>> Nah, it would still be a disk, but you would have:
>> 
>>> ID_CDROM=1
>> 
>> 
>> What does `/lib/udev/cdrom_id /dev/vda` say?
> 
> Hmmm seemingly nothing:
> 
> ~ # /lib/udev/cdrom_id /dev/vda
> ~ #

Aha, known issue with virtio[1]. This would be fixed by scanning for
ID_FS_TYPE=iso9660 as well as ID_CDROM=1...

Regards,
James

[1] https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1155403

Re: Missing virtio modules for sparc64

[James Clarke]

On 17 Mar 2017, at 11:36, Mark Cave-Ayland  
wrote:
> On 17/03/17 11:33, John Paul Adrian Glaubitz wrote:
> 
>> On 03/17/2017 12:22 PM, Mark Cave-Ayland wrote:
>>> There is one issue I've found in that the debian-installer fails to
>>> detect the installation CDROM hardware automatically.
>>> 
>>> I was able to workaround this by selecting the option to load an
>>> external driver, let that fail, then manually enter the /dev/vda device
>>> which allowed installation to continue but something is preventing the
>>> virtio-blk device being seen as a CDROM.
>> 
>> It's most likely the same issue as the one we have with the vdisk block
>> devices when installing inside a SPARC LDOM [1].
>> 
>> Can you post the output of "udevadm info -q env -p /sys/block/vda" if
>> /dev/vda is the virtual block device for your CD-ROM drive? If it
>> doesn't include any indication of a CD device, you know why d-i doesn't
>> detect the CD drive.
> 
> Yep, here she is:
> 
> ~ # udevadm info -q env -p /sys/block/vda
> DEVLINKS=/dev/disk/by-path/platform-ffe2d650-pci-:00:06.0
> /dev/disk/by-label/Debian\x209.0\x20sparc64\x201
> /dev/disk/by-uuid/2017-03-16-23-13-57-00
> DEVNAME=/dev/vda
> DEVPATH=/devices/root/ffe2d650/pci:00/:00:06.0/virtio0/block/vda
> DEVTYPE=disk
> ID_FS_LABEL=Debian_9.0_sparc64_1
> ID_FS_LABEL_ENC=Debian\x209.0\x20sparc64\x201
> ID_FS_TYPE=iso9660
> ID_FS_USAGE=filesystem
> ID_FS_UUID=2017-03-16-23-13-57-00
> ID_FS_UUID_ENC=2017-03-16-23-13-57-00
> ID_PART_TABLE_TYPE=sun
> ID_PATH=platform-ffe2d650-pci-:00:06.0
> ID_PATH_TAG=platform-ffe2d650-pci-_00_06_0
> MAJOR=254
> MINOR=0
> SUBSYSTEM=block
> USEC_INITIALIZED=4920671
> ~ #
> 
> Presumably the DEVTYPE=disk gives away that the device isn't correctly
> being detected as a CDROM?

Nah, it would still be a disk, but you would have:

> ID_CDROM=1


What does `/lib/udev/cdrom_id /dev/vda` say?

James

Re: Retrieving disk info from sunvdc using udevadm

[James Clarke]

On 16 Mar 2017, at 12:15, Anatoly Pugachev  wrote:
> On Wed, Mar 15, 2017 at 1:14 AM, John Paul Adrian Glaubitz
>  wrote:
>> Hi!
>> 
>> Some Debian users who are installing Debian for sparc64 in an LDOM run into
>> the problem that the debian-installer is unable to detect the installation
>> medium.
>> 
>> Digging through the sources of the responsible debian-installer module, it
>> turns out that d-i uses "udevadm info" to query information from all 
>> available
>> block devices listed in /sys/block. To detect a CD-ROM, it looks for 
>> "ID_CDROM=1"
>> or "ID_TYPE=cd".
>> 
>> Unfortunately, this fails with sunvdc with a virtual CD-ROM drive as the data
>> retrieved by "udevadm info" is very limited as compared to a standard PC with
>> a physical CD-ROM drive.
>> 
>> For comparison, on a SPARC T5, I get:
>> 
>> /sys/block # udevadm info -q env -p /sys/block/vdiskd
>> DEVLINKS=/dev/disk/by-uuid/2017-03-14-14-05-33-00 
>> /dev/disk/by-label/Debian\x209.0\x20sparc64\x201
>> DEVNAME=/dev/vdiskd
>> DEVPATH=/devices/channel-devices/vdc-port-3-0/block/vdiskd
>> DEVTYPE=disk
>> ID_FS_LABEL=Debian_9.0_sparc64_1
>> ID_FS_LABEL_ENC=Debian\x209.0\x20sparc64\x201
>> ID_FS_TYPE=iso9660
>> ID_FS_USAGE=filesystem
>> ID_FS_UUID=2017-03-14-14-05-33-00
>> ID_FS_UUID_ENC=2017-03-14-14-05-33-00
>> ID_PART_TABLE_TYPE=sun
>> MAJOR=254
>> MINOR=24
>> SUBSYSTEM=block
>> USEC_INITIALIZED=634522
>> /sys/block #
>> 
>> Compare this to the output for a standard USB CD-ROM device on my laptop:
>> 
>> glaubitz@ikarus:/sys/block$ udevadm info -q env -p /sys/block/sr0
>> DEVLINKS=/dev/disk/by-path/pci-:00:14.0-usb-0:2:1.0-scsi-0:0:0:0 
>> /dev/disk/by-id/usb-TSSTcorp_CDDVDW_SE-S084D_0j468695-0:0 /dev/dvdrw 
>> /dev/dvd /dev/cdrom
>> /dev/cdrw
>> DEVNAME=/dev/sr0
>> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/host4/target4:0:0/4:0:0:0/block/sr0
>> DEVTYPE=disk
>> ID_BUS=usb
>> ID_CDROM=1
>> ID_CDROM_CD=1
>> ID_CDROM_CD_R=1
>> ID_CDROM_CD_RW=1
>> ID_CDROM_DVD=1
>> ID_CDROM_DVD_PLUS_R=1
>> ID_CDROM_DVD_PLUS_RW=1
>> ID_CDROM_DVD_PLUS_R_DL=1
>> ID_CDROM_DVD_R=1
>> ID_CDROM_DVD_RAM=1
>> ID_CDROM_DVD_RW=1
>> ID_CDROM_MRW=1
>> ID_CDROM_MRW_W=1
>> ID_FOR_SEAT=block-pci-_00_14_0-usb-0_2_1_0-scsi-0_0_0_0
>> ID_INSTANCE=0:0
>> ID_MODEL=CDDVDW_SE-S084D
>> ID_MODEL_ENC=CDDVDW\x20SE-S084D\x20
>> ID_MODEL_ID=1836
>> ID_PATH=pci-:00:14.0-usb-0:2:1.0-scsi-0:0:0:0
>> ID_PATH_TAG=pci-_00_14_0-usb-0_2_1_0-scsi-0_0_0_0
>> ID_REVISION=TS00
>> ID_SERIAL=TSSTcorp_CDDVDW_SE-S084D_0j468695-0:0
>> ID_SERIAL_SHORT=0j468695
>> ID_TYPE=cd
>> ID_USB_DRIVER=usb-storage
>> ID_USB_INTERFACES=:080250:
>> ID_USB_INTERFACE_NUM=00
>> ID_VENDOR=TSSTcorp
>> ID_VENDOR_ENC=TSSTcorp
>> ID_VENDOR_ID=0e8d
>> MAJOR=11
>> MINOR=0
>> SUBSYSTEM=block
>> SYSTEMD_READY=0
>> TAGS=:systemd:uaccess:seat:
>> USEC_INITIALIZED=16198574878
>> glaubitz@ikarus:/sys/block$
>> 
>> Would it be possible to extend sunvdc to display additional fields? In 
>> particular, it would be very useful
>> if sunvdc could indicate whether the virtual block device is a regular disk 
>> or a CD-ROM drive.
> 
> 
> Adrian,
> 
> wouldn't it be easier to patch d-i (userspace) to add support for
> "ID_FS_TYPE=iso9660" as /dev/cdrom (besides of "ID_CDROM=1"), instead
> of patching kernel (sunvdc.c) sources?

Patching d-i might make sense, since it will ensure other architectures don't
have similar issues, but I believe the problem is in udev itself, specifically
60-cdrom_id.rules[1] which needs to whitelist "vdisk*" as possible CDs.
Certainly if you invoke /lib/udev/cdrom_id manually it is able to distinguish
between CDs and non-CDs.

Regards,
James

[1] https://github.com/systemd/systemd/blob/master/rules/60-cdrom_id.rules



signature.asc
Description: Message signed with OpenPGP

Re: openjdk-8 build failure on landau, unable to reproduce locally

[James Clarke]

On 11 Mar 2017, at 19:39, David Matthew Mattli  wrote:
> 
> Several of the last openjdk-8 builds have failed with a segfault[0] but
> I haven't been able to reproduce the failure locally. Looking at the
> list of build logs[1] I noticed that the last successful build was by
> andi on 2016-12-12. All eight of the landau builds failed with a
> segfault.
> 
> Given that I can't reproduce the failure and andi seems to be able to
> build openjdk-8 successfully is it possible that landau has an issue?

Hi David,
Firstly, thanks for caring about ports architectures!

Other than generally not being the same processor, and landau having many more
threads (it uses parallel=32, since there are 4 concurrent builds over 128
threads), there is one potentially important difference; the UltraSparc T1 on
andi uses a 48-bit virtual address space (with any returned addresses being
sign-extended), whereas the T5 on landau has a 52-bit virtual address space. It
could also be something completely different, too, of course.

What machine were you trying to reproduce it on? The sparc64 porterbox, notker,
also uses a T1, so if this is the problem you won't be able to reproduce it
there.

Regards,
James

Re: Strange failures on 4.9.6-3 kernel

[James Clarke]

On 9 Feb 2017, at 23:08, Adhemerval Zanella <adhemerval.zane...@linaro.org> 
wrote:
> On 09/02/2017 20:14, James Clarke wrote:
>>> On 9 Feb 2017, at 21:31, Adhemerval Zanella <adhemerval.zane...@linaro.org> 
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> While testing glibc on the kindly provided T5 machine from Debian 
>>> environment,
>>> I started to see some strange issues on sparc64 where glibc is failing on 
>>> mostly static tests. 
>>> 
>>> Funny thing is I checked the latest working revision I used to update 2.25 
>>> release page [1] and now the tests that used to pass are now failing. In 
>>> fact I checked even the 2.23 and 2.24 glibc releases and both show the same
>>> issues as master branch, so I am almost ruling out a glibc regression 
>>> (which 
>>> was my first idea).
>>> 
>>> I noted that the machine kernel was updated (from 4.9.2-2 to 4.9.6-3), but 
>>> I am not sure if this is something to kernel.  I haven't recorded the
>>> gcc revision I used on my initial testings.  The static tets are failing due
>>> a memcpy call that issues bogus instructions:
>>> 
>>> (gdb) r
>>> Starting program: /home/azanella/glibc/glibc-git-build/elf/tst-tls1-static 
>>> 
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x0340 in ?? ()
>>> (gdb) bt
>>> #0  0x0340 in ?? ()
>>> #1  0x00101fd8 in __libc_setup_tls () at libc-tls.c:180
>>> #2  0x00101950 in __libc_start_main (main=0x4e8, argc=>> out>, argv=0x7feef78, init=0x4a8, fini=0x220, rtld_fini=0x0, 
>>> stack_end=0x1)
>>>   at libc-start.c:189
>>> #3  0x00100704 in _start () at ../sysdeps/sparc/sparc64/start.S:88
>>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>> 
>>> (gdb) up
>>> [...]
>>>  0x00101fc8 <+344>:   add  %l4, %o0, %o0
>>>  0x00101fcc <+348>:   mov  %i1, %o1
>>>  0x00101fd0 <+352>:   call  0x2949c0
>>>  0x00101fd4 <+356>:   stx  %o0, [ %i4 + 0x20 ]
>>> => 0x00101fd8 <+360>:   sethi  %hi(0x4800), %g3
>>> 
>>> It seems 0x2949c0 is a unknown address, where it should be the memcpy one. 
>> 
>> Do you have the .o still for this? I would be interested to see what the
>> relocation was. One thing that has changed within the last week is enabling
>> PIE by default in GCC, though this call is a plain PC-relative one.
>> 
>> Regards,
>> James
>> 
> 
> Yes, objdump shows:
> 
> $ objdump -r string/memcpy.o
> string/memcpy.o: file format elf64-sparc
> 
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE  VALUE 
> 0010 R_SPARC_GOT22 __memcpy_niagara4
> 0014 R_SPARC_GOT10 __memcpy_niagara4
> 0028 R_SPARC_GOT22 __memcpy_niagara2
> 002c R_SPARC_GOT10 __memcpy_niagara2
> 0040 R_SPARC_GOT22 __memcpy_niagara1
> 0044 R_SPARC_GOT10 __memcpy_niagara1
> 0058 R_SPARC_GOT22 __memcpy_ultra3
> 005c R_SPARC_GOT10 __memcpy_ultra3
> 0068 R_SPARC_GOT22 __memcpy_ultra1
> 006c R_SPARC_GOT10 __memcpy_ultra1
> 0088 R_SPARC_GOT22 __mempcpy_niagara4
> 008c R_SPARC_GOT10 __mempcpy_niagara4
> 00a0 R_SPARC_GOT22 __mempcpy_niagara2
> 00a4 R_SPARC_GOT10 __mempcpy_niagara2
> 00b8 R_SPARC_GOT22 __mempcpy_niagara1
> 00bc R_SPARC_GOT10 __mempcpy_niagara1
> 00d0 R_SPARC_GOT22 __mempcpy_ultra3
> 00d4 R_SPARC_GOT10 __mempcpy_ultra3
> 00e0 R_SPARC_GOT22 __mempcpy_ultra1
> 00e4 R_SPARC_GOT10 __mempcpy_ultra1
> 
> [debug relocations...]
> 
> Which is expected to use GOT relocations for PIE.  And if I build the 
> same object with -fno-pie I do see:
> 
> string/memcpy.o: file format elf64-sparc
> 
> RELOCATION RECORDS FOR [.text]:
> OFFSET   TYPE  VALUE
> 0010 R_SPARC_HI22  __memcpy_niagara4
> 0014 R_SPARC_LO10  __memcpy_niagara4
> 0028 R_SPARC_HI22  __memcpy_niagara2
> 002c R_SPARC_LO10  __memcpy_niagara2
> 0040 R_SPARC_HI22  __memcpy_niagara1
> 0044 R_SPARC_LO10  __memcpy_niagara1
> 0058 R_SPARC_HI22  __memcpy_ultra3
> 005c R_SPARC_LO10  __m

Re: Strange failures on 4.9.6-3 kernel

[James Clarke]

> On 9 Feb 2017, at 21:31, Adhemerval Zanella  
> wrote:
> 
> Hi all,
> 
> While testing glibc on the kindly provided T5 machine from Debian environment,
> I started to see some strange issues on sparc64 where glibc is failing on 
> mostly static tests. 
> 
> Funny thing is I checked the latest working revision I used to update 2.25 
> release page [1] and now the tests that used to pass are now failing. In 
> fact I checked even the 2.23 and 2.24 glibc releases and both show the same
> issues as master branch, so I am almost ruling out a glibc regression (which 
> was my first idea).
> 
> I noted that the machine kernel was updated (from 4.9.2-2 to 4.9.6-3), but 
> I am not sure if this is something to kernel.  I haven't recorded the
> gcc revision I used on my initial testings.  The static tets are failing due
> a memcpy call that issues bogus instructions:
> 
> (gdb) r
> Starting program: /home/azanella/glibc/glibc-git-build/elf/tst-tls1-static 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0340 in ?? ()
> (gdb) bt
> #0  0x0340 in ?? ()
> #1  0x00101fd8 in __libc_setup_tls () at libc-tls.c:180
> #2  0x00101950 in __libc_start_main (main=0x4e8, argc= out>, argv=0x7feef78, init=0x4a8, fini=0x220, rtld_fini=0x0, 
> stack_end=0x1)
>at libc-start.c:189
> #3  0x00100704 in _start () at ../sysdeps/sparc/sparc64/start.S:88
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> (gdb) up
> [...]
>   0x00101fc8 <+344>:   add  %l4, %o0, %o0
>   0x00101fcc <+348>:   mov  %i1, %o1
>   0x00101fd0 <+352>:   call  0x2949c0
>   0x00101fd4 <+356>:   stx  %o0, [ %i4 + 0x20 ]
> => 0x00101fd8 <+360>:   sethi  %hi(0x4800), %g3
> 
> It seems 0x2949c0 is a unknown address, where it should be the memcpy one. 

Do you have the .o still for this? I would be interested to see what the
relocation was. One thing that has changed within the last week is enabling
PIE by default in GCC, though this call is a plain PC-relative one.

Regards,
James

Bug#854090: gcc-6: Please enable PIE hardening flags by default on sparc*

[James Clarke]

Package: gcc-6
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Please enable PIE by default on sparc and sparc64.

Regards,
James

Re: Grub2 with sparc64 patches

[James Clarke]

On 26 Jan 2017, at 17:08, Adrian Davey  wrote:
> On 2017-01-26 16:52, louis ayotte wrote:
>> On 2017-01-25 03:02 PM, John Paul Adrian Glaubitz wrote:
>>> On 01/25/2017 08:21 PM, Eric Snowberg wrote:
 I believe you are running out of memory here because grub is trying to 
 load all those frame buffer modules within your config.
> error: no suitable video mode found.
 And then it didn’t find one that worked.
 For this, I believe you are having the same problem as Frans.  Could you 
 add the following to /etc/default/grub:
 GRUB_TERMINAL_OUTPUT="console"
 GRUB_DISABLE_RECOVERY="true"
 GRUB_PRELOAD_MODULES=“iso9660"
 and then regenerate your grub.cfg with grub-mkconfig.
 Adrian,
 I don’t plan on adding frame buffer support since newer systems don’t have 
 them.  Would it be possible to change your grub package to include a 
 /etc/default/grub file for SPARC with the changes above?  We do the same 
 thing with our grub rpm.
>>> Oh, absolutely. Thanks for the suggestion. This was just the first package 
>>> and I'm happy to include
>>> all improvements that are necessary.
>>> Adrian
>> K applied these changes, in chroot
>>  GNU nano 2.7.4   File:
>> /etc/default/grub
>> # note that you can use only modes which your graphic card supports via VBE
>> # you can see them in real GRUB with the command `vbeinfo'
>> #GRUB_GFXMODE=640x480
>> # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
>> Linux
>> #GRUB_DISABLE_LINUX_UUID=true
>> # Uncomment to disable generation of recovery mode menu entries
>> #GRUB_DISABLE_RECOVERY="true"
>> # Uncomment to get a beep at grub start
>> #GRUB_INIT_TUNE="480 440 1"
>> GRUB_TERMINAL_OUTPUT="console"
>> GRUB_DISABLE_RECOVERY="true"
>> GRUB_PRELOAD_MODULES="iso9660"
>> Saved and exited
>> # grub-mkconfig
>> Generating grub configuration file ...
>> #
>> # DO NOT EDIT THIS FILE
>> #
>> # It is automatically generated by grub-mkconfig using templates
>> # from /etc/grub.d and settings from /etc/default/grub
>> #
>> ### BEGIN /etc/grub.d/00_header ###
>> insmod iso9660
>> if [ -s $prefix/grubenv ]; then
>>  set have_grubenv=true
>>  load_env
>> fi
>> if [ "${next_entry}" ] ; then
>>   set default="${next_entry}"
>>   set next_entry=
>>   save_env next_entry
>>   set boot_once=true
>> else
>>   set default="0"
>> fi
>> if [ x"${feature_menuentry_id}" = xy ]; then
>>  menuentry_id_option="--id"
>> else
>>  menuentry_id_option=""
>> fi
>> export menuentry_id_option
>> if [ "${prev_saved_entry}" ]; then
>>  set saved_entry="${prev_saved_entry}"
>>  save_env saved_entry
>>  set prev_saved_entry=
>>  save_env prev_saved_entry
>>  set boot_once=true
>> fi
>> function savedefault {
>>  if [ -z "${boot_once}" ]; then
>>saved_entry="${chosen}"
>>save_env saved_entry
>>  fi
>> }
>> function load_video {
>>  if [ x$feature_all_video_module = xy ]; then
>>insmod all_video
>>  else
>>insmod efi_gop
>>insmod efi_uga
>>insmod ieee1275_fb
>>insmod vbe
>>insmod vga
>>insmod video_bochs
>>insmod video_cirrus
>>  fi
>> }
>> terminal_output console
>> if [ "${recordfail}" = 1 ] ; then
>>  set timeout=30
>> else
>>  if [ x$feature_timeout_style = xy ] ; then
>>set timeout_style=menu
>>set timeout=5
>>  # Fallback normal timeout code in case the timeout_style feature is
>>  # unavailable.
>>  else
>>set timeout=5
>>  fi
>> fi
>> ### END /etc/grub.d/00_header ###
>> ### BEGIN /etc/grub.d/05_debian_theme ###
>> set menu_color_normal=cyan/blue
>> set menu_color_highlight=white/blue
>> ### END /etc/grub.d/05_debian_theme ###
>> ### BEGIN /etc/grub.d/10_linux ###
>> function gfxmode {
>>set gfxpayload="${1}"
>> }
>> set linux_gfx_mode=
>> export linux_gfx_mode
>> Found linux image: /boot/vmlinuz-4.9.0-1-sparc64-smp
>> Found initrd image: /boot/initrd.img-4.9.0-1-sparc64-smp
>> menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class
>> gnu --class os $menuentry_id_option
>> 'gnulinux-simple-2f8e4b53-061c-4878-9d30-bec179fb59e4' {
>>load_video
>>insmod gzio
>>if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
>>insmod part_sun
>>insmod ext2
>>set root='hd1,sun1'
>>if [ x$feature_platform_search_hint = xy ]; then
>>  search --no-floppy --fs-uuid --set=root
>> --hint-ieee1275='ieee1275//pci@400/pci@0/pci@8/scsi@0/disk@0,sun1'
>> --hint-bios=hd1,sun1 --hint-efi=hd1,sun1 --hint-baremetal=ahci1,sun1
>> eda75771-2b2f-4ef8-95f7-d007f3f3355a
>>else
>>  search --no-floppy --fs-uuid --set=root
>> eda75771-2b2f-4ef8-95f7-d007f3f3355a
>>fi
>>echo'Loading Linux 4.9.0-1-sparc64-smp ...'
>>linux/vmlinuz-4.9.0-1-sparc64-smp
>> root=UUID=2f8e4b53-061c-4878-9d30-bec179fb59e4 ro  quiet
>>echo'Loading initial ramdisk ...'
>>initrd/initrd.img-4.9.0-1-sparc64-smp
>> }
>> submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
>> 

Re: Bug#764432: FTBFS on sparc, segfault in TestAlignment

[James Clarke]

Control: tags -1 patch

On Wed, Oct 08, 2014 at 03:10:57AM +, Mike Gabriel wrote:
> Package: freerdp
> Version: 1.1.0~git20140921.1.440916e+dfsg1-2
> Severity: important
>
> Hi Aurelien, hi other porters,
>
> The freerdp version 1.1.0~git20140921.1.440916e+dfsg1-2 still shows FTBFS
> symptoms on Sparc architecture.
>
> """
> [...]
>
> 99% tests passed, 1 tests failed out of 89
>
> Total Test time (real) =   3.07 sec
>
> The following tests FAILED:
> Errors while running CTest
>16 - TestAlignment (SEGFAULT)
> make[1]: *** [test] Error 8
> Makefile:140: recipe for target 'test' failed
> make[1]: Leaving directory
> '/«BUILDDIR»/freerdp-1.1.0~git20140921.1.440916e+dfsg1/obj-sparc-linux-gnu'
> make: *** [debian/stamp-makefile-check] Error 2
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
> /usr/share/cdbs/1/class/makefile.mk:67: recipe for target
> 'debian/stamp-makefile-check' failed
> """
>
> Any help to dig this out is appreciated...
>
> Thanks,
> Mike
>
>
> --
>
> DAS-NETZWERKTEAM
> mike gabriel, herweg 7, 24357 fleckeby
> fon: +49 (1520) 1976 148
>
> GnuPG Key ID 0x25771B31
> mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
>
> freeBusy:
> https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

I had a look at it today. It isn't actually segfaulting, it's getting a
bus error, but somewhere in the testing framework this gets treated the
same as a segfault. The problem lies because the _aligned_offset_malloc
code doesn't ensure that the *header* is aligned, and it then tries to
dereference an unaligned header pointer, if a non-zero offset is given
(well, if you give offset as a multiple of 8, that's fine, since it
won't break the alignment). The attached patch ensures that the header
is always pointer-size-aligned. In fact, since Debian uses gcc, it could
use __alignof__(struct _aligned_meminfo) instead of sizeof(void *), but
that's not portable.

Regards,
James
Description: Ensure the _aligned_meminfo pointer itself is sufficiently aligned
Author: James Clarke <jrt...@jrtc27.com>

--- a/winpr/libwinpr/crt/alignment.c
+++ b/winpr/libwinpr/crt/alignment.c
@@ -73,15 +73,20 @@ void* _aligned_offset_malloc(size_t size
if (alignment < sizeof(void*))
alignment = sizeof(void*);
 
-   /* malloc size + alignment to make sure we can align afterwards */
-   tmpptr = malloc(size + alignment + sizeof(struct _aligned_meminfo));
+   /* malloc size + alignment to make sure we can align afterwards.
+* Include an extra sizeof(void*) to ensure there's always space to 
align
+* ameminfo downwards, in case malloc doesn't align to sizeof(void*). 
This
+* could be dropped if there was a portable way to get alignof(struct
+* _aligned_meminfo), but instead we have to overestimate with
+* sizeof(void*). */
+   tmpptr = malloc(size + alignment + sizeof(struct _aligned_meminfo) + 
sizeof(void*));
if (!tmpptr)
return NULL;
 
 
-   memptr = (void *)size_t)((PBYTE)tmpptr + alignment + offset + 
sizeof(struct _aligned_meminfo)) & ~(alignment - 1)) - offset));
+   memptr = (void *)size_t)((PBYTE)tmpptr + alignment + offset + 
sizeof(struct _aligned_meminfo) + sizeof(void*)) & ~(alignment - 1)) - offset));
 
-   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memptr - 
sizeof(struct _aligned_meminfo;
+   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memptr - 
sizeof(struct _aligned_meminfo))) & ~(sizeof(void*)-1));
ameminfo->base_addr = tmpptr;
ameminfo->size = size;
 
@@ -107,7 +112,7 @@ void* _aligned_offset_realloc(void* memb
if (!newmem)
return NULL;
 
-   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memblock - 
sizeof(struct _aligned_meminfo;
+   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memblock - 
sizeof(struct _aligned_meminfo))) & ~(sizeof(void*)-1));
memcpy(newmem, memblock, ameminfo->size);
_aligned_free(memblock);
return newmem;
@@ -129,7 +134,7 @@ void _aligned_free(void* memblock)
if (!memblock)
return;
 
-   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memblock - 
sizeof(struct _aligned_meminfo;
+   ameminfo = (struct _aligned_meminfo *) (((size_t)((PBYTE)memblock - 
sizeof(struct _aligned_meminfo))) & ~(sizeof(void*)-1));
 
free(ameminfo->base_addr);
 }

Bug#852401: SIGBUS due to gdk_x11_window_set_opacity on sparc64

[James Clarke]

Source: gtk+2.0
Version: 2.24.31-1
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Control: affects -1 libgtk2-perl
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=777683

Hi,
Currently, libgtk2-perl crashes in its testsuite in a call to
gdk_x11_window_set_opacity with a SIGBUS. This turns out to be a bug in
GTK+, which was fixed in GTK+3.0 but never backported. Patch attached.

Regards,
James
>From 710f538d68e6f9ca0b2fbe38df3f8ee35ddd0126 Mon Sep 17 00:00:00 2001
From: James Clarke <jrt...@jrtc27.com>
Date: Tue, 24 Jan 2017 08:35:28 +
Subject: [PATCH] Don't use guint32 with XChangeProperty

Fixes bug 777683.
---
 gdk/x11/gdkwindow-x11.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdk/x11/gdkwindow-x11.c b/gdk/x11/gdkwindow-x11.c
index 837f605..887a5ef 100644
--- a/gdk/x11/gdkwindow-x11.c
+++ b/gdk/x11/gdkwindow-x11.c
@@ -5575,7 +5575,7 @@ gdk_window_set_opacity (GdkWindow *window,
gdoubleopacity)
 {
   GdkDisplay *display;
-  guint32 cardinal;
+  gulong cardinal;
   
   g_return_if_fail (GDK_IS_WINDOW (window));
 
-- 
2.11.0

libx11: Issues with Data32/_XData32

[James Clarke]

Hi,
I've been debugging an issue in gtk2-perl causing it to SIGBUS on
sparc64, and traced it back to what seems to be dodgy code inside
libx11. One of the tests calls gdk_window_set_opacity, which calls
XChangeProperty with a pointer to a guint32, cast to char*, with the
length set to 32 bits as expected. However, this data pointer then gets
cast to a (long *) on line 83 of ChProp.c when calling Data32. Indeed,
the definition of Data32 specifies that data is a (long *) on sparc64,
since LONG64 is defined. This feels very wrong, but in and of itself is
not too bad (I believe it violates strict aliasing).

The problem really comes inside the implementation of _XData32. The
destination buffer, buf, is an (int *), but data is still a (long *).
These are not the same size. The issues with this are as follows:

 1. Incrementing data increases the pointer by 8, so it skips over every
other 4-byte int, and reads twice as many bytes as it should.

 2. On big-endian systems, (int)*(long *)an_int_pointer will end up
getting the 4 bytes *after* an_int_pointer, which means it gets
completely the wrong data even in the case of len being 4 (bytes).

 3. On sparc64, pointers have strict alignment requirements - they must
be size aligned (ie (int *) must be 4-byte aligned, (long *) must be
8-byte aligned). In this case, the data pointer (which came all the
way from gdk_window_set_opacity) is only 4-byte aligned (which is
fine, since it's a pointer to a guint32), but it has been cast to a
(long *) and dereferenced, so it is required to be 8-byte aligned.
This is the cause of the observed crash.

However, I wonder how 1. is not seen currently given the wide use
of X11 on amd64. I can only assume 2. not being seen is because the only
64-bit big-endian architectures are generally used for servers, and
there aren't many of them.

I don't know what the solution to the problem is. There are various
places in the call stack where this could be fixed up. The "correct" fix
seems to be to change Data32 to take an (int *) (or some other data type
of your choosing if you're worried about int's size not being portable)
and fix up the casts at all the call sites, but this is an intrusive
change to a public header, and I worry that there are things out there
relying on the current behaviour.

Alternatively, Data32 could be altered to still take a (long *), but
cast it back to an (int *). This has the advantage of not touching
public headers, but the prototype is then lying about what it's actually
doing, and this still has the problem of breaking behaviour.

The final, ugly alternative, is to alter XChangeProperty so it makes a
copy of data as an array of long, padding or sign-extending each
element, before passing it to Data32.

I can't claim to have spent much time looking through the code, so it's
highly likely I've missed something. Could those with more knowledge
please comment on the above?

Thanks,
James

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

[James Clarke]

On 15 Jan 2017, at 19:32, László Böszörményi (GCS)  wrote:
> On Sun, Jan 15, 2017 at 7:26 PM, Simon McVittie  wrote:
>> On Sun, 15 Jan 2017 at 17:06:00 +0100, John Paul Adrian Glaubitz wrote:
>>> For the time being, Firefox upstream is now using the arm64 workaround on 
>>> sparc64
>>> as well which fixed Firefox on sparc64. Firefox will be fixed on sparc64 
>>> with
>>> version 53.
>> 
>> Can you point those interested in this bug to a patch/commit/something that
>> describes "the arm64 workaround"? Is it related to #839050?
> I think Adrian refers to the upstream bugreport #1275204 [1] and two
> fixes[2][3]. Any other patches I should backport? I attach a debdiff
> for testing.

Not sure why you listed it as an NMU in d/changelog, given you're the
maintainer :)

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1275204
> [2] https://hg.mozilla.org/integration/mozilla-inbound/rev/f9307a83e555

This one only affects NetBSD. Might as well backport it though.

> [3] https://hg.mozilla.org/integration/mozilla-inbound/rev/0cb0fe7e92f6

This is the important one. Adrian, is there anything else?

Regards,
James

Re: Bug#827815: libmozjs-24-0: initialization segfaults on sparc64

[James Clarke]

On 15 Jan 2017, at 18:26, Simon McVittie  wrote:
> On Sun, 15 Jan 2017 at 17:06:00 +0100, John Paul Adrian Glaubitz wrote:
>> For the time being, Firefox upstream is now using the arm64 workaround on 
>> sparc64
>> as well which fixed Firefox on sparc64. Firefox will be fixed on sparc64 with
>> version 53.
> 
> Can you point those interested in this bug to a patch/commit/something that
> describes "the arm64 workaround"? Is it related to #839050?

The upstream commit is 0cb0fe7e92f6[1]. Essentially, it loops over a range of
possible addresses, trying to mmap them until it finds a free one that's big
enough. Ugly, but there's not much alternative until they fix their tagging.
Perhaps we could get this patch included in Debian, if it's not going to be
included in an upstream release soon? I see it was already NMU'ed on arm64 to
fix it there.

Regards,
James

[1] http://hg.mozilla.org/mozilla-central/rev/0cb0fe7e92f6

Bug#851176: FTBFS on sparc64: invalid heap expanding (base_length: 89, GC.stat[:heap_eden_pages]: 92)

[James Clarke]

Source: ruby2.3
Version: 2.3.3-1
Severity: important
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Currently, ruby2.3 FTBFS on sparc64 (and has done for a while) due to a
single test case failure:

>   1) Failure:
> TestGc#test_expand_heap [/<>/test/ruby/test_gc.rb:293]:
> invalid heap expanding (base_length: 89, GC.stat[:heap_eden_pages]: 92).
> Expected |89 - 92| (3) to be <= 2.
>
> 15901 tests, 2236055 assertions, 1 failures, 0 errors, 82 skips

I see that the threshold was initially 1, but was bumped up to 2 by
upstream. Is this failure indicative of a problem, or should the
threshold be further relaxed?

The porterbox notker.debian.net is available to all DDs. I have not
tried reproducing this bug on it, but the consistent failure across 3
different buildds gives me confidence that it can be reproduced on
notker.

Regards,
James

Bug#850250: FTBFS on sparc with DEB_BUILD_OPTIONS=nolang=biarch

[James Clarke]

Source: gcc-6
Version: 6.3.0-2
Tags: patch
User: debian-sparc@lists.debian.org
Usertag: sparc
X-Debbugs-Cc: helm...@debian.org, debian-sparc@lists.debian.org

Thanks to the recent changes to get gcc to target ultrasparc by default,
the biarch build is now successful. However, it still fails in exactly
the same way when biarch is disabled; I believe the following patch
should fix this. Is there a good reason why this wasn't done before,
other than an oversight?

Regards,
James

> --- debian/rules2.orig  2017-01-05 11:06:00.846518693 +
> +++ debian/rules2   2017-01-05 11:08:24.644346025 +
> @@ -543,9 +543,9 @@
>  endif
>
>  ifneq (,$(findstring sparc-linux,$(DEB_TARGET_GNU_TYPE)))
> +  CONFARGS += --with-cpu-32=ultrasparc
>ifeq ($(biarch64),yes)
>  CONFARGS += --enable-targets=all
> -CONFARGS += --with-cpu-32=ultrasparc
>endif
>  endif
>

Bug#849542: PIE specs ignored even with DEB_BUILD_MAINT_OPTIONS hardening

[James Clarke]

Package: gcc-6
Version: 6.2.1-7
Severity: important

The check introduced to ignore dpkg's PIE specs when PIE is not enabled
by default is wrong, and ends up ignoring them even when hardening=+all
or hardening=+pie is present in DEB_BUILD_MAINT_OPTIONS.

The current check is:

>   if (ignore_pie_specs_when_not_enabled("DEB_BUILD_MAINT_OPTIONS", arg)
>  || ignore_pie_specs_when_not_enabled("DEB_BUILD_OPTIONS", arg))

but since only DEB_BUILD_MAINT_OPTIONS includes the hardening options,
the second call with DEB_BUILD_OPTIONS returns true and causes the file
to be ignored. I believe this should be && rather than ||.

I can reproduce this regression by building one of my packages
(src:polyml) on sparc64:

> $ grep hardening debian/rules
> export DEB_BUILD_MAINT_OPTIONS=hardening=+all
> $ dpkg-buildpackage -us -uc
> [...]
> g++: note: pie specs /usr/share/dpkg/pie-compile.specs ignored when pie is 
> not enabled

Regards,
James

Re: XVR500 and SysVInit

[James Clarke]

Hi,
> 
> On 21 Dec 2016, at 13:36, transmail  wrote:
> 
> Hi.
>  
> I just would like to know, if the Sparc64 port of Debian 9 will
> support my XVR500 card in my Sun Blade 100

The kernel's config has CONFIG_FB_XVR500=y (as well as 2500 and 1000),
so I assume yes.

> and also i would like to know, that if there will be SysVInit in the
> binary repos, so i can just replace systemd with SysVInit.

Yes, sysvinit is available. In theory it should work, although in
practice I can't guarantee anything; systemd has much more testing in
Debian these days. I don't understand all the hate for systemd (and
don't want to start a debate), but I appreciate that people have their
reasons for not choosing it.

Regards,
James

Re: Kernel Panic with updating

[James Clarke]

> On 8 Dec 2016, at 17:31, Louis Liu  wrote:
> 
> Hi all,
> 
> My system panics when updating packages.
> 
> System:
> Sun Netra T1-105
> Linux FirstRangers 4.8.0-1-sparc64 #1 Debian 4.8.7-1 (2016-11-13)
> sparc64 GNU/Linux
> 
> The system panics every time with the command:
> root@FirstRangers:~# dpkg --configure -a
> Setting up systemd (232-7) ...
> addgroup: The group `systemd-journal' already exists as a system group. 
> Exiting.
> 
> panic message:
> 
> [575227.880355] CPU: 0 PID: 1 Comm: systemd Not tainted
> 4.8.0-1-sparc64 #1 Debian 4.8.7-1
> [575227.984570] task: f800360ac020 task.stack: f800360e
> [575228.063583] TSTATE: 11001600 TPC: 007951e4 TNPC:
> 007951e8 Y: 1cc01dbaNot tainted
> [575228.194131] TPC: 
> [575228.245660] g0:  g1: 102987e8 g2:
>  g3: 001d
> [575228.361315] g4: f800360ac020 g5: 00b3ac24 g6:
> f800360e g7: 0001
> [575228.476949] o0: 00b42cd8 o1: 000a o2:
> 00eb o3: 0002
> [575228.592584] o4: 07feff91f270 o5:  sp:
> f800360e2f81 ret_pc: 007951a0
> [575228.712803] RPC: 
> [575228.764360] l0: 00b42c00 l1: 00031fdbe203 l2:
> f80035e1bee0 l3: 
> [575228.880012] l4: 0001 l5: 010b4750 l6:
> f800360e l7: 
> [575228.995645] i0: f80034483d50 i1: f80033d8f640 i2:
> 00b42c00 i3: 00b42cf0
> [575229.111281] i4: 00eb i5: 102987d0 i6:
> f800360e3031 i7: 005b48b0
> [575229.226931] I7: 
> [575229.279609] Call Trace:
> [575229.312906]  [005b48b0] chrdev_open+0x90/0x120
> [575229.381658]  [005acd0c] do_dentry_open+0x22c/0x360
> [575229.454959]  [005adccc] vfs_open+0x4c/0x80
> [575229.519119]  [005be928] path_openat+0x188/0x11c0
> [575229.590143]  [005c0ab0] do_filp_open+0x50/0xc0
> [575229.658880]  [005ae114] do_sys_open+0x134/0x220
> [575229.728758]  [005ae224] SyS_open+0x24/0x40
> [575229.792930]  [004060b4] linux_sparc_syscall+0x34/0x44


Was there anything else about the type of panic? Does an older kernel
work? If so, please try booting an older working kernel and update to
4.8.11-1, which has some sparc64 fixes.

Regards,
James

Re: git kernel (4.9.0-rc5; was 4.9.0-rc3) hard lockup on cpu

[James Clarke]

Here’s a more detailed dump for a 4.9.0-rc5+ kernel (commit
81bcfe5e48f9b8c42cf547f1c74c7f60c44c34c8). If I’m interpreting the output
correctly, it seems the kworkers are all blocked on RCU barriers, waiting for
an outstanding request, presumably because CPU 64 didn’t perform its requested
action (is the 0xfff8000ea7097c48 some kind of PC corruption, or just a user
space address?). Thoughts?

Regards,
James

[8752781.281403] Watchdog detected hard LOCKUP on cpu 64[8752781.281524] 
[ cut here ]
[8752781.281542] WARNING: CPU: 64 PID: 204238 at arch/sparc/kernel/nmi.c:80 
perfctr_irq+0x310/0x360
[8752781.281559] Modules linked in:
c tcp_diag
c inet_diag
c unix_diag
c 
netlink_diag
c dccp_ipv4
c dccp
c tun
c xt_tcpudp
c xt_multiport
c 
xt_conntrack
c iptable_filter
c iptable_nat
c nf_conntrack_ipv4
c 
nf_defrag_ipv4
c nf_nat_ipv4
c nf_nat
c nf_conntrack
c n2_rng
c flash
c 
rng_core
c camellia_sparc64
c des_sparc64
c des_generic
c aes_sparc64
c 
md5_sparc64
c sha512_sparc64
c sha256_sparc64
c sha1_sparc64
c ip_tables
c 
x_tables
c autofs4
c ext4
c crc16
c jbd2
c fscrypto
c mbcache
c btrfs
c xor
c 
zlib_deflate
c raid6_pq
c crc32c_sparc64
c sunvnet
c sunvdc
c
[8752781.281609] CPU: 64 PID: 204238 Comm: cc1plus Tainted: G L  
4.9.0-rc5+ #2
[8752781.281623] Call Trace:
[8752781.281632]  [00468520] __warn+0xc0/0xe0
[8752781.281641]  [00468574] warn_slowpath_fmt+0x34/0x60
[8752781.281650]  [00a70d10] perfctr_irq+0x310/0x360
[8752781.281660]  [004209f4] tl0_irq15+0x14/0x20
[8752781.281670] ---[ end trace 7e95909338ac2698 ]---
[8752842.316164] INFO: rcu_sched detected stalls on CPUs/tasks:
[8752842.316212]64-...: (0 ticks this GP) idle=2ad/140/0 
softirq=12887641/12887641 fqs=0 
[8752842.316232](detected by 20, t=6502 jiffies, g=9924284, c=9924283, 
q=104887)
[8752842.316278] Task dump for CPU 64:
[8752842.316287] cc1plus R  running task0 210491 210470 
0x20800010200
[8752842.316306] Call Trace:
[8752842.316318]  [fff8000ea7097c48] 0xfff8000ea7097c48
[8752842.316332] rcu_sched kthread starved for 6502 jiffies! g9924284 c9924283 
f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
[8752842.316345] rcu_sched   S0 7  2 0x0600
[8752842.316357] Call Trace:
[8752842.316378]  [00a6a930] schedule+0x30/0xc0
[8752842.316391]  [00a6f284] schedule_timeout+0x224/0x480
[8752842.316410]  [004f777c] rcu_gp_kthread+0x75c/0x1f00
[8752842.316428]  [00491c00] kthread+0xc0/0x100
[8752842.316445]  [00406084] ret_from_fork+0x1c/0x2c
[8752842.316455]  []   (null)
[8752869.431088] INFO: rcu_sched detected stalls on CPUs/tasks:
[8752869.431133]64-...: (33 GPs behind) idle=eac/0/0 
softirq=12887641/12887641 fqs=1 
[8752869.431152](detected by 26, t=6502 jiffies, g=9924317, c=9924316, 
q=43778)
[8752869.431204] Task dump for CPU 64:
[8752869.431215] swapper/64  R  running task0 0  1 
0x0500
[8752869.431236] Call Trace:
[8752869.431259]  [005134c0] tick_nohz_idle_enter+0x40/0xa0
[8752869.431276] rcu_sched kthread starved for 6498 jiffies! g9924317 c9924316 
f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
[8752869.431292] rcu_sched   S0 7  2 0x0600
[8752869.431306] Call Trace:
[8752869.431326]  [00a6a930] schedule+0x30/0xc0
[8752869.431341]  [00a6f284] schedule_timeout+0x224/0x480
[8752869.431360]  [004f777c] rcu_gp_kthread+0x75c/0x1f00
[8752869.431381]  [00491c00] kthread+0xc0/0x100
[8752869.431400]  [00406084] ret_from_fork+0x1c/0x2c
[8752869.431413]  []   (null)
[8752925.429157] INFO: task kworker/66:38:113388 blocked for more than 120 
seconds.
[8752925.429193]   Tainted: GWL  4.9.0-rc5+ #2
[8752925.429206] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
[8752925.429223] kworker/66:38   D0 113388  2 0x0600
[8752925.429255] Workqueue: cgroup_destroy css_free_work_fn
[8752925.429268] Call Trace:
[8752925.429290]  [00a6a930] schedule+0x30/0xc0
[8752925.429305]  [00a6adb8] schedule_preempt_disabled+0x18/0x40
[8752925.429319]  [00a6bc0c] mutex_lock_nested+0x18c/0x3e0
[8752925.429338]  [004f1f0c] _rcu_barrier+0x4c/0x2a0
[8752925.429351]  [004f2190] rcu_barrier+0x10/0x20
[8752925.429365]  [005df674] release_caches+0x54/0x80
[8752925.429378]  [005df738] memcg_destroy_kmem_caches+0x98/0xe0
[8752925.429400]  [0062b660] mem_cgroup_css_free+0xe0/0x140
[8752925.429413]  [0052e194] css_free_work_fn+0x34/0x8a0
[8752925.429429]  [0048977c] process_one_work+0x21c/0x7a0
[8752925.429442]  [00489e30] worker_thread+0x130/0x540
[8752925.429458]  [00491c00] kthread+0xc0/0x100
[8752925.429476]  [00406084] ret_from_fork+0x1c/0x2c
[8752925.429487]  []   (null)
[8752925.429495] 

Re: Segmentation faults with aptitude and apt-get on some packages

[James Clarke]

> On 28 Nov 2016, at 22:07, rod  wrote:
>> On 11/18/2016 4:32 PM, John Paul Adrian Glaubitz wrote:
>>> On 11/16/2016 06:13 PM, rod wrote:
>>> The current problem I'm having is this:
>>> 
>>> root@mw-monitor:/home/rod# aptitude
>>> Ouch!  Got SIGSEGV, dying..
>>> Segmentation fault
>> 
>> This has turned out to be an issue with libstdc++6 which comes from the gcc-6
>> package which was built with a broken version of binutils. The buildds are
>> currently building a fresh gcc-6 package which is being built with a fixed
>> version of binutils which should mitigate the problem.
>> 
>> For anyone experiencing the issue, here is a quick workaround to fix apt
>> for the time being until the buildds have finished building the new gcc-6
>> package (which should be in around 2-3 hours).
>> 
>> Fix:
>> 
>> $ wget 
>> http://snapshot.debian.org/archive/debian-ports/20161022T004918Z/pool-sparc64/main/g/gcc-6/gcc-6-base_6.2.0-9_sparc64.deb
>>  \
>>   
>> http://snapshot.debian.org/archive/debian-ports/20161022T004918Z/pool-sparc64/main/g/gcc-6/libstdc%2B%2B6_6.2.0-9_sparc64.deb
>> $ dpkg -i gcc-6-base_6.2.0-9_sparc64.deb libstdc++6_6.2.0-9_sparc64.deb
>> 
>> Once gcc-6_6.2.1-3 has finished building on sparc64 here [1], it should be
>> safe to dist-upgrade the machine again.
>> 
>> Please let us know when you encounter any other issues.
>> 
>> Adrian
>> 
>>> [1] https://buildd.debian.org/status/package.php?p=gcc-6=sid
>> 
> Using the above thread and after installing several packages (apache2,
> mariadb, phpmyadmin, webmin, & shellinabox and their associated
> requirement packages);  I got the following crash and had to reboot.
> 
> [ 2983.405916] systemd[1]: apt-daily.timer: Adding 10h 21min 29.083051s
> random time.
> [ 2987.766873] systemd[1]: apt-daily.timer: Adding 4h 3min 23.373286s
> random time.
> [ 3049.054254]   \|/  \|/
> [ 3049.054254]   "@'/ .. \`@"
> [ 3049.054254]   /_| \__/ |_\
> [ 3049.054254]  \__U_/
> [ 3049.247708] systemd(1): Kernel illegal instruction [#1]
> [ 3049.316397] CPU: 0 PID: 1 Comm: systemd Not tainted
> 4.8.0-1-sparc64-smp #1 Debian 4.8.5-1
> [ 3049.424029] task: fff000123e14f620 task.stack: fff000123e158000
> [ 3049.501869] TSTATE: 004411001603 TPC: 005ca4a8 TNPC:
> 005ca4ac Y: Not tainted
> [ 3049.631240] TPC: <__kmalloc_track_caller+0x128/0x200>
> [ 3049.697661] g0:  g1: 0040 g2:
>  g3: 0001
> [ 3049.812168] g4: fff000123e14f620 g5: fff000123ebc6000 g6:
> fff000123e158000 g7: 00636500
> [ 3049.926669] o0:  o1: 024000c0 o2:
>  o3: 
> [ 3050.041113] o4:  o5:  sp:
> fff000123e15af01 ret_pc: 005ca4a0
> [ 3050.160172] RPC: <__kmalloc_track_caller+0x120/0x200>
> [ 3050.226606] l0: fff000123e0032e0 l1: 4000 l2:
> fff000123e004898 l3: 000c28fb0d68
> [ 3050.341088] l4:  l5: fff000123f80f328 l6:
> 000c28fb0d88 l7: fff100e9a000
> [ 3050.455564] i0: fff000123e0032e0 i1: 024000c0 i2:
> 0058c47c i3: 024000c0
> [ 3050.570055] i4: 000b i5: 024000c0 i6:
> fff000123e15afb1 i7: 0058c408
> [ 3050.635685]   \|/  \|/
> [ 3050.635685]   "@'/ .. \`@"
> [ 3050.635685]   /_| \__/ |_\
> [ 3050.635685]  \__U_/
> [ 3050.635690] systemd-journal(209): Kernel illegal instruction [#2]
> [ 3050.635698] CPU: 1 PID: 209 Comm: systemd-journal Not tainted
> 4.8.0-1-sparc64-smp #1 Debian 4.8.5-1
> [ 3050.635701] task: fff00012049dc080 task.stack: fff000123d1dc000
> [ 3050.635705] TSTATE: 004411001604 TPC: 005ca4a8 TNPC:
> 005ca4ac Y: Not tainted
> [ 3050.635718] TPC: <__kmalloc_track_caller+0x128/0x200>
> [ 3050.635720] g0: fff000123d1dee71 g1: 0040 g2:
>  g3: c000
> [ 3050.635723] g4: fff00012049dc080 g5: fff000123edc6000 g6:
> fff000123d1dc000 g7: fff000123edc6000
> [ 3050.635725] o0:  o1: 025106c0 o2:
> fff000123de2dc20 o3: 00b15c00
> [ 3050.635727] o4:  o5:  sp:
> fff000123d1deed1 ret_pc: 005ca4a0
> [ 3050.635731] RPC: <__kmalloc_track_caller+0x120/0x200>
> [ 3050.635734] l0: fff000123e003220 l1: 4000 l2:
> f000 l3: fff0001204c54e40
> [ 3050.635736] l4:  l5:  l6:
>  l7: fff100327e90
> [ 3050.635738] i0: fff000123e003220 i1: 025106c0 i2:
> 00862a1c i3: 025106c0
> [ 3050.635740] i4: 0180 i5: 025106c0 i6:
> fff000123d1def81 i7: 00862960
> [ 3050.635751] I7: <__kmalloc_reserve.isra.5+0x20/0x80>
> [ 3050.635752] Call Trace:
> [ 3050.635757]  [00862960] __kmalloc_reserve.isra.5+0x20/0x80
> [ 3050.635760]  [00862a1c] 

Re: New Debian sparc installation images

[James Clarke]

> On 27 Nov 2016, at 18:29, John Paul Adrian Glaubitz 
>  wrote:
> 
> Hi Kieron!
> 
>> On 11/27/2016 04:10 PM, Kieron Gillespie wrote:
>> Nov 27 14:59:50 debootstrap: sh: apt_dest: unknown operand
>> Nov 27 14:59:50 debootstrap: /usr/sbin/debootstrap: line 607: : Permission 
>> denied
> 
> This look like a general issue in debian-installer, i.e. not specific to 
> sparc64.
> 
> Looking at the source of debootstrap:607 [1], there is just a closing "if" 
> statement
> at this line, so I don't really see where the "Permission denied" should come 
> from.
> 
> My first guess was that it's related with the usr-merge which was by enabled 
> by default
> on debootstrap recently, but I currently have no idea really.

Is this to a freshly-formatted partition, or one with
a pre-existing /bin etc? I've seen issues running
debootstrap on the latter before.

Regards,
James

Re: [PATCH] silo: Add 64-bit support

[James Clarke]

> On 24 Nov 2016, at 22:26, John Paul Adrian Glaubitz 
>  wrote:
> 
> On 11/24/2016 11:05 PM, Aaro Koskinen wrote:
>> I think that's your job to try. If you want to "add 64-bit support"
>> (instead of forcing it to everybody), do the required changes so that
>> it's still works for everybody without extra fiddling.
> 
> Don't be so rude, I'm not forcing anything onto anyone.
> 
 Also you broke the tilo build...
>>> 
>>> Not here. Just tried it again and it builds fine. Can you be more specific?
>> 
>> The same issue as with silo.
> 
> Don't you think your statements are a bit misleading then? I didn't break 
> anything,
> I changed the default target to 64-bit which is somewhat reasonable in the 
> year
> 2016, isn't it.
> 
> Or are you going to tell me now that your 333 MHz, 128 MiB RAM Sun Ultra 5 is
> your everyday production machine?

Part of the problem is not forcing 64-bit, but that the Makefile is 
inconsistent.
The default CC is gcc without any flags, but ld is given -m elf64_sparc. If you
are running with sparc32 as your default target, gcc will generate 32-bit files
but ld expects 64-bit. If you really want to force 64-bit, you should also pass
appropriate -m64/-64 flags to gcc/as. However, I think the sensible, least
controversial solution is to just drop the -m elf64_sparc and let everything
be the default. It was only changed to force 32-bit in c836dbda because 64-bit
support wasn’t present.

Regards,
James

Bug#844782: Please revert problematic sparc64 GOT patch

[James Clarke]

Source: binutils
Version: 2.27.51.20161118-1
Severity: important
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi Matthias,
While global symbol references are now fine, we've noticed that TLS is
broken in a similar way, except in this case the linker can't do much to
fix it up unless it wants to patch the opcodes themselves. This has the
very bad side effect of causing apt-get to segfault in libstdc++. Until
this gets properly dealt with upstream, could you please revert the
relevant patch[1]?

James

[1] b19753ce31da347605dfa903c6fd2158e2444f0d

Re: Segmentation faults with aptitude and apt-get on some packages

[James Clarke]

> On 16 Nov 2016, at 22:26, rod <r.schn...@mythos.freeddns.org> wrote:
>> On 11/16/2016 2:12 PM, rod wrote:
>>> On 11/16/2016 1:32 PM, James Clarke wrote:
>>> Hi Rod,
>>>> On 16 Nov 2016, at 17:13, rod <r.schn...@mythos.freeddns.org> wrote:
>>>> 
>>>> I followed the guide you wrote (after dumping debian for solaris to
>>>> reset the sc> password). It works well as written, covering all the
>>>> issues that came up.
>>>> 
>>>> The current problem I'm having is this:
>>>> 
>>>> root@mw-monitor:/home/rod# aptitude
>>>> Ouch!  Got SIGSEGV, dying..
>>>> Segmentation fault
>>>> 
>>>> or
>>>> 
>>>> root@mw-monitor:/home/rod# apt-get install gunzip
>>>> Reading package lists... Done
>>>> Building dependency tree
>>>> Reading state information... Done
>>>> ESegmentation fault
>>>> 
>>>> with this on the console:
>>>> 
>>>> [ 1656.976655] apt-get[545]: segfault at fff200794008 ip
>>>> fff100015994 (rpc fff100015970) sp 07feffa705b1 error 30001
>>>> in ld-2.24.so[fff1+22000]
>>>> 
>>>> Any ideas?
>>> 
>>> We’ve had to rebuild ~1700 packages built in the last couple of weeks,
>>> since they were built with a broken binutils. My guess is that aptitude
>>> was broken by this (it’s one of the packages built during that time
>>> period).  I am however surprised that apt-get is segfaulting; that was
>>> built well before any of this mess. If I run that command I get this:
>>> 
>>> # apt-get install gunzip
>>> Reading package lists... Done
>>> Building dependency tree   
>>> Reading state information... Done
>>> E: Unable to locate package gunzip
>>> 
>>> That’s with the latest version (1.3.1). FYI, there is no gunzip package;
>>> it’s included in gzip.
>>> 
>>> If you want to get a working system set up now, I suggest you reinstall
>>> with your mirror configured to a snapshot taken before 2nd November using
>>> http://snapshot.debian.org/archive/debian-ports/, as it’s going to be a
>>> few days before everything has finished building. Unfortunately we weren’t
>>> aware of the problem and how widespread it was when you were installing.
>>> 
>>> Regards,
>>> James
>> 
>> Thanks James.  I did look at the buildd page and saw large number
>> working on being rebuilt and thought it might be something like this.
>> 
>> I will change the mirror and reload simple for quickness.
>> 
>> I figured it was better to mention it...
>> 
>> Rod
> 
> OK so new question...
> Once I've done the reinstall from the archive should I do apt-get update
> && apt-get upgrade followed by apt-get dist-upgrade?  Will it grab from
> the newly built packages? Will it bork the newly installed system?

You can, but it won’t do anything, since the installer should have put the
snapshot mirror in your /etc/apt/sources.list, so as far as it’s concerned
everything is up to date. Once everything has been rebuilt, you can put the
original mirror configuration back in /etc/apt/sources.list and do an upgrade.

Regards,
James

Re: Segmentation faults with aptitude and apt-get on some packages

[James Clarke]

Hi Rod,
> On 16 Nov 2016, at 17:13, rod  wrote:
> 
> I followed the guide you wrote (after dumping debian for solaris to
> reset the sc> password). It works well as written, covering all the
> issues that came up.
> 
> The current problem I'm having is this:
> 
> root@mw-monitor:/home/rod# aptitude
> Ouch!  Got SIGSEGV, dying..
> Segmentation fault
> 
> or
> 
> root@mw-monitor:/home/rod# apt-get install gunzip
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> ESegmentation fault
> 
> with this on the console:
> 
> [ 1656.976655] apt-get[545]: segfault at fff200794008 ip
> fff100015994 (rpc fff100015970) sp 07feffa705b1 error 30001
> in ld-2.24.so[fff1+22000]
> 
> Any ideas?

We’ve had to rebuild ~1700 packages built in the last couple of weeks,
since they were built with a broken binutils. My guess is that aptitude
was broken by this (it’s one of the packages built during that time
period).  I am however surprised that apt-get is segfaulting; that was
built well before any of this mess. If I run that command I get this:

# apt-get install gunzip
Reading package lists... Done
Building dependency tree   
Reading state information... Done
E: Unable to locate package gunzip

That’s with the latest version (1.3.1). FYI, there is no gunzip package;
it’s included in gzip.

If you want to get a working system set up now, I suggest you reinstall
with your mirror configured to a snapshot taken before 2nd November using
http://snapshot.debian.org/archive/debian-ports/, as it’s going to be a
few days before everything has finished building. Unfortunately we weren’t
aware of the problem and how widespread it was when you were installing.

Regards,
James

Re: configure sources.list

[James Clarke]

> On 14 Nov 2016, at 21:55, John Paul Adrian Glaubitz 
> <glaub...@physik.fu-berlin.de> wrote:
>> On 11/14/2016 10:53 PM, James Clarke wrote:
>> Except it’s not in main (the clue’s in the name)...
> 
> Right. Then it's probably a good idea to add "contrib" and "non-free"
> with [arch=all] to the sources.list on any machine running a ports
> architecture.
> 
> I think that should work, e.g:
> 
> deb [arch=all] ftp://ftp.de.debian.org/debian contrib non-free

I didn’t know all could now be treated as a proper architecture, but
it does work. You missed off the codename though:

deb [arch=all] http://ftp.de.debian.org/debian unstable contrib non-free

Replace ftp.de.debian.org with your favourite mirror (same one you would
use for amd64).

James

Re: configure sources.list

[James Clarke]

> On 14 Nov 2016, at 21:51, John Paul Adrian Glaubitz 
>  wrote:
> 
> On 11/14/2016 10:29 PM, rod wrote:
>> Suggestions on how to get rid of the tg3 error? Should I even be
>> bothered by them as it does connect to the internet?
> 
> APT says, the firmware files are in the firmware-misc-nonfree package:
> 
> glaubitz@ikarus:~$ apt-cache search tg3_tso5.bin
> firmware-misc-nonfree - Binary firmware for various drivers in the Linux 
> kernel
> glaubitz@ikarus:~$
> 
> So, just installing the package with:
> 
> $ apt install firmware-misc-nonfree
> 
> should fix the issue.

Except it’s not in main (the clue’s in the name)...

James

Re: configure sources.list

[James Clarke]

> On 14 Nov 2016, at 21:18, rod  wrote:
>> On 11/14/2016 9:51 AM, John Paul Adrian Glaubitz wrote:
>>> On 11/14/2016 04:34 PM, rod wrote:
>>> Thanks for the quick response.  Now I know how my day is going to go.  I
>>> think I have another functioning machine which I will put a fresh
>>> install on and investigate packages and migrate from old to new.
>>> 
>>> I now the information on how to do this is within the list so I'll dig
>>> around and see if I can consolidate it into one document. (Wish me luck!)
>> 
>> I wrote a small guide which should help you getting Debian/sparc64 installed:
>> 
>>> https://lists.debian.org/debian-sparc/2016/06/msg00126.html
>> 
>> Adrian
>> 
> 
> Thanks Adrian!
> 
> I've gotten the new machine up with few problems not covered in your
> document.
> 
> I've got the following error messages:
> W: Possible missing firmware /lib/firmware/tigon/tg3_tso5.bin for module tg3
> W: Possible missing firmware /lib/firmware/tigon/tg3_tso.bin for module tg3
> W: Possible missing firmware /lib/firmware/tigon/tg3.bin for module tg3
> 
> Can I add the following:
> deb http://ftp.us.debian.org/debian unstable main contrib non-free
> deb http://ftp.debian.org/debian/ Sid-updates main contrib non-free
> deb http://security.debian.org/ Sid/updates main contrib non-free
> 
> # SOURCE
> deb-src http://ftp.us.debian.org/debian unstable main contrib non-free
> deb-src http://ftp.debian.org/debian/ Sid-updates main contrib non-free
> deb-src http://security.debian.org/ Sid/updates main contrib non-free
> 
> or will it blow things up?

That won’t work; sparc64 is only available from debian-ports (ie from
ftp.ports.debian.org/debian-ports or a handful of other mirrors). There’s
no equivalent of contrib/non-free either (we have enough work as it is
getting all of main to work). The security and -updates suites are only
available for testing and below, even on release architectures, not sid.
Nothing will blow up; apt will just moan at you saying it can’t find
sparc64 for each of those (but just a warning; things will still work).

James

Re: configure sources.list

[James Clarke]

Hi Rod,
> On 14 Nov 2016, at 15:21, rod  wrote:
> 
> Good morning (CDT),
> 
> Q: If I change to sources.list to what's below on a machine running;
> 
> rod@cplus:~$ uname -a
> Linux cplus 3.2.0-4-sparc64 #1 Debian 3.2.68-1+deb7u3 sparc64 GNU/Linux
> 
> and go through the update process, will it bring the machine to our
> current level;
> 
> rod@ravirin~$uname -a
> Linux ravirin 4.9.0-rc2+ #3 SMP Thu Oct 27 01:17:17 BST 2016 sparc64
> GNU/Linux
> 
> ?
> 
> I would like to update the first machine without having to load it from
> scratch.

This is uncharted waters. You’ll be trying to cross-grade[1] (sparc32 to
sparc64 userland) and skip a release (no jessie as a stepping-stone).
Unfortunately, I really don’t see a way in which this will work without
a world of pain. Even going from i386->amd64 on the same release is not
recommended (though possible). I strongly suggest you reinstall; you can
get a list of the installed packages with `dpkg --get-selections`, but
this will need to be hand-inspected rather than blindly installing
everything there on the new system, since packages will have been renamed,
especially shared libraries.

Regards,
James

[1] https://wiki.debian.org/CrossGrading

Re: Bug#843826: PIE specs file leads to segfaults on sparc64

[James Clarke]

> On 10 Nov 2016, at 05:35, Guillem Jover <guil...@debian.org> wrote:
> 
> Hi!
> 
> On Wed, 2016-11-09 at 23:46:42 +, James Clarke wrote:
>> Package: dpkg-dev
>> Version: 1.18.13
>> Severity: important
>> User: debian-sparc@lists.debian.org
>> Usertags: sparc64
>> X-Debbugs-Cc: debian-sparc@lists.debian.org
> 
>> Unfortunately, your new specs files lead to segfaults on sparc64:
>> 
>>> $ cat exit.c
>>> #include 
>>> 
>>> int main(int argc, char **argv) {
>>>exit(1);
>>>return 2;
>>> }
>>> $ gcc -specs=/usr/share/dpkg/pie-compile.specs -c exit.c -o exit.o
>>> $ gcc -specs=/usr/share/dpkg/pie-link.specs exit.o -o exit
>>> $ ./exit
>>> Segmentation fault
>> 
>> This is because, while cc1 is given -fPIE, as is not given anything. For
>> most architectures, this is actually fine, but on SPARC, as *must* be
>> given -K PIC. When looking at strace, this is the only difference
>> between gcc -specs=... and gcc -fPIE for compiling. Otherwise, what
>> happens is the assembler does not emit a PLT call, instead leaving the
>> call address as an immediate to be filled in by a 30-bit relocation,
>> which doesn't fit at runtime (with this particular example, libc was
>> loaded such that exit was at 0xfff80001001624e0) and gets truncated.
>> Note that the linker invocation itself is fine; it was just given bad
>> input (although perhaps this is something it could have caught and given
>> an error message?).
>> 
>> As far as I can tell, changing the cc1_options to self_spec in
>> (no-)pie-compile.specs should work fine. It certainly fixes the problem
>> here, and off the top of my head, I can't think of any issues this would
>> cause.
> 
> Thanks for the analysis! I've done several changes to the specs, I've
> tried on a powerpc schroot I had already lying around due to another
> report, if you could test on sparc64 that would be appreciated!
> 
> Attached the changes.

Yep, I can confirm that this works fine (at least pie-*; no-pie-* are
irrelevant given that PIE is not enabled by default).

Thanks,
James

> diff --git i/data/no-pie-compile.specs w/data/no-pie-compile.specs
> index f85b394..2277b97 100644
> --- i/data/no-pie-compile.specs
> +++ w/data/no-pie-compile.specs
> @@ -1,2 +1,2 @@
> -*cc1_options:
> +*self_spec:
>  + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fno-PIE}}
> diff --git i/data/no-pie-link.specs w/data/no-pie-link.specs
> index 15243a0..54db649 100644
> --- i/data/no-pie-link.specs
> +++ w/data/no-pie-link.specs
> @@ -1,2 +1,2 @@
>  *self_spec:
> -+ %{!shared:%{!r:-fno-PIE -no-pie}}
> ++ %{!shared:%{!r:%{!fPIE:%{!pie:-fno-PIE -no-pie
> diff --git i/data/pie-compile.specs w/data/pie-compile.specs
> index fc54bcb..74d8215 100644
> --- i/data/pie-compile.specs
> +++ w/data/pie-compile.specs
> @@ -1,2 +1,2 @@
> -*cc1_options:
> -+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> +*self_spec:
> ++ 
> %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:%{!fno-PIE:%{!no-pie:-fPIE
> diff --git i/data/pie-link.specs w/data/pie-link.specs
> index a5e0fe4..35d26e1 100644
> --- i/data/pie-link.specs
> +++ w/data/pie-link.specs
> @@ -1,2 +1,2 @@
>  *self_spec:
> -+ %{!shared:%{!r:-fPIE -pie}}
> ++ %{!shared:%{!r:%{!fno-PIE:%{!no-pie:-fPIE -pie

Bug#842780: Fix SIGBUS on sparc64

[James Clarke]

Source: ghc
Version: 8.0.1-8
Severity: important
Tags: patch
X-Debbugs-Cc: debian-sparc@lists.debian.org
User: debian-sparc@lists.debian.org
Usertags: sparc64

Hi,
Please find attached a patch to ensure GHC does not perform unaligned
accesses on sparc64 (and sparc if native code gen is disabled, but
there's no sparc64 native code gen support). This is currently blocking
all of Haskell on sparc64.

Regards,
James
--- a/compiler/cmm/PprC.hs
+++ b/compiler/cmm/PprC.hs
@@ -1114,6 +1114,8 @@ cLoad expr rep
   bewareLoadStoreAlignment ArchMipsel   = True
   bewareLoadStoreAlignment (ArchARM {}) = True
   bewareLoadStoreAlignment ArchARM64= True
+  bewareLoadStoreAlignment ArchSPARC= True
+  bewareLoadStoreAlignment ArchSPARC64  = True
   -- Pessimistically assume that they will also cause problems
   -- on unknown arches
   bewareLoadStoreAlignment ArchUnknown  = True


signature.asc
Description: PGP signature

Re: ravirin down

[James Clarke]

The tool works by each server sending an HTTP PUT every 5 minutes, so it’s
possible it was dying and a login shell was too much to ask for; odd though.
Anyway, back up now.

James

> On 31 Oct 2016, at 14:20, rod <r.schn...@mythos.freeddns.org> wrote:
> 
> I tried to get a prompt, which I usually do when I see seg fault errors,
> and it wouldn't return one.  Maybe it's a ghost.  Today's the day for them.
> 
> Rod
> 
> On 10/31/2016 9:18 AM, James Clarke wrote:
>> Hi Rod,
>> Don’t worry; those are all down to me (a kernel module to dump vmap_lazy_nr
>> and friends, and the DEBUG ones are because I added a printk to see if a
>> particular condition is reached). Then of course the tst_qtgraphical segfault
>> is just a normal user-space SIGSEGV.
>> 
>> I’m curious as to whether raverin actually needed rebooting; my monitoring
>> tool says it was still up 7 minutes ago, but not 2 minutes later at the
>> next refresh (presumably because you’ve rebooted). Being idle is expected;
>> there are no packages queued for building.
>> 
>> Thanks,
>> James
>> 
>>> On 31 Oct 2016, at 14:12, rod <r.schn...@mythos.freeddns.org> wrote:
>>> 
>>> Good morning,
>>> 
>>> I saw ravirin was not building again so in the process of rebooting him
>>> I found this snipet.
>>> 
>>> [ 1208.832559] vln_init: lazy_max_pages() is 4096
>>> [ 1208.918323] vln_init: vmap_lazy_nr is caeb1c
>>> [ 1208.974405] vln_init: *vmap_lazy_nr is 145
>>> [ 1209.030340] vln_init: lazy_max_pages() is 4096
>>> [ 1209.294257] vln_init: vmap_lazy_nr is caeb1c
>>> [ 1209.350412] vln_init: *vmap_lazy_nr is 174
>>> [ 1209.406334] vln_init: lazy_max_pages() is 4096
>>> [ 1209.834246] vln_init: vmap_lazy_nr is caeb1c
>>> [ 1209.890347] vln_init: *vmap_lazy_nr is 203
>>> [ 1209.946274] vln_init: lazy_max_pages() is 4096
>>> [ 1210.553105] vln_init: vmap_lazy_nr is caeb1c
>>> [ 1210.609279] vln_init: *vmap_lazy_nr is 232
>>> [ 1210.665157] vln_init: lazy_max_pages() is 4096
>>> [ 1211.349159] vln_init: vmap_lazy_nr is caeb1c
>>> [ 1211.405310] vln_init: *vmap_lazy_nr is 261
>>> [ 1211.461203] vln_init: lazy_max_pages() is 4096
>>> [24537.258928] TSB[kworker/0:5:5958]: DEBUG flush_tsb_kernel_range
>>> start=1000c000 end=f000 PAGE_SIZE=2000
>>> [24537.404378] TSB[kworker/0:5:5958]: DEBUG flush_tsb_kernel_range
>>> start=0001 end=0001020d6000 PAGE_SIZE=2000
>>> [217632.451540] TSB[kworker/0:1:17055]: DEBUG flush_tsb_kernel_range
>>> start=00014000 end=000102126000 PAGE_SIZE=2000
>>> [230284.512421] tst_qtgraphical[476]: segfault at 0 ip fff1013e8644
>>> (rpc fff100841884) sp 07feffc275e1 error 30001 in
>>> libc-2.24.so[fff10135c000+15e000]
>>> 
>>> Not sure what it means nor what I can do to help fix it.  Thoughts.
>>> 
>>> Rod
>>> 
>>> 
>>> On 10/27/2016 7:07 AM, James Clarke wrote:
>>>> Hi Rod,
>>>> It seems ravirin has been down for at least the past few days. Could you 
>>>> please
>>>> give it some love? If it’s crashed/hung with CPU lockups, I’ve built a 4.9
>>>> kernel with a patch to fix this which I’d like to test.
>>>> 
>>>> Thanks,
>>>> James
>>>> 
>> 

Re: ravirin down

[James Clarke]

Hi Rod,
Don’t worry; those are all down to me (a kernel module to dump vmap_lazy_nr
and friends, and the DEBUG ones are because I added a printk to see if a
particular condition is reached). Then of course the tst_qtgraphical segfault
is just a normal user-space SIGSEGV.

I’m curious as to whether raverin actually needed rebooting; my monitoring
tool says it was still up 7 minutes ago, but not 2 minutes later at the
next refresh (presumably because you’ve rebooted). Being idle is expected;
there are no packages queued for building.

Thanks,
James

> On 31 Oct 2016, at 14:12, rod <r.schn...@mythos.freeddns.org> wrote:
> 
> Good morning,
> 
> I saw ravirin was not building again so in the process of rebooting him
> I found this snipet.
> 
> [ 1208.832559] vln_init: lazy_max_pages() is 4096
> [ 1208.918323] vln_init: vmap_lazy_nr is caeb1c
> [ 1208.974405] vln_init: *vmap_lazy_nr is 145
> [ 1209.030340] vln_init: lazy_max_pages() is 4096
> [ 1209.294257] vln_init: vmap_lazy_nr is caeb1c
> [ 1209.350412] vln_init: *vmap_lazy_nr is 174
> [ 1209.406334] vln_init: lazy_max_pages() is 4096
> [ 1209.834246] vln_init: vmap_lazy_nr is caeb1c
> [ 1209.890347] vln_init: *vmap_lazy_nr is 203
> [ 1209.946274] vln_init: lazy_max_pages() is 4096
> [ 1210.553105] vln_init: vmap_lazy_nr is caeb1c
> [ 1210.609279] vln_init: *vmap_lazy_nr is 232
> [ 1210.665157] vln_init: lazy_max_pages() is 4096
> [ 1211.349159] vln_init: vmap_lazy_nr is caeb1c
> [ 1211.405310] vln_init: *vmap_lazy_nr is 261
> [ 1211.461203] vln_init: lazy_max_pages() is 4096
> [24537.258928] TSB[kworker/0:5:5958]: DEBUG flush_tsb_kernel_range
> start=1000c000 end=f000 PAGE_SIZE=2000
> [24537.404378] TSB[kworker/0:5:5958]: DEBUG flush_tsb_kernel_range
> start=0001 end=0001020d6000 PAGE_SIZE=2000
> [217632.451540] TSB[kworker/0:1:17055]: DEBUG flush_tsb_kernel_range
> start=00014000 end=000102126000 PAGE_SIZE=2000
> [230284.512421] tst_qtgraphical[476]: segfault at 0 ip fff1013e8644
> (rpc fff100841884) sp 07feffc275e1 error 30001 in
> libc-2.24.so[fff10135c000+15e000]
> 
> Not sure what it means nor what I can do to help fix it.  Thoughts.
> 
> Rod
> 
> 
> On 10/27/2016 7:07 AM, James Clarke wrote:
>> Hi Rod,
>> It seems ravirin has been down for at least the past few days. Could you 
>> please
>> give it some love? If it’s crashed/hung with CPU lockups, I’ve built a 4.9
>> kernel with a patch to fix this which I’d like to test.
>> 
>> Thanks,
>> James
>> 

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[James Clarke]

> On 27 Oct 2016, at 16:51, David Miller <da...@davemloft.net> wrote:
> 
> From: James Clarke <jrt...@jrtc27.com>
> Date: Thu, 27 Oct 2016 09:25:36 +0100
> 
>> I’ve run it on the T5 and it seems to work without lockups:
>> 
>> [5948090.988821] vln_init: *vmap_lazy_nr is 32754
>> [5948090.989943] vln_init: lazy_max_pages() is 32768
>> [5948091.157381] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
>> start=10006000 end=f000 PAGE_SIZE=2000
>> [5948091.157530] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
>> start=0001 end=00058c00 PAGE_SIZE=2000
>> [5948091.158240] vln_init: vmap_lazy_nr is caeb1c
>> [5948091.158252] vln_init: *vmap_lazy_nr is 0
>> [5948091.159311] vln_init: lazy_max_pages() is 32768
>> ... continues on as normal ...
>> 
>> (again, that’s my debugging module to see how close the system is to a flush)
>> 
>> I can't (yet) vouch for the IIIi, but when it comes back up I’ll give it a 
>> go[1].
>> I'll also put it on the T1 at some point today, but it *should* also work 
>> since
>> it's using the same sun4v/hypervisor implementation as the T5.
> 
> I'm about to test it on my IIIi and will commit this if it seems to work 
> properly.
> 
> I guess you have no opinion about the cut-off choosen? :-)
> 
> Anyways, we can fine tune it later.

I was just testing it on the IIIi when I got this. Anyway, it seems to work 
fine.
It hasn’t (yet) had one of the stupidly high allocations, but it did flush a 
block
of 3658 pages just fine (assuming the flush actually worked). Similarly for the 
T1.

The cut-off seems pretty arbitrary, and the only way to determine it properly 
would
be benchmarking (or finding out what the relevant delays are). Given x86 uses 
33,
32 or 64 seem perfectly fine, but going into the hundreds doesn’t sound stupid
either... For such small numbers it’s probably hardly going to matter.

Tested-by: James Clarke <jrt...@jrtc27.com>

James

Re: ravirin down

[James Clarke]

Thanks! I'll put the new kernel on there.

James

> On 27 Oct 2016, at 15:11, rod <r.schn...@mythos.freeddns.org> wrote:
> 
> James,
> 
> He's back up.  Let me know if you need anything else.
> 
> Rod
> 
>> On 10/27/2016 7:07 AM, James Clarke wrote:
>> Hi Rod,
>> It seems ravirin has been down for at least the past few days. Could you 
>> please
>> give it some love? If it’s crashed/hung with CPU lockups, I’ve built a 4.9
>> kernel with a patch to fix this which I’d like to test.
>> 
>> Thanks,
>> James
>> 

ravirin down

[James Clarke]

Hi Rod,
It seems ravirin has been down for at least the past few days. Could you please
give it some love? If it’s crashed/hung with CPU lockups, I’ve built a 4.9
kernel with a patch to fix this which I’d like to test.

Thanks,
James

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[James Clarke]

> On 27 Oct 2016, at 02:27, James Clarke <jrt...@jrtc27.com> wrote:
> 
>> On 26 Oct 2016, at 22:02, David Miller <da...@davemloft.net> wrote:
>> 
>> From: James Clarke <jrt...@jrtc27.com>
>> Date: Wed, 26 Oct 2016 21:05:36 +0100
>> 
>>> Thanks for this, it's now compiling. I'll let you know if it works
>>> within the next 24 hours.
>> 
>> Thanks.
>> 
>>> Before I forget, what do you think about the following patch? I know
>>> Debian used to use the 64-bit kernel for a 32-bit sparc userland, and so
>>> "Architecture: sparc" was correct, but obviously sparc64 also exists. It
>>> seems more sane to make sparc64 default to "Architecture: sparc64", with
>>> sparc users needing to override this with KBUILD_DEBARCH if they want
>>> to, rather than providing a setup that's broken out of the box for
>>> sparc64 users.
>>> 
>>> From: James Clarke <jrt...@jrtc27.com>
>>> Date: Wed, 26 Oct 2016 20:17:10 +0100
>>> Subject: [PATCH] builddeb: Add support for sparc64
>>> 
>>> Signed-off-by: James Clarke <jrt...@jrtc27.com>
>> 
>> I don't know.
>> 
>> I still personally use a 32-bit userland on my sparc64 systems because
>> that is what performs the best and is what I will be using for as long
>> as I possibly can.
>> 
>> I've actually never used this target, is this for build the kernel or
>> userland components?
> 
> Yes, make pkg-deb builds kernel, firmware, headers and linux-libc packages.
> By the way, the first build I made of 4.9 (using Debian’s 4.8 config as old
> config) wouldn’t boot, since:
> 
> * sunvdc module needs _mcount
> * sunvnet module needs _mcount and count_bits
> * crc32c_sparc64 module needs _mcount and VISenter
> [* raid6_pq module needs memcpy, though that’s just for a data partition]
> 
> The workaround is not to use CONFIG_MODVERSIONS, but this wasn’t at all clear
> at first. This is because of d3867f0483, which moved these to being exported 
> in
> their .S.
> 
> Anyway, the new kernel is running now and being stress-tested.

Hi David,
I’ve run it on the T5 and it seems to work without lockups:

[5948090.988821] vln_init: *vmap_lazy_nr is 32754
[5948090.989943] vln_init: lazy_max_pages() is 32768
[5948091.157381] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
start=10006000 end=f000 PAGE_SIZE=2000
[5948091.157530] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
start=0001 end=00058c00 PAGE_SIZE=2000
[5948091.158240] vln_init: vmap_lazy_nr is caeb1c
[5948091.158252] vln_init: *vmap_lazy_nr is 0
[5948091.159311] vln_init: lazy_max_pages() is 32768
... continues on as normal ...

(again, that’s my debugging module to see how close the system is to a flush)

I can't (yet) vouch for the IIIi, but when it comes back up I’ll give it a 
go[1].
I'll also put it on the T1 at some point today, but it *should* also work since
it's using the same sun4v/hypervisor implementation as the T5.

Thanks,
James

[1] Not sure how long that will take...

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[James Clarke]

> On 26 Oct 2016, at 22:02, David Miller <da...@davemloft.net> wrote:
> 
> From: James Clarke <jrt...@jrtc27.com>
> Date: Wed, 26 Oct 2016 21:05:36 +0100
> 
>> Thanks for this, it's now compiling. I'll let you know if it works
>> within the next 24 hours.
> 
> Thanks.
> 
>> Before I forget, what do you think about the following patch? I know
>> Debian used to use the 64-bit kernel for a 32-bit sparc userland, and so
>> "Architecture: sparc" was correct, but obviously sparc64 also exists. It
>> seems more sane to make sparc64 default to "Architecture: sparc64", with
>> sparc users needing to override this with KBUILD_DEBARCH if they want
>> to, rather than providing a setup that's broken out of the box for
>> sparc64 users.
>> 
>> From: James Clarke <jrt...@jrtc27.com>
>> Date: Wed, 26 Oct 2016 20:17:10 +0100
>> Subject: [PATCH] builddeb: Add support for sparc64
>> 
>> Signed-off-by: James Clarke <jrt...@jrtc27.com>
> 
> I don't know.
> 
> I still personally use a 32-bit userland on my sparc64 systems because
> that is what performs the best and is what I will be using for as long
> as I possibly can.
> 
> I've actually never used this target, is this for build the kernel or
> userland components?

Yes, make pkg-deb builds kernel, firmware, headers and linux-libc packages.
By the way, the first build I made of 4.9 (using Debian’s 4.8 config as old
config) wouldn’t boot, since:

* sunvdc module needs _mcount
* sunvnet module needs _mcount and count_bits
* crc32c_sparc64 module needs _mcount and VISenter
[* raid6_pq module needs memcpy, though that’s just for a data partition]

The workaround is not to use CONFIG_MODVERSIONS, but this wasn’t at all clear
at first. This is because of d3867f0483, which moved these to being exported in
their .S.

Anyway, the new kernel is running now and being stress-tested.

James

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[James Clarke]

On Wed, Oct 26, 2016 at 03:04:59PM -0400, David Miller wrote:
> From: James Clarke <jrt...@jrtc27.com>
> Date: Wed, 26 Oct 2016 18:21:06 +0100
>
> >> On 26 Oct 2016, at 18:09, David Miller <da...@davemloft.net> wrote:
> >>
> >> From: James Clarke <jrt...@jrtc27.com>
> >> Date: Wed, 26 Oct 2016 17:58:16 +0100
> >>
> >>>> On 26 Oct 2016, at 16:54, David Miller <da...@davemloft.net> wrote:
> >>>>
> >>>> From: James Clarke <jrt...@jrtc27.com>
> >>>> Date: Wed, 26 Oct 2016 09:28:05 +0100
> >>>>
> >>>>> Any progress on TLB flushing?
> >>>>
> >>>> I'll keep plugging away at it today.
> >>>
> >>> Great; let me know if you need a guinea pig, as it’s pretty easy for me to
> >>> reproduce.
> >>
> >> Will do, what kind of cpus do you have?
> >
> > * UltraSparc T5 (Niagara5)
> > * UltraSparc T1 (Niagara)
> > * UltraSPARC IIIi
> >
> > The IIIi seems to be down at the moment though.
>
> James, here is what I have so far.  I only gave it a brief testing on
> sun4v, so no guarantees for the sun4u cases.  This is against the
> current sparc GIT tree.
>
> The cut-off is 32 pages, we can discuss whether that's a good value
> to use or not.  FWIW, x86_64 has similar code for this situation and
> uses a cut-off of 33.  Perhaps 64 is a better value, who knows.
>
> It might even make sense to use a different cut-off for the hypervisor
> case since the hypervisor trap we have to use to do the TLB operation
> adds even more expense to each iteration of the range loop.
>
> The policy implemented for huge range flushes below is:
>
> 1) Spitfire - Flush all non-locked entries, by hand using diagnostic
>TLB accesses.
>
> 2) Cheetah - Flush all non-locked entries using "flush all" operation.
>
> 3) sun4v/hypervisor - Flush entire kernel context, which does not
>remove locked or "permanent" entries.
>
> Anyways, let me know how it goes.

Thanks for this, it's now compiling. I'll let you know if it works
within the next 24 hours.

Before I forget, what do you think about the following patch? I know
Debian used to use the 64-bit kernel for a 32-bit sparc userland, and so
"Architecture: sparc" was correct, but obviously sparc64 also exists. It
seems more sane to make sparc64 default to "Architecture: sparc64", with
sparc users needing to override this with KBUILD_DEBARCH if they want
to, rather than providing a setup that's broken out of the box for
sparc64 users.

From: James Clarke <jrt...@jrtc27.com>
Date: Wed, 26 Oct 2016 20:17:10 +0100
Subject: [PATCH] builddeb: Add support for sparc64

Signed-off-by: James Clarke <jrt...@jrtc27.com>
---
 scripts/package/builddeb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 8ea9fd2..63b3112 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -41,6 +41,8 @@ set_debarch() {
debarch="$UTS_MACHINE" ;;
x86_64)
debarch=amd64 ;;
+   sparc64)
+   debarch=sparc64 ;;
sparc*)
debarch=sparc ;;
s390*)
--
2.9.3

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[James Clarke]

> On 26 Oct 2016, at 18:09, David Miller <da...@davemloft.net> wrote:
> 
> From: James Clarke <jrt...@jrtc27.com>
> Date: Wed, 26 Oct 2016 17:58:16 +0100
> 
>>> On 26 Oct 2016, at 16:54, David Miller <da...@davemloft.net> wrote:
>>> 
>>> From: James Clarke <jrt...@jrtc27.com>
>>> Date: Wed, 26 Oct 2016 09:28:05 +0100
>>> 
>>>> Any progress on TLB flushing?
>>> 
>>> I'll keep plugging away at it today.
>> 
>> Great; let me know if you need a guinea pig, as it’s pretty easy for me to
>> reproduce.
> 
> Will do, what kind of cpus do you have?

* UltraSparc T5 (Niagara5)
* UltraSparc T1 (Niagara)
* UltraSPARC IIIi

The IIIi seems to be down at the moment though.

James

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[James Clarke]

> On 26 Oct 2016, at 16:54, David Miller <da...@davemloft.net> wrote:
> 
> From: James Clarke <jrt...@jrtc27.com>
> Date: Wed, 26 Oct 2016 09:28:05 +0100
> 
>> Any progress on TLB flushing?
> 
> I was half-way through an implementation when I noticed that
> hypervisor TLB flush handler relative branch bug I posted the
> fix for last night.

Yep, I saw that. Looks like you forgot to update the comment on
__hypervisor_flush_tlb_pending; it still says 16 insns rather than 27.

> I'll keep plugging away at it today.

Great; let me know if you need a guinea pig, as it’s pretty easy for me to
reproduce.

Thanks,
James

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[James Clarke]

> On 26 Oct 2016, at 03:44, David Miller <da...@davemloft.net> wrote:
> 
> 
> If the number of pages we are flushing is more than twice the number
> of entries in the TSB, just scan the TSB table for matches rather
> than probing each and every page in the range.
> 
> Based upon a patch and report by James Clarke.
> 
> Signed-off-by: David S. Miller <da...@davemloft.net>
> ---
> 
> James this is the final version I pushed into the tree.

Great, thanks. Any progress on TLB flushing?

James

Re: NMI watchdog: BUG: soft lockup

[James Clarke]

> On 25 Oct 2016, at 18:27, David Miller  wrote:
> 
> From: David Miller 
> Date: Tue, 25 Oct 2016 13:18:08 -0400 (EDT)
> 
>> So the full virtual address comparison is something like:
>> 
>>  unsigned long compare = (tag >> 22) << 22; /* Clear CONTEXT bits */
>> 
>>  compare |= (tsb_index & (nentries - 1)) << 13;
>> 
>>  if (vaddr == compare)
>>  goto match;
>> 
>> The swapper TSB only stores PAGE_SIZE translations.
> 
> Ok, this should work:
> 
> static void flush_tsb_kernel_range_scan(unsigned long start, unsigned long 
> end)
> {
>unsigned long idx;
> 
>for (idx = 0; idx < KERNEL_TSB_NENTRIES; idx++) {
>struct tsb *ent = _tsb[idx];
>unsigned long match = idx << 13;
> 
>match |= (ent->tag << 22);
>if (match >= start && match < end)
>ent->tag = (1UL << TSB_TAG_INVALID_BIT);
>}
> }
> 
> Bits 13-"21+N" come from the TSB index, and the tag always stores
> bits 22 and above.  So simply 'or'ing them together always gives
> us a usable match value.

Ah, right, got it. That makes it much nicer than mine.

James

Re: NMI watchdog: BUG: soft lockup

[James Clarke]

> On 25 Oct 2016, at 18:04, David Miller <da...@davemloft.net> wrote:
> 
> From: James Clarke <jrt...@jrtc27.com>
> Date: Tue, 25 Oct 2016 16:59:04 +0100
> 
>> That’s basically the same as my patch, except this potentially flushes things
>> outside [start, end) if they’re not on 2^22-byte boundaries.
> 
> Oh yes, I see, thanks for pointing that out.
> 
> We have to take the index into account for the purposes of virtual
> address comparison.

I don’t quite follow what you’re trying to say here? idx is only used to index 
the TSB.

James

Re: NMI watchdog: BUG: soft lockup

[James Clarke]

> On 25 Oct 2016, at 16:50, David Miller <da...@davemloft.net> wrote:
> 
> From: David Miller <da...@davemloft.net>
> Date: Tue, 25 Oct 2016 11:22:31 -0400 (EDT)
> 
>> From: James Clarke <jrt...@jrtc27.com>
>> Date: Tue, 25 Oct 2016 16:11:52 +0100
>> 
>>> Yep, that fix is still there, but you will note that end *is* above start in
>>> the call. Something is being allocated and freed right at the end of the 
>>> malloc
>>> area, so it’s iterating over almost the entire thing.
>> 
>> Ok, let me think about this some more.
> 
> So, for the TSB part we don't need to do anything fancy, something like
> the patch below will suffice.
> 
> As per the TLB flush that's a bit more complicated.
> 
> For the older chips we need to do more work because they unfortunately
> defined the context flush to even remove locked TLB entries.
> Otherwise we could simply do a nucleus context flush if the range is
> too large.  So we'll have to use diagnostic accesses to implement the
> same functionality.
> 
> UltraSPARC-III and later provide more usable facilities for this
> situation.  UltraSPARC-III/IV have a "flush all" which removes all
> non-locked TLB entries.  And all of the sun4v chips have a more
> reasonable context flush, which does not remove "permanent" entries.
> 
> I'll start hacking something up.
> 
> diff --git a/arch/sparc/mm/tsb.c b/arch/sparc/mm/tsb.c
> index f2b7711..1f63411 100644
> --- a/arch/sparc/mm/tsb.c
> +++ b/arch/sparc/mm/tsb.c
> @@ -27,6 +27,20 @@ static inline int tag_compare(unsigned long tag, unsigned 
> long vaddr)
>   return (tag == (vaddr >> 22));
> }
> 
> +static void flush_tsb_kernel_range_scan(unsigned long start, unsigned long 
> end)
> +{
> + unsigned long idx;
> +
> + start >> 22;
> + end >> 22;
> + for (idx = 0; idx < KERNEL_TSB_NENTRIES; idx++) {
> + struct tsb *ent = _tsb[idx];
> +
> + if (ent->tag >= start && end->tag < end)
> + ent->tag = (1UL << TSB_TAG_INVALID_BIT);
> + }
> +}
> +
> /* TSB flushes need only occur on the processor initiating the address
>  * space modification, not on each cpu the address space has run on.
>  * Only the TLB flush needs that treatment.
> @@ -36,6 +50,9 @@ void flush_tsb_kernel_range(unsigned long start, unsigned 
> long end)
> {
>   unsigned long v;
> 
> + if ((end - start) >> PAGE_SHIFT >= 2 * KERNEL_TSB_NENTRIES)
> + return flush_tsb_kernel_range_scan(start, end);
> +
>   for (v = start; v < end; v += PAGE_SIZE) {
>   unsigned long hash = tsb_hash(v, PAGE_SHIFT,
> KERNEL_TSB_NENTRIES);

That’s basically the same as my patch, except this potentially flushes things
outside [start, end) if they’re not on 2^22-byte boundaries. Of course, the
performance hit of that may be better than my patch which also walks through
pages up to the first 2^22-aligned address after start, and those after the
last 2^22-aligned address before end, but won’t flush anything that’s outside
the range.

Can we do a similar thing for the TLB by iterating over all its entries? Surely
one of the ASIs lets you do that?

James

Re: NMI watchdog: BUG: soft lockup

[James Clarke]

> On 25 Oct 2016, at 16:07, David Miller <da...@davemloft.net> wrote:
> 
> From: James Clarke <jrt...@jrtc27.com>
> Date: Tue, 25 Oct 2016 14:15:26 +0100
> 
>> I built a custom kernel with a single extra printk at the start of
>> flush_tsb_kernel_range which prints its arguments. I then had to wait for it 
>> to
>> be hit, and when it was, I got the following:
>> 
>> [5717559.949396] TSB: DEBUG flush_tsb_kernel_range start=10006000 
>> end=f000 PAGE_SIZE=2000
>> [5717560.062663] TSB: DEBUG flush_tsb_kernel_range start=0001 
>> end=0005a200 PAGE_SIZE=2000
> 
> I thought I fixed this a very very long time ago:
> 
> commit 473ad7f4fb005d1bb727e4ef27d370d28703a062
> Author: David S. Miller <da...@davemloft.net>
> Date:   Sat Oct 4 21:05:14 2014 -0700
> 
>sparc64: Fix reversed start/end in flush_tlb_kernel_range()
> 
>When we have to split up a flush request into multiple pieces
>(in order to avoid the firmware range) we don't specify the
>arguments in the right order for the second piece.
> 
>Fix the order, or else we get hangs as the code tries to
>flush "a lot" of entries and we get lockups like this:
> 
>[ 4422.981276] NMI watchdog: BUG: soft lockup - CPU#12 stuck for 23s! 
> [expect:117032]
>[ 4422.996130] Modules linked in: ipv6 loop usb_storage igb ptp sg sr_mod 
> ehci_pci ehci_hcd pps_core n2_rng rng_core
>[ 4423.016617] CPU: 12 PID: 117032 Comm: expect Not tainted 3.17.0-rc4+ 
> #1608
>[ 4423.030331] task: fff8003cc730e220 ti: fff8003d99d54000 task.ti: 
> fff8003d99d54000
>[ 4423.045282] TSTATE: 11001602 TPC: 004521e8 TNPC: 
> 004521ec Y: Not tainted
>[ 4423.064905] TPC: <__flush_tlb_kernel_range+0x28/0x40>
>[ 4423.074964] g0: 0052fd10 g1: 0001295a8000 g2: 
> ff7176ffc000 g3: 2000
>[ 4423.092324] g4: fff8003cc730e220 g5: fff8003dfedcc000 g6: 
> fff8003d99d54000 g7: 0006
>[ 4423.109687] o0:  o1:  o2: 
> 0003 o3: f000
>[ 4423.127058] o4: 0080 o5: 0001295a8000 sp: 
> fff8003d99d56d01 ret_pc: 0052ff54
>[ 4423.145121] RPC: <__purge_vmap_area_lazy+0x314/0x3a0>
>[ 4423.155185] l0:  l1:  l2: 
> 00a38040 l3: 
>[ 4423.172559] l4: fff8003dae8965e0 l5:  l6: 
>  l7: f7e2b138
>[ 4423.189913] i0: fff8003d99d576a0 i1: fff8003d99d576a8 i2: 
> fff8003d99d575e8 i3: 
>[ 4423.207284] i4: 8008 i5: fff8003d99d575c8 i6: 
> fff8003d99d56df1 i7: 00530c24
>[ 4423.224640] I7: <free_vmap_area_noflush+0x64/0x80>
>[ 4423.234193] Call Trace:
>[ 4423.239051]  [00530c24] free_vmap_area_noflush+0x64/0x80
>[ 4423.251029]  [00531a7c] remove_vm_area+0x5c/0x80
>[ 4423.261628]  [00531b80] __vunmap+0x20/0x120
>[ 4423.271352]  [0071cf18] n_tty_close+0x18/0x40
>[ 4423.281423]  [007222b0] tty_ldisc_close+0x30/0x60
>[ 4423.292183]  [007225a4] tty_ldisc_reinit+0x24/0xa0
>[ 4423.303120]  [00722ab4] tty_ldisc_hangup+0xd4/0x1e0
>[ 4423.314232]  [00719aa0] __tty_hangup+0x280/0x3c0
>[ 4423.324835]  [00724cb4] pty_close+0x134/0x1a0
>[ 4423.334905]  [0071aa24] tty_release+0x104/0x500
>[ 4423.345316]  [005511d0] __fput+0x90/0x1e0
>[ 4423.354701]  [0047fa54] task_work_run+0x94/0xe0
>[ 4423.365126]  [00404b44] __handle_signal+0xc/0x2c
> 
>Fixes: 4ca9a23765da ("sparc64: Guard against flushing openfirmware 
> mappings.")
>Signed-off-by: David S. Miller <da...@davemloft.net>
> 
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index c8bccaf..bd08ed4 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -2837,8 +2837,8 @@ void flush_tlb_kernel_range(unsigned long start, 
> unsigned long end)
>   do_flush_tlb_kernel_range(start, LOW_OBP_ADDRESS);
>   }
>   if (end > HI_OBP_ADDRESS) {
> - flush_tsb_kernel_range(end, HI_OBP_ADDRESS);
> - do_flush_tlb_kernel_range(end, HI_OBP_ADDRESS);
> + flush_tsb_kernel_range(HI_OBP_ADDRESS, end);
> + do_flush_tlb_kernel_range(HI_OBP_ADDRESS, end);
>   }
>   } else {
>   flush_tsb_kernel_range(start, end);

Yep, that fix is still there, but you will note that end *is* above start in
the call. Something is being allocated and freed right at the end of the malloc
area, so it’s iterating over almost the entire thing.

James

NMI watchdog: BUG: soft lockup

[James Clarke]

Hi,
We've been having regular soft lockups on our servers (various different kinds
of hardware); on one in particular which sees heavy load, this can happen every
24h. When it happens, the whole machine grinds to a halt, and it needs to be
hard rebooted. The recurring stack trace given on the console for the stuck
kworker is:

[5717580.933396]  [00498edc] dump_cpu_task+0x3c/0x60
[5717580.933407]  [00567034] rcu_dump_cpu_stacks+0xbc/0xe8
[5717580.933418]  [004d1410] rcu_check_callbacks+0x850/0x9c0
[5717580.933427]  [004d73c4] update_process_times+0x24/0x60
[5717580.933437]  [004e6640] tick_sched_handle.isra.4+0x20/0x80
[5717580.933444]  [004e66d0] tick_sched_timer+0x30/0x80
[5717580.933450]  [004d7fcc] __hrtimer_run_queues+0xcc/0x300
[5717580.933458]  [004d8924] hrtimer_interrupt+0x84/0x1a0
[5717580.933467]  [009935a0] timer_interrupt+0x80/0xe0
[5717580.933475]  [004209d4] tl0_irq14+0x14/0x20
[5717580.933483]  [00456208] flush_tsb_kernel_range+0x68/0xa0
[5717580.933491]  [004587bc] flush_tlb_kernel_range+0x5c/0xc0
[5717580.933499]  [005b0528] __purge_vmap_area_lazy+0x288/0x300
[5717580.933506]  [005b076c] free_vmap_area_noflush+0x6c/0x80
[5717580.933513]  [005b2420] remove_vm_area+0x60/0x80
[5717580.933519]  [005b2464] __vunmap+0x24/0x100

I built a custom kernel with a single extra printk at the start of
flush_tsb_kernel_range which prints its arguments. I then had to wait for it to
be hit, and when it was, I got the following:

[5717559.949396] TSB: DEBUG flush_tsb_kernel_range start=10006000 
end=f000 PAGE_SIZE=2000
[5717560.062663] TSB: DEBUG flush_tsb_kernel_range start=0001 
end=0005a200 PAGE_SIZE=2000

The first call to flush_tsb_kernel_range corresponds to [start,
LOW_OBP_ADDRESS) for kernel modules, and the second one to [HIGH_OBP_ADDRESS,
end), since start and end straddle the OBP region, and thus it took that branch
in flush_tlb_kernel_range. Given the fact that flush_tsb_kernel_range steps
through every possible page address in the range, this is not going to
terminate in a reasonable amount of time (1 million iterations per second would
give just over 2 days of execution time…). Note that end *is* within
[VMALLOC_START, VMALLOC_END), despite the comment in pgtable_64.h suggesting
VMALLOC_END is 0x2:

[0.00] MM: VMALLOC [0x0001 --> 0x0006]

I made the change given below, which exploits the fact that if start and end
are sufficiently aligned, you can walk through the TSB and check each entry,
since the lower bits in the virtual addresses referenced by the tags don't
matter. Since there are 512 pages to a 2^22-byte block, there can be at most
1023 iterations of __flush_tsb_kernel_range_short's loop during the entire
execution of flush_tsb_kernel_range.

However, that’s only half the problem. flush_tlb_kernel_range still calls
do_flush_tlb_kernel_range, which is now reached and itself loops over every
address (in ultra.S's __(hypervisor_)flush_tlb_kernel_range). Is there a way to
make this fast as well? Here's what I get running with my patch:

[5796396.351352] TSB[insmod:53414]: DEBUG flush_tsb_kernel_range 
start=10006000 end=f000 PAGE_SIZE=2000
[5796396.351369] TSB[insmod:53414]: DEBUG __flush_tsb_kernel_range_short 
start=10006000 end=1040 PAGE_SIZE=2000
[5796396.351386] TSB[insmod:53414]: DEBUG __flush_tsb_kernel_range_block 
start=1040 end=f000 PAGE_SIZE=2000
[5796396.351407] TSB[insmod:53414]: DEBUG __flush_tsb_kernel_range_short 
start=f000 end=f000 PAGE_SIZE=2000
[5796396.464227] TSB[insmod:53414]: DEBUG flush_tsb_kernel_range 
start=0001 end=0005ee00 PAGE_SIZE=2000
[5796396.464258] TSB[insmod:53414]: DEBUG __flush_tsb_kernel_range_short 
start=0001 end=0001 PAGE_SIZE=2000
[5796396.464280] TSB[insmod:53414]: DEBUG __flush_tsb_kernel_range_block 
start=0001 end=0005ee00 PAGE_SIZE=2000
[5796396.464311] TSB[insmod:53414]: DEBUG __flush_tsb_kernel_range_short 
start=0005ee00 end=0005ee00 PAGE_SIZE=2000
[5796396.464328] INIT[insmod:53414]: DEBUG flush_tlb_kernel_range about to call 
long do_flush_tlb_kernel_range...
[5796421.014160] NMI watchdog: BUG: soft lockup - CPU#110 stuck for 22s! 
[insmod:53414]
[5796421.014187] Modules linked in: vmap_lazy_nr2(O+) tun xt_tcpudp 
xt_multiport xt_conntrack iptable_filter iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack n2_rng flash camellia_sparc64 
des_sparc64 des_generic rng_core md5_sparc64 sha512_sparc64 sha256_sparc64 
sha1_sparc64 ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto ecb mbcache 
btrfs crc32c_generic xor zlib_deflate raid6_pq crc32c_sparc64 aes_sparc64 
sunvnet sunvdc [last unloaded: vmap_lazy_nr2]
[5796421.014418] CPU: 110 PID: 53414 

Re: Regression with 4.7.2 on sun4u

[James Clarke]

> On 24 Oct 2016, at 19:11, David Miller <da...@davemloft.net> wrote:
> 
> From: James Clarke <jrt...@jrtc27.com>
> Date: Sat, 22 Oct 2016 10:51:28 +0100
> 
>> @@ -19,12 +19,20 @@ void arch_jump_label_transform(struct jump_entry *entry,
>>  if (type == JUMP_LABEL_JMP) {
>>  s32 off = (s32)entry->target - (s32)entry->code;
>> 
>> +BUG_ON(off & 3);
>> +
>> #ifdef CONFIG_SPARC64
>> -/* ba,pt %xcc, . + (off << 2) */
>> -val = 0x1068 | ((u32) off >> 2);
>> +/* WDISP19 - target is . + (immed << 2) */
>> +BUG_ON(off > 0xf);
>> +BUG_ON(off < -0x10);
>> +/* ba,pt %xcc, . + off */
>> +val = 0x1068 | (((u32) off >> 2) & 0x7);
>> #else
>> -/* ba . + (off << 2) */
>> -val = 0x1080 | ((u32) off >> 2);
>> +/* WDISP22 - target is . + (immed << 2) */
>> +BUG_ON(off > 0x7f);
>> +BUG_ON(off < -0x80);
>> +/* ba . + off */
>> +val = 0x1080 | (((u32) off >> 2) & 0x3f);
>> #endif
> 
> Since we can determine at run time whether we need to use a non-v9
> branch or not, it makes no sense to fail when a v9 branch is out of
> range.
> 
> We can simply downgrade to a pre-v9 one.
> 
> Something like this:
> 
> diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
> index 59bbeff..689e557 100644
> --- a/arch/sparc/kernel/jump_label.c
> +++ b/arch/sparc/kernel/jump_label.c
> @@ -13,19 +13,24 @@
> void arch_jump_label_transform(struct jump_entry *entry,
>  enum jump_label_type type)
> {
> - u32 val;
>   u32 *insn = (u32 *) (unsigned long) entry->code;
> + u32 val;
> 
>   if (type == JUMP_LABEL_JMP) {
>   s32 off = (s32)entry->target - (s32)entry->code;
> + bool use_v9_branch = false;
> 
> #ifdef CONFIG_SPARC64
> - /* ba,pt %xcc, . + (off << 2) */
> - val = 0x1068 | ((u32) off >> 2);
> -#else
> - /* ba . + (off << 2) */
> - val = 0x1080 | ((u32) off >> 2);
> + if (off <= 0xf && off >= -0x10)
> + use_v9_branch = true;
> #endif
> + if (use_v9_branch) {
> + /* ba,pt %xcc, . + (off << 2) */
> + val = 0x10680000 | (((u32) off >> 2) & 0x7);
> + } else {
> + /* ba . + (off << 2) */
> + val = 0x1080 | (((u32) off >> 2) & 0x3f);
> + }
>   } else {
>   val = 0x0100;
>   }

Sure, that makes sense; updated and tested for a few hours:

From d5997fd98fc80d1ceabe11f6fcd63dfce99b8253 Mon Sep 17 00:00:00 2001
From: James Clarke <jrt...@jrtc27.com>
Date: Mon, 24 Oct 2016 19:49:25 +0100
Subject: [PATCH v2] sparc: Handle negative offsets in
 arch_jump_label_transform

Additionally, if the offset will overflow the immediate for a ba,pt
instruction, fall back on a standard ba to get an extra 3 bits.

Signed-off-by: James Clarke <jrt...@jrtc27.com>
---
 arch/sparc/kernel/jump_label.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
index 59bbeff..07933b9 100644
--- a/arch/sparc/kernel/jump_label.c
+++ b/arch/sparc/kernel/jump_label.c
@@ -13,19 +13,30 @@
 void arch_jump_label_transform(struct jump_entry *entry,
   enum jump_label_type type)
 {
-   u32 val;
u32 *insn = (u32 *) (unsigned long) entry->code;
+   u32 val;
 
if (type == JUMP_LABEL_JMP) {
s32 off = (s32)entry->target - (s32)entry->code;
+   bool use_v9_branch = false;
+
+   BUG_ON(off & 3);
 
 #ifdef CONFIG_SPARC64
-   /* ba,pt %xcc, . + (off << 2) */
-   val = 0x1068 | ((u32) off >> 2);
-#else
-   /* ba . + (off << 2) */
-   val = 0x1080 | ((u32) off >> 2);
+   if (off <= 0xf && off >= -0x10)
+   use_v9_branch = true;
 #endif
+   if (use_v9_branch) {
+   /* WDISP19 - target is . + immed << 2 */
+   /* ba,pt %xcc, . + off */
+   val = 0x1068 | (((u32) off >> 2) & 0x7);
+   } else {
+   /* WDISP22 - target is . + immed << 2 */
+   BUG_ON(off > 0x7f);
+   BUG_ON(off < -0x80);
+   /* ba . + off */
+   val = 0x1080 | (((u32) off >> 2) & 0x3f);
+   }
} else {
val = 0x0100;
}
-- 
2.9.3

Re: Regression with 4.7.2 on sun4u

[James Clarke]

On Fri, Oct 21, 2016 at 09:07:26PM -0400, David Miller wrote:
> From: James Clarke <jrt...@jrtc27.com>
> Date: Fri, 21 Oct 2016 22:52:45 +0100
> 
> > This indeed was the case. The attached patch fixes the problem for me,
> > generating 0x1062, which gdb can verify is sensible (of course, the
> > addresses have shifted slightly):
> 
> Please don't use attachments for patch submissions.
> 
> Patches must be inline so that they can be commented upon properly
> using simply email quoting mechanisms.
> 
> Thank you.

Ok; same patch inline:

From 27ecad347d19c613d4e85665e710f1bd6bd56117 Mon Sep 17 00:00:00 2001
From: James Clarke <jrt...@jrtc27.com>
Date: Fri, 21 Oct 2016 19:11:10 +0100
Subject: [PATCH] sparc: Handle negative offsets in arch_jump_label_transform

Signed-off-by: James Clarke <jrt...@jrtc27.com>
---
 arch/sparc/kernel/jump_label.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
index 59bbeff..dec09ce 100644
--- a/arch/sparc/kernel/jump_label.c
+++ b/arch/sparc/kernel/jump_label.c
@@ -19,12 +19,20 @@ void arch_jump_label_transform(struct jump_entry *entry,
if (type == JUMP_LABEL_JMP) {
s32 off = (s32)entry->target - (s32)entry->code;
 
+   BUG_ON(off & 3);
+
 #ifdef CONFIG_SPARC64
-   /* ba,pt %xcc, . + (off << 2) */
-   val = 0x1068 | ((u32) off >> 2);
+   /* WDISP19 - target is . + (immed << 2) */
+   BUG_ON(off > 0xf);
+   BUG_ON(off < -0x10);
+   /* ba,pt %xcc, . + off */
+   val = 0x1068 | (((u32) off >> 2) & 0x7);
 #else
-   /* ba . + (off << 2) */
-   val = 0x1080 | ((u32) off >> 2);
+   /* WDISP22 - target is . + (immed << 2) */
+   BUG_ON(off > 0x7f);
+   BUG_ON(off < -0x80);
+   /* ba . + off */
+   val = 0x1080 | (((u32) off >> 2) & 0x3f);
 #endif
} else {
val = 0x0100;
-- 
2.9.3



signature.asc
Description: PGP signature

Re: Regression with 4.7.2 on sun4u

[James Clarke]

> On 21 Oct 2016, at 18:47, James Clarke <jrt...@jrtc27.com> wrote:
>> On 21 Oct 2016, at 18:26, David Miller <da...@davemloft.net> wrote:
>> 
>> From: Rob Gardner <rob.gard...@oracle.com>
>> Date: Fri, 21 Oct 2016 09:49:30 -0600
>> 
>>> That could be either a stray memory write or a boot time patch gone
>>> wrong.
>> 
>> It could be that we need to use non-predicting branches in the jump
>> label implementation.  We could be overflowing the branch displacement
>> range if the kernel being built is really huge.
>> 
>> Something like the following would fix it if true:
>> 
>> diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
>> index 59bbeff..841d98e 100644
>> --- a/arch/sparc/kernel/jump_label.c
>> +++ b/arch/sparc/kernel/jump_label.c
>> @@ -19,13 +19,8 @@ void arch_jump_label_transform(struct jump_entry *entry,
>>   if (type == JUMP_LABEL_JMP) {
>>   s32 off = (s32)entry->target - (s32)entry->code;
>> 
>> -#ifdef CONFIG_SPARC64
>> -/* ba,pt %xcc, . + (off << 2) */
>> -val = 0x1068 | ((u32) off >> 2);
>> -#else
>>   /* ba . + (off << 2) */
>>   val = 0x1080 | ((u32) off >> 2);
>> -#endif
>>   } else {
>>   val = 0x0100;
>>   }
>> 
> 
> (Was top-post; moved here)
> 
> Yes, I found that. I don't think its overflowing, more negative (hence the
> 3ff2, which would be f88 or something like that for off). Trying with
> that masked appropriately. If it works I'll send a patch with appropriate
> BUG_ONs.

This indeed was the case. The attached patch fixes the problem for me,
generating 0x1062, which gdb can verify is sensible (of course, the
addresses have shifted slightly):

(gdb) x/10xw 0x5c9880
0x5c9880:   0x400f10d0  0x0100  0x1062  0x0100
0x5c9890:   0x106fffc8  0x0100  0xc611a036  0x05002c36
0x5c98a0:   0x8410a038  0x8328f030
(gdb) x/i 0x5c9888
   0x5c9888:b  %xcc, 0x5c9850
   0x5c988c:nop 

I also took the opportunity to correct the misleading/incorrect comments.
Please let me know if you’d like this properly submitted git-send-email style.

Regards,
James


0001-sparc-Handle-negative-offsets-in-arch_jump_label_tra.patch
Description: Binary data

Re: Regression with 4.7.2 on sun4u

[James Clarke]

(On phone, sorry for top-posting)
Yes, I found that. I don't think its overflowing, more negative (hence the 
3ff2, which would be f88 or something like that for off). Trying with 
that masked appropriately. If it works I'll send a patch with appropriate 
BUG_ONs.

James

> On 21 Oct 2016, at 18:26, David Miller  wrote:
> 
> From: Rob Gardner 
> Date: Fri, 21 Oct 2016 09:49:30 -0600
> 
>> That could be either a stray memory write or a boot time patch gone
>> wrong.
> 
> It could be that we need to use non-predicting branches in the jump
> label implementation.  We could be overflowing the branch displacement
> range if the kernel being built is really huge.
> 
> Something like the following would fix it if true:
> 
> diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c
> index 59bbeff..841d98e 100644
> --- a/arch/sparc/kernel/jump_label.c
> +++ b/arch/sparc/kernel/jump_label.c
> @@ -19,13 +19,8 @@ void arch_jump_label_transform(struct jump_entry *entry,
>if (type == JUMP_LABEL_JMP) {
>s32 off = (s32)entry->target - (s32)entry->code;
> 
> -#ifdef CONFIG_SPARC64
> -/* ba,pt %xcc, . + (off << 2) */
> -val = 0x1068 | ((u32) off >> 2);
> -#else
>/* ba . + (off << 2) */
>val = 0x1080 | ((u32) off >> 2);
> -#endif
>} else {
>val = 0x0100;
>}
> 

Re: Regression with 4.7.2 on sun4u

[James Clarke]

> On 21 Oct 2016, at 16:49, Rob Gardner  wrote:
> 
> On 10/21/2016 06:57 AM, Anatoly Pugachev wrote:
>> On Fri, Oct 21, 2016 at 12:12 PM, Anatoly Pugachev  
>> wrote:
>>> On Wed, Sep 7, 2016 at 1:01 PM, Anatoly Pugachev  wrote:
 On Wed, Sep 7, 2016 at 12:22 PM, John Paul Adrian Glaubitz
  wrote:
> Hello!
> 
> After kernel 4.7.2 entered Debian unstable, I decided to upgrade the 
> buildds and ran into an
> apparent regression with the 4.7.x kernels on sun4u machines:
 It's not only with sun4u, we're getting kernel OOPS on sun4v as well:
>>> debian packaged 4.7.6 kernel, machine is a LDOM on T5-2 server, OOPS
>>> after kernel boot within a few minutes:
>> 
>> reproduced with latest git 4.9.0-rc1+ (v4.9-rc1-148-g6f33d645) kernel.
>> Machine boots ok, i can login as unprivileged user (via ssh), compile
>> and install kernel, run sudo, install packages (apt upgrade),
>> apache/mysql and other startup daemons works, but if I try to login as
>> root via ssh, it throws kernel oops / illegal instruction.
>> 
>> Any idea how to debug this?
>> 
>> otherhost$ ssh ttip -l root -v
>> ...
>> debug1: channel 0: new [client-session]
>> debug1: Requesting no-more-sessi...@openssh.com
>> debug1: Entering interactive session.
>> Write failed: Broken pipe
>> $
>> 
>> I can strace -f -p $pid_of_sshd , but not sure it would help.
>> 
>> URL version => http://paste.debian.net/plain/884751
>> kernel config => http://paste.debian.net/plain/884806
>> 
>> NOTICE: Entering OpenBoot.
>> NOTICE: Fetching Guest MD from HV.
>> NOTICE: Starting additional cpus.
>> NOTICE: Initializing LDC services.
>> NOTICE: Probing PCI devices.
>> NOTICE: Finished PCI probing.
>> 
>> SPARC T5-2, No Keyboard
>> Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved.
>> OpenBoot 4.38.5, 32. GB memory available, Serial #83494642.
>> Ethernet address 0:14:4f:fa:6:f2, Host ID: 84fa06f2.
>> 
>> 
>> 
>> Boot device: vdisk1  File and args:
>> SILO Version 1.4.14
>> boot:
>> Allocated 64 Megs of memory at 0x4000 for kernel
>> Uncompressing image...
>> Loaded kernel version 4.9.0
>> Loading initial ramdisk (13616359 bytes at 0x7400 phys, 0x40C0 
>> virt)...
>> 
>> [0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.38.5 2016/06/22 19:36'
>> [0.00] PROMLIB: Root node compatible: sun4v
>> [0.00] Linux version 4.9.0-rc1+ (mator@ttip) (gcc version
>> 6.2.0 20161010 (Debian 6.2.0-6+sparc64) ) #19 SMP Fri Oct 21 14:47:01
>> MSK 2016
>> [0.00] bootconsole [earlyprom0] enabled
>> [0.00] ARCH: SUN4V
>> ... snip ...
>> [5446612.115339] dbus-daemon(521): Kernel illegal instruction [#3]
>> [5446612.115342] CPU: 15 PID: 521 Comm: dbus-daemon Tainted: G  D
>>4.9.0-rc1+ #19
>> [5446612.115347] task: fff800080b331bc0 task.stack: fff80007f937c000
>> [5446612.115349] TSTATE: 004411001606 TPC: 005ccfec TNPC:
>> 005ccff0 Y: Tainted: G  D
>> [5446612.115353] TPC: <__kmalloc_track_caller+0x14c/0x240>
>> [5446612.115355] g0: fff800080fb28b00 g1: 0040 g2:
>>  g3: c000
>> [5446612.115357] g4: fff800080b331bc0 g5: fff800082c5b g6:
>> fff80007f937c000 g7: 3c06
>> [5446612.115358] o0:  o1: 025106c0 o2:
>> 5a5a5a5a o3: fff800080fb28b00
>> [5446612.115360] o4: 5a5a5a5a5a5a5a5a o5: 0028 sp:
>> fff80007f937eda1 ret_pc: 005ccfe4
>> [5446612.115362] RPC: <__kmalloc_track_caller+0x144/0x240>
>> [5446612.115365] l0: fff830402800 l1: 07feffe44e40 l2:
>> 07feffe452b0 l3: 
>> [5446612.115367] l4:  l5: 0020 l6:
>> fff8000100b875c8 l7: fff800010026bf30
>> [5446612.115368] i0: 0240 i1: 025106c0 i2:
>> 00864e00 i3: 025106c0
>> [5446612.115371] i4:  i5: 025106c0 i6:
>> fff80007f937ee51 i7: 00864d40
>> [5446612.115376] I7: <__kmalloc_reserve.isra.5+0x20/0x80>
>> [5446612.115376] Call Trace:
>> [5446612.115378]  [00864d40] __kmalloc_reserve.isra.5+0x20/0x80
>> [5446612.115381]  [00864e00] __alloc_skb+0x60/0x180
>> [5446612.115383]  [00864f68] alloc_skb_with_frags+0x48/0x1c0
>> [5446612.115390]  [0085f54c] sock_alloc_send_pskb+0x1ec/0x220
>> [5446612.115400]  [009367a8] unix_stream_sendmsg+0x228/0x380
>> [5446612.115404]  [00859ddc] sock_sendmsg+0x3c/0x80
>> [5446612.115406]  [0085a810] ___sys_sendmsg+0x250/0x260
>> [5446612.115409]  [0085b794] __sys_sendmsg+0x34/0x80
>> [5446612.115411]  [0085b800] SyS_sendmsg+0x20/0x40
>> [5446612.115415]  [004061f4] linux_sparc_syscall+0x34/0x44
>> [5446612.115417] Caller[00864d40]: __kmalloc_reserve.isra.5+0x20/0x80
>> [5446612.115419] Caller[00864e00]: __alloc_skb+0x60/0x180
>> [5446612.115423] 

Re: Bug#840574: Please backport libgo fixes for sparc64

[James Clarke]

Control: tags -1 patch
(almost; explained below)

Hi Matthias,
On Tue, Oct 18, 2016 at 01:47:20PM +0200, Matthias Klose wrote:
> Control: tags -1 - patch
>
> James, based on your feedback, I tried to apply these revisions on the branch,
> had to update some of these, and got a failed build. I'm not intending to work
> on this, and would like to ask you to prepare a tested debdiff for a backport 
> or
> to get the backport upstream if you want to include the libgo port into the
> gcc-6 Debian packages.

Please find a debdiff attached; I have successfully built it on sparc64.

There is just *one* little detail which messes this up (and perhaps was
the cause of your failure?): libgo-elf-relocations-sparc64.diff
references a new binary file (for the test suite), but "svn diff"
doesn't include the actual data, nor does quilt seem to support
git-style binary diffs. Please either remove the hunks for
libgo/go/debug/elf/{file_test.go,testdata/go-relocation-test-gcc620-sparc64.obj}
or place a copy of the latter .obj in the source package and ensure it
gets copied to the same relative directory under src when
unpacking/patching.

Do let me know if I can do anything else to make this happen. I will
also see if I can get them backported upstream (though even with that
you'll still need to faff about with the .obj or drop the test...).

Thanks,
James

> On 16.10.2016 19:40, James Clarke wrote:
> > Control: tags -1 - help + patch
> >
> > Hi Matthias,
> > On Thu, Oct 13, 2016 at 01:50:43PM +0200, Matthias Klose wrote:
> >> Control: tags -1 + help
> >> Control: tags -1 - patch
> >>
> >> James, please could you name the revisions in the GCC subversion 
> >> repository?
> >> Afaics these are r241084, r241077, r241051.  Even better, could you test 
> >> and
> >> propose this backport upstream?
> >
> > To confirm, they are the following revisions:
> >
> > * r241171 (sparc64 relocations, e1fc2925 in go master, now also in
> >gofrontend/gccgo)
> > * r241084 (don't use pt_regs; unnecessary, and seemingly not defined by
> >the included headers on arm64)
> > * r241072 (make rawClone no_split_stack)
> > * r241051 (fix getrandom on sparc64 and clone on sparc*)
> > * r240457 (add getrandom for MIPS/SPARC)
> >
> > We've been using the latest gcc-6 package with these patches (other than
> > no_split_stack and pt_regs fixups) applied on top for sparc64 (uploaded
> > to unreleased) for the past few days, and the only packages which fail
> > to build seem to be because Debian currently has an out-of-date x/sys
> > package without sparc64 definitions. I haven't been aware of any
> > regressions.
> >
> > Ian: I imagine the getrandom and elf changes would be fine for gcc-6,
> > but what about the clone changes? I can understand if that's too
> > invasive, but backporting would be great.
> >
> > Regards,
> > James
> >
> >> On 12.10.2016 23:35, James Clarke wrote:
> >>> Source: gcc-6
> >>> Version: 6.2.0-6
> >>> User: debian-sparc@lists.debian.org
> >>> Usertags: sparc64
> >>> X-Debbugs-Cc: debian-sparc@lists.debian.org
> >>> Tags: patch fixed-upstream
> >>>
> >>> Hi,
> >>> Could you please backport the patches listed below so that we can have a
> >>> working gccgo? They fix the (minor) issue of using the wrong syscall
> >>> number for getrandom (if code uses it), add support for sparc64's
> >>> relocations, and also the following error when running go build:
> >>>
> >>> /usr/bin/sparc64-linux-gnu-gccgo-6: wait: no child processes
> >>> /usr/bin/sparc64-linux-gnu-gccgo-6: exit status 1
> >>>
> >>> The patches are:
> >>>
> >>> https://go.googlesource.com/go/+/e1fc292500aa70c265937aebad00ac010031cbaf
> >>> (not yet pulled into gofrontend's libgo)
> >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a357a86a9f2772561454ce17ef13a89a51fc4a27
> >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0509fa0eae193f8d99886e9b6a1feda4c6c16356
> >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3457370357929d70f26873e914fae6ea6f1a8ffd
> >>>
> >>> With all but the last patch (a minor fixup after my patches), I have
> >>> been able to successfully build and run go programs on sparc64.
> >>>
> >>> Regards,
> >>> James
> >>>
> >>
>
diff -u gcc-6-6.2.0/debian/changelog gcc-6-6.2.0/debian/changelog
--- gcc-6-6.2.0/debian/changelog
+++ gcc-6-6.2.0/debian/changelog
@@ -1,3 +1,16 

Re: Bug#840423 closed by James Clarke <jrt...@jrtc27.com> (Re: Bug#840423: New upstream version with sparc64 support)

[James Clarke]

Control: reopen -1

In fact, 9bb9f09 itself broke sparc64 and s390x. Please update to
002cbb5 to fix this.

Regards,
James


signature.asc
Description: PGP signature

Re: Bug#840423: New upstream version with sparc64 support

[James Clarke]

Version: 0.0~git20161012.0.9bb9f09-1

On Sun, Oct 16, 2016 at 07:51:56PM +0200, John Paul Adrian Glaubitz wrote:
> Sorry for offlist and HTML (currently on the train).
>
> I just checked, they uploaded a new snapshot today. Can you check whether 
> your changes are in?

Yes, they are. I probably should have checked the PTS before sending
this... A Closes: would have been helpful though.

James

> > On Oct 16, 2016, at 7:45 PM, James Clarke <jrt...@jrtc27.com> wrote:
> >
> > Hi,
> >> On Tue, Oct 11, 2016 at 02:27:37PM +0100, James Clarke wrote:
> >> Source: golang-golang-x-sys
> >> Version: 0.0~git20160704.0.a408501-1
> >> X-Debbugs-Cc: debian-sparc@lists.debian.org
> >> User: debian-sparc@lists.debian.org
> >> Usertags: sparc64
> >>
> >> Hi,
> >> Upstream has made several commits to golang.org/x/sys since the last
> >> uploaded version, the latest being adding sparc64 support (67f277b).
> >> Please either cherry-pick the patch or update to the latest version.
> >>
> >> Regards,
> >> James
> >
> > Any progress on this? I'm happy to perform the upload myself, either as
> > an NMU or by joining pkg-go and performing a team upload, if that helps.
> >
> > Regards,
> > James
>


signature.asc
Description: PGP signature

Re: Bug#840423: New upstream version with sparc64 support

[James Clarke]

Hi,
On Tue, Oct 11, 2016 at 02:27:37PM +0100, James Clarke wrote:
> Source: golang-golang-x-sys
> Version: 0.0~git20160704.0.a408501-1
> X-Debbugs-Cc: debian-sparc@lists.debian.org
> User: debian-sparc@lists.debian.org
> Usertags: sparc64
>
> Hi,
> Upstream has made several commits to golang.org/x/sys since the last
> uploaded version, the latest being adding sparc64 support (67f277b).
> Please either cherry-pick the patch or update to the latest version.
>
> Regards,
> James

Any progress on this? I'm happy to perform the upload myself, either as
an NMU or by joining pkg-go and performing a team upload, if that helps.

Regards,
James


signature.asc
Description: PGP signature

Re: Bug#840574: Please backport libgo fixes for sparc64

[James Clarke]

Control: tags -1 - help + patch

Hi Matthias,
On Thu, Oct 13, 2016 at 01:50:43PM +0200, Matthias Klose wrote:
> Control: tags -1 + help
> Control: tags -1 - patch
>
> James, please could you name the revisions in the GCC subversion repository?
> Afaics these are r241084, r241077, r241051.  Even better, could you test and
> propose this backport upstream?

To confirm, they are the following revisions:

* r241171 (sparc64 relocations, e1fc2925 in go master, now also in
   gofrontend/gccgo)
* r241084 (don't use pt_regs; unnecessary, and seemingly not defined by
   the included headers on arm64)
* r241072 (make rawClone no_split_stack)
* r241051 (fix getrandom on sparc64 and clone on sparc*)
* r240457 (add getrandom for MIPS/SPARC)

We've been using the latest gcc-6 package with these patches (other than
no_split_stack and pt_regs fixups) applied on top for sparc64 (uploaded
to unreleased) for the past few days, and the only packages which fail
to build seem to be because Debian currently has an out-of-date x/sys
package without sparc64 definitions. I haven't been aware of any
regressions.

Ian: I imagine the getrandom and elf changes would be fine for gcc-6,
but what about the clone changes? I can understand if that's too
invasive, but backporting would be great.

Regards,
James

> On 12.10.2016 23:35, James Clarke wrote:
> > Source: gcc-6
> > Version: 6.2.0-6
> > User: debian-sparc@lists.debian.org
> > Usertags: sparc64
> > X-Debbugs-Cc: debian-sparc@lists.debian.org
> > Tags: patch fixed-upstream
> >
> > Hi,
> > Could you please backport the patches listed below so that we can have a
> > working gccgo? They fix the (minor) issue of using the wrong syscall
> > number for getrandom (if code uses it), add support for sparc64's
> > relocations, and also the following error when running go build:
> >
> > /usr/bin/sparc64-linux-gnu-gccgo-6: wait: no child processes
> > /usr/bin/sparc64-linux-gnu-gccgo-6: exit status 1
> >
> > The patches are:
> >
> > https://go.googlesource.com/go/+/e1fc292500aa70c265937aebad00ac010031cbaf
> > (not yet pulled into gofrontend's libgo)
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a357a86a9f2772561454ce17ef13a89a51fc4a27
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0509fa0eae193f8d99886e9b6a1feda4c6c16356
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3457370357929d70f26873e914fae6ea6f1a8ffd
> >
> > With all but the last patch (a minor fixup after my patches), I have
> > been able to successfully build and run go programs on sparc64.
> >
> > Regards,
> > James
> >
>


signature.asc
Description: PGP signature

Bug#840574: Please backport libgo fixes for sparc64

[James Clarke]

Source: gcc-6
Version: 6.2.0-6
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Tags: patch fixed-upstream

Hi,
Could you please backport the patches listed below so that we can have a
working gccgo? They fix the (minor) issue of using the wrong syscall
number for getrandom (if code uses it), add support for sparc64's
relocations, and also the following error when running go build:

/usr/bin/sparc64-linux-gnu-gccgo-6: wait: no child processes
/usr/bin/sparc64-linux-gnu-gccgo-6: exit status 1

The patches are:

https://go.googlesource.com/go/+/e1fc292500aa70c265937aebad00ac010031cbaf
(not yet pulled into gofrontend's libgo)
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a357a86a9f2772561454ce17ef13a89a51fc4a27
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0509fa0eae193f8d99886e9b6a1feda4c6c16356
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3457370357929d70f26873e914fae6ea6f1a8ffd

With all but the last patch (a minor fixup after my patches), I have
been able to successfully build and run go programs on sparc64.

Regards,
James


signature.asc
Description: PGP signature

Bug#840423: New upstream version with sparc64 support

[James Clarke]

Source: golang-golang-x-sys
Version: 0.0~git20160704.0.a408501-1
X-Debbugs-Cc: debian-sparc@lists.debian.org
User: debian-sparc@lists.debian.org
Usertags: sparc64

Hi,
Upstream has made several commits to golang.org/x/sys since the last
uploaded version, the latest being adding sparc64 support (67f277b).
Please either cherry-pick the patch or update to the latest version.

Regards,
James


signature.asc
Description: PGP signature