NetBSD Problem Report #42068

From www@NetBSD.org  Tue Sep 15 16:21:39 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 8437E63BD27
	for <gnats-bugs@gnats.netbsd.org>; Tue, 15 Sep 2009 16:21:39 +0000 (UTC)
Message-Id: <20090915162138.ED50B63B877@www.NetBSD.org>
Date: Tue, 15 Sep 2009 16:21:38 +0000 (UTC)
From: elentirmo.gilgalad@gmail.com
Reply-To: elentirmo.gilgalad@gmail.com
To: gnats-bugs@NetBSD.org
Subject: fxp address adding or removing causes link changes
X-Send-Pr-Version: www-1.0

>Number:         42068
>Category:       kern
>Synopsis:       fxp address adding or removing causes link changes
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    martin
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 15 16:25:00 +0000 2009
>Last-Modified:  Wed Jan 06 01:10:03 +0000 2010
>Originator:     Gabor Gergely
>Release:        5.99.17
>Organization:
>Environment:
NetBSD hunyadi.local 5.99.17 NetBSD 5.99.17 (GENERIC) #0: Sat Sep 12 04:15:36 UTC 2009  builds@b6.netbsd.org:/home/builds/ab/HEAD/i386/200909120000Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/GENERIC i386
>Description:
the simptoms are, that using dhcpcd once the address has been aquired, the link goes away, and the dhcp process has to start again. This behaviour has been reproduced with the following commands:

ifconfig fxp0 -alias 168.254.158.96/24
ifconfig fxp0 alias 168.254.158.96/24
ifconfig fxp0 -alias 168.254.158.96/24
ifconfig fxp0 alias 168.254.158.96/24
ifconfig fxp0 -alias 168.254.158.96/24

yielding the following results on route monitor:

### file pasted
got message of size 120 on Tue Sep 15 17:21:25 2009
RTM_DELETE: Delete Route: len 120, pid 0, seq 0, errno 0, flags: <CLONING>
locks:  inits: 
sockaddrs: <DST,GATEWAY,NETMASK>
 169.254.158.0  255.255.255.0
got message of size 80 on Tue Sep 15 17:21:25 2009
RTM_DELADDR: address being removed from iface: len 80, metric 0, flags: <CLONING>
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.0 fxp0:0.a.e4.34.7e.7f 169.254.158.96 169.254.158.255
got message of size 148 on Tue Sep 15 17:21:25 2009
#20: len 148, if# 2, carrier: no carrier, flags: <UP,BROADCAST,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:21:25 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: <sendpipe,recvpipe>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.82.aa.02.00.0
got message of size 144 on Tue Sep 15 17:21:25 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
got message of size 148 on Tue Sep 15 17:21:27 2009
#20: len 148, if# 2, carrier: active, flags: <UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:21:27 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: <sendpipe,recvpipe,hopcount>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.82.aa.02.00.0
got message of size 144 on Tue Sep 15 17:21:27 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
got message of size 80 on Tue Sep 15 17:23:39 2009
RTM_NEWADDR: address being added to iface: len 80, metric 0, flags: <CLONING>
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.0 fxp0:0.a.e4.34.7e.7f 169.254.158.96 169.254.158.255
got message of size 120 on Tue Sep 15 17:23:39 2009
RTM_ADD: Add Route: len 120, pid 0, seq 0, errno 0, flags: <UP,CLONING>
locks:  inits: 
sockaddrs: <DST,GATEWAY,NETMASK>
 169.254.158.0  255.255.255.0
got message of size 148 on Tue Sep 15 17:23:39 2009
#20: len 148, if# 2, carrier: no carrier, flags: <UP,BROADCAST,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:23:39 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: <pksent,rtt,recvpipe>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.13.1a.03.00.0
got message of size 144 on Tue Sep 15 17:23:39 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
got message of size 148 on Tue Sep 15 17:23:41 2009
#20: len 148, if# 2, carrier: active, flags: <UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:23:41 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: <pksent,rtt,recvpipe,hopcount>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.13.1a.03.00.0
got message of size 144 on Tue Sep 15 17:23:41 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
got message of size 120 on Tue Sep 15 17:27:45 2009
RTM_DELETE: Delete Route: len 120, pid 0, seq 0, errno 0, flags: <CLONING>
locks:  inits: 
sockaddrs: <DST,GATEWAY,NETMASK>
 169.254.158.0  255.255.255.0
got message of size 80 on Tue Sep 15 17:27:45 2009
RTM_DELADDR: address being removed from iface: len 80, metric 0, flags: <CLONING>
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.0 fxp0:0.a.e4.34.7e.7f 169.254.158.96 169.254.158.255
got message of size 148 on Tue Sep 15 17:27:45 2009
#20: len 148, if# 2, carrier: no carrier, flags: <UP,BROADCAST,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:27:45 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: <ssthresh,sendpipe,expire,mtu>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.81.1f.04.00.0
got message of size 144 on Tue Sep 15 17:27:45 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
got message of size 148 on Tue Sep 15 17:27:49 2009
#20: len 148, if# 2, carrier: active, flags: <UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:27:49 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: <ssthresh,sendpipe,recvpipe,hopcount>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.81.1f.04.00.0
got message of size 144 on Tue Sep 15 17:27:49 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
got message of size 80 on Tue Sep 15 17:31:28 2009
RTM_NEWADDR: address being added to iface: len 80, metric 0, flags: <CLONING>
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.0 fxp0:0.a.e4.34.7e.7f 169.254.158.96 169.254.158.255
got message of size 120 on Tue Sep 15 17:31:28 2009
RTM_ADD: Add Route: len 120, pid 0, seq 0, errno 0, flags: <UP,CLONING>
locks:  inits: 
sockaddrs: <DST,GATEWAY,NETMASK>
 169.254.158.0  255.255.255.0
got message of size 148 on Tue Sep 15 17:31:28 2009
#20: len 148, if# 2, carrier: no carrier, flags: <UP,BROADCAST,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:31:28 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: <rttvar,rtt,ssthresh,sendpipe,expire>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.ea.19.05.00.0
got message of size 144 on Tue Sep 15 17:31:28 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
got message of size 148 on Tue Sep 15 17:31:30 2009
#20: len 148, if# 2, carrier: active, flags: <UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:31:30 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: <rttvar,rtt,ssthresh,sendpipe,recvpipe>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.ea.19.05.00.0
got message of size 144 on Tue Sep 15 17:31:30 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
got message of size 120 on Tue Sep 15 17:32:43 2009
RTM_DELETE: Delete Route: len 120, pid 0, seq 0, errno 0, flags: <CLONING>
locks:  inits: 
sockaddrs: <DST,GATEWAY,NETMASK>
 169.254.158.0  255.255.255.0
got message of size 80 on Tue Sep 15 17:32:43 2009
RTM_DELADDR: address being removed from iface: len 80, metric 0, flags: <CLONING>
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.0 fxp0:0.a.e4.34.7e.7f 169.254.158.96 169.254.158.255
got message of size 148 on Tue Sep 15 17:32:43 2009
#20: len 148, if# 2, carrier: no carrier, flags: <UP,BROADCAST,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:32:43 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: <pksent,rtt,sendpipe,recvpipe,expire>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.0b.3b.05.00.0
got message of size 144 on Tue Sep 15 17:32:43 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
got message of size 148 on Tue Sep 15 17:32:45 2009
#20: len 148, if# 2, carrier: active, flags: <UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
got message of size 84 on Tue Sep 15 17:32:45 2009
RTM_OIFINFO: iface status change (pre-1.5): len 84, pid 919046, seq 1500, errno 0, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: <pksent,rtt,ssthresh>
sockaddrs: <GATEWAY>
 (174) af.4a.6e.bb.0b.00.00.00.00.00.0b.3b.05.00.0
got message of size 144 on Tue Sep 15 17:32:45 2009
RTM_IFINFO: iface status change: len 144, pid 919046, seq 0, errno 1500, flags: <UP,GATEWAY,DONE,STATIC,PROTO1>
locks:  inits: 
sockaddrs: <GATEWAY>
 default
### file over

>How-To-Repeat:
Use my IBM Thnikpad R50e computer, and try to acquire an ip address using dhcpcd. (Note that bypassing the link detection efature in dhcpcd makes it work.)
>Fix:
Probably the fxp driver needs to be checked and corrected.

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/42068: fxp address adding or removing causes link changes
Date: Tue, 15 Sep 2009 18:35:44 +0200

 On Tue, Sep 15, 2009 at 04:25:00PM +0000, elentirmo.gilgalad@gmail.com wrote:
 > Probably the fxp driver needs to be checked and corrected.

 Can you please add a printf to the ioctl code in src/sys/dev/ic/i82557.c
 line 221 (at least in -current, maybe slightly offset in netbsd-5) and
 see if it hits the fxp_init() in this block:

                 if (cmd != SIOCADDMULTI && cmd != SIOCDELMULTI)
                         ;
                 else if (ifp->if_flags & IFF_RUNNING) {
                         /*
                          * Multicast list has changed; set the
                          * hardware filter accordingly.
                          */
                         while (sc->sc_txpending) {
                                 sc->sc_flags |= FXPF_WANTINIT;
                                 tsleep(sc, PSOCK, "fxp_init", 0);
                         }
                         error = fxp_init(ifp);
                 }
                 break;

 ?


 Thanks,

 Martin

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/42068: fxp address adding or removing causes link changes
Date: Tue, 15 Sep 2009 18:39:53 +0200

 On Tue, Sep 15, 2009 at 06:35:44PM +0200, Martin Husemann wrote:
 > Can you please add a printf to the ioctl code in src/sys/dev/ic/i82557.c
 > line 221 (at least in -current, maybe slightly offset in netbsd-5) and

 That should be 2210 and it is at 2123 in netbsd-5.

 Martin

From: Gergely =?iso-8859-2?q?G=E1bor?= <elentirmo.gilgalad@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/42068: fxp address adding or removing causes link changes
Date: Wed, 23 Sep 2009 13:02:25 +0200

 --nextPart1614143.Zgs0uhzQfL
 Content-Type: Text/Plain;
   charset="iso-8859-2"
 Content-Transfer-Encoding: quoted-printable

 Greetings!

 I added the code to the apropriate line, noticed, that fxp_init() is hit=20
 everytime address is addedor removed. In other words: when the dropping of =
 a=20
 connection or obtaining of an address happens, i got a nice green kernel=20
 message line stating that the code as in the apropriate section.

 G=E1bor.


 On Tuesday 15 September 2009 18.40.05 Martin Husemann wrote:
 > The following reply was made to PR kern/42068; it has been noted by GNATS.
 >=20
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
 > 	netbsd-bugs@netbsd.org
 > Subject: Re: kern/42068: fxp address adding or removing causes link chang=
 es
 > Date: Tue, 15 Sep 2009 18:35:44 +0200
 >=20
 >  On Tue, Sep 15, 2009 at 04:25:00PM +0000, elentirmo.gilgalad@gmail.com=20
 wrote:
 >  > Probably the fxp driver needs to be checked and corrected.
 >=20
 >  Can you please add a printf to the ioctl code in src/sys/dev/ic/i82557.c
 >  line 221 (at least in -current, maybe slightly offset in netbsd-5) and
 >  see if it hits the fxp_init() in this block:
 >=20
 >                  if (cmd !=3D SIOCADDMULTI && cmd !=3D SIOCDELMULTI)
 >                          ;
 >                  else if (ifp->if_flags & IFF_RUNNING) {
 >                          /*
 >                           * Multicast list has changed; set the
 >                           * hardware filter accordingly.
 >                           */
 >                          while (sc->sc_txpending) {
 >                                  sc->sc_flags |=3D FXPF_WANTINIT;
 >                                  tsleep(sc, PSOCK, "fxp_init", 0);
 >                          }
 >                          error =3D fxp_init(ifp);
 >                  }
 >                  break;
 >=20
 >  ?
 >=20
 >=20
 >  Thanks,
 >=20
 >  Martin
 >=20

 --nextPart1614143.Zgs0uhzQfL
 Content-Type: application/pgp-signature; name=signature.asc 
 Content-Description: This is a digitally signed message part.

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.10 (NetBSD)

 iEYEABECAAYFAkq6AEEACgkQlZGsj+xzT3mTrQCgnkua7afi29gn+gp1Xqxo6vZb
 6VwAoLGsSFKyMoAHQKbTl5U0hCBW8HO+
 =h63c
 -----END PGP SIGNATURE-----

 --nextPart1614143.Zgs0uhzQfL--

From: Gergely =?iso-8859-2?q?G=E1bor?= <elentirmo.gilgalad@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/42068: fxp address adding or removing causes link changes
Date: Thu, 3 Dec 2009 21:15:36 +0100

 --nextPart1645275.BsvMPU9L0W
 Content-Type: Text/Plain;
   charset="iso-8859-2"
 Content-Transfer-Encoding: 7bit

 I have to add, that the problem arises on 5.0.1 also.

 --nextPart1645275.BsvMPU9L0W
 Content-Type: application/pgp-signature; name=signature.asc 
 Content-Description: This is a digitally signed message part.

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.10 (NetBSD)

 iEYEABECAAYFAksYHGgACgkQlZGsj+xzT3lilwCeNkidMrj/QcpYxtOs5YM9Wmpq
 h7UAniCkM5Qtn1OtNBMUVjyEAisyJZ1Z
 =CnhF
 -----END PGP SIGNATURE-----

 --nextPart1645275.BsvMPU9L0W--

Responsible-Changed-From-To: kern-bug-people->martin
Responsible-Changed-By: martin@NetBSD.org
Responsible-Changed-When: Thu, 03 Dec 2009 20:38:19 +0000
Responsible-Changed-Why:
I'll try to look at it this weekend.


From: Gergely =?iso-8859-2?q?G=E1bor?= <elentirmo.gilgalad@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/42068: fxp address adding or removing causes link changes
Date: Thu, 3 Dec 2009 21:49:16 +0100

 OK, Thanks. I'll be mostly around (with some lag) You may find me in email,=
 =20
 thru this bugtracker, and i'll be up on irc.freenode.net in rooms #openrc a=
 nd=20
 #netbsd, so should you need feedback, or info, i'm eager to help, as this i=
 s=20
 primarily my problem not yours, i merely lack the knowledge of the code and=
 =20
 the HW to be able to fix it in reasonable time.

 Yours Sincerely: G=E1bor Gergely

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: dyoung@NetBSD.org
Subject: Re: kern/42068: fxp address adding or removing causes link changes
Date: Tue, 29 Dec 2009 09:26:14 +0100

 --zhXaljGHf11kAtnf
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline

 Hi Gabor,

 the attached patch against -current (and only very lightly tested) seems to
 work for me. Could you test if this fixes it for you too please?

 Dave, could you please review?

 Thanks,

 Martin

 --zhXaljGHf11kAtnf
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename=patch

 Index: i82557.c
 ===================================================================
 RCS file: /cvsroot/src/sys/dev/ic/i82557.c,v
 retrieving revision 1.130
 diff -c -u -p -r1.130 i82557.c
 --- i82557.c	15 Sep 2009 19:20:30 -0000	1.130
 +++ i82557.c	29 Dec 2009 08:24:02 -0000
 @@ -2186,10 +2186,11 @@ fxp_ioctl(struct ifnet *ifp, u_long cmd,
  {
  	struct fxp_softc *sc = ifp->if_softc;
  	struct ifreq *ifr = (struct ifreq *)data;
 -	int s, error;
 +	int s, error, allm;

  	s = splnet();

 +	allm = ifp->if_flags & IFF_ALLMULTI;
  	switch (cmd) {
  	case SIOCSIFMEDIA:
  	case SIOCGIFMEDIA:
 @@ -2213,7 +2214,13 @@ fxp_ioctl(struct ifnet *ifp, u_long cmd,
  				sc->sc_flags |= FXPF_WANTINIT;
  				tsleep(sc, PSOCK, "fxp_init", 0);
  			}
 -			error = fxp_init(ifp);
 +
 +			ifp->if_timer = 0;
 +			ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE);
 +			callout_stop(&sc->sc_callout);
 +			fxp_mc_setup(sc);
 +			if ((ifp->if_flags & IFF_ALLMULTI) != allm)
 +				error = fxp_init(ifp);
  		}
  		break;
  	}

 --zhXaljGHf11kAtnf--

From: Gergely =?iso-8859-2?q?G=E1bor?= <elentirmo.gilgalad@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/42068: fxp address adding or removing causes link changes
Date: Wed, 30 Dec 2009 23:00:13 +0100

 --nextPart7092826.MmijMhWTOO
 Content-Type: Text/Plain;
   charset="iso-8859-2"
 Content-Transfer-Encoding: quoted-printable

 Greetings!

 Sorry Martin, but after trying the patch, I have to report it did not fix t=
 he=20
 problem. although it did significantly change the erroneous behaviour :)

 Now ifconfig can see if the network cable is plugged in, or not, but other=
 =20
 tools cannot. I did try ifwatchd and dhcpcd, and both believe that the=20
 interface is always down. To complicate, dhcpcd could not bring it up (for=
 =20
 longer than a wink of an eye) either, not even with the -K (disable link=20
 status detection) switch!

 Pasting simultaneous dhcpcd and ifwatchd run outputs:

 dhcpcd:=20
 root@hunyadi:~ # dhcpcd -dBK fxp0                                          =
  =20
 dhcpcd - - - version 5.1.3 starting
 dhcpcd - - - fxp0: executing `/libexec/dhcpcd-run-hooks', reason PREINIT
 dhcpcd - - - fxp0: reading lease `/var/db/dhcpcd-fxp0.lease'
 dhcpcd - - - fxp0: checking for 169.254.61.184
 dhcpcd - - - fxp0: sending ARP probe (1 of 3), next in 1.40 seconds
 dhcpcd - - - send_arp: Network is down
 dhcpcd - - - fxp0: sending ARP probe (2 of 3), next in 1.66 seconds
 dhcpcd - - - send_arp: Network is down
 dhcpcd - - - fxp0: sending ARP probe (3 of 3), next in 2.00 seconds
 dhcpcd - - - send_arp: Network is down
 dhcpcd - - - fxp0: using IPv4LL address 169.254.61.184
 dhcpcd - - - fxp0: adding IP address 169.254.61.184/16
 dhcpcd - - - fxp0: adding route to 169.254.0.0/16
 dhcpcd - - - fxp0: executing `/libexec/dhcpcd-run-hooks', reason IPV4LL
 dhcpcd - - - fxp0: sending ARP announce (1 of 2), next in 2.00 seconds
 dhcpcd - - - send_arp: Network is down
 dhcpcd - - - fxp0: sending ARP announce (2 of 2)
 dhcpcd - - - send_arp: Network is down
 dhcpcd - - - fxp0: broadcasting for a lease
 dhcpcd - - - fxp0: sending DHCP_DISCOVER (xid 0x22b9e70d), next in 3.01=20
 seconds
 dhcpcd - - - fxp0: send_raw_packet: Network is down
 dhcpcd - - - fxp0: deleting route to 169.254.0.0/16
 dhcpcd - - - fxp0: deleting IP address 169.254.61.184/16
 dhcpcd - - - fxp0: executing `/libexec/dhcpcd-run-hooks', reason FAIL

 ifwatch did produce the following output (ignore the error messages,I proba=
 bly=20
 did not write completely good dummy scripts.)
 calling: up fxp0 /dev/null 9600 169.254.61.184 169.254.255.255
 up: Bad file descriptor
 calling: carrier fxp0 /dev/null 9600 =20
 carrier: Bad file descriptor
 unknown message ignored (14)
 unknown message ignored (15)
 calling: no-carrier fxp0 /dev/null 9600 =20
 no-carrier: Bad file descriptor
 unknown message ignored (14)
 unknown message ignored (15)
 calling: carrier fxp0 /dev/null 9600 =20
 carrier: Bad file descriptor
 unknown message ignored (14)
 unknown message ignored (15)
 calling: no-carrier fxp0 /dev/null 9600 =20
 no-carrier: Bad file descriptor
 unknown message ignored (14)
 unknown message ignored (15)
 calling: up fxp0 /dev/null 9600 169.254.61.184 169.254.255.255
 up: Bad file descriptor
 calling: carrier fxp0 /dev/null 9600 =20
 carrier: Bad file descriptor
 unknown message ignored (14)
 unknown message ignored (15)

 This is all I can think of being relevant, if I forgot anything, feel free =
 to=20
 notify me, and I will do my bast to help. Thanks for your help, and Happy N=
 ew=20
 Year!

 Greetings: G=E1bor Gergely

 --nextPart7092826.MmijMhWTOO
 Content-Type: application/pgp-signature; name=signature.asc 
 Content-Description: This is a digitally signed message part.

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.10 (NetBSD)

 iEYEABECAAYFAks7zW4ACgkQlZGsj+xzT3mafwCgtngbNIuu5IyZEbWMPZqrlHff
 hJYAn1WMS8M0qBzjHwW+pXt/XL/gDnA/
 =61mv
 -----END PGP SIGNATURE-----

 --nextPart7092826.MmijMhWTOO--

From: David Young <dyoung@pobox.com>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/42068: fxp address adding or removing causes link changes
Date: Tue, 5 Jan 2010 19:06:12 -0600

 On Tue, Dec 29, 2009 at 09:26:14AM +0100, Martin Husemann wrote:
 > Hi Gabor,
 > 
 > the attached patch against -current (and only very lightly tested) seems to
 > work for me. Could you test if this fixes it for you too please?
 > 
 > Dave, could you please review?

 The patch clears IFF_RUNNING (why?) and does not restore it.  On my
 machine, IFF_RUNNING remains clear, so fxp(4) does not operate.

 Dave

 -- 
 David Young             OJC Technologies
 dyoung@ojctech.com      Urbana, IL * (217) 278-3933

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.