From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 20:48:07 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7E051065672; Wed, 21 Jul 2010 20:48:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id ABEA98FC17; Wed, 21 Jul 2010 20:48:07 +0000 (UTC) Received: by pvh1 with SMTP id 1so3217070pvh.13 for ; Wed, 21 Jul 2010 13:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Dhses1smW2EyMvHCt4pFEtx9apGVpwssadL7KM9uoYA=; b=OyXweEQocLEpG9AtDXdQTEURfLWYvdbYORZZO8oD9afXBOCUKxN+31Vn/RzfGbOrnx Vbcxrn9Y6gl717MY/FWHZJzIf88d3E+A+qqLUJ3q6m+vB7mPgLguBpU/N9JH94P/Oxm8 ObEt2978+M2rINPlfadQ+x80dCbliYYMXAFXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ApU6dvv0p1naDVs2qwF8vY6LLkL4e18R7V/V+QNU59o0QB+v+5k/qSQ/fgZPmWzCK/ dceySN+vC6OhzAl1siKoXlRxz2xfSXqv3uiWMmcb+FIoPV8S31fqg0OyQS0bsWf7Z7Os +P0x4AxTq7FQOLVpYle7jQBtLvUsRylMIJS9E= Received: by 10.142.216.21 with SMTP id o21mr869890wfg.153.1279745284905; Wed, 21 Jul 2010 13:48:04 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w8sm9496607wfd.7.2010.07.21.13.48.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 13:48:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 21 Jul 2010 13:47:15 -0700 From: Pyun YongHyeon Date: Wed, 21 Jul 2010 13:47:15 -0700 To: Kurt Jaeger Message-ID: <20100721204715.GC10798@michelle.cdnetworks.com> References: <201007202234.o6KMY7oV031115@freefall.freebsd.org> <20100721062945.GA51934@home.opsec.eu> <20100721063234.GB51934@home.opsec.eu> <20100721170201.GA10798@michelle.cdnetworks.com> <20100721170605.GG51934@home.opsec.eu> <20100721181846.GB10798@michelle.cdnetworks.com> <20100721200332.GH51934@home.opsec.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100721200332.GH51934@home.opsec.eu> User-Agent: Mutt/1.4.2.3i Cc: fbsd-pr@opsec.eu, freebsd-net@FreeBSD.org, yongari@FreeBSD.org Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 20:48:08 -0000 On Wed, Jul 21, 2010 at 10:03:32PM +0200, Kurt Jaeger wrote: > Hi! > > > > http://opsec.eu/backup/alc-bug/dmesg.boot-verbose > > > One odd thing is alc(4) failed to read station address from EEPROM. > > So alc(4) assumed BIOS correctly programmed station address but the > > station address looks wrong to me. > > > How about cold booting? Does other OS also report the same station > > address? > > I have no other OS at hand right now 8-} > > > > with the patch applied (and booted with a cable). > > > > > > Before the patch: > > > > > > http://opsec.eu/backup/alc-bug/dmesg.boot > > > > > > > Would you try this one? > > http://people.freebsd.org/~yongari/alc/alc.link.patch2 > > It works better, does not hang during boot. > > Next: add break-to-debugger 8-( > > > > Thanks! If you need remote access... > > > > That does not work mainly because I can't unplug/plug UTP cable > > through remote access. > > must.work.on.telekinetic.power 8-) > > Now, this is going somewhere, as follows: > > 1) > reboot with unplugged cable, then some ifconfig alc0 up/down, then: > I ping'ed on the alc0 host and tcpdump on the other host sees some traffic > (this failed in the past): > > 21:19:59.983843 48:5b:39:73:03:4f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.5.11 tell 192.168.5.10 > 21:19:59.983855 00:e0:18:fc:7f:00 > 48:5b:39:73:03:4f, ethertype ARP (0x0806), length 42: arp reply 192.168.5.11 is-at 00:e0:18:fc:7f:00 > > But: apparently the alc0 does not receive the answer, and so it > fails to register the arp. > > Hmm. > > 2) reboot with cable plugged in: ping etc works immediatly. > > 3) shutdown and reboot: > > ifconfig alc0 says: > > alc0: flags=8802 metric 0 mtu 1500 > options=c3198 > ether 48:5b:39:73:03:4f > media: Ethernet autoselect > > then: > > ndog# ifconfig alc0 192.168.5.10 > ndog# ifconfig alc0 > alc0: flags=8843 metric 0 mtu 1500 > options=c3198 > ether 48:5b:39:73:03:4f > inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 > media: Ethernet autoselect (none ) > status: no carrier > > then after a few seconds the netbook just hung 8-( > > 4) shutdown and reboot from cold, unplugged cable: > > - started tcpdump on alc0 > - plugged in cable > - ifconfig alc0 192.168.5.10 > > whow, it works. > > I then unplugged, replugged etc. Looks stable now. Did some ipv6 over > it. Rebooted with this as the primary interface. Works fine. > > Cool. Thank you very much. > Ok, it seems it shows some mixed result. It's possible that warm boot may not clear some power related configuration of system which could be incorrectly programmed with stock alc(4). So start testing from cold booting with/without UTP cable and see whether alc(4) can establish a valid link with link partner. You should never see "" media. If that works as expected, test warm booting with/without UTP cable.