Re: IUCV 2WAY missing from AF_IUCV in zLinux?
On 8/17/20 6:56 PM, Christian Svensson wrote: > [+linux-390 mailing list] > > On Mon, Aug 17, 2020 at 6:55 PM Christian Svensson wrote: >> >> Hi, >> >> I am trying to call TCPIP service using IUCV. >> I found AF_IUCV which seemed to do what I want, but reading >> more into it it looks like AF_IUCV only ever implemented one-way >> SEND operations. >> >> Is that correct? >> Yes, that's correct. The intention of the socket family AF_IUCV has been to come up with a socket interface of types SOCK_STREAM and SOCK_SEQPACKET on top of IUCV as transport layer. Later we added HiperSockets as another transport layer. >> There appears to exist a message_send and a message_send2way in >> the Linux IUCV interface, however only message_send appears to be used >> by AF_IUCV. >> There is a base IUCV layer in net/iucv/iucv.c offering message_send2way. The base layer is used by several other kernel components, among them net/iucv/af_iucv.c. But for the AF_IUCV socket family there has been no need to exploit message_send2way. >> If my reading is correct, is there any way I can work around this >> without writing a kernel module? >> Probably not: Either there is a good idea why to include message_send2way into the standard socket interface AF_IUCV, or there is a new kernel module for communication with the TCPIP service, built on top of net/iucv/iucv.c similar to other specific IUCV exploiters like drivers/s390/char/vmlogrdr.c, drivers/s390/net/netiucv.c, drivers/s390/net/smsgiucv.c, drivers/tty/hvc/... >> Thanks > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: DEDICATED OSA, LINUX VLAN tagging and bonding
There have been fixes for VLAN interfaces on top of bonding interfaces with active-backup mode and fail_over_mac=1. For RHEL6 for instance I remember there exists RH1159818/1115606- "Bonding mode active-backup and fail_over_mac active for Vlan interface Propagate MAC address is not working" Make sure you run an up-to-date kernel. Regards, Ursula Braun, IBM Germany On 03/07/2017 11:30 PM, Marcy Cortes wrote: > Hi, > > I have vlan tagged channel bonded interfaces on xDR proxies. Maybe it > will help just to show you. > In my case VLAN number is 71 and the IP address used here is 162.101.1.129. > You need to make up unique LLADDR's. Generally i think it's start them with > 02:00:00 to indicate user made up (Alan can correct me there if I > misremembered that :) > > rename off your vswitch configs so in case you need to get back its easy :) > > > xdr91:/etc/sysconfig/network # cat ifcfg-bond0 > BOOTPROTO='static' > STARTMODE='onboot' > BONDING_MASTER='yes' > BONDING_MODULE_OPTS='mode=active-backup fail_over_mac=active miimon=100' > BONDING_SLAVE0='eth0' > BONDING_SLAVE1='eth1' > > > xdr91:/etc/sysconfig/network # cat ifcfg-vlan71 > ETHERDEVICE='bond0' > IPADDR='162.101.1.129' > NETMASK='255.255.255.0' > NAME='VLAN access' > NETWORK='162.101.1.0' > BROADCAST='162.101.1.255' > STARTMODE='onboot' > VLAN='YES' > > > xdr91:/etc/sysconfig/network # cat ifcfg-eth0 > BOOTPROTO='static' > IPADDR='' > BROADCAST='' > STARTMODE='auto' > LLADDR='' > NAME='OSA Express Network card (0.0.3000)' > ETHTOOL_OPTIONS='' > MTU='' > NETWORK='' > REMOTE_IPADDR='' > USERCONTROL='no' > SLAVE='yes' > LLADDR='02:00:00:00:91:EF' > > > xdr91:/etc/sysconfig/network # cat ifcfg-eth1 > BOOTPROTO='static' > IPADDR='' > BROADCAST='' > STARTMODE='auto' > LLADDR='' > NAME='OSA Express Network card (0.0.4000)' > ETHTOOL_OPTIONS='' > MTU='' > NETWORK='' > REMOTE_IPADDR='' > USERCONTROL='no' > SLAVE='yes' > LLADDR='02:00:00:00:91:EE' > > xdr91:/etc/sysconfig/network # cat routes > default 162.101.1.1 - - > > > The bonding and 8021q modules seem to have loaded themselves - I couldn’t > find anything specific to them in /etc/modprobe.d > > Marcy > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Bill > Head > Sent: Tuesday, March 07, 2017 2:07 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: [LINUX-390] DEDICATED OSA, LINUX VLAN tagging and bonding > > And Alan is correct about VLAN tagging in LINUX (much easier to configure > VSWITCH's, www), not to mention trying to do it with bonding two > dedicated OSA's. I opened up a ticket with SuSE for some guidance on that. > I may have to trudge on with just a VSWITCH connection until I get that > figured out, at least I can get all the proxy guests built, get DNS changes > in, etc. GDPS is a different animal, miles to go before I sleep. > > > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan > Altmark > Sent: Tuesday, March 07, 2017 4:26 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: DEDICATED OSA, LINUX VLAN tagging and bonding > > The VSWITCH depends on the controller virtual machines. It and some related > CP control blocks may be swapped out. > > In a hyperswap, you can't do I/O to bring them back in. > > Bill is correct regarding the requirements for the GDPS proxy servers. > > Regards, > Alan > > > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain CONFIDENTIAL material. If you receive > this material/information in error, please contact the sender and delete or > destroy the material/information. > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Qeth at 10Mb?
On 02/19/2017 08:53 PM, Mauro Souza wrote: > Hi guys, > > We got an interesting situation today. One of our WAS guys called us to say > the SLES12 guest we just IPL'd has a 10Mb qeth interface. I thought he was > mistaken or joking, but there was a 10Mb device showing on ethtool, with > "twisted pair" link type and all... > > All our SLES11 on this lpar are fine (and on the same vswitch). All SLES12 > on another lpars are fine (both zVM 6.3 and 6.4). All SLES12 guests on this > specific lpar (running zvm 6.3) are running on 10Mb. The vswitch conf on > any lpar are exactly the same except the OSA channel. There exists z/VM APAR VM65785 / PTF UM34782 for z/VM 6.3 to improve port speed and lan type reported to guests. Can you please check, if this PTF is applied? Kind regards, Ursula -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Ethernet on VSwitch
> From:Mark Post <mp...@suse.com> > To:LINUX-390@VM.MARIST.EDU, > Date:08/03/2016 21:55 > Subject:Re: Ethernet on VSwitch > Sent by:Linux on 390 Port <LINUX-390@VM.MARIST.EDU> > >>> On 3/8/2016 at 02:09 PM, "Frank M. Ramaekers" > <framaek...@ailife.com> wrote: > > I'm wondering why it was assumed that these adapters should use the > > (almost) slowest speeds: > > There's a feature request from IBM for SLES12 SP2 that involves a qeth > driver update to more accurately report data to the ethtool command. > > > Mark Post > Here the information provided by the Linux qeth driver depends on information provided by z/VM. z/VM promised to come up with a code change. Ursula Braun -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: How to find a memory leak?
Tomas, the qeth driver has been improved in 2014 to reduce its demand for contiguous storage: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/s390/net/qeth_core.h?id=d445a4e28c0ff740e946ae22860be85428814c39 Regards, Ursula Braun, IBM Germany, Linux on System z Dev. On Mon, 2015-07-13 at 13:39 +, Pavelka, Tomas wrote: I wouldn't really put that at the feet of s390 (z/Architecture). Bad wording on my part. When I said s390 I meant the s390 part of the Linux kernel implementation, not the entire architecture. I meant to point out that the other parts of the kernel are working on getting out of the requirement of large contiguous buffers. AFAIK the vmcp driver uses the largest buffer and as you say, if the diag allowed to return discontiguous memory then it would solve the fragmentation problem. There are few other places that used larger buffers, NIC driver was one of them. So not sure if all over was the good wording either, maybe I should have said multiple places ;-) Tomas -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Fw: SUSE12 Gold image on VM
Martin, yes, I can take care about removing the portname from the qeth driver. Regards, Uschi Martin Schwidefsky/Germany/IBM wrote on 17/06/2015 09:24:59: From: Martin Schwidefsky/Germany/IBM To: Mark Post mp...@suse.com, Ursula Braun1/Germany/IBM@IBMDE, Cc: Linux on 390 Port LINUX-390@VM.MARIST.EDU Date: 17/06/2015 09:25 Subject: Re: SUSE12 Gold image on VM Mark Post mp...@suse.com wrote on 06/16/2015 04:53:29 PM: From: Mark Post mp...@suse.com To: Linux on 390 Port LINUX-390@VM.MARIST.EDU, Date: 06/16/2015 04:53 PM Subject: Re: SUSE12 Gold image on VM On 6/16/2015 at 09:55 AM, Alan Altmark alan_altm...@us.ibm.com wrote: On Tuesday, 06/16/2015 at 12:50 EDT, Mark Post mp...@suse.com wrote: On 6/15/2015 at 11:54 PM, Alan Altmark alan_altm...@us.ibm.com wrote: Neither z/VM nor Linux have to specify a portname (real or virtual). I recommend that you do NOT specify the portname. I don't understand why the distros still worry about the portname. We got rid of the requirement for z/VM and Linux on the z900 and z800 back in 2003. Just issue a msg that it's obsolete and ignore it. Even for Linux in an LPAR sharing an OSA with a z/OS system that is specifying (their equivalent of) a portname? Yes, even then. You can google OSA portname relief. OK then. I'm going to open up a bug with IBM to either remove that attribute from the driver, or make it read-only in sysfs. Preferably removing it altogether since it can only cause problems by being present. Looking at the results of my Google searches, I can see why I never made the complete connection. There were always statements made about z/OS requiring the parameter, and if you specify it in Linux it has to match. Looking at it now, I understand what was meant. Back then it meant (to me and apparently others) if you're sharing an OSA you need to specify the same portname as z/OS is using. Well, technically there have been machines with OSA cards that required the portname which is why the parameter has survived until now. There is a bit in the response block of the read channel activation ccw that tells us if the portname is required. With the option for 31-bit kernel builds gone from the upstream source and the fact that the z900/z800 does not require the portname we could remove the portname code from the OSA driver. Uschi, care to create a patch to remove everything portname related from the OSA driver? blue skies, Martin Martin Schwidefsky Linux on System z Development IBM System Technology Group, System Software Development IBM Deutschland Research Development GmbH Vorsitzender des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Strange vswitch problem
On Wed, 2015-01-28 at 09:50 -0500, Andrew Lemay wrote: What I don't get is my configs are the same for all 42 guests. But this one keeps showing up on guest LAN [root@test-09 ~]# dmesg | grep qeth qeth: loading core functions qeth: register layer 2 discipline qeth 0.0.8000: MAC address 11:11:11:11:11:11 successfully registered on device eth0 qeth 0.0.8000: Device is a Guest LAN QDIO card (level: V614) qeth 0.0.8000: MAC address 11:11:11:11:11:11 successfully registered on device eth0 ... Andrew, message qeth 0.0.8000: Device is a Guest LAN QDIO card (level: V614) is confusing. It applies to VSWITCHes as well. The qeth driver supports z/VM virtual NICs for Guest LANs and VSWITCHes (there is not a real difference from a qeth point of view). In recent kernels we have changed this message to qeth 0.0.8000: Device is a Virtual NIC QDIO card (level: V614). Regards, Ursula Braun, IBM Germany, Linux on System z development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Hipersockets Early Completion Queue Support
On Thu, 2014-05-29 at 17:26 +, Gerard Howells wrote: Hello All, As a result of some issues we've been seeing we're looking to implement the z/VM Hipersockets Early Completion queue feature in our systems. We run VM 6.2 with z/VSE 5.1 and a mixture of SLES 10 SP4 and 11 SP3 guests. I know that it's supported in SLES 11 my question is whether it's supported in SLES 10? Thanks in advance! Gerard Howells Gerard, currently Linux exploits HiperSockets Completion Queues only for the address family AF_IUCV (in case of HiperSockets transport), i.e. when running an AF_IUCV socket program. It is not used for standard IP-traffic across HiperSockets. Regards, Ursula Braun, IBM Germany, Linux on System z development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Red Hat OSA-Express5S
Mike, for optimum performance we recommend a RHEL5 kernel-2.6.18-382.el5 (or higher) and a RHEL6 kernel-2.6.32-416.el6 (or higher) - Bugzillas RH997628 and RH99762. Ursula Braun, IBM Germany, Linux on System z development On Thu, 2014-04-24 at 11:08 +0100, Mike Wawiorko wrote: Is a Red Hat QDIO driver update required for Red Hat Linux to run with OSA-Express5S? All works fine with OSA-Express3 and OSA-Express4S. This is with Linux driving the OSAs directly using master/slave bonding - no VSWITCH. Mike Wawiorko I Global z Connectivity and Automation Engineering I Global Technology Infrastructure and Services Tel +44 (0)1565 615415I Int 7-2000-5415 I Mobile +44 (0)7824 527120 I Email mike.wawio...@barclays.commailto:mike.wawio...@barclays.com Barclays, Ground Floor (B4), Turing House, BTC Radbroke, WA16 9EU (Mail Van 49) barclays.com P Please consider the environment before printing this e-mail This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: TX-Errs on hipersocket interface.
Ron, I have not followed all IP-stack related patches for SLES12; thus I can answer your question just from a qeth driver perspective: Your kernel level misses some qeth patches, but none of these patches is related to your TX errors symptom. Thus my answer is no from my qeth driver perspective. Kind Regards, Ursula Braun, Linux on System z development, IBM Germany On Fri, 2013-07-26 at 19:47 +, Ron Foster wrote: Ursula, We are running kernel 3.0.42-0.7-default. Would it help to go to a more recent kernel? Thanks, Ron Foster Baldor Electric Company 5711 R S Boreham Jr Street Fort Smith, AR 72901 Phone:479-648-5865 Fax:479-646-5440 Email: ron.fos...@baldor.abb.com IM Address:rfos...@baldor.com www.baldor.com From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Ursula Braun [ubr...@linux.vnet.ibm.com] Sent: Friday, July 26, 2013 3:05 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: TX-Errs on hipersocket interface. Jon, without any performance data my answer can be only vague. But let's assume a performance increase for data sending when moving from SLES10 to SLES11. If the receiver has already been close to his buffer usage limit with SLES10, he might hit this limit after upgrading the sender to SLES11. Regards, Ursula Braun, Linux on System z Development, IBM Germany On Thu, 2013-07-25 at 18:21 +, Veencamp, Jonathon D. wrote: Question: Why would SLES 11 see hipersocket retransmits and window adjustments and not SLES 10? Is the device driver either more forgiving or efficient on SLES 10? I'm just curious. I may be in the same situation soon. Regards Jon Veencamp Federated Insurance -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ursula Braun Sent: Thursday, July 25, 2013 9:54 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: TX-Errs on hipersocket interface. Ron, Carsten's first explanation is correct. If you see tx_errors on a HiperSockets interface, it usually means transmission of a packet fails because the receiver has currently no free receive buffer. You should verify first if the receiver has configured the maximum of 128 buffers (sysfs attribute buffer_count) for his HiperSockets device. 128 is nowadays the default, but older qeth driver versions run with a default of 16. If you see the tx_errors even though your receiver runs already with the maximum of 128 buffers, you either have to live with the autotuning mechanisms of tcp or you take actions to slow down the sender or to accelerate the receiver. As Alan suggested we can document this in the Device Driver book. The other option would be to change the current behavior of the qeth driver and increase probably both the tx_dropped and the tx_error counter. It is definitely not a problem to report to SuSe folks. Kind regards, Ursula Braun, Linux on System z development, IBM Germany On Thu, 2013-07-25 at 13:18 +, Ron Foster wrote: Carsten, Do you know where I would start looking for causes of the transmit errors on Hipersockets? The error is occurring on SLES11 SP2 systems. We are not having it on our SLES10 SP4 systems. Do I need to open a problem with the SuSe folks? Thanks, Ron Foster Baldor Electric Company 5711 R S Boreham Jr Street Fort Smith, AR 72901 The information contained in this e-mail message is intended only for the personal and confidential use of the designated recipient(s) named above. This message may be an attorney-client or work product communication which is privileged and confidential. It may also contain protected health information that is protected by federal law. If you have received this communication in error, please notify us immediately by telephone and destroy (shred) the original message and all attachments. Any review, dissemination, distribution or copying of this message by any person other than the intended recipient(s) or their authorized agents is strictly prohibited. Thank you. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http
Re: TX-Errs on hipersocket interface.
Jon, without any performance data my answer can be only vague. But let's assume a performance increase for data sending when moving from SLES10 to SLES11. If the receiver has already been close to his buffer usage limit with SLES10, he might hit this limit after upgrading the sender to SLES11. Regards, Ursula Braun, Linux on System z Development, IBM Germany On Thu, 2013-07-25 at 18:21 +, Veencamp, Jonathon D. wrote: Question: Why would SLES 11 see hipersocket retransmits and window adjustments and not SLES 10? Is the device driver either more forgiving or efficient on SLES 10? I'm just curious. I may be in the same situation soon. Regards Jon Veencamp Federated Insurance -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ursula Braun Sent: Thursday, July 25, 2013 9:54 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: TX-Errs on hipersocket interface. Ron, Carsten's first explanation is correct. If you see tx_errors on a HiperSockets interface, it usually means transmission of a packet fails because the receiver has currently no free receive buffer. You should verify first if the receiver has configured the maximum of 128 buffers (sysfs attribute buffer_count) for his HiperSockets device. 128 is nowadays the default, but older qeth driver versions run with a default of 16. If you see the tx_errors even though your receiver runs already with the maximum of 128 buffers, you either have to live with the autotuning mechanisms of tcp or you take actions to slow down the sender or to accelerate the receiver. As Alan suggested we can document this in the Device Driver book. The other option would be to change the current behavior of the qeth driver and increase probably both the tx_dropped and the tx_error counter. It is definitely not a problem to report to SuSe folks. Kind regards, Ursula Braun, Linux on System z development, IBM Germany On Thu, 2013-07-25 at 13:18 +, Ron Foster wrote: Carsten, Do you know where I would start looking for causes of the transmit errors on Hipersockets? The error is occurring on SLES11 SP2 systems. We are not having it on our SLES10 SP4 systems. Do I need to open a problem with the SuSe folks? Thanks, Ron Foster Baldor Electric Company 5711 R S Boreham Jr Street Fort Smith, AR 72901 The information contained in this e-mail message is intended only for the personal and confidential use of the designated recipient(s) named above. This message may be an attorney-client or work product communication which is privileged and confidential. It may also contain protected health information that is protected by federal law. If you have received this communication in error, please notify us immediately by telephone and destroy (shred) the original message and all attachments. Any review, dissemination, distribution or copying of this message by any person other than the intended recipient(s) or their authorized agents is strictly prohibited. Thank you. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: TX-Errs on hipersocket interface.
Ron, Carsten's first explanation is correct. If you see tx_errors on a HiperSockets interface, it usually means transmission of a packet fails because the receiver has currently no free receive buffer. You should verify first if the receiver has configured the maximum of 128 buffers (sysfs attribute buffer_count) for his HiperSockets device. 128 is nowadays the default, but older qeth driver versions run with a default of 16. If you see the tx_errors even though your receiver runs already with the maximum of 128 buffers, you either have to live with the autotuning mechanisms of tcp or you take actions to slow down the sender or to accelerate the receiver. As Alan suggested we can document this in the Device Driver book. The other option would be to change the current behavior of the qeth driver and increase probably both the tx_dropped and the tx_error counter. It is definitely not a problem to report to SuSe folks. Kind regards, Ursula Braun, Linux on System z development, IBM Germany On Thu, 2013-07-25 at 13:18 +, Ron Foster wrote: Carsten, Do you know where I would start looking for causes of the transmit errors on Hipersockets? The error is occurring on SLES11 SP2 systems. We are not having it on our SLES10 SP4 systems. Do I need to open a problem with the SuSe folks? Thanks, Ron Foster Baldor Electric Company 5711 R S Boreham Jr Street Fort Smith, AR 72901 Phone:479-648-5865 Fax:479-646-5440 Email: ron.fos...@baldor.abb.com IM Address:rfos...@baldor.com www.baldor.com From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Carsten Otte [co...@de.ibm.com] Sent: Thursday, July 25, 2013 7:53 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: TX-Errs on hipersocket interface. Alan wrote: Carsten, this is information that really needs to be in the Device Driver book, as it differs from the traditional interpretation of TX/RX counters. Ah, you're right - that would be accouned as dropped, not TX error. Forget about my reply then, time to look at other causes for that TX error. Sorry for the noise. with kind regards Carsten Otte System z firmware development / Boeblingen lab --- Every revolution was first a thought in one man's mind; and when the same thought occurs to another man, it is the key to that era. - Ralph Waldo Emerson, Essays: First Series, 1841 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: CCL OSA device not activated
Hi Berry, found the problem in /sbin/qeth_configure. It enforces a definition for the layer2 attribute, which is not applicable for OSN-devices. You might edit the created udev rule in /etc/udev/rules.d/51-qeth... and remove the layer2 line. Anyway, the problem should be reported to SuSE. Will you do this yourself or should we follow up on this? Regards, Ursula Braun, IBM Germany On Tue, 2012-11-06 at 10:44 +, van Sleeuwen, Berry wrote: At first I've copied the rule from the vswitch connection and configured the udev rule according to the configuration we had on the SLES9 machine, including the portno and layer2 rules. When that didn't work I did try to configure with yast, but that didn't work either, basically with the same error: stderr:/sbin/qeth_configure: line 280: echo: write error: Input/output error \n, stdout:Could not set device 0.0.efac online\n] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: CCL OSA device not activated
Hi Berry, ok, we will open a SuSE-bugzilla to get this qeth_configure problem fixed for OSN-devices. Regards, Ursula Braun, IBM Germany On Wed, 2012-11-07 at 09:34 +, van Sleeuwen, Berry wrote: Hi Ursula, I did remove the line, if anything just to see if the device would be activated without it. I haven't put it back in after we got the device to activate during boot. I guess you can report it. If I would report it it would go through IBM so it would still end up at your desk anyway. Thanks, Berry. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: CCL OSA device not activated
On Thu, 2012-11-01 at 09:57 +, van Sleeuwen, Berry wrote: I tried to activate with these commands, as well as with znetconf but that was still not successful. After installing the most recent patches, the kernel is now on 2.6.32.59, the ccwgroup device 0.0.efac is activated during boot. Since it's now active we can test the new CCL once again. The funny thing is we are upgrading, from SLES9 to SLES11, just to have a supported version before we migrate to a new CPU. But indeed, the installed SLES11 level was not the most recent. Since it's an OSN it must be layer2. Even more so, files portname, portno and layer2 are not available in /sys/bus/ccwgroup/drivers/qeth/0.0.efac/. But it looks like that's the same in SLES9. During boot there is no comment about that on SLES9, on SLES11 udev complains about these rules. Berry, now I recognize my first hint has been useless for you - sorry. Your problem is specific to OSN. OSN-devices are special OSA-devices which offer just a few writable sysfs-attributes (buffer_count and recover). Thus it does not make sense to have definitions for portname, portno, and layer2 in a udev-rule for an OSN-device. I assume your udev-rule has been created by yast - correct? Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: CCL OSA device not activated
Berry,
what's the kernel version of your SLES11 SP1 kernel running? I am aware
of a race problem between udev rules and kernel while accessing a sysfs
attribute of a ccwgroup device. It has been fixed with kernel
2.6.32.49-0.3.1. This problem would match your described symptom
udevd-event[554]: error opening
ATTR{/sys/devices/qeth/0.0.efac/portname} for writing: No such file or
directory
Regards, Ursula Braun, IBM Germany
On Fri, 2012-10-26 at 10:00 +, van Sleeuwen, Berry wrote:
Hello All,
We are migrating a CCL guest from SLES9 to SLES11 SP1. The guest is available
but the CCL is not activated. Looking at it it looks like udev can't activate
the devices needed for the CCL engine. The guest has the three OSA devices
(EFAC, EFAD, EFAE) attached, just as it had in the SLES9 CCL guest.
/var/log/boot.msg:
udevd-event[554]: error opening ATTR{/sys/devices/qeth/0.0.efac/portname} for
writing: No such file or directory
Devices (EFAC, EFAD, EFAE) are online but the ccwgroup is offline.
cat /sys/bus/ccw/devices/0.0.efac/online
1
cat /sys/bus/ccwgroup/devices/0.0.efac/online
0
When I compare this with a running SLES9 CCL machine the ccwgroup should be
online, so I guess this is the problem I need to fix.
Any ideas how to configure these OSA devices in SLES11?
Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: CCL OSA device not activated
Hi Berry, sure, you can always activate a qeth device manually. One possiblitiy is to make use of the znetconf command. Determine your configured options for your OSA (for instance from the corresponding udev-rule in /etc/udev/rules.d/51-qeth...) and specify them explicitly with the -o option of znetconf. The command is described in our Device Drivers book ( http://public.dhe.ibm.com/software/dw/linux390/docu/l26edd01.pdf ). Regards, Ursula, IBM Germany On Tue, 2012-10-30 at 12:24 +, van Sleeuwen, Berry wrote: Hi Ursula, Thanks. That might be something then. We have 2.6.32.12-0.7 in these guests. Is there any way to go around this issue? Can we activate the OSA outside udev? Regards, Berry. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: QETH issue?
On Tue, 2012-08-14 at 15:26 +, KEETON Dave * ETS wrote: On an occasional basis, when I have to IPL a guest under 5.4, I find that the primary network connection doesn't work properly when the SLES system comes [back] up. It isn't until I ping the gateway from said guest that I'm able to access it remotely. Until that step is performed, the system is inaccessible over the network. I accomplish this either by accessing the guest from another systems over a Hipersockets connection or the TN3270 console. After this step is performed, it's again possible to access the guest remotely, via SSH, over the primary network connection. All of the SLES guests are attached to a VLAN-aware VSWITCH, which in turn is connected to redundant OSA Express-3 cards. Has anyone else seen this behavior? Any idea why it might do this? It doesn't appear to matter whether it's a SLES 10 or SLES 11 guest, the issue is the same. It is NOT every time the guests is IPL'd, either which makes it all the more bizzare and difficult to troubleshoot. Dave, we reported this problem for SLES 11 in SUSE bugzilla 617373. Solution has been to introduce a SEND_GRATUITOUS_ARP config option. Its default is no. Changing it to yes should trigger the sending of gratuitous ARPs. It applies to ETHERNET (not IP) VSWITCHes. The config option is offered starting with sysconfig-0.71.30-0.10.1. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Network card speed
On Tue, 2012-06-19 at 16:15 -0400, Victor Echavarry Diaz wrote: We have installed an OSA gigabit card. When we check the speed of any zlinux guest attached to this OSA card velocity show 100Mbs instead of Gigabit. Is there a tool or a command to check inside the zlinux guest the speed of the card? We have z/vm 5.4 and z/linux 10SP4 and SLES 11SP1. I use ethtool and show no data available for eth0. Regards, Victor Echavarry System Programmer Technology Systems Operations Division EVERTEC Victor, with SLES11 SP1 you can use ethtool ethx. This feature is not available with SLES10 SP4. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Network card speed
On Wed, 2012-06-20 at 09:15 -0400, Victor Echavarry Diaz wrote: Ursula: Which tool we have for SLES 10? Our majority of servers are on SLES 10. Victor, for SLES10 (and SLES11) you can derive the maximum speed from the card_type line in the output of lsqeth ethx Once OSA-devices are online, it displays one of these values OSD_100 OSD_1000 OSD_10GIG Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Network card speed
On Wed, 2012-06-20 at 11:27 -0400, Victor Echavarry Diaz wrote: Ursula: This is my output # lsqeth eth0 Device name : eth0 - card_type : GuestLAN QDIO Victor, then you are running a virtual net interface connected to a z/VM VSWITCH or GuestLAN. In this case Linux cannot provide a value for the maximum speed - only for real OSA-devices added to Linux. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Start networkadapter without reboot
On Fri, 2012-06-15 at 14:54 +, van Sleeuwen, Berry wrote: Hi Scott, Yes it is. I've found some more information when looking through the /sys/ directory. The state for this device is in HARDSETUP. nlzlx204:~ # cat /sys/devices/qeth/0.0.0f10/state HARDSETUP Searching for this I've found some information in patch reports, for instance at git390.marist.edu and kerneltrap.org. This status is a result of a boot without the actual device available. Indeed, what we have here now. When the cable is plugged (or the vswitch connected) the state should switch to SOFTSETUP or eventualy even to UP. But it doesn't. Would it be possible to get it to UP dynamically or is this a bug that can be resolved with a reboot or network restart only? (kernel level is at 2.6.32.12-0.7). Berry. Hi Berry, correct, state HARDSETUP should be a temporary state during online setting for a qeth device only. If the device stays in state HARDSETUP something unexpected occurred. To understand the reason, the trace file /sys/kernel/debugfs/qeth_setup/hex_ascii should be checked by a qeth expert. It's a wrap around buffer; thus it needs to be saved immediately after the problem shows up. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Start networkadapter without reboot
On Mon, 2012-06-18 at 10:15 +0100, Malcolm Beattie wrote: Ursula Braun writes: correct, state HARDSETUP should be a temporary state during online setting for a qeth device only. If the device stays in state HARDSETUP something unexpected occurred. To understand the reason, the trace file /sys/kernel/debugfs/qeth_setup/hex_ascii should be checked by a qeth expert. It's a wrap around buffer; thus it needs to be saved immediately after the problem shows up. I can reproduce this easily on SLES11SP1 kernel 2.6.32.12-0.7-default (not up to date on service at all). I'll send you a transcript. Malcolm, looking through your transcript, I find the definition of the NIC (vmcp def nic 800 type qdio), but I do not see a vmcp couple command to bind the created NIC to a VSWITCH or GuestLAN. This would explain the failing STARTLAN command for this qeth device. Try to insert a vmcp couple command between vmcp def nic... and znetconf -a ... . Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Start networkadapter without reboot
On Mon, 2012-06-18 at 11:36 +0100, Malcolm Beattie wrote: I intentionally didn't bother with a COUPLE since I was trying to reproduce Berry's problem and also expecting the vNIC to act like a normal NIC and let me configure it and even ifconfig it up before plugging it into a switch. I'd thought that that used to work but maybe not. Would it be considered a bug or an unimplemented feature that it doesn't act that way? Actually, even when I then couple it to a VSWITCH, the state remains in HARDSETUP (even after I do an echo 1 recover too) and an ifup eth1 still fails. That makes it even more unlike a normal NIC and seems very inconvenient. I'll send you the trace for that too in case that part is unexpected. --Malcolm Malcolm, tried to recreate your problem with my available upstream kernel. But my qeth device stayed in state SOFTSETUP after znetconf. Further analysis showed that you need to upgrade to a kernel level of at least 2.6.32.29-0.3.1 (bugzilla 68725) to see this behavior. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mac address problem
On Mon, 2012-05-21 at 06:41 -0500, David Boyes wrote: On 5/21/12 4:11 AM, Ursula Braun ubr...@linux.vnet.ibm.com wrote: we reported this problem in Novell bugzilla 617373. Solution has been to introduce a SEND_GRATUITOUS_ARP config option. Its default is no. Changing it to yes should trigger the sending of gratuitous ARPs. The config option is offered starting with sysconfig-0.71.30-0.10.1. When would this NOT be the correct behavior? Seems like the default should be yes, given that that's the way ARP has worked for decades. The solution with SEND_GRATUITOUS_ARP config option is provided by SUSE. They would have to change the default to yes. We have never asked for this default change. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mac address problem
On Thu, 2012-05-17 at 15:52 +, Levy, Alan wrote: We have a problem with a linux server that when we reboot it, it takes at least 15 minutes to be able to ssh into. It seems, from out network traces, that when the server reboots, it has 2 mac addresses in the arp tables on the firewall (one from before and one from after the reboot). We cannot ping or ssh into the server after the reboot. Yesterday, we rebooted it. The network group ran traces, captured packets, etc and we found that if we pinged the network gateway address from this server, everything started working again. Has anyone seen this before ? Alan, we reported this problem in Novell bugzilla 617373. Solution has been to introduce a SEND_GRATUITOUS_ARP config option. Its default is no. Changing it to yes should trigger the sending of gratuitous ARPs. The config option is offered starting with sysconfig-0.71.30-0.10.1. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: IPv6 on hypersockets
On Wed, 2012-05-09 at 13:57 -0400, Bauer, Bobby (NIH/CIT) [E] wrote: ping doesn't work yet but one step at a time. Bobby, use ping6 for IPv6; ping works just for IPv4. Kind regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES11 SP1 - Have you seen this?
On Thu, 2012-05-03 at 20:18 -0600, Lee Stewart wrote: Hi... I have a customer running SLES11 SP1 and a layer 2 Vswitch. When we did the initial install, all went well, and all the clones behaved as expected. They did another from scratch install the other day and it seemed to go well. But when they cloned it, they started to have network trouble, and it ended up that they couldn't have their new master Linux and a clone of that up at the same time -- even though they had different IPs. The problem turned out to be that for some reason the new master (and therefore it's clone) had a hardcoded MAC address (LLADDR=) in the network definition. So even though they had different IPs, they were trying to use the same MAC address. Removing the LLADDR= fixed the problem and both were assigned dynamic MAC addresses by the Vswitch. But the question was posed -- Why was it different than the first install? I wasn't there for the 2nd install, but they say they followed the same steps and chose the same options. And there was no LAYER2=1 in the network setup files. Anyone have any thoughts on what they might have done differently to cause the MAC address to become fixed on the Linux side? Lee, 1. The LLADDR settings for qeth devices have been covered in several bugzillas. yast-fixes went into SLES11 SP2. Removing LLADDR= for layer2 VSWITCH devices is definitely the correct solution. 2. The configuration for layer2 is contained in the udev-rule /etc/udev/rules.d/51-qeth-... 3. The MAC-address for a VSWITCH NIC of a Linux guest is defined within z/VM. It may change after LOGOFF / LOGON of the Linux guest. Sometimes the LLADDR= specification in Linux may accidentally match the current definition in z/VM and you do not run into network trouble this time. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Anyone lose network connectivity during upgrade to SLES11 SP1
Ron, the MAC-address for a VSWITCH interface is defined by z/VM. Can you check somehow if this MAC-address changes during upgrade - for instance in z/VM CP with command CP Q VSWITCH DETAILS? If yes, the problem seems to be related to Novell bugzilla 617373. Kind regards, Ursula Braun, IBM Germany, Linux on System z development On Thu, 2012-02-02 at 13:34 -0600, Ron Foster at Baldor-IS wrote: Hello, We are in the midst of performing our first upgrade from SLES10 SP4 to SLES11 SP1 and are having network connection issues. We are attempting to upgrade our Linux sandbox system that runs under z/VM. We ipl from the card reader and perform the first part of the upgrade just fine. After the first part of the upgrade, the install program reboots itself. All appears to be working fine until the part that tells us to VNC into the system to finish the upgrade. At that point we try to do this and VNC does not connect. We try to ping the guest and get no response. I run nmap against the address and it shows no ports open. The device 0700 being used is connected to a VSWITCH. Before the upgrade, the device works fine. The first part of the upgrade works fine. It is only the second part of the upgrade that does not work ok. Here are what I think are the relevant portions of the messages that come out out boot. dasd-eckd.412b53: 0.0.0201: DASD with 4 KB/block, 2403360 KB total size, 48 KB/t rack, compatible disk layout dasdd: qeth.736dae: 0.0.0700: Device is a Guest LAN QDIO card (level: V620) with link type GuestLAN QDIO (portname: ) qeth.47953b: 0.0.0700: Hardware IP fragmentation not supported on eth0 qeth.066069: 0.0.0700: Inbound source MAC-address not supported on eth0 qeth.d7fdb4: 0.0.0700: VLAN enabled qeth.e90c78: 0.0.0700: Multicast enabled qeth.5a9d02: 0.0.0700: IPV6 enabled qeth.184d8a: 0.0.0700: Broadcast enabled qeth.dac2aa: 0.0.0700: Using SW checksumming on eth0. qeth.9c4c89: 0.0.0700: Outbound TSO not supported on eth0 VOL1/ 0X0200: Adding 2403256k swap on /dev/dasdb1. Priority:-1 extents:1 across:2403256k device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-de...@redhat.com redir.aspx?C=c96b8535c5c94f02aa7b733fd5bd1f87URL=mailto%3adm-devel%40redhat.com loop: module loaded REISERFS (device dasda2): found reiserfs format 3.6 with standard journal (Deleted lines) Disabling IPv6 privacy..done ..done Setting up hostname 'bus0105'..done Setting up loopback interface lo loIP address: 127.0.0.1/8 IP address: 127.0.0.2/8 ..done Running sadc ..done Setting kernel specific parameters for a SAP system ..doneSystem Boot Control: The system has been set up Skipped features: [80C [14Dboot.md System Boot Control: Running /etc/init.d/boot.local ..doneStarting syslog services..done Starting D-Bus daemon..done Loading CPUFreq modules (CPUFreq not supported) Starting HAL daemon..done Setting up (localfs) network interfaces: lo loIP address: 127.0.0.1/8 IP address: 127.0.0.2/8 lo ..doneeth0 name: IBM OSA Express Network card (0.0.0700) eth0 IP address: 10.80.200.126/24 eth0 ..doneWaiting for mandatory devices: qeth-bus-ccw-0.0.0600 qeth-bus-ccw-0.0.510 0 qeth-bus-ccw-0.0.5200 qeth-bus-ccw-0.0.a006 __NSC__ 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 qeth-bus-ccw-0.0.0600 No interface found ..failedqeth-bus-ccw-0.0.5100 No interface found ..failedqeth-bus-ccw-0.0.5200 No interface found ..failedqeth-bus-ccw-0.0.a006 No interface found ..failedSetting up service (localfs) network . . . . . . . . . ...fail ed *** *** Please return to your X-Server screen to finish installation *** pcilib: Cannot open /proc/bus/pci lspci: Cannot find any working access method. starting VNC server... A log file will be written to: /var/log/YaST2/vncserver.log ... *** *** You can connect to 10.80.200.126, display :1 now with vncviewer *** Or use a Java capable browser on http://10.80.200.126:5801/ redir.aspx?C=c96b8535c5c94f02aa7b733fd5bd1f87URL=http%3a%2f%2f10.80.200.126%3a5801%2f *** (When YaST2 is finished, close your VNC viewer and return to this window.) *** Starting YaST2 *** This is a sandbox system, so for various reasons has many network interfaces. But for this run, the 0600, 5100, 5200, and a006 interfaces have been removed from the directory. That is the reason for all the no interface found messages. We have also made an update run where we removed the interfaces from the guest before we started. The results were the same. We try to connect to 10.80.200.126 and do not get a response. Any ideas? Any additional documentation required? Thanks, Ron -- For LINUX-390 subscribe / signoff
Re: How to change /udev/rules.d/ for hsi
Mark,
try to move the buffer_count and checksumming line before the
online line. The qeth driver does not allow to change the buffer_count
value in online state.
Regards, Ursula Braun, IBM Germany
On Thu, 2011-12-08 at 10:13 -0500, Mark D Vandale wrote:
Here's some more detail if that helps... The hipersocket address e000.
I've added the last 2 lines, 1 to increase the buffer cnt and the other to
turn off checksumming. Neither parameter changes during a reboot.
lsqeth -p still shows a cnt of 16 for the device
-rw-r--r-- 1 root root 1296 2011-12-07
10:06 /etc/udev/rules.d/51-hsi-0.0.e000.rules
# Configure hsi device at 0.0.e000/0.0.e001/0.0.e002
ACTION==add, SUBSYSTEM==drivers, KERNEL==qeth, IMPORT
{program}=collect 0.0.e000 %k 0.0.e000 0.0.e001 0.0.e002 qeth
ACTION==add, SUBSYSTEM==ccw, KERNEL==0.0.e000, IMPORT
{program}=collect 0.0.e000 %k 0.0.e000 0.0.e001 0.0.e002 qeth
ACTION==add, SUBSYSTEM==ccw, KERNEL==0.0.e001, IMPORT
{program}=collect 0.0.e000 %k 0.0.e000 0.0.e001 0.0.e002 qeth
ACTION==add, SUBSYSTEM==ccw, KERNEL==0.0.e002, IMPORT
{program}=collect 0.0.e000 %k 0.0.e000 0.0.e001 0.0.e002 qeth
TEST==[ccwgroup/0.0.e000], GOTO=hsi-0.0.e000-end
ACTION==add, SUBSYSTEM==ccw, ENV{COLLECT_0.0.e000}==0, ATTR
{[drivers/ccwgroup:qeth]group}=0.0.e000,0.0.e001,0.0.e002
ACTION==add, SUBSYSTEM==drivers, KERNEL==qeth, ENV
{COLLECT_0.0.e000}==0, ATTR
{[drivers/ccwgroup:qeth]group}=0.0.e000,0.0.e001,0.0.e002
LABEL=hsi-0.0.e000-end
ACTION==add, SUBSYSTEM==ccwgroup, KERNEL==0.0.e000, ATTR{portno}=0
ACTION==add, SUBSYSTEM==ccwgroup, KERNEL==0.0.e000, ATTR{layer2}=0
ACTION==add, SUBSYSTEM==ccwgroup, KERNEL==0.0.e000, ATTR{online}=1
ACTION==add, SUBSYSTEM==ccwgroup, KERNEL==0.0.e000, ATTR
{buffer_count}=128
ACTION==add, SUBSYSTEM==ccwgroup, KERNEL==0.0.e000, ATTR
{checksumming}=no_checksumming
Is there something else that needs to be changed ? SLES 11
Thanks,
Mark
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: MTU size in z/Linux
Terry, when changing the MTU value for a qeth device, the qeth driver does some checking against the the maximum value allowed. This value depends on the type of the qeth device (OSA or HiperSockets), but in both cases the hardware / firmware defines the maximum allowed value. Regards, Ursula Braun, IBM Germany On Wed, 2011-11-09 at 12:28 -0500, Martin, Terry R. (CMS/CTR) (CTR) wrote: Hi It does not seem to let us specify an MTU higher than 8192. The question is can we specify a MTU size of 9000 or 9200 Thank You, Terry Martin Principal Systems Engineer Lockheed Martin CMS - CITIC 3300 Lord Baltimore Drive, Suite 200, 21244 Engineering Computing Mainframe Support Cell - 443 632-4191 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: hipersockets don't come up after HW upgrade
Hi Roger, your boot.messages do not show any message refering to 0.0.7000 or hsi0. Your hsi0-device is in state SOFTSETUP, which means it has been activated successfully; just the ifup step fails. The configuration file for ifup is /etc/sysconfig/network/ifcfg-hsi0. Can you check the definitions of this file? By the way, you have chosen layer2=1 for your hsi0-device. This is ok, but it allows communication to other layer2 HiperSockets participants only, no layer3 HiperSockets participants. Regards, Ursula Braun, IBM Germany On Tue, 2011-11-08 at 08:39 +0100, Roger Evans wrote: Hi, Ursula uname -a Linux DPRODDB2 2.6.32.46-0.3-default #1 SMP 2011-09-29 17:49:31 +0200 s390x s390x s390x GNU/Linux lsqeth ... [other devices] Device name : hsi0 - card_type : HiperSockets cdev0 : 0.0.7000 cdev1 : 0.0.7001 cdev2 : 0.0.7002 chpid : F1 online : 1 portname: no portname required portno : 0 state : SOFTSETUP priority_queueing : always queue 2 buffer_count: 16 layer2 : 1 isolation : none I am attaching the results of the dmesg command Med vennlig hilsen Roger Evans -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: hipersockets don't come up after HW upgrade
Roger, get rid of the LLADDR='00:00:00:00:00:00' definition. ifup does no longer work for a zero MAC-address. HiperSockets define a MAC-address; during initialization Linux determines this MAC-address and uses it, if LLADDR is not defined. Ursula On Tue, 2011-11-08 at 10:47 +0100, Roger Evans wrote: Forgot to send the info you requested: DPRODDB2:/etc/sysconfig/network # cat ifcfg-hsi0 BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='10.5.2.11/16' LLADDR='00:00:00:00:00:00' MTU='' NAME='Hipersocket (0.0.7000)' NETWORK='' REMOTE_IPADDR='' STARTMODE='manual' USERCONTROL='no' Roger -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: hipersockets don't come up after HW upgrade
Roger, when configuring a network interface with yast, a udev-rule is created for the device containing qeth attribute definitions, among them attribute layer2. Look into /etc/udev/rules.d and check a rule starting with 51-...7000... . I assume this rule contains a line with layer2=1. Change this into layer2=0 and the device should come up with layer3 after reboot. Ursula On Tue, 2011-11-08 at 10:45 +0100, Roger Evans wrote: THanks for that tip. I can't remember having chosen level2, but I see that my other (older) interfaces are not level2, so, yes, I would like to switch to level3. I used the commands (from Device Drivers, Features...) to to take the device offline and to make it not level2 (level2=9); After that, lsqeth showed it as level2=0. But after rebooting, it reverted to level2=1. I noticed the following message on VM when booting: --- ..skippedWaiting for mandatory devices: hsi-bus-ccw-0.0.7000 __NSC__ 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 hsi-bus-ccw-0.0.7000No interface found Any idea what I'm missing? Roger -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: hipersockets don't come up after HW upgrade
Roger, good news. I am working in the networking team of Linux on System z development; thus qeth-related problems are my daily business. But please do not ask me financial questions ;-) For your remaining problem: Have you upgraded your system from SLES10? In this case you may still have old configuration files /etc/sysconfig/hardware/hwcfg-hsi-bus-ccw-0.0.7000 or /etc/sysconfig/network/ifcfg-hsi-bus-ccw-0.0.7000. Those are no longer needed for SLES11 and can be removed. Ursula On Tue, 2011-11-08 at 12:58 +0100, Roger Evans wrote: Thank you, Ursula That solved the problem. I can now ping and ftp between my layer3 hipersockets. I still get the Waiting for mandatory devices. hsi-bus-ccw-0.0.7000 No interface found msg. when booting but now that it works, I'll just stop watching. You're pretty amazing. Think you could fix the Greek deficit crisis, too? Best Regards Roger Evans, Autodata Norge A/S http://www.autodata.no -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: hipersockets don't come up after HW upgrade
On Fri, 2011-11-04 at 15:18 +0200, Roger Evans wrote: Hi Sue Didn't seem to help. When booting with SLES10v2 I see the following when watching the boot from VM: - eth: IPv6 not supported on hsi0 qeth: Broadcast enabled qeth: Using SW checksumming on hsi0. qeth: Outbound TSO not supported on hsi0 operand exception: 0015 ¬Æ1| CPU: 0 Not tainted Process hwup-qeth (pid: 709, task: 0f400048, ksp: 0eee3960) Krnl PSW : 070400018000 1098cefa (do_QDIO+0x452/0x2a9c ¬qdio|) Krnl GPRS: 0001 00010006 8000 8000 00010006 000f 0e931000 0e4cf000 0e931000 1097f000 10994960 0eee3ba8 0eee3aa8 Krnl Code: b2 22 00 30 88 30 00 1c 12 33 a7 84 00 0c bf 4f 92 50 a7 84 Call Trace: (¬10b03a68| qeth_dbf_setup+0x0/0xfffe7ad0 ¬qeth|) ¬10adeafc| __qeth_set_online+0x2780/0x2de4 ¬qeth| ¬1081b544| ccwgroup_online_store+0x10c/0x1fc ¬ccwgroup| ¬002c43a0| sysfs_write_file+0x120/0x190 ¬002250f8| sys_write+0x188/0x38c ¬00115d10| sysc_noemu+0x10/0x16 ¬021c8738| 0x21c8738 ..done Loading required kernel modules ¬1A..done6device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel ... -- I get this regardless of whether QIOASSIST is ON or OFF. Regards/ Med vennlig hilsen Roger Evans Roger, the HiperSockets issue after HW upgrade requires a Linux upgrade: - see Novell bugzilla 659101 for SLES11 SP1 - see Novell bugzilla 662984 for SLES10 SP4 - RHEL 5.7 - RHEL 6.1 Description: qdio: use proper QEBSM operand for SIGA-R and SIGA-S Symptom: Operand exception leading to kernel panic. Problem: Wrong SIGA operand on QEBSM enabled qdio devices. Solution:Use proper SIGA operands in QEBSM mode. Switching QIOASSIST OFF for HiperSockets Devices should circumvent the problem. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: hipersockets don't come up after HW upgrade
Roger, the minimum SLES11 SP1 kernel level should be 2.6.32.29-0.3.1. If you still have problems with a kernel level greater or equal to this one, something else is wrong. Which qeth-related messages show up in dmesg? What does lsqeth return? Regards, Ursula Braun, IBM Germany On Mon, 2011-11-07 at 16:04 +0100, Roger Evans wrote: Thank you Ursula I don't seem to have the permissions to read those bugzilla entries, or maybe I'm looking in the wrong Novell Bugzilla. Upgrading from sp3 to sp4 solved the problem for SLES10. I upgraded my SLES11sp1 with all the upgrades SuSE provides, but still get the following msg: -- DPRODDB2:~ # ifup hsi0 hsi0 name: Hipersocket (0.0.7000) RTNETLINK answers: Unknown error 18446744073709486085 Cannot enable interface hsi0. interface hsi0 is not up - I will go through the steps in the hipersocket configuration instructions again. Maybe it's not enough to define it in YAST.. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Another Layer 2 question.
On Tue, 2011-06-28 at 11:08 -0700, Chuck Tribolet wrote: I've got a similar problem to Dave Jones, converting from real OSA ports to a Layer 2 VSWITCH. I've successfully done SLES 10 and RHEL 5, but I'm having trouble with a SLES 11 system on the same VSWITCH. What do I need to change there? Chuck, does your ifcfg-eth file for the VSWITCH NIC contain an LLADDR-definition? If yes, please remove it. VSWITCH NICs should always use the zVM-chosen MAC-address, which may change after LOGOFF/LOGON. Bugzilla 658708 is open to address this issue. Regards, Ursula Braun IBM Germany, Linux on System z development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Layer 2 question
On Mon, 2011-06-27 at 14:25 -0500, Dave Jones wrote: Here is what is in the ifcfg-eth0 file: # IBM QETH DEVICE=eth0 BOOTPROTO=static VSWITCH=1 OPTION=(layer2=1) IPADDR=xxx.yyy.www.zzz NETMASK=255.255.255.0 NETTYPE=qeth TYPE=Ehternet ONBOOT=yes HWADDR=02:00:00:00:00:07 SUBCHANNELS=0.0.0100,0.0.0101,0.0.0102 Dave, I would change 3 things in your ifcfg-eth0 file: 1. Remove HWADDR and VSWITCH 2. typo:TYPE=Ethernet 3. Specify the layer2 option with this syntax: OPTIONS='layer2=1' resulting in: # IBM QETH DEVICE=eth0 BOOTPROTO=static OPTIONS='layer2=1' IPADDR=xxx.yyy.www.zzz NETMASK=255.255.255.0 NETTYPE=qeth TYPE=Ethernet ONBOOT=yes SUBCHANNELS=0.0.0100,0.0.0101,0.0.0102 Does this config file help? Regards, Ursula Braun, IBM Germany, Linux on System z Development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES10 LPAR clone - OSA interface not found
Doug, an OSA-card can be used in non-QDIO mode (OSE) or in QDIO-mode (OSD). Your IOCDS-definition defines the type of your OSA-Express channel to be OSE or OSD. If lscss displays a CU-Type 1731/01, your OSA-Express channel is defined as OSD. In Linux the lcs-driver is responsible for OSE-type channels and the qeth-driver is responsible for OSD-type channels. For OSD-type devices a subchannel-triple is necessary to create a qeth-device, for instance echo 0.0.3200,0.0.3201,0.0.3202 /sys/bus/ccwgroup/drivers/qeth/group Regards, Ursula Braun, IBM Germany On Fri, 2011-02-11 at 14:57 -0800, Lester, Doug wrote: Mark, This is the lscss output. How do I tell if it is in LCS mode? Device Subchan. DevType CU Type Use PIM PAM POM CHPIDs -- 0.0.3200 0.0.1103 1732/01 1731/01 80 80 FF 0200 0.0.3201 0.0.1104 1732/01 1731/01 80 80 FF 0200 Thanks, Doug -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES 11 strange behavior network
Rogerio,
z/VM assigns MAC-addresses for virtual NICs. I assume the MAC-address
assigned to your SLES11 virtual NIC has changed after LOGOUT and this
change is not propagated to your network. If this is correct, I see 2
options to work around this problem:
1. Overwrite the z/VM-assigned MAC-address with a user-defined
MAC-address using an LLADDR-definition line
in /etc/sysconfig/network/ifcfg-ethx. Thus the MAC-address does not
change after LOGOUT.
2. Run an arping-command after ifup:
/sbin/arping -q -A -c 1 -I ${REALDEVICE} ${IPADDR}
to update your neighbours.
Regards,
Ursula Braun, IBM Germany
On Tue, 2011-02-01 at 15:49 -0200, Rogério Soares wrote:
Guys, i get another ghost on my enviroment...
i set up my vswitch to use port group, and give grant permission to guest
sles 11 Sp1..
all works okay, but if i give LOGOUT on machine, network not comes back,
until i give some network request FROM this machine.. this request can be a
ping for example...
instantly i give a ping, the nework wake up... anybody already see this
behavior ? any clue?
this behavior not happens if i give a simple reboot command :-/
here is my definitions of vswitch and port group:
00242 VMLAN MACPREF 026101
00243 MOD PORT GROUP GRPSRV01 JOIN 1D00.P0 1E00.P0
00244 DEFINE VSWITCH VSWSVC01 ETHERNET RDEV 0800.P0 GROUP GRPSRV01
00245
00246 MODIFY VSWITCH VSWSVC01 GRANT DB2P101
on linux, we are currentily using vlan
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: SLES 11 strange behavior network
On Wed, 2011-02-02 at 10:40 -0500, Alan Altmark wrote: The problem arises when you move a guest from one physical port to another before that forget timer pops. If the guest does not generate any traffic, inbound traffic will go to the wrong port. So, what should Linux do? When Linux brings an interface up, he's supposed to issue an unsolicited (gratuitous) ARP response. When operating in layer 3 mode (VSWITCH or OSA), CP or the OSA issues the grat ARP on your behalf. We have opened Novell bugzilla 617373 to address the problem of the missing unsolicited (gratuitous) ARP response in SLES11 SP1. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Hipersockets Not working z/Linux to z/VM z/OS
Kyle, please try to add line ARP=no to your /etc/sysconfig/network-scripts/ifcfg-hsi0 configuration file. Regards, Ursula -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Attach OSA express3 to a guest
Hi Berry, the kernel patch has been backported to SLES10 SP2. Regards, Ursula On Tue, 2010-07-27 at 22:16 +0200, Berry van Sleeuwen wrote: Hi Mark, At the IBM devworks (http://www.ibm.com/developerworks/linux/linux390/development_recommended.html) I found that four-port OSA is supported with a patch against kernel 2.6.25. We are running in SLES10 SP2 at level 2.6.16. So does our system support this option? Regards, Berry. Op 27-07-10 19:36, Mark Post schreef: On 7/27/2010 at 05:55 AM, van Sleeuwen, Berry berry.vansleeu...@atosorigin.com wrote: But how can we configure the linux guest to use port 1? Either in VM or in the linuxguest. Where can I find this in the documentation? On SLES 10 (SP2 and higher): yast - Network Devices - Network Card - Edit - Advanced - S/390 and set Port Number to 1. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: VSWITCH and QETH buffer_count parameter
On Wed, 2010-06-23 at 15:33 -0500, Ron Foster at Baldor-IS wrote: I know that if I am using hipersockets to communicate from a zLinux guest under zVM to a zOS LPAR, that I might be able to see improved performance if I increased the buffer_count from it's default of 16 to something higher. I have seen information indicating if I have a directly attached OSA adapter to communicate with other systems, that I might be able to improve performance by increasing buffer_count. But what about a zLinux guest, is there likely to be any performance improvement if I increase the buffer_count for a device attached to a VSWITCH? Ron, buffer_count determines the number of input buffers that the qeth driver shares with the (real or virtual) device. Every buffer is either controlled by Linux (when processing inbound data) or by the device (when providing inbound data). Initially Linux hands over control to the device for all available input buffers. The device fills (some of) them and notifies Linux. Now Linux controls these buffers, processes them, and returns control back to the device. The device can provide inbound data only, if it controls at least 1 input buffer. That means, increasing the buffer_count increases the probability that the device controls input buffers to provide inbound data. The maximum number of input buffers is 128. The only reason qeth chooses a default of 16 as buffer_count are memory-constrained systems. One buffer uses 64K of kernel memory. If your system is not memory-constrained and if the expected burst workload for your network connection is high, it makes always sense to increase buffer_count of a qeth device to 128. This applies to a VSWITCH-attached device as well. Regards, Ursula Braun, IBM Germany, Linux on System z development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: 2010-05-28 Linux on System z kernel 2.6.34 related updates on developerWorks
On Tue, 2010-06-15 at 12:00 -0500, Sterling James wrote: Does anyone have more information about the HiperSockets network traffic analyzer (HS NTA)that is refer to in the s390-tools 1.9.0? Its Linux announcement is contained in http://www.ibm.com/developerworks/linux/linux390/kernel-2.6.34.html . The corresponding Device Drivers book for 2.6.34 will be available on DeveloperWorks at the beginning of next week. This version will contain a subchapter on Setting up a HiperSockets network traffic analyzer. The latest z10-hardware offers the base support to implement a HiperSockets network traffic analyzer. The SE contains panels to configure authorization for the analyzing partition and the partitions to be analyzed. Regards, Ursula Braun, IBM Germany, Linux on System z development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Announcing Red Hat Enterprise Linux 6 beta
On Mon, 2010-04-26 at 21:10 +0200, Xose Vazquez Perez wrote: Brad Hinson bhin...@redhat.com wrote: Below is the announcement for RHEL 6 beta, released this past Wednesday. It's currently available on RHN (https://rhn.redhat.com). be careful, The CTC (channel-to-channel) and IUCV (inter-user communication vehicle) are deprecated and are not supported in Red Hat Enterprise Linux : http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/Installation_Guide/#s1-s390-steps-hardware to clarify: it is not IUCV that is deprecated in RHEL6, just the netiucv driver is deprecated. The base iucv-API and the af_iucv socket interface continues to be available. Regards, Ursula Braun (IBM Germany, Linux on System z development) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES11 - error when trying to compile snipl
On Thu, 2010-03-18 at 16:31 -0400, Bernie Wu wrote: Hi Ursula, A couple of questions: 1. After downloading the 3 tarballs from linux-ha.org, I'm not sure where to un-tar them to . Currently, I put them into /tmp, but I'm sure make doesn't know about /tmp. 2. I cut and pasted your email and put it into a file called patchfile and tried to apply it and this is what I got: # cd /tmp/snipl-0.2.1.7 # patch patchfile patching file Makefile patch: malformed patch at line 22: $(INCDIR) -I$(STONITHINCDIR) Am I missing something ? The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Bernie, it should not matter where you un-tar the downloaded tarballs. But they use different configuration commands. For Heartbeat you start with ConfigureMe configure, for the others with autogen.sh (followed by configure, make, make install). I am sending you the snipl Makefile patch in a separate file to avoid listserver wrapping. Regards, Ursula Braun -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES11 - error when trying to compile snipl
On Thu, 2010-03-18 at 08:04 -0400, Bernie Wu wrote: Mark, I picked up snipl-0.2.1.6.tar.gz from IBM's developerworks. The original make error : # make *** WARNING *** *** *** *** vmsmapi cannot be built without dmsvsma.x*** gcc -DUNIX=1 -DST_TEXTDOMAIN='stonith' -g -O2 -Wall -I. -I/usr/include -I/usr/include/stonith -o snipl -L. -L/usr/lib64 -lnsl -ldl -lsniplapi -lhwmcaapi -lconfig snipl.o prepare.o /bin/sh libtool --mode=compile gcc \ -DUNIX=1 -DST_TEXTDOMAIN='stonith' -g -O2 -Wall -I. -I/usr/include -I/usr/include/stonith -DLPAR_INCLUDED=1 `pkg-config --cflags glib-2.0` \ -c lic_vps.c -o lic_vps.lo libtool: compile: gcc -DUNIX=1 -DST_TEXTDOMAIN=\stonith\ -g -O2 -Wall -I. -I/usr/include -I/usr/include/stonith -DLPAR_INCLUDED=1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -c lic_vps.c -fPIC -DPIC -o .libs/lic_vps.o In file included from /usr/include/stonith/stonith.h:47, from ./snipl_stonith_plugin.h:31, from lic_vps.c:17: /usr/include/pils/plugin.h:24:27: error: glue_config.h: No such file or directory make: *** [lic_vps.lo] Error 1 Bernie, lic_vps is the snipl plugin for stonith/heartbeat. If you are just interested in snipl command line functionality, you can remove this part of the Makefile. If you are interested in stonith/heartbeat, there are 3 downloadable tar files on linux-ha.org: Heartbeat, Cluster Glue, and Resource Agents. Are all of them available on your system? Which versions? Regards, Ursula Braun IBM Germany Linux on System z development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES11 - error when trying to compile snipl
On Thu, 2010-03-18 at 12:02 -0300, Frank Pani wrote:
Hi - we have the very same issue.
We are interested in stonith/heartbeat and have the following Heartbeat,
Cluster Glue, and Resource Agents. We have download v3.0.2 for heartbeat.
For us, we are using RHEL v5.3 and because these components are not
available in binary form from the distributor we have compiled these
components ourselves with success.
Ursula, any direction on this would be grateful. Seems that simply a file
is just missing in the latest build. Thanks.
- Frank Pani
Frank,
looks like the snipl stonith part requires adaptions to the latest
download files on linux-ha.org.
After downloading these files to my system, I could compile snipl after
applying this patch to the snipl Makefile (see the new include directory
HEARTBEATINCDIR):
---
Makefile |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: src/Makefile
===
--- src.orig/Makefile
+++ src/Makefile
@@ -26,6 +26,7 @@ LIBDIR = ${PREFIX}/${LIB_STRING
STONITHLIBDIR = ${PREFIX}/${LIB_STRING}/stonith
INCDIR = ${PREFIX}/include
STONITHINCDIR = ${INCDIR}/stonith
+HEARTBEATINCDIR = ${INCDIR}/heartbeat
MANDIR = ${PREFIX}/share/man
LIB_LPAR=
LIB_VM =
@@ -38,7 +39,7 @@ OWNER = $(shell id -un)
GROUP = $(shell id -gn)
GLIB2_HEADERS = `pkg-config --cflags glib-2.0`
-CFLAGS += -DUNIX=1 -DST_TEXTDOMAIN='stonith' -g -O2 -Wall -I. -I
$(INCDIR) -I$(STONITHINCDIR)
+CFLAGS += -DUNIX=1 -DST_TEXTDOMAIN='stonith' -g -O2 -Wall -I. -I
$(INCDIR) -I$(STONITHINCDIR) -I$(HEARTBEATINCDIR)
all: all_config all_sniplapi all_vmsmapi all_snipl all_stonith
install: install_subdirs install_config install_sniplapi
install_vmsmapi install_snipl install_stonith
Regards, Ursula Braun
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Linux HA with RHEL and MySQL on System z
On Sat, 2010-03-13 at 09:18 -0500, Alan Altmark wrote: On Saturday, 03/13/2010 at 06:49 EST, Frank Pani fpa...@ca.ibm.com wrote: 1) Because the database will be 200-300GB, we can use LVM and have it available to mount RW on either system. We need to be very careful not to mount RW at the same time; else we risk destroying the data. In cases where customers are using VMWARE or Xen on distributed, you ensure this by using PaceMaker to tell the hypervisor to issue a STONITH to totally kill the primary machine. This ensures, that the filesystem will be RW only on the backup now. However! There is currently no capability on z/VM to allow PaceMaker (or any other software that I know of) to do this. For quite a while now we have had the System Management API (SMAPI). Write a program on Linux that uses SMAPI to stop the Linux guest. Have PaceMaker execute said program. Linux provides the snipl command (incl. a STONITH plugin) to kill a system (LPAR or z/VM guest). It is available with SLES10 / SLES11 or can be downloaded from: http://www.ibm.com/developerworks/linux/linux390/snipl.html Ursula Braun Linux on System z development IBM Boeblingen -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Location of network configuration
Berry, there is a known problem (race in udev) in activation of network interfaces. Details can be found in Novell-bugzilla number 506571. Regards, Ursula Braun, IBM Germany, Linux on System z development On Mon, 2010-02-15 at 11:55 +0100, van Sleeuwen, Berry wrote: Hello listers, We have two SLES10 guests running SAMBA. The two machines should be identical, and in VM they are. The production machine has two network interfaces defined, F00 and F10. The first is the network for regular connections, the second is the connection to our TSM backup server. The test machine can't start the connection for TSM backup. ifconfig shows only eth0. The f10 device is indeed available but for some reason it isn't started. I have compared the two guests but can't find a difference that could tell me why this networkinterface isn't started. The nic f10 is defined and coupled to the vswitch. The /etc/sysconfig/hardware contains identical entries. The /etc/sysconfig/network contains configuration for both f00 (eth0) and f10 (eth1). Other than the IP address these members are identical too. rcnetwork restart only starts lo and eth0. ifup eth1 shows interface eth1 is not available. How to get eth1 available? Is there any other location that defines a NIC that I can check? Met vriendelijke groet/With kind regards, Berry van Sleeuwen Flight Forum 3000 5657 EW Eindhoven ( +31 (0)6 22564276 Atos Origin http://www.atosorigin.com/ MO CF SC Mainframe Services -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: osa layer 2 setup in redhat ???
Andrew Avramenko stated: You can share one OSA Adapter between two systems and use different Layers for their networking, but they cannot communicate with each other, so be careful with that. This restriction applies only to old generations of OSA-cards. Current OSA Express2 and OSA Express3 cards allow communication between two systems using different layers. Kind regards, Ursula -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
[Fwd: Fw: qeth ipv6 dependency]
Justin, Problem still exists for qeth layer3 devices. If qeth layer2 devices are needed only, qeth can now be used without ipv6: Starting with 2.6.25 the qeth driver is splitted into 3 modules: a core module qeth, a layer2 module qeth_l2 and a layer3 module qeth_l3. The ipv6-dependency is isolated in the layer3 module qeth_l3. Module qeth_l3 will only be loaded, if qeth layer3 devices are activated. Regards, Ursula Braun, IBM Germany, Linux on System z development Forwarded Message From: Ursula Braun1 ursula.br...@de.ibm.com To: ubr...@linux.vnet.ibm.com Subject: Fw: qeth ipv6 dependency Date: Mon, 31 Aug 2009 14:01:07 +0200 From: Justin Payne jpa...@redhat.com To: LINUX-390@VM.MARIST.EDU Date: 27.08.2009 15:55 Subject: Re: qeth ipv6 dependency __ Was an alternative solution to this ever found? On 07/02/2007 02:47 AM, Ursula Braun1 wrote: Brad, since qeth supports layer3 devices, it is difficult to make qeth independent of ipv6. The best solution would be a kernel rebuild without ipv6 configured. There exists the SLES9 solution solving Novell Bugzilla 128561 you are pointing to. Unfortunately it is more a quick hack and thus more a circumvention than a real solution for the problem. Thus up to now there have been no efforts to port it to upstream or to another distribution. Nevertheless we are aware of this problem and we are going to investigate into alternative solutions. Best regards,Ursula Braun Brad Hinson bhin...@redhat.c om To Sent by: Linux on LINUX-390@VM.MARIST.EDU 390 Port cc linux-...@vm.mar IST.EDU Subject qeth ipv6 dependency 29.06.2007 21:42 Please respond to Linux on 390 Port linux-...@vm.mar IST.EDU A customer has a security policy that only allows ipv4, so they can't assign an ipv6 address to eth0, and can't have an ipv6 over ipv4 tunnel. Ideally, they'd like to remove the ipv6 kernel module altogether. In RHEL 4 and SLES 9, they were able to do this. In RHEL 5 and SLES 10, they're finding that dependencies don't allow them to do this. It appears there are too many hard linkages between qeth and ipv6. When they alias ipv6 off in modprobe.conf, they get messages like: qeth: Unknown symbol in6_dev_finish_destroy qeth: Unknown symbol addrconf_lock qeth: Unknown symbol unregister_inet6addr_notifier qeth: Unknown symbol ndisc_mc_map qeth: Unknown symbol register_inet6addr_notifier qeth: Unknown symbol in6_dev_finish_destroy qeth: Unknown symbol addrconf_lock qeth: Unknown symbol unregister_inet6addr_notifier qeth: Unknown symbol ndisc_mc_map qeth: Unknown symbol register_inet6addr_notifier qeth: Unknown symbol in6_dev_finish_destroy qeth: Unknown symbol addrconf_lock qeth: Unknown symbol unregister_inet6addr_notifier qeth: Unknown symbol ndisc_mc_map qeth: Unknown symbol register_inet6addr_notifier I found this link, so it seems someone has asked this question before: http://www.ibm.com/developerworks/linux/linux390/linux-2.6.5-s390-32-april2004.html Specifically, Problem-ID 19880: Description: qeth: customer wants qeth driver to be loaded and running without ipv6 module loaded prior to. Symptom: qeth module built with ipv6 support will not load when ipv6 module is not loaded. Problem: qeth driver is using basic ipv6 functions which are needed to register IPv6 IP addresses. These functions are not available when ipv6 module is not loaded. Solution: Use symbol_put/symbol_get and get function addresses when available and call them. Use wrapper functions then in qeth. - So the question is: Does anyone know when this change happened in the qeth code? i.e. What was the decision/feature in the module that necessitated this dependency? Was the patch in the link above ever proposed upstream? Thanks, -Brad -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: OSA/Express Assistance
Dave, after reboot your OSA interfaces can be 'dead', because 1. problem in OSA-device configuration 2. just a missing gateway After reboot invoke from the HMC-console lsqeth -p to check if OSA-devices are available and route to check if the default gateway is defined. And what is contained in /etc/sysconfig/network/route ? Ursula Ursula Braun, IBM Germany, Linux on System z development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: OSA/Express Assistance
Dave, you can try to setup a qeth device manually at your HMC console using these steps: 1. Check with lscss, if the subchannel triplet (0.0., 0.0.xxxy, 0.0.xxxz) of your OSA-device is available. 2. Define the ccwgroup device with: echo 0.0.,0.0.xxxy,0.0.xxxz /sys/bus/ccwgroup/drivers/qeth/group 3. Bring the device online: echo 1 /sys/bus/ccwgroup/devices/0.0./online 4. Activate the network interface: ifconfig eth0 ip.ad.dr.es netmask aa.bb.cc.dd Now you should be able to connect from your PC. Then you should check the SLES10 configuration files: /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0. /etc/sysconfig/network/ifcfg-qeth-bus-ccw-0.0. Regards, Ursula Ursula Braun, IBM Germany, Linux on System z development -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Layer 2 VSWITCH and SUSE 10 starter system problems
Realistically, is there a reason why ANY error code from an OSA should not issue a meaningful message? I mean, after all, you (IBM) control the error code set, and it's not like cryptic error messages are a virtue, even in the Unix world... David, I agree with you. But most of the error codes indicate programming errors, which should be reported to us. It is an ongoing effort for us to identify those real error codes, which are not caused by code problems, and to come up with a meaningful message for them (like the error code 0xf6 discussed in this thread). Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Layer 2 VSWITCH and SUSE 10 starter system problems
Mark, some comments on the qeth IDX terminate cause codes mentioned in this thread: 1. 0xf6 layer2/layer3 mismatch error short term solution: recent qeth patch to come up with a meaningful message discussed long term solution: let qeth choose the appropriate layer; Such a solution would require changes in Linux qeth driver and z/VM. 2. 0x04, 0x08, 0x17 If those error codes are seen with latest versions of Linux and z/VM, the problem should be reported. Otherwise upgrading service level may help. 3. 0x4e If you have a scenario to run into 0x4e, we should analyze this in detail. Regards, Ursula -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Layer 2 VSWITCH and SUSE 10 starter system problems
On 3/12/2009 at 3:37 PM, Alan Altmark alan_altm...@us.ibm.com wrote: On Thursday, 03/12/2009 at 02:40 EDT, Mark Post mp...@novell.com wrote: I get an IDX TERMINATE with cause code 0xf6, which I have read some of the archives that said that was a layer2/layer3 mismatch error. I'm pretty sure that would be a 0x4e error, since I just deliberately caused that mismatch on one of my test systems to check. - 0x4E means the adapter doesn't understand what the device driver told it. Either a bad primitive was sent or the operands are bad. This could be because you've configured Linux to speak OSA but you defined a HIPERS NIC. Cause code 0xf6 has been caught in qeth recently: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fc9c24603c4b93d84160e14c0a98a754d4328d15 I am going to discuss with z/VM development whether qeth should catch cause code 0x4e as well. Ursula Braun Linux on System z Development IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Fw: Help with network settings on z/Linux (fwd)
Eric, HiperSocket interfaces use already a high MTU-size as default. You can increase this value only by additional 4064 bytes. The default MTU-size depends on the CHPARM-value of your IQD CHPID definition. CHPARMmax. frame sizeMTU size = 00 (default) 16KB 8KB 40 24KB16KB 80 40KB32KB C0 64KB56KB Probably you are using a HiperSocket interface with CHPARM 00, while Terry is using CHPARM 40. Regards, Ursula Braun IBM Germany, Linux on System z development Forwarded Message Eric Hunter [EMAIL PROTECTED] Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU 29.08.2008 22:49 Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU To LINUX-390@VM.MARIST.EDU cc Subject Re: Help with network settings on z/Linux How do you set the MTU so high? I'm trying to play with super jumbo frames on a SLES10 guest under Z/VM and it doesnt appear to allow an MTU value larger than 12256: db1:~ # ifconfig hsi0 mtu 12257 SIOCSIFMTU: Invalid argument db1:~ # ifconfig hsi0 mtu 12256 db1:~ # ifconfig hsi0 mtu 16384 SIOCSIFMTU: Invalid argument What did you have to do to get yours to accept 16384? -Original Message- From: Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] To: LINUX-390@VM.MARIST.EDU Sent: Tue, 19 Aug 2008 12:01 pm Subject: Re: Help with network settings on z/Linux Hi Alan, I did some research based on your response I this is what I found: In my case the E3 (HiperSockets CHPID) with a CHPARM=40k is being used in the environment that is working. The E2 (HiperSockets CHPID) with a CHPARM=64k is being used in the environment that is NOT working. Can the difference in these sizes alone cause me the issue I am having? The MTU size for both HiperSockets is set to 16,348 across the board. Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Tuesday, August 19, 2008 11:10 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Help with network settings on z/Linux On Tuesday, 08/19/2008 at 10:41 EDT, Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] wrote: We have two environments that we are building as part of our POC. We ship data via DB2 Connect from the mainframe DB2 to a Linux guest via a HiperSockets Network. In our DEV environment all of our tables process without issue. In our VAL environment there are six tables that the SQL fails for. We have been engaged with IBM via a PMR on this and have been going back and forth. At this point it appears that the issue is with the number of rows. In the SQL when they do an SELECT * and do not specify the rows it works. When they specify the tables in the Select it apparently increases the size of the SQL and it never gets to the mainframe. It looks like it is a 2k buffer limitation somewhere. Is there anything in the TCP/IP stack in z/Linux or any network setting in z/Linux that would enforce this limitation? Verify that the MFS (CHPARM= or OS= in IOCP) and MTU for the HiperSockets connection are the same for your DEV and VAL environments. Alan Altmark z/VM Development IBM Endicott -- 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 -- End Forwarded Message -- -- 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
Re: VIPA and hot standby
Since there are discussions about heartbeat-stonith I want to call your attention to an IBM-provided tool called snIPL available on http://www10.software.ibm.com/developerworks/opensource/linux390/useful_add-ons_snipl.shtml. snIPL provides a heartbeat-stonith plugin to reset zLinux images running either natively in an LPAR or under VM. Best regards,Ursula Braun-Krahl IBM Germany, Linux for zSeries Dev. -- 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
