Mailing List Archive

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

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.

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

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?

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

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.

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

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

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.

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

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

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

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.

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?

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

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

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.

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

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.

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

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

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.

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

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.

On 02/13/2016 12:32 PM, Alex McWhirter wrote:
> 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.
>

3.14.58 works fine when built with the latest toolchain. I had to use
the CD config, as genkernel doesn't have correct sparc settings and i
didn't feel like manually configuring it just to see if rsync worked
afterwards. The fun part will be finding which exact kernel introduced
the breakage, or perhaps it could be an rsync bug as the rest of the
system works fine on newer kernels. Even if it is an issue with rsync,
finding the kernel the breaks this functionality might help narrow down
the issue.

It looks like were dying on a select syscall. My only thought is that
maybe rsync is opening what it thinks is the correct file descriptor,
but it's actually getting a different file descriptor. It could be
requesting the wrong file descriptor entirely. Again, more speculation
at this point. My experience with strace / gdb is somewhat limited as i
come from a Solaris / BSD background.

Attached is the strace log from doing "rsync -a /usr/portage/*
/root/portage"

On 13 Feb 2016 16:26, Alex McWhirter wrote:
> On 02/13/2016 12:32 PM, Alex McWhirter wrote:
> > 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
> >
> > 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.
>
> 3.14.58 works fine when built with the latest toolchain. I had to use
> the CD config, as genkernel doesn't have correct sparc settings and i
> didn't feel like manually configuring it just to see if rsync worked
> afterwards. The fun part will be finding which exact kernel introduced
> the breakage, or perhaps it could be an rsync bug as the rest of the
> system works fine on newer kernels. Even if it is an issue with rsync,
> finding the kernel the breaks this functionality might help narrow down
> the issue.

agreed -- if we can narrow down the kernel range, that should help with
triaging
-mike

Using vanilla kernels, 3.18.26 is the last kernel that seems to work.
4.1.17 introduces the issue. Is this something worth bringing up on the
sparc kernel mailing list? I'm currently scouring through a 4.1.17 /
3.18.26 diff which is so large it's hard to get anywhere.

On 14 Feb 2016 18:44, Alex McWhirter wrote:
> Using vanilla kernels, 3.18.26 is the last kernel that seems to work.
> 4.1.17 introduces the issue. Is this something worth bringing up on the
> sparc kernel mailing list? I'm currently scouring through a 4.1.17 /
> 3.18.26 diff which is so large it's hard to get anywhere.

erm, there are kernel versions inbetween those. can you not try 3.19,
4.0, or 4.1 from kernel.org ?
-mike

On 02/14/2016 09:13 PM, Mike Frysinger wrote:
> On 14 Feb 2016 18:44, Alex McWhirter wrote:
>> Using vanilla kernels, 3.18.26 is the last kernel that seems to work.
>> 4.1.17 introduces the issue. Is this something worth bringing up on the
>> sparc kernel mailing list? I'm currently scouring through a 4.1.17 /
>> 3.18.26 diff which is so large it's hard to get anywhere.
> erm, there are kernel versions inbetween those. can you not try 3.19,
> 4.0, or 4.1 from kernel.org ?
> -mike
Well after a few days of building kernels (each one takes about 5 hours
on this box :/)...

3.18.26 - Works
3.19.0 - Dead

So it looks like 3.19.0 added the issue.

On 17 Feb 2016 17:11, Alex McWhirter wrote:
> On 02/14/2016 09:13 PM, Mike Frysinger wrote:
> > On 14 Feb 2016 18:44, Alex McWhirter wrote:
> >> Using vanilla kernels, 3.18.26 is the last kernel that seems to work.
> >> 4.1.17 introduces the issue. Is this something worth bringing up on the
> >> sparc kernel mailing list? I'm currently scouring through a 4.1.17 /
> >> 3.18.26 diff which is so large it's hard to get anywhere.
> > erm, there are kernel versions inbetween those. can you not try 3.19,
> > 4.0, or 4.1 from kernel.org ?
>
> Well after a few days of building kernels (each one takes about 5 hours
> on this box :/)...
>
> 3.18.26 - Works
> 3.19.0 - Dead
>
> So it looks like 3.19.0 added the issue.

feel like bisecting it further ? you can clone:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/

and then run:
$ git bisect start v3.19 v3.18

and then try building/booting each combo it comes up with. if it fails,
run `git bisect bad`. if it passes, run `git bisect good`. if it does
not compile (sometimes that happens), you can use `git bisect skip`.
-mike

On 02/17/2016 05:46 PM, Mike Frysinger wrote:
> On 17 Feb 2016 17:11, Alex McWhirter wrote:
>> On 02/14/2016 09:13 PM, Mike Frysinger wrote:
>>> On 14 Feb 2016 18:44, Alex McWhirter wrote:
>>>> Using vanilla kernels, 3.18.26 is the last kernel that seems to work.
>>>> 4.1.17 introduces the issue. Is this something worth bringing up on the
>>>> sparc kernel mailing list? I'm currently scouring through a 4.1.17 /
>>>> 3.18.26 diff which is so large it's hard to get anywhere.
>>> erm, there are kernel versions inbetween those. can you not try 3.19,
>>> 4.0, or 4.1 from kernel.org ?
>> Well after a few days of building kernels (each one takes about 5 hours
>> on this box :/)...
>>
>> 3.18.26 - Works
>> 3.19.0 - Dead
>>
>> So it looks like 3.19.0 added the issue.
> feel like bisecting it further ? you can clone:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
>
> and then run:
> $ git bisect start v3.19 v3.18
>
> and then try building/booting each combo it comes up with. if it fails,
> run `git bisect bad`. if it passes, run `git bisect good`. if it does
> not compile (sometimes that happens), you can use `git bisect skip`.
> -mike

Well one way or another someone has to do it right?

Time to get back to the lonely world of constantly compiling kernels...

Git bisect if officially the coolest thing i've seen in a long time. I
wish i would have known about it earlier...

Anyways...

e5a4b0bb803b39a36478451eae53a880d2663d5b is the first bad commit
commit e5a4b0bb803b39a36478451eae53a880d2663d5b
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Mon Nov 24 18:17:55 2014 -0500

switch memcpy_to_msg() and skb_copy{,_and_csum}_datagram_msg() to
primitives

... making both non-draining. That means that tcp_recvmsg() becomes
non-draining. And _that_ would break iscsit_do_rx_data() unless we
a) make sure tcp_recvmsg() is uniformly non-draining (it is)
b) make sure it copes with arbitrary (including shifted)
iov_iter (it does, all it uses is iov_iter primitives)
c) make iscsit_do_rx_data() initialize ->msg_iter only once.

Fortunately, (c) is doable with minimal work and we are rid of one
the two places where kernel send/recvmsg users would be unhappy with
non-draining behaviour.

Actually, that makes all but one of ->recvmsg() instances
iov_iter-clean.
The exception is skcipher_recvmsg() and it also isn't hard to convert
to primitives (iov_iter_get_pages() is needed there). That'll wait
a bit - there's some interplay with ->sendmsg() path for that one.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

:040000 040000 b4d6852e73bd3d54a30b72441c8e35f79dc07266
f0b90ef68ee891b38decf571247002c1d7fad519 M drivers
:040000 040000 8ba2fadf14c05a86a7c21448dac52fed661a2e12
0051ec4b6f273dbaed2bed21e4fddd48664d5afa M include
:040000 040000 d28e72369891521f7d853b30612a32cf65a27f6b
b828e68082a6fed2cf240aad4b365c5808928122 M net

On 02/19/2016 03:37 AM, Alex McWhirter wrote:
> Git bisect if officially the coolest thing i've seen in a long time. I
> wish i would have known about it earlier...
>
> Anyways...
>
> e5a4b0bb803b39a36478451eae53a880d2663d5b is the first bad commit
> commit e5a4b0bb803b39a36478451eae53a880d2663d5b
> Author: Al Viro <viro@zeniv.linux.org.uk>
> Date: Mon Nov 24 18:17:55 2014 -0500
>
> switch memcpy_to_msg() and skb_copy{,_and_csum}_datagram_msg() to
> primitives
>
> ... making both non-draining. That means that tcp_recvmsg() becomes
> non-draining. And _that_ would break iscsit_do_rx_data() unless we
> a) make sure tcp_recvmsg() is uniformly non-draining (it is)
> b) make sure it copes with arbitrary (including shifted)
> iov_iter (it does, all it uses is iov_iter primitives)
> c) make iscsit_do_rx_data() initialize ->msg_iter only once.
>
> Fortunately, (c) is doable with minimal work and we are rid of one
> the two places where kernel send/recvmsg users would be unhappy with
> non-draining behaviour.
>
> Actually, that makes all but one of ->recvmsg() instances
> iov_iter-clean.
> The exception is skcipher_recvmsg() and it also isn't hard to convert
> to primitives (iov_iter_get_pages() is needed there). That'll wait
> a bit - there's some interplay with ->sendmsg() path for that one.
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>
> :040000 040000 b4d6852e73bd3d54a30b72441c8e35f79dc07266
> f0b90ef68ee891b38decf571247002c1d7fad519 M drivers
> :040000 040000 8ba2fadf14c05a86a7c21448dac52fed661a2e12
> 0051ec4b6f273dbaed2bed21e4fddd48664d5afa M include
> :040000 040000 d28e72369891521f7d853b30612a32cf65a27f6b
> b828e68082a6fed2cf240aad4b365c5808928122 M net
>
>

Here's a snippet from the kernel list...

> Ok, so bit more info. This only seems to effect local disk transfers,
not server -> client transfers. I can verify this behaviour on Debian
and Gentoo, as well as on a Sun Fire V215 and Sun Blade 150.
>
> Steps to reproduce.
>
> rysnc -a rsync://rsync.ca.gentoo.org/gentoo-portage/ ~/portage
> rsync -a ~/portage ~/portage2
>
> You should see something around these lines occur...
>
> rsync: [sender] write error: Broken pipe (32)
> rsync error: error in socket IO (code 10) at io.c(820) [sender=3.1.1]
>
>
> If you don't want to download the whole portage tree, you can probably
get away with a large subdirectory like x11-libs.
>
> I.E.
>
> rysnc -a rsync://rsync.ca.gentoo.org/gentoo-portage/x11-libs ~/x11-libs
> rsync -a ~/x11-libs ~/x11-libs2
>
> As stated earlier, using git bisect to eventually roll back commit
e5a4b0bb803b39a36478451eae53a880d2663d5b will resolve the problem.

Mike, any ideas of what else i could do to try and pick this apart a bit
more?

Alex,

On 03/10/16 19:53, Alex McWhirter wrote:
> On 02/19/2016 03:37 AM, Alex McWhirter wrote:
>> Git bisect if officially the coolest thing i've seen in a long time. I
>> wish i would have known about it earlier...
>>
>> Anyways...
>>
>> e5a4b0bb803b39a36478451eae53a880d2663d5b is the first bad commit
>> commit e5a4b0bb803b39a36478451eae53a880d2663d5b
>> Author: Al Viro <viro@zeniv.linux.org.uk>
>> Date: Mon Nov 24 18:17:55 2014 -0500
>>
>> switch memcpy_to_msg() and skb_copy{,_and_csum}_datagram_msg() to
>> primitives
>>
>> ... making both non-draining. That means that tcp_recvmsg() becomes
>> non-draining. And _that_ would break iscsit_do_rx_data() unless we
>> a) make sure tcp_recvmsg() is uniformly non-draining (it is)
>> b) make sure it copes with arbitrary (including shifted)
>> iov_iter (it does, all it uses is iov_iter primitives)
>> c) make iscsit_do_rx_data() initialize ->msg_iter only once.
>>
>> Fortunately, (c) is doable with minimal work and we are rid of one
>> the two places where kernel send/recvmsg users would be unhappy with
>> non-draining behaviour.
>>
>> Actually, that makes all but one of ->recvmsg() instances
>> iov_iter-clean.
>> The exception is skcipher_recvmsg() and it also isn't hard to convert
>> to primitives (iov_iter_get_pages() is needed there). That'll wait
>> a bit - there's some interplay with ->sendmsg() path for that one.
>>
>> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
>>
>> :040000 040000 b4d6852e73bd3d54a30b72441c8e35f79dc07266
>> f0b90ef68ee891b38decf571247002c1d7fad519 M drivers
>> :040000 040000 8ba2fadf14c05a86a7c21448dac52fed661a2e12
>> 0051ec4b6f273dbaed2bed21e4fddd48664d5afa M include
>> :040000 040000 d28e72369891521f7d853b30612a32cf65a27f6b
>> b828e68082a6fed2cf240aad4b365c5808928122 M net
>>
>>
> Here's a snippet from the kernel list...
>
>> Ok, so bit more info. This only seems to effect local disk transfers,
> not server -> client transfers. I can verify this behaviour on Debian
> and Gentoo, as well as on a Sun Fire V215 and Sun Blade 150.
>> Steps to reproduce.
>>
>> rysnc -a rsync://rsync.ca.gentoo.org/gentoo-portage/ ~/portage
>> rsync -a ~/portage ~/portage2
>>
>> You should see something around these lines occur...
>>
>> rsync: [sender] write error: Broken pipe (32)
>> rsync error: error in socket IO (code 10) at io.c(820) [sender=3.1.1]
>>
>>
>> If you don't want to download the whole portage tree, you can probably
> get away with a large subdirectory like x11-libs.
>> I.E.
>>
>> rysnc -a rsync://rsync.ca.gentoo.org/gentoo-portage/x11-libs ~/x11-libs
>> rsync -a ~/x11-libs ~/x11-libs2
>>
>> As stated earlier, using git bisect to eventually roll back commit
> e5a4b0bb803b39a36478451eae53a880d2663d5b will resolve the problem.
>
> Mike, any ideas of what else i could do to try and pick this apart a bit
> more?
>
Any update on this issue? rsync is still broken on sparc.

--
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan <jmorgan@gentoo.org>
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

On 2016-08-08 18:52, Jack Morgan wrote:
> Any update on this issue? rsync is still broken on sparc.

Yes it, as well as ssh, ssl, and ext4 bugs were fixed via this patch. It
was taged for stable.



-------- Original Message --------
Subject: [PATCH] sparc: Don't leak context bits into
thread->fault_address
Date: 2016-07-27 20:53
From: David Miller <davem@davemloft.net>
To: sparclinux@vger.kernel.org
Cc: mpatocka@redhat.com

On pre-Niagara systems, we fetch the fault address on data TLB
exceptions from the TLB_TAG_ACCESS register. But this register also
contains the context ID assosciated with the fault in the low 13 bits
of the register value.

This propagates into current_thread_info()->fault_address and can
cause trouble later on.

So clear the low 13-bits out of the TLB_TAG_ACCESS value in the cases
where it matters.

Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/sparc/kernel/dtlb_prot.S | 4 ++--
arch/sparc/kernel/ktlb.S | 12 ++++++++++++
arch/sparc/kernel/tsb.S | 12 ++++++++++--
3 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/dtlb_prot.S
b/arch/sparc/kernel/dtlb_prot.S
index d668ca14..4087a62 100644
--- a/arch/sparc/kernel/dtlb_prot.S
+++ b/arch/sparc/kernel/dtlb_prot.S
@@ -25,13 +25,13 @@

/* PROT ** ICACHE line 2: More real fault processing */
ldxa [%g4] ASI_DMMU, %g5 ! Put tagaccess in %g5
+ srlx %g5, PAGE_SHIFT, %g5
+ sllx %g5, PAGE_SHIFT, %g5 ! Clear context ID bits
bgu,pn %xcc, winfix_trampoline ! Yes, perform winfixup
mov FAULT_CODE_DTLB | FAULT_CODE_WRITE, %g4
ba,pt %xcc, sparc64_realfault_common ! Nope, normal fault
nop
nop
- nop
- nop

/* PROT ** ICACHE line 3: Unused... */
nop
diff --git a/arch/sparc/kernel/ktlb.S b/arch/sparc/kernel/ktlb.S
index ef0d8e9..f22bec0 100644
--- a/arch/sparc/kernel/ktlb.S
+++ b/arch/sparc/kernel/ktlb.S
@@ -20,6 +20,10 @@ kvmap_itlb:
mov TLB_TAG_ACCESS, %g4
ldxa [%g4] ASI_IMMU, %g4

+ /* The kernel executes in context zero, therefore we do not
+ * need to clear the context ID bits out of %g4 here.
+ */
+
/* sun4v_itlb_miss branches here with the missing virtual
* address already loaded into %g4
*/
@@ -128,6 +132,10 @@ kvmap_dtlb:
mov TLB_TAG_ACCESS, %g4
ldxa [%g4] ASI_DMMU, %g4

+ /* The kernel executes in context zero, therefore we do not
+ * need to clear the context ID bits out of %g4 here.
+ */
+
/* sun4v_dtlb_miss branches here with the missing virtual
* address already loaded into %g4
*/
@@ -251,6 +259,10 @@ kvmap_dtlb_longpath:
nop
.previous

+ /* The kernel executes in context zero, therefore we do not
+ * need to clear the context ID bits out of %g5 here.
+ */
+
be,pt %xcc, sparc64_realfault_common
mov FAULT_CODE_DTLB, %g4
ba,pt %xcc, winfix_trampoline
diff --git a/arch/sparc/kernel/tsb.S b/arch/sparc/kernel/tsb.S
index be98685..d568c82 100644
--- a/arch/sparc/kernel/tsb.S
+++ b/arch/sparc/kernel/tsb.S
@@ -29,13 +29,17 @@
*/
tsb_miss_dtlb:
mov TLB_TAG_ACCESS, %g4
+ ldxa [%g4] ASI_DMMU, %g4
+ srlx %g4, PAGE_SHIFT, %g4
ba,pt %xcc, tsb_miss_page_table_walk
- ldxa [%g4] ASI_DMMU, %g4
+ sllx %g4, PAGE_SHIFT, %g4

tsb_miss_itlb:
mov TLB_TAG_ACCESS, %g4
+ ldxa [%g4] ASI_IMMU, %g4
+ srlx %g4, PAGE_SHIFT, %g4
ba,pt %xcc, tsb_miss_page_table_walk
- ldxa [%g4] ASI_IMMU, %g4
+ sllx %g4, PAGE_SHIFT, %g4

/* At this point we have:
* %g1 -- PAGE_SIZE TSB entry address
@@ -284,6 +288,10 @@ tsb_do_dtlb_fault:
nop
.previous

+ /* Clear context ID bits. */
+ srlx %g5, PAGE_SHIFT, %g5
+ sllx %g5, PAGE_SHIFT, %g5
+
be,pt %xcc, sparc64_realfault_common
mov FAULT_CODE_DTLB, %g4
ba,pt %xcc, winfix_trampoline

Alex,

On 08/08/16 22:14, alexmcwhirter@triadic.us wrote:
> On 2016-08-08 18:52, Jack Morgan wrote:
>> Any update on this issue? rsync is still broken on sparc.
>
> Yes it, as well as ssh, ssl, and ext4 bugs were fixed via this patch. It
> was taged for stable.

We are tracking this issue with BZ-590790. We have one person confirm
this is fixed in the 4.7.0 kernel (vanilla-sources).


thanks,

--
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan <jmorgan@gentoo.org>
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A

On 2016-08-10 14:45, Jack Morgan wrote:
> Alex,
>
> On 08/08/16 22:14, alexmcwhirter@triadic.us wrote:
>> On 2016-08-08 18:52, Jack Morgan wrote:
>>> Any update on this issue? rsync is still broken on sparc.
>>
>> Yes it, as well as ssh, ssl, and ext4 bugs were fixed via this patch.
>> It
>> was taged for stable.
>
> We are tracking this issue with BZ-590790. We have one person confirm
> this is fixed in the 4.7.0 kernel (vanilla-sources).
>
>
> thanks,

Just gave 4.7.2 a try, the issue is still present. Looks like the patch
is in 4.8-rc4 however. This only effect sun4u, not sun4v so any reports
of this being fixed should also include the machine it's fixed on.

Alex,

Thanks for update. Let us know if you find it works in a stable kernel
release. I've not tried it myself but hope to get to it this weekend.


On 08/31/16 10:26, alexmcwhirter@triadic.us wrote:
> On 2016-08-10 14:45, Jack Morgan wrote:
>> Alex,
>>
>> On 08/08/16 22:14, alexmcwhirter@triadic.us wrote:
>>> On 2016-08-08 18:52, Jack Morgan wrote:
>>>> Any update on this issue? rsync is still broken on sparc.
>>>
>>> Yes it, as well as ssh, ssl, and ext4 bugs were fixed via this patch. It
>>> was taged for stable.
>>
>> We are tracking this issue with BZ-590790. We have one person confirm
>> this is fixed in the 4.7.0 kernel (vanilla-sources).
>>
>>
>> thanks,
>
> Just gave 4.7.2 a try, the issue is still present. Looks like the patch
> is in 4.8-rc4 however. This only effect sun4u, not sun4v so any reports
> of this being fixed should also include the machine it's fixed on.
>

Thanks,
--
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan <jmorgan@gentoo.org>
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A