From owner-freebsd-stable@FreeBSD.ORG Fri Jul 7 00:59:59 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96F4816A4DD for ; Fri, 7 Jul 2006 00:59:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF2C143D46 for ; Fri, 7 Jul 2006 00:59:58 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so1123464nzi for ; Thu, 06 Jul 2006 17:59:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=VaDth/DLhXjBuS7wsBqgE8jXWCcAnhEE4Eck/LLXG5QSQ+c7sR06NhjEAz2yXQRc90yNCG1pDEh17xRnZqSMKl8O3b3O0MX0NfT/nRXeyH/QnkWDoRI35/Eq/WX2WxiCa0VRWnEZPMjMSmSgILX3Fo+B7adNJnQw79ZKNBUmflk= Received: by 10.36.127.4 with SMTP id z4mr1771532nzc; Thu, 06 Jul 2006 17:59:58 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 19sm16845359nzp.2006.07.06.17.59.55; Thu, 06 Jul 2006 17:59:57 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k6713hO6083809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jul 2006 10:03:43 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k6713fsK083808; Fri, 7 Jul 2006 10:03:41 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 7 Jul 2006 10:03:41 +0900 From: Pyun YongHyeon To: Atanas Message-ID: <20060707010341.GD82406@cdnetworks.co.kr> References: <44A3817F.4030105@thebeastie.org> <20060629092154.GE742@turion.vk2pj.dyndns.org> <20060629083130.X1229@ganymede.hub.org> <44A4A02A.9060802@thebeastie.org> <20060630012615.Q1103@ganymede.hub.org> <44A57B71.6020201@asd.aplus.net> <20060701035416.GC54876@cdnetworks.co.kr> <44AC6793.2070608@asd.aplus.net> <20060706021444.GA76865@cdnetworks.co.kr> <44AD7297.7080605@asd.aplus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AD7297.7080605@asd.aplus.net> User-Agent: Mutt/1.4.2.1i Cc: Peter Jeremy , freebsd-stable@freebsd.org, Michael Vince , User Freebsd Subject: Re: em device hangs on ifconfig alias ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2006 00:59:59 -0000 On Thu, Jul 06, 2006 at 01:29:11PM -0700, Atanas wrote: > Pyun YongHyeon said the following on 7/5/06 7:14 PM: > > > >Here is patch generated against RELENG_6. > > > OK, I just tested that, but it doesn't seem to make any difference. > > Here's what I did: > > I commented out the em device from my kernel (a 6-STABLE one from > yesterday) and compiled three if_em kernel modules: > - one taken from 6.1 release > - the unpatched 6-STABLE one > - the latter with the above patch applied > > So I was able to load and test each of these modules independently and > without actually restarting the machine. I changed also the driver > version string in if_em.c, just to ensure that I'm really loading the > right em module by checking dmesg: > > em1: > port 0xdc80-0xdcbf mem 0xfcfe0000-0xfcffffff irq 55 at device 4.1 on pci3 > em1: Ethernet address: 00:04:23:b5:1b:ff > em1: link state changed to UP > > I used 2 machines - one running 6.1-RELEASE and using fxp (I'll call it > "FXP"), and the test one running 6-STABLE with em (I'll call it "EM"), > and tried exchanging/moving an IP alias between them. > > FXP# ifconfig > fxp0: flags=8843 mtu 1500 > options=b > inet 10.10.64.30 netmask 0xffffff00 broadcast 10.10.64.255 > ether 00:e0:81:31:f4:1e > media: Ethernet autoselect (100baseTX ) > status: active > > EM# ifconfig > em1: flags=8843 mtu 1500 > options=b > inet 10.10.64.63 netmask 0xffffff00 broadcast 10.10.64.255 > ether 00:04:23:b5:1b:ff > media: Ethernet autoselect (100baseTX ) > status: active > > First I brought up an IP alias on the FXP machine: > > FXP# ifconfig fxp0 inet alias 10.10.64.40 netmask 255.255.255.255 > > and checked whether it's accessible from anywhere - yes. Then I moved > that to EM: > > FXP# ifconfig fxp0 inet -alias 10.10.64.40 > EM# ifconfig em1 inet alias 10.10.64.40 netmask 255.255.255.255 > > and checked again - no. It was accessible only from its own subnet > (10.10.64.x), but not from anywhere else. > > Moving that back to FXP works, but moving it back to EM doesn't. The > only way I found to make it accessible was to arping something from the > aliased IP address: > > EM# arping -S10.10.64.40 -c1 somehost > > So it seems that when an IP alias has been recently used on some other > machine (on FXP in my case), the em driver is unable to initialize that > IP alias properly. > > It might be that the fxp driver is not sending something when releasing > an alias, who knows. But fact is that fxp always initializes its aliases > properly - I use it extensively and it always worked. > > I tried setting another IP alias that never has been used on these > machines. I brought that up first on EM and it worked. The moved it to > FXP and it also worked! But moving it back to EM made it inaccessible. > Hmm, that's strange. I've double checked that stock em(4) didn't generate ARP packets when its addresses were changed. So I made em(4) generate ARP. Could you see a gratuitous ARP with tcpdump when you change its address? > It looks like there's something fishy with the alias initialization. > > Another related problem is that the card gets re-initialized (reset?) on > each alias you add (takes between 0.3 and 1 seconds, depending how fast > the hardware is), which for mass aliased systems could be a serious > hurdle after a crash or reboot. > This is other issue. em(4) performs two time-consuming operations in its initialization routine. One is DMA tag/map creation and the other is checksumming EEPROM contents in init routine. I have an experimental patch for it but let's fix one at a time. -- Regards, Pyun YongHyeon