Thanks for several replies, a couple of which I've included here. It is safe to assume that the z/OS image (LPARed on the same machine) that is sharing the OSA devices is not experiencing the same issue. It's running fat and happy.
Greg B. also suggested changes to QIOASSIST, which is a term I'm not familiar with. I'm assuming that QIOASSIST is part of a z/VM configuration (from the context of Greg's note) but in my case I'm not running Linux under z/VM - it's carved out of an partition on the machine using LPAR mode. If I'm mistaken about the QIOASSIST and z/VM, please feel free to enlighten me. I haven't tried the network restart command yet, but I will the next time this occurs. Thanks again. Tim -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of ADAMS Steven Sent: Thursday, December 15, 2005 3:40 PM To: [email protected] Subject: Re: SLES 9, zSeries, and dropping OSA-G's You might try: /etc/init.d/network restart So it stops the connections before starting them. Is it safe to assume that z/OS doesn't experience the same issue? -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of MOEUR TIM C Sent: Thursday, December 15, 2005 2:31 PM To: [email protected] Subject: SLES 9, zSeries, and dropping OSA-G's Hello, I have an odd situation and I'm wondering if anybody else has encountered the same and if so, what they did to correct the situation. I'm running a test Suse Linux ES 9.0 on a zseries 890 in LPAR mode. The machine has on it two OSA Gigabit adapters which are shared with a production z/OS system running on another LPAR. When I start the Linux system both adapters come up, both seem to work with no errors as seen by PINGs, IFCONFIG statements, or by actually running traffic from clients to the Linux system. BUT - when I begin to load either of the two OSA's with traffic, for instance I've been testing TSM and running a bunch of backup data to Linux, it will stop. The OSA adapter, that is, not the application. I've refined this process down and I'll start a PING -T on a separate command window, and then start the 'high-traffic' application on some other client. At some random time, and occasionally never, the OSA device will stop answering pings and the client with time out. Once this happens all TCP/IP traffic through that device is halted, but the other device remains alive and working (unless I move a bunch of data through it and kill it too). I mentioned TSM before but this problem isn't limited to TSM - I can recreate it by x-windowing to a local desktop, presumably generating a decently large traffic flow from zLinux to the desktop machine, or any application which might move some data. I've done it with YaST while installing extra components. When this happens nothing seems out of place when looking around with normal Linux commands. IFCONFIG will show the device as UP and the normal IP address. I've tried normal commands to restart the device (ping, ifdown, ifup, ifconfig, /etc/init.d/network start ehtx, etc...) but non seem to have any effect. The device is hosed until I reboot the Linux system. Also, I've run OSA/SF from the z/OS system before and after and nothing looks odd or out of place. If I ping the dead address from the Linux box it'll answer, but from any client outside the box it stalls. Also, this seems to be limited to the 64 bit version of Suse. I've run 32 bit on the same machine and same OSA's for quite some time and never encountered this problem. I'm less concerned about the ability to restart the OSA's once they drop into this state, that would just make my testing a bit smoother, since I wouldn't need to reboot the image each time. More so, I'd like to identify the problem and keep the network OSAs up in the first place! So, as I said in the beginning, Is this a problem that anyone else has encountered? Have you some suggestions of other places I might look before/after to determine the root cause? How about some commands that will restart a dead OSA channel once it is down? Tim [EMAIL PROTECTED] ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
