Mailing List Archive

Official SPARC64 Port
I'm going to try to keep all future discussion of this in this thread
for now on.

If you've kept up with the sparc list lately (seems like very few people
do these days) i've been working on fixing up the sparc port to include
a pure 64bit port. Basically here is where we stand in regard to the
completion of this project.

Profiles:
sparc32: Done
sparc32-multilib: Done
sparc64: Done
sparc64-multilib: Done

Stage3's
sparc32: Booting
sparc32-multilib: Booting
sparc64: Booting + Fairly Well Tested
sparc64-multilib: Booting

Install ISO: TODO

The profiles have all been reworked quite a bit, which is why i feel the
need to test all of them thoroughly.

It's also worth noting that at this moment i am not an official Gentoo
developer, although i am working towards having that goal met in the
very near future. So at this point it's possible all of my work is junk
as no one has really looked over it but me :p, so keep that in mind.
That being said, i am posting this from an Ultra 45 with ZFS and a
native 64bit userland ;)

Ok, so now on to an issue...

pciutils will not compile on sparc64, which i believe could be udev
related. See the error below.

../../lib64/libudev.so: Only registers %g[2367] can be declared using
STT_REGISTER

It seems like systemd also has a similar issue.
https://sourceware.org/bugzilla/show_bug.cgi?id=19019

Originally it was decided to use the old sparc keyword for sparc32 and
sparc64, but in this case we have an app that will compile on sparc32
but not sparc64. How should this be handled? A new keyword would be a
pain, so is there another way of dealing with this?
Re: Official SPARC64 Port [ In reply to ]
On 28 Jan 2016 18:06, Alex McWhirter wrote:
> It's also worth noting that at this moment i am not an official Gentoo
> developer, although i am working towards having that goal met in the
> very near future. So at this point it's possible all of my work is junk
> as no one has really looked over it but me :p, so keep that in mind.

you don't have to be a dev to get your work merged. you just have to
be a dev to do the final push yourself. so if you have changes that
you think are ready to go now, we can get them merged.

> pciutils will not compile on sparc64, which i believe could be udev
> related. See the error below.
>
> ../../lib64/libudev.so: Only registers %g[2367] can be declared using
> STT_REGISTER
>
> It seems like systemd also has a similar issue.
> https://sourceware.org/bugzilla/show_bug.cgi?id=19019

that bug indicates it's a bug when using gold. so if things are working
fine w/ld.bfd, then it's fine to move forward. that bug also makes it
sound like there's something fundamentally broken in gold that udev just
happens to trip over, so we'd simply say gold isn't yet supported for
sparc.

> Originally it was decided to use the old sparc keyword for sparc32 and
> sparc64, but in this case we have an app that will compile on sparc32
> but not sparc64. How should this be handled? A new keyword would be a
> pain, so is there another way of dealing with this?

let's ignore the bfd-vs-gold aspect and just assume that it's a situation
where sparc64 always fails and sparc32 always works, and there's no way
to fix the problem. if that truly is the case, packages can be masked in
the sparc64-specific linux profile. it's a bit heavy weight, but since
this scenario rarely comes up, it's not that big of a deal.

a more pertinent example would probably be something like grub-0. the
code fundamentally assumes 32-bit everywhere, and links against 32-bit
system libs, so it's not worth our effort to try and rewrite the code
to work in a 64-bit env. on amd64 non-multilib systems, we mask it,
and provide a grub-static package instead.
-mike
Re: Re: Official SPARC64 Port [ In reply to ]
On 01/28/2016 06:26 PM, Mike Frysinger wrote:
>
> you don't have to be a dev to get your work merged. you just have to
> be a dev to do the final push yourself. so if you have changes that
> you think are ready to go now, we can get them merged.

I want to do a bit more testing to ensure im not going to break any
existing sparc32 installs. I am fairly certain that we are going to
break sparc32 + multilib, but considering that profile was never
officially released it may not be that big of a deal.

My main concern with sparc32 + multilib is what happens when you have
system installed with SYMLINK_LIB="yes" and later change it to "no".

> let's ignore the bfd-vs-gold aspect and just assume that it's a situation
> where sparc64 always fails and sparc32 always works, and there's no way
> to fix the problem. if that truly is the case, packages can be masked in
> the sparc64-specific linux profile. it's a bit heavy weight, but since
> this scenario rarely comes up, it's not that big of a deal.
>
> a more pertinent example would probably be something like grub-0. the
> code fundamentally assumes 32-bit everywhere, and links against 32-bit
> system libs, so it's not worth our effort to try and rewrite the code
> to work in a 64-bit env. on amd64 non-multilib systems, we mask it,
> and provide a grub-static package instead.
> -mike

True, that slipped my mind. I've already had to patch a few things that
make assumptions about things they otherwise shouldn't, sparc-utils
being a prime example which always assumes a 32bit userland and breaks
silo in a 64bit userland. So if it ends up not being an insanely
complicated issue ill take a stab at it. However, I'll save that
discussion for another day.
Re: Re: Official SPARC64 Port [ In reply to ]
On 28 Jan 2016 18:37, Alex McWhirter wrote:
> On 01/28/2016 06:26 PM, Mike Frysinger wrote:
> > you don't have to be a dev to get your work merged. you just have to
> > be a dev to do the final push yourself. so if you have changes that
> > you think are ready to go now, we can get them merged.
>
> I want to do a bit more testing to ensure im not going to break any
> existing sparc32 installs. I am fairly certain that we are going to
> break sparc32 + multilib, but considering that profile was never
> officially released it may not be that big of a deal.
>
> My main concern with sparc32 + multilib is what happens when you have
> system installed with SYMLINK_LIB="yes" and later change it to "no".

the profile is explicitly labeled "experimental":
default/linux/sparc/experimental/multilib

so just deleting it and forcing the people (if any) to manually update
is fine. you don't run "experimental" on a system in production ;).
-mike
Re: Official SPARC64 Port [ In reply to ]
Regarding the issue with pcitutils, it is indeed and issue with gold. It
turns out udev is broken as well, as in it wont start.

binutils has supposedly fixed this issue upstream, i may try to emerge
9999 later tonight. perhaps eudev fairs a bit better than udev? Would
there be any issue with moving to eudev as a default?
Re: Official SPARC64 Port [ In reply to ]
On 29 Jan 2016 19:28, Alex McWhirter wrote:
> Regarding the issue with pcitutils, it is indeed and issue with gold. It
> turns out udev is broken as well, as in it wont start.
>
> binutils has supposedly fixed this issue upstream, i may try to emerge
> 9999 later tonight. perhaps eudev fairs a bit better than udev? Would
> there be any issue with moving to eudev as a default?

arches should not be picking any defaults like udev. we should be using
the same default across all linux systems. especially if the only point
is to workaround a bug in gold.

is the fix in binutils-2.26 ? that's going into the tree in a bit ...
i'm waiting for some feedback from upstream before i push it.
-mike
Re: Official SPARC64 Port [ In reply to ]
On 01/29/2016 07:44 PM, Mike Frysinger wrote:
> On 29 Jan 2016 19:28, Alex McWhirter wrote:
>> Regarding the issue with pcitutils, it is indeed and issue with gold. It
>> turns out udev is broken as well, as in it wont start.
>>
>> binutils has supposedly fixed this issue upstream, i may try to emerge
>> 9999 later tonight. perhaps eudev fairs a bit better than udev? Would
>> there be any issue with moving to eudev as a default?
> arches should not be picking any defaults like udev. we should be using
> the same default across all linux systems. especially if the only point
> is to workaround a bug in gold.
>
> is the fix in binutils-2.26 ? that's going into the tree in a bit ...
> i'm waiting for some feedback from upstream before i push it.
> -mike

I can check to see if the fix is in .26, but eudev does work without
issue for what it's worth. pciutils is also compiling without issue with
eudev.

I will try pulling 9999 and see if the issue is no longer there, if it's
been resolved there then ill check into .26

Without that fix, sparc64 is probably a no-go. I suppose we could always
patch .25 if needed.
Re: Official SPARC64 Port [ In reply to ]
No change in 9999, which is strange. Maybe i was wrong about the fix for
gold.

On 01/29/2016 07:55 PM, Alex McWhirter wrote:
> On 01/29/2016 07:44 PM, Mike Frysinger wrote:
>> On 29 Jan 2016 19:28, Alex McWhirter wrote:
>>> Regarding the issue with pcitutils, it is indeed and issue with gold. It
>>> turns out udev is broken as well, as in it wont start.
>>>
>>> binutils has supposedly fixed this issue upstream, i may try to emerge
>>> 9999 later tonight. perhaps eudev fairs a bit better than udev? Would
>>> there be any issue with moving to eudev as a default?
>> arches should not be picking any defaults like udev. we should be using
>> the same default across all linux systems. especially if the only point
>> is to workaround a bug in gold.
>>
>> is the fix in binutils-2.26 ? that's going into the tree in a bit ...
>> i'm waiting for some feedback from upstream before i push it.
>> -mike
> I can check to see if the fix is in .26, but eudev does work without
> issue for what it's worth. pciutils is also compiling without issue with
> eudev.
>
> I will try pulling 9999 and see if the issue is no longer there, if it's
> been resolved there then ill check into .26
>
> Without that fix, sparc64 is probably a no-go. I suppose we could always
> patch .25 if needed.
>
Re: Official SPARC64 Port [ In reply to ]
On 29 Jan 2016 19:55, Alex McWhirter wrote:
> On 01/29/2016 07:44 PM, Mike Frysinger wrote:
> > On 29 Jan 2016 19:28, Alex McWhirter wrote:
> >> Regarding the issue with pcitutils, it is indeed and issue with gold. It
> >> turns out udev is broken as well, as in it wont start.
> >>
> >> binutils has supposedly fixed this issue upstream, i may try to emerge
> >> 9999 later tonight. perhaps eudev fairs a bit better than udev? Would
> >> there be any issue with moving to eudev as a default?
> >
> > arches should not be picking any defaults like udev. we should be using
> > the same default across all linux systems. especially if the only point
> > is to workaround a bug in gold.
> >
> > is the fix in binutils-2.26 ? that's going into the tree in a bit ...
> > i'm waiting for some feedback from upstream before i push it.
>
> I can check to see if the fix is in .26, but eudev does work without
> issue for what it's worth. pciutils is also compiling without issue with
> eudev.
>
> I will try pulling 9999 and see if the issue is no longer there, if it's
> been resolved there then ill check into .26
>
> Without that fix, sparc64 is probably a no-go. I suppose we could always
> patch .25 if needed.

why ? as i said, gold is not the default, and we don't hold up issues
because of gold compatibility. if sparc64 w/ld.bfd works fine, then
that's all we need.
-mike
Re: Official SPARC64 Port [ In reply to ]
On 02/01/2016 12:44 PM, Mike Frysinger wrote:
> On 29 Jan 2016 19:55, Alex McWhirter wrote:
>> On 01/29/2016 07:44 PM, Mike Frysinger wrote:
>>> On 29 Jan 2016 19:28, Alex McWhirter wrote:
>>>> Regarding the issue with pcitutils, it is indeed and issue with gold. It
>>>> turns out udev is broken as well, as in it wont start.
>>>>
>>>> binutils has supposedly fixed this issue upstream, i may try to emerge
>>>> 9999 later tonight. perhaps eudev fairs a bit better than udev? Would
>>>> there be any issue with moving to eudev as a default?
>>> arches should not be picking any defaults like udev. we should be using
>>> the same default across all linux systems. especially if the only point
>>> is to workaround a bug in gold.
>>>
>>> is the fix in binutils-2.26 ? that's going into the tree in a bit ...
>>> i'm waiting for some feedback from upstream before i push it.
>> I can check to see if the fix is in .26, but eudev does work without
>> issue for what it's worth. pciutils is also compiling without issue with
>> eudev.
>>
>> I will try pulling 9999 and see if the issue is no longer there, if it's
>> been resolved there then ill check into .26
>>
>> Without that fix, sparc64 is probably a no-go. I suppose we could always
>> patch .25 if needed.
> why ? as i said, gold is not the default, and we don't hold up issues
> because of gold compatibility. if sparc64 w/ld.bfd works fine, then
> that's all we need.
> -mike
>

It looks like udev is hard coded to use gold, i may have to hack around
with configure.ac to get it to compile with bfd.
Re: Official SPARC64 Port [ In reply to ]
On 01 Feb 2016 14:29, Alex McWhirter wrote:
> On 02/01/2016 12:44 PM, Mike Frysinger wrote:
> > On 29 Jan 2016 19:55, Alex McWhirter wrote:
> >> On 01/29/2016 07:44 PM, Mike Frysinger wrote:
> >>> On 29 Jan 2016 19:28, Alex McWhirter wrote:
> >>>> Regarding the issue with pcitutils, it is indeed and issue with gold. It
> >>>> turns out udev is broken as well, as in it wont start.
> >>>>
> >>>> binutils has supposedly fixed this issue upstream, i may try to emerge
> >>>> 9999 later tonight. perhaps eudev fairs a bit better than udev? Would
> >>>> there be any issue with moving to eudev as a default?
> >>> arches should not be picking any defaults like udev. we should be using
> >>> the same default across all linux systems. especially if the only point
> >>> is to workaround a bug in gold.
> >>>
> >>> is the fix in binutils-2.26 ? that's going into the tree in a bit ...
> >>> i'm waiting for some feedback from upstream before i push it.
> >>
> >> I can check to see if the fix is in .26, but eudev does work without
> >> issue for what it's worth. pciutils is also compiling without issue with
> >> eudev.
> >>
> >> I will try pulling 9999 and see if the issue is no longer there, if it's
> >> been resolved there then ill check into .26
> >>
> >> Without that fix, sparc64 is probably a no-go. I suppose we could always
> >> patch .25 if needed.
> >
> > why ? as i said, gold is not the default, and we don't hold up issues
> > because of gold compatibility. if sparc64 w/ld.bfd works fine, then
> > that's all we need.
>
> It looks like udev is hard coded to use gold, i may have to hack around
> with configure.ac to get it to compile with bfd.

OK, that's an important point :). yes, we'll want to deploy a hack for
`use sparc` to the udev ebuild to disable the usage of gold. should be
as simple as:
if use sparc ; then
sed -i 's:-Wl,-fuse-ld=gold::' configure.ac || die
fi
-mike
Re: Official SPARC64 Port [ In reply to ]
On 02/01/2016 03:24 PM, Mike Frysinger wrote:
> On 01 Feb 2016 14:29, Alex McWhirter wrote:
>> On 02/01/2016 12:44 PM, Mike Frysinger wrote:
>>> On 29 Jan 2016 19:55, Alex McWhirter wrote:
>>>> On 01/29/2016 07:44 PM, Mike Frysinger wrote:
>>>>> On 29 Jan 2016 19:28, Alex McWhirter wrote:
>>>>>> Regarding the issue with pcitutils, it is indeed and issue with gold. It
>>>>>> turns out udev is broken as well, as in it wont start.
>>>>>>
>>>>>> binutils has supposedly fixed this issue upstream, i may try to emerge
>>>>>> 9999 later tonight. perhaps eudev fairs a bit better than udev? Would
>>>>>> there be any issue with moving to eudev as a default?
>>>>> arches should not be picking any defaults like udev. we should be using
>>>>> the same default across all linux systems. especially if the only point
>>>>> is to workaround a bug in gold.
>>>>>
>>>>> is the fix in binutils-2.26 ? that's going into the tree in a bit ...
>>>>> i'm waiting for some feedback from upstream before i push it.
>>>> I can check to see if the fix is in .26, but eudev does work without
>>>> issue for what it's worth. pciutils is also compiling without issue with
>>>> eudev.
>>>>
>>>> I will try pulling 9999 and see if the issue is no longer there, if it's
>>>> been resolved there then ill check into .26
>>>>
>>>> Without that fix, sparc64 is probably a no-go. I suppose we could always
>>>> patch .25 if needed.
>>> why ? as i said, gold is not the default, and we don't hold up issues
>>> because of gold compatibility. if sparc64 w/ld.bfd works fine, then
>>> that's all we need.
>> It looks like udev is hard coded to use gold, i may have to hack around
>> with configure.ac to get it to compile with bfd.
> OK, that's an important point :). yes, we'll want to deploy a hack for
> `use sparc` to the udev ebuild to disable the usage of gold. should be
> as simple as:
> if use sparc ; then
> sed -i 's:-Wl,-fuse-ld=gold::' configure.ac || die
> fi
> -mike

The systemd mailing list makes it look like this may not be a sparc only
problem, it looks like it can also happen to 64 bit mips. What about
patching configure.ac to have an --disable-lto option?

if use sparc ; then
configure_opts+=" --disable-lto "
fi
Re: Official SPARC64 Port [ In reply to ]
On 01 Feb 2016 15:34, Alex McWhirter wrote:
> On 02/01/2016 03:24 PM, Mike Frysinger wrote:
> > On 01 Feb 2016 14:29, Alex McWhirter wrote:
> >> On 02/01/2016 12:44 PM, Mike Frysinger wrote:
> >>> On 29 Jan 2016 19:55, Alex McWhirter wrote:
> >>>> On 01/29/2016 07:44 PM, Mike Frysinger wrote:
> >>>>> On 29 Jan 2016 19:28, Alex McWhirter wrote:
> >>>>>> Regarding the issue with pcitutils, it is indeed and issue with gold. It
> >>>>>> turns out udev is broken as well, as in it wont start.
> >>>>>>
> >>>>>> binutils has supposedly fixed this issue upstream, i may try to emerge
> >>>>>> 9999 later tonight. perhaps eudev fairs a bit better than udev? Would
> >>>>>> there be any issue with moving to eudev as a default?
> >>>>> arches should not be picking any defaults like udev. we should be using
> >>>>> the same default across all linux systems. especially if the only point
> >>>>> is to workaround a bug in gold.
> >>>>>
> >>>>> is the fix in binutils-2.26 ? that's going into the tree in a bit ...
> >>>>> i'm waiting for some feedback from upstream before i push it.
> >>>> I can check to see if the fix is in .26, but eudev does work without
> >>>> issue for what it's worth. pciutils is also compiling without issue with
> >>>> eudev.
> >>>>
> >>>> I will try pulling 9999 and see if the issue is no longer there, if it's
> >>>> been resolved there then ill check into .26
> >>>>
> >>>> Without that fix, sparc64 is probably a no-go. I suppose we could always
> >>>> patch .25 if needed.
> >>> why ? as i said, gold is not the default, and we don't hold up issues
> >>> because of gold compatibility. if sparc64 w/ld.bfd works fine, then
> >>> that's all we need.
> >> It looks like udev is hard coded to use gold, i may have to hack around
> >> with configure.ac to get it to compile with bfd.
> > OK, that's an important point :). yes, we'll want to deploy a hack for
> > `use sparc` to the udev ebuild to disable the usage of gold. should be
> > as simple as:
> > if use sparc ; then
> > sed -i 's:-Wl,-fuse-ld=gold::' configure.ac || die
> > fi
>
> The systemd mailing list makes it look like this may not be a sparc only
> problem, it looks like it can also happen to 64 bit mips. What about
> patching configure.ac to have an --disable-lto option?

in cases like this, the preference would be to get any patches merged
upstream, and then add that to our ebuild. but if upstream won't pick
up a patch that'll help, just minimize the sed/patch hackary. generally
the whole point of doing a "clean" patch is to get it merged upstream.
-mike
Re: Official SPARC64 Port [ In reply to ]
On 02/01/2016 03:51 PM, Mike Frysinger wrote:
> in cases like this, the preference would be to get any patches merged
> upstream, and then add that to our ebuild. but if upstream won't pick
> up a patch that'll help, just minimize the sed/patch hackary. generally
> the whole point of doing a "clean" patch is to get it merged upstream.
> -mike

Ok, ill shoot a pull request over to systemd, hopefully they will
acknowledge the issue instead of insisting the only way to fix it is for
gold to be fixed.

anyways you're sed one-liner works perfectly on 225, so if we could get
that pushed that should fix up standard catalyst builds without any
custom tree hacks.
Re: Official SPARC64 Port [ In reply to ]
On 02/01/2016 05:03 PM, Alex McWhirter wrote:
> On 02/01/2016 03:51 PM, Mike Frysinger wrote:
>> in cases like this, the preference would be to get any patches merged
>> upstream, and then add that to our ebuild. but if upstream won't pick
>> up a patch that'll help, just minimize the sed/patch hackary. generally
>> the whole point of doing a "clean" patch is to get it merged upstream.
>> -mike
> Ok, ill shoot a pull request over to systemd, hopefully they will
> acknowledge the issue instead of insisting the only way to fix it is for
> gold to be fixed.
>
> anyways you're sed one-liner works perfectly on 225, so if we could get
> that pushed that should fix up standard catalyst builds without any
> custom tree hacks.
>

I'd like to get the udev fix and a glibc fix pushed into the tree
because they aren't handled by the sparc team. What would be the best
way to go about this?
Re: Official SPARC64 Port [ In reply to ]
On 04 Feb 2016 13:40, Alex McWhirter wrote:
> On 02/01/2016 05:03 PM, Alex McWhirter wrote:
> > On 02/01/2016 03:51 PM, Mike Frysinger wrote:
> >> in cases like this, the preference would be to get any patches merged
> >> upstream, and then add that to our ebuild. but if upstream won't pick
> >> up a patch that'll help, just minimize the sed/patch hackary. generally
> >> the whole point of doing a "clean" patch is to get it merged upstream.
> >
> > Ok, ill shoot a pull request over to systemd, hopefully they will
> > acknowledge the issue instead of insisting the only way to fix it is for
> > gold to be fixed.
> >
> > anyways you're sed one-liner works perfectly on 225, so if we could get
> > that pushed that should fix up standard catalyst builds without any
> > custom tree hacks.
>
> I'd like to get the udev fix and a glibc fix pushed into the tree
> because they aren't handled by the sparc team. What would be the best
> way to go about this?

you can file a bug for each issue and attach the patch and it'll get
routed to the right person. you could just post the glibc one here
and i'll review/merge it directly.
-mike
Re: Official SPARC64 Port [ In reply to ]
On 02/04/2016 04:54 PM, Mike Frysinger wrote:
> On 04 Feb 2016 13:40, Alex McWhirter wrote:
>> On 02/01/2016 05:03 PM, Alex McWhirter wrote:
>>> On 02/01/2016 03:51 PM, Mike Frysinger wrote:
>>>> in cases like this, the preference would be to get any patches merged
>>>> upstream, and then add that to our ebuild. but if upstream won't pick
>>>> up a patch that'll help, just minimize the sed/patch hackary. generally
>>>> the whole point of doing a "clean" patch is to get it merged upstream.
>>> Ok, ill shoot a pull request over to systemd, hopefully they will
>>> acknowledge the issue instead of insisting the only way to fix it is for
>>> gold to be fixed.
>>>
>>> anyways you're sed one-liner works perfectly on 225, so if we could get
>>> that pushed that should fix up standard catalyst builds without any
>>> custom tree hacks.
>> I'd like to get the udev fix and a glibc fix pushed into the tree
>> because they aren't handled by the sparc team. What would be the best
>> way to go about this?
> you can file a bug for each issue and attach the patch and it'll get
> routed to the right person. you could just post the glibc one here
> and i'll review/merge it directly.
> -mike

Bug for glibc - https://bugs.gentoo.org/show_bug.cgi?id=573872

Bug for udev - https://bugs.gentoo.org/show_bug.cgi?id=573874
Re: Official SPARC64 Port [ In reply to ]
Have there been any reports of rsync being broken on sparc? I can't get
it to work on my 64bit host or my official 32 bit host.

It always kicks this back almost instantly. Doesn't matter if it's local
or remote

rsync: [sender] write error: Broken pipe (32)


Oddly enough scp has issues too which may point to something being wrong
with ssh. This is what happens.

On remote machine run..


scp blah root@<ip-address>:~/
root@<ip-address>'s password:
Permission denied, please try again.
root@<ip-address>'s password:
Permission denied, please try again.
root@<ip-address>'s password:
Permission denied ().
lost connection

However if i try a second / third time...

scp blah root@<ip-address>:~/
Password:
blah 100%
102MB 11.4MB/s 13.0MB/s 00:09


Notice how in the first attempt sshd is returning the boxes IP and wont
take my password. A few attempts later and it will not return the IP,
but will take my password. It's completely intermittent.
Re: Official SPARC64 Port [ In reply to ]
On 07 Feb 2016 05:35, Alex McWhirter wrote:
> Have there been any reports of rsync being broken on sparc? I can't get
> it to work on my 64bit host or my official 32 bit host.

it's working on our sparc dev box and my sparc chroots

> It always kicks this back almost instantly. Doesn't matter if it's local
> or remote

are you trying with plain rsync ? or rsync over a diff protocol ? try:
rsync rsync://uclibc.org/svn/
it should provide a file listing

> Oddly enough scp has issues too which may point to something being wrong
> with ssh. This is what happens.
>
> On remote machine run..
>
>
> scp blah root@<ip-address>:~/
> root@<ip-address>'s password:
> Permission denied, please try again.
> root@<ip-address>'s password:
> Permission denied, please try again.
> root@<ip-address>'s password:
> Permission denied ().
> lost connection
>
> However if i try a second / third time...
>
> scp blah root@<ip-address>:~/
> Password:
> blah 100%
> 102MB 11.4MB/s 13.0MB/s 00:09
>
>
> Notice how in the first attempt sshd is returning the boxes IP and wont
> take my password. A few attempts later and it will not return the IP,
> but will take my password. It's completely intermittent.

yes, it sounds like openssh or openssl is broken instead
-mike
Re: Official SPARC64 Port [ In reply to ]
On 02/08/2016 10:21 AM, Mike Frysinger wrote:
> On 07 Feb 2016 05:35, Alex McWhirter wrote:
>> Have there been any reports of rsync being broken on sparc? I can't get
>> it to work on my 64bit host or my official 32 bit host.
> it's working on our sparc dev box and my sparc chroots
>
>> It always kicks this back almost instantly. Doesn't matter if it's local
>> or remote
> are you trying with plain rsync ? or rsync over a diff protocol ? try:
> rsync rsync://uclibc.org/svn/
> it should provide a file listing
>
>> Oddly enough scp has issues too which may point to something being wrong
>> with ssh. This is what happens.
>>
>> On remote machine run..
>>
>>
>> scp blah root@<ip-address>:~/
>> root@<ip-address>'s password:
>> Permission denied, please try again.
>> root@<ip-address>'s password:
>> Permission denied, please try again.
>> root@<ip-address>'s password:
>> Permission denied ().
>> lost connection
>>
>> However if i try a second / third time...
>>
>> scp blah root@<ip-address>:~/
>> Password:
>> blah 100%
>> 102MB 11.4MB/s 13.0MB/s 00:09
>>
>>
>> Notice how in the first attempt sshd is returning the boxes IP and wont
>> take my password. A few attempts later and it will not return the IP,
>> but will take my password. It's completely intermittent.
> yes, it sounds like openssh or openssl is broken instead
> -mike

If i force --protocol=29 it works just fine. Can you think of any kernel
options that might cause this? I'm running a fairly minimal kernel.
Re: Official SPARC64 Port [ In reply to ]
On 02/08/2016 03:48 PM, Alex McWhirter wrote:
> On 02/08/2016 10:21 AM, Mike Frysinger wrote:
>> On 07 Feb 2016 05:35, Alex McWhirter wrote:
>>> Have there been any reports of rsync being broken on sparc? I can't get
>>> it to work on my 64bit host or my official 32 bit host.
>> it's working on our sparc dev box and my sparc chroots
>>
>>> It always kicks this back almost instantly. Doesn't matter if it's local
>>> or remote
>> are you trying with plain rsync ? or rsync over a diff protocol ? try:
>> rsync rsync://uclibc.org/svn/
>> it should provide a file listing
>>
>>> Oddly enough scp has issues too which may point to something being wrong
>>> with ssh. This is what happens.
>>>
>>> On remote machine run..
>>>
>>>
>>> scp blah root@<ip-address>:~/
>>> root@<ip-address>'s password:
>>> Permission denied, please try again.
>>> root@<ip-address>'s password:
>>> Permission denied, please try again.
>>> root@<ip-address>'s password:
>>> Permission denied ().
>>> lost connection
>>>
>>> However if i try a second / third time...
>>>
>>> scp blah root@<ip-address>:~/
>>> Password:
>>> blah 100%
>>> 102MB 11.4MB/s 13.0MB/s 00:09
>>>
>>>
>>> Notice how in the first attempt sshd is returning the boxes IP and wont
>>> take my password. A few attempts later and it will not return the IP,
>>> but will take my password. It's completely intermittent.
>> yes, it sounds like openssh or openssl is broken instead
>> -mike
> If i force --protocol=29 it works just fine. Can you think of any kernel
> options that might cause this? I'm running a fairly minimal kernel.
>

I am completely stumped here. It's just simply broken. Fresh 64bit install

localhost ~ # rsync -a /usr/portage/ /root/portage
rsync: [sender] write error: Broken pipe (32)
rsync error: error in socket IO (code 10) at io.c(820) [sender=3.1.2]

It's almost like the rsync socket is broken or something...
Re: Official SPARC64 Port [ In reply to ]
On 09 Feb 2016 00:11, Alex McWhirter wrote:
> On 02/08/2016 03:48 PM, Alex McWhirter wrote:
> > On 02/08/2016 10:21 AM, Mike Frysinger wrote:
> >> On 07 Feb 2016 05:35, Alex McWhirter wrote:
> >>> Have there been any reports of rsync being broken on sparc? I can't get
> >>> it to work on my 64bit host or my official 32 bit host.
> >> it's working on our sparc dev box and my sparc chroots
> >>
> >>> It always kicks this back almost instantly. Doesn't matter if it's local
> >>> or remote
> >> are you trying with plain rsync ? or rsync over a diff protocol ? try:
> >> rsync rsync://uclibc.org/svn/
> >> it should provide a file listing
> >>
> >>> Oddly enough scp has issues too which may point to something being wrong
> >>> with ssh. This is what happens.
> >>>
> >>> On remote machine run..
> >>>
> >>>
> >>> scp blah root@<ip-address>:~/
> >>> root@<ip-address>'s password:
> >>> Permission denied, please try again.
> >>> root@<ip-address>'s password:
> >>> Permission denied, please try again.
> >>> root@<ip-address>'s password:
> >>> Permission denied ().
> >>> lost connection
> >>>
> >>> However if i try a second / third time...
> >>>
> >>> scp blah root@<ip-address>:~/
> >>> Password:
> >>> blah 100%
> >>> 102MB 11.4MB/s 13.0MB/s 00:09
> >>>
> >>>
> >>> Notice how in the first attempt sshd is returning the boxes IP and wont
> >>> take my password. A few attempts later and it will not return the IP,
> >>> but will take my password. It's completely intermittent.
> >> yes, it sounds like openssh or openssl is broken instead
> >> -mike
> > If i force --protocol=29 it works just fine. Can you think of any kernel
> > options that might cause this? I'm running a fairly minimal kernel.
> >
>
> I am completely stumped here. It's just simply broken. Fresh 64bit install
>
> localhost ~ # rsync -a /usr/portage/ /root/portage
> rsync: [sender] write error: Broken pipe (32)
> rsync error: error in socket IO (code 10) at io.c(820) [sender=3.1.2]
>
> It's almost like the rsync socket is broken or something...

EPIPE here looks like the server/receiver died. might want to try adding
-vvvvv to rsync, or running it through `strace -o log -f` and see if you
find anything interesting.
-mike
Re: Official SPARC64 Port [ In reply to ]
On 02/09/2016 01:14 AM, Mike Frysinger wrote:
> On 09 Feb 2016 00:11, Alex McWhirter wrote:
>> On 02/08/2016 03:48 PM, Alex McWhirter wrote:
>>> On 02/08/2016 10:21 AM, Mike Frysinger wrote:
>>>> On 07 Feb 2016 05:35, Alex McWhirter wrote:
>>>>> Have there been any reports of rsync being broken on sparc? I can't get
>>>>> it to work on my 64bit host or my official 32 bit host.
>>>> it's working on our sparc dev box and my sparc chroots
>>>>
>>>>> It always kicks this back almost instantly. Doesn't matter if it's local
>>>>> or remote
>>>> are you trying with plain rsync ? or rsync over a diff protocol ? try:
>>>> rsync rsync://uclibc.org/svn/
>>>> it should provide a file listing
>>>>
>>>>> Oddly enough scp has issues too which may point to something being wrong
>>>>> with ssh. This is what happens.
>>>>>
>>>>> On remote machine run..
>>>>>
>>>>>
>>>>> scp blah root@<ip-address>:~/
>>>>> root@<ip-address>'s password:
>>>>> Permission denied, please try again.
>>>>> root@<ip-address>'s password:
>>>>> Permission denied, please try again.
>>>>> root@<ip-address>'s password:
>>>>> Permission denied ().
>>>>> lost connection
>>>>>
>>>>> However if i try a second / third time...
>>>>>
>>>>> scp blah root@<ip-address>:~/
>>>>> Password:
>>>>> blah 100%
>>>>> 102MB 11.4MB/s 13.0MB/s 00:09
>>>>>
>>>>>
>>>>> Notice how in the first attempt sshd is returning the boxes IP and wont
>>>>> take my password. A few attempts later and it will not return the IP,
>>>>> but will take my password. It's completely intermittent.
>>>> yes, it sounds like openssh or openssl is broken instead
>>>> -mike
>>> If i force --protocol=29 it works just fine. Can you think of any kernel
>>> options that might cause this? I'm running a fairly minimal kernel.
>>>
>> I am completely stumped here. It's just simply broken. Fresh 64bit install
>>
>> localhost ~ # rsync -a /usr/portage/ /root/portage
>> rsync: [sender] write error: Broken pipe (32)
>> rsync error: error in socket IO (code 10) at io.c(820) [sender=3.1.2]
>>
>> It's almost like the rsync socket is broken or something...
> EPIPE here looks like the server/receiver died. might want to try adding
> -vvvvv to rsync, or running it through `strace -o log -f` and see if you
> find anything interesting.
> -mike
Well, time for more fun

Copying over the 3.4.14 kernel from the install cd will make rsync work.

Kernel 4.1.12 rsync is dead
Kernel 4.1.15 rsync is dead

Since all sparc profiles use a 64bit kernel i would be heavily
interested in what kernel / options you are running.



Using the kernel config from the CD on a newer kernel still results in a
broken rsync. So the kernel is either broken somehow or there's an
option somewhere that genkernel, the cd config, and myself are missing.


Strace wasn't all that helpful unfortunately.
Re: Official SPARC64 Port [ In reply to ]
On 13 Feb 2016 04:26, Alex McWhirter wrote:
> Well, time for more fun
>
> Copying over the 3.4.14 kernel from the install cd will make rsync work.
>
> Kernel 4.1.12 rsync is dead
> Kernel 4.1.15 rsync is dead
>
> Since all sparc profiles use a 64bit kernel i would be heavily
> interested in what kernel / options you are running.

Linux bender 3.17.2 #2 SMP Tue Nov 11 18:56:20 UTC 2014 sparc64 sun4v UltraSparc T1 (Niagara) GNU/Linux

[ 0.000000] Linux version 3.17.2 (root@bender) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.5, pie-0.5.5) ) #2 SMP Tue Nov 11 18:56:20 UTC 2014

config is attached

> Using the kernel config from the CD on a newer kernel still results in a
> broken rsync. So the kernel is either broken somehow or there's an
> option somewhere that genkernel, the cd config, and myself are missing.

or the toolchain is unhappy
-mike
Re: Official SPARC64 Port [ In reply to ]
On 02/13/2016 06:25 AM, Mike Frysinger wrote:
> On 13 Feb 2016 04:26, Alex McWhirter wrote:
>> Well, time for more fun
>>
>> Copying over the 3.4.14 kernel from the install cd will make rsync work.
>>
>> Kernel 4.1.12 rsync is dead
>> Kernel 4.1.15 rsync is dead
>>
>> Since all sparc profiles use a 64bit kernel i would be heavily
>> interested in what kernel / options you are running.
> Linux bender 3.17.2 #2 SMP Tue Nov 11 18:56:20 UTC 2014 sparc64 sun4v UltraSparc T1 (Niagara) GNU/Linux
>
> [ 0.000000] Linux version 3.17.2 (root@bender) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.5, pie-0.5.5) ) #2 SMP Tue Nov 11 18:56:20 UTC 2014
>
> config is attached
>
>> Using the kernel config from the CD on a newer kernel still results in a
>> broken rsync. So the kernel is either broken somehow or there's an
>> option somewhere that genkernel, the cd config, and myself are missing.
> or the toolchain is unhappy
> -mike

It's fairly likely that you will break rsync as well if you upgrade to a
4.X kernel as i have experienced this with an official install on
another box. I'm working on building a 3.14 kernel with a newer
toolchain to see what happens. 4.4.1 still has this issue, i may try
vanilla sources as well after 3.14.

I suppose its also likely that this could be a bug in rsync as well that
may have been relying on a bug in older kernels which was later fixed.
But this is all speculation at this point.

1 2  View All