Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Jul 2010 22:03:32 +0200
From:      Kurt Jaeger <pi@opsec.eu>
To:        Pyun YongHyeon <pyunyh@gmail.com>
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:  <20100721200332.GH51934@home.opsec.eu>
In-Reply-To: <20100721181846.GB10798@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
pi@opsec.eu            +49 171 3101372                        10 years to go !



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100721200332.GH51934>