From owner-freebsd-questions@FreeBSD.ORG Fri Aug 10 10:39:40 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A5EE106566B for ; Fri, 10 Aug 2012 10:39:40 +0000 (UTC) (envelope-from kuku@kukulies.org) Received: from kukulies.org (mail.kukulies.org [78.47.239.221]) by mx1.freebsd.org (Postfix) with ESMTP id 00AA68FC12 for ; Fri, 10 Aug 2012 10:39:39 +0000 (UTC) Received: by kukulies.org (Postfix, from userid 5001) id 0C15C1AD860; Fri, 10 Aug 2012 12:39:39 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on kukulies.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED autolearn=ham version=3.3.2 Received: from [172.27.4.215] (unknown [87.79.34.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kukulies.org (Postfix) with ESMTPSA id 2D76E1AD85F for ; Fri, 10 Aug 2012 12:39:38 +0200 (CEST) Message-ID: <5024E4E8.3010606@kukulies.org> Date: Fri, 10 Aug 2012 12:39:36 +0200 From: "Christoph P.U. Kukulies" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <5024D442.6090707@kukulies.org> <5024D715.9030409@kukulies.org> In-Reply-To: <5024D715.9030409@kukulies.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: weird problem with 9.0 Release and ed0 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 10:39:40 -0000 Am 10.08.2012 11:40, schrieb Christoph P.U. Kukulies: > Am 10.08.2012 11:28, schrieb Christoph P.U. Kukulies: >> The problem need not to be confined to 9.0. It stated to develop >> under 5.1 already. > read: started to develop... >> >> I'm running a natd gateway machine that was developing strange >> behaviour such that the >> outside interface (ed0, BNC connector) that was connected via a small >> media converter switch to >> the providers sync line had dropouts. The machine couldn't ping into >> the Internet and also couldn't be pinged. >> >> I first thought it was the switch/media converter, but another >> (Windows XP) machine that was on the >> same BNC cable worked flawlessly. >> >> So I decided to migrate that 5.1 machine to a 9.0 machine. The >> situation now is that I have the9.0 machine >> at the BNC cable and simultanously the old FreeBSD 5.1 gateway on the >> same BNC cable but through a >> TP adapter. This was the old machine works fine and I can care about >> the new machine. >> >> Is there a known problem with ed0 cards that have the Realtek 8029 >> chipset. Do they need some >> special flags like memory mapping or irq? >> >> When I for example boot the 9.0 machine the comping up of the em0 (on >> mainboard interface results in a highlighted >> kernel message on the console. The coming up of the ed0 is not >> flagged this way. And as a result the >> ed0 interface seems to be dead. >> >> >> Here some excerpts of dmesg: >> em0: port 0x4400-0x441f >> mem 0x93100000-0x9311ffff,0x93124000-0x93124fff irq 20 at device 25.0 >> on pci0 >> em0: Using an MSI interrupt >> em0: Ethernet address: 00:1c:c0:37:b2:9f >> >> ed0: port 0x1000-0x101f irq 22 at device 1.0 on pci7 >> ed0: Ethernet address: 00:e0:7d:7c:2b:4a >> >> I also see this: >> Jul 30 23:03:54 forum ntpd[1711]: unable to create socket on ed0 (20) >> for fe80:: >> 2e0:7dff:fe7c:2b4a#123 > > Forgot to add this info: > > ed0: flags=8843 metric 0 mtu 1500 > ether 00:e0:7d:7c:2b:4a > inet 80.72.44.230 netmask 0xfffffff0 broadcast 80.72.44.239 > inet6 fe80::2e0:7dff:fe7c:2b4a%ed0 prefixlen 64 scopeid 0xa > nd6 options=29 > media: Ethernet autoselect (10base2/BNC) > Must add some more info: My kernel config: cpu I486_CPU cpu I586_CPU cpu I686_CPU ident DIVERT makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT (the rest like in GENERIC). Strange thing: I cannot ping neither the outside interface address nor the inside (172.27.2.115) -- Christoph Kukulies