Date: Wed, 21 Jul 2010 13:47:15 -0700 From: Pyun YongHyeon <pyunyh@gmail.com> To: Kurt Jaeger <pi@opsec.eu> 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 Message-ID: <20100721204715.GC10798@michelle.cdnetworks.com> In-Reply-To: <20100721200332.GH51934@home.opsec.eu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=c3198<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE> > ether 48:5b:39:73:03:4f > media: Ethernet autoselect > > then: > > ndog# ifconfig alc0 192.168.5.10 > ndog# ifconfig alc0 > alc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > options=c3198<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE> > ether 48:5b:39:73:03:4f > inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 > media: Ethernet autoselect (none <hw-loopback>) > 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 "<hw-loopback>" media. If that works as expected, test warm booting with/without UTP cable.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100721204715.GC10798>