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 +0000, 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 +0000, 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 +0000, Ron Foster wrote: > > > Carsten, > > > Do you know where I would start looking for causes of the transmit errors > > > on Hipersockets? > > > The error is occurring on SLES11 SP2 systems. We are not having it on > > > our SLES10 SP4 systems. > > > Do I need to open a problem with the SuSe folks? > > > > > > Thanks, > > > Ron Foster > > > Baldor Electric Company > > > 5711 R S Boreham Jr Street > > > Fort Smith, AR 72901 > > > > ________________________________ > > > > The information contained in this e-mail message is intended only for the > > personal and confidential use of the designated recipient(s) named above. > > This message may be an attorney-client or work product communication which > > is privileged and confidential. It may also contain protected health > > information that is protected by federal law. If you have received this > > communication in error, please notify us immediately by telephone and > > destroy (shred) the original message and all attachments. Any review, > > dissemination, distribution or copying of this message by any person other > > than the intended recipient(s) or their authorized agents is strictly > > prohibited. Thank you. > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://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/
