Mailing List Archive

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