From owner-freebsd-net@FreeBSD.ORG Tue Sep 30 09:35:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A73E93E6 for ; Tue, 30 Sep 2014 09:35:13 +0000 (UTC) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id 6A02BBED for ; Tue, 30 Sep 2014 09:35:13 +0000 (UTC) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id 5312E14148A0 for ; Tue, 30 Sep 2014 11:34:51 +0200 (CEST) Received: from asbach.renzel.net (unknown [10.2.0.7]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id 82A9A98724 for ; Tue, 30 Sep 2014 11:35:03 +0200 (CEST) Content-Type: text/plain; charset="ISO-8859-1" From: Nils Beyer Organization: VKF Renzel GmbH Date: Tue, 30 Sep 2014 11:35:03 +0200 User-Agent: KNode/4.12.5 Content-Transfer-Encoding: 7Bit Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support To: freebsd-net@freebsd.org References: <20140930015741.GA2451@michelle.fasterthan.com> <20140930082053.4D9EFF8F@hub.freebsd.org> <20140930085228.GB969@michelle.fasterthan.com> Lines: 59 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98 at nijmegen.renzel.net X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=7.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 09:35:13 -0000 Hi, Yonghyeon PYUN wrote: >> Then I've connected a network cable and rebooted. I've got a link and >> performed an "iperf" test. The results are really good: around 930 Mbit/s >> TX and 840 Mbit/s RX. CPU load during that test: "70.75% kernel{alc0 >> taskq}". > > Hmm, the RX performance number looks bad to me. You have to see > more than 920Mbps. You're right; my fault - sorry for that. The "iperf partner" seems to have a bad/weak NIC because it also only gets 840 Mbit/s sending to another computer. So I've exchanged the "iperf partner" with another computer and am getting now 935 Mbit/s in both directions. I should always measure measuring equipment before measuring. > Could you show me the output of "pciconf -lcbv"? Probably not neccessary anymore, but here you are (with additional -e option): ------------------------------------------------------------------------------- #pciconf -lcbve | tail -20 alc0@pci0:2:0:0: class=0x020000 card=0x05621028 chip=0x10911969 rev=0x10 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR8161 Gigabit Ethernet' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xd0400000, size 262144, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 128, enabled cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) cap 05[c0] = MSI supports 16 messages, 64 bit, vector masks cap 11[d8] = MSI-X supports 16 messages, enabled Table in map 0x10[0x2000], PBA in map 0x10[0x3000] ecap 0001[100] = AER 1 0 fatal 1 non-fatal 1 corrected ecap 0003[180] = Serial 1 ff55c9fb5cf9ddff PCI-e errors = Correctable Error Detected Non-Fatal Error Detected Unsupported Request Detected Non-fatal = Unsupported Request Corrected = Bad DLLP ------------------------------------------------------------------------------- > I thought I verified link lost condition before requesting test. > After reading your mail, I was successfully reproduce it with > engineering sample board. It seems when link lost time lasts long > enough alc(4) fails to re-establish a link. Confirmed - if the network cable is disconnected long enough I cannot get a link either. As a workaround I un- and reload the "if_alc" module; then everything is working again as before... Regards, Nils