Looking at arch/s390/kernel/traps.c, do_trap(), I bet interruption code 0x4 corresponds to EINTR 'interrupted system call'. An strace of the sshd process while you attempt to connect may help identify which syscall is failing, if any. I used:
# ps aux | grep sshd root 1267 0.0 0.9 5224 2344 ? Ss Sep16 0:00 /usr/sbin/sshd # strace -p 1267 -o /tmp/strace.out Process 1267 attached - interrupt to quit ((connect with client)) ^c Process 1267 detached I wonder if anything is returning -1.. Also, does it make a difference if you run 'ldconfig' on the target system? I tend to blame glibc for syscall errors, but maybe it's not related. On Sat, 2006-09-23 at 17:46 -0400, Post, Mark K wrote: > Nope, no differences in sshd_config, since that is delivered as part of > the package, and Pat doesn't do PAM, so no PAM configuration files at > all. > > > Thanks for the suggestions to check, > > Mark Post > > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > Marcy Cortes > Sent: Saturday, September 23, 2006 5:35 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: OpenSSH Oddity > > Is you sshd_config the same? How about the /etc/pam.d stuff? > > > Marcy Cortes > > > "This message may contain confidential and/or privileged information. > If you are not the addressee or authorized to receive this for the > addressee, you must not use, copy, disclose, or take any action based on > this message or any information herein. If you have received this > message in error, please advise the sender immediately by reply e-mail > and delete this message. Thank you for your cooperation." > > > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > Post, Mark K > Sent: Saturday, September 23, 2006 2:21 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: [LINUX-390] OpenSSH Oddity > > One other item of interest. If I try to connect using keys, and not a > password, things work just fine. But, as I said, when I am not using > keys, I don't even get prompted for a password, so it's something in the > processing that's going wrong before it gets to asking for a password. > > > Mark Post > > -----Original Message----- > From: Post, Mark K > Sent: Saturday, September 23, 2006 5:10 PM > To: 'Linux on 390 Port' > Subject: RE: OpenSSH Oddity > > From my note: > > I've checked the md5 checksums for all the files in the openssh and > > openssl packages, as well as all the shared libraries the sshd binary > > uses. > > So, not that I can tell. > > > Mark Post > > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > Rick Troth > Sent: Saturday, September 23, 2006 3:38 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: OpenSSH Oddity > > Target system has different run-time libs? > > -- R; > > On Sat, 23 Sep 2006, Post, Mark K wrote: > > > I'm having a very strange problem show up with OpenSSH 4.3p1. On the > > development system where I built it, it works fine. When I ship the > > binary package to another Linux guest on the same z/VM system, it > > doesn't work. When I try to ssh into the system, the client gets a > > "Connection closed by 192.168.0.20" message, without even being > prompted > > for a password. The sshd daemon on the other system throws off this > > error in the kernel ring buffer (but keeps on running): > > User process fault: interruption code 0x4 failing address: 40016000 > > CPU: 0 Not tainted > > Process sshd (pid: 13181, task: 0152c000, ksp: 0152dd00) User PSW : > > 070dc000 c0006318 User GPRS: ffffffff 40017738 00010dd0 00000000 > > 00000000 ffffffff 7fffcfa8 40016f3c > > 00000000 00000000 40016f3c 7fffcf68 > > 40017000 c0006164 c00064b2 7fffcf48 User ACRS: 40010870 > > 00000000 00000000 00000000 > > 00000000 00000000 00000000 00000000 > > 00000000 00000000 00000000 00000000 > > 00000000 00000000 00000000 00000000 User Code: 50 00 70 00 > > a7 f4 ff ed 58 80 b0 d4 58 90 d0 40 58 20 80 00 > > > > > > I've checked the md5 checksums for all the files in the openssh and > > openssl packages, as well as all the shared libraries the sshd binary > > uses. They all match on both systems. Even if I build the binary on > > the target system, I get the same results. I'm at a loss to explain > why > > it works fine on one system, but not others. Anyone have any ideas > > where to look further? > > > > > > Thanks, > > > > Mark Post > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
