Official SPARC64 Port

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Official SPARC64 Port

alexmcwhirter
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?




Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

Mike Frysinger
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

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

Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

Mike Frysinger
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

alexmcwhirter
In reply to this post by alexmcwhirter
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?

Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

Mike Frysinger
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

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

Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

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


Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

Mike Frysinger
In reply to this post by alexmcwhirter
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

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

Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

Mike Frysinger
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

alexmcwhirter
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

Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

Mike Frysinger
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

alexmcwhirter

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.

Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

alexmcwhirter
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?

Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

Mike Frysinger
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

alexmcwhirter
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

Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

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



Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

Mike Frysinger
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Official SPARC64 Port

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

12