Netdev List
 help / color / mirror / Atom feed
* tcp_mtu_probe implementation details
From: Anatoly Sivov @ 2011-12-20 21:49 UTC (permalink / raw)
  To: netdev

Hi all,

Looking on TCP implementation in Linux I see that there are some things
that I don't understand in tcp_mtu_probe() implementation.
Could someone clear them for me or share the link to Linux PMTUD
documentation, please?
The first thing I don't understand is tp->snd_cwnd < 11 in
if (!icsk->icsk_mtup.enabled ||
             icsk->icsk_mtup.probe_size ||
             inet_csk(sk)->icsk_ca_state != TCP_CA_Open ||
             tp->snd_cwnd < 11 ||
             tp->rx_opt.num_sacks || tp->rx_opt.dsack)
                 return -1;
What is magic number "11" here?
The other question is about size_needed variable.
It is assigned to value probe_size + (tp->reordering + 1) * tp->mss_cache
And that is not clear for me.
What is this "(tp->reordering + 1) * tp->mss_cache" addition?

Thanks.

^ permalink raw reply

* Re: tcp_mtu_probe implementation details
From: Vijay Subramanian @ 2011-12-20 22:33 UTC (permalink / raw)
  To: Anatoly Sivov; +Cc: netdev
In-Reply-To: <op.v6s5j2i0fzo5me@stalin>

> The other question is about size_needed variable.
> It is assigned to value probe_size + (tp->reordering + 1) * tp->mss_cache
> And that is not clear for me.
> What is this "(tp->reordering + 1) * tp->mss_cache" addition?
>

I think the idea is that you want enough bytes in the write_queue so
that even if the probe is lost, the sender will get an ack even if
there is reordering in the network. Without sufficient bytes, the
probe will not be sent. This is what I make of the code but I could be
wrong.

Regards,
Vijay

^ permalink raw reply

* 3.2-rc6+: Reported regressions from 3.0 and 3.1
From: Rafael J. Wysocki @ 2011-12-20 23:11 UTC (permalink / raw)
  To: Linux Kernel Mailing List
  Cc: Linux SCSI List, Florian Mickler, Network Development,
	Linux Wireless List, DRI, Linux ACPI, Andrew Morton,
	Kernel Testers List, Linus Torvalds, Linux PM List,
	Maciej Rutecki
In-Reply-To: <lx6sezwGldO.A.IhF.UBpWOB@chimera>

This message contains a list of some regressions from 3.0 and 3.1
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 3.0 and 3.1, please let us
know either and we'll add them to the list.  Also, please let us know if any of
the entries below are invalid.

The entries below are simplified and the statistics are not present due to the
continuing Bugzilla outage.


Subject    : iwlagn is getting very shaky
Submitter  : Norbert Preining <preining@logic.at>
Date       : 2011-10-19 6:01
Message-ID : 20111019060108.GA11588@gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2

Subject    : Regression: "irqpoll" hasn't been working for me since March 16 IRQ
Submitter  : Edward Donovan <edward.donovan@numble.net>
Date       : 2011-10-19 22:09
Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2

Subject    : 3.1+ iwlwifi lockup
Submitter  : Dave Jones <davej@redhat.com>
Date       : 2011-10-31 14:34
Message-ID : 20111031143408.GA17152@redhat.com
References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2

Subject    : Linus GIT - INFO: possible circular locking dependency detected
Submitter  : Miles Lane <miles.lane@gmail.com>
Date       : 2011-11-03 15:57
Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2

Subject    : DMA-API check_sync errors with 3.2
Submitter  : Josh Boyer <jwboyer@redhat.com>
Date       : 2011-11-08 17:31
Message-ID : 20111108173153.GE14216@zod.bos.redhat.com
References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2

Subject    : 3.2-rc1 doesn't boot on dual socket opteron without swap
Submitter  : Niklas Schnelle <niklas@komani.de>
Date       : 2011-11-10 20:09
Message-ID : 1320955769.1718.8.camel@jupiter
References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2

Subject    : Sparc-32 doesn't work in 3.1.
Submitter  : Rob Landley <rob@landley.net>
Date       : 2011-11-12 11:22
Message-ID : 4EBEAB5A.5020809@landley.net
References : http://www.spinics.net/lists/kernel/msg1260383.html

Subject    : WARNING: at fs/sysfs/sysfs.h:195 (during boot)
Submitter  : Markus Trippelsdorf <markus@trippelsdorf.de>
Date       : 2011-11-13 19:24
Message-ID : 20111113192417.GA1659@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2

Subject    : max PWM is zero
Submitter  : Marcos Paulo de Souza <marcos.mage@gmail.com>
Date       : 2011-11-15 15:14
Message-ID : alpine.LNX.2.00.1111151301410.2693@darkstar.example.net
References : http://marc.info/?l=linux-kernel&m=132137019330548&w=2

Subject    : Oops on suspend with libertas SDIO (Linux 3.2-rc2)
Submitter  : Sven Neumann <s.neumann@raumfeld.com>
Date       : 2011-11-17 15:36
Message-ID : 1321544210.31090.6.camel@sven
References : http://marc.info/?l=linux-kernel&m=132154527715807&w=2

Subject    : Impossible high cpu-time values for migration threads
Submitter  : Markus Trippelsdorf <markus@trippelsdorf.de>
Date       : 2011-11-17 22:17
Message-ID : 20111117221731.GA9229@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132156832124314&w=2

Subject    : WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
Submitter  : Markus Trippelsdorf <markus@trippelsdorf.de>
Date       : 2011-11-18 7:25
Message-ID : 20111118072519.GA1615@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132160119031794&w=2

Subject    : [REGRESSION] resume takes 10s longer due to e1b6eb3 (Bluetooth: Increase HCI reset timeout ...)
Submitter  : Tomáš Janoušek <tomi@nomi.cz>
Date       : 2011-11-18 18:40
Message-ID : 20111118184017.GA5052@nomi.cz
References : http://marc.info/?l=linux-kernel&m=132164169511416&w=2

Subject    : [REGRESSION] sudden cpu hogging in kernel 3.2 rc-series
Submitter  : "Nicolas Kalkhof" <nkalkhof@web.de>
Date       : 2011-11-18 20:33
Message-ID : 506786689.810044.1321648395265.JavaMail.fmail@mwmweb010
References : http://marc.info/?l=linux-kernel&m=132164909313594&w=2

Subject    : Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0
Submitter  : Meelis Roos <mroos@linux.ee>
Date       : 2011-11-22 10:15
Message-ID : alpine.SOC.1.00.1111221207090.6490@math.ut.ee
References : http://marc.info/?l=linux-kernel&m=132195700023709&w=2

Subject    : 3.2-rc2 regression: floppy driver breaks boot
Submitter  : Pavel Machek <pavel@ucw.cz>
Date       : 2011-11-22 11:14
Message-ID : 20111122111405.GA28215@elf.ucw.cz
References : http://marc.info/?l=linux-kernel&m=132196052124801&w=2

Subject    : [regression 3.1.0 -> 3.20rc] USB Oops
Submitter  : Norbert Preining <preining@logic.at>
Date       : 2011-11-22 12:52
Message-ID : 20111122125256.GB32440@gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=132196644726900&w=2

Subject    : Freezing of tasks failed after 20.01 seconds in kernel 3.2.0-rc2
Submitter  : Belisko Marek <marek.belisko@gmail.com>
Date       : 2011-11-22 21:20
Message-ID : 
CAAfyv36nxYq1EA2pcHi5WR1BdWYHp2sQTY1mMA4Q3JjcOG5RDw@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132199691706100&w=2

Subject    : 3.2.0-rc2+git: possible recursive locking detected in process 
memory freeing
Submitter  : Meelis Roos <mroos@linux.ee>
Date       : 2011-11-23 13:12
Message-ID : alpine.SOC.1.00.1111231311490.15939@math.ut.ee
References : http://lkml.org/lkml/2011/11/23/159

Subject    : i915: 3.2 rc1/2 KMS regression
Submitter  : Patrik Kullman <patrik.kullman@gmail.com>
Date       : 2011-11-23 23:43
Message-ID : CAGPN=9THOv-
M4Td4haE94uDcsAjW3eGMG7ioLeu+p8xUOBPd7w@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132209186403288&w=2

Subject    : 3.2-rc2: regression after hibernate: lots of warnings, broken 
system
Submitter  : Pavel Machek <pavel@ucw.cz>
Date       : 2011-11-24 15:40
Message-ID : 20111124154014.GA2153@elf.ucw.cz
References : http://marc.info/?l=linux-kernel&m=132214929818015&w=2

Subject    : [regression] WARNING: at drivers/block/floppy.c:2929 
do_fd_request+0xb7/0xb9() in 3.2.0-rc2 and 3
Submitter  : Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
Date       : 2011-11-25 10:34
Message-ID : 20111125103420.GO4581@charite.de
References : http://marc.info/?l=linux-kernel&m=132221799501685&w=2

Subject    : [BUG] 3.2-rcX radeon KMS system freeze
Submitter  : Bob Tracy <rct@gherkin.frus.com>
Date       : 2011-11-25 20:33
Message-ID : 20111125203351.GA3651@gherkin.frus.com
References : http://marc.info/?l=linux-kernel&m=132225331312019&w=2

Subject    : 3.2-rc2 regression due to commit "USB: EHCI: fix HUB TT scheduling 
issue with iso transfer" 811c926c538f7e8d3c08b630dd5844efd7e000f6
Submitter  : Sander Eikelenboom <linux@eikelenboom.it>
Date       : 2011-11-26 15:47
Message-ID : 1001209018.20111126164712@eikelenboom.it
References : http://marc.info/?l=linux-kernel&m=132232295425393&w=2

Subject    : 3.2-rc3+: [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer 
elapsed... GPU hung
Submitter  : Sergei Trofimovich <slyich@gmail.com>
Date       : 2011-12-02 17:56
Message-ID : 20111202205601.115522b1@sf.home
References : http://marc.info/?l=linux-kernel&m=132284845705156&w=2

Subject    : [BUG] deadlock: jfs (3.2.0-rc4-00154-g8e8da02)
Submitter  : Nico Schottelius <nico-linux-20111201@schottelius.org>
Date       : 2011-12-06 10:05
Message-ID : 20111206100533.GB6161@schottelius.org
References : http://marc.info/?l=linux-kernel&m=132317917827825&w=2

Subject    : [3.2-rc4] pcnet32: DMA-API: device driver tries to sync DMA 
memory it has not allocated
Submitter  : Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date       : 2011-12-09 3:40
Message-ID : 201112090340.pB93ek9i086855@www262.sakura.ne.jp
References : http://marc.info/?l=linux-kernel&m=132340215706219&w=2

Subject    : Enabling FCoE point-to-point mode triggers a deadlock
Submitter  : Bart Van Assche <bvanassche@acm.org>
Date       : 2011-12-09 14:33
References : http://permalink.gmane.org/gmane.linux.scsi.open-fcoe.devel/11451

Subject    : iwlagn unusable in 3.2.0rc4
Submitter  : Dave Jones <davej@redhat.com>
Date       : 2011-12-09 19:42
Message-ID : 20111209194208.GA15236@redhat.com
References : http://marc.info/?l=linux-kernel&m=132345984724433&w=2

Subject    : DRM nouveau crash with 3.2.0-rc5
Submitter  : "Berck E. Nash" <flyboy@gmail.com>
Date       : 2011-12-10 5:10
Message-ID : 4EE2E9BB.8060801@gmail.com
References : http://marc.info/?l=linux-kernel&m=132349393700419&w=2

Subject    : Reiserfs.c bug in 3.2-rc5
Submitter  : "Jorge Bastos" <mysql.jorge@decimal.pt>
Date       : 2011-12-10 23:48
Message-ID : 43556.213.228.140.150.1323560920.squirrel@webmail.decimal.pt
References : http://marc.info/?l=linux-kernel&m=132356156914296&w=2

Subject    : [REGRESSION] 3.2.0-rc3 Bluetooth L2CAP Linux to Linux rfcomm 
fails
Submitter  : David Fries <david@fries.net>
Date       : 2011-12-11 5:16
Message-ID : 20111211051624.GA12050@spacedout.fries.net
References : http://marc.info/?l=linux-kernel&m=132358071417198&w=2

Subject    : recent regression: after resume the mouse and X is extremely slow
Submitter  : Norbert Preining <preining@logic.at>
Date       : 2011-12-11 22:13
Message-ID : 20111211221303.GA8710@gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=132364169929740&w=2


Thanks!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* [PATCH net-next V2] tcp: Replace constants with #define macros
From: Vijay Subramanian @ 2011-12-20 23:23 UTC (permalink / raw)
  To: netdev; +Cc: David S. Miller, Eric Dumazet, ilpo.jarvinen, Vijay Subramanian

    to record the state of SACK/FACK and DSACK for better readability and maintenance.

Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
 include/linux/tcp.h   |    5 +++++
 include/net/tcp.h     |    4 ++--
 net/ipv4/syncookies.c |    2 +-
 net/ipv4/tcp_input.c  |    6 +++---
 4 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 7f59ee9..46a85c9 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -238,6 +238,11 @@ struct tcp_sack_block {
 	u32	end_seq;
 };
 
+/*These are used to set the sack_ok field in struct tcp_options_received */
+#define TCP_SACK_SEEN     (1 << 0)   /*1 = peer is SACK capable, */
+#define TCP_FACK_ENABLED  (1 << 1)   /*1 = FACK is enabled locally*/
+#define TCP_DSACK_SEEN    (1 << 2)   /*1 = DSACK was received from peer*/
+
 struct tcp_options_received {
 /*	PAWS/RTTM data	*/
 	long	ts_recent_stamp;/* Time we stored ts_recent (for aging) */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index a4f52e1..0118ea9 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -773,12 +773,12 @@ static inline int tcp_is_reno(const struct tcp_sock *tp)
 
 static inline int tcp_is_fack(const struct tcp_sock *tp)
 {
-	return tp->rx_opt.sack_ok & 2;
+	return tp->rx_opt.sack_ok & TCP_FACK_ENABLED;
 }
 
 static inline void tcp_enable_fack(struct tcp_sock *tp)
 {
-	tp->rx_opt.sack_ok |= 2;
+	tp->rx_opt.sack_ok |= TCP_FACK_ENABLED;
 }
 
 static inline unsigned int tcp_left_out(const struct tcp_sock *tp)
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index 90f6544..51fdbb4 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -245,7 +245,7 @@ bool cookie_check_timestamp(struct tcp_options_received *tcp_opt, bool *ecn_ok)
 	if (!sysctl_tcp_timestamps)
 		return false;
 
-	tcp_opt->sack_ok = (options >> 4) & 0x1;
+	tcp_opt->sack_ok = (options & (1 << 4)) ? TCP_SACK_SEEN : 0;
 	*ecn_ok = (options >> 5) & 1;
 	if (*ecn_ok && !sysctl_tcp_ecn)
 		return false;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index f131d92..2877c3e 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -865,13 +865,13 @@ static void tcp_disable_fack(struct tcp_sock *tp)
 	/* RFC3517 uses different metric in lost marker => reset on change */
 	if (tcp_is_fack(tp))
 		tp->lost_skb_hint = NULL;
-	tp->rx_opt.sack_ok &= ~2;
+	tp->rx_opt.sack_ok &= ~TCP_FACK_ENABLED;
 }
 
 /* Take a notice that peer is sending D-SACKs */
 static void tcp_dsack_seen(struct tcp_sock *tp)
 {
-	tp->rx_opt.sack_ok |= 4;
+	tp->rx_opt.sack_ok |= TCP_DSACK_SEEN;
 }
 
 /* Initialize metrics on socket. */
@@ -3878,7 +3878,7 @@ void tcp_parse_options(const struct sk_buff *skb, struct tcp_options_received *o
 			case TCPOPT_SACK_PERM:
 				if (opsize == TCPOLEN_SACK_PERM && th->syn &&
 				    !estab && sysctl_tcp_sack) {
-					opt_rx->sack_ok = 1;
+					opt_rx->sack_ok = TCP_SACK_SEEN;
 					tcp_sack_reset(opt_rx);
 				}
 				break;
-- 
1.7.0.4

^ permalink raw reply related

* 3.2-rc6+: Reported regressions from 3.0 and 3.1
From: Rafael J. Wysocki @ 2011-12-20 23:39 UTC (permalink / raw)
  To: Kernel Testers List
  Cc: Linux SCSI List, Florian Mickler, Network Development,
	Linux PM list, Linux Wireless List, Linux Kernel Mailing List,
	DRI, Linux ACPI, Andrew Morton, Linus Torvalds, Maciej Rutecki
In-Reply-To: <lx6sezwGldO.A.IhF.UBpWOB@chimera>

[I'm sorry if you receive this message twice, I seem to have problems with
sending it.]

This message contains a list of some regressions from 3.0 and 3.1
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 3.0 and 3.1, please let us
know either and we'll add them to the list.  Also, please let us know if any of
the entries below are invalid.

The entries below are simplified and the statistics are not present due to the
continuing Bugzilla outage.


Subject    : iwlagn is getting very shaky
Submitter  : Norbert Preining <preining@logic.at>
Date       : 2011-10-19 6:01
Message-ID : 20111019060108.GA11588@gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2

Subject    : Regression: "irqpoll" hasn't been working for me since March 16 IRQ
Submitter  : Edward Donovan <edward.donovan@numble.net>
Date       : 2011-10-19 22:09
Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2

Subject    : 3.1+ iwlwifi lockup
Submitter  : Dave Jones <davej@redhat.com>
Date       : 2011-10-31 14:34
Message-ID : 20111031143408.GA17152@redhat.com
References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2

Subject    : Linus GIT - INFO: possible circular locking dependency detected
Submitter  : Miles Lane <miles.lane@gmail.com>
Date       : 2011-11-03 15:57
Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2

Subject    : DMA-API check_sync errors with 3.2
Submitter  : Josh Boyer <jwboyer@redhat.com>
Date       : 2011-11-08 17:31
Message-ID : 20111108173153.GE14216@zod.bos.redhat.com
References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2

Subject    : 3.2-rc1 doesn't boot on dual socket opteron without swap
Submitter  : Niklas Schnelle <niklas@komani.de>
Date       : 2011-11-10 20:09
Message-ID : 1320955769.1718.8.camel@jupiter
References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2

Subject    : Sparc-32 doesn't work in 3.1.
Submitter  : Rob Landley <rob@landley.net>
Date       : 2011-11-12 11:22
Message-ID : 4EBEAB5A.5020809@landley.net
References : http://www.spinics.net/lists/kernel/msg1260383.html

Subject    : WARNING: at fs/sysfs/sysfs.h:195 (during boot)
Submitter  : Markus Trippelsdorf <markus@trippelsdorf.de>
Date       : 2011-11-13 19:24
Message-ID : 20111113192417.GA1659@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2

Subject    : max PWM is zero
Submitter  : Marcos Paulo de Souza <marcos.mage@gmail.com>
Date       : 2011-11-15 15:14
Message-ID : alpine.LNX.2.00.1111151301410.2693@darkstar.example.net
References : http://marc.info/?l=linux-kernel&m=132137019330548&w=2

Subject    : Oops on suspend with libertas SDIO (Linux 3.2-rc2)
Submitter  : Sven Neumann <s.neumann@raumfeld.com>
Date       : 2011-11-17 15:36
Message-ID : 1321544210.31090.6.camel@sven
References : http://marc.info/?l=linux-kernel&m=132154527715807&w=2

Subject    : Impossible high cpu-time values for migration threads
Submitter  : Markus Trippelsdorf <markus@trippelsdorf.de>
Date       : 2011-11-17 22:17
Message-ID : 20111117221731.GA9229@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132156832124314&w=2

Subject    : WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
Submitter  : Markus Trippelsdorf <markus@trippelsdorf.de>
Date       : 2011-11-18 7:25
Message-ID : 20111118072519.GA1615@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132160119031794&w=2

Subject    : [REGRESSION] resume takes 10s longer due to e1b6eb3 (Bluetooth: Increase HCI reset timeout ...)
Submitter  : Tomáš Janoušek <tomi@nomi.cz>
Date       : 2011-11-18 18:40
Message-ID : 20111118184017.GA5052@nomi.cz
References : http://marc.info/?l=linux-kernel&m=132164169511416&w=2

Subject    : [REGRESSION] sudden cpu hogging in kernel 3.2 rc-series
Submitter  : "Nicolas Kalkhof" <nkalkhof@web.de>
Date       : 2011-11-18 20:33
Message-ID : 506786689.810044.1321648395265.JavaMail.fmail@mwmweb010
References : http://marc.info/?l=linux-kernel&m=132164909313594&w=2

Subject    : Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0
Submitter  : Meelis Roos <mroos@linux.ee>
Date       : 2011-11-22 10:15
Message-ID : alpine.SOC.1.00.1111221207090.6490@math.ut.ee
References : http://marc.info/?l=linux-kernel&m=132195700023709&w=2

Subject    : 3.2-rc2 regression: floppy driver breaks boot
Submitter  : Pavel Machek <pavel@ucw.cz>
Date       : 2011-11-22 11:14
Message-ID : 20111122111405.GA28215@elf.ucw.cz
References : http://marc.info/?l=linux-kernel&m=132196052124801&w=2

Subject    : [regression 3.1.0 -> 3.20rc] USB Oops
Submitter  : Norbert Preining <preining@logic.at>
Date       : 2011-11-22 12:52
Message-ID : 20111122125256.GB32440@gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=132196644726900&w=2

Subject    : Freezing of tasks failed after 20.01 seconds in kernel 3.2.0-rc2
Submitter  : Belisko Marek <marek.belisko@gmail.com>
Date       : 2011-11-22 21:20
Message-ID : 
CAAfyv36nxYq1EA2pcHi5WR1BdWYHp2sQTY1mMA4Q3JjcOG5RDw@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132199691706100&w=2

Subject    : 3.2.0-rc2+git: possible recursive locking detected in process 
memory freeing
Submitter  : Meelis Roos <mroos@linux.ee>
Date       : 2011-11-23 13:12
Message-ID : alpine.SOC.1.00.1111231311490.15939@math.ut.ee
References : http://lkml.org/lkml/2011/11/23/159

Subject    : i915: 3.2 rc1/2 KMS regression
Submitter  : Patrik Kullman <patrik.kullman@gmail.com>
Date       : 2011-11-23 23:43
Message-ID : CAGPN=9THOv-
M4Td4haE94uDcsAjW3eGMG7ioLeu+p8xUOBPd7w@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132209186403288&w=2

Subject    : 3.2-rc2: regression after hibernate: lots of warnings, broken 
system
Submitter  : Pavel Machek <pavel@ucw.cz>
Date       : 2011-11-24 15:40
Message-ID : 20111124154014.GA2153@elf.ucw.cz
References : http://marc.info/?l=linux-kernel&m=132214929818015&w=2

Subject    : [regression] WARNING: at drivers/block/floppy.c:2929 
do_fd_request+0xb7/0xb9() in 3.2.0-rc2 and 3
Submitter  : Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
Date       : 2011-11-25 10:34
Message-ID : 20111125103420.GO4581@charite.de
References : http://marc.info/?l=linux-kernel&m=132221799501685&w=2

Subject    : [BUG] 3.2-rcX radeon KMS system freeze
Submitter  : Bob Tracy <rct@gherkin.frus.com>
Date       : 2011-11-25 20:33
Message-ID : 20111125203351.GA3651@gherkin.frus.com
References : http://marc.info/?l=linux-kernel&m=132225331312019&w=2

Subject    : 3.2-rc2 regression due to commit "USB: EHCI: fix HUB TT scheduling 
issue with iso transfer" 811c926c538f7e8d3c08b630dd5844efd7e000f6
Submitter  : Sander Eikelenboom <linux@eikelenboom.it>
Date       : 2011-11-26 15:47
Message-ID : 1001209018.20111126164712@eikelenboom.it
References : http://marc.info/?l=linux-kernel&m=132232295425393&w=2

Subject    : 3.2-rc3+: [drm:i915_hangcheck_elapsed] ERROR Hangcheck timer 
elapsed... GPU hung
Submitter  : Sergei Trofimovich <slyich@gmail.com>
Date       : 2011-12-02 17:56
Message-ID : 20111202205601.115522b1@sf.home
References : http://marc.info/?l=linux-kernel&m=132284845705156&w=2

Subject    : [BUG] deadlock: jfs (3.2.0-rc4-00154-g8e8da02)
Submitter  : Nico Schottelius <nico-linux-20111201@schottelius.org>
Date       : 2011-12-06 10:05
Message-ID : 20111206100533.GB6161@schottelius.org
References : http://marc.info/?l=linux-kernel&m=132317917827825&w=2

Subject    : [3.2-rc4] pcnet32: DMA-API: device driver tries to sync DMA 
memory it has not allocated
Submitter  : Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date       : 2011-12-09 3:40
Message-ID : 201112090340.pB93ek9i086855@www262.sakura.ne.jp
References : http://marc.info/?l=linux-kernel&m=132340215706219&w=2

Subject    : Enabling FCoE point-to-point mode triggers a deadlock
Submitter  : Bart Van Assche <bvanassche@acm.org>
Date       : 2011-12-09 14:33
References : http://permalink.gmane.org/gmane.linux.scsi.open-fcoe.devel/11451

Subject    : iwlagn unusable in 3.2.0rc4
Submitter  : Dave Jones <davej@redhat.com>
Date       : 2011-12-09 19:42
Message-ID : 20111209194208.GA15236@redhat.com
References : http://marc.info/?l=linux-kernel&m=132345984724433&w=2

Subject    : DRM nouveau crash with 3.2.0-rc5
Submitter  : "Berck E. Nash" <flyboy@gmail.com>
Date       : 2011-12-10 5:10
Message-ID : 4EE2E9BB.8060801@gmail.com
References : http://marc.info/?l=linux-kernel&m=132349393700419&w=2

Subject    : Reiserfs.c bug in 3.2-rc5
Submitter  : "Jorge Bastos" <mysql.jorge@decimal.pt>
Date       : 2011-12-10 23:48
Message-ID : 43556.213.228.140.150.1323560920.squirrel@webmail.decimal.pt
References : http://marc.info/?l=linux-kernel&m=132356156914296&w=2

Subject    : [REGRESSION] 3.2.0-rc3 Bluetooth L2CAP Linux to Linux rfcomm 
fails
Submitter  : David Fries <david@fries.net>
Date       : 2011-12-11 5:16
Message-ID : 20111211051624.GA12050@spacedout.fries.net
References : http://marc.info/?l=linux-kernel&m=132358071417198&w=2

Subject    : recent regression: after resume the mouse and X is extremely slow
Submitter  : Norbert Preining <preining@logic.at>
Date       : 2011-12-11 22:13
Message-ID : 20111211221303.GA8710@gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=132364169929740&w=2


Thanks!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* RE: [PATCH 0/2] Tracepoint for tcp retransmission
From: Satoru Moriya @ 2011-12-20 23:40 UTC (permalink / raw)
  To: Hagen Paul Pfeifer, Stephen Hemminger
  Cc: nhorman@tuxdriver.com, davem@davemloft.net, tgraf@infradead.org,
	Seiji Aguchi, dle-develop@lists.sourceforge.net,
	netdev@vger.kernel.org
In-Reply-To: <20111218004944.GB14903@hell>


On 12/17/2011 07:49 PM, Hagen Paul Pfeifer wrote:
>> Sometimes network packets are dropped for some reason. In enterprise 
>> systems which require strict RAS functionality, we must know the 
>> reason why it happened and explain it to our customers even if using 
>> TCP. When we investigate the incidents, at first we try to find out 
>> whether the problem is in the server(kernel, application) or else 
>> (router, hub etc). And next we try to find out which layer
>> (application/middleware/kernel(IP/TCP/UDP/..)etc.) the problem 
>> occurs.
> 
> For the first question tcpdump may the right tool.

We'd like to keep records on memory and save it to file when
we detect problems so that we can keep tracing overhead low.
We can also keep the amount of trace data lower than with
tcpdump because we only record data when retransmission occurs.

Capturing all the packets and saving them to file cannot satisfy
our requirements. I should have written them in the cover-letter.
I'll fix it.

Also, we can analyze incidents in combination with the data
from this tracepoint and from others easily.

> For the later systemtap can be used. I mean we now have the 
> possibility to instrument the kernel at runtime, without bloating the 
> source.

Yes, we can use systemtap to get the data we need. But systemtap
is not included in kernel and we must maintain systemtap scripts
to follow kernel modification.

By adding tracepoint here, we can get useful data via ftrace/perf
without any instruments which is not included in kernel.
Of course, systemtap can insert a probe with this tracepoint too.

> Anyway: is 63e03724b51 not suitable to gather the required information 
> easily?

We use trace_kfree_skb() which 63e03724b51 uses to detect packet
drop event. In addition to that, we would like to detect errors
in TCP layer for better trouble shooting.

Regards,
Satoru

^ permalink raw reply

* Re: [PATCH RFC] virtio_net: fix refill related races
From: Rusty Russell @ 2011-12-20 23:43 UTC (permalink / raw)
  To: Michael S. Tsirkin, Tejun Heo
  Cc: Amit Shah, netdev, linux-kernel, virtualization
In-Reply-To: <20111220194518.GB26692@redhat.com>

On Tue, 20 Dec 2011 21:45:19 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Dec 20, 2011 at 11:31:54AM -0800, Tejun Heo wrote:
> > On Tue, Dec 20, 2011 at 09:30:55PM +0200, Michael S. Tsirkin wrote:
> > > Hmm, in that case it looks like a nasty race could get
> > > triggered, with try_fill_recv run on multiple CPUs in parallel,
> > > corrupting the linked list within the vq.
> > > 
> > > Using the mutex as my patch did will fix that naturally, as well.
> > 
> > Don't know the code but just use nrt wq.  There's even a system one
> > called system_nrq_wq.
> > 
> > Thanks.
> 
> We can, but we need the mutex for other reasons, anyway.

Well, here's the alternate approach.  What do you think?

Finding two wq issues makes you justifiably cautious, but it almost
feels like giving up to simply wrap it in a lock.  The APIs are designed
to let us do it without a lock; I was just using them wrong.

Two patches in one mail.  It's gauche, but it's an RFC only (untested).

Cheers,
Rusty.

virtio_net: set/cancel work on ndo_open/ndo_stop

Michael S. Tsirkin noticed that we could run the refill work after
ndo_close, which can re-enable napi - we don't disable it until
virtnet_remove.  This is clearly wrong, so move the workqueue control
to ndo_open and ndo_stop (aka. virtnet_open and virtnet_close).

One subtle point: virtnet_probe() could simply fail if it couldn't
allocate a receive buffer, but that's less polite in virtnet_open() so
we schedule a refill as we do in the normal receive path if we run out
of memory.

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -719,6 +719,10 @@ static int virtnet_open(struct net_devic
 {
 	struct virtnet_info *vi = netdev_priv(dev);
 
+	/* Make sure we have some buffersl if oom use wq. */
+	if (!try_fill_recv(vi, GFP_KERNEL))
+		schedule_delayed_work(&vi->refill, 0);
+
 	virtnet_napi_enable(vi);
 	return 0;
 }
@@ -772,6 +776,8 @@ static int virtnet_close(struct net_devi
 {
 	struct virtnet_info *vi = netdev_priv(dev);
 
+	/* Make sure refill_work doesn't re-enable napi! */
+	cancel_delayed_work_sync(&vi->refill);
 	napi_disable(&vi->napi);
 
 	return 0;
@@ -1082,7 +1088,6 @@ static int virtnet_probe(struct virtio_d
 
 unregister:
 	unregister_netdev(dev);
-	cancel_delayed_work_sync(&vi->refill);
 free_vqs:
 	vdev->config->del_vqs(vdev);
 free_stats:
@@ -1121,9 +1126,7 @@ static void __devexit virtnet_remove(str
 	/* Stop all the virtqueues. */
 	vdev->config->reset(vdev);
 
-
 	unregister_netdev(vi->dev);
-	cancel_delayed_work_sync(&vi->refill);
 
 	/* Free unused buffers in both send and recv, if any. */
 	free_unused_bufs(vi);


virtio_net: use non-reentrant workqueue.

Michael S. Tsirkin also noticed that we could run the refill work
multiple CPUs: if we kick off a refill on one CPU and then on another,
they would both manipulate the queue at the same time (they use
napi_disable to avoid racing against the receive handler itself).

Tejun points out that this is what the WQ_NON_REENTRANT flag is for,
and that there is a convenient system kthread we can use.

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -501,7 +501,7 @@ static void refill_work(struct work_stru
 	/* In theory, this can happen: if we don't get any buffers in
 	 * we will *never* try to fill again. */
 	if (still_empty)
-		schedule_delayed_work(&vi->refill, HZ/2);
+		queue_delayed_work(system_nrt_wq, &vi->refill, HZ/2);
 }
 
 static int virtnet_poll(struct napi_struct *napi, int budget)
@@ -520,7 +520,7 @@ again:
 
 	if (vi->num < vi->max / 2) {
 		if (!try_fill_recv(vi, GFP_ATOMIC))
-			schedule_delayed_work(&vi->refill, 0);
+			queue_delayed_work(system_nrt_wq, &vi->refill, 0);
 	}
 
 	/* Out of packets? */
@@ -721,7 +721,7 @@ static int virtnet_open(struct net_devic
 
 	/* Make sure we have some buffersl if oom use wq. */
 	if (!try_fill_recv(vi, GFP_KERNEL))
-		schedule_delayed_work(&vi->refill, 0);
+		queue_delayed_work(&system_nrt_wq, &vi->refill, 0);
 
 	virtnet_napi_enable(vi);
 	return 0;

^ permalink raw reply

* [PATCH] drivers/iwlwifi: use dma_zalloc_coherent() for DMA allocation
From: Djalal Harouni @ 2011-12-21  0:21 UTC (permalink / raw)
  To: Wey-Yi Guy, Intel Linux Wireless, John W. Linville,
	linux-wireless
  Cc: netdev, Andrew Morton

Replace dma_alloc_coherent()+memset() with the new dma_zalloc_coherent()

Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
---
 drivers/net/wireless/iwlwifi/iwl-trans-pcie.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
index ce91898..4363da7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
@@ -88,18 +88,16 @@ static int iwl_trans_rx_alloc(struct iwl_trans *trans)
 		return -EINVAL;
 
 	/* Allocate the circular buffer of Read Buffer Descriptors (RBDs) */
-	rxq->bd = dma_alloc_coherent(dev, sizeof(__le32) * RX_QUEUE_SIZE,
-				     &rxq->bd_dma, GFP_KERNEL);
+	rxq->bd = dma_zalloc_coherent(dev, sizeof(__le32) * RX_QUEUE_SIZE,
+				      &rxq->bd_dma, GFP_KERNEL);
 	if (!rxq->bd)
 		goto err_bd;
-	memset(rxq->bd, 0, sizeof(__le32) * RX_QUEUE_SIZE);
 
 	/*Allocate the driver's pointer to receive buffer status */
-	rxq->rb_stts = dma_alloc_coherent(dev, sizeof(*rxq->rb_stts),
-					  &rxq->rb_stts_dma, GFP_KERNEL);
+	rxq->rb_stts = dma_zalloc_coherent(dev, sizeof(*rxq->rb_stts),
+					   &rxq->rb_stts_dma, GFP_KERNEL);
 	if (!rxq->rb_stts)
 		goto err_rb_stts;
-	memset(rxq->rb_stts, 0, sizeof(*rxq->rb_stts));
 
 	return 0;
 
-- 
1.7.1

^ permalink raw reply related

* [PATCH 0/8] Fix virtual and physical address types
From: Ben Hutchings @ 2011-12-21  1:29 UTC (permalink / raw)
  To: LKML
  Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Kevin Curtis,
	netdev-u79uwXL29TY76Z2rM5mHXA, David Airlie,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, James E.J. Bottomley,
	linux-scsi, Hans J. Koch, Greg Kroah-Hartman, Venkat Venkatsubra,
	rds-devel-N0ozoZBvEnrZJqsBc5GL+g, Anil Ravindranath

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

This series fixes compiler warnings on some architectures about implicit
conversions and narrowing conversions between pointer and integer types.

Please apply these to the appropriate trees.

Ben.

Ben Hutchings (8):
  IB/cxgb4: Fix formatting of physical address
  farsync: Fix confusion about DMA address and buffer offset types
  drm: Do not include page offset in argument to virt_to_page()
  drm: Pass pointers to virt_to_page()
  [SCSI] tgt: Pass pointers to virt_to_page(), not integers
  uio: Pass pointers to virt_to_page(), not integers
  rds: Pass pointers to virt_to_page(), not integers
  pmcraid: Pass pointers to access_ok(), not integers

 drivers/gpu/drm/drm_pci.c            |    4 ++--
 drivers/gpu/drm/drm_vm.c             |    2 +-
 drivers/infiniband/hw/cxgb4/device.c |    4 ++--
 drivers/net/wan/farsync.c            |   19 +++++++------------
 drivers/scsi/pmcraid.c               |    3 ++-
 drivers/scsi/scsi_tgt_if.c           |    2 +-
 drivers/uio/uio.c                    |    6 ++++--
 net/rds/message.c                    |    2 +-
 8 files changed, 20 insertions(+), 22 deletions(-)

-- 
1.7.7.3



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: Ben Hutchings @ 2011-12-21  1:32 UTC (permalink / raw)
  To: Kevin Curtis, netdev; +Cc: LKML
In-Reply-To: <1324430940.2844.144.camel@deadeye>

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

Consistently use dma_addr_t for DMA addresses, except in
fst_{rx,tx}_dma where we truncate them to 32 bits.  (We know this is
OK because that's the default DMA mask for PCI devices.)

Consistently use u32 for buffer offsets within shared memory.

Compile-tested only.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 drivers/net/wan/farsync.c |   19 +++++++------------
 1 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index ebb9f24..98c04c6 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -886,15 +886,13 @@ fst_rx_dma_complete(struct fst_card_info *card, struct fst_port_info *port,
  *      Receive a frame through the DMA
  */
 static inline void
-fst_rx_dma(struct fst_card_info *card, dma_addr_t skb,
-	   dma_addr_t mem, int len)
+fst_rx_dma(struct fst_card_info *card, dma_addr_t skb, u32 mem, int len)
 {
 	/*
 	 * This routine will setup the DMA and start it
 	 */
 
-	dbg(DBG_RX, "In fst_rx_dma %lx %lx %d\n",
-	    (unsigned long) skb, (unsigned long) mem, len);
+	dbg(DBG_RX, "In fst_rx_dma %x %x %d\n", (u32)skb, mem, len);
 	if (card->dmarx_in_progress) {
 		dbg(DBG_ASS, "In fst_rx_dma while dma in progress\n");
 	}
@@ -915,20 +913,19 @@ fst_rx_dma(struct fst_card_info *card, dma_addr_t skb,
  *      Send a frame through the DMA
  */
 static inline void
-fst_tx_dma(struct fst_card_info *card, unsigned char *skb,
-	   unsigned char *mem, int len)
+fst_tx_dma(struct fst_card_info *card, dma_addr_t skb, u32 mem, int len)
 {
 	/*
 	 * This routine will setup the DMA and start it.
 	 */
 
-	dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);
+	dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len);
 	if (card->dmatx_in_progress) {
 		dbg(DBG_ASS, "In fst_tx_dma while dma in progress\n");
 	}
 
-	outl((unsigned long) skb, card->pci_conf + DMAPADR1);	/* Copy from here */
-	outl((unsigned long) mem, card->pci_conf + DMALADR1);	/* to here */
+	outl(skb, card->pci_conf + DMAPADR1);	/* Copy from here */
+	outl(mem, card->pci_conf + DMALADR1);	/* to here */
 	outl(len, card->pci_conf + DMASIZ1);	/* for this length */
 	outl(0x000000004, card->pci_conf + DMADPR1);	/* In this direction */
 
@@ -1405,9 +1402,7 @@ do_bottom_half_tx(struct fst_card_info *card)
 					card->dma_len_tx = skb->len;
 					card->dma_txpos = port->txpos;
 					fst_tx_dma(card,
-						   (char *) card->
-						   tx_dma_handle_card,
-						   (char *)
+						   card->tx_dma_handle_card,
 						   BUF_OFFSET(txBuffer[pi]
 							      [port->txpos][0]),
 						   skb->len);
-- 
1.7.7.3




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply related

* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: Ben Hutchings @ 2011-12-21  1:42 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <1324431172.2844.147.camel@deadeye>

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

I accidentally left signing enabled for this one, which I had intended
to disable since you've said that patchwork doesn't deal with
signatures.  Except this looks OK on patchwork:
<http://patchwork.ozlabs.org/patch/132548/>.

If that also looks OK to you, is there any reason to avoid signing
networking patches?

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* Re: [PATCH net-next] igb: add basic runtime PM support
From: Yan, Zheng @ 2011-12-21  1:49 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: e1000-devel, netdev@vger.kernel.org, bruce.w.allan,
	jesse.brandeburg, rjw, john.ronciak, davem@davemloft.net
In-Reply-To: <4EF0F32F.4040603@intel.com>

On 12/21/2011 04:42 AM, Alexander Duyck wrote:
> I am curious on if you have done any testing on an actual igb device with this code enabled?  My main concern is that the PHY is integrated into these parts, thus putting the MAC into D3 will result in behaviour changes in the PHY.  Specifically in the case of D3 the PHY on many of the igb parts will go into a low power link up mode, and may exclude a 1Gb/s link.  If this occurs I would expect to see a number of link issues on the device.
> 
I tested the code on a 82576 dual ports adapter, didn't noticed any issue.

> From what I can tell it looks like if you were to perform any ethtool operations while the link is down and this code is enabled it would likely result in multiple errors.  I am not sure what would happen if you were to run an "ethtool -t" test while the device was in a powered down state.
> 
This is not big problem because netif_device_detach() is called when suspending a device. "ethtool -t" reports "No such device" if the device is suspended. (There is a bug my patch, it doesn't calls netif_device_detach() if the device is down. Will send a new patch later)

> Also have you done any tests to see what the actual power savings of this patch might be?  I'm concerned there may be none due to the fact that putting a single function of an igb device into D3 will not result in any power savings.  In order to see any power savings you would need to put all of the functions on a given MAC into D3hot before the device will actually switch the PCIe bus to L1.  On e1000e parts this made sense since most parts are only single port, however since igb supports dual and quad port adapters I don't know how effective this would be.
>
Yes, there is no power saving unless all functions are put into D3hot. I used a power meter to measure the power consumption, about 1 watt was saved if both ports of 82576 were put into D3hot.

Regards
Yan, Zheng

> Thanks,
> 
> Alex
> 
> On 12/18/2011 09:07 PM, Yan, Zheng wrote:
>> Use the runtime power management framework to add basic runtime PM support
>> to the igb driver. Namely, make the driver suspend the device when the link
>> is off and set it up for generating a wakeup event after the link has been
>> detected again. Also make the driver suspend the device when the interface
>> is being shut down. This feature is disabled by default.
>>
>> Based on e1000e's runtime PM code.
>>
>> Signed-off-by: Zheng Yan<zheng.z.yan@intel.com>
>> ---
>>   drivers/net/ethernet/intel/igb/igb_main.c |  151 ++++++++++++++++++++++++-----
>>   1 files changed, 126 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
>> index 89d576c..aac529b 100644
>> --- a/drivers/net/ethernet/intel/igb/igb_main.c
>> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
>> @@ -53,6 +53,7 @@
>>   #include<linux/if_ether.h>
>>   #include<linux/aer.h>
>>   #include<linux/prefetch.h>
>> +#include<linux/pm_runtime.h>
>>   #ifdef CONFIG_IGB_DCA
>>   #include<linux/dca.h>
>>   #endif
>> @@ -172,8 +173,18 @@ static int igb_check_vf_assignment(struct igb_adapter *adapter);
>>   #endif
>>
>>   #ifdef CONFIG_PM
>> -static int igb_suspend(struct pci_dev *, pm_message_t);
>> -static int igb_resume(struct pci_dev *);
>> +static int igb_suspend(struct device *);
>> +static int igb_resume(struct device *);
>> +#ifdef CONFIG_PM_RUNTIME
>> +static int igb_runtime_suspend(struct device *dev);
>> +static int igb_runtime_resume(struct device *dev);
>> +static int igb_runtime_idle(struct device *dev);
>> +#endif
>> +static const struct dev_pm_ops igb_pm_ops = {
>> +    SET_SYSTEM_SLEEP_PM_OPS(igb_suspend, igb_resume)
>> +    SET_RUNTIME_PM_OPS(igb_runtime_suspend, igb_runtime_resume,
>> +            igb_runtime_idle)
>> +};
>>   #endif
>>   static void igb_shutdown(struct pci_dev *);
>>   #ifdef CONFIG_IGB_DCA
>> @@ -214,9 +225,7 @@ static struct pci_driver igb_driver = {
>>       .probe    = igb_probe,
>>       .remove   = __devexit_p(igb_remove),
>>   #ifdef CONFIG_PM
>> -    /* Power Management Hooks */
>> -    .suspend  = igb_suspend,
>> -    .resume   = igb_resume,
>> +    .driver.pm =&igb_pm_ops,
>>   #endif
>>       .shutdown = igb_shutdown,
>>       .err_handler =&igb_err_handler
>> @@ -2111,6 +2120,8 @@ static int __devinit igb_probe(struct pci_dev *pdev,
>>       default:
>>           break;
>>       }
>> +
>> +    pm_runtime_put_noidle(&pdev->dev);
>>       return 0;
>>
>>   err_register:
>> @@ -2150,6 +2161,8 @@ static void __devexit igb_remove(struct pci_dev *pdev)
>>       struct igb_adapter *adapter = netdev_priv(netdev);
>>       struct e1000_hw *hw =&adapter->hw;
>>
>> +    pm_runtime_get_noresume(&pdev->dev);
>> +
>>       /*
>>        * The watchdog timer may be rescheduled, so explicitly
>>        * disable watchdog from being rescheduled.
>> @@ -2472,16 +2485,23 @@ static int __devinit igb_sw_init(struct igb_adapter *adapter)
>>    * handler is registered with the OS, the watchdog timer is started,
>>    * and the stack is notified that the interface is ready.
>>    **/
>> -static int igb_open(struct net_device *netdev)
>> +static int __igb_open(struct net_device *netdev, bool resuming)
>>   {
>>       struct igb_adapter *adapter = netdev_priv(netdev);
>>       struct e1000_hw *hw =&adapter->hw;
>> +    struct pci_dev *pdev = adapter->pdev;
>>       int err;
>>       int i;
>>
>> -    /* disallow open during test */
>> -    if (test_bit(__IGB_TESTING,&adapter->state))
>> -        return -EBUSY;
>> +    if (!resuming) {
>> +        /* disallow open during test */
>> +        if (test_bit(__IGB_TESTING,&adapter->state))
>> +            return -EBUSY;
>> +        pm_runtime_get_sync(&pdev->dev);
>> +    } else if (test_bit(__IGB_TESTING,&adapter->state)) {
>> +        while (test_bit(__IGB_TESTING,&adapter->state))
>> +            msleep(100);
>> +    }
>>
>>       netif_carrier_off(netdev);
>>
>> @@ -2527,6 +2547,9 @@ static int igb_open(struct net_device *netdev)
>>
>>       netif_tx_start_all_queues(netdev);
>>
>> +    if (!resuming)
>> +        pm_runtime_put(&pdev->dev);
>> +
>>       /* start the watchdog. */
>>       hw->mac.get_link_status = 1;
>>       schedule_work(&adapter->watchdog_task);
>> @@ -2541,10 +2564,17 @@ err_setup_rx:
>>       igb_free_all_tx_resources(adapter);
>>   err_setup_tx:
>>       igb_reset(adapter);
>> +    if (!resuming)
>> +        pm_runtime_put(&pdev->dev);
>>
>>       return err;
>>   }
>>
>> +static int igb_open(struct net_device *netdev)
>> +{
>> +    return __igb_open(netdev, false);
>> +}
>> +
>>   /**
>>    * igb_close - Disables a network interface
>>    * @netdev: network interface device structure
>> @@ -2556,21 +2586,32 @@ err_setup_tx:
>>    * needs to be disabled.  A global MAC reset is issued to stop the
>>    * hardware, and all transmit and receive resources are freed.
>>    **/
>> -static int igb_close(struct net_device *netdev)
>> +static int __igb_close(struct net_device *netdev, bool suspending)
>>   {
>>       struct igb_adapter *adapter = netdev_priv(netdev);
>> +    struct pci_dev *pdev = adapter->pdev;
>>
>>       WARN_ON(test_bit(__IGB_RESETTING,&adapter->state));
>> -    igb_down(adapter);
>>
>> +    if (!suspending)
>> +        pm_runtime_get_sync(&pdev->dev);
>> +
>> +    igb_down(adapter);
>>       igb_free_irq(adapter);
>>
>>       igb_free_all_tx_resources(adapter);
>>       igb_free_all_rx_resources(adapter);
>>
>> +    if (!suspending)
>> +        pm_runtime_put_sync(&pdev->dev);
>>       return 0;
>>   }
>>
>> +static int igb_close(struct net_device *netdev)
>> +{
>> +    return __igb_close(netdev, false);
>> +}
>> +
>>   /**
>>    * igb_setup_tx_resources - allocate Tx resources (Descriptors)
>>    * @tx_ring: tx descriptor ring (for a specific queue) to setup
>> @@ -3630,6 +3671,9 @@ static void igb_watchdog_task(struct work_struct *work)
>>
>>       link = igb_has_link(adapter);
>>       if (link) {
>> +        /* Cancel scheduled suspend requests. */
>> +        pm_runtime_resume(netdev->dev.parent);
>> +
>>           if (!netif_carrier_ok(netdev)) {
>>               u32 ctrl;
>>               hw->mac.ops.get_speed_and_duplex(hw,
>> @@ -3701,6 +3745,9 @@ static void igb_watchdog_task(struct work_struct *work)
>>               if (!test_bit(__IGB_DOWN,&adapter->state))
>>                   mod_timer(&adapter->phy_info_timer,
>>                         round_jiffies(jiffies + 2 * HZ));
>> +
>> +            pm_schedule_suspend(netdev->dev.parent,
>> +                        MSEC_PER_SEC * 5);
>>           }
>>       }
>>
>> @@ -6583,21 +6630,24 @@ err_inval:
>>       return -EINVAL;
>>   }
>>
>> -static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake)
>> +static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake,
>> +              bool runtime)
>>   {
>>       struct net_device *netdev = pci_get_drvdata(pdev);
>>       struct igb_adapter *adapter = netdev_priv(netdev);
>>       struct e1000_hw *hw =&adapter->hw;
>>       u32 ctrl, rctl, status;
>> -    u32 wufc = adapter->wol;
>> +    u32 wufc = runtime ? E1000_WUFC_LNKC : adapter->wol;
>>   #ifdef CONFIG_PM
>>       int retval = 0;
>>   #endif
>>
>> -    netif_device_detach(netdev);
>> -
>> -    if (netif_running(netdev))
>> -        igb_close(netdev);
>> +    if (netif_running(netdev)) {
>> +        netif_device_detach(netdev);
>> +        __igb_close(netdev, true);
>> +    } else {
>> +        wufc&= ~E1000_WUFC_LNKC;
>> +    }
>>
>>       igb_clear_interrupt_scheme(adapter);
>>
>> @@ -6656,12 +6706,13 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake)
>>   }
>>
>>   #ifdef CONFIG_PM
>> -static int igb_suspend(struct pci_dev *pdev, pm_message_t state)
>> +static int igb_suspend(struct device *dev)
>>   {
>>       int retval;
>>       bool wake;
>> +    struct pci_dev *pdev = to_pci_dev(dev);
>>
>> -    retval = __igb_shutdown(pdev,&wake);
>> +    retval = __igb_shutdown(pdev,&wake, 0);
>>       if (retval)
>>           return retval;
>>
>> @@ -6675,8 +6726,9 @@ static int igb_suspend(struct pci_dev *pdev, pm_message_t state)
>>       return 0;
>>   }
>>
>> -static int igb_resume(struct pci_dev *pdev)
>> +static int igb_resume(struct device *dev)
>>   {
>> +    struct pci_dev *pdev = to_pci_dev(dev);
>>       struct net_device *netdev = pci_get_drvdata(pdev);
>>       struct igb_adapter *adapter = netdev_priv(netdev);
>>       struct e1000_hw *hw =&adapter->hw;
>> @@ -6697,7 +6749,18 @@ static int igb_resume(struct pci_dev *pdev)
>>       pci_enable_wake(pdev, PCI_D3hot, 0);
>>       pci_enable_wake(pdev, PCI_D3cold, 0);
>>
>> -    if (igb_init_interrupt_scheme(adapter)) {
>> +    if (!rtnl_is_locked()) {
>> +        /*
>> +         * shut up ASSERT_RTNL() warning in
>> +         * netif_set_real_num_tx/rx_queues.
>> +         */
>> +        rtnl_lock();
>> +        err = igb_init_interrupt_scheme(adapter);
>> +        rtnl_unlock();
>> +    } else {
>> +        err = igb_init_interrupt_scheme(adapter);
>> +    }
>> +    if (err) {
>>           dev_err(&pdev->dev, "Unable to allocate memory for queues\n");
>>           return -ENOMEM;
>>       }
>> @@ -6710,23 +6773,61 @@ static int igb_resume(struct pci_dev *pdev)
>>
>>       wr32(E1000_WUS, ~0);
>>
>> -    if (netif_running(netdev)) {
>> -        err = igb_open(netdev);
>> +    if (netdev->flags&  IFF_UP) {
>> +        err = __igb_open(netdev, true);
>>           if (err)
>>               return err;
>> +        netif_device_attach(netdev);
>>       }
>>
>> -    netif_device_attach(netdev);
>> +    return 0;
>> +}
>> +
>> +#ifdef CONFIG_PM_RUNTIME
>> +static int igb_runtime_idle(struct device *dev)
>> +{
>> +    struct pci_dev *pdev = to_pci_dev(dev);
>> +    struct net_device *netdev = pci_get_drvdata(pdev);
>> +    struct igb_adapter *adapter = netdev_priv(netdev);
>> +
>> +    if (!netif_running(netdev) || !igb_has_link(adapter))
>> +        pm_schedule_suspend(dev, MSEC_PER_SEC * 5);
>> +
>> +    return -EBUSY;
>> +}
>> +
>> +static int igb_runtime_suspend(struct device *dev)
>> +{
>> +    struct pci_dev *pdev = to_pci_dev(dev);
>> +    int retval;
>> +    bool wake;
>> +
>> +    retval = __igb_shutdown(pdev,&wake, 1);
>> +    if (retval)
>> +        return retval;
>> +
>> +    if (wake) {
>> +        pci_prepare_to_sleep(pdev);
>> +    } else {
>> +        pci_wake_from_d3(pdev, false);
>> +        pci_set_power_state(pdev, PCI_D3hot);
>> +    }
>>
>>       return 0;
>>   }
>> +
>> +static int igb_runtime_resume(struct device *dev)
>> +{
>> +    return igb_resume(dev);
>> +}
>> +#endif /* CONFIG_PM_RUNTIME */
>>   #endif
>>
>>   static void igb_shutdown(struct pci_dev *pdev)
>>   {
>>       bool wake;
>>
>> -    __igb_shutdown(pdev,&wake);
>> +    __igb_shutdown(pdev,&wake, 0);
>>
>>       if (system_state == SYSTEM_POWER_OFF) {
>>           pci_wake_from_d3(pdev, wake);
> 


------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

^ permalink raw reply

* linux-next: manual merge of the wireless-next tree with the  tree
From: Stephen Rothwell @ 2011-12-21  1:49 UTC (permalink / raw)
  To: John W. Linville
  Cc: linux-next, linux-kernel, Rusty Russell, David Miller, netdev,
	Franky Lin

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

Hi John,

Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c between commit
3db1cd5c05f3 ("net: fix assignment of 0/1 to bool variables") from the
tree and commit 3fb1d8d2dad3 ("brcm80211: fmac: move driver up status to
struct brcmf_bus") from the wireless-next tree.

I fixed it up (see below) and can carry the fix as necessary.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
index 2c3a99d,72bee2c..0000000
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
@@@ -805,7 -784,7 +784,7 @@@ static int brcmf_netdev_stop(struct net
  		return 0;
  
  	/* Set state and stop OS transmissions */
- 	drvr->up = false;
 -	drvr->bus_if->drvr_up = 0;
++	drvr->bus_if->drvr_up = false;
  	netif_stop_queue(ndev);
  
  	return 0;
@@@ -842,8 -821,8 +821,8 @@@ static int brcmf_netdev_open(struct net
  	}
  	/* Allow transmit calls */
  	netif_start_queue(ndev);
- 	drvr_priv->pub.up = true;
- 	if (brcmf_cfg80211_up(drvr_priv->pub.config)) {
 -	drvr->bus_if->drvr_up = 1;
++	drvr->bus_if->drvr_up = true;
+ 	if (brcmf_cfg80211_up(drvr->config)) {
  		brcmf_dbg(ERROR, "failed to bring up cfg80211\n");
  		return -1;
  	}

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH net-next] igb: add basic runtime PM support
From: Jeff Kirsher @ 2011-12-21  2:02 UTC (permalink / raw)
  To: Yan, Zheng
  Cc: Alexander Duyck, netdev@vger.kernel.org, e1000-devel,
	davem@davemloft.net, jesse.brandeburg, bruce.w.allan,
	carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
	peter.p.waskiewicz.jr, john.ronciak, rjw
In-Reply-To: <4EF13B27.5050809@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

On Wed, 2011-12-21 at 09:49 +0800, Yan, Zheng wrote:
> On 12/21/2011 04:42 AM, Alexander Duyck wrote:
> > I am curious on if you have done any testing on an actual igb device
> with this code enabled?  My main concern is that the PHY is integrated
> into these parts, thus putting the MAC into D3 will result in
> behaviour changes in the PHY.  Specifically in the case of D3 the PHY
> on many of the igb parts will go into a low power link up mode, and
> may exclude a 1Gb/s link.  If this occurs I would expect to see a
> number of link issues on the device.
> > 
> I tested the code on a 82576 dual ports adapter, didn't noticed any
> issue.
> 
> > From what I can tell it looks like if you were to perform any
> ethtool operations while the link is down and this code is enabled it
> would likely result in multiple errors.  I am not sure what would
> happen if you were to run an "ethtool -t" test while the device was in
> a powered down state.
> > 
> This is not big problem because netif_device_detach() is called when
> suspending a device. "ethtool -t" reports "No such device" if the
> device is suspended. (There is a bug my patch, it doesn't calls
> netif_device_detach() if the device is down. Will send a new patch
> later) 

I will hold off on adding this patch to my queue of patches since you
intend to send a v2 of the patch.

Thanks Zheng!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: David Miller @ 2011-12-21  4:46 UTC (permalink / raw)
  To: ben; +Cc: kevin.curtis, netdev, linux-kernel
In-Reply-To: <1324431172.2844.147.camel@deadeye>

From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 21 Dec 2011 01:32:52 +0000

> -	dbg(DBG_RX, "In fst_rx_dma %lx %lx %d\n",
> -	    (unsigned long) skb, (unsigned long) mem, len);
> +	dbg(DBG_RX, "In fst_rx_dma %x %x %d\n", (u32)skb, mem, len);

This is more appropriately fixed by using "%p" instead of casting
to a 32-bit int.

^ permalink raw reply

* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: David Miller @ 2011-12-21  4:48 UTC (permalink / raw)
  To: ben; +Cc: netdev
In-Reply-To: <1324431746.2844.161.camel@deadeye>

From: Ben Hutchings <ben@decadent.org.uk>
Date: Wed, 21 Dec 2011 01:42:26 +0000

> I accidentally left signing enabled for this one, which I had intended
> to disable since you've said that patchwork doesn't deal with
> signatures.  Except this looks OK on patchwork:
> <http://patchwork.ozlabs.org/patch/132548/>.
> 
> If that also looks OK to you, is there any reason to avoid signing
> networking patches?

What do you mean exactly by "signing".

Do you mean simply the "Signed-off-by: " tag, which you should always
add to your own patches, or something else?

^ permalink raw reply

* [PATCH] Avoid extra calculation in ip_route_input_common
From: Michael Wang @ 2011-12-21  5:12 UTC (permalink / raw)
  To: netdev@vger.kernel.org; +Cc: Michael Wang

From: Michael Wang <wangyun@linux.vnet.ibm.com>

If previous condition doesn't meet, the later check will be cancelled.
So we don't need to do all the calculation.

Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
---
 net/ipv4/route.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index f30112f..2872bfb 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2362,10 +2362,10 @@ int ip_route_input_common(struct sk_buff *skb, __be32 daddr, __be32 saddr,
 
 	for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
 	     rth = rcu_dereference(rth->dst.rt_next)) {
-		if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |
-		     ((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
-		     (rth->rt_route_iif ^ iif) |
-		     (rth->rt_key_tos ^ tos)) == 0 &&
+		if (((__force u32)rth->rt_key_dst ^ (__force u32)daddr) == 0 &&
+		    ((__force u32)rth->rt_key_src ^ (__force u32)saddr) == 0 &&
+		    rth->rt_route_iif == iif &&
+		    rth->rt_key_tos == tos &&
 		    rth->rt_mark == skb->mark &&
 		    net_eq(dev_net(rth->dst.dev), net) &&
 		    !rt_is_expired(rth)) {
-- 
1.7.4.1

^ permalink raw reply related

* Re: [PATCH] Avoid extra calculation in ip_route_input_common
From: Michael Wang @ 2011-12-21  5:19 UTC (permalink / raw)
  To: Michael Wang; +Cc: netdev@vger.kernel.org
In-Reply-To: <4EF16AA3.2070303@linux.vnet.ibm.com>

Please tell me if this patch is silly...
I really want to know the reason we need to use ^ and | instead of if and &&.

On 12/21/2011 01:12 PM, Michael Wang wrote:

> From: Michael Wang <wangyun@linux.vnet.ibm.com>
> 
> If previous condition doesn't meet, the later check will be cancelled.
> So we don't need to do all the calculation.
> 
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
> ---
>  net/ipv4/route.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index f30112f..2872bfb 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2362,10 +2362,10 @@ int ip_route_input_common(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> 
>  	for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
>  	     rth = rcu_dereference(rth->dst.rt_next)) {
> -		if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |


And I also wonder whether I can use "rth->rt_key_dst == daddr" here or not...

Thanks & Regards,
Michael Wang

> -		     ((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
> -		     (rth->rt_route_iif ^ iif) |
> -		     (rth->rt_key_tos ^ tos)) == 0 &&
> +		if (((__force u32)rth->rt_key_dst ^ (__force u32)daddr) == 0 &&
> +		    ((__force u32)rth->rt_key_src ^ (__force u32)saddr) == 0 &&
> +		    rth->rt_route_iif == iif &&
> +		    rth->rt_key_tos == tos &&
>  		    rth->rt_mark == skb->mark &&
>  		    net_eq(dev_net(rth->dst.dev), net) &&
>  		    !rt_is_expired(rth)) {

^ permalink raw reply

* [PATCH net-next V2] igb: add basic runtime PM support
From: Yan, Zheng @ 2011-12-21  5:21 UTC (permalink / raw)
  To: netdev@vger.kernel.org, e1000-devel
  Cc: davem@davemloft.net, jeffrey.t.kirsher, jesse.brandeburg,
	bruce.w.allan, carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
	peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak, rjw

Use the runtime power management framework to add basic runtime PM support
to the igb driver. Namely, make the driver suspend the device when the link
is off and set it up for generating a wakeup event after the link has been
detected again. This feature is disabled by default.

Based on e1000e's runtime PM code.

Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
---
Changes since v1:
Don't suspend the device when shutting down the interface.
Avoid race between runtime suspending and ethtool operations.

 drivers/net/ethernet/intel/igb/igb_ethtool.c |   16 +++
 drivers/net/ethernet/intel/igb/igb_main.c    |  136 ++++++++++++++++++++++----
 2 files changed, 133 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index e9335ef..3411073 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -36,6 +36,7 @@
 #include <linux/ethtool.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
+#include <linux/pm_runtime.h>
 
 #include "igb.h"
 
@@ -2159,6 +2160,19 @@ static void igb_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
 	}
 }
 
+static int igb_ethtool_begin(struct net_device *netdev)
+{
+	struct igb_adapter *adapter = netdev_priv(netdev);
+	pm_runtime_get_sync(&adapter->pdev->dev);
+	return 0;
+}
+
+static void igb_ethtool_complete(struct net_device *netdev)
+{
+	struct igb_adapter *adapter = netdev_priv(netdev);
+	pm_runtime_put(&adapter->pdev->dev);
+}
+
 static const struct ethtool_ops igb_ethtool_ops = {
 	.get_settings           = igb_get_settings,
 	.set_settings           = igb_set_settings,
@@ -2185,6 +2199,8 @@ static const struct ethtool_ops igb_ethtool_ops = {
 	.get_ethtool_stats      = igb_get_ethtool_stats,
 	.get_coalesce           = igb_get_coalesce,
 	.set_coalesce           = igb_set_coalesce,
+	.begin			= igb_ethtool_begin,
+	.complete		= igb_ethtool_complete,
 };
 
 void igb_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 143cfeb..aecfbf5 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -53,6 +53,7 @@
 #include <linux/if_ether.h>
 #include <linux/aer.h>
 #include <linux/prefetch.h>
+#include <linux/pm_runtime.h>
 #ifdef CONFIG_IGB_DCA
 #include <linux/dca.h>
 #endif
@@ -172,8 +173,18 @@ static int igb_check_vf_assignment(struct igb_adapter *adapter);
 #endif
 
 #ifdef CONFIG_PM
-static int igb_suspend(struct pci_dev *, pm_message_t);
-static int igb_resume(struct pci_dev *);
+static int igb_suspend(struct device *);
+static int igb_resume(struct device *);
+#ifdef CONFIG_PM_RUNTIME
+static int igb_runtime_suspend(struct device *dev);
+static int igb_runtime_resume(struct device *dev);
+static int igb_runtime_idle(struct device *dev);
+#endif
+static const struct dev_pm_ops igb_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(igb_suspend, igb_resume)
+	SET_RUNTIME_PM_OPS(igb_runtime_suspend, igb_runtime_resume,
+			igb_runtime_idle)
+};
 #endif
 static void igb_shutdown(struct pci_dev *);
 #ifdef CONFIG_IGB_DCA
@@ -214,9 +225,7 @@ static struct pci_driver igb_driver = {
 	.probe    = igb_probe,
 	.remove   = __devexit_p(igb_remove),
 #ifdef CONFIG_PM
-	/* Power Management Hooks */
-	.suspend  = igb_suspend,
-	.resume   = igb_resume,
+	.driver.pm = &igb_pm_ops,
 #endif
 	.shutdown = igb_shutdown,
 	.err_handler = &igb_err_handler
@@ -2111,6 +2120,8 @@ static int __devinit igb_probe(struct pci_dev *pdev,
 	default:
 		break;
 	}
+
+	pm_runtime_put_noidle(&pdev->dev);
 	return 0;
 
 err_register:
@@ -2150,6 +2161,8 @@ static void __devexit igb_remove(struct pci_dev *pdev)
 	struct igb_adapter *adapter = netdev_priv(netdev);
 	struct e1000_hw *hw = &adapter->hw;
 
+	pm_runtime_get_noresume(&pdev->dev);
+
 	/*
 	 * The watchdog timer may be rescheduled, so explicitly
 	 * disable watchdog from being rescheduled.
@@ -2472,16 +2485,22 @@ static int __devinit igb_sw_init(struct igb_adapter *adapter)
  * handler is registered with the OS, the watchdog timer is started,
  * and the stack is notified that the interface is ready.
  **/
-static int igb_open(struct net_device *netdev)
+static int __igb_open(struct net_device *netdev, bool resuming)
 {
 	struct igb_adapter *adapter = netdev_priv(netdev);
 	struct e1000_hw *hw = &adapter->hw;
+	struct pci_dev *pdev = adapter->pdev;
 	int err;
 	int i;
 
 	/* disallow open during test */
-	if (test_bit(__IGB_TESTING, &adapter->state))
+	if (test_bit(__IGB_TESTING, &adapter->state)) {
+		WARN_ON(resuming);
 		return -EBUSY;
+	}
+
+	if (!resuming)
+		pm_runtime_get_sync(&pdev->dev);
 
 	netif_carrier_off(netdev);
 
@@ -2527,6 +2546,9 @@ static int igb_open(struct net_device *netdev)
 
 	netif_tx_start_all_queues(netdev);
 
+	if (!resuming)
+		pm_runtime_put(&pdev->dev);
+
 	/* start the watchdog. */
 	hw->mac.get_link_status = 1;
 	schedule_work(&adapter->watchdog_task);
@@ -2541,10 +2563,17 @@ err_setup_rx:
 	igb_free_all_tx_resources(adapter);
 err_setup_tx:
 	igb_reset(adapter);
+	if (!resuming)
+		pm_runtime_put(&pdev->dev);
 
 	return err;
 }
 
+static int igb_open(struct net_device *netdev)
+{
+	return __igb_open(netdev, false);
+}
+
 /**
  * igb_close - Disables a network interface
  * @netdev: network interface device structure
@@ -2556,21 +2585,32 @@ err_setup_tx:
  * needs to be disabled.  A global MAC reset is issued to stop the
  * hardware, and all transmit and receive resources are freed.
  **/
-static int igb_close(struct net_device *netdev)
+static int __igb_close(struct net_device *netdev, bool suspending)
 {
 	struct igb_adapter *adapter = netdev_priv(netdev);
+	struct pci_dev *pdev = adapter->pdev;
 
 	WARN_ON(test_bit(__IGB_RESETTING, &adapter->state));
-	igb_down(adapter);
 
+	if (!suspending)
+		pm_runtime_get_sync(&pdev->dev);
+
+	igb_down(adapter);
 	igb_free_irq(adapter);
 
 	igb_free_all_tx_resources(adapter);
 	igb_free_all_rx_resources(adapter);
 
+	if (!suspending)
+		pm_runtime_put_sync(&pdev->dev);
 	return 0;
 }
 
+static int igb_close(struct net_device *netdev)
+{
+	return __igb_close(netdev, false);
+}
+
 /**
  * igb_setup_tx_resources - allocate Tx resources (Descriptors)
  * @tx_ring: tx descriptor ring (for a specific queue) to setup
@@ -3630,6 +3670,9 @@ static void igb_watchdog_task(struct work_struct *work)
 
 	link = igb_has_link(adapter);
 	if (link) {
+		/* Cancel scheduled suspend requests. */
+		pm_runtime_resume(netdev->dev.parent);
+
 		if (!netif_carrier_ok(netdev)) {
 			u32 ctrl;
 			hw->mac.ops.get_speed_and_duplex(hw,
@@ -3701,6 +3744,9 @@ static void igb_watchdog_task(struct work_struct *work)
 			if (!test_bit(__IGB_DOWN, &adapter->state))
 				mod_timer(&adapter->phy_info_timer,
 					  round_jiffies(jiffies + 2 * HZ));
+
+			pm_schedule_suspend(netdev->dev.parent,
+					    MSEC_PER_SEC * 5);
 		}
 	}
 
@@ -6579,13 +6625,14 @@ err_inval:
 	return -EINVAL;
 }
 
-static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake)
+static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake,
+			  bool runtime)
 {
 	struct net_device *netdev = pci_get_drvdata(pdev);
 	struct igb_adapter *adapter = netdev_priv(netdev);
 	struct e1000_hw *hw = &adapter->hw;
 	u32 ctrl, rctl, status;
-	u32 wufc = adapter->wol;
+	u32 wufc = runtime ? E1000_WUFC_LNKC : adapter->wol;
 #ifdef CONFIG_PM
 	int retval = 0;
 #endif
@@ -6593,7 +6640,7 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake)
 	netif_device_detach(netdev);
 
 	if (netif_running(netdev))
-		igb_close(netdev);
+		__igb_close(netdev, true);
 
 	igb_clear_interrupt_scheme(adapter);
 
@@ -6652,12 +6699,13 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake)
 }
 
 #ifdef CONFIG_PM
-static int igb_suspend(struct pci_dev *pdev, pm_message_t state)
+static int igb_suspend(struct device *dev)
 {
 	int retval;
 	bool wake;
+	struct pci_dev *pdev = to_pci_dev(dev);
 
-	retval = __igb_shutdown(pdev, &wake);
+	retval = __igb_shutdown(pdev, &wake, 0);
 	if (retval)
 		return retval;
 
@@ -6671,8 +6719,9 @@ static int igb_suspend(struct pci_dev *pdev, pm_message_t state)
 	return 0;
 }
 
-static int igb_resume(struct pci_dev *pdev)
+static int igb_resume(struct device *dev)
 {
+	struct pci_dev *pdev = to_pci_dev(dev);
 	struct net_device *netdev = pci_get_drvdata(pdev);
 	struct igb_adapter *adapter = netdev_priv(netdev);
 	struct e1000_hw *hw = &adapter->hw;
@@ -6693,7 +6742,18 @@ static int igb_resume(struct pci_dev *pdev)
 	pci_enable_wake(pdev, PCI_D3hot, 0);
 	pci_enable_wake(pdev, PCI_D3cold, 0);
 
-	if (igb_init_interrupt_scheme(adapter)) {
+	if (!rtnl_is_locked()) {
+		/*
+		 * shut up ASSERT_RTNL() warning in
+		 * netif_set_real_num_tx/rx_queues.
+		 */
+		rtnl_lock();
+		err = igb_init_interrupt_scheme(adapter);
+		rtnl_unlock();
+	} else {
+		err = igb_init_interrupt_scheme(adapter);
+	}
+	if (err) {
 		dev_err(&pdev->dev, "Unable to allocate memory for queues\n");
 		return -ENOMEM;
 	}
@@ -6706,23 +6766,61 @@ static int igb_resume(struct pci_dev *pdev)
 
 	wr32(E1000_WUS, ~0);
 
-	if (netif_running(netdev)) {
-		err = igb_open(netdev);
+	if (netdev->flags & IFF_UP) {
+		err = __igb_open(netdev, true);
 		if (err)
 			return err;
 	}
 
 	netif_device_attach(netdev);
+	return 0;
+}
+
+#ifdef CONFIG_PM_RUNTIME
+static int igb_runtime_idle(struct device *dev)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+	struct net_device *netdev = pci_get_drvdata(pdev);
+	struct igb_adapter *adapter = netdev_priv(netdev);
+
+	if (!igb_has_link(adapter))
+		pm_schedule_suspend(dev, MSEC_PER_SEC * 5);
+
+	return -EBUSY;
+}
+
+static int igb_runtime_suspend(struct device *dev)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+	int retval;
+	bool wake;
+
+	retval = __igb_shutdown(pdev, &wake, 1);
+	if (retval)
+		return retval;
+
+	if (wake) {
+		pci_prepare_to_sleep(pdev);
+	} else {
+		pci_wake_from_d3(pdev, false);
+		pci_set_power_state(pdev, PCI_D3hot);
+	}
 
 	return 0;
 }
+
+static int igb_runtime_resume(struct device *dev)
+{
+	return igb_resume(dev);
+}
+#endif /* CONFIG_PM_RUNTIME */
 #endif
 
 static void igb_shutdown(struct pci_dev *pdev)
 {
 	bool wake;
 
-	__igb_shutdown(pdev, &wake);
+	__igb_shutdown(pdev, &wake, 0);
 
 	if (system_state == SYSTEM_POWER_OFF) {
 		pci_wake_from_d3(pdev, wake);
-- 
1.7.7.4

^ permalink raw reply related

* Re: [PATCH] Avoid extra calculation in ip_route_input_common
From: Joe Perches @ 2011-12-21  5:23 UTC (permalink / raw)
  To: Michael Wang, Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <4EF16AA3.2070303@linux.vnet.ibm.com>

On Wed, 2011-12-21 at 13:12 +0800, Michael Wang wrote:
> From: Michael Wang <wangyun@linux.vnet.ibm.com>
> 
> If previous condition doesn't meet, the later check will be cancelled.
> So we don't need to do all the calculation.

Not sure about that.

> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
> ---
>  net/ipv4/route.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index f30112f..2872bfb 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2362,10 +2362,10 @@ int ip_route_input_common(struct sk_buff *skb, __be32 daddr, __be32 saddr,
>  
>  	for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
>  	     rth = rcu_dereference(rth->dst.rt_next)) {
> -		if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |
> -		     ((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
> -		     (rth->rt_route_iif ^ iif) |
> -		     (rth->rt_key_tos ^ tos)) == 0 &&
> +		if (((__force u32)rth->rt_key_dst ^ (__force u32)daddr) == 0 &&
> +		    ((__force u32)rth->rt_key_src ^ (__force u32)saddr) == 0 &&
> +		    rth->rt_route_iif == iif &&
> +		    rth->rt_key_tos == tos &&
>  		    rth->rt_mark == skb->mark &&
>  		    net_eq(dev_net(rth->dst.dev), net) &&
>  		    !rt_is_expired(rth)) {

See:

commit c0b8c32b1c96afc9b32b717927330025cc1c501e
Author: Stephen Hemminger <shemminger@vyatta.com>
Date:   Thu Apr 10 04:00:28 2008 -0700

    IPV4: use xor rather than multiple ands for route compare
    
    The comparison in ip_route_input is a hot path, by recoding the C
    "and" as bit operations, fewer conditional branches get generated
    so the code should be faster. Maybe someday Gcc will be smart
    enough to do this?
    
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Acked-by: Eric Dumazet <dada1@cosmosbay.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

^ permalink raw reply

* Re: [PATCH] Avoid extra calculation in ip_route_input_common
From: Michael Wang @ 2011-12-21  5:39 UTC (permalink / raw)
  To: Joe Perches; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <1324445033.20505.2.camel@joe2Laptop>

On 12/21/2011 01:23 PM, Joe Perches wrote:

> On Wed, 2011-12-21 at 13:12 +0800, Michael Wang wrote:
>> From: Michael Wang <wangyun@linux.vnet.ibm.com>
>>
>> If previous condition doesn't meet, the later check will be cancelled.
>> So we don't need to do all the calculation.
> 
> Not sure about that.
> 

Hi, Joe

Thanks for your reply :)

>> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
>> ---
>>  net/ipv4/route.c |    8 ++++----
>>  1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
>> index f30112f..2872bfb 100644
>> --- a/net/ipv4/route.c
>> +++ b/net/ipv4/route.c
>> @@ -2362,10 +2362,10 @@ int ip_route_input_common(struct sk_buff *skb, __be32 daddr, __be32 saddr,
>>  
>>  	for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
>>  	     rth = rcu_dereference(rth->dst.rt_next)) {
>> -		if ((((__force u32)rth->rt_key_dst ^ (__force u32)daddr) |
>> -		     ((__force u32)rth->rt_key_src ^ (__force u32)saddr) |
>> -		     (rth->rt_route_iif ^ iif) |
>> -		     (rth->rt_key_tos ^ tos)) == 0 &&
>> +		if (((__force u32)rth->rt_key_dst ^ (__force u32)daddr) == 0 &&
>> +		    ((__force u32)rth->rt_key_src ^ (__force u32)saddr) == 0 &&
>> +		    rth->rt_route_iif == iif &&
>> +		    rth->rt_key_tos == tos &&
>>  		    rth->rt_mark == skb->mark &&
>>  		    net_eq(dev_net(rth->dst.dev), net) &&
>>  		    !rt_is_expired(rth)) {
> 
> See:
> 
> commit c0b8c32b1c96afc9b32b717927330025cc1c501e
> Author: Stephen Hemminger <shemminger@vyatta.com>
> Date:   Thu Apr 10 04:00:28 2008 -0700
> 
>     IPV4: use xor rather than multiple ands for route compare
>     
>     The comparison in ip_route_input is a hot path, by recoding the C
>     "and" as bit operations, fewer conditional branches get generated
>     so the code should be faster. Maybe someday Gcc will be smart
>     enough to do this?


This is what confused me, why "fewer conditional branches get generated"
will make code faster?
In this example, I think the best condition when daddr is different, we
only need to go to one branch do compare then quit, won't this be faster?

Thanks,
Michael Wang

>     
>     Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>     Acked-by: Eric Dumazet <dada1@cosmosbay.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> 

^ permalink raw reply

* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: Ben Hutchings @ 2011-12-21  5:41 UTC (permalink / raw)
  To: David Miller; +Cc: kevin.curtis, netdev, linux-kernel
In-Reply-To: <20111220.234656.658595607282312696.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Tue, 2011-12-20 at 23:46 -0500, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Wed, 21 Dec 2011 01:32:52 +0000
> 
> > -	dbg(DBG_RX, "In fst_rx_dma %lx %lx %d\n",
> > -	    (unsigned long) skb, (unsigned long) mem, len);
> > +	dbg(DBG_RX, "In fst_rx_dma %x %x %d\n", (u32)skb, mem, len);
> 
> This is more appropriately fixed by using "%p" instead of casting
> to a 32-bit int.

'skb' is the physical address of the data in the skb.  Whereas 'mem' is
the offset of the corresponding buffer in shared memory.

All completely clear, right? ;-)

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: Ben Hutchings @ 2011-12-21  5:41 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20111220.234834.1265302793309771407.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Tue, 2011-12-20 at 23:48 -0500, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Wed, 21 Dec 2011 01:42:26 +0000
> 
> > I accidentally left signing enabled for this one, which I had intended
> > to disable since you've said that patchwork doesn't deal with
> > signatures.  Except this looks OK on patchwork:
> > <http://patchwork.ozlabs.org/patch/132548/>.
> > 
> > If that also looks OK to you, is there any reason to avoid signing
> > networking patches?
> 
> What do you mean exactly by "signing".
> 
> Do you mean simply the "Signed-off-by: " tag, which you should always
> add to your own patches, or something else?

GPG signing.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* Re: [PATCH] Avoid extra calculation in ip_route_input_common
From: Joe Perches @ 2011-12-21  5:50 UTC (permalink / raw)
  To: Michael Wang; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <4EF170F5.5040900@linux.vnet.ibm.com>

On Wed, 2011-12-21 at 13:39 +0800, Michael Wang wrote:
> On 12/21/2011 01:23 PM, Joe Perches wrote:
> > On Wed, 2011-12-21 at 13:12 +0800, Michael Wang wrote:
> >> From: Michael Wang <wangyun@linux.vnet.ibm.com>
> >>
> >> If previous condition doesn't meet, the later check will be cancelled.
> >> So we don't need to do all the calculation.
[]
> > commit c0b8c32b1c96afc9b32b717927330025cc1c501e
> > Author: Stephen Hemminger <shemminger@vyatta.com>
> > Date:   Thu Apr 10 04:00:28 2008 -0700
> > 
> >     IPV4: use xor rather than multiple ands for route compare
> >     
> >     The comparison in ip_route_input is a hot path, by recoding the C
> >     "and" as bit operations, fewer conditional branches get generated
> >     so the code should be faster. Maybe someday Gcc will be smart
> >     enough to do this?
> This is what confused me, why "fewer conditional branches get generated"
> will make code faster?
> In this example, I think the best condition when daddr is different, we
> only need to go to one branch do compare then quit, won't this be faster?

	if (a && b)
		...
pseudo-codes to:
	if (!a)
		goto fail;
	if (!b)
		goto fail;
	...
fail:

Each of those conditional branches has a cost.
Combining tests of variables in the same cache lines
has relatively little cost compared to the conditional
branches.

That's the theory anyway.

If you have tests that demonstrate otherwise, please
provide them.

cheers, Joe

^ permalink raw reply

* Re: [PATCH] Avoid extra calculation in ip_route_input_common
From: David Miller @ 2011-12-21  5:57 UTC (permalink / raw)
  To: wangyun; +Cc: netdev
In-Reply-To: <4EF16AA3.2070303@linux.vnet.ibm.com>

From: Michael Wang <wangyun@linux.vnet.ibm.com>
Date: Wed, 21 Dec 2011 13:12:03 +0800

> From: Michael Wang <wangyun@linux.vnet.ibm.com>
> 
> If previous condition doesn't meet, the later check will be cancelled.
> So we don't need to do all the calculation.
> 
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>

This is intentional to reduce the number of branch prediction
misses, please don't change this.

Once we read one of these values, the rest are incredibly cheap,
the real cost is if we have tons of real branches here, each
of which can be mispredicted.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox