* Re: iproute2 / tbf with large burst seems broken again
From: Jarek Poplawski @ 2009-08-25 20:03 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: netdev
In-Reply-To: <200908251416.13888.denys@visp.net.lb>
Denys Fedoryschenko wrote, On 08/25/2009 01:16 PM:
...
> But this one maybe will overflow because of limitations in iproute2.
>
> PPoE_146 ~ # ./tc -s -d qdisc show dev ppp13
> qdisc tbf 8004: root rate 96000bit burst 797465b/8 mpu 0b lat 275.4s
> Sent 82867 bytes 123 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> qdisc ingress ffff: parent ffff:fff1 ----------------
> Sent 506821 bytes 1916 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
>
> So maybe all of that just wrong way of using TBF.
I guess so; I've just recollected you described it some time ago. If
it were done only with TBF it would mean very large surges with line
speed and probably a lot of drops by ISP. Since you're ISP, you
probably drop this with HTB or something (then you should mention it
describing the problem) or keep very long queues which means great
latencies. Probably there is a lot of TCP resending btw. Using TBF
with HTB etc. is considered wrong idea anyway. (But if it works for
you shouldn't care.)
> At same time this means, if HTB and policers in filters done same way, that
> QoS in Linux cannot do similar to squid delay pools feature:
>
> First 10Mb give with 1Mbit/s, then slow 64Kbit/s. If user use less than 64K -
> recharge with that unused bandwidth a "10 Mb / 1Mbit bucket".
Could you remind me why HFSC can't do something similar for you?
Jarek P.
^ permalink raw reply
* 2.6.31-rc7-git2: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-25 20:00 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.30, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.
If you know of any other unresolved regressions from 2.6.30, please let me know
either and I'll add them to the list. Also, please let me know if any of the
entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-08-26 108 33 26
2009-08-20 102 32 29
2009-08-10 89 27 24
2009-08-02 76 36 28
2009-07-27 70 51 43
2009-07-07 35 25 21
2009-06-29 22 22 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14060
Subject : oops: sysfs_remove_link and i915
Submitter : Dominik Brodowski <linux-X3ehHDuj6sIIGcDfoQAp7OTW4wlIGRCZ@public.gmane.org>
Date : 2009-08-22 5:48 (4 days old)
References : http://marc.info/?l=linux-kernel&m=125092139113955&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14058
Subject : Oops in fsnotify
Submitter : Grant Wilson <grant.wilson-1HOZaDBbGgxaa/9Udqfwiw@public.gmane.org>
Date : 2009-08-20 15:48 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125078450923133&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14057
Subject : Strange network timeouts w/ e100
Submitter : Walt Holman <walt-Wo+ox+avW/9ByuSxxbvQtw@public.gmane.org>
Date : 2009-08-20 0:21 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125072831831443&w=4
Handled-By : Krzysztof Halasa <khc-9GfyWEdoJtJmR6Xm/wNWPw@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14031
Subject : dvb_usb_af9015: Oops on hotplugging
Submitter : Stefan Lippers-Hollmann <s.L-H-Mmb7MZpHnFY@public.gmane.org>
Date : 2009-08-05 20:32 (21 days old)
References : http://marc.info/?l=linux-kernel&m=124949716608828&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14018
Subject : kernel freezes, inotify problem
Submitter : Christoph Thielecke <christoph.thielecke-Mmb7MZpHnFY@public.gmane.org>
Date : 2009-08-19 12:48 (7 days old)
References : http://marc.info/?l=linux-kernel&m=125068616818353&w=4
Handled-By : Eric Paris <eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14016
Subject : mm/ipw2200 regression
Submitter : Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-15 16:56 (11 days old)
References : http://marc.info/?l=linux-kernel&m=125036437221408&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14015
Subject : pty regressed again, breaking expect and gcc's testsuite
Submitter : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date : 2009-08-14 23:41 (12 days old)
References : http://marc.info/?l=linux-kernel&m=125029329805643&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14013
Subject : hd don't show up
Submitter : Tim Blechmann <tim-xpEK/MU0Hawdnm+yROfE0A@public.gmane.org>
Date : 2009-08-14 8:26 (12 days old)
References : http://marc.info/?l=linux-kernel&m=125023842514480&w=4
Handled-By : Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14012
Subject : latest git fried my x86_64 imac
Submitter : Justin P. Mattock <justinmattock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-13 07:20 (13 days old)
References : http://marc.info/?l=linux-kernel&m=125014080427090&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14011
Subject : Kernel paging request failed in kmem_cache_alloc
Submitter : Matthias Dahl <ml_kernel-Rk1lLwyeSiSCvTm3UDtA3g@public.gmane.org>
Date : 2009-08-10 22:26 (16 days old)
References : http://marc.info/?l=linux-kernel&m=124993603825082&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13987
Subject : Received NMI interrupt at resume
Submitter : Christian Casteyde <casteyde.christian-GANU6spQydw@public.gmane.org>
Date : 2009-08-15 07:55 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13950
Subject : Oops when USB Serial disconnected while in use
Submitter : Bruno Prémont <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>
Date : 2009-08-08 17:47 (18 days old)
References : http://marc.info/?l=linux-kernel&m=124975432900466&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject : WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter : Fabio Comolli <fabio.comolli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-06 20:15 (20 days old)
References : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13942
Subject : Troubles with AoE and uninitialized object
Submitter : Bruno Prémont <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>
Date : 2009-08-04 10:12 (22 days old)
References : http://marc.info/?l=linux-kernel&m=124938117104811&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject : x86 Geode issue
Submitter : Martin-Éric Racine <q-funk-X3B1VOXEql0@public.gmane.org>
Date : 2009-08-03 12:58 (23 days old)
References : http://marc.info/?l=linux-kernel&m=124930434732481&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13940
Subject : iwlagn and sky2 stopped working, ACPI-related
Submitter : Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
Date : 2009-08-07 22:33 (19 days old)
References : http://marc.info/?l=linux-kernel&m=124968457731107&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13935
Subject : 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
Submitter : Adrian Ulrich <kernel-4ZM2p5qjiQGewZBzVTKGGg@public.gmane.org>
Date : 2009-08-08 22:08 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject : Huawei E169 GPRS connection causes Ooops
Submitter : Clemens Eisserer <linuxhippy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-04 09:02 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13869
Subject : Radeon framebuffer (w/o KMS) corruption at boot.
Submitter : Duncan <1i5t5.duncan-j9pdmedNgrk@public.gmane.org>
Date : 2009-07-29 16:44 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13848
Subject : iwlwifi (4965) regression since 2.6.30
Submitter : Lukas Hejtmanek <xhejtman-8qz54MUs51PtwjQa/ONI9g@public.gmane.org>
Date : 2009-07-26 7:57 (31 days old)
References : http://marc.info/?l=linux-kernel&m=124859658502866&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13836
Subject : suspend script fails, related to stdout?
Submitter : Tomas M. <tmezzadra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-07-17 21:24 (40 days old)
References : http://marc.info/?l=linux-kernel&m=124785853811667&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject : system freeze when switching to console
Submitter : Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2009-07-23 17:57 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13809
Subject : oprofile: possible circular locking dependency detected
Submitter : Jerome Marchand <jmarchan-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date : 2009-07-22 13:35 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13740
Subject : X server crashes with 2.6.31-rc2 when options are changed
Submitter : Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-07-07 15:19 (50 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject : 2.6.31-rc2: irq 16: nobody cared
Submitter : Niel Lambrechts <niel.lambrechts-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-07-06 18:32 (51 days old)
References : http://marc.info/?l=linux-kernel&m=124690524027166&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject : NULL pointer dereference at (null) (level2_spare_pgt)
Submitter : poornima nayak <mpnayak-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date : 2009-06-17 17:56 (70 days old)
References : http://lkml.org/lkml/2009/6/17/194
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14062
Subject : Failure to boot as xen guest
Submitter : Arnd Hannemann <hannemann-JasiFyN5vQG662+jY7v6MhvVK+yQ3ZXh@public.gmane.org>
Date : 2009-08-25 15:48 (1 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=83b519e8b9572c319c8e0c615ee5dd7272856090
References : http://marc.info/?l=linux-kernel&m=125121534229538&w=4
Handled-By : Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/43799/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14061
Subject : Crash due to buggy flat_phys_pkg_id
Submitter : Ravikiran G Thirumalai <kiran-HAaLjvVgespg9hUCZPvPmw@public.gmane.org>
Date : 2009-08-24 18:26 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125114085701508&w=4
Handled-By : Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/43806/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14030
Subject : Kernel NULL pointer dereference at 0000000000000008, pty-related
Submitter : Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Date : 2009-08-20 5:46 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125074724623423&w=4
Handled-By : Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/43679/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14017
Subject : _end symbol missing from Symbol.map
Submitter : Hannes Reinecke <hare-l3A5Bk7waGM@public.gmane.org>
Date : 2009-08-13 6:45 (13 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=091e52c3551d3031343df24b573b770b4c6c72b6
References : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
Handled-By : Hannes Reinecke <hare-l3A5Bk7waGM@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13960
Subject : rtl8187 not connect to wifi
Submitter : okias <d.okias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-08-10 19:16 (16 days old)
Handled-By : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=22798
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13948
Subject : ath5k broken after suspend-to-ram
Submitter : Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org>
Date : 2009-08-07 21:51 (19 days old)
References : http://marc.info/?l=linux-kernel&m=124968192727854&w=4
Handled-By : Nick Kossifidis <mickflemm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/38550/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13947
Subject : Libertas: Association request to the driver failed
Submitter : Daniel Mack <daniel-rDUAYElUppE@public.gmane.org>
Date : 2009-08-07 19:11 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
References : http://marc.info/?l=linux-kernel&m=124967234311481&w=4
Handled-By : Roel Kluin <roel.kluin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/43114/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.30,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13615
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Joe Perches @ 2009-08-25 19:56 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Stevens, David S. Miller, Eric Dumazet, netdev,
netdev-owner, niv, sri
In-Reply-To: <alpine.DEB.1.10.0908251514190.17963@gentwo.org>
On Tue, 2009-08-25 at 15:15 -0400, Christoph Lameter wrote:
> On Tue, 25 Aug 2009, David Stevens wrote:
> > Christoph Lameter <cl@linux-foundation.org> wrote on 08/25/2009 06:48:24
> > AM:
> > > On Mon, 24 Aug 2009, Sridhar Samudrala wrote:
> > > > If we count these drops as qdisc drops, should we also count them as
> > IP OUTDISCARDS?
> > > Yes.
> > Actually, no. (!)
> > IP_OUTDISCARDS should count the packets IP dropped, not
> > anything dropped at a lower layer (which, in general, it
> > is not aware of). If you count these in multiple layers,
> > then you don't really know who dropped it.
> They need to be accounted at the qdisc level though.
It's probably useful to be able to know when packets
and payloads are dropped. It may not be necessary though.
It's probably not a fundamental.
Chariot, LANforge and apps like it might care, but most all
other apps might not care at all.
Maybe these should be allowed with a CONFIG.
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Christoph Lameter @ 2009-08-25 19:15 UTC (permalink / raw)
To: David Stevens
Cc: David S. Miller, Eric Dumazet, netdev, netdev-owner, niv, sri
In-Reply-To: <OFB18AD855.24C5AC71-ON8825761D.00687D5E-8825761D.0068BB9C@us.ibm.com>
On Tue, 25 Aug 2009, David Stevens wrote:
> Christoph Lameter <cl@linux-foundation.org> wrote on 08/25/2009 06:48:24
> AM:
>
> > On Mon, 24 Aug 2009, Sridhar Samudrala wrote:
>
> > > If we count these drops as qdisc drops, should we also count them as
> IP OUTDISCARDS?
> >
> > Yes.
>
> Actually, no. (!)
>
> IP_OUTDISCARDS should count the packets IP dropped, not
> anything dropped at a lower layer (which, in general, it
> is not aware of). If you count these in multiple layers,
> then you don't really know who dropped it.
You are right. I skipped that IP OUTDICARDS reference. They need to be
accounted at the qdisc level though.
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: David Miller @ 2009-08-25 19:08 UTC (permalink / raw)
To: dlstevens; +Cc: cl, eric.dumazet, netdev, netdev-owner, niv, sri
In-Reply-To: <OFB18AD855.24C5AC71-ON8825761D.00687D5E-8825761D.0068BB9C@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Tue, 25 Aug 2009 12:03:58 -0700
> IP_OUTDISCARDS should count the packets IP dropped, not
> anything dropped at a lower layer (which, in general, it
> is not aware of). If you count these in multiple layers,
> then you don't really know who dropped it.
Right.
We are in danger of going from one extreme to the other.
Previously we lacked some drop detection capabilities
but now we've filled most of these holes and ON TOP of
all of that we have Neil's SKB drop tracer.
Let's not get carried away over-accounting this stuff.
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: David Stevens @ 2009-08-25 19:03 UTC (permalink / raw)
To: Christoph Lameter
Cc: David S. Miller, Eric Dumazet, netdev, netdev-owner, niv, sri
In-Reply-To: <alpine.DEB.1.10.0908250946520.5972@gentwo.org>
Christoph Lameter <cl@linux-foundation.org> wrote on 08/25/2009 06:48:24
AM:
> On Mon, 24 Aug 2009, Sridhar Samudrala wrote:
> > If we count these drops as qdisc drops, should we also count them as
IP OUTDISCARDS?
>
> Yes.
Actually, no. (!)
IP_OUTDISCARDS should count the packets IP dropped, not
anything dropped at a lower layer (which, in general, it
is not aware of). If you count these in multiple layers,
then you don't really know who dropped it.
+-DLS
^ permalink raw reply
* [PATCH 10/9] s2io: Generate complete messages using single line DBG_PRINTs
From: Joe Perches @ 2009-08-25 18:52 UTC (permalink / raw)
To: netdev
Cc: Anil Murthy, Sreenivasa Honnur, Sivakumar Subramani,
Rastapur Santosh, Ramkrishna Vepa, David S. Miller, Andrew Morton,
linux-next
In-Reply-To: <cover.1251170438.git.joe@perches.com>
Single line log messages should be emitted by a single call
where possible.
Converted multiple calls to DBG_PRINT to single call form.
Removed "s2io:" preface from DBG_PRINTs.
The DBG_PRINT macro now emits a log level and is surrounded by
a do {...} while (0)
All s2io log output is now prefaced with KBUILD_MODNAME ": "
via pr_fmt.
The DBG_PRINT macro should probably be converted to use the
dev_<level> form eventually.
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 1d13f60..3138df5 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -652,9 +652,9 @@ static int init_shared_mem(struct s2io_nic *nic)
size += tx_cfg->fifo_len;
}
if (size > MAX_AVAILABLE_TXDS) {
- DBG_PRINT(ERR_DBG, "s2io: Requested TxDs too high, ");
- DBG_PRINT(ERR_DBG, "Requested: %d, max supported: 8192\n",
- size);
+ DBG_PRINT(ERR_DBG,
+ "Too many TxDs requested: %d, max supported: %d\n",
+ size, MAX_AVAILABLE_TXDS);
return -EINVAL;
}
@@ -667,10 +667,9 @@ static int init_shared_mem(struct s2io_nic *nic)
* Legal values are from 2 to 8192
*/
if (size < 2) {
- DBG_PRINT(ERR_DBG, "s2io: Invalid fifo len (%d)", size);
- DBG_PRINT(ERR_DBG, "for fifo %d\n", i);
- DBG_PRINT(ERR_DBG, "s2io: Legal values for fifo len"
- "are 2 to 8192\n");
+ DBG_PRINT(ERR_DBG, "Fifo %d: Invalid length (%d) - "
+ "Valid lengths are 2 through 8192\n",
+ i, size);
return -EINVAL;
}
}
@@ -713,8 +712,8 @@ static int init_shared_mem(struct s2io_nic *nic)
tmp_v = pci_alloc_consistent(nic->pdev,
PAGE_SIZE, &tmp_p);
if (!tmp_v) {
- DBG_PRINT(INFO_DBG, "pci_alloc_consistent ");
- DBG_PRINT(INFO_DBG, "failed for TxDL\n");
+ DBG_PRINT(INFO_DBG,
+ "pci_alloc_consistent failed for TxDL\n");
return -ENOMEM;
}
/* If we got a zero DMA address(can happen on
@@ -725,17 +724,14 @@ static int init_shared_mem(struct s2io_nic *nic)
if (!tmp_p) {
mac_control->zerodma_virt_addr = tmp_v;
DBG_PRINT(INIT_DBG,
- "%s: Zero DMA address for TxDL. ",
- dev->name);
- DBG_PRINT(INIT_DBG,
- "Virtual address %p\n", tmp_v);
+ "%s: Zero DMA address for TxDL. "
+ "Virtual address %p\n",
+ dev->name, tmp_v);
tmp_v = pci_alloc_consistent(nic->pdev,
PAGE_SIZE, &tmp_p);
if (!tmp_v) {
DBG_PRINT(INFO_DBG,
- "pci_alloc_consistent ");
- DBG_PRINT(INFO_DBG,
- "failed for TxDL\n");
+ "pci_alloc_consistent failed for TxDL\n");
return -ENOMEM;
}
mem_allocated += PAGE_SIZE;
@@ -771,9 +767,9 @@ static int init_shared_mem(struct s2io_nic *nic)
struct ring_info *ring = &mac_control->rings[i];
if (rx_cfg->num_rxd % (rxd_count[nic->rxd_mode] + 1)) {
- DBG_PRINT(ERR_DBG, "%s: RxD count of ", dev->name);
- DBG_PRINT(ERR_DBG, "Ring%d is not a multiple of ", i);
- DBG_PRINT(ERR_DBG, "RxDs per Block");
+ DBG_PRINT(ERR_DBG, "%s: Ring%d RxD count is not a "
+ "multiple of RxDs per Block\n",
+ dev->name, i);
return FAILURE;
}
size += rx_cfg->num_rxd;
@@ -927,7 +923,7 @@ static int init_shared_mem(struct s2io_nic *nic)
tmp_v_addr = mac_control->stats_mem;
mac_control->stats_info = (struct stat_block *)tmp_v_addr;
memset(tmp_v_addr, 0, size);
- DBG_PRINT(INIT_DBG, "%s:Ring Mem PHY: 0x%llx\n", dev->name,
+ DBG_PRINT(INIT_DBG, "%s: Ring Mem PHY: 0x%llx\n", dev->name,
(unsigned long long)tmp_p_addr);
mac_control->stats_info->sw_stat.mem_allocated += mem_allocated;
return SUCCESS;
@@ -994,10 +990,9 @@ static void free_shared_mem(struct s2io_nic *nic)
mac_control->zerodma_virt_addr,
(dma_addr_t)0);
DBG_PRINT(INIT_DBG,
- "%s: Freeing TxDL with zero DMA addr. ",
- dev->name);
- DBG_PRINT(INIT_DBG, "Virtual address %p\n",
- mac_control->zerodma_virt_addr);
+ "%s: Freeing TxDL with zero DMA address. "
+ "Virtual address %p\n",
+ dev->name, mac_control->zerodma_virt_addr);
swstats->mem_freed += PAGE_SIZE;
}
kfree(fifo->list_info);
@@ -1120,6 +1115,7 @@ static int s2io_print_pci_mode(struct s2io_nic *nic)
register u64 val64 = 0;
int mode;
struct config_param *config = &nic->config;
+ const char *pcimode;
val64 = readq(&bar0->pci_mode);
mode = (u8)GET_PCI_MODE(val64);
@@ -1135,38 +1131,39 @@ static int s2io_print_pci_mode(struct s2io_nic *nic)
return mode;
}
- DBG_PRINT(ERR_DBG, "%s: Device is on %d bit ",
- nic->dev->name, val64 & PCI_MODE_32_BITS ? 32 : 64);
-
switch (mode) {
case PCI_MODE_PCI_33:
- DBG_PRINT(ERR_DBG, "33MHz PCI bus\n");
+ pcimode = "33MHz PCI bus";
break;
case PCI_MODE_PCI_66:
- DBG_PRINT(ERR_DBG, "66MHz PCI bus\n");
+ pcimode = "66MHz PCI bus";
break;
case PCI_MODE_PCIX_M1_66:
- DBG_PRINT(ERR_DBG, "66MHz PCIX(M1) bus\n");
+ pcimode = "66MHz PCIX(M1) bus";
break;
case PCI_MODE_PCIX_M1_100:
- DBG_PRINT(ERR_DBG, "100MHz PCIX(M1) bus\n");
+ pcimode = "100MHz PCIX(M1) bus";
break;
case PCI_MODE_PCIX_M1_133:
- DBG_PRINT(ERR_DBG, "133MHz PCIX(M1) bus\n");
+ pcimode = "133MHz PCIX(M1) bus";
break;
case PCI_MODE_PCIX_M2_66:
- DBG_PRINT(ERR_DBG, "133MHz PCIX(M2) bus\n");
+ pcimode = "133MHz PCIX(M2) bus";
break;
case PCI_MODE_PCIX_M2_100:
- DBG_PRINT(ERR_DBG, "200MHz PCIX(M2) bus\n");
+ pcimode = "200MHz PCIX(M2) bus";
break;
case PCI_MODE_PCIX_M2_133:
- DBG_PRINT(ERR_DBG, "266MHz PCIX(M2) bus\n");
+ pcimode = "266MHz PCIX(M2) bus";
break;
default:
- return -1; /* Unsupported bus speed */
+ pcimode = "unsupported bus!";
+ mode = -1;
}
+ DBG_PRINT(ERR_DBG, "%s: Device is on %d bit %s\n",
+ nic->dev->name, val64 & PCI_MODE_32_BITS ? 32 : 64, pcimode);
+
return mode;
}
@@ -1704,9 +1701,9 @@ static int init_nic(struct s2io_nic *nic)
/* Disable differentiated services steering logic */
for (i = 0; i < 64; i++) {
if (rts_ds_steer(nic, i, 0) == FAILURE) {
- DBG_PRINT(ERR_DBG, "%s: failed rts ds steering",
- dev->name);
- DBG_PRINT(ERR_DBG, "set on codepoint %d\n", i);
+ DBG_PRINT(ERR_DBG,
+ "%s: rts_ds_steer failed on codepoint %d\n",
+ dev->name, i);
return -ENODEV;
}
}
@@ -1783,7 +1780,7 @@ static int init_nic(struct s2io_nic *nic)
break;
if (time > 10) {
- DBG_PRINT(ERR_DBG, "%s: RTI init Failed\n",
+ DBG_PRINT(ERR_DBG, "%s: RTI init failed\n",
dev->name);
return -ENODEV;
}
@@ -2189,35 +2186,35 @@ static int verify_xena_quiescence(struct s2io_nic *sp)
mode = s2io_verify_pci_mode(sp);
if (!(val64 & ADAPTER_STATUS_TDMA_READY)) {
- DBG_PRINT(ERR_DBG, "%s", "TDMA is not ready!");
+ DBG_PRINT(ERR_DBG, "TDMA is not ready!\n");
return 0;
}
if (!(val64 & ADAPTER_STATUS_RDMA_READY)) {
- DBG_PRINT(ERR_DBG, "%s", "RDMA is not ready!");
+ DBG_PRINT(ERR_DBG, "RDMA is not ready!\n");
return 0;
}
if (!(val64 & ADAPTER_STATUS_PFC_READY)) {
- DBG_PRINT(ERR_DBG, "%s", "PFC is not ready!");
+ DBG_PRINT(ERR_DBG, "PFC is not ready!\n");
return 0;
}
if (!(val64 & ADAPTER_STATUS_TMAC_BUF_EMPTY)) {
- DBG_PRINT(ERR_DBG, "%s", "TMAC BUF is not empty!");
+ DBG_PRINT(ERR_DBG, "TMAC BUF is not empty!\n");
return 0;
}
if (!(val64 & ADAPTER_STATUS_PIC_QUIESCENT)) {
- DBG_PRINT(ERR_DBG, "%s", "PIC is not QUIESCENT!");
+ DBG_PRINT(ERR_DBG, "PIC is not QUIESCENT!\n");
return 0;
}
if (!(val64 & ADAPTER_STATUS_MC_DRAM_READY)) {
- DBG_PRINT(ERR_DBG, "%s", "MC_DRAM is not ready!");
+ DBG_PRINT(ERR_DBG, "MC_DRAM is not ready!\n");
return 0;
}
if (!(val64 & ADAPTER_STATUS_MC_QUEUES_READY)) {
- DBG_PRINT(ERR_DBG, "%s", "MC_QUEUES is not ready!");
+ DBG_PRINT(ERR_DBG, "MC_QUEUES is not ready!\n");
return 0;
}
if (!(val64 & ADAPTER_STATUS_M_PLL_LOCK)) {
- DBG_PRINT(ERR_DBG, "%s", "M_PLL is not locked!");
+ DBG_PRINT(ERR_DBG, "M_PLL is not locked!\n");
return 0;
}
@@ -2229,12 +2226,12 @@ static int verify_xena_quiescence(struct s2io_nic *sp)
if (!(val64 & ADAPTER_STATUS_P_PLL_LOCK) &&
sp->device_type == XFRAME_II_DEVICE &&
mode != PCI_MODE_PCI_33) {
- DBG_PRINT(ERR_DBG, "%s", "P_PLL is not locked!");
+ DBG_PRINT(ERR_DBG, "P_PLL is not locked!\n");
return 0;
}
if (!((val64 & ADAPTER_STATUS_RC_PRC_QUIESCENT) ==
ADAPTER_STATUS_RC_PRC_QUIESCENT)) {
- DBG_PRINT(ERR_DBG, "%s", "RC_PRC is not QUIESCENT!");
+ DBG_PRINT(ERR_DBG, "RC_PRC is not QUIESCENT!\n");
return 0;
}
return 1;
@@ -2339,9 +2336,9 @@ static int start_nic(struct s2io_nic *nic)
*/
val64 = readq(&bar0->adapter_status);
if (!verify_xena_quiescence(nic)) {
- DBG_PRINT(ERR_DBG, "%s: device is not ready, ", dev->name);
- DBG_PRINT(ERR_DBG, "Adapter status reads: 0x%llx\n",
- (unsigned long long)val64);
+ DBG_PRINT(ERR_DBG, "%s: device is not ready, "
+ "Adapter status reads: 0x%llx\n",
+ dev->name, (unsigned long long)val64);
return FAILURE;
}
@@ -2455,7 +2452,7 @@ static void free_tx_buffers(struct s2io_nic *nic)
}
}
DBG_PRINT(INTR_DBG,
- "%s:forcibly freeing %d skbs on FIFO%d\n",
+ "%s: forcibly freeing %d skbs on FIFO%d\n",
dev->name, cnt, i);
fifo->tx_curr_get_info.offset = 0;
fifo->tx_curr_put_info.offset = 0;
@@ -2547,8 +2544,8 @@ static int fill_rx_buffers(struct s2io_nic *nic, struct ring_info *ring,
if ((block_no == block_no1) &&
(off == ring->rx_curr_get_info.offset) &&
(rxdp->Host_Control)) {
- DBG_PRINT(INTR_DBG, "%s: Get and Put", ring->dev->name);
- DBG_PRINT(INTR_DBG, " info equated\n");
+ DBG_PRINT(INTR_DBG, "%s: Get and Put info equated\n",
+ ring->dev->name);
goto end;
}
if (off && (off == ring->rxd_count)) {
@@ -2583,8 +2580,8 @@ static int fill_rx_buffers(struct s2io_nic *nic, struct ring_info *ring,
/* allocate skb */
skb = dev_alloc_skb(size);
if (!skb) {
- DBG_PRINT(INFO_DBG, "%s: Out of ", ring->dev->name);
- DBG_PRINT(INFO_DBG, "memory to allocate SKBs\n");
+ DBG_PRINT(INFO_DBG, "%s: Could not allocate skb\n",
+ ring->dev->name);
if (first_rxdp) {
wmb();
first_rxdp->Control_1 |= RXD_OWN_XENA;
@@ -2806,7 +2803,7 @@ static void free_rx_buffers(struct s2io_nic *sp)
ring->rx_curr_put_info.offset = 0;
ring->rx_curr_get_info.offset = 0;
ring->rx_bufs_left = 0;
- DBG_PRINT(INIT_DBG, "%s:Freed 0x%x Rx Buffers on ring%d\n",
+ DBG_PRINT(INIT_DBG, "%s: Freed 0x%x Rx Buffers on ring%d\n",
dev->name, buf_cnt, i);
}
}
@@ -2814,8 +2811,8 @@ static void free_rx_buffers(struct s2io_nic *sp)
static int s2io_chk_rx_buffers(struct s2io_nic *nic, struct ring_info *ring)
{
if (fill_rx_buffers(nic, ring, 0) == -ENOMEM) {
- DBG_PRINT(INFO_DBG, "%s:Out of memory", ring->dev->name);
- DBG_PRINT(INFO_DBG, " in Rx Intr!!\n");
+ DBG_PRINT(INFO_DBG, "%s: Out of memory in Rx Intr!!\n",
+ ring->dev->name);
}
return 0;
}
@@ -2938,8 +2935,9 @@ static void s2io_netpoll(struct net_device *dev)
struct ring_info *ring = &mac_control->rings[i];
if (fill_rx_buffers(nic, ring, 0) == -ENOMEM) {
- DBG_PRINT(INFO_DBG, "%s:Out of memory", dev->name);
- DBG_PRINT(INFO_DBG, " in Rx Netpoll!!\n");
+ DBG_PRINT(INFO_DBG,
+ "%s: Out of memory in Rx Netpoll!!\n",
+ dev->name);
break;
}
}
@@ -2991,9 +2989,8 @@ static int rx_intr_handler(struct ring_info *ring_data, int budget)
}
skb = (struct sk_buff *)((unsigned long)rxdp->Host_Control);
if (skb == NULL) {
- DBG_PRINT(ERR_DBG, "%s: The skb is ",
+ DBG_PRINT(ERR_DBG, "%s: NULL skb in Rx Intr\n",
ring_data->dev->name);
- DBG_PRINT(ERR_DBG, "Null in Rx Intr\n");
return 0;
}
if (ring_data->rxd_mode == RXD_MODE_1) {
@@ -3126,8 +3123,8 @@ static void tx_intr_handler(struct fifo_info *fifo_data)
skb = s2io_txdl_getskb(fifo_data, txdlp, get_info.offset);
if (skb == NULL) {
spin_unlock_irqrestore(&fifo_data->tx_lock, flags);
- DBG_PRINT(ERR_DBG, "%s: Null skb ", __func__);
- DBG_PRINT(ERR_DBG, "in Tx Free Intr\n");
+ DBG_PRINT(ERR_DBG, "%s: NULL skb in Tx Free Intr\n",
+ __func__);
return;
}
pkt_cnt++;
@@ -3266,22 +3263,22 @@ static void s2io_chk_xpak_counter(u64 *counter, u64 * regs_stat, u32 index,
if (val64 == 3) {
switch (type) {
case 1:
- DBG_PRINT(ERR_DBG, "Take Xframe NIC out of "
- "service. Excessive temperatures may "
- "result in premature transceiver "
- "failure \n");
+ DBG_PRINT(ERR_DBG,
+ "Take Xframe NIC out of service.\n");
+ DBG_PRINT(ERR_DBG,
+"Excessive temperatures may result in premature transceiver failure.\n");
break;
case 2:
- DBG_PRINT(ERR_DBG, "Take Xframe NIC out of "
- "service Excessive bias currents may "
- "indicate imminent laser diode "
- "failure \n");
+ DBG_PRINT(ERR_DBG,
+ "Take Xframe NIC out of service.\n");
+ DBG_PRINT(ERR_DBG,
+"Excessive bias currents may indicate imminent laser diode failure.\n");
break;
case 3:
- DBG_PRINT(ERR_DBG, "Take Xframe NIC out of "
- "service Excessive laser output "
- "power may saturate far-end "
- "receiver\n");
+ DBG_PRINT(ERR_DBG,
+ "Take Xframe NIC out of service.\n");
+ DBG_PRINT(ERR_DBG,
+"Excessive laser output power may saturate far-end receiver.\n");
break;
default:
DBG_PRINT(ERR_DBG,
@@ -3321,15 +3318,16 @@ static void s2io_updt_xpak_counter(struct net_device *dev)
val64 = 0x0;
val64 = s2io_mdio_read(MDIO_MMD_PMAPMD, addr, dev);
if ((val64 == 0xFFFF) || (val64 == 0x0000)) {
- DBG_PRINT(ERR_DBG, "ERR: MDIO slave access failed - "
- "Returned %llx\n", (unsigned long long)val64);
+ DBG_PRINT(ERR_DBG,
+ "ERR: MDIO slave access failed - Returned %llx\n",
+ (unsigned long long)val64);
return;
}
/* Check for the expected value of control reg 1 */
if (val64 != MDIO_CTRL1_SPEED10G) {
- DBG_PRINT(ERR_DBG, "Incorrect value at PMA address 0x0000 - ");
- DBG_PRINT(ERR_DBG, "Returned: %llx- Expected: 0x%x\n",
+ DBG_PRINT(ERR_DBG, "Incorrect value at PMA address 0x0000 - "
+ "Returned: %llx- Expected: 0x%x\n",
(unsigned long long)val64, MDIO_CTRL1_SPEED10G);
return;
}
@@ -3481,7 +3479,7 @@ static void s2io_reset(struct s2io_nic *sp)
struct stat_block *stats;
struct swStat *swstats;
- DBG_PRINT(INIT_DBG, "%s - Resetting XFrame card %s\n",
+ DBG_PRINT(INIT_DBG, "%s: Resetting XFrame card %s\n",
__func__, sp->dev->name);
/* Back up the PCI-X CMD reg, dont want to lose MMRBC, OST settings */
@@ -3618,10 +3616,9 @@ static int s2io_set_swapper(struct s2io_nic *sp)
i++;
}
if (i == 4) {
- DBG_PRINT(ERR_DBG, "%s: Endian settings are wrong, ",
- dev->name);
- DBG_PRINT(ERR_DBG, "feedback read %llx\n",
- (unsigned long long)val64);
+ DBG_PRINT(ERR_DBG, "%s: Endian settings are wrong, "
+ "feedback read %llx\n",
+ dev->name, (unsigned long long)val64);
return FAILURE;
}
valr = value[i];
@@ -3650,8 +3647,8 @@ static int s2io_set_swapper(struct s2io_nic *sp)
}
if (i == 4) {
unsigned long long x = val64;
- DBG_PRINT(ERR_DBG, "Write failed, Xmsi_addr ");
- DBG_PRINT(ERR_DBG, "reads:0x%llx\n", x);
+ DBG_PRINT(ERR_DBG,
+ "Write failed, Xmsi_addr reads:0x%llx\n", x);
return FAILURE;
}
}
@@ -3711,10 +3708,9 @@ static int s2io_set_swapper(struct s2io_nic *sp)
val64 = readq(&bar0->pif_rd_swapper_fb);
if (val64 != 0x0123456789ABCDEFULL) {
/* Endian settings are incorrect, calls for another dekko. */
- DBG_PRINT(ERR_DBG, "%s: Endian settings are wrong, ",
- dev->name);
- DBG_PRINT(ERR_DBG, "feedback read %llx\n",
- (unsigned long long)val64);
+ DBG_PRINT(ERR_DBG,
+ "%s: Endian settings are wrong, feedback read %llx\n",
+ dev->name, (unsigned long long)val64);
return FAILURE;
}
@@ -3758,7 +3754,8 @@ static void restore_xmsi_data(struct s2io_nic *nic)
val64 = (s2BIT(7) | s2BIT(15) | vBIT(msix_index, 26, 6));
writeq(val64, &bar0->xmsi_access);
if (wait_for_msix_trans(nic, msix_index)) {
- DBG_PRINT(ERR_DBG, "failed in %s\n", __func__);
+ DBG_PRINT(ERR_DBG, "%s: index: %d failed\n",
+ __func__, msix_index);
continue;
}
}
@@ -3779,7 +3776,8 @@ static void store_xmsi_data(struct s2io_nic *nic)
val64 = (s2BIT(15) | vBIT(msix_index, 26, 6));
writeq(val64, &bar0->xmsi_access);
if (wait_for_msix_trans(nic, msix_index)) {
- DBG_PRINT(ERR_DBG, "failed in %s\n", __func__);
+ DBG_PRINT(ERR_DBG, "%s: index: %d failed\n",
+ __func__, msix_index);
continue;
}
addr = readq(&bar0->xmsi_address);
@@ -3851,7 +3849,7 @@ static int s2io_enable_msi_x(struct s2io_nic *nic)
ret = pci_enable_msix(nic->pdev, nic->entries, nic->num_entries);
/* We fail init if error or we get less vectors than min required */
if (ret) {
- DBG_PRINT(ERR_DBG, "s2io: Enabling MSI-X failed\n");
+ DBG_PRINT(ERR_DBG, "Enabling MSI-X failed\n");
kfree(nic->entries);
swstats->mem_freed += nic->num_entries *
sizeof(struct msix_entry);
@@ -3915,8 +3913,8 @@ static int s2io_test_msi(struct s2io_nic *sp)
if (!sp->msi_detected) {
/* MSI(X) test failed, go back to INTx mode */
DBG_PRINT(ERR_DBG, "%s: PCI %s: No interrupt was generated "
- "using MSI(X) during test\n", sp->dev->name,
- pci_name(pdev));
+ "using MSI(X) during test\n",
+ sp->dev->name, pci_name(pdev));
err = -EOPNOTSUPP;
}
@@ -4095,7 +4093,7 @@ static int s2io_xmit(struct sk_buff *skb, struct net_device *dev)
DBG_PRINT(TX_DBG, "%s: In Neterion Tx routine\n", dev->name);
if (unlikely(skb->len <= 0)) {
- DBG_PRINT(TX_DBG, "%s:Buffer has no data..\n", dev->name);
+ DBG_PRINT(TX_DBG, "%s: Buffer has no data..\n", dev->name);
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
@@ -5052,18 +5050,17 @@ static void s2io_set_multicast(struct net_device *dev)
val64 = readq(&bar0->mac_cfg);
sp->promisc_flg = 0;
- DBG_PRINT(INFO_DBG, "%s: left promiscuous mode\n",
- dev->name);
+ DBG_PRINT(INFO_DBG, "%s: left promiscuous mode\n", dev->name);
}
/* Update individual M_CAST address list */
if ((!sp->m_cast_flg) && dev->mc_count) {
if (dev->mc_count >
(config->max_mc_addr - config->max_mac_addr)) {
- DBG_PRINT(ERR_DBG, "%s: No more Rx filters ",
+ DBG_PRINT(ERR_DBG,
+ "%s: No more Rx filters can be added - "
+ "please enable ALL_MULTI instead\n",
dev->name);
- DBG_PRINT(ERR_DBG, "can be added, please enable ");
- DBG_PRINT(ERR_DBG, "ALL_MULTI instead\n");
return;
}
@@ -5086,8 +5083,9 @@ static void s2io_set_multicast(struct net_device *dev)
if (wait_for_cmd_complete(&bar0->rmac_addr_cmd_mem,
RMAC_ADDR_CMD_MEM_STROBE_CMD_EXECUTING,
S2IO_BIT_RESET)) {
- DBG_PRINT(ERR_DBG, "%s: Adding ", dev->name);
- DBG_PRINT(ERR_DBG, "Multicasts failed\n");
+ DBG_PRINT(ERR_DBG,
+ "%s: Adding Multicasts failed\n",
+ dev->name);
return;
}
}
@@ -5117,8 +5115,9 @@ static void s2io_set_multicast(struct net_device *dev)
if (wait_for_cmd_complete(&bar0->rmac_addr_cmd_mem,
RMAC_ADDR_CMD_MEM_STROBE_CMD_EXECUTING,
S2IO_BIT_RESET)) {
- DBG_PRINT(ERR_DBG, "%s: Adding ", dev->name);
- DBG_PRINT(ERR_DBG, "Multicasts failed\n");
+ DBG_PRINT(ERR_DBG,
+ "%s: Adding Multicasts failed\n",
+ dev->name);
return;
}
}
@@ -5552,7 +5551,7 @@ static void s2io_ethtool_gringparam(struct net_device *dev,
for (i = 0 ; i < sp->config.tx_fifo_num ; i++)
tx_desc_count += sp->config.tx_cfg[i].fifo_len;
- DBG_PRINT(INFO_DBG, "\nmax txds : %d\n", sp->config.max_txds);
+ DBG_PRINT(INFO_DBG, "max txds: %d\n", sp->config.max_txds);
ering->tx_pending = tx_desc_count;
rx_desc_count = 0;
for (i = 0 ; i < sp->config.rx_ring_num ; i++)
@@ -5886,8 +5885,10 @@ static int s2io_ethtool_seeprom(struct net_device *dev,
if (eeprom->magic != (sp->pdev->vendor | (sp->pdev->device << 16))) {
DBG_PRINT(ERR_DBG,
- "ETHTOOL_WRITE_EEPROM Err: Magic value ");
- DBG_PRINT(ERR_DBG, "is wrong, Its not 0x%x\n", eeprom->magic);
+ "ETHTOOL_WRITE_EEPROM Err: "
+ "Magic value is wrong, it is 0x%x should be 0x%x\n",
+ (sp->pdev->vendor | (sp->pdev->device << 16)),
+ eeprom->magic);
return -EFAULT;
}
@@ -5900,9 +5901,8 @@ static int s2io_ethtool_seeprom(struct net_device *dev,
if (write_eeprom(sp, (eeprom->offset + cnt), valid, 0)) {
DBG_PRINT(ERR_DBG,
- "ETHTOOL_WRITE_EEPROM Err: Cannot ");
- DBG_PRINT(ERR_DBG,
- "write into the specified offset\n");
+ "ETHTOOL_WRITE_EEPROM Err: "
+ "Cannot write into the specified offset\n");
return -EFAULT;
}
cnt++;
@@ -5934,13 +5934,13 @@ static int s2io_register_test(struct s2io_nic *sp, uint64_t *data)
val64 = readq(&bar0->pif_rd_swapper_fb);
if (val64 != 0x123456789abcdefULL) {
fail = 1;
- DBG_PRINT(INFO_DBG, "Read Test level 1 fails\n");
+ DBG_PRINT(INFO_DBG, "Read Test level %d fails\n", 1);
}
val64 = readq(&bar0->rmac_pause_cfg);
if (val64 != 0xc000ffff00000000ULL) {
fail = 1;
- DBG_PRINT(INFO_DBG, "Read Test level 2 fails\n");
+ DBG_PRINT(INFO_DBG, "Read Test level %d fails\n", 2);
}
val64 = readq(&bar0->rx_queue_cfg);
@@ -5950,13 +5950,13 @@ static int s2io_register_test(struct s2io_nic *sp, uint64_t *data)
exp_val = 0x0808080808080808ULL;
if (val64 != exp_val) {
fail = 1;
- DBG_PRINT(INFO_DBG, "Read Test level 3 fails\n");
+ DBG_PRINT(INFO_DBG, "Read Test level %d fails\n", 3);
}
val64 = readq(&bar0->xgxs_efifo_cfg);
if (val64 != 0x000000001923141EULL) {
fail = 1;
- DBG_PRINT(INFO_DBG, "Read Test level 4 fails\n");
+ DBG_PRINT(INFO_DBG, "Read Test level %d fails\n", 4);
}
val64 = 0x5A5A5A5A5A5A5A5AULL;
@@ -5964,7 +5964,7 @@ static int s2io_register_test(struct s2io_nic *sp, uint64_t *data)
val64 = readq(&bar0->xmsi_data);
if (val64 != 0x5A5A5A5A5A5A5A5AULL) {
fail = 1;
- DBG_PRINT(ERR_DBG, "Write Test level 1 fails\n");
+ DBG_PRINT(ERR_DBG, "Write Test level %d fails\n", 1);
}
val64 = 0xA5A5A5A5A5A5A5A5ULL;
@@ -5972,7 +5972,7 @@ static int s2io_register_test(struct s2io_nic *sp, uint64_t *data)
val64 = readq(&bar0->xmsi_data);
if (val64 != 0xA5A5A5A5A5A5A5A5ULL) {
fail = 1;
- DBG_PRINT(ERR_DBG, "Write Test level 2 fails\n");
+ DBG_PRINT(ERR_DBG, "Write Test level %d fails\n", 2);
}
*data = fail;
@@ -6825,8 +6825,9 @@ static void s2io_set_link(struct work_struct *work)
}
nic->device_enabled_once = true;
} else {
- DBG_PRINT(ERR_DBG, "%s: Error: ", dev->name);
- DBG_PRINT(ERR_DBG, "device is not Quiescent\n");
+ DBG_PRINT(ERR_DBG,
+ "%s: Error: device is not Quiescent\n",
+ dev->name);
s2io_stop_all_tx_queue(nic);
}
}
@@ -6876,9 +6877,9 @@ static int set_rxd_buffer_pointer(struct s2io_nic *sp, struct RxD_t *rxdp,
} else {
*skb = dev_alloc_skb(size);
if (!(*skb)) {
- DBG_PRINT(INFO_DBG, "%s: Out of ", dev->name);
- DBG_PRINT(INFO_DBG, "memory to allocate ");
- DBG_PRINT(INFO_DBG, "1 buf mode SKBs\n");
+ DBG_PRINT(INFO_DBG,
+ "%s: Out of memory to allocate %s\n",
+ dev->name, "1 buf mode SKBs");
stats->mem_alloc_fail_cnt++;
return -ENOMEM ;
}
@@ -6905,9 +6906,10 @@ static int set_rxd_buffer_pointer(struct s2io_nic *sp, struct RxD_t *rxdp,
} else {
*skb = dev_alloc_skb(size);
if (!(*skb)) {
- DBG_PRINT(INFO_DBG, "%s: Out of ", dev->name);
- DBG_PRINT(INFO_DBG, "memory to allocate ");
- DBG_PRINT(INFO_DBG, "2 buf mode SKBs\n");
+ DBG_PRINT(INFO_DBG,
+ "%s: Out of memory to allocate %s\n",
+ dev->name,
+ "2 buf mode SKBs");
stats->mem_alloc_fail_cnt++;
return -ENOMEM;
}
@@ -7095,8 +7097,8 @@ static int s2io_add_isr(struct s2io_nic *sp)
}
if (!err) {
pr_info("MSI-X-RX %d entries enabled\n", --msix_rx_cnt);
- DBG_PRINT(INFO_DBG, "MSI-X-TX entries enabled"
- " through alarm vector\n");
+ DBG_PRINT(INFO_DBG,
+ "MSI-X-TX entries enabled through alarm vector\n");
}
}
if (sp->config.intr_type == INTA) {
@@ -7176,8 +7178,8 @@ static void do_s2io_card_down(struct s2io_nic *sp, int do_io)
msleep(50);
cnt++;
if (cnt == 10) {
- DBG_PRINT(ERR_DBG, "s2io_close:Device not Quiescent ");
- DBG_PRINT(ERR_DBG, "adaper status reads 0x%llx\n",
+ DBG_PRINT(ERR_DBG, "Device not Quiescent - "
+ "adapter status reads 0x%llx\n",
(unsigned long long)val64);
break;
}
@@ -7628,7 +7630,7 @@ static int s2io_verify_parm(struct pci_dev *pdev, u8 *dev_intr_type,
u8 *dev_multiq)
{
if ((tx_fifo_num > MAX_TX_FIFOS) || (tx_fifo_num < 1)) {
- DBG_PRINT(ERR_DBG, "s2io: Requested number of tx fifos "
+ DBG_PRINT(ERR_DBG, "Requested number of tx fifos "
"(%d) not supported\n", tx_fifo_num);
if (tx_fifo_num < 1)
@@ -7636,8 +7638,7 @@ static int s2io_verify_parm(struct pci_dev *pdev, u8 *dev_intr_type,
else
tx_fifo_num = MAX_TX_FIFOS;
- DBG_PRINT(ERR_DBG, "s2io: Default to %d ", tx_fifo_num);
- DBG_PRINT(ERR_DBG, "tx fifos\n");
+ DBG_PRINT(ERR_DBG, "Default to %d tx fifos\n", tx_fifo_num);
}
if (multiq)
@@ -7646,7 +7647,7 @@ static int s2io_verify_parm(struct pci_dev *pdev, u8 *dev_intr_type,
if (tx_steering_type && (1 == tx_fifo_num)) {
if (tx_steering_type != TX_DEFAULT_STEERING)
DBG_PRINT(ERR_DBG,
- "s2io: Tx steering is not supported with "
+ "Tx steering is not supported with "
"one fifo. Disabling Tx steering.\n");
tx_steering_type = NO_STEERING;
}
@@ -7654,21 +7655,21 @@ static int s2io_verify_parm(struct pci_dev *pdev, u8 *dev_intr_type,
if ((tx_steering_type < NO_STEERING) ||
(tx_steering_type > TX_DEFAULT_STEERING)) {
DBG_PRINT(ERR_DBG,
- "s2io: Requested transmit steering not supported\n");
- DBG_PRINT(ERR_DBG, "s2io: Disabling transmit steering\n");
+ "Requested transmit steering not supported\n");
+ DBG_PRINT(ERR_DBG, "Disabling transmit steering\n");
tx_steering_type = NO_STEERING;
}
if (rx_ring_num > MAX_RX_RINGS) {
DBG_PRINT(ERR_DBG,
- "s2io: Requested number of rx rings not supported\n");
- DBG_PRINT(ERR_DBG, "s2io: Default to %d rx rings\n",
+ "Requested number of rx rings not supported\n");
+ DBG_PRINT(ERR_DBG, "Default to %d rx rings\n",
MAX_RX_RINGS);
rx_ring_num = MAX_RX_RINGS;
}
if ((*dev_intr_type != INTA) && (*dev_intr_type != MSI_X)) {
- DBG_PRINT(ERR_DBG, "s2io: Wrong intr_type requested. "
+ DBG_PRINT(ERR_DBG, "Wrong intr_type requested. "
"Defaulting to INTA\n");
*dev_intr_type = INTA;
}
@@ -7676,14 +7677,14 @@ static int s2io_verify_parm(struct pci_dev *pdev, u8 *dev_intr_type,
if ((*dev_intr_type == MSI_X) &&
((pdev->device != PCI_DEVICE_ID_HERC_WIN) &&
(pdev->device != PCI_DEVICE_ID_HERC_UNI))) {
- DBG_PRINT(ERR_DBG, "s2io: Xframe I does not support MSI_X. "
+ DBG_PRINT(ERR_DBG, "Xframe I does not support MSI_X. "
"Defaulting to INTA\n");
*dev_intr_type = INTA;
}
if ((rx_ring_mode != 1) && (rx_ring_mode != 2)) {
- DBG_PRINT(ERR_DBG, "s2io: Requested ring mode not supported\n");
- DBG_PRINT(ERR_DBG, "s2io: Defaulting to 1-buffer mode\n");
+ DBG_PRINT(ERR_DBG, "Requested ring mode not supported\n");
+ DBG_PRINT(ERR_DBG, "Defaulting to 1-buffer mode\n");
rx_ring_mode = 1;
}
return SUCCESS;
@@ -7776,12 +7777,12 @@ s2io_init_nic(struct pci_dev *pdev, const struct pci_device_id *pre)
ret = pci_enable_device(pdev);
if (ret) {
DBG_PRINT(ERR_DBG,
- "s2io_init_nic: pci_enable_device failed\n");
+ "%s: pci_enable_device failed\n", __func__);
return ret;
}
if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
- DBG_PRINT(INIT_DBG, "s2io_init_nic: Using 64bit DMA\n");
+ DBG_PRINT(INIT_DBG, "%s: Using 64bit DMA\n", __func__);
dma_flag = true;
if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
DBG_PRINT(ERR_DBG,
@@ -7791,14 +7792,14 @@ s2io_init_nic(struct pci_dev *pdev, const struct pci_device_id *pre)
return -ENOMEM;
}
} else if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
- DBG_PRINT(INIT_DBG, "s2io_init_nic: Using 32bit DMA\n");
+ DBG_PRINT(INIT_DBG, "%s: Using 32bit DMA\n", __func__);
} else {
pci_disable_device(pdev);
return -ENOMEM;
}
ret = pci_request_regions(pdev, s2io_driver_name);
if (ret) {
- DBG_PRINT(ERR_DBG, "%s: Request Regions failed - %x \n",
+ DBG_PRINT(ERR_DBG, "%s: Request Regions failed - %x\n",
__func__, ret);
pci_disable_device(pdev);
return -ENODEV;
@@ -7992,7 +7993,7 @@ s2io_init_nic(struct pci_dev *pdev, const struct pci_device_id *pre)
/* Setting swapper control on the NIC, for proper reset operation */
if (s2io_set_swapper(sp)) {
- DBG_PRINT(ERR_DBG, "%s:swapper settings are wrong\n",
+ DBG_PRINT(ERR_DBG, "%s: swapper settings are wrong\n",
dev->name);
ret = -EAGAIN;
goto set_swap_failed;
@@ -8002,8 +8003,8 @@ s2io_init_nic(struct pci_dev *pdev, const struct pci_device_id *pre)
if (sp->device_type & XFRAME_II_DEVICE) {
mode = s2io_verify_pci_mode(sp);
if (mode < 0) {
- DBG_PRINT(ERR_DBG, "%s: ", __func__);
- DBG_PRINT(ERR_DBG, " Unsupported PCI bus mode\n");
+ DBG_PRINT(ERR_DBG, "%s: Unsupported PCI bus mode\n",
+ __func__);
ret = -EBADSLT;
goto set_swap_failed;
}
@@ -8021,7 +8022,7 @@ s2io_init_nic(struct pci_dev *pdev, const struct pci_device_id *pre)
if (ret) {
DBG_PRINT(ERR_DBG,
- "s2io: MSI-X requested but failed to enable\n");
+ "MSI-X requested but failed to enable\n");
sp->config.intr_type = INTA;
}
}
@@ -8137,12 +8138,11 @@ s2io_init_nic(struct pci_dev *pdev, const struct pci_device_id *pre)
sp->product_name, pdev->revision);
DBG_PRINT(ERR_DBG, "%s: Driver version %s\n", dev->name,
s2io_driver_version);
- DBG_PRINT(ERR_DBG, "%s: MAC ADDR: %pM\n", dev->name, dev->dev_addr);
- DBG_PRINT(ERR_DBG, "SERIAL NUMBER: %s\n", sp->serial_num);
+ DBG_PRINT(ERR_DBG, "%s: MAC Address: %pM\n", dev->name, dev->dev_addr);
+ DBG_PRINT(ERR_DBG, "Serial number: %s\n", sp->serial_num);
if (sp->device_type & XFRAME_II_DEVICE) {
mode = s2io_print_pci_mode(sp);
if (mode < 0) {
- DBG_PRINT(ERR_DBG, " Unsupported PCI bus mode\n");
ret = -EBADSLT;
unregister_netdev(dev);
goto set_swap_failed;
@@ -8532,8 +8532,9 @@ static int s2io_club_tcp_session(struct ring_info *ring_data, u8 *buffer,
*lro = l_lro;
if ((*lro)->tcp_next_seq != ntohl(tcph->seq)) {
- DBG_PRINT(INFO_DBG, "%s:Out of order. expected "
- "0x%x, actual 0x%x\n", __func__,
+ DBG_PRINT(INFO_DBG, "%s: Out of sequence. "
+ "expected 0x%x, actual 0x%x\n",
+ __func__,
(*lro)->tcp_next_seq,
ntohl(tcph->seq));
@@ -8571,7 +8572,7 @@ static int s2io_club_tcp_session(struct ring_info *ring_data, u8 *buffer,
}
if (ret == 0) { /* sessions exceeded */
- DBG_PRINT(INFO_DBG, "%s:All LRO sessions already in use\n",
+ DBG_PRINT(INFO_DBG, "%s: All LRO sessions already in use\n",
__func__);
*lro = NULL;
return ret;
@@ -8593,7 +8594,7 @@ static int s2io_club_tcp_session(struct ring_info *ring_data, u8 *buffer,
}
break;
default:
- DBG_PRINT(ERR_DBG, "%s:Dont know, can't say!!\n", __func__);
+ DBG_PRINT(ERR_DBG, "%s: Don't know, can't say!!\n", __func__);
break;
}
diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
index d5c5be6..47c36e0 100644
--- a/drivers/net/s2io.h
+++ b/drivers/net/s2io.h
@@ -64,7 +64,10 @@ enum {
static int debug_level = ERR_DBG;
/* DEBUG message print. */
-#define DBG_PRINT(dbg_level, args...) if(!(debug_level<dbg_level)) printk(args)
+#define DBG_PRINT(dbg_level, fmt, args...) do { \
+ if (dbg_level >= debug_level) \
+ pr_info(fmt, ##args); \
+ } while (0)
/* Protocol assist features of the NIC */
#define L3_CKSUM_OK 0xFFFF
^ permalink raw reply related
* Re: [Bonding-devel] [PATCH net-next-2.6] bonding: introduce primary_lazy option
From: Jay Vosburgh @ 2009-08-25 18:41 UTC (permalink / raw)
To: =?ISO-8859-1?Q?Nicolas_de_Peslo=FCan?=
Cc: netdev, bonding-devel, davem, Jiri Pirko
In-Reply-To: <4A941FD9.6050304@free.fr>
Nicolas de Pesloüan <nicolas.2p.debian@free.fr> wrote:
>Jiri Pirko wrote:
>> Mon, Aug 24, 2009 at 07:35:17PM CEST, fubar@us.ibm.com wrote:
>>> I'm still unclear as to why it's better to add another special
>>> case option to bonding instead of changing this in user space, other
>>> than it'd be a change to user space (initscripts / sysconfig).
>>>
>>> The way I see it, this patch is adding a mechanism that says,
>>> effectively, "make slave X the active slave, but do it only once."
>>> There is already a way to do that in bonding (sysfs, as above, or
>>> ifenslave -c); I am reluctant to add another without good reason.
>>
>> Hello Jay.
>>
>> As I already replied you once it's not only about selecting a slave at the
>> start. It's also about following:
>>
>> Imagine you have bond with 3 slaves:
>> eth0 eth1 eth2
>> UP(curr) UP UP
>> DOWN UP(curr) UP
>> UP UP(curr) UP
>> UP DOWN UP(curr)
>>
>> eth2 ends up being current active but we prefer eth0 (as primary interface).
>> This is not desirable and is solved by primary_lazy option.
>>
>> Jirka
>>
>>> I'm not necessarily against the "weight" business in general.
>>> For the purposes of this discussion, however, it's a big complex
>>> solution to a pretty simple problem, and the "weight" system still has
>>> to have special sauce added it to to handle this special case.
>>>
>>> Last, presuming for the moment that this goes forward as an
>>> option to bonding, I think this should be named something along the
>>> lines of "make_active" (or perhaps "make_active_once", but that's a bit
>>> long). The option has the effect of making the specified slave the
>>> active slave one time, then the option setting is cleared.
>
>Hi Jay,
>
> From what I understand from Jirka's needs, the exact expected behaviors are :
>
>1/ If a slave is active, keep it active, even if the primary comes back up.
>2/ If the current slave just failed, choose the new active slave, giving
>priority to the master.
>
>Selecting the active slave at startup (by using ifenslave -c or writing into
>/sys/class/net/bond0/bonding/active_slave) would solve 1, but not 2.
Yah, I had missed step 2. I'd still call it something other
than "lazy," though; "passive" sounds better to me.
>Also, I suggested to change 1 in this way :
>
>1/ If a slave is active, keep it active, even if the primary comes back up,
>*except if the speed of the primary is better than the speed of the active slave*.
>
>Thinking about all that, I start feeling that some sort of user space system to
>select the "best" slave would be better. If we can design a NETLINK interface to
>report events (slave up, slave down...) to user space, then any user space
>daemon would be able to tell bonding what to do. Only if no process register to
>receive those events would bonding use the normal slave selection rules.
This has been discussed more than once in the past, but hasn't
ever really gotten anywhere. I suspect the main impediment is the lack
of a suitable API.
>Designing such a NETLINK interface would replace my proposed weight option (at
>least for best slave selection in active-backup mode and for best aggregator
>selection in 802.3ad mode). It would also solve the problem reported by Jirka
>and so replace the proposed primary_lazy option.
Yes, a lot of the decision making at failover could be moved
into a user space daemon. The daemon, I think, should be optional; if
the basic selection policies are sufficient, then there's no need for a
trip to user space and back.
>Any way, NETLINK is something that is supposed to come into bonding at some
>times, because we know that the sysfs purists hate the sysfs bonding stuff and
>that NETLINK is the target to setup networking.
I'm not a big fan of the sysfs API, either; it seemed like a
good idea at the time. It's certainly better than ifenslave in terms of
features, but some of it is pretty convoluted, and there are things that
just can't be done from within sysfs.
I recall seeing a note from Stephen Hemminger not too long ago
(a month or two ago) that he was working on a netlink API for bonding,
but I don't know how far that ever got.
One quesiton is, if a netlink API is implemented, whether to
convert ifenslave, or deprecate ifenslave and put the various bonding
functions into ip.
If a netlink API is on the relatively near horizon (say, within
a few months), then I'm less inclined to put in the "lazy" option, since
it would just become baggage carried forward for the next several years
(until the sysfs API could be deprecated and removed).
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Sridhar Samudrala @ 2009-08-25 18:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Christoph Lameter, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <4A9415F5.6020006@gmail.com>
On Tue, 2009-08-25 at 18:48 +0200, Eric Dumazet wrote:
> Christoph Lameter a écrit :
> > On Tue, 25 Aug 2009, Eric Dumazet wrote:
> >
> >>> I read this just yesterday. IP_RECVERR means that the application wants to
> >>> see details on each loss. We just want some counters that give us accurate
> >>> statistics to gauge where packet loss is occurring. Applications are
> >>> usually not interested in tracking the fate of each packet.
> >> Yep, but IP_RECVERR also has the side effect of letting kernel returns -ENOBUFS error
> >> in sending and congestion, which was your initial point :)
> >
> > The initial point was that the SNMP counters are not updated if IP_RECVERR
> > is not set which is clearly a bug and your and my patch addresses that.
>
> Technically speaking, the send() syscall is in error. Frame is not sent, so
> there is no drop at all. Like trying to send() from a bad user buffer, or write()
> to a too big file...
>
>
> >
> > Then Sridhar noted that there are other tx drop counters. qdisc counters
> > are also not updated. Wish we would maintain tx drops counters there as
> > well so that we can track down which NIC drops it.
> >
> > Then came the wishlist of UDP counters for tx drops and socket based
> > tx_drop accounting for tuning and tracking down which app is sending
> > too fast .... ;-)
> >
> > The apps could be third party apps. Just need to be able to troubleshoot
> > packet loss.
> >
>
> Question is : should we just allow send() to return an error (-ENOBUF) regardless
> of IP_RECVERR being set or not ? I dont think it would be so bad after all.
> Most apps probably dont care, or already handle the error.
This patch would allow tracking drops at UDP level too via UDP_MIB_SNDBUFERRORS
that is incremented in udp_sendmsg(). Right now this happens only if IP_RECVERR
is set on the socket.
Ideally, it would be good to track the drops at qdisc, IP and UDP if a
packet is passed all the way to dev_queue_xmit() and then dropped.
Thanks
Sridhar
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 7d08210..afae0cb 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -1302,7 +1302,7 @@ int ip_push_pending_frames(struct sock *sk)
> err = ip_local_out(skb);
> if (err) {
> if (err > 0)
> - err = inet->recverr ? net_xmit_errno(err) : 0;
> + err = net_xmit_errno(err);
> if (err)
> goto error;
> }
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 87f8419..a7e5f93 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -1526,7 +1526,7 @@ int ip6_push_pending_frames(struct sock *sk)
> err = ip6_local_out(skb);
> if (err) {
> if (err > 0)
> - err = np->recverr ? net_xmit_errno(err) : 0;
> + err = net_xmit_errno(err);
> if (err)
> goto error;
> }
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Christoph Lameter @ 2009-08-25 17:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <4A941AA6.5070506@gmail.com>
Manpage for send says:
ENOBUFS
The output queue for a network interface was full. This generally indicates that the interface has stopped
sending, but may be caused by transient congestion. (Normally, this does not occur in Linux. Packets are just
silently dropped when a device queue overflows.)
So ENOBUFS seems to be designed to have the role that you envision. We
just need to remove the statement in (). Its still a change in behavior
though.
^ permalink raw reply
* Re: [PATCHv4 2/2] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-08-25 17:50 UTC (permalink / raw)
To: Rusty Russell
Cc: virtualization, netdev, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins
In-Reply-To: <200908252140.41295.rusty@rustcorp.com.au>
On Tue, Aug 25, 2009 at 09:40:40PM +0930, Rusty Russell wrote:
> > + u32 __user *featurep = argp;
> > + int __user *fdp = argp;
> > + u32 features;
> > + int fd, r;
> > + switch (ioctl) {
> > + case VHOST_NET_SET_SOCKET:
> > + r = get_user(fd, fdp);
> > + if (r < 0)
> > + return r;
> > + return vhost_net_set_socket(n, fd);
> > + case VHOST_GET_FEATURES:
> > + /* No features for now */
> > + features = 0;
> > + return put_user(features, featurep);
>
> We may well get more than 32 feature bits, at least for virtio_net, which will
> force us to do some trickery in virtio_pci.
Unlike PCI, if we ever run out of bits we can just
add FEATURES_EXTENDED ioctl, no need for trickery.
> I'd like to avoid that here,
> though it's kind of ugly. We'd need VHOST_GET_FEATURES (and ACK) to take a
> struct like:
>
> u32 feature_size;
> u32 features[];
Thinking about this proposal some more, how will the guest
determine the size to supply the GET_FEATURES ioctl?
Since we are a bit tight in 32 bit space already,
let's just use a 64 bit integer and be done with it?
Right?
--
MST
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Christoph Lameter @ 2009-08-25 17:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <4A941AA6.5070506@gmail.com>
On Tue, 25 Aug 2009, Eric Dumazet wrote:
> Christoph Lameter a ?crit :
> > On Tue, 25 Aug 2009, Eric Dumazet wrote:
> >
> >>> The initial point was that the SNMP counters are not updated if IP_RECVERR
> >>> is not set which is clearly a bug and your and my patch addresses that.
> >> Technically speaking, the send() syscall is in error. Frame is not sent, so
> >> there is no drop at all. Like trying to send() from a bad user buffer, or write()
> >> to a too big file...
> >
> > Frame is submitted to the IP layer which discards it. That is the
> > definition of an output discard.
> >
>
> Last patch accounts for this *error* AFAIK, or did I missed something ?
Right.
> >> Question is : should we just allow send() to return an error (-ENOBUF) regardless
> >> of IP_RECVERR being set or not ? I dont think it would be so bad after all.
> >> Most apps probably dont care, or already handle the error.
> >
> > Some applications will then start to fail because so far you can send with
> > impunity without getting errors. AFAICT IP_RECVERR was added to preserve
> > that behavior. Your patch is changing basic send() semantics.
>
> Sorry ???, I guess your machines have plenty available LOWMEM then, and kmalloc() never fail then...
Nope. Currently sendto() just drops the packet and returns success if the
TX ring is full. That can be done ad infinitum and at very high traffic
rates. We had one person here believing he could send 800k 300 byte
packets per second on a 1G wire.... ROTFL.
> basic send() semantics are respected.
basic send() semantics are changed by your patch. The 800k pps would no
longer work without sendto() returning errors.
^ permalink raw reply
* Re: [Bonding-devel] [PATCH net-next-2.6] bonding: introduce primary_lazy option
From: Nicolas de Pesloüan @ 2009-08-25 17:31 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Jiri Pirko, netdev, davem, bonding-devel
In-Reply-To: <20090825064351.GA3426@psychotron.englab.brq.redhat.com>
Jiri Pirko wrote:
> Mon, Aug 24, 2009 at 07:35:17PM CEST, fubar@us.ibm.com wrote:
>> I'm still unclear as to why it's better to add another special
>> case option to bonding instead of changing this in user space, other
>> than it'd be a change to user space (initscripts / sysconfig).
>>
>> The way I see it, this patch is adding a mechanism that says,
>> effectively, "make slave X the active slave, but do it only once."
>> There is already a way to do that in bonding (sysfs, as above, or
>> ifenslave -c); I am reluctant to add another without good reason.
>
> Hello Jay.
>
> As I already replied you once it's not only about selecting a slave at the
> start. It's also about following:
>
> Imagine you have bond with 3 slaves:
> eth0 eth1 eth2
> UP(curr) UP UP
> DOWN UP(curr) UP
> UP UP(curr) UP
> UP DOWN UP(curr)
>
> eth2 ends up being current active but we prefer eth0 (as primary interface).
> This is not desirable and is solved by primary_lazy option.
>
> Jirka
>
>> I'm not necessarily against the "weight" business in general.
>> For the purposes of this discussion, however, it's a big complex
>> solution to a pretty simple problem, and the "weight" system still has
>> to have special sauce added it to to handle this special case.
>>
>> Last, presuming for the moment that this goes forward as an
>> option to bonding, I think this should be named something along the
>> lines of "make_active" (or perhaps "make_active_once", but that's a bit
>> long). The option has the effect of making the specified slave the
>> active slave one time, then the option setting is cleared.
Hi Jay,
From what I understand from Jirka's needs, the exact expected behaviors are :
1/ If a slave is active, keep it active, even if the primary comes back up.
2/ If the current slave just failed, choose the new active slave, giving
priority to the master.
Selecting the active slave at startup (by using ifenslave -c or writing into
/sys/class/net/bond0/bonding/active_slave) would solve 1, but not 2.
Also, I suggested to change 1 in this way :
1/ If a slave is active, keep it active, even if the primary comes back up,
*except if the speed of the primary is better than the speed of the active slave*.
Thinking about all that, I start feeling that some sort of user space system to
select the "best" slave would be better. If we can design a NETLINK interface to
report events (slave up, slave down...) to user space, then any user space
daemon would be able to tell bonding what to do. Only if no process register to
receive those events would bonding use the normal slave selection rules.
Designing such a NETLINK interface would replace my proposed weight option (at
least for best slave selection in active-backup mode and for best aggregator
selection in 802.3ad mode). It would also solve the problem reported by Jirka
and so replace the proposed primary_lazy option.
Any way, NETLINK is something that is supposed to come into bonding at some
times, because we know that the sysfs purists hate the sysfs bonding stuff and
that NETLINK is the target to setup networking.
Any comments ?
Nicolas.
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Eric Dumazet @ 2009-08-25 17:08 UTC (permalink / raw)
To: Christoph Lameter
Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <alpine.DEB.1.10.0908251258000.26329@gentwo.org>
Christoph Lameter a écrit :
> On Tue, 25 Aug 2009, Eric Dumazet wrote:
>
>>> The initial point was that the SNMP counters are not updated if IP_RECVERR
>>> is not set which is clearly a bug and your and my patch addresses that.
>> Technically speaking, the send() syscall is in error. Frame is not sent, so
>> there is no drop at all. Like trying to send() from a bad user buffer, or write()
>> to a too big file...
>
> Frame is submitted to the IP layer which discards it. That is the
> definition of an output discard.
>
Last patch accounts for this *error* AFAIK, or did I missed something ?
>> Question is : should we just allow send() to return an error (-ENOBUF) regardless
>> of IP_RECVERR being set or not ? I dont think it would be so bad after all.
>> Most apps probably dont care, or already handle the error.
>
> Some applications will then start to fail because so far you can send with
> impunity without getting errors. AFAICT IP_RECVERR was added to preserve
> that behavior. Your patch is changing basic send() semantics.
Sorry ???, I guess your machines have plenty available LOWMEM then, and kmalloc() never fail then...
man P send
ENOBUFS
Insufficient resources were available in the system to perform the operation.
basic send() semantics are respected.
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Christoph Lameter @ 2009-08-25 17:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <4A9415F5.6020006@gmail.com>
On Tue, 25 Aug 2009, Eric Dumazet wrote:
> > The initial point was that the SNMP counters are not updated if IP_RECVERR
> > is not set which is clearly a bug and your and my patch addresses that.
>
> Technically speaking, the send() syscall is in error. Frame is not sent, so
> there is no drop at all. Like trying to send() from a bad user buffer, or write()
> to a too big file...
Frame is submitted to the IP layer which discards it. That is the
definition of an output discard.
> Question is : should we just allow send() to return an error (-ENOBUF) regardless
> of IP_RECVERR being set or not ? I dont think it would be so bad after all.
> Most apps probably dont care, or already handle the error.
Some applications will then start to fail because so far you can send with
impunity without getting errors. AFAICT IP_RECVERR was added to preserve
that behavior. Your patch is changing basic send() semantics.
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Eric Dumazet @ 2009-08-25 16:48 UTC (permalink / raw)
To: Christoph Lameter
Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <alpine.DEB.1.10.0908251230430.26329@gentwo.org>
Christoph Lameter a écrit :
> On Tue, 25 Aug 2009, Eric Dumazet wrote:
>
>>> I read this just yesterday. IP_RECVERR means that the application wants to
>>> see details on each loss. We just want some counters that give us accurate
>>> statistics to gauge where packet loss is occurring. Applications are
>>> usually not interested in tracking the fate of each packet.
>> Yep, but IP_RECVERR also has the side effect of letting kernel returns -ENOBUFS error
>> in sending and congestion, which was your initial point :)
>
> The initial point was that the SNMP counters are not updated if IP_RECVERR
> is not set which is clearly a bug and your and my patch addresses that.
Technically speaking, the send() syscall is in error. Frame is not sent, so
there is no drop at all. Like trying to send() from a bad user buffer, or write()
to a too big file...
>
> Then Sridhar noted that there are other tx drop counters. qdisc counters
> are also not updated. Wish we would maintain tx drops counters there as
> well so that we can track down which NIC drops it.
>
> Then came the wishlist of UDP counters for tx drops and socket based
> tx_drop accounting for tuning and tracking down which app is sending
> too fast .... ;-)
>
> The apps could be third party apps. Just need to be able to troubleshoot
> packet loss.
>
Question is : should we just allow send() to return an error (-ENOBUF) regardless
of IP_RECVERR being set or not ? I dont think it would be so bad after all.
Most apps probably dont care, or already handle the error.
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 7d08210..afae0cb 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1302,7 +1302,7 @@ int ip_push_pending_frames(struct sock *sk)
err = ip_local_out(skb);
if (err) {
if (err > 0)
- err = inet->recverr ? net_xmit_errno(err) : 0;
+ err = net_xmit_errno(err);
if (err)
goto error;
}
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 87f8419..a7e5f93 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1526,7 +1526,7 @@ int ip6_push_pending_frames(struct sock *sk)
err = ip6_local_out(skb);
if (err) {
if (err > 0)
- err = np->recverr ? net_xmit_errno(err) : 0;
+ err = net_xmit_errno(err);
if (err)
goto error;
}
^ permalink raw reply related
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Christoph Lameter @ 2009-08-25 16:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <4A9410E9.6090602@gmail.com>
On Tue, 25 Aug 2009, Eric Dumazet wrote:
> > I read this just yesterday. IP_RECVERR means that the application wants to
> > see details on each loss. We just want some counters that give us accurate
> > statistics to gauge where packet loss is occurring. Applications are
> > usually not interested in tracking the fate of each packet.
>
> Yep, but IP_RECVERR also has the side effect of letting kernel returns -ENOBUFS error
> in sending and congestion, which was your initial point :)
The initial point was that the SNMP counters are not updated if IP_RECVERR
is not set which is clearly a bug and your and my patch addresses that.
Then Sridhar noted that there are other tx drop counters. qdisc counters
are also not updated. Wish we would maintain tx drops counters there as
well so that we can track down which NIC drops it.
Then came the wishlist of UDP counters for tx drops and socket based
tx_drop accounting for tuning and tracking down which app is sending
too fast .... ;-)
The apps could be third party apps. Just need to be able to troubleshoot
packet loss.
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Eric Dumazet @ 2009-08-25 16:27 UTC (permalink / raw)
To: Christoph Lameter
Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <alpine.DEB.1.10.0908251203220.26329@gentwo.org>
Christoph Lameter a écrit :
> On Tue, 25 Aug 2009, Eric Dumazet wrote:
>
>> It wont be very nice, because it'll add yet another 32bits counter in each socket
>> structure, for a unlikely use. While rx_drops can happen if application is slow.
>
> tx_drops happen if the application sends too fast.
>
> TX drop tracking is important due to the braindamaged throttling logic
> during send. If SO_SNDBUF is less than what happens to fit in the TX ring then the
> application will be throttled and no packet loss happens. If SO_SNDBUF is
> set high then the TX ring will overflow and packets are dropped.
>
> We need some way to diagnose TX drops per socket as long as we have
> that mind boggling issue. TX drops means that one should reduce the size
> of the sendbuffer in order to get better throttling which reduces packet
> loss.
>
>> Also, tx_drops might be done later and not noticed.
>>
>> Please read this old (and usefull) thread, with Alexey words...
>>
>> http://oss.sgi.com/archives/netdev/2002-10/msg00612.html
>>
>> http://oss.sgi.com/archives/netdev/2002-10/msg00617.html
>>
>>
>> So I bet your best choice is to set IP_RECVERR, as mentioned in 2002 by Jamal and Alexey :)
>
> I read this just yesterday. IP_RECVERR means that the application wants to
> see details on each loss. We just want some counters that give us accurate
> statistics to gauge where packet loss is occurring. Applications are
> usually not interested in tracking the fate of each packet.
Yep, but IP_RECVERR also has the side effect of letting kernel returns -ENOBUFS error
in sending and congestion, which was your initial point :)
^ permalink raw reply
* Re: Kernel forwarding performance test regressions
From: Eric Dumazet @ 2009-08-25 16:25 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev, Robert Olsson
In-Reply-To: <20090825090459.3a821298@nehalam>
Stephen Hemminger a écrit :
> On Tue, 25 Aug 2009 11:47:58 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Thats strange, because at Giga flood level, we should be on NAPI mode,
>> ksoftirqd using 100% of one cpu. SMP affinities should not matter at all...
>
> The transmit completions are still kicking off some interrupts.
Ah, yes, in my case, as I use same device for transmit, I had no addtional interrupts
>
>>> * unidirectional numbers are 2X the bidirectional numbers:
>>> 2.6.26 goes from 20% to 40%
>>>
>>> * this is single stream (doesn't help/use multiqueue)
>>>
>>> * system loads iptables but does not use it, so each packet
>>> sees the overhead of null rules.
>>>
>>> So kernel 2.6.29 had an observable dip in performance
>>> which seems to be mostly recovered in 2.6.30.
>>>
>>> These are from our QA, not me so please don't ask me for
>>> "please rerun with XX enabled", go run the same test
>>> yourself with pktgen.
>>>
>> Unfortunatly I cannot reach line-rate with pktgen and small packets.
>> (Limit ~1012333pps 485Mb/sec on my test machine, 3GHz E5450 cpu)
>
> Things that help:
> * make sure flow control is off
it is
> * increase transmit ring size
already at max 511 value
> * sometimes tx IRQ coalescing
yep
> Using an old SMP Opteron box for pktgen right now.
>
>> It seems timestamping is too expensive on pktgen, even for "delay 0"
>> and only one device setup (next_to_run() doesnt have to select the 'best' device)
>> We probably can improve pktgen a litle bit, or use a faster timestamping...
>
> I have a patch that might help, I haven't tested it or used it.
> It converts the pktgen calls from gettimeofday to using sched_clock()
> this saves the math overhead since pktgen only cares about comparison
> and delta's. It also prevents problems with kernel deciding clock
> source is not stable. Still need to test and review this to make
> sure pktgen only uses value on same cpu.
Well, I tried using two adapters and got more bandwidth from same CPU0, so it seems
tg3 on my machine is not able to go past 1012333pps (and BTW, bnx2 is much
slower, I dont know why...)
Configuring /proc/net/pktgen/eth3 (tg3)
Configuring /proc/net/pktgen/eth1 (bnx2)
Running... ctrl^C to stop
Done
Params: count 100000 min_pkt_size: 56 max_pkt_size: 56
frags: 0 delay: 0 clone_skb: 1000 ifname: eth3
flows: 0 flowlen: 0
queue_map_min: 0 queue_map_max: 0
dst_min: 192.168.20.120 dst_max: 192.168.20.121
src_min: src_max:
src_mac: 00:1e:0b:92:78:51 dst_mac: 00:1f:29:6b:86:15
udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9
src_mac_count: 0 dst_mac_count: 0
Flags:
Current:
pkts-sofar: 100000 errors: 0
started: 1251217024743446us stopped: 1251217024842450us idle: 253us
seq_num: 100001 cur_dst_mac_offset: 0 cur_src_mac_offset: 0
cur_saddr: 0x200a8c0 cur_daddr: 0x7814a8c0
cur_udp_dst: 9 cur_udp_src: 9
cur_queue_map: 0
flows: 0
Result: OK: 99004(c98751+d253) usec, 100000 (56byte,0frags)
1010060pps 452Mb/sec (452506880bps) errors: 0
Params: count 100000 min_pkt_size: 56 max_pkt_size: 56
frags: 0 delay: 0 clone_skb: 1000 ifname: eth1
flows: 0 flowlen: 0
queue_map_min: 0 queue_map_max: 0
dst_min: 192.168.20.120 dst_max: 192.168.20.121
src_min: src_max:
src_mac: 00:1e:0b:ec:d3:d2 dst_mac: 00:1f:29:6b:86:15
udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9
src_mac_count: 0 dst_mac_count: 0
Flags:
Current:
pkts-sofar: 100000 errors: 0
started: 1251217024743445us stopped: 1251217024888749us idle: 329us
seq_num: 100001 cur_dst_mac_offset: 0 cur_src_mac_offset: 0
cur_saddr: 0x0 cur_daddr: 0x7814a8c0
cur_udp_dst: 9 cur_udp_src: 9
cur_queue_map: 0
flows: 0
Result: OK: 145304(c144975+d329) usec, 100000 (56byte,0frags)
688212pps 308Mb/sec (308318976bps) errors: 0
07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (rev 12)
Subsystem: Hewlett-Packard Company NC373i Integrated Multifunction Gigabit Server Adapter
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 34
Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
[virtual] Expansion ROM at d0000000 [disabled] [size=16K]
Capabilities: [40] PCI-X non-bridge device
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: bnx2 (eth1)
14:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5715S Gigabit Ethernet (rev a3)
Subsystem: Hewlett-Packard Company NC326m PCIe Dual Port Adapter
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 35
Memory at fdff0000 (64-bit, non-prefetchable) [size=64K]
Memory at fdfe0000 (64-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at d0200000 [disabled] [size=128K]
Capabilities: [40] PCI-X non-bridge device
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable+ Count=1/8 Maskable- 64bit+
Kernel driver in use: tg3
Kernel modules: tg3 (eth2, not used in my pktgen setup)
14:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5715S Gigabit Ethernet (rev a3)
Subsystem: Hewlett-Packard Company NC326m PCIe Dual Port Adapter
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 37
Memory at fdfd0000 (64-bit, non-prefetchable) [size=64K]
Memory at fdfc0000 (64-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at d0220000 [disabled] [size=128K]
Capabilities: [40] PCI-X non-bridge device
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable+ Count=1/8 Maskable- 64bit+
Kernel driver in use: tg3
Kernel modules: tg3 (eth3)
>
>> oprofile results on pktgen machine (linux 2.6.30.5) :
>> CPU: Core 2, speed 3000.08 MHz (estimated)
>> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
>> samples cum. samples % cum. % symbol name
>> 58137 58137 27.9549 27.9549 read_tsc
>> 51487 109624 24.7573 52.7122 pktgen_thread_worker
>> 33079 142703 15.9059 68.6181 getnstimeofday
>> 15694 158397 7.5464 76.1645 getCurUs
>> 11806 170203 5.6769 81.8413 do_gettimeofday
>> 5852 176055 2.8139 84.6553 kthread_should_stop
>> 5244 181299 2.5216 87.1768 kthread
>> 4181 185480 2.0104 89.1872 mwait_idle
>> 3837 189317 1.8450 91.0322 consume_skb
>> 2217 191534 1.0660 92.0983 skb_dma_unmap
>> 1599 193133 0.7689 92.8671 skb_dma_map
>> 1389 194522 0.6679 93.5350 local_bh_enable_ip
>> 1350 195872 0.6491 94.1842 nommu_map_page
>> 1086 196958 0.5222 94.7064 mix_pool_bytes_extract
>> 835 197793 0.4015 95.1079 apic_timer_interrupt
>> 774 198567 0.3722 95.4801 irq_entries_start
>> 450 199017 0.2164 95.6964 timer_stats_update_stats
>> 404 199421 0.1943 95.8907 scheduler_tick
>> 403 199824 0.1938 96.0845 find_busiest_group
>> 336 200160 0.1616 96.2460 local_bh_disable
>> 332 200492 0.1596 96.4057 rb_get_reader_page
>> 329 200821 0.1582 96.5639 ring_buffer_consume
>> 267 201088 0.1284 96.6923 add_timer_randomness
>
> The profile of pktgen will favor the tsc because it spins and looks
> at TSC during the spin. Not sure why tg3 driver overhead isn't showing up.
Sorry, for a strange reason, I have to load tg3 as a module (all other things are in static in vmlinux)
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Christoph Lameter @ 2009-08-25 16:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <4A940A10.60607@gmail.com>
On Tue, 25 Aug 2009, Eric Dumazet wrote:
> It wont be very nice, because it'll add yet another 32bits counter in each socket
> structure, for a unlikely use. While rx_drops can happen if application is slow.
tx_drops happen if the application sends too fast.
TX drop tracking is important due to the braindamaged throttling logic
during send. If SO_SNDBUF is less than what happens to fit in the TX ring then the
application will be throttled and no packet loss happens. If SO_SNDBUF is
set high then the TX ring will overflow and packets are dropped.
We need some way to diagnose TX drops per socket as long as we have
that mind boggling issue. TX drops means that one should reduce the size
of the sendbuffer in order to get better throttling which reduces packet
loss.
> Also, tx_drops might be done later and not noticed.
>
> Please read this old (and usefull) thread, with Alexey words...
>
> http://oss.sgi.com/archives/netdev/2002-10/msg00612.html
>
> http://oss.sgi.com/archives/netdev/2002-10/msg00617.html
>
>
> So I bet your best choice is to set IP_RECVERR, as mentioned in 2002 by Jamal and Alexey :)
I read this just yesterday. IP_RECVERR means that the application wants to
see details on each loss. We just want some counters that give us accurate
statistics to gauge where packet loss is occurring. Applications are
usually not interested in tracking the fate of each packet.
^ permalink raw reply
* Re: Kernel forwarding performance test regressions
From: Stephen Hemminger @ 2009-08-25 16:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Robert Olsson
In-Reply-To: <4A93B34E.1040100@gmail.com>
On Tue, 25 Aug 2009 11:47:58 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Stephen Hemminger a écrit :
> > Vyatta regularly runs RFC2544 performance tests as part of
> > the QA release regression tests. These tests are run using
> > a Spirent analyzer that sends packets at maximum rate and
> > measures the number of packets received.
> >
> > The interesting (worst case) number is the forwarding percentage for
> > minimum size Ethernet packets. For packets 1K and above all the packets
> > get through but for smaller sizes the system can't keep up.
> >
> > The hardware is Dell based
> > CPU is Intel Dual Core E2220 @ 2.40GHz (or 2.2GHz)
> > NIC's are internal Broadcom (tg3).
> >
> > Size 2.6.23 2.6.24 2.6.26 2.6.29 2.6.30
> > 64 14.% 20% 21% 17% 19%
> > 128 22 33 34 28 32
> > 256 37 52 58 49 54
> > 512 67 85 83 85 85
> > 1024 100 100 100 100 100
> > 1280 100 100 100 100 100
> > 1518 100 100 100 100 100
> >
> >
> > Some other details:
> > * Hardware change between 2.6.24 -> 2.6.26 numbers
> > went from 2.2 to 2.4Ghz
> >
> > * no SMP affinity (or irqbalance) is done,
> > numbers are significantly better if IRQ's are pinned.
> > 2.6.26 goes from 20% to 32%
>
> Thats strange, because at Giga flood level, we should be on NAPI mode,
> ksoftirqd using 100% of one cpu. SMP affinities should not matter at all...
The transmit completions are still kicking off some interrupts.
> >
> > * unidirectional numbers are 2X the bidirectional numbers:
> > 2.6.26 goes from 20% to 40%
> >
> > * this is single stream (doesn't help/use multiqueue)
> >
> > * system loads iptables but does not use it, so each packet
> > sees the overhead of null rules.
> >
> > So kernel 2.6.29 had an observable dip in performance
> > which seems to be mostly recovered in 2.6.30.
> >
> > These are from our QA, not me so please don't ask me for
> > "please rerun with XX enabled", go run the same test
> > yourself with pktgen.
> >
>
> Unfortunatly I cannot reach line-rate with pktgen and small packets.
> (Limit ~1012333pps 485Mb/sec on my test machine, 3GHz E5450 cpu)
Things that help:
* make sure flow control is off
* increase transmit ring size
* sometimes tx IRQ coalescing
Using an old SMP Opteron box for pktgen right now.
> It seems timestamping is too expensive on pktgen, even for "delay 0"
> and only one device setup (next_to_run() doesnt have to select the 'best' device)
> We probably can improve pktgen a litle bit, or use a faster timestamping...
I have a patch that might help, I haven't tested it or used it.
It converts the pktgen calls from gettimeofday to using sched_clock()
this saves the math overhead since pktgen only cares about comparison
and delta's. It also prevents problems with kernel deciding clock
source is not stable. Still need to test and review this to make
sure pktgen only uses value on same cpu.
> oprofile results on pktgen machine (linux 2.6.30.5) :
> CPU: Core 2, speed 3000.08 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
> samples cum. samples % cum. % symbol name
> 58137 58137 27.9549 27.9549 read_tsc
> 51487 109624 24.7573 52.7122 pktgen_thread_worker
> 33079 142703 15.9059 68.6181 getnstimeofday
> 15694 158397 7.5464 76.1645 getCurUs
> 11806 170203 5.6769 81.8413 do_gettimeofday
> 5852 176055 2.8139 84.6553 kthread_should_stop
> 5244 181299 2.5216 87.1768 kthread
> 4181 185480 2.0104 89.1872 mwait_idle
> 3837 189317 1.8450 91.0322 consume_skb
> 2217 191534 1.0660 92.0983 skb_dma_unmap
> 1599 193133 0.7689 92.8671 skb_dma_map
> 1389 194522 0.6679 93.5350 local_bh_enable_ip
> 1350 195872 0.6491 94.1842 nommu_map_page
> 1086 196958 0.5222 94.7064 mix_pool_bytes_extract
> 835 197793 0.4015 95.1079 apic_timer_interrupt
> 774 198567 0.3722 95.4801 irq_entries_start
> 450 199017 0.2164 95.6964 timer_stats_update_stats
> 404 199421 0.1943 95.8907 scheduler_tick
> 403 199824 0.1938 96.0845 find_busiest_group
> 336 200160 0.1616 96.2460 local_bh_disable
> 332 200492 0.1596 96.4057 rb_get_reader_page
> 329 200821 0.1582 96.5639 ring_buffer_consume
> 267 201088 0.1284 96.6923 add_timer_randomness
The profile of pktgen will favor the tsc because it spins and looks
at TSC during the spin. Not sure why tg3 driver overhead isn't showing up.
> I experiment 0.1% drops around 635085pps 284Mb/sec, on my dev machine
> (using vlan and bonding, bi-directional , output device = input device)
>
> Some notes :
>
> - Small packets hit the copybreak (mis)feature (that tg3 and other drivers use),
> and we know this slow down forwarding. No real differences on small
> packets anyway since we need to read packet to process it (one cache line)
Good point: we disable copybreak on some devices (with modprobe options) in
the Vyatta distro.
> - neigh_resolve_output() has a cost because
> of atomic ops of read_lock_bh(&neigh->lock)/read_unlock_bh(&neigh->lock)
> This might be a candidate for RCU conversion ?
yes
> - ip_rt_send_redirect() is quite expensive, even if send_redirect is set to 0, because
> of in_dev_get()/in_dev_put() (two atomic ops that could be avoided : I submitted a patch)
>
--
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Eric Dumazet @ 2009-08-25 15:58 UTC (permalink / raw)
To: Christoph Lameter
Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <alpine.DEB.1.10.0908251135380.26329@gentwo.org>
Christoph Lameter a écrit :
> On Tue, 25 Aug 2009, Eric Dumazet wrote:
>
>> Christoph Lameter a ?crit :
>>> On Tue, 25 Aug 2009, Eric Dumazet wrote:
>>>
>>>> Please hold on, I would like to fully understand what's happening,
>>>> and test the patch :)
>>> Ok. It would be good if the drops would also be somehow noted by the UDP
>>> subsystem (one should see something with netstat -su) and may be even the
>>> socket. I see a drops column in /proc/net/udp. rx_drops, tx_drops?
>> This /proc/net/udp column is for rx_drops currently and was recently added...
>
> So lets rename it to rx_drops and then add tx_drops?
>
It wont be very nice, because it'll add yet another 32bits counter in each socket
structure, for a unlikely use. While rx_drops can happen if application is slow.
Also, tx_drops might be done later and not noticed.
Please read this old (and usefull) thread, with Alexey words...
http://oss.sgi.com/archives/netdev/2002-10/msg00612.html
http://oss.sgi.com/archives/netdev/2002-10/msg00617.html
So I bet your best choice is to set IP_RECVERR, as mentioned in 2002 by Jamal and Alexey :)
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Christoph Lameter @ 2009-08-25 15:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <4A9403F0.2060301@gmail.com>
On Tue, 25 Aug 2009, Eric Dumazet wrote:
> Christoph Lameter a ?crit :
> > On Tue, 25 Aug 2009, Eric Dumazet wrote:
> >
> >> Please hold on, I would like to fully understand what's happening,
> >> and test the patch :)
> >
> > Ok. It would be good if the drops would also be somehow noted by the UDP
> > subsystem (one should see something with netstat -su) and may be even the
> > socket. I see a drops column in /proc/net/udp. rx_drops, tx_drops?
>
> This /proc/net/udp column is for rx_drops currently and was recently added...
So lets rename it to rx_drops and then add tx_drops?
^ permalink raw reply
* Re: UDP multicast packet loss not reported if TX ring overrun?
From: Eric Dumazet @ 2009-08-25 15:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Sridhar Samudrala, Nivedita Singhvi, netdev, David S. Miller
In-Reply-To: <alpine.DEB.1.10.0908250958540.28552@gentwo.org>
Christoph Lameter a écrit :
> On Tue, 25 Aug 2009, Eric Dumazet wrote:
>
>> Please hold on, I would like to fully understand what's happening,
>> and test the patch :)
>
> Ok. It would be good if the drops would also be somehow noted by the UDP
> subsystem (one should see something with netstat -su) and may be even the
> socket. I see a drops column in /proc/net/udp. rx_drops, tx_drops?
This /proc/net/udp column is for rx_drops currently and was recently added...
^ permalink raw reply
* [PATCH 26/26] et131x: clean up MP_FLAG macros
From: Alan Cox @ 2009-08-25 15:01 UTC (permalink / raw)
To: greg, netdev
In-Reply-To: <20090825145619.16176.68780.stgit@localhost.localdomain>
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/staging/et131x/et1310_mac.c | 2 +-
drivers/staging/et131x/et1310_phy.c | 8 +++-----
drivers/staging/et131x/et1310_pm.c | 4 ++--
drivers/staging/et131x/et1310_rx.c | 12 ++++++------
drivers/staging/et131x/et1310_tx.c | 8 ++++----
drivers/staging/et131x/et131x_adapter.h | 13 -------------
drivers/staging/et131x/et131x_initpci.c | 2 +-
drivers/staging/et131x/et131x_netdev.c | 14 +++++++-------
8 files changed, 24 insertions(+), 39 deletions(-)
diff --git a/drivers/staging/et131x/et1310_mac.c b/drivers/staging/et131x/et1310_mac.c
index a27d815..c94d661 100644
--- a/drivers/staging/et131x/et1310_mac.c
+++ b/drivers/staging/et131x/et1310_mac.c
@@ -272,7 +272,7 @@ void ConfigMACRegs2(struct et131x_adapter *etdev)
writel(ctl.value, &etdev->regs->txmac.ctl.value);
/* Ready to start the RXDMA/TXDMA engine */
- if (!MP_TEST_FLAG(etdev, fMP_ADAPTER_LOWER_POWER)) {
+ if (etdev->Flags & fMP_ADAPTER_LOWER_POWER) {
et131x_rx_dma_enable(etdev);
et131x_tx_dma_enable(etdev);
} else {
diff --git a/drivers/staging/et131x/et1310_phy.c b/drivers/staging/et131x/et1310_phy.c
index 19ffb65..f856381 100644
--- a/drivers/staging/et131x/et1310_phy.c
+++ b/drivers/staging/et131x/et1310_phy.c
@@ -498,7 +498,7 @@ void et131x_Mii_check(struct et131x_adapter *etdev,
spin_lock_irqsave(&etdev->Lock, flags);
etdev->MediaState = NETIF_STATUS_MEDIA_CONNECT;
- MP_CLEAR_FLAG(etdev, fMP_ADAPTER_LINK_DETECTION);
+ etdev->Flags &= ~fMP_ADAPTER_LINK_DETECTION);
spin_unlock_irqrestore(&etdev->Lock, flags);
@@ -529,10 +529,8 @@ void et131x_Mii_check(struct et131x_adapter *etdev,
* Timer expires, we can report disconnected (handled
* in the LinkDetectionDPC).
*/
- if ((MP_IS_FLAG_CLEAR
- (etdev, fMP_ADAPTER_LINK_DETECTION))
- || (etdev->MediaState ==
- NETIF_STATUS_MEDIA_DISCONNECT)) {
+ if (!(etdev->Flags & fMP_ADAPTER_LINK_DETECTION) ||
+ (etdev->MediaState == NETIF_STATUS_MEDIA_DISCONNECT)) {
spin_lock_irqsave(&etdev->Lock, flags);
etdev->MediaState =
NETIF_STATUS_MEDIA_DISCONNECT;
diff --git a/drivers/staging/et131x/et1310_pm.c b/drivers/staging/et131x/et1310_pm.c
index ea186a8..f4c942c 100644
--- a/drivers/staging/et131x/et1310_pm.c
+++ b/drivers/staging/et131x/et1310_pm.c
@@ -134,7 +134,7 @@ void EnablePhyComa(struct et131x_adapter *etdev)
/* Stop sending packets. */
spin_lock_irqsave(&etdev->SendHWLock, flags);
- MP_SET_FLAG(etdev, fMP_ADAPTER_LOWER_POWER);
+ etdev->Flags |= fMP_ADAPTER_LOWER_POWER;
spin_unlock_irqrestore(&etdev->SendHWLock, flags);
/* Wait for outstanding Receive packets */
@@ -189,7 +189,7 @@ void DisablePhyComa(struct et131x_adapter *etdev)
et131x_adapter_setup(etdev);
/* Allow Tx to restart */
- MP_CLEAR_FLAG(etdev, fMP_ADAPTER_LOWER_POWER);
+ etdev->Flags &= ~fMP_ADAPTER_LOWER_POWER;
/* Need to re-enable Rx. */
et131x_rx_dma_enable(etdev);
diff --git a/drivers/staging/et131x/et1310_rx.c b/drivers/staging/et131x/et1310_rx.c
index 757a8cd..54a7ecf 100644
--- a/drivers/staging/et131x/et1310_rx.c
+++ b/drivers/staging/et131x/et1310_rx.c
@@ -415,7 +415,7 @@ int et131x_rx_dma_memory_alloc(struct et131x_adapter *adapter)
SLAB_HWCACHE_ALIGN,
NULL);
- MP_SET_FLAG(adapter, fMP_ADAPTER_RECV_LOOKASIDE);
+ adapter->Flags |= fMP_ADAPTER_RECV_LOOKASIDE;
/* The RFDs are going to be put on lists later on, so initialize the
* lists now.
@@ -569,9 +569,9 @@ void et131x_rx_dma_memory_free(struct et131x_adapter *adapter)
/* Free receive packet pool */
/* Destroy the lookaside (RFD) pool */
- if (MP_TEST_FLAG(adapter, fMP_ADAPTER_RECV_LOOKASIDE)) {
+ if (adapter->Flags & fMP_ADAPTER_RECV_LOOKASIDE) {
kmem_cache_destroy(rx_ring->RecvLookaside);
- MP_CLEAR_FLAG(adapter, fMP_ADAPTER_RECV_LOOKASIDE);
+ adapter->Flags &= ~fMP_ADAPTER_RECV_LOOKASIDE;
}
/* Free the FBR Lookup Table */
@@ -1223,9 +1223,9 @@ void et131x_handle_recv_interrupt(struct et131x_adapter *etdev)
* If length is zero, return the RFD in order to advance the
* Free buffer ring.
*/
- if ((!etdev->PacketFilter) ||
- (!MP_LINK_DETECTED(etdev)) ||
- (pMpRfd->PacketSize == 0)) {
+ if (!etdev->PacketFilter ||
+ !(etdev->Flags & fMP_ADAPTER_LINK_DETECTION) ||
+ pMpRfd->PacketSize == 0) {
continue;
}
diff --git a/drivers/staging/et131x/et1310_tx.c b/drivers/staging/et131x/et1310_tx.c
index dd79975..4a0108f 100644
--- a/drivers/staging/et131x/et1310_tx.c
+++ b/drivers/staging/et131x/et1310_tx.c
@@ -510,9 +510,9 @@ static int et131x_send_packet(struct sk_buff *skb,
if ((shbufva[0] == 0xffff) &&
(shbufva[1] == 0xffff) && (shbufva[2] == 0xffff)) {
- MP_SET_FLAG(pMpTcb, fMP_DEST_BROAD);
+ pMpTcb->Flags |= fMP_DEST_BROAD;
} else if ((shbufva[0] & 0x3) == 0x0001) {
- MP_SET_FLAG(pMpTcb, fMP_DEST_MULTI);
+ pMpTcb->Flags |= fMP_DEST_MULTI;
}
}
@@ -1232,9 +1232,9 @@ inline void et131x_free_send_packet(struct et131x_adapter *etdev,
TX_DESC_ENTRY_t *desc = NULL;
struct net_device_stats *stats = &etdev->net_stats;
- if (MP_TEST_FLAG(pMpTcb, fMP_DEST_BROAD))
+ if (pMpTcb->Flags & fMP_DEST_BROAD))
atomic_inc(&etdev->Stats.brdcstxmt);
- else if (MP_TEST_FLAG(pMpTcb, fMP_DEST_MULTI))
+ else if (pMpTcb->Flags & fMP_DEST_MULTI))
atomic_inc(&etdev->Stats.multixmt);
else
atomic_inc(&etdev->Stats.unixmt);
diff --git a/drivers/staging/et131x/et131x_adapter.h b/drivers/staging/et131x/et131x_adapter.h
index 04bb603..05388eb 100644
--- a/drivers/staging/et131x/et131x_adapter.h
+++ b/drivers/staging/et131x/et131x_adapter.h
@@ -100,24 +100,11 @@
#define LO_MARK_PERCENT_FOR_PSR 15
#define LO_MARK_PERCENT_FOR_RX 15
-/* Macros for flag and ref count operations */
-#define MP_SET_FLAG(_M, _F) ((_M)->Flags |= (_F))
-#define MP_CLEAR_FLAG(_M, _F) ((_M)->Flags &= ~(_F))
-#define MP_CLEAR_FLAGS(_M) ((_M)->Flags = 0)
-#define MP_TEST_FLAG(_M, _F) (((_M)->Flags & (_F)) != 0)
-#define MP_TEST_FLAGS(_M, _F) (((_M)->Flags & (_F)) == (_F))
-#define MP_IS_FLAG_CLEAR(_M, _F) (((_M)->Flags & (_F)) == 0)
-
/* Macros specific to the private adapter structure */
#define MP_TCB_RESOURCES_AVAILABLE(_M) ((_M)->TxRing.nBusySend < NUM_TCB)
#define MP_TCB_RESOURCES_NOT_AVAILABLE(_M) ((_M)->TxRing.nBusySend >= NUM_TCB)
#define MP_SHOULD_FAIL_SEND(_M) ((_M)->Flags & fMP_ADAPTER_FAIL_SEND_MASK)
-#define MP_IS_NOT_READY(_M) ((_M)->Flags & fMP_ADAPTER_NOT_READY_MASK)
-#define MP_IS_READY(_M) (!((_M)->Flags & fMP_ADAPTER_NOT_READY_MASK))
-
-#define MP_HAS_CABLE(_M) (!((_M)->Flags & fMP_ADAPTER_NO_CABLE))
-#define MP_LINK_DETECTED(_M) (!((_M)->Flags & fMP_ADAPTER_LINK_DETECTION))
/* Counters for error rate monitoring */
typedef struct _MP_ERR_COUNTERS {
diff --git a/drivers/staging/et131x/et131x_initpci.c b/drivers/staging/et131x/et131x_initpci.c
index d7a1b34..0a3464a 100644
--- a/drivers/staging/et131x/et131x_initpci.c
+++ b/drivers/staging/et131x/et131x_initpci.c
@@ -523,7 +523,7 @@ void et131x_link_detection_handler(unsigned long data)
spin_lock_irqsave(&etdev->Lock, flags);
etdev->MediaState = NETIF_STATUS_MEDIA_DISCONNECT;
- MP_CLEAR_FLAG(etdev, fMP_ADAPTER_LINK_DETECTION);
+ etdev->Flags &= ~fMP_ADAPTER_LINK_DETECTION;
spin_unlock_irqrestore(&etdev->Lock, flags);
diff --git a/drivers/staging/et131x/et131x_netdev.c b/drivers/staging/et131x/et131x_netdev.c
index 62febe9..2a4b9ac 100644
--- a/drivers/staging/et131x/et131x_netdev.c
+++ b/drivers/staging/et131x/et131x_netdev.c
@@ -253,7 +253,7 @@ int et131x_open(struct net_device *netdev)
/* Enable device interrupts */
et131x_enable_interrupts(adapter);
- MP_SET_FLAG(adapter, fMP_ADAPTER_INTERRUPT_IN_USE);
+ adapter->Flags |= fMP_ADAPTER_INTERRUPT_IN_USE;
/* We're ready to move some data, so start the queue */
netif_start_queue(netdev);
@@ -285,7 +285,7 @@ int et131x_close(struct net_device *netdev)
et131x_disable_interrupts(adapter);
/* Deregistering ISR */
- MP_CLEAR_FLAG(adapter, fMP_ADAPTER_INTERRUPT_IN_USE);
+ adapter->Flags &= ~fMP_ADAPTER_INTERRUPT_IN_USE;
DBG_TRACE(et131x_dbginfo, "Deregistering ISR...\n");
free_irq(netdev->irq, netdev);
@@ -615,7 +615,7 @@ void et131x_tx_timeout(struct net_device *netdev)
DBG_WARNING(et131x_dbginfo, "TX TIMEOUT\n");
/* Just skip this part if the adapter is doing link detection */
- if (MP_TEST_FLAG(etdev, fMP_ADAPTER_LINK_DETECTION)) {
+ if (etdev->Flags & fMP_ADAPTER_LINK_DETECTION) {
DBG_ERROR(et131x_dbginfo, "Still doing link detection\n");
return;
}
@@ -623,13 +623,13 @@ void et131x_tx_timeout(struct net_device *netdev)
/* Any nonrecoverable hardware error?
* Checks adapter->flags for any failure in phy reading
*/
- if (MP_TEST_FLAG(etdev, fMP_ADAPTER_NON_RECOVER_ERROR)) {
+ if (etdev->Flags & fMP_ADAPTER_NON_RECOVER_ERROR) {
DBG_WARNING(et131x_dbginfo, "Non recoverable error - remove\n");
return;
}
/* Hardware failure? */
- if (MP_TEST_FLAG(etdev, fMP_ADAPTER_HARDWARE_ERROR)) {
+ if (etdev->Flags & fMP_ADAPTER_HARDWARE_ERROR) {
DBG_WARNING(et131x_dbginfo, "hardware error - reset\n");
return;
}
@@ -751,7 +751,7 @@ int et131x_change_mtu(struct net_device *netdev, int new_mtu)
et131x_adapter_setup(adapter);
/* Enable interrupts */
- if (MP_TEST_FLAG(adapter, fMP_ADAPTER_INTERRUPT_IN_USE))
+ if (adapter->Flags & fMP_ADAPTER_INTERRUPT_IN_USE)
et131x_enable_interrupts(adapter);
/* Restart the Tx and Rx DMA engines */
@@ -847,7 +847,7 @@ int et131x_set_mac_addr(struct net_device *netdev, void *new_mac)
et131x_adapter_setup(adapter);
/* Enable interrupts */
- if (MP_TEST_FLAG(adapter, fMP_ADAPTER_INTERRUPT_IN_USE))
+ if (adapter->Flags & fMP_ADAPTER_INTERRUPT_IN_USE)
et131x_enable_interrupts(adapter);
/* Restart the Tx and Rx DMA engines */
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox