From pi@ndog.opsec.eu  Mon Jul 19 19:57:35 2010
Return-Path: <pi@ndog.opsec.eu>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 968D4106566B
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 19 Jul 2010 19:57:35 +0000 (UTC)
	(envelope-from pi@ndog.opsec.eu)
Received: from ndog.opsec.eu (unknown [IPv6:2001:14f8:200::c])
	by mx1.freebsd.org (Postfix) with ESMTP id 4F2388FC1A
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 19 Jul 2010 19:57:34 +0000 (UTC)
Received: from ndog.opsec.eu (localhost [127.0.0.1])
	by ndog.opsec.eu (8.14.4/8.14.4) with ESMTP id o6JJvXY9001774
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 19 Jul 2010 21:57:33 +0200 (CEST)
	(envelope-from pi@ndog.opsec.eu)
Received: (from root@localhost)
	by ndog.opsec.eu (8.14.4/8.14.4/Submit) id o6JJvXZx001773;
	Mon, 19 Jul 2010 21:57:33 +0200 (CEST)
	(envelope-from pi)
Message-Id: <201007191957.o6JJvXZx001773@ndog.opsec.eu>
Date: Mon, 19 Jul 2010 21:57:33 +0200 (CEST)
From: Kurt Jaeger <fbsd-pr@opsec.eu>
Reply-To: Kurt Jaeger <fbsd-pr@opsec.eu>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: alc0 does not send/receive packets if not plugged in during boot
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         148772
>Category:       kern
>Synopsis:       [alc] alc0 does not send/receive packets if not plugged in during boot
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 19 20:00:03 UTC 2010
>Closed-Date:    Tue Aug 30 19:03:32 UTC 2011
>Last-Modified:  Tue Aug 30 19:03:32 UTC 2011
>Originator:     Kurt Jaeger
>Release:        FreeBSD 8.1-RC2-p1 i386
>Organization:
-
>Environment:
System: FreeBSD ndog.opsec.eu 8.1-RC2-p1 FreeBSD 8.1-RC2-p1 #0: Mon Jul 12 23:02:47 UTC 2010 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386

Hardware is Asus EEEPC 1015PE.

>Description:
	o interface alc0 (full dmesg etc see below) works fine,
	  if the ethernet cable is plugged in during boot.
	o if the cable is not plugged in, no combination
	  of "ifconfig alc0 down, up, <ip-assigment>, etc.
	  brings it back to work.

For full details (verbose dmesg, pciconf, ifconfig -a, dmidecode) see:
http://opsec.eu/backup/alc-bug/

>How-To-Repeat:
	a) boot with cable plugged in, everything works -- unplug/replug,
 	   it still works.
        b) boot without cable plugged in, it can not be made to work.
>Fix:

	No fix available.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Jul 19 20:00:38 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 

From: Kurt Jaeger <fbsd-pr@opsec.eu>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc:  
Subject: Re: kern/148772: alc0 does not send/receive packets if not plugged
 in during boot
Date: Mon, 19 Jul 2010 22:05:23 +0200

 Hi!
 
 > >Synopsis:       alc0 does not send/receive packets if not plugged in during boot
 
 One thing: I can provide remote access to the system in question
 and to one beside it that shares the same ethernet.
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Tue Jul 20 22:32:06 UTC 2010 
State-Changed-Why:  
Would you try the patch at the following URL and let me know 
whether it makes any difference? 
http://people.freebsd.org/~yongari/alc/alc.link.patch 


Responsible-Changed-From-To: freebsd-net->yongari 
Responsible-Changed-By: yongari 
Responsible-Changed-When: Tue Jul 20 22:32:06 UTC 2010 
Responsible-Changed-Why:  
Mine. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@FreeBSD.org, FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Sun, 8 Aug 2010 20:26:40 +0200

 Hi!
 
 > > > It works better, does not hang during boot.
 [...]
 > > 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.
 
 I found a little more time to do debugging.
 
 With the patch, the system now works if a cable is plugged in after
 the boot, and an IP is configured afterwards.
 
 But:
 
 a) Booting it without a cable plugged in, with
 
 ipv6_enable="YES"
 
 in /etc/rc.conf and some
 
 ifconfig alc0 inet6 2001:14f8:0200:0000:0000:0000:0000:xxxx prefixlen 64 alias
 
 in /etc/rc.local
 
 but no IPv4 config will hang the system a few seconds after login: appears.
 
 b) Same problem with some IPv4 config only. So it's still sensitive.
 
 I added kernel debugging options, but break-to-debugger (ctrl-alt-esc)
 does not work.
 
 c) There are sometimes panic messages during shutdown, sometimes
 (after the filesystems are unmounted). See
 http://opsec.eu/backup/eeepc-crash.jpg
 
 I'm not sure they are related.
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Sun, 8 Aug 2010 14:16:13 -0700

 On Sun, Aug 08, 2010 at 08:26:40PM +0200, Kurt Jaeger wrote:
 > Hi!
 > 
 > > > > It works better, does not hang during boot.
 > [...]
 > > > 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.
 > 
 > I found a little more time to do debugging.
 > 
 > With the patch, the system now works if a cable is plugged in after
 > the boot, and an IP is configured afterwards.
 > 
 > But:
 > 
 > a) Booting it without a cable plugged in, with
 > 
 > ipv6_enable="YES"
 > 
 > in /etc/rc.conf and some
 > 
 > ifconfig alc0 inet6 2001:14f8:0200:0000:0000:0000:0000:xxxx prefixlen 64 alias
 > 
 > in /etc/rc.local
 > 
 > but no IPv4 config will hang the system a few seconds after login: appears.
 > 
 > b) Same problem with some IPv4 config only. So it's still sensitive.
 > 
 
 Because I can't reproduce this on both AR8131 and AR8132 sample
 boards it's hard to guess what's happening here. Anyway, here is
 updated alc(4) which may affect AR8131/AR8132 behavior. Would you
 give it try and let me know whether it makes any difference?
 
 http://people.freebsd.org/~yongari/alc/if_alc.c
 http://people.freebsd.org/~yongari/alc/if_alcreg.h
 http://people.freebsd.org/~yongari/alc/if_alcvar.h
 Make sure to save your stock alc(4) before overwriting it with files
 above.
 
 > I added kernel debugging options, but break-to-debugger (ctrl-alt-esc)
 > does not work.
 > 
 > c) There are sometimes panic messages during shutdown, sometimes
 > (after the filesystems are unmounted). See
 > http://opsec.eu/backup/eeepc-crash.jpg
 > 
 > I'm not sure they are related.
 
 It's hard to say the panic is related with alc(4) or not. At least
 you should show back trace information to narrow down the issue.

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Mon, 9 Aug 2010 21:46:48 +0200

 Hi!
 
 > > b) Same problem with some IPv4 config only. So it's still sensitive.
 > 
 > Because I can't reproduce this on both AR8131 and AR8132 sample
 > boards it's hard to guess what's happening here.
 
 Would it help you, if I plug in an USB ethernet device,
 unplug the alc0 and provide you remote access to the system via the
 USB ethernet ?
 
 > Anyway, here is
 > updated alc(4) which may affect AR8131/AR8132 behavior. Would you
 > give it try and let me know whether it makes any difference?
 
 I tried:
 
 - shutdown -p and reboot with ethernet plugged in, then ifconfig alc0
   after boot: works.
 - shutdown -p and reboot with ethernet unplugged, then ifconfig alc0
   after boot: does not work after plugging in the cable.
   (no packets on the wire)
 - shutdown -p and reboot with ethernet unplugged, with config in /etc/rc.conf:
   solid hang after cable is plugged in.
   ctrl-alt-esc does not work.
 
 So, no improvement, as far as I can see.
 
 > > c) There are sometimes panic messages during shutdown, sometimes
 > > (after the filesystems are unmounted). See
 > > http://opsec.eu/backup/eeepc-crash.jpg
 > > 
 > > I'm not sure they are related.
 > 
 > It's hard to say the panic is related with alc(4) or not. At least
 > you should show back trace information to narrow down the issue.
 
 Basically, the panic is after the kernel did almost all shutdown
 stuff, so there's no disc drive mounted any more etc.
 
 I was lucky with the picture, normally, it would reboot at that
 stage.
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Mon, 9 Aug 2010 15:08:01 -0700

 On Mon, Aug 09, 2010 at 09:46:48PM +0200, Kurt Jaeger wrote:
 > Hi!
 > 
 > > > b) Same problem with some IPv4 config only. So it's still sensitive.
 > > 
 > > Because I can't reproduce this on both AR8131 and AR8132 sample
 > > boards it's hard to guess what's happening here.
 > 
 > Would it help you, if I plug in an USB ethernet device,
 > unplug the alc0 and provide you remote access to the system via the
 > USB ethernet ?
 > 
 > > Anyway, here is
 > > updated alc(4) which may affect AR8131/AR8132 behavior. Would you
 > > give it try and let me know whether it makes any difference?
 > 
 > I tried:
 > 
 > - shutdown -p and reboot with ethernet plugged in, then ifconfig alc0
 >   after boot: works.
 > - shutdown -p and reboot with ethernet unplugged, then ifconfig alc0
 >   after boot: does not work after plugging in the cable.
 >   (no packets on the wire)
 > - shutdown -p and reboot with ethernet unplugged, with config in /etc/rc.conf:
 >   solid hang after cable is plugged in.
 >   ctrl-alt-esc does not work.
 > 
 > So, no improvement, as far as I can see.
 >	 
 
 Ok, I slightly changed PHY power down logic. Would you give it try
 and let me know whether it makes any difference?
 
 http://people.freebsd.org/~yongari/alc/if_alc.c
 http://people.freebsd.org/~yongari/alc/if_alcreg.h
 http://people.freebsd.org/~yongari/alc/if_alcvar.h
 
 > > > c) There are sometimes panic messages during shutdown, sometimes
 > > > (after the filesystems are unmounted). See
 > > > http://opsec.eu/backup/eeepc-crash.jpg
 > > > 
 > > > I'm not sure they are related.
 > > 
 > > It's hard to say the panic is related with alc(4) or not. At least
 > > you should show back trace information to narrow down the issue.
 > 
 > Basically, the panic is after the kernel did almost all shutdown
 > stuff, so there's no disc drive mounted any more etc.
 > 
 > I was lucky with the picture, normally, it would reboot at that
 > stage.
 > 
 
 I see but that information is insufficient to narrow down the
 issue.

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Tue, 10 Aug 2010 02:36:26 +0200

 Hi!
 
 > > > Anyway, here is
 > > > updated alc(4) which may affect AR8131/AR8132 behavior. Would you
 > > > give it try and let me know whether it makes any difference?
 > > 
 > > I tried:
 > > 
 [...]
 > Ok, I slightly changed PHY power down logic. Would you give it try
 > and let me know whether it makes any difference?
 > 
 > http://people.freebsd.org/~yongari/alc/if_alc.c
 > http://people.freebsd.org/~yongari/alc/if_alcreg.h
 > http://people.freebsd.org/~yongari/alc/if_alcvar.h
 
 Same tests as above, same result:
 
 - shutdown -p and reboot with ethernet plugged in, then ifconfig alc0
   after boot: works.
 - shutdown -p and reboot with ethernet unplugged, then ifconfig alc0
   after boot: does not work after plugging in the cable.
   (no packets on the wire)
 - shutdown -p and reboot with ethernet unplugged, with config in /etc/rc.conf:
   solid hang after cable is plugged in.
   ctrl-alt-esc does not work.
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Tue, 10 Aug 2010 02:44:06 +0200

 Hi!
 
 > Ok, I slightly changed PHY power down logic. Would you give it try
 > and let me know whether it makes any difference?
 
 Does it matter that the link is only half-duplex ?
 
 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 xxx.xxx.xxx.xxx netmask 0xffffffe0 broadcast xxx.xxx.xxx.xxx
         media: Ethernet autoselect (100baseTX <half-duplex>)
         status: active
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Mon, 9 Aug 2010 17:57:34 -0700

 On Tue, Aug 10, 2010 at 02:44:06AM +0200, Kurt Jaeger wrote:
 > Hi!
 > 
 > > Ok, I slightly changed PHY power down logic. Would you give it try
 > > and let me know whether it makes any difference?
 > 
 > Does it matter that the link is only half-duplex ?
 > 
 > 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 xxx.xxx.xxx.xxx netmask 0xffffffe0 broadcast xxx.xxx.xxx.xxx
 >         media: Ethernet autoselect (100baseTX <half-duplex>)
 >         status: active
 > 
 
 Does link partner also agree on the resolved speed duplex?
 
 When system boots with UTP cable plugged, the negotiated
 speed/duplex shows different one from above? By chance, did you
 manually set media configuration on link partner(switch) instead
 of using auto-negotiation?

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Tue, 10 Aug 2010 07:14:08 +0200

 Hi!
 
 > >         media: Ethernet autoselect (100baseTX <half-duplex>)
 > >         status: active
 > 
 > Does link partner also agree on the resolved speed duplex?
 
 Yes, it's a hub.
 
 > When system boots with UTP cable plugged, the negotiated
 > speed/duplex shows different one from above?
 
 No.
 
 > By chance, did you
 > manually set media configuration on link partner(switch) instead
 > of using auto-negotiation?
 
 No, it's auto-neg.
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not 
	plugged in during boot
Date: Mon, 9 Aug 2010 22:20:25 -0700

 On Mon, Aug 9, 2010 at 10:14 PM, Kurt Jaeger <pi@opsec.eu> wrote:
 > Hi!
 >
 >> > =A0 =A0 =A0 =A0 media: Ethernet autoselect (100baseTX <half-duplex>)
 >> > =A0 =A0 =A0 =A0 status: active
 >>
 >> Does link partner also agree on the resolved speed duplex?
 >
 > Yes, it's a hub.
 >
 
 Hmm, do you mean it's dummy hub?
 It's not common to see half-duplex link in these days.
 If it's not a dummy hub, you can see established link state in
 switch's port menu.
 
 >> When system boots with UTP cable plugged, the negotiated
 >> speed/duplex shows different one from above?
 >
 > No.
 >
 >> By chance, did you
 >> manually set media configuration on link partner(switch) instead
 >> of using auto-negotiation?
 >
 > No, it's auto-neg.
 
 To rule out possible switch issues, could you try the same test
 with direct cable against other host?

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Tue, 10 Aug 2010 07:48:56 +0200

 Hi!
 
 > >> >     media: Ethernet autoselect (100baseTX <half-duplex>)
 > >> >     status: active
 
 > >> Does link partner also agree on the resolved speed duplex?
 
 > > Yes, it's a hub.
 
 > Hmm, do you mean it's dummy hub?
 
 Yes.
 
 > It's not common to see half-duplex link in these days.
 
 I know. I deliberatly selected this to be a 10/100 hub, for ethernet
 debugging purposes. I can connect the device to some switch, if this
 helps.
 
 > To rule out possible switch issues, could you try the same test
 > with direct cable against other host?
 
 I'll try.
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Tue, 10 Aug 2010 07:59:25 +0200

 Hi!
 
 > To rule out possible switch issues, could you try the same test
 > with direct cable against other host?
 
 Here the host after booting, with no cable plugged in:
 
 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 xxx.xxx.xxx.12 netmask 0xffffffe0 broadcast xxx.xxx.xxx.31
 	media: Ethernet autoselect (none <hw-loopback>)
 	status: no carrier
 
 Here after a cable was plugged in, for a short period it shows this:
 
 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 xxx.xxx.xxx.12 netmask 0xffffffe0 broadcast xxx.xxx.xxx.31
 	media: Ethernet autoselect (none)
 	status: no carrier
 
 After a short while, the correct link type is detected:
 
 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 xxx.xxx.xxx.12 netmask 0xffffffe0 broadcast xxx.xxx.xxx.31
         media: Ethernet autoselect (100baseTX <full-duplex>)
         status: active
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Tue, 10 Aug 2010 16:09:50 -0700

 On Tue, Aug 10, 2010 at 07:59:25AM +0200, Kurt Jaeger wrote:
 > Hi!
 > 
 > > To rule out possible switch issues, could you try the same test
 > > with direct cable against other host?
 > 
 > Here the host after booting, with no cable plugged in:
 > 
 > 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 xxx.xxx.xxx.12 netmask 0xffffffe0 broadcast xxx.xxx.xxx.31
 > 	media: Ethernet autoselect (none <hw-loopback>)
 > 	status: no carrier
 > 
 > Here after a cable was plugged in, for a short period it shows this:
 > 
 > 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 xxx.xxx.xxx.12 netmask 0xffffffe0 broadcast xxx.xxx.xxx.31
 > 	media: Ethernet autoselect (none)
 > 	status: no carrier
 > 
 > After a short while, the correct link type is detected:
 > 
 
 It should. Auto-negotiation takes a couple of seconds, sometimes it
 would take more than 10 seconds.
 
 > 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 xxx.xxx.xxx.12 netmask 0xffffffe0 broadcast xxx.xxx.xxx.31
 >         media: Ethernet autoselect (100baseTX <full-duplex>)
 >         status: active
 > 
 
 Looks perfectly normal to me. And alc(4) could not send or receive
 any packets from link partner, right?
 If yes, how about DOWNing interface and UP again?(e.g. ifconfig
 alc0 down; ifconfig alc0 up)
State-Changed-From-To: feedback->open 
State-Changed-By: yongari 
State-Changed-When: Wed Aug 11 16:48:17 UTC 2010 
State-Changed-Why:  
feedback received. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Thu, 12 Aug 2010 04:33:36 +0200

 Hi!
 
 > > 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 xxx.xxx.xxx.12 netmask 0xffffffe0 broadcast xxx.xxx.xxx.31
 > >         media: Ethernet autoselect (100baseTX <full-duplex>)
 > >         status: active
 
 > Looks perfectly normal to me. And alc(4) could not send or receive
 > any packets from link partner, right?
 
 Yes, but:
 
 1) I did one powercycle with case 
 
 - shutdown -p and reboot with ethernet unplugged, then ifconfig alc0
 after boot and then typing 'ifconfig alc0' very often until the
 link came up, and: It worked!
 
 Then I tried
 
 - shutdown -p and reboot with ethernet unplugged, with config in /etc/rc.conf:
 
 which did *not* cause the hang, but see below:
 
 > If yes, how about DOWNing interface and UP again?(e.g. ifconfig
 > alc0 down; ifconfig alc0 up)
 
 2)
 I did this, and then:
 
 ping xxx.xxx.xxx.1, while doing a
 
 tcpdump -i em0 -n -s 1500 ether host 48:5b:39:73:03:4f
 
 on the .1:
 
 04:27:11.535692 ARP, Request who-has xxx.xxx.xxx.1 tell xxx.xxx.xxx.12, length 46
 04:27:11.535706 ARP, Reply xxx.xxx.xxx.1 is-at 00:1b:21:31:e2:2b, length 28
 
 So the alc0 sends out packets, but it does not receive them ?
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Thu, 12 Aug 2010 04:33:36 +0200

 Hi!
 
 > > 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 xxx.xxx.xxx.12 netmask 0xffffffe0 broadcast xxx.xxx.xxx.31
 > >         media: Ethernet autoselect (100baseTX <full-duplex>)
 > >         status: active
 
 > Looks perfectly normal to me. And alc(4) could not send or receive
 > any packets from link partner, right?
 
 Yes, but:
 
 1) I did one powercycle with case 
 
 - shutdown -p and reboot with ethernet unplugged, then ifconfig alc0
 after boot and then typing 'ifconfig alc0' very often until the
 link came up, and: It worked!
 
 Then I tried
 
 - shutdown -p and reboot with ethernet unplugged, with config in /etc/rc.conf:
 
 which did *not* cause the hang, but see below:
 
 > If yes, how about DOWNing interface and UP again?(e.g. ifconfig
 > alc0 down; ifconfig alc0 up)
 
 2)
 I did this, and then:
 
 ping xxx.xxx.xxx.1, while doing a
 
 tcpdump -i em0 -n -s 1500 ether host 48:5b:39:73:03:4f
 
 on the .1:
 
 04:27:11.535692 ARP, Request who-has xxx.xxx.xxx.1 tell xxx.xxx.xxx.12, length 46
 04:27:11.535706 ARP, Reply xxx.xxx.xxx.1 is-at 00:1b:21:31:e2:2b, length 28
 
 So the alc0 sends out packets, but it does not receive them ?
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Thu, 12 Aug 2010 16:00:21 -0700

 On Thu, Aug 12, 2010 at 04:33:36AM +0200, Kurt Jaeger wrote:
 > Hi!
 > 
 > > > 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 xxx.xxx.xxx.12 netmask 0xffffffe0 broadcast xxx.xxx.xxx.31
 > > >         media: Ethernet autoselect (100baseTX <full-duplex>)
 > > >         status: active
 > 
 > > Looks perfectly normal to me. And alc(4) could not send or receive
 > > any packets from link partner, right?
 > 
 > Yes, but:
 > 
 > 1) I did one powercycle with case 
 > 
 > - shutdown -p and reboot with ethernet unplugged, then ifconfig alc0
 > after boot and then typing 'ifconfig alc0' very often until the
 > link came up, and: It worked!
 > 
 > Then I tried
 > 
 > - shutdown -p and reboot with ethernet unplugged, with config in /etc/rc.conf:
 > 
 > which did *not* cause the hang, but see below:
 > 
 > > If yes, how about DOWNing interface and UP again?(e.g. ifconfig
 > > alc0 down; ifconfig alc0 up)
 > 
 > 2)
 > I did this, and then:
 > 
 > ping xxx.xxx.xxx.1, while doing a
 > 
 > tcpdump -i em0 -n -s 1500 ether host 48:5b:39:73:03:4f
 > 
 > on the .1:
 > 
 > 04:27:11.535692 ARP, Request who-has xxx.xxx.xxx.1 tell xxx.xxx.xxx.12, length 46
 > 04:27:11.535706 ARP, Reply xxx.xxx.xxx.1 is-at 00:1b:21:31:e2:2b, length 28
 > 
 > So the alc0 sends out packets, but it does not receive them ?
 > 
 
 Yes it does. I think I found a bug in driver but I'm not sure
 whether it is related with your issue. Anyway, I updated if_alc.c
 file. Let me know how it goes.
 
 http://people.freebsd.org/~yongari/alc/if_alc.c
 http://people.freebsd.org/~yongari/alc/if_alcreg.h
 http://people.freebsd.org/~yongari/alc/if_alcvar.h
 

From: "Sergey V. Dyatko" <sergey.dyatko@gmail.com>
To: bug-followup@FreeBSD.org, fbsd-pr@opsec.eu
Cc:  
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Fri, 13 Aug 2010 14:48:17 +0300

 Hi, 
 I build kmod with
 http://people.freebsd.org/~yongari/alc/if_alc.c
 http://people.freebsd.org/~yongari/alc/if_alcreg.h
 http://people.freebsd.org/~yongari/alc/if_alcvar.h
 nothing changes for me :(
 
 I run tcpdump on laptop (hostA) and on server with dhcpd (hostB). on
 hostB I see requests and reply. On hostA - only requests
 As usual, if i boot with plugged cable - all works fine
 
 -- 
 wbr, tiger

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@freebsd.org, FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Fri, 13 Aug 2010 20:44:43 +0200

 Hi!
 
 > > > Looks perfectly normal to me. And alc(4) could not send or receive
 > > > any packets from link partner, right?
 [...]
 > > 1) I did one powercycle with case 
 > > 
 > > - shutdown -p and reboot with ethernet unplugged, then ifconfig alc0
 > > after boot and then typing 'ifconfig alc0' very often until the
 > > link came up, and: It worked!
 
 I had one case of this, where this worked, but...
 
 > > Then I tried
 > > 
 > > - shutdown -p and reboot with ethernet unplugged, with config in /etc/rc.conf:
 > > 
 > > which did *not* cause the hang, but see below:
 
 I had one case of this as well.
 
 I had a case where after the shutdown at the end, the DDB prompt
 was scrolling through:
 
 db>
 db>
 [...]
 
 > > > If yes, how about DOWNing interface and UP again?(e.g. ifconfig
 > > > alc0 down; ifconfig alc0 up)
 > > 
 > > 2)
 > > I did this, and then:
 > > 
 > > ping xxx.xxx.xxx.1, while doing a
 > > 
 > > tcpdump -i em0 -n -s 1500 ether host 48:5b:39:73:03:4f
 > > 
 > > on the .1:
 > > 
 > > 04:27:11.535692 ARP, Request who-has xxx.xxx.xxx.1 tell xxx.xxx.xxx.12, length 46
 > > 04:27:11.535706 ARP, Reply xxx.xxx.xxx.1 is-at 00:1b:21:31:e2:2b, length 28
 > > 
 > > So the alc0 sends out packets, but it does not receive them ?
 
 And I had one case of this, again:
 
 20:43:26.570828 ARP, Request who-has 213.178.180.1 tell 213.178.180.12, length 46
 20:43:26.570837 ARP, Reply 213.178.180.1 is-at 00:1b:21:31:e2:2b, length 28
 20:43:27.571300 ARP, Request who-has 213.178.180.1 tell 213.178.180.12, length 46
 20:43:27.571310 ARP, Reply 213.178.180.1 is-at 00:1b:21:31:e2:2b, length 28
 20:43:28.572265 ARP, Request who-has 213.178.180.1 tell 213.178.180.12, length 46
 20:43:28.572273 ARP, Reply 213.178.180.1 is-at 00:1b:21:31:e2:2b, length 28
 20:43:29.573359 ARP, Request who-has 213.178.180.1 tell 213.178.180.12, length 46
 
 Hmm, this did not fix it. Maybe I should ship this box to you 8-)
 
 -- 
 pi@opsec.eu            +49 171 3101372                        10 years to go !

From: "Sergey V. Dyatko" <sergey.dyatko@gmail.com>
To: bug-followup@FreeBSD.org, fbsd-pr@opsec.eu
Cc:  
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Mon, 29 Nov 2010 10:33:42 +0200

 Hi, 
 
 looks like all works fine for me.
 does r214542 fixed it ?
 
 % uname -a
 FreeBSD laptop.minsk.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #15
 r215936M: Sat Nov 27 11:13:52 EET 2010
 root@laptop.minsk.domain:/usr/obj/usr/src/sys/b450  i386
 
 -- 
 wbr, tiger

From: Pyun YongHyeon <pyunyh@gmail.com>
To: "Sergey V. Dyatko" <sergey.dyatko@gmail.com>
Cc: yongari@freebsd.org, bug-followup@FreeBSD.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Mon, 29 Nov 2010 14:51:47 -0800

 On Mon, Nov 29, 2010 at 09:10:11AM +0000, Sergey V. Dyatko wrote:
 > The following reply was made to PR kern/148772; it has been noted by GNATS.
 > 
 > From: "Sergey V. Dyatko" <sergey.dyatko@gmail.com>
 > To: bug-followup@FreeBSD.org, fbsd-pr@opsec.eu
 > Cc:  
 > Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 >  plugged in during boot
 > Date: Mon, 29 Nov 2010 10:33:42 +0200
 > 
 >  Hi, 
 >  
 >  looks like all works fine for me.
 >  does r214542 fixed it ?
 >  
 
 
 Probably, thanks for reporting.
 
 Kurt, could you try latest CURRENT or latest stable/8 and stable/7
 and let me whether it is fixed or not on your box?
 
 >  % uname -a
 >  FreeBSD laptop.minsk.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #15
 >  r215936M: Sat Nov 27 11:13:52 EET 2010
 >  root@laptop.minsk.domain:/usr/obj/usr/src/sys/b450  i386
State-Changed-From-To: open->closed 
State-Changed-By: yongari 
State-Changed-When: Mon Jan 17 19:50:40 UTC 2011 
State-Changed-Why:  
Feedback timeout. 
I believe the issue was fixed in r214542 and already MFCed to 
stable/8 and stable/7. If you still see the issue please open a new 
PR. Thanks for reporting! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 
State-Changed-From-To: closed->open 
State-Changed-By: yongari 
State-Changed-When: Tue Jan 18 17:12:47 UTC 2011 
State-Changed-Why:  
Reopen. Submitter still see the issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 

From: Kurt Jaeger <pi@opsec.eu>
To: yongari@FreeBSD.org
Cc: fbsd-pr@opsec.eu
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Tue, 18 Jan 2011 09:14:14 +0100

 Hi!
 
 > Synopsis: [alc] alc0 does not send/receive packets if not plugged in during boot
 
 > I believe the issue was fixed in r214542 and already MFCed to
 > stable/8 and stable/7. If you still see the issue please open a new
 > PR. Thanks for reporting!
 > 
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=148772
 
 Tried with 8.2-RC2, still the same problem. Sorry.
 
 -- 
 pi@opsec.eu            +49 171 3101372                         9 years to go !

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@FreeBSD.org, fbsd-pr@opsec.eu, bug-followup@FreeBSD.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Wed, 19 Jan 2011 19:23:30 -0800

 On Tue, Jan 18, 2011 at 09:14:14AM +0100, Kurt Jaeger wrote:
 > Hi!
 > 
 > > Synopsis: [alc] alc0 does not send/receive packets if not plugged in during boot
 > 
 > > I believe the issue was fixed in r214542 and already MFCed to
 > > stable/8 and stable/7. If you still see the issue please open a new
 > > PR. Thanks for reporting!
 > > 
 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148772
 > 
 > Tried with 8.2-RC2, still the same problem. Sorry.
 > 
 
 Could you try the patch at the following URL?
 http://people.freebsd.org/~yongari/alc/alc.L2CB.diff2

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@FreeBSD.org, fbsd-pr@opsec.eu, bug-followup@FreeBSD.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Thu, 20 Jan 2011 07:26:56 +0100

 Hi!
 
 > > > Synopsis: [alc] alc0 does not send/receive packets if not plugged in during boot
 
 > > > I believe the issue was fixed in r214542 and already MFCed to
 > > > stable/8 and stable/7. If you still see the issue please open a new
 > > > PR. Thanks for reporting!
 > > > 
 > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148772
 > > 
 > > Tried with 8.2-RC2, still the same problem. Sorry.
 
 > Could you try the patch at the following URL?
 > http://people.freebsd.org/~yongari/alc/alc.L2CB.diff2
 
 Tried, after a shutdown -p and reboot with unplugged cable, the link was
 up, but no ping was possible.
 
 Reboot with plugged-in cable: Worked.
 
 -- 
 pi@opsec.eu            +49 171 3101372                         9 years to go !

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@FreeBSD.org, fbsd-pr@opsec.eu, bug-followup@FreeBSD.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Thu, 20 Jan 2011 17:49:45 -0800

 On Thu, Jan 20, 2011 at 07:26:56AM +0100, Kurt Jaeger wrote:
 > Hi!
 > 
 > > > > Synopsis: [alc] alc0 does not send/receive packets if not plugged in during boot
 > 
 > > > > I believe the issue was fixed in r214542 and already MFCed to
 > > > > stable/8 and stable/7. If you still see the issue please open a new
 > > > > PR. Thanks for reporting!
 > > > > 
 > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148772
 > > > 
 > > > Tried with 8.2-RC2, still the same problem. Sorry.
 > 
 > > Could you try the patch at the following URL?
 > > http://people.freebsd.org/~yongari/alc/alc.L2CB.diff2
 > 
 > Tried, after a shutdown -p and reboot with unplugged cable, the link was
 > up, but no ping was possible.
 > 
 > Reboot with plugged-in cable: Worked.
 > 
 
 Hmm, Back out all patches then try again the patch in URL below.
 http://people.freebsd.org/~yongari/alc/alc.link.patch3
 
 The patch will also show "LINK UP" or "LINK DOWN" whenever link
 state change is detected. After you boot without UTP cable and
 assign an IP address to the controller and then plug the cable. If
 alc(4) detects link state change it would print "LINK UP" message.
 Please let me know whether you can see these messages.

From: Kurt Jaeger <pi@opsec.eu>
To: Pyun YongHyeon <pyunyh@gmail.com>
Cc: yongari@FreeBSD.org, fbsd-pr@opsec.eu, bug-followup@FreeBSD.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Fri, 21 Jan 2011 20:53:43 +0100

 Hi!
 
 > > > Could you try the patch at the following URL?
 > > > http://people.freebsd.org/~yongari/alc/alc.L2CB.diff2
 > > 
 > > Tried, after a shutdown -p and reboot with unplugged cable, the link was
 > > up, but no ping was possible.
 > > 
 > > Reboot with plugged-in cable: Worked.
 
 > Hmm, Back out all patches then try again the patch in URL below.
 > http://people.freebsd.org/~yongari/alc/alc.link.patch3
 > 
 > The patch will also show "LINK UP" or "LINK DOWN" whenever link
 > state change is detected.
 
 Funny, it shows LINK DOWN more often, actually, quite a few times.
 
 If I plug in a cable, it says: LINK UP. But: No packets are flowing.
 
 > After you boot without UTP cable and
 > assign an IP address to the controller and then plug the cable. If
 > alc(4) detects link state change it would print "LINK UP" message.
 
 It does this, yes.
 
 > Please let me know whether you can see these messages.
 
 Yes.
 
 But still: No packets are flowing.
 
 That's really wierd (but not wired 8-)
 
 -- 
 pi@opsec.eu            +49 171 3101372                         9 years to go !

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@FreeBSD.org, fbsd-pr@opsec.eu, bug-followup@FreeBSD.org
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Fri, 21 Jan 2011 15:15:47 -0800

 On Fri, Jan 21, 2011 at 08:53:43PM +0100, Kurt Jaeger wrote:
 > Hi!
 > 
 > > > > Could you try the patch at the following URL?
 > > > > http://people.freebsd.org/~yongari/alc/alc.L2CB.diff2
 > > > 
 > > > Tried, after a shutdown -p and reboot with unplugged cable, the link was
 > > > up, but no ping was possible.
 > > > 
 > > > Reboot with plugged-in cable: Worked.
 > 
 > > Hmm, Back out all patches then try again the patch in URL below.
 > > http://people.freebsd.org/~yongari/alc/alc.link.patch3
 > > 
 > > The patch will also show "LINK UP" or "LINK DOWN" whenever link
 > > state change is detected.
 > 
 > Funny, it shows LINK DOWN more often, actually, quite a few times.
 > 
 
 I guess it's trying to establish a link with auto-negotiation.
 During that time link state can fluctuating and you may see them.
 
 > If I plug in a cable, it says: LINK UP. But: No packets are flowing.
 > 
 > > After you boot without UTP cable and
 > > assign an IP address to the controller and then plug the cable. If
 > > alc(4) detects link state change it would print "LINK UP" message.
 > 
 > It does this, yes.
 > 
 > > Please let me know whether you can see these messages.
 > 
 > Yes.
 > 
 > But still: No packets are flowing.
 > 
 
 Ok. It seems I need access to real hardware that show the issue.
 Could you provide a remote access to me as described in
 http://people.freebsd.org/~yongari/remote_debugging.txt
 
 It seems remote debugging looks hard since it requires manual
 cable plugging/unplugging to test that. However, I think you can
 boot the box without UTP cable and plug UTP cable again before I 
 begin testing with alc kernel module.
 
 Using kernel module made no difference, right? I mean booting
 without UTP cable and then load alc kernel module.
 
 > That's really wierd (but not wired 8-)

From: Garrett Cooper <yanegomi@gmail.com>
To: bug-followup@FreeBSD.org, fbsd-pr@opsec.eu
Cc:  
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Wed, 17 Aug 2011 09:33:41 -0700

     This has been happening for me as well on two different ASUS EEEPC
 netbooks (one using PCBSD 9.0-BETA1, the other using a recent version
 of HEAD). Configuring the device to use static IPs/routes and DHCP
 based connectivity fails. The only thing that works is having the
 cable plugged in at boot.
     I haven't tried 8.x on these netbooks yet..
 -Garrett
 
 PS. There are some LORs reported in the if_alc's ioctl code with
 WITNESS on (saw it on the PCBSD 9.0-BETA1 machine). I'll try and see
 if these are the root cause for the issue reported.

From: "Sergey V. Dyatko" <sergey.dyatko@gmail.com>
To: bug-followup@FreeBSD.org, fbsd-pr@opsec.eu
Cc:  
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Fri, 19 Aug 2011 09:42:31 +0300

 Hi again, 
 
 one year passed and the same problem again.
 
 same hardware (lenovo b450 laptop), head/
 
 alc0@pci0:2:0:0:        class=0x020000 card=0x38a317aa chip=0x10621969
 rev=0xc0 hdr=0x00
     vendor     = 'Atheros Communications'
     device     = 'AR8132 Fast Ethernet'
     class      = network
     subclass   = ethernet
 
 unfortunately I can't provide remote access, but I can test patches and
 spam GNATS with results :)
 
 -- 
 wbr, tiger
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Mon Aug 22 22:00:51 UTC 2011 
State-Changed-Why:  
I've chcked in disabling hibernation and it seems it also fixes 
this PR. Would you try the patch and let me know whether it fixes 
the issue or not? You can get the patch at the following URL. 
http://svnweb.freebsd.org/base/head/sys/dev/alc/if_alc.c?r1=221407&r2=225088&view=patch 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 

From: Kurt Jaeger <pi@opsec.eu>
To: yongari@FreeBSD.org, bug-followup@FreeBSD.org
Cc: fbsd-pr@opsec.eu
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Wed, 24 Aug 2011 07:38:00 +0200

 Hi!
 
 > I've chcked in disabling hibernation and it seems it also fixes
 > this PR. Would you try the patch and let me know whether it fixes
 > the issue or not? You can get the patch at the following URL.
 > http://svnweb.freebsd.org/base/head/sys/dev/alc/if_alc.c?r1=221407&r2=225088&view=patch
 
 I tested it, it works much better. Thank you. Please commit this patch.
 
 There's one more issue, and I have to investigate it:
 
 If the switch you are plugged into is of the "green" type (links
 powered down if nothing is connected), then the alc0 still does
 not get a connection.
 
 I'll have to investigate a bit more with the two different types
 of green switches (that I happen to have to test against) to find out more:
 
 - D-Link DGS 1008G
 - ASUS GX-D01081/G
 
 -- 
 pi@opsec.eu            +49 171 3101372                         9 years to go !

From: "Sergey V. Dyatko" <sergey.dyatko@gmail.com>
To: bug-followup@FreeBSD.org, fbsd-pr@opsec.eu
Cc:  
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Wed, 24 Aug 2011 08:59:07 +0300

 Hi,
 
 [tiger@laptop]~%uname -a
 FreeBSD laptop.minsk.domain 9.0-BETA1 FreeBSD 9.0-BETA1 #3 r225099: Tue
 Aug 23 10:52:30 EEST 2011
 root@laptop.minsk.domain:/usr/obj/usr/src/sys/b450  amd64
 
 works good even when I boot w/o plugged UTP cable
 
 -- 
 wbr, tiger

From: Kurt Jaeger <pi@opsec.eu>
To: yongari@FreeBSD.org, bug-followup@FreeBSD.org
Cc: fbsd-pr@opsec.eu
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Wed, 24 Aug 2011 09:14:11 +0200

 Hi!
 
 > I tested it, it works much better. Thank you. Please commit this patch.
 
 I tested it on 8.2-RELEASE i386, FYI.
 
 -- 
 pi@opsec.eu            +49 171 3101372                         9 years to go !

From: YongHyeon PYUN <pyunyh@gmail.com>
To: Kurt Jaeger <pi@opsec.eu>
Cc: yongari@FreeBSD.org, bug-followup@FreeBSD.org, fbsd-pr@opsec.eu
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not plugged in during boot
Date: Wed, 24 Aug 2011 10:06:22 -0700

 On Wed, Aug 24, 2011 at 07:38:00AM +0200, Kurt Jaeger wrote:
 > Hi!
 > 
 > > I've chcked in disabling hibernation and it seems it also fixes
 > > this PR. Would you try the patch and let me know whether it fixes
 > > the issue or not? You can get the patch at the following URL.
 > > http://svnweb.freebsd.org/base/head/sys/dev/alc/if_alc.c?r1=221407&r2=225088&view=patch
 > 
 > I tested it, it works much better. Thank you. Please commit this patch.
 > 
 
 It was already committed in HEAD.
 
 > There's one more issue, and I have to investigate it:
 > 
 > If the switch you are plugged into is of the "green" type (links
 > powered down if nothing is connected), then the alc0 still does
 > not get a connection.
 > 
 > I'll have to investigate a bit more with the two different types
 > of green switches (that I happen to have to test against) to find out more:
 > 
 > - D-Link DGS 1008G
 > - ASUS GX-D01081/G
 > 
 
 It seems the D-Link switch is gigabit switch. Not sure about ASUS
 switch.  There is another fix committed to tree after releasing
 8.2-RELEASE.
 http://svnweb.freebsd.org/base/stable/8/sys/dev/mii/atphy.c?r1=217670&r2=222098&view=patch
 I'm not sure whether this can address your other issue though.
 Anyway, please try the patch and let me know whether it makes any
 difference.  If auto-negotiation does not work, try manual
 configuration.
 
 If the patch above does not address link establishment issue, could
 you try other operating system like Windows?

From: Kurt Jaeger <pi@opsec.eu>
To: YongHyeon PYUN <pyunyh@gmail.com>
Cc: yongari@FreeBSD.org, bug-followup@FreeBSD.org, fbsd-pr@opsec.eu
Subject: Re: kern/148772: [alc] alc0 does not send/receive packets if not
 plugged in during boot
Date: Wed, 24 Aug 2011 21:40:18 +0200

 Hi!
 
 > > > I've chcked in disabling hibernation and it seems it also fixes
 > > > this PR. Would you try the patch and let me know whether it fixes
 > > > the issue or not? You can get the patch at the following URL.
 > > > http://svnweb.freebsd.org/base/head/sys/dev/alc/if_alc.c?r1=221407&r2=225088&view=patch
 > > 
 > > I tested it, it works much better. Thank you. Please commit this patch.
 
 > It was already committed in HEAD.
 
 Thanks!
 
 > > There's one more issue, and I have to investigate it:
 > > 
 > > If the switch you are plugged into is of the "green" type (links
 > > powered down if nothing is connected), then the alc0 still does
 > > not get a connection.
 > > 
 > > I'll have to investigate a bit more with the two different types
 > > of green switches (that I happen to have to test against) to find out more:
 > > 
 > > - D-Link DGS 1008G
 > > - ASUS GX-D01081/G
 
 The ASUS is:
 
 - ASUS GX-D1081/G
 
 The D-Link is the old white model which does not seem to be sold any more.
 
 I tested the old state against both switches. alc0 worked against
 the ASUS switch, but it failed against the D-Link.
 
 > It seems the D-Link switch is gigabit switch. Not sure about ASUS
 > switch.  There is another fix committed to tree after releasing
 > 8.2-RELEASE.
 > http://svnweb.freebsd.org/base/stable/8/sys/dev/mii/atphy.c?r1=217670&r2=222098&view=patch
 > I'm not sure whether this can address your other issue though.
 
 I tested the patch and it addressed my issue, thank you very much for
 the pointer. So I'm a happy camper now 8-)
 
 -- 
 pi@opsec.eu            +49 171 3101372                         9 years to go !
State-Changed-From-To: feedback->patched 
State-Changed-By: yongari 
State-Changed-When: Wed Aug 24 23:08:10 UTC 2011 
State-Changed-Why:  
Fixed in HEAD(r225088). 
Thanke for testing! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/148772: commit references a PR
Date: Tue, 30 Aug 2011 17:20:48 +0000 (UTC)

 Author: yongari
 Date: Tue Aug 30 17:20:34 2011
 New Revision: 225268
 URL: http://svn.freebsd.org/changeset/base/225268
 
 Log:
   MFC r225088:
     Disable PHY hibernation until I get more detailed hibernation
     programming secret.  The PHY would go into sleep state when it
     detects no established link and it will re-establish link when the
     cable is plugged in.  Previously it failed to re-establish link
     when the cable is plugged in such that it required to manually down
     and up the interface again to make it work.  This came from
     incorrectly programmed hibernation parameters.  According to
     Atheros, each PHY chip requires different configuration for
     hibernation and different vendor has different settings for the
     same chip.
     Disabling hibernation may consume more power but establishing link
     looks more important than saving power.
     Special thanks to Atheros for giving me instructions that disable
     hibernation.
   
     PR:	kern/148772
 
 Modified:
   stable/8/sys/dev/alc/if_alc.c
 Directory Properties:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
 
 Modified: stable/8/sys/dev/alc/if_alc.c
 ==============================================================================
 --- stable/8/sys/dev/alc/if_alc.c	Tue Aug 30 16:52:25 2011	(r225267)
 +++ stable/8/sys/dev/alc/if_alc.c	Tue Aug 30 17:20:34 2011	(r225268)
 @@ -534,13 +534,11 @@ alc_phy_reset(struct alc_softc *sc)
  	uint16_t data;
  
  	/* Reset magic from Linux. */
 -	CSR_WRITE_2(sc, ALC_GPHY_CFG,
 -	    GPHY_CFG_HIB_EN | GPHY_CFG_HIB_PULSE | GPHY_CFG_SEL_ANA_RESET);
 +	CSR_WRITE_2(sc, ALC_GPHY_CFG, GPHY_CFG_SEL_ANA_RESET);
  	CSR_READ_2(sc, ALC_GPHY_CFG);
  	DELAY(10 * 1000);
  
 -	CSR_WRITE_2(sc, ALC_GPHY_CFG,
 -	    GPHY_CFG_EXT_RESET | GPHY_CFG_HIB_EN | GPHY_CFG_HIB_PULSE |
 +	CSR_WRITE_2(sc, ALC_GPHY_CFG, GPHY_CFG_EXT_RESET |
  	    GPHY_CFG_SEL_ANA_RESET);
  	CSR_READ_2(sc, ALC_GPHY_CFG);
  	DELAY(10 * 1000);
 @@ -625,6 +623,23 @@ alc_phy_reset(struct alc_softc *sc)
  	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr,
  	    ALC_MII_DBG_DATA, data);
  	DELAY(1000);
 +
 +	/* Disable hibernation. */
 +	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr, ALC_MII_DBG_ADDR,
 +	    0x0029);
 +	data = alc_miibus_readreg(sc->alc_dev, sc->alc_phyaddr,
 +	    ALC_MII_DBG_DATA);
 +	data &= ~0x8000;
 +	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr, ALC_MII_DBG_DATA,
 +	    data);
 +
 +	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr, ALC_MII_DBG_ADDR,
 +	    0x000B);
 +	data = alc_miibus_readreg(sc->alc_dev, sc->alc_phyaddr,
 +	    ALC_MII_DBG_DATA);
 +	data &= ~0x8000;
 +	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr, ALC_MII_DBG_DATA,
 +	    data);
  }
  
  static void
 @@ -650,8 +665,7 @@ alc_phy_down(struct alc_softc *sc)
  		break;
  	default:
  		/* Force PHY down. */
 -		CSR_WRITE_2(sc, ALC_GPHY_CFG,
 -		    GPHY_CFG_EXT_RESET | GPHY_CFG_HIB_EN | GPHY_CFG_HIB_PULSE |
 +		CSR_WRITE_2(sc, ALC_GPHY_CFG, GPHY_CFG_EXT_RESET |
  		    GPHY_CFG_SEL_ANA_RESET | GPHY_CFG_PHY_IDDQ |
  		    GPHY_CFG_PWDOWN_HW);
  		DELAY(1000);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/148772: commit references a PR
Date: Tue, 30 Aug 2011 17:22:11 +0000 (UTC)

 Author: yongari
 Date: Tue Aug 30 17:21:55 2011
 New Revision: 225269
 URL: http://svn.freebsd.org/changeset/base/225269
 
 Log:
   MFC r225088:
     Disable PHY hibernation until I get more detailed hibernation
     programming secret.  The PHY would go into sleep state when it
     detects no established link and it will re-establish link when the
     cable is plugged in.  Previously it failed to re-establish link
     when the cable is plugged in such that it required to manually down
     and up the interface again to make it work.  This came from
     incorrectly programmed hibernation parameters.  According to
     Atheros, each PHY chip requires different configuration for
     hibernation and different vendor has different settings for the
     same chip.
     Disabling hibernation may consume more power but establishing link
     looks more important than saving power.
     Special thanks to Atheros for giving me instructions that disable
     hibernation.
   
     PR:	kern/148772
 
 Modified:
   stable/7/sys/dev/alc/if_alc.c
 Directory Properties:
   stable/7/sys/   (props changed)
   stable/7/sys/cddl/contrib/opensolaris/   (props changed)
   stable/7/sys/contrib/dev/acpica/   (props changed)
   stable/7/sys/contrib/pf/   (props changed)
 
 Modified: stable/7/sys/dev/alc/if_alc.c
 ==============================================================================
 --- stable/7/sys/dev/alc/if_alc.c	Tue Aug 30 17:20:34 2011	(r225268)
 +++ stable/7/sys/dev/alc/if_alc.c	Tue Aug 30 17:21:55 2011	(r225269)
 @@ -534,13 +534,11 @@ alc_phy_reset(struct alc_softc *sc)
  	uint16_t data;
  
  	/* Reset magic from Linux. */
 -	CSR_WRITE_2(sc, ALC_GPHY_CFG,
 -	    GPHY_CFG_HIB_EN | GPHY_CFG_HIB_PULSE | GPHY_CFG_SEL_ANA_RESET);
 +	CSR_WRITE_2(sc, ALC_GPHY_CFG, GPHY_CFG_SEL_ANA_RESET);
  	CSR_READ_2(sc, ALC_GPHY_CFG);
  	DELAY(10 * 1000);
  
 -	CSR_WRITE_2(sc, ALC_GPHY_CFG,
 -	    GPHY_CFG_EXT_RESET | GPHY_CFG_HIB_EN | GPHY_CFG_HIB_PULSE |
 +	CSR_WRITE_2(sc, ALC_GPHY_CFG, GPHY_CFG_EXT_RESET |
  	    GPHY_CFG_SEL_ANA_RESET);
  	CSR_READ_2(sc, ALC_GPHY_CFG);
  	DELAY(10 * 1000);
 @@ -625,6 +623,23 @@ alc_phy_reset(struct alc_softc *sc)
  	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr,
  	    ALC_MII_DBG_DATA, data);
  	DELAY(1000);
 +
 +	/* Disable hibernation. */
 +	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr, ALC_MII_DBG_ADDR,
 +	    0x0029);
 +	data = alc_miibus_readreg(sc->alc_dev, sc->alc_phyaddr,
 +	    ALC_MII_DBG_DATA);
 +	data &= ~0x8000;
 +	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr, ALC_MII_DBG_DATA,
 +	    data);
 +
 +	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr, ALC_MII_DBG_ADDR,
 +	    0x000B);
 +	data = alc_miibus_readreg(sc->alc_dev, sc->alc_phyaddr,
 +	    ALC_MII_DBG_DATA);
 +	data &= ~0x8000;
 +	alc_miibus_writereg(sc->alc_dev, sc->alc_phyaddr, ALC_MII_DBG_DATA,
 +	    data);
  }
  
  static void
 @@ -650,8 +665,7 @@ alc_phy_down(struct alc_softc *sc)
  		break;
  	default:
  		/* Force PHY down. */
 -		CSR_WRITE_2(sc, ALC_GPHY_CFG,
 -		    GPHY_CFG_EXT_RESET | GPHY_CFG_HIB_EN | GPHY_CFG_HIB_PULSE |
 +		CSR_WRITE_2(sc, ALC_GPHY_CFG, GPHY_CFG_EXT_RESET |
  		    GPHY_CFG_SEL_ANA_RESET | GPHY_CFG_PHY_IDDQ |
  		    GPHY_CFG_PWDOWN_HW);
  		DELAY(1000);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: yongari 
State-Changed-When: Tue Aug 30 19:02:56 UTC 2011 
State-Changed-Why:  
MFC to both stable/8 and stable/7 done. 
Thans to all users who tested patch. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148772 
>Unformatted:
