On 17/08/2021 00:18, Darren Tucker wrote:> On Tue, 17 Aug 2021 at 04:46, Tom G. Christensen <tgc at jupiterrise.com
> <mailto:tgc at jupiterrise.com>> wrote:
>
> If you are not already, make sure you are compiling OpenSSH and
> especially OpenSSL with SPARC v8 instructions (for gcc, that's -mv8).
> At least some versions of gcc default to v7 which has no hardware
> multiply which slows down some crypto, Diffie-Hellman in particular.
> Not sure about other compilers.
>
I am seeing this both on a 900Mhz US-III Solaris 9 system where I build
with v8 instructions (gcc explicitly defaults to it) and a 336Mhz US-II
Solaris 7 system where currently only openssl is built v8 and the rest
v7 (gcc explicitly defaults to it).
The Solaris 9 system will always hang in the rekey test at some point,
the Solaris 7 system often didn't even get that far before hanging.
After the revert both have completed the full testsuite.
Both systems also completed the testsuite in 8.6p1 with no hangs.
> Looking at sshd.log it seems it closed the connection but from what I
> can gather from ssh.log the client still thinks it is connected and is
> just waiting.
> Looking at ps output I see two sshd processes running, one a child of
> the other, and then a <defunct> child of the still running child.
> With truss I see that the client is still doing poll().
>
> I tried reverting 4bdf7a04797a0ea1c431a9d54588417c29177d19 and it seems
> to fix it. I've now run through the rekey test twice and the full
> testsuite once with no hangs where before it would always hang at some
> point.
>
>
> this one is a concern,?and while I have some SPARC hardware I can't
> currently access it to repro.? Does it have pselect()?? If so, try
> removing HAVE_PSELECT from config.h and recompiling (this will use the
> compat code instead, which should be equivalent to what was there
> previously.? If it doesn't have pselect then the problem likely relates
> to the compat code itself.
>
Solaris < 10 does not have pselect() it uses the compat code.
-tgc