From owner-freebsd-current@FreeBSD.ORG Sun Nov 11 19:41:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6FA216A418 for ; Sun, 11 Nov 2007 19:41:29 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.org [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 70F0913C4B9 for ; Sun, 11 Nov 2007 19:41:29 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:62957 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IrIgI-000FNf-5I for freebsd-current@freebsd.org; Sun, 11 Nov 2007 19:41:18 +0000 Message-ID: <47375ADD.2020001@conducive.net> Date: Sun, 11 Nov 2007 19:41:17 +0000 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <507457093.20071111190706@rulez.sk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Reproducible problems with re(4) on RELENG_7 and HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 19:41:29 -0000 Aryeh Friedman wrote: >> Disconnecting: Corrupted MAC on input. > > I have not seen any error messages but your description sound > identical to something happening on the same hardware to me (p35, > e6850).... Daniel: does this happen to be a MSI Neo-F Mobo? > >> Ok, these were the symptones, now the device in the question: >> >> I suppose that it is an integrated card (the machine is in >> collocation and I've never seen it by myself). This is the >> respective line from dmesg: >> >> re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff irq 19 at device 0.0 on pci2 >> >> pciconf -lv output: >> >> re0@pci0:2:0:0: class=0x020000 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00 >> vendor = 'Realtek Semiconductor' >> device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' >> class = network >> subclass = ethernet > > re0: port 0xe800-0xe8ff mem > 0xfcfff000-0xfcffffff irq 17 at device 0.0 on pci4 > re0: Using 2 MSI messages > miibus0: on re0 > > re0@pci0:4:0:0: class=0x020000 card=0x360c1462 chip=0x816810ec rev=0x01 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > ======== Ok - here's what may be a slightly earlier rev on a Gigabyte GA G33-DS3R: re0: port 0xc000-0xc0ff mem 0xf1000000-0xf1000fff irq 16 at device 0.0 on pci3 re0: Using 2 MSI messages miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1a:4d:4e:22:e8 re0: [FILTER] re0: [FILTER] ======= re0@pci0:3:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet ======= OS build: FreeBSD chameleon.triligon.to 7.0-BETA1 FreeBSD 7.0-BETA1 #0: Sat Oct 20 22:37:19 UTC 2007 root@chameleon.triligon.local:/usr/obj/usr/src/sys/WBH_ULE i386 Core-2 Quad 2.6 GHz, 2 GB DDR-800. Supporting a Win 'server' with IIS 6.0 inside a Qemu container. - We were hunting a Squid conf problem before switching to varnishd, (thanks phk@!), so ran some largish tcpdump -i to files and perused same. Problem was not with the NIC. *So far* - this one hasn't set a foot wrong with: - multiple, often long-running (days) ssh sessions - squid & varnish accelerators - multiple GB per file qcow2 .img backups .. on either the re Gig-E (above), or the add-on fxp0 10/100. Interested in the outcome, as this one is in 'production' now. - Might the issue be external to the box (cables, routers, network)? - Does a long-running 'ping' show packet loss? - Have you run tcpdump -i re0 >> {some.file} and looked at what it shows around the time of the aberrant behaviour? Bill