NetBSD Problem Report #29126
From www@netbsd.org Wed Jan 26 14:02:31 2005
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
id BB74963B843; Wed, 26 Jan 2005 14:02:31 +0000 (UTC)
Message-Id: <20050126140231.BB74963B843@narn.netbsd.org>
Date: Wed, 26 Jan 2005 14:02:31 +0000 (UTC)
From: zafer@gmx.org
Reply-To: zafer@gmx.org
To: gnats-bugs@netbsd.org
Subject: tcpdump leads to packet loss
X-Send-Pr-Version: www-1.0
>Number: 29126
>Notify-List: freza@netbsd.org erh@netbsd.org
>Category: kern
>Synopsis: tcpdump leads to packet loss
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: analyzed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Jan 26 14:03:00 +0000 2005
>Closed-Date:
>Last-Modified: Sun Jan 05 14:04:34 +0000 2020
>Originator: Zafer Aydogan
>Release: 2.99.15
>Organization:
>Environment:
2.99.15 GENERIC i386
>Description:
Starting tcpdump with or without arguments leads to heavy packet loss, (like freezing all connections, up to 15 seconds) until the first packets are seen on the screen from the dump. During dump flow, no packet loss is detected, but same scenario happens if you stop tcpdump with CTRL-C. Again heavy packet loss. This can lead to break established connections (ssh for example). Maybe this is NIC related. I'm using an ex0 (3com 3c905 txm) Network Card. Verified on 2.99.10 and 2.99.15.
>How-To-Repeat:
open a ssh connection to another host. on this host display top with one second delay. now start tcpdump on your local machine and watch the time from top. time stops until tcpdump start printing packets. time stops again when stopping tcpdump.
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: bin-bug-people->kern-bug-people
Responsible-Changed-By: martin@netbsd.org
Responsible-Changed-When: Wed, 26 Jan 2005 15:58:55 +0000
Responsible-Changed-Why:
This is a kernel problem - the driver switches the NIC to/out of promiscous
mode.
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Wed, 26 Jan 2005 19:17:34 +0100
On Wed, Jan 26, 2005 at 02:03:00PM +0000, zafer@gmx.org wrote:
> Starting tcpdump with or without arguments leads to heavy packet loss, (like freezing all connections, up to 15 seconds) until the first packets are seen on the screen from the dump. During dump flow, no packet loss is detected, but same scenario happens if you stop tcpdump with CTRL-C. Again heavy packet loss. This can lead to break established connections (ssh for example). Maybe this is NIC related. I'm using an ex0 (3com 3c905 txm) Network Card. Verified on 2.99.10 and 2.99.15.
This is because the driver reset the adapter when changing promiscous mode,
which also has the effect of taking the link down (so media settings have to
be renegotiated with the remote end. If you have spanning tree enabled,
you're also hit by a spanning-tree cold restart). I don't know if, for
this particular nic it's possible to enable/disable promiscous mode without
resetting the adapter. Some drivers could possibly be smarter here, but
it's definitively nic-dependant.
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
NetBSD: 26 ans d'experience feront toujours la difference
--
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Wed, 26 Jan 2005 15:29:17 -0500
On Jan 26, 6:17pm, bouyer@antioche.lip6.fr (Manuel Bouyer) wrote:
-- Subject: Re: bin/29126: tcpdump leads to packet loss
| The following reply was made to PR kern/29126; it has been noted by GNATS.
|
| From: Manuel Bouyer <bouyer@antioche.lip6.fr>
| To: gnats-bugs@NetBSD.org
| Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
| Subject: Re: bin/29126: tcpdump leads to packet loss
| Date: Wed, 26 Jan 2005 19:17:34 +0100
|
| On Wed, Jan 26, 2005 at 02:03:00PM +0000, zafer@gmx.org wrote:
| > Starting tcpdump with or without arguments leads to heavy packet loss, (like freezing all connections, up to 15 seconds) until the first packets are seen on the screen from the dump. During dump flow, no packet loss is detected, but same scenario happens if you stop tcpdump with CTRL-C. Again heavy packet loss. This can lead to break established connections (ssh for example). Maybe this is NIC related. I'm using an ex0 (3com 3c905 txm) Network Card. Verified on 2.99.10 and 2.99.15.
|
| This is because the driver reset the adapter when changing promiscous mode,
| which also has the effect of taking the link down (so media settings have to
| be renegotiated with the remote end. If you have spanning tree enabled,
| you're also hit by a spanning-tree cold restart). I don't know if, for
| this particular nic it's possible to enable/disable promiscous mode without
| resetting the adapter. Some drivers could possibly be smarter here, but
| it's definitively nic-dependant.
And you can set the spanning tree port to be 'smart', i.e. not to restart
negotiation immediately.,
christos
From: kim@tac.nyc.ny.us (Kimmo Suominen)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Thu, 27 Jan 2005 11:05:26 -0500 (EST)
I see the loss of traffic also happening on tlp and gsip and using dumb
switches (i.e. no STP in use).
It definitely was not happening with earlier versions of NetBSD.
The only "old" version I have around anymore is 1.6B. The NIC's I have
on that are fxp and tlp. Neither one exhibits this problem.
How to test: start tcpdump on the interface you are connected over,
and hit RETURN repeatedly to verify if tty echoes it back immediately.
inet-fw:~# tcpdump -i tlp0 port 22
tcpdump: listening on tlp0
17:59:57.387560 inet-fw.xxx.xxx.ssh > beowulf.gw.com.63960: [...]
The empty lines above are the tty driver echoing my RETURN keypresses.
With 2.99.x there is no echoback until the network resumes functioning.
If this is a NIC driver issue, then it would need to be an change made
to at least ex, gsip and tlp, since I don't recall the problem with any
of them with earlier versions.
I hope this helps.
Regards,
+ Kim
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Thu, 27 Jan 2005 11:39:25 -0500
On Jan 27, 4:06pm, kim@tac.nyc.ny.us (Kimmo Suominen) wrote:
-- Subject: Re: bin/29126: tcpdump leads to packet loss
| The following reply was made to PR kern/29126; it has been noted by GNATS.
|
| From: kim@tac.nyc.ny.us (Kimmo Suominen)
| To: gnats-bugs@netbsd.org
| Cc:
| Subject: Re: bin/29126: tcpdump leads to packet loss
| Date: Thu, 27 Jan 2005 11:05:26 -0500 (EST)
|
| I see the loss of traffic also happening on tlp and gsip and using dumb
| switches (i.e. no STP in use).
|
| It definitely was not happening with earlier versions of NetBSD.
|
| The only "old" version I have around anymore is 1.6B. The NIC's I have
| on that are fxp and tlp. Neither one exhibits this problem.
|
| How to test: start tcpdump on the interface you are connected over,
| and hit RETURN repeatedly to verify if tty echoes it back immediately.
|
| inet-fw:~# tcpdump -i tlp0 port 22
| tcpdump: listening on tlp0
|
Some nics reset the interface when they enter or exit promiscuous mode,
dropping link. If you are connected over a switch
that does spanning tree it might take some time to recalc. During that
time, the network does not work at all over that interface.
christos
From: kim@tac.nyc.ny.us (Kimmo Suominen)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Thu, 27 Jan 2005 12:05:52 -0500 (EST)
In gmane.os.netbsd.bugs you write:
| On Jan 27, 4:06pm, kim@tac.nyc.ny.us (Kimmo Suominen) wrote:
| -- Subject: Re: bin/29126: tcpdump leads to packet loss
|
| | I see the loss of traffic also happening on tlp and gsip and using dumb
| | switches (i.e. no STP in use).
|
| Some nics reset the interface when they enter or exit promiscuous mode,
| dropping link. If you are connected over a switch
| that does spanning tree it might take some time to recalc. During that
| time, the network does not work at all over that interface.
By "no STP" I meant "no Spanning Tree Protocol"...
I really do think this is a problem introduced in NetBSD. The network
setup has not changed where I see the problem.
When was STP added to the NetBSD bridge? Could that be the problem?
Would it affect NIC's that are not even participating in a bridge?
+ Kim
From: Kimmo Suominen <kim@tac.nyc.ny.us>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Thu, 27 Jan 2005 12:48:56 -0500
I can also reproduce this with fxp on NetBSD 2.99.12. As you can see
from my previous messages, the problem does not exist with fxp on 1.6B.
So, the list of problem NIC's drivers: ex, fxp, gsip, tlp
Christos & Manuel: which drivers are you using that do not exhibit
this problem at all?
Regards,
+ Kim
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>
From: jukka@salmi.ch
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Thu, 27 Jan 2005 19:10:37 +0100
Kimmo Suominen wrote:
> So, the list of problem NIC's drivers: ex, fxp, gsip, tlp
>
> Christos & Manuel: which drivers are you using that do not exhibit
> this problem at all?
I just tried to reproduce the problem on a i386 system with two
ethernet NICs running NetBSD 2.0_STABLE with the following results:
- ex exhibits the problem (as reported before)
- rtk does _not_ exhibit the problem
Partial dmesg output from the machine in question:
NetBSD 2.0_STABLE (GENERIC) #0: Wed Jan 19 13:45:35 CET 2005
[...]
ex0 at pci0 dev 8 function 0: 3Com 3c905C-TX 10/100 Ethernet with mngmt (rev. 0x
74)
ex0: interrupting at irq 11
ex0: MAC address 00:01:02:37:ed:2b
bmtphy0 at ex0 phy 24: Broadcom 3c905C internal PHY, rev. 6
bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
[...]
rtk0 at pci0 dev 14 function 0: Realtek 8139 10/100BaseTX
rtk0: interrupting at irq 10
rtk0: Ethernet address 00:11:5b:27:43:f9
ukphy0 at rtk0 phy 7: Generic IEEE 802.3u media interface
ukphy0: OUI 0x000000, model 0x0000, rev. 0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
HTH, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Thu, 27 Jan 2005 19:39:19 +0100
On Thu, Jan 27, 2005 at 05:49:01PM +0000, Kimmo Suominen wrote:
> I can also reproduce this with fxp on NetBSD 2.99.12. As you can see
> from my previous messages, the problem does not exist with fxp on 1.6B.
>
> So, the list of problem NIC's drivers: ex, fxp, gsip, tlp
>
> Christos & Manuel: which drivers are you using that do not exhibit
> this problem at all?
I don't have the problem with wm on 1.6.2. I have it with epic and ex, even on
1.6.2.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: john heasley <heas@shrubbery.net>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Thu, 27 Jan 2005 11:21:23 -0800
Thu, Jan 27, 2005 at 05:49:01PM +0000, Kimmo Suominen:
> I can also reproduce this with fxp on NetBSD 2.99.12. As you can see
> from my previous messages, the problem does not exist with fxp on 1.6B.
>
> So, the list of problem NIC's drivers: ex, fxp, gsip, tlp
>
> Christos & Manuel: which drivers are you using that do not exhibit
> this problem at all?
Most likely any driver that does not handle SIOCSIFFLAGS itself. ether_ioctl
does:
case SIOCSIFFLAGS:
....
} else if ((ifp->if_flags & IFF_UP) != 0) {
/*
* Reset the interface to pick up changes in any other
* flags that affect the hardware state.
*/
error = (*ifp->if_init)(ifp);
}
for most drivers that i've looked at, the first thing the init function
does is stop the chip and reset it. hme deals with it like this:
case SIOCSIFFLAGS:
...
} else if ((ifp->if_flags & IFF_UP) != 0) {
/*
* If setting debug or promiscuous mode, do not reset
* the chip; for everything else, call hme_init()
* which will trigger a reset.
*/
#define RESETIGN (IFF_CANTCHANGE | IFF_DEBUG)
if (ifp->if_flags == sc->sc_if_flags)
break;
if ((ifp->if_flags & (~RESETIGN))
== (sc->sc_if_flags & (~RESETIGN)))
hme_setladrf(sc);
else
hme_init(sc);
#undef RESETIGN
}
From: Kimmo Suominen <kim@tac.nyc.ny.us>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/29126: tcpdump leads to packet loss
Date: Thu, 27 Jan 2005 16:10:49 -0500
I have a 1.6.2 laptop with ex and tqphy. Neither the 1.6.2 nor the 2.0
GENERIC_LAPTOP kernel exhibits the problem (1.6.2 userland in both cases).
-------------------------------------------------------------------------
nocport:~# uname -a
NetBSD nocport 1.6.2 NetBSD 1.6.2 (GENERIC_LAPTOP) #0: Tue Feb 10 22:02:37 UTC 2004 autobuild@tgm.netbsd.org:/autobuild/netbsd-1-6-PATCH002/i386/OBJ/autobuild/netbsd-1-6-PATCH002/src/sys/arch/i386/compile/GENERIC_LAPTOP i386
ex0 at pci0 dev 16 function 0: 3Com 3c556 MiniPCI 10/100 Ethernet (rev. 0x10)
ex0: interrupting at irq 11
ex0: MAC address 00:04:76:47:06:96
tqphy0 at ex0 phy 0: 78Q2120 10/100 media interface, rev. 11
tqphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
-------------------------------------------------------------------------
nocport:~# uname -a
NetBSD nocport 2.0 NetBSD 2.0 (GENERIC_LAPTOP) #0: Wed Dec 1 11:01:08 UTC 2004 builds@build:/big/builds/ab/netbsd-2-0-RELEASE/i386/200411300000Z-obj/big/builds/ab/netbsd-2-0-RELEASE/src/sys/arch/i386/compile/GENERIC_LAPTOP i386
ex0 at pci0 dev 16 function 0: 3Com 3c556 MiniPCI 10/100 Ethernet (rev. 0x10)
ex0: interrupting at irq 11
ex0: MAC address 00:04:76:47:06:96
tqphy0 at ex0 phy 0: 78Q2120 10/100 media interface, rev. 11
tqphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
-------------------------------------------------------------------------
I did not change /dev or anything else apart from replacing /netbsd and
rebooting.
For reference, the NetBSD 2.99.12 machines where I can reproduce the problem
all have the same kernel, and the following interfaces:
-------------------------------------------------------------------------
NetBSD grendel.gw.com 2.99.12 NetBSD 2.99.12 (GW-GENERIC) #99: Sat Jan 15 10:04:29 EST 2005 kim@hrothgar.gw.com:/usr/src/sys/arch/i386/compile/GW-GENERIC i386
ex0 at pci0 dev 14 function 0: 3Com 3c905-TX 10/100 Ethernet (rev. 0x0)
ex0: interrupting at irq 11
ex0: MAC address 00:60:08:c6:33:2c
nsphy0 at ex0 phy 24: DP83840 10/100 media interface, rev. 1
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
gsip0 at pci0 dev 9 function 0: NatSemi DP83820 Gigabit Ethernet, rev 00
gsip0: interrupting at ioapic0 pin 17 (irq 5)
gsip0: Ethernet address 00:04:e2:1c:75:2e
gphyter0 at gsip0 phy 1: DP83861 1000BASE-T media interface, rev. 2
gphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
gphyter0: strapped to slave mode, pre-C5 BCM5400 compat enabled
tlp0 at pci2 dev 4 function 0: DECchip 21140A Ethernet, pass 2.2
tlp0: interrupting at irq 11
tlp0: Adaptec ANA-6944A, Ethernet address 00:00:92:a7:dd:8c
nsphy0 at tlp0 phy 1: DP83840 10/100 media interface, rev. 1
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
tlp1 at pci2 dev 5 function 0: DECchip 21140A Ethernet, pass 2.2
tlp1: sharing interrupt with tlp0
tlp1: Adaptec ANA-6944A, Ethernet address 00:00:92:a7:dd:8d
nsphy1 at tlp1 phy 1: DP83840 10/100 media interface, rev. 1
nsphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
tlp2 at pci2 dev 6 function 0: DECchip 21140A Ethernet, pass 2.2
tlp2: sharing interrupt with tlp0
tlp2: Adaptec ANA-6944A, Ethernet address 00:00:92:a7:dd:8e
nsphy2 at tlp2 phy 1: DP83840 10/100 media interface, rev. 1
nsphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
tlp3 at pci2 dev 7 function 0: DECchip 21140A Ethernet, pass 2.2
tlp3: sharing interrupt with tlp0
tlp3: Adaptec ANA-6944A, Ethernet address 00:00:92:a7:dd:8f
nsphy3 at tlp3 phy 1: DP83840 10/100 media interface, rev. 1
nsphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
-------------------------------------------------------------------------
Manuel -- what userland, and what exact ex and phy do you have on the
1.6.2 machine that has the problem?
Regards,
+ Kim
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>
From: Kimmo Suominen <kim@tac.nyc.ny.us>
To: gnats-bugs@netbsd.org
Cc: Christos Zoulas <christos@zoulas.com>,
Arto Selonen <arto@selonen.org>
Subject: Re: kern/29126: tcpdump leads to packet loss
Date: Sat, 5 Feb 2005 19:15:20 -0500
And the changes below fix ex for me...
Regards,
+ Kim
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>
Index: elinkxl.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/elinkxl.c,v
retrieving revision 1.75
diff -u -r1.75 elinkxl.c
--- elinkxl.c 30 Oct 2004 18:08:36 -0000 1.75
+++ elinkxl.c 6 Feb 2005 00:02:41 -0000
@@ -427,6 +427,7 @@
ifp->if_stop = ex_stop;
ifp->if_flags =
IFF_BROADCAST | IFF_SIMPLEX | IFF_NOTRAILERS | IFF_MULTICAST;
+ sc->sc_if_flags = ifp->if_flags;
IFQ_SET_READY(&ifp->if_snd);
/*
@@ -697,6 +698,7 @@
ifp->if_flags |= IFF_RUNNING;
ifp->if_flags &= ~IFF_OACTIVE;
ex_start(ifp);
+ sc->sc_if_flags = ifp->if_flags;
GO_WINDOW(1);
@@ -1382,7 +1384,21 @@
case SIOCGIFMEDIA:
error = ifmedia_ioctl(ifp, ifr, &sc->ex_mii.mii_media, cmd);
break;
-
+ case SIOCSIFFLAGS:
+ /* If the interface is up and running, only modify the receive
+ * filter when setting promiscuous or debug mode. Otherwise
+ * fall through to ether_ioctl, which will reset the chip.
+ */
+#define RESETIGN (IFF_CANTCHANGE|IFF_DEBUG)
+ if (((ifp->if_flags & (IFF_UP|IFF_RUNNING))
+ == (IFF_UP|IFF_RUNNING))
+ && ((ifp->if_flags & (~RESETIGN))
+ == (sc->sc_if_flags & (~RESETIGN)))) {
+ ex_set_mc(sc);
+ error = 0;
+#undef RESETIGN
+ } else
+ /* FALLTHROUGH */
default:
error = ether_ioctl(ifp, cmd, data);
if (error == ENETRESET) {
@@ -1397,6 +1413,7 @@
break;
}
+ sc->sc_if_flags = ifp->if_flags;
splx(s);
return (error);
}
@@ -1569,6 +1586,7 @@
ex_disable(sc);
ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE);
+ sc->sc_if_flags = ifp->if_flags;
ifp->if_timer = 0;
}
Index: elinkxlvar.h
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/elinkxlvar.h,v
retrieving revision 1.14
diff -u -r1.14 elinkxlvar.h
--- elinkxlvar.h 5 Jun 2003 22:11:22 -0000 1.14
+++ elinkxlvar.h 6 Feb 2005 00:02:41 -0000
@@ -137,6 +137,8 @@
bus_dma_segment_t sc_useg, sc_dseg;
int sc_urseg, sc_drseg;
+
+ short sc_if_flags;
};
#define ex_waitcmd(sc) \
From: Kimmo Suominen <kim@tac.nyc.ny.us>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/29126: tcpdump leads to packet loss
Date: Sat, 5 Feb 2005 19:17:31 -0500
[Resending...]
The patch below would appear to fix this for gsip (I don't have a sip
card to test with). I'm basically copying the idea from the hme driver,
as pointed out by John: ignore changes in internal-only flags.
I've tested downing and re-upping the interface as well as adding and
removing an inet alias. Seems to work for me... :-)
I'll look at ex next, then tlp.
Regards,
+ Kim
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>
Index: if_sip.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_sip.c,v
retrieving revision 1.97
diff -u -r1.97 if_sip.c
--- if_sip.c 30 Jan 2005 18:56:34 -0000 1.97
+++ if_sip.c 5 Feb 2005 23:23:06 -0000
@@ -309,6 +309,8 @@
struct sip_txsq sc_txfreeq; /* free Tx descsofts */
struct sip_txsq sc_txdirtyq; /* dirty Tx descsofts */
+ short sc_if_flags;
+
int sc_rxptr; /* next ready Rx descriptor/descsoft */
#if defined(DP83820)
int sc_rxdiscard;
@@ -979,6 +981,7 @@
strcpy(ifp->if_xname, sc->sc_dev.dv_xname);
ifp->if_softc = sc;
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
+ sc->sc_if_flags = ifp->if_flags;
ifp->if_ioctl = SIP_DECL(ioctl);
ifp->if_start = SIP_DECL(start);
ifp->if_watchdog = SIP_DECL(watchdog);
@@ -1551,7 +1554,22 @@
case SIOCGIFMEDIA:
error = ifmedia_ioctl(ifp, ifr, &sc->sc_mii.mii_media, cmd);
break;
-
+ case SIOCSIFFLAGS:
+ /* If the interface is up and running, only modify the receive
+ * filter when setting promiscuous or debug mode. Otherwise
+ * fall through to ether_ioctl, which will reset the chip.
+ */
+#define RESETIGN (IFF_CANTCHANGE|IFF_DEBUG)
+ if (((ifp->if_flags & (IFF_UP|IFF_RUNNING))
+ == (IFF_UP|IFF_RUNNING))
+ && ((ifp->if_flags & (~RESETIGN))
+ == (sc->sc_if_flags & (~RESETIGN)))) {
+ /* Set up the receive filter. */
+ (*sc->sc_model->sip_variant->sipv_set_filter)(sc);
+ error = 0;
+#undef RESETIGN
+ } else
+ /* FALLTHROUGH */
default:
error = ether_ioctl(ifp, cmd, data);
if (error == ENETRESET) {
@@ -1569,6 +1587,7 @@
/* Try to get more packets going. */
SIP_DECL(start)(ifp);
+ sc->sc_if_flags = ifp->if_flags;
splx(s);
return (error);
}
@@ -2542,6 +2561,7 @@
*/
ifp->if_flags |= IFF_RUNNING;
ifp->if_flags &= ~IFF_OACTIVE;
+ sc->sc_if_flags = ifp->if_flags;
out:
if (error)
From: Kimmo Suominen <kim@tac.nyc.ny.us>
To: gnats-bugs@netbsd.org
Cc: Christos Zoulas <christos@zoulas.com>,
Arto Selonen <arto@selonen.org>
Subject: Re: kern/29126: tcpdump leads to packet loss
Date: Sat, 5 Feb 2005 19:52:17 -0500
And a tlp patch is below...
I've made the patches available over FTP (probably easier than trying
to extract them from GNATS).
ftp://ftp.gw.com/pub/people/kim/netbsd/netbsd-2.99.15-tcpdump-ex.diff
ftp://ftp.gw.com/pub/people/kim/netbsd/netbsd-2.99.15-tcpdump-gsip.diff
ftp://ftp.gw.com/pub/people/kim/netbsd/netbsd-2.99.15-tcpdump-tlp.diff
Regards,
+ Kim
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>
Index: tulip.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/tulip.c,v
retrieving revision 1.131
diff -u -r1.131 tulip.c
--- tulip.c 30 Jan 2005 17:27:38 -0000 1.131
+++ tulip.c 6 Feb 2005 00:32:34 -0000
@@ -497,6 +497,7 @@
strcpy(ifp->if_xname, sc->sc_dev.dv_xname);
ifp->if_softc = sc;
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
+ sc->sc_if_flags = ifp->if_flags;
ifp->if_ioctl = tlp_ioctl;
ifp->if_start = tlp_start;
ifp->if_watchdog = tlp_watchdog;
@@ -1001,7 +1002,22 @@
case SIOCGIFMEDIA:
error = ifmedia_ioctl(ifp, ifr, &sc->sc_mii.mii_media, cmd);
break;
-
+ case SIOCSIFFLAGS:
+ /* If the interface is up and running, only modify the receive
+ * filter when setting promiscuous or debug mode. Otherwise
+ * fall through to ether_ioctl, which will reset the chip.
+ */
+#define RESETIGN (IFF_CANTCHANGE|IFF_DEBUG)
+ if (((ifp->if_flags & (IFF_UP|IFF_RUNNING))
+ == (IFF_UP|IFF_RUNNING))
+ && ((ifp->if_flags & (~RESETIGN))
+ == (sc->sc_if_flags & (~RESETIGN)))) {
+ /* Set up the receive filter. */
+ (*sc->sc_filter_setup)(sc);
+ error = 0;
+#undef RESETIGN
+ } else
+ /* FALLTHROUGH */
default:
error = ether_ioctl(ifp, cmd, data);
if (error == ENETRESET) {
@@ -1021,6 +1037,7 @@
if (TULIP_IS_ENABLED(sc))
tlp_start(ifp);
+ sc->sc_if_flags = ifp->if_flags;
splx(s);
return (error);
}
@@ -1930,6 +1947,7 @@
*/
ifp->if_flags |= IFF_RUNNING;
ifp->if_flags &= ~IFF_OACTIVE;
+ sc->sc_if_flags = ifp->if_flags;
out:
if (error) {
@@ -2094,6 +2112,7 @@
* Mark the interface down and cancel the watchdog timer.
*/
ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE);
+ sc->sc_if_flags = ifp->if_flags;
ifp->if_timer = 0;
/*
Index: tulipvar.h
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/tulipvar.h,v
retrieving revision 1.51
diff -u -r1.51 tulipvar.h
--- tulipvar.h 24 Oct 2004 00:35:08 -0000 1.51
+++ tulipvar.h 6 Feb 2005 00:32:35 -0000
@@ -451,6 +451,8 @@
struct tulip_txsq sc_txfreeq; /* free Tx descsofts */
struct tulip_txsq sc_txdirtyq; /* dirty Tx descsofts */
+ short sc_if_flags;
+
int sc_rxptr; /* next ready RX descriptor/descsoft */
#if NRND > 0
Responsible-Changed-From-To: kern-bug-people->kim
Responsible-Changed-By: kim@netbsd.org
Responsible-Changed-When: Sun, 06 Feb 2005 00:56:42 +0000
Responsible-Changed-Why:
I'll care for this one.
State-Changed-From-To: open->feedback
State-Changed-By: kim@netbsd.org
State-Changed-When: Sun, 06 Feb 2005 00:56:42 +0000
State-Changed-Why:
Zafer,
Please try out the patch for the ex driver, and let me know if it
works for you.
Regards,
+ Kim
From: christos@zoulas.com (Christos Zoulas)
To: Kimmo Suominen <kim@tac.nyc.ny.us>, gnats-bugs@netbsd.org
Cc: Arto Selonen <arto@selonen.org>
Subject: Re: kern/29126: tcpdump leads to packet loss
Date: Sat, 5 Feb 2005 21:28:55 -0500
On Feb 5, 7:15pm, kim@tac.nyc.ny.us (Kimmo Suominen) wrote:
-- Subject: Re: kern/29126: tcpdump leads to packet loss
| And the changes below fix ex for me...
again, fix the } else and commit it.
christos
|
| Regards,
| + Kim
| --
| <A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>
|
|
| Index: elinkxl.c
| ===================================================================
| RCS file: /cvsroot/src/sys/dev/ic/elinkxl.c,v
| retrieving revision 1.75
| diff -u -r1.75 elinkxl.c
| --- elinkxl.c 30 Oct 2004 18:08:36 -0000 1.75
| +++ elinkxl.c 6 Feb 2005 00:02:41 -0000
| @@ -427,6 +427,7 @@
| ifp->if_stop = ex_stop;
| ifp->if_flags =
| IFF_BROADCAST | IFF_SIMPLEX | IFF_NOTRAILERS | IFF_MULTICAST;
| + sc->sc_if_flags = ifp->if_flags;
| IFQ_SET_READY(&ifp->if_snd);
|
| /*
| @@ -697,6 +698,7 @@
| ifp->if_flags |= IFF_RUNNING;
| ifp->if_flags &= ~IFF_OACTIVE;
| ex_start(ifp);
| + sc->sc_if_flags = ifp->if_flags;
|
| GO_WINDOW(1);
|
| @@ -1382,7 +1384,21 @@
| case SIOCGIFMEDIA:
| error = ifmedia_ioctl(ifp, ifr, &sc->ex_mii.mii_media, cmd);
| break;
| -
| + case SIOCSIFFLAGS:
| + /* If the interface is up and running, only modify the receive
| + * filter when setting promiscuous or debug mode. Otherwise
| + * fall through to ether_ioctl, which will reset the chip.
| + */
| +#define RESETIGN (IFF_CANTCHANGE|IFF_DEBUG)
| + if (((ifp->if_flags & (IFF_UP|IFF_RUNNING))
| + == (IFF_UP|IFF_RUNNING))
| + && ((ifp->if_flags & (~RESETIGN))
| + == (sc->sc_if_flags & (~RESETIGN)))) {
| + ex_set_mc(sc);
| + error = 0;
| +#undef RESETIGN
| + } else
| + /* FALLTHROUGH */
| default:
| error = ether_ioctl(ifp, cmd, data);
| if (error == ENETRESET) {
| @@ -1397,6 +1413,7 @@
| break;
| }
|
| + sc->sc_if_flags = ifp->if_flags;
| splx(s);
| return (error);
| }
| @@ -1569,6 +1586,7 @@
| ex_disable(sc);
|
| ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE);
| + sc->sc_if_flags = ifp->if_flags;
| ifp->if_timer = 0;
| }
|
| Index: elinkxlvar.h
| ===================================================================
| RCS file: /cvsroot/src/sys/dev/ic/elinkxlvar.h,v
| retrieving revision 1.14
| diff -u -r1.14 elinkxlvar.h
| --- elinkxlvar.h 5 Jun 2003 22:11:22 -0000 1.14
| +++ elinkxlvar.h 6 Feb 2005 00:02:41 -0000
| @@ -137,6 +137,8 @@
|
| bus_dma_segment_t sc_useg, sc_dseg;
| int sc_urseg, sc_drseg;
| +
| + short sc_if_flags;
| };
|
| #define ex_waitcmd(sc) \
-- End of excerpt from Kimmo Suominen
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/29126: tcpdump leads to packet loss
Date: Sat, 5 Feb 2005 21:29:51 -0500
On Feb 6, 12:53am, kim@tac.nyc.ny.us (Kimmo Suominen) wrote:
-- Subject: Re: kern/29126: tcpdump leads to packet loss
| The following reply was made to PR kern/29126; it has been noted by GNATS.
|
| From: Kimmo Suominen <kim@tac.nyc.ny.us>
| To: gnats-bugs@netbsd.org
| Cc: Christos Zoulas <christos@zoulas.com>,
| Arto Selonen <arto@selonen.org>
| Subject: Re: kern/29126: tcpdump leads to packet loss
| Date: Sat, 5 Feb 2005 19:52:17 -0500
|
| And a tlp patch is below...
|
| I've made the patches available over FTP (probably easier than trying
| to extract them from GNATS).
|
| ftp://ftp.gw.com/pub/people/kim/netbsd/netbsd-2.99.15-tcpdump-ex.diff
| ftp://ftp.gw.com/pub/people/kim/netbsd/netbsd-2.99.15-tcpdump-gsip.diff
| ftp://ftp.gw.com/pub/people/kim/netbsd/netbsd-2.99.15-tcpdump-tlp.diff
commit all of them...
christos
From: Kimmo Suominen <kim@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/29126 CVS commit: src/sys/dev
Date: Sun, 6 Feb 2005 03:15:14 +0000 (UTC)
Module Name: src
Committed By: kim
Date: Sun Feb 6 03:15:14 UTC 2005
Modified Files:
src/sys/dev/ic: elinkxl.c elinkxlvar.h tulip.c tulipvar.h
src/sys/dev/pci: if_sip.c
Log Message:
If the interface is up and running, only modify the receive filter
when setting promiscuous or debug mode. This avoids resetting the
chip unnecessarily.
Fixes PR kern/29126.
To generate a diff of this commit:
cvs rdiff -r1.76 -r1.77 src/sys/dev/ic/elinkxl.c
cvs rdiff -r1.15 -r1.16 src/sys/dev/ic/elinkxlvar.h
cvs rdiff -r1.132 -r1.133 src/sys/dev/ic/tulip.c
cvs rdiff -r1.52 -r1.53 src/sys/dev/ic/tulipvar.h
cvs rdiff -r1.97 -r1.98 src/sys/dev/pci/if_sip.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Zafer Aydogan <zafer@gmx.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/29126
Date: Sun, 20 Mar 2005 17:20:48 +0100
Fixed for ex and tlp driver.
Solved.
State-Changed-From-To: feedback->closed
State-Changed-By: chs@netbsd.org
State-Changed-When: Sun, 20 Mar 2005 17:30:43 +0000
State-Changed-Why:
submitter reports the problem is solved.
From: Pavel Cahyna <pavel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/29126 CVS commit: src/sys/dev/pci
Date: Mon, 10 Apr 2006 16:37:22 +0000 (UTC)
Module Name: src
Committed By: pavel
Date: Mon Apr 10 16:37:22 UTC 2006
Modified Files:
src/sys/dev/pci: if_sip.c
Log Message:
In rev. 1.98, the ioctl method of the (g)sip drivers was optimized for
SIOCSIFFLAGS: it compares the new flags with the old flags and avoids
reset if there are only certain changes. This was done to fix PR 29126.
It does not take into account, though, that there is other state which
can change and SIOCSIFFLAGS is called to inform about it. Namely,
if_capenable, ec_capenable and ec_nvlans. For all three, the _init
method must program the hardware specially. Not doing it resulted in:
- VLAN frames getting truncated
- hw checksumming not working
- outgoing VLAN frames not being tagged when they should
- incoming VLAN frames being treated as untagged.
Fix by keeping all the old state in the softc and initializing the
hardware if any of it changes.
Tested on gsip. Also tested by Nino Dehne and Martin J. Laubach
on sip, thanks.
Fixes PRs 32900 and 33216.
Approved by martin@ .
To generate a diff of this commit:
cvs rdiff -r1.105 -r1.106 src/sys/dev/pci/if_sip.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Matthias Scheler <tron@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/29126 CVS commit: [netbsd-3] src/sys/dev/pci
Date: Fri, 21 Apr 2006 12:03:38 +0000 (UTC)
Module Name: src
Committed By: tron
Date: Fri Apr 21 12:03:38 UTC 2006
Modified Files:
src/sys/dev/pci [netbsd-3]: if_sip.c
Log Message:
Pull up following revision(s) (requested by pavel in ticket #1280):
sys/dev/pci/if_sip.c: revision 1.106
In rev. 1.98, the ioctl method of the (g)sip drivers was optimized for
SIOCSIFFLAGS: it compares the new flags with the old flags and avoids
reset if there are only certain changes. This was done to fix PR 29126.
It does not take into account, though, that there is other state which
can change and SIOCSIFFLAGS is called to inform about it. Namely,
if_capenable, ec_capenable and ec_nvlans. For all three, the _init
method must program the hardware specially. Not doing it resulted in:
- VLAN frames getting truncated
- hw checksumming not working
- outgoing VLAN frames not being tagged when they should
- incoming VLAN frames being treated as untagged.
Fix by keeping all the old state in the softc and initializing the
hardware if any of it changes.
Tested on gsip. Also tested by Nino Dehne and Martin J. Laubach
on sip, thanks.
Fixes PRs 32900 and 33216.
Approved by martin@ .
To generate a diff of this commit:
cvs rdiff -r1.101.2.2 -r1.101.2.3 src/sys/dev/pci/if_sip.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: closed->analyzed
State-Changed-By: pavel@netbsd.org
State-Changed-When: Mon, 29 Jan 2007 23:05:01 +0000
State-Changed-Why:
while the problem is fixed for the devices mentioned in the PR log, there are
others sufferning from it. freza@ observed audio DMA underrun when using bpf
on top of fxp because of this. Eric Haszlakiewicz reports similar problem
with vr.
wm is probably another offender.
From: Christoph Kaegi <kgc@zhwin.ch>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/29126
Date: Mon, 23 Apr 2007 16:15:38 +0200
I get these timeouts also with NetBSD 3.1 and wm interfaces.
This bites us every time we want to examine traffic on one of our
firewalls...
Is there a patch available for wm(4) interfaces (i82546EB and i82546GB)?
Thanks
Chris
--
----------------------------------------------------------------------
Christoph Kaegi kgc@zhwin.ch
----------------------------------------------------------------------
From: Matthias Scheler <tron@zhadum.org.uk>
To: Christoph Kaegi <kgc@zhwin.ch>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/29126
Date: Tue, 24 Apr 2007 12:46:37 +0100
On Mon, Apr 23, 2007 at 02:20:03PM +0000, Christoph Kaegi wrote:
> The following reply was made to PR kern/29126; it has been noted by GNATS.
>
> From: Christoph Kaegi <kgc@zhwin.ch>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/29126
> Date: Mon, 23 Apr 2007 16:15:38 +0200
>
> I get these timeouts also with NetBSD 3.1 and wm interfaces.
>
> This bites us every time we want to examine traffic on one of our
> firewalls...
>
> Is there a patch available for wm(4) interfaces (i82546EB and i82546GB)?
There are significant improvements to the wm(4) driver in NetBSD 3.1_STABLE
(sources from the "netbsd-3" branch). Please check for details:
http://releng.netbsd.org/cgi-bin/req-3.cgi?show=1681
You could therefore try to build a kernel from that branch. It will run
fine with your NetBSD 3.1 userland.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
From: Mark Davies <mark@ecs.vuw.ac.nz>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/29126: tcpdump leads to packet loss
Date: Sun, 12 Jul 2009 22:33:02 +1200
This is still a problem with wm in NetBSD 5.0.
[I hadn't particularly noticed the issue till now with our machines with wm
(probably because the switch ports are set to do "portfast" spanning tree)
but on looking I see that there is a three second or so break going into
or out of promisc. However we now have some machines with wm interfaces
that are configured as 802.1q trunks and if you put those into promisc
there is a 35 second disruption]
From: Kimmo Suominen <kim@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/29126: tcpdump leads to packet loss
Date: Sun, 12 Jul 2009 15:49:11 +0300
--0016e6480842fc59bc046e81a2d5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Unfortunately I don't have any wm cards and when I looked at fxp, I didn't
have the knowledge necessary for fixing it (the driver is very different
from the ones I fixed -- and my fixed even needed further fixing as seen in
the ticket).
It might be better to open a separate ticket for each driver that
unnecessarily resets the card when flags change. This would allow assigning
each ticket to a person who understands the corresponding driver. This
ticket could then remain closed, and just referenced from the new tickets.
Best regards,
+ Kimmo
--0016e6480842fc59bc046e81a2d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Unfortunately I don't have any wm cards and when I looked at fxp, I did=
n't have the knowledge necessary for fixing it (the driver is very diff=
erent from the ones I fixed -- and my fixed even needed further fixing as s=
een in the ticket).<br>
<br>It might be better to open a separate ticket for each driver that unnec=
essarily resets the card when flags change. This would allow assigning each=
ticket to a person who understands the corresponding driver. This ticket c=
ould then remain closed, and just referenced from the new tickets.<br>
<br>Best regards,<br>+ Kimmo<br><br>
--0016e6480842fc59bc046e81a2d5--
From: SAITOH Masanobu <msaitoh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/29126 CVS commit: src/sys/dev/pci
Date: Thu, 6 Aug 2009 03:03:46 +0000
Module Name: src
Committed By: msaitoh
Date: Thu Aug 6 03:03:46 UTC 2009
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
If the difference bettween last flag and new flag is only IFF_PROMISC or
IFF_ALLMULTI, set multicast filter only to prevent link down. Tested by
Mark Davies and me. Fixes PR#29126 for wm.
To generate a diff of this commit:
cvs rdiff -u -r1.178 -r1.179 src/sys/dev/pci/if_wm.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: David Holland <dholland-bugs@netbsd.org>
To: Kimmo Suominen <kim@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/29126: tcpdump leads to packet loss
Date: Fri, 7 Aug 2009 15:17:21 +0000
On Sun, Jul 12, 2009 at 12:55:02PM +0000, Kimmo Suominen wrote:
> Unfortunately I don't have any wm cards and when I looked at fxp, I didn't
> have the knowledge necessary for fixing it (the driver is very different
> from the ones I fixed -- and my fixed even needed further fixing as seen in
> the ticket).
>
> It might be better to open a separate ticket for each driver that
> unnecessarily resets the card when flags change. This would allow assigning
> each ticket to a person who understands the corresponding driver. This
> ticket could then remain closed, and just referenced from the new tickets.
That is probably not necessary if we can keep the fixes coming.
Do we have a list of the affected devices? From the earlier traffic it
looks like fxp and vr remain unfixed; are there others?
--
David A. Holland
dholland@netbsd.org
From: Stephen Borrill <sborrill@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/29126 CVS commit: [netbsd-5] src/sys/dev
Date: Wed, 23 Dec 2009 10:37:37 +0000
Module Name: src
Committed By: sborrill
Date: Wed Dec 23 10:37:37 UTC 2009
Modified Files:
src/sys/dev/mii [netbsd-5]: igphy.c
src/sys/dev/pci [netbsd-5]: if_wm.c if_wmreg.h
Added Files:
src/sys/dev/pci [netbsd-5]: if_wmvar.h
Log Message:
Pull up the following revisions(s) (requested by msaitoh in ticket #1203):
sys/dev/pci/if_wm.c: 1.176-1.179, 1.181-1.183
sys/dev/pci/if_wmreg.h: 1.28
sys/dev/pci/if_wmvar.h: 1.1-1.4
sys/dev/mii/igphy.c: 1.18-1.20 via patch
Many bugfixes:
- Some fixes for i80003 and ICH{8,9,10} from e1000 driver and document:
- Add setting for KABGTXD register for ICH{8,9,10}.
- ICH9 and ICH10 has no FCAL, FCAH and FCT like ICH8.
- Add special setting for FCTTV and TCTL_EXT register for i80003
- The special setting for TIPG is only for i80003.
- Some of kumeran settings are only for i80003's bugs.
- Add some ICH10 fixes.
- Fix the bug that another lock mechanism is used to access Kumeran
registers on i80003 and ICHs.
- Fix yet another i80003 ONLY workaround. The code to modifing TIPG
register is only for i80003.
- Set the Re-Transmit on Late Collision(RTLC) flag for all devices.
- Fix a typo in a printf message.
- If the difference bettween last flag and new flag is only IFF_PROMISC
or IFF_ALLMULTI, set multicast filter only to prevent link down.
Tested by Mark Davies and me. Fixes PR#29126 for wm.
- Cleanup interrupt establish error messages. Do not mix
aprint_error/aprint_normal/printf calls for a single line.
- Fix igphy's 82566 support.
- Patch for the DSP code is only for 8254[17] and we have to apply
the different patches between rev. 1 and rev. 2.
- The workaround for analog fuse is only for 82547 rev. 1.
- The workaround for smartspeed is only for 8254[17]
- Sync with Intel's original em driver:
- Check PCI-X mode as e1000 driver.
- Add dspcode for igp3 and use it when the EEPROM isn't available.
- Add some delays.
- Stop the PHY transmitter before patching the DSP code and
restart it after writing.
- Save and restore register 0x2f5b.
To generate a diff of this commit:
cvs rdiff -u -r1.16 -r1.16.10.1 src/sys/dev/mii/igphy.c
cvs rdiff -u -r1.162.4.10 -r1.162.4.11 src/sys/dev/pci/if_wm.c
cvs rdiff -u -r1.24.20.2 -r1.24.20.3 src/sys/dev/pci/if_wmreg.h
cvs rdiff -u -r0 -r1.2.46.1 src/sys/dev/pci/if_wmvar.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Responsible-Changed-From-To: kim->kern-bug-people
Responsible-Changed-By: kim@NetBSD.org
Responsible-Changed-When: Sun, 05 Jan 2020 14:04:34 +0000
Responsible-Changed-Why:
I don't have the hardware that resulted in reopening this.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home