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 > To:LINUX-390@VM.MARIST.EDU, > Date:08/03/2016 21:55 > Subject:Re: Ethernet on VSwitch > Sent by:Linux on 390 Port > >>> On 3/8/2016 at 02:09 PM, "Frank M. Ramaekers" > 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" , Ursula Braun1/Germany/IBM@IBMDE, > > Cc: "Linux on 390 Port" > > Date: 17/06/2015 09:25 > > Subject: Re: SUSE12 Gold image on VM > > > > "Mark Post" wrote on 06/16/2015 04:53:29 PM: > > > > > From: "Mark Post" > > > To: "Linux on 390 Port" , > > > Date: 06/16/2015 04:53 PM > > > Subject: Re: SUSE12 Gold image on VM > > > > > > >>> On 6/16/2015 at 09:55 AM, Alan Altmark > wrote: > > > > On Tuesday, 06/16/2015 at 12:50 EDT, Mark Post > wrote: > > > >> >>> On 6/15/2015 at 11:54 PM, Alan Altmark > > > > > 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.com<mailto: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. > > -
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, 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
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
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
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: 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: 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 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: 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 eth 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 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 eth". 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: 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: 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 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: mac address problem
On Mon, 2012-05-21 at 06:41 -0500, David Boyes wrote: > On 5/21/12 4:11 AM, "Ursula Braun" 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 > > > 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/ > > > *** > > (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 th
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
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
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, 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
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, 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: 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..done<6>device-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: 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
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: 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-eth. 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: 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" > > > 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 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 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: 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: 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 > 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 > To: ubr...@linux.vnet.ibm.com > Subject: Fw: qeth ipv6 dependency > Date: Mon, 31 Aug 2009 14:01:07 +0200 > > From: > Justin Payne > 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 > >> om> > To > > Sent by: Linux on LINUX-390@VM.MARIST.EDU > > 390 Port > cc > >> IST.EDU> > Subject > > qeth ipv6 dependency > > > > 29.06.2007 21:42 > > > > > > Please respond to > > Linux on 390 Port > >> 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 netmask 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 wrote: > On Thursday, 03/12/2009 at 02:40 EDT, Mark Post 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 29.08.2008 22:49 Please respond to Linux on 390 Port 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
Re: zipl boot menu
Mark, insert the lines [defaultboot] defaultmenu=menu1 into your /etc/zipl.conf Ursula Braun-Krahl, IBM Germany -- 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
