* Re: [PATCH 0/3] r8169 driver fixes
From: David Miller @ 2011-02-03 23:18 UTC (permalink / raw)
To: romieu; +Cc: netdev, ivecera, hayeswang
In-Reply-To: <20110203172557.GA9024@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 3 Feb 2011 18:26:11 +0100
> The following series includes Ivan Rx fifo overflow fix and similar
> changes I did after testing with various 8168 chipsets.
>
> The series is available as
> git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git r8169-davem
These are bug fixes, but this GIT branch is based upon net-next-2.6,
what is the intent here?
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Hagen Paul Pfeifer @ 2011-02-03 22:55 UTC (permalink / raw)
To: H.K. Jerry Chu; +Cc: David Miller, netdev, dccp, therbert
In-Reply-To: <AANLkTimWHAz0SX_u42guHp2KNyQESsH6ysNwRoe7ZVJ=@mail.gmail.com>
* H.K. Jerry Chu | 2011-02-03 13:17:19 [-0800]:
>> to setup a ns-2 environment but due to lack of time I am a little bit
>> behind schedule. Anyway, why not make this a tunable per route knob so that
>> it is easier to fix things, e.g. set IW back to 3.
>
>You've seemed to get this backwards. Shouldn't we set the default for the normal
>cases and leave the corner cases to the initcwnd and initrwnd knobs to cover?
Yes Jerry, I phrase this a little bit abstruse. Apply David patch and use per
route options to reduce the IW if some curious behavior appear.
It seems the time is come to increase the IW. ;-)
Hagen
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Ilpo Järvinen @ 2011-02-03 22:43 UTC (permalink / raw)
To: David Miller; +Cc: Netdev, therbert, H.K. Jerry Chu
In-Reply-To: <20110202.170750.229739784.davem@davemloft.net>
It would perhaps be useful to change receiver advertized window to include
some extra segs initially. It should be >= IW + peer's dupThresh-1 as
otherwise limited transmit won't work for the initial window because we
won't open more receiver window with dupacks (IIRC, I suppose Jerry might
be able to correct me right away if I'm wrong and we open window with
dupacks too?). I think initial receiver window code used to have some
surplus but it was broken by the rfc3390-func conversion (against my
advice on how to do the conversion).
--
i.
^ permalink raw reply
* Re: sending IP pkgs form user space on a specific interface?
From: Ben Greear @ 2011-02-03 22:41 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF72446498.F31B6A78-ONC125782C.00794F9B-C125782C.007A2D64@transmode.se>
On 02/03/2011 02:14 PM, Joakim Tjernlund wrote:
> Ben Greear<greearb@candelatech.com> wrote on 2011/02/03 23:03:53:
>> From: Ben Greear<greearb@candelatech.com>
>> To: Joakim Tjernlund<joakim.tjernlund@transmode.se>
>> Cc: netdev@vger.kernel.org
>> Date: 2011/02/03 23:03
>> Subject: Re: sending IP pkgs form user space on a specific interface?
>>
>> On 02/03/2011 01:55 PM, Joakim Tjernlund wrote:
>>>
>>> Is there a way to specify what I/F a IP pkg should be sent
>>> out on?
>>>
>>> I have multiple ppp I/Fs with the same local and remote address
>>> and I need to specify what interface to send OSPF protocol
>>> messages to.
>>
>> Check out SO_BINDTODEVICE.
>
> Thanks, can do setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, ..) for
> each I/Fs I need tx pkgs over?
> How do I unbind to any I/F?
>
> If possible, I would like to specify the I/F in the pkg overhead.
Man-pages and google should find those answers.
You could put my name in your search as well, if you want..I know I've
posted sample code in the past to some mailing list or another.
Thanks,
Ben
>
> Jocke
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: David Miller @ 2011-02-03 22:21 UTC (permalink / raw)
To: fleitner; +Cc: netdev
In-Reply-To: <1296758717-18406-1-git-send-email-fleitner@redhat.com>
From: Flavio Leitner <fleitner@redhat.com>
Date: Thu, 3 Feb 2011 16:45:17 -0200
> It's possible to trigger a crash if one CPU is opening
> the device while another CPU gets its statistics.
>
> It happens because niu_alloc_channels() called from
> niu_open() sets num_tx/rx_rings before allocating the
> ring, so the other thread crashes when accessing
> np->tx_rings[i].tx_packets at niu_get_tx_stats().
>
> Signed-off-by: Flavio Leitner <fleitner@redhat.com>
...
> Compile tested only because I don't have the hardware.
I'll apply this and give it a quick test, thanks.
Can you have the person who reported this crash to you test the patch
out at least? That's how you learned about this problem, right,
someone else hit the crash?
In such cases I'd really appreciate it if you got positive testing
feedback from the reporter before posting the patch.
Longer term a better way to fix this is to RCU free the ring data
structures, and use a quick NULL test at the top of the get stats
implementation.
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Linus Torvalds @ 2011-02-03 22:19 UTC (permalink / raw)
To: Carlos Mafra, Keith Packard, Dave Airlie
Cc: Rafael J. Wysocki, Takashi Iwai, Linux Kernel Mailing List,
Maciej Rutecki, Florian Mickler, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <AANLkTi=7EOih=fY5FCvhQbewSc=3a49cYVaKJRWM+-3d@mail.gmail.com>
On Thu, Feb 3, 2011 at 2:10 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Maybe the right thing to do is to set it to 'unknown', something like this.
>
> TOTALLY UNTESTED!
Doing some grepping and "git blame", I found this: commit 032d2a0d068
("drm/i915: Prevent double dpms on") which took a very similar
approach, except it just uses "-1" directly instead of introducing
that DRM_MODE_DPMS_UNKNOWN concept.
So I suspect that my patch is going in the right direction, and
judging by the comments in that commit, we probably should do this
correctly at the dri level rather than have drivers see those stupid
"let's set dpms to the state that it was already in". But that very
much does require that kind of "UNKNOWN" state option.
So maybe we can get that patch tested (and acked if it works)? Carlos, Takashi?
Linus
^ permalink raw reply
* Re: sending IP pkgs form user space on a specific interface?
From: Joakim Tjernlund @ 2011-02-03 22:14 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4D4B2649.40404@candelatech.com>
Ben Greear <greearb@candelatech.com> wrote on 2011/02/03 23:03:53:
> From: Ben Greear <greearb@candelatech.com>
> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> Cc: netdev@vger.kernel.org
> Date: 2011/02/03 23:03
> Subject: Re: sending IP pkgs form user space on a specific interface?
>
> On 02/03/2011 01:55 PM, Joakim Tjernlund wrote:
> >
> > Is there a way to specify what I/F a IP pkg should be sent
> > out on?
> >
> > I have multiple ppp I/Fs with the same local and remote address
> > and I need to specify what interface to send OSPF protocol
> > messages to.
>
> Check out SO_BINDTODEVICE.
Thanks, can do setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, ..) for
each I/Fs I need tx pkgs over?
How do I unbind to any I/F?
If possible, I would like to specify the I/F in the pkg overhead.
Jocke
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Linus Torvalds @ 2011-02-03 22:10 UTC (permalink / raw)
To: Carlos Mafra, Keith Packard, Dave Airlie
Cc: Rafael J. Wysocki, Takashi Iwai, Linux Kernel Mailing List,
Maciej Rutecki, Florian Mickler, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <AANLkTi=suS1VDL=6EtT0D2=0c1DWwxdwZBBv=-BySNX-@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra <crmafra2@gmail.com> wrote:
>>
>> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
>> post-2.6.36 regressions for further tracking.
>
> I also tested on 2.6.38-rc3+ now and the issue is not solved,
> just like Takashi expected.
Hmm. That commit (bf9dc102e284) still reverts cleanly.
Keith, Dave, should we just revert it? It's definitely a regression,
and we do _not_ allow "fixes" to one thing that just causes a
regression to another.
Quite frankly, I think it's totally wrong to just blindly set DPMS
status to ON like that. It's as wrong as it was to leave it off, and
the regressions reported are basically mirror images of the exact same
bug that that commit tried to fix.
IOW, the commit message says:
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
but setting it to ON doesn't actually _fix_ anything, because you just
get the exact same issue in reverse, ie you just get
.. and a future mode set that ENables the specified connector will
not turn the connector ON.
instead. Which is exactly what Carlos and Takashi are reporting.
Maybe the right thing to do is to set it to 'unknown', something like this.
TOTALLY UNTESTED!
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1334 bytes --]
drivers/gpu/drm/drm_crtc_helper.c | 6 +++---
include/drm/drm_mode.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 952b3d4..7f585ed 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -681,11 +681,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
goto fail;
}
}
- DRM_DEBUG_KMS("Setting connector DPMS state to on\n");
+ DRM_DEBUG_KMS("Setting connector DPMS state to 'unknown'\n");
for (i = 0; i < set->num_connectors; i++) {
- DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS on\n", set->connectors[i]->base.id,
+ DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS 'unknown'\n", set->connectors[i]->base.id,
drm_get_connector_name(set->connectors[i]));
- set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
+ set->connectors[i]->dpms = DRM_MODE_DPMS_UNKNOWN;
}
kfree(save_connectors);
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 0fc7397..4b5144c 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -59,6 +59,7 @@
/* DPMS flags */
/* bit compatible with the xorg definitions. */
+#define DRM_MODE_DPMS_UNKNOWN (-1)
#define DRM_MODE_DPMS_ON 0
#define DRM_MODE_DPMS_STANDBY 1
#define DRM_MODE_DPMS_SUSPEND 2
^ permalink raw reply related
* Re: sending IP pkgs form user space on a specific interface?
From: Ben Greear @ 2011-02-03 22:03 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OFAEE2A3EA.1C3F2C8A-ONC125782C.0077F327-C125782C.007872C6@transmode.se>
On 02/03/2011 01:55 PM, Joakim Tjernlund wrote:
>
> Is there a way to specify what I/F a IP pkg should be sent
> out on?
>
> I have multiple ppp I/Fs with the same local and remote address
> and I need to specify what interface to send OSPF protocol
> messages to.
Check out SO_BINDTODEVICE.
Thanks,
Ben
>
> Jocke
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* sending IP pkgs form user space on a specific interface?
From: Joakim Tjernlund @ 2011-02-03 21:55 UTC (permalink / raw)
To: netdev
Is there a way to specify what I/F a IP pkg should be sent
out on?
I have multiple ppp I/Fs with the same local and remote address
and I need to specify what interface to send OSPF protocol
messages to.
Jocke
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Leandro Melo de Sales @ 2011-02-03 22:00 UTC (permalink / raw)
To: netdev, dccp
In-Reply-To: <AANLkTi=z-1-=R4X6hxs738jMEdYwfMPBFq9Ss-JwKCy3@mail.gmail.com>
Just forwarding my reply to the list netdev and dccp lists, the text
was in HTML format and Majordomo rejected it...
---------- Forwarded message ----------
From: Leandro Melo de Sales <leandroal@gmail.com>
Date: Thu, Feb 3, 2011 at 2:48 PM
Subject: Re: [PATCH] tcp: Increase the initial congestion window to 10.
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, dccp@vger.kernel.org, therbert@google.com,
Angelo Perkusich <Angelo.Perkusich@gmail.com>, Hyggo Almeida
<hyggo.almeida@gmail.com>
On Wed, Feb 2, 2011 at 10:07 PM, David Miller <davem@davemloft.net> wrote:
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>
> I've left the DCCP code to keep using RFC3390 logic, if they
> wish to adopt this change in their code they can do so by
> simply deleting the rfc33390_bytes_to_packets() function and
> using TCP_INIT_CWND in their assignment.
>
> include/net/tcp.h | 12 +++---------
> net/dccp/ccids/ccid2.c | 9 +++++++++
> net/ipv4/tcp_input.c | 2 +-
> 3 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 9179111..7118668 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -196,6 +196,9 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
> /* TCP thin-stream limits */
> #define TCP_THIN_LINEAR_RETRIES 6 /* After 6 linear retries, do exp. backoff */
>
> +/* TCP initial congestion window */
> +#define TCP_INIT_CWND 10
> +
> extern struct inet_timewait_death_row tcp_death_row;
>
> /* sysctl variables for tcp */
> @@ -799,15 +802,6 @@ static inline __u32 tcp_current_ssthresh(const struct sock *sk)
> /* Use define here intentionally to get WARN_ON location shown at the caller */
> #define tcp_verify_left_out(tp) WARN_ON(tcp_left_out(tp) > tp->packets_out)
>
> -/*
> - * Convert RFC 3390 larger initial window into an equivalent number of packets.
> - * This is based on the numbers specified in RFC 5681, 3.1.
> - */
> -static inline u32 rfc3390_bytes_to_packets(const u32 smss)
> -{
> - return smss <= 1095 ? 4 : (smss > 2190 ? 2 : 3);
> -}
> -
> extern void tcp_enter_cwr(struct sock *sk, const int set_ssthresh);
> extern __u32 tcp_init_cwnd(struct tcp_sock *tp, struct dst_entry *dst);
>
> diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c
> index e96d5e8..fadecd2 100644
> --- a/net/dccp/ccids/ccid2.c
> +++ b/net/dccp/ccids/ccid2.c
> @@ -583,6 +583,15 @@ done:
> dccp_ackvec_parsed_cleanup(&hc->tx_av_chunks);
> }
>
> +/*
> + * Convert RFC 3390 larger initial window into an equivalent number of packets.
> + * This is based on the numbers specified in RFC 5681, 3.1.
> + */
> +static inline u32 rfc3390_bytes_to_packets(const u32 smss)
> +{
> + return smss <= 1095 ? 4 : (smss > 2190 ? 2 : 3);
> +}
> +
> static int ccid2_hc_tx_init(struct ccid *ccid, struct sock *sk)
> {
> struct ccid2_hc_tx_sock *hc = ccid_priv(ccid);
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index eb7f82e..2f692ce 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -817,7 +817,7 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp, struct dst_entry *dst)
> __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0);
>
> if (!cwnd)
> - cwnd = rfc3390_bytes_to_packets(tp->mss_cache);
> + cwnd = TCP_INIT_CWND;
> return min_t(__u32, cwnd, tp->snd_cwnd_clamp);
> }
>
> --
> 1.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
David and others,
I don't think this change will make sense for DCCP, once IW10 is
for the cases of short-lived flows. DCCP is used on scenarios for
multimedia flows, which are, in general, long-lived flows. So, IMO the
way how we calculate IW for DCCP is appropriate, at least considering
a quick answer. In fact, nowadays we need better congestion control
algorithms for DCCP, and in this sense we are working on adapt TCP
Cubic for DCCP as a CCID, and also we started some work to make DCCP
support TCP pluggable mechanism , which will allow us to use TCP
congestion control algorithms in DCCP.
I've been following all the discussions about IW10 in the TCPM
discussion list and also been reading all materials in this context
(papers and ppts) provided by Tom Herbert and Nandita Dukkipati (along
with other researchers from Networking Research Lab at North Carolina
State University), but although the results is really great (at least
for scenarios they've experimented and regardless to all opinions
expressed at TCPM), DCCP should calculate its IW as specified in
RFC3390 rather than set it to IW10. For the moment, I understand that
for DCCP, we have to discuss more about this in a separated thread.
Leandro.
--
Leandro Melo de Sales
Professor at Institute of Computing at Federal University of Alagoas, Brazil
PhD candidate in Computer Science
Pervasive and Embedded Computing Laboratory, UFCG
^ permalink raw reply
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Carlos Mafra @ 2011-02-03 21:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Takashi Iwai, Linus Torvalds, Keith Packard, Dave Airlie,
Linux Kernel Mailing List, Maciej Rutecki, Florian Mickler,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <201102032009.17100.rjw@sisk.pl>
On Thu, Feb 3, 2011 at 8:09 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday, February 03, 2011, Takashi Iwai wrote:
>> At Thu, 3 Feb 2011 07:42:05 -0800,
>> Linus Torvalds wrote:
>> >
>> > On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra <crmafra2@gmail.com> wrote:
>> > > On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
>> > Just to confirm, can you also check -rc3? I'm pretty sure nothing has
>> > changed, but there were a few drm patches after -rc2, so it's alsways
>> > good to double-check.
>>
>> The problem I reported in the bugzilla above is still present in
>> 2.6.38-rc3. I'm pretty sure that's the same issue as Carlos' case.
>
> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
> post-2.6.36 regressions for further tracking.
I also tested on 2.6.38-rc3+ now and the issue is not solved,
just like Takashi expected.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ServerEngines, benet: Avoid potential null deref in be_cmd_get_seeprom_data()
From: Jesper Juhl @ 2011-02-03 21:27 UTC (permalink / raw)
To: netdev
Cc: linux-drivers, linux-kernel, Ajit Khaparde, Sarveshwar Bandi,
Subbu Seetharaman, Sathya Perla
wrb_from_mccq() may return null, so we may crash on a null deref in
be_cmd_get_seeprom_data().
This avoids that potential crash.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
be_cmds.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 0c7811f..ec4a21d 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1786,6 +1786,8 @@ int be_cmd_get_seeprom_data(struct be_adapter *adapter,
spin_lock_bh(&adapter->mcc_lock);
wrb = wrb_from_mccq(adapter);
+ if (!wrb)
+ return -EBUSY;
req = nonemb_cmd->va;
sge = nonembedded_sgl(wrb);
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: H.K. Jerry Chu @ 2011-02-03 21:17 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: David Miller, netdev, dccp, therbert
In-Reply-To: <47859e9273bb0c1b2c32fc1adfa450ee@localhost>
On Thu, Feb 3, 2011 at 6:00 AM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
>
> On Wed, 02 Feb 2011 17:07:50 -0800 (PST), David Miller wrote:
>
>> +/* TCP initial congestion window */
>> +#define TCP_INIT_CWND 10
>> +
>
> Davem, there is _no_ research how this huge IW will behave in environments
> with a small BDP. Belief it or not, but there are networks out there with a
> BDP similar to ~1980. Why for heaven's sake should this work in these
> environments? There are only _two_ extensive analysis one from Cherry and
> and one from Ilpo. Both analysis focus on current mainstream BDP. I started
It's more than that. We have also conducted extensive, large scale
experiments covering
all BDP/RTT combinations and the result was documented in details in a
SIGCOMM/CCR paper that can be found from a summary page
http://code.google.com/speed/protocols/tcpm-IW10.html covering all our
IW10 work.
> to setup a ns-2 environment but due to lack of time I am a little bit
> behind schedule. Anyway, why not make this a tunable per route knob so that
> it is easier to fix things, e.g. set IW back to 3.
You've seemed to get this backwards. Shouldn't we set the default for the normal
cases and leave the corner cases to the initcwnd and initrwnd knobs to cover?
Jerry
>
> HGN
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-02-02
From: David Miller @ 2011-02-03 21:07 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110202215322.GD2500-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 2 Feb 2011 16:53:22 -0500
> Here we have another big batch of updates destined for 2.6.39.
>
> A highlight is AP mode support for the wl12xx driver. There are
> also the usual updates to ath5k, ath9k, iwlwifi, rt2x00, and others.
> Also included are some wireless-2.6 pulls to correct for some build breakage.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* potential null pointer dereference in drivers/isdn/hisax/isdnl2.c
From: Jesper Juhl @ 2011-02-03 20:27 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Tejun Heo, Karsten Keil
Hi,
In drivers/isdn/hisax/isdnl2.c:l2_pull_iqueue() we have this:
...
skb = alloc_skb(oskb->len + i, GFP_ATOMIC);
memcpy(skb_put(skb, i), header, i);
...
If alloc_skb() fails and returns NULL then the second line will cause a
NULL pointer dereference - skb_put() gives the pointer to
skb_tail_pointer() which dereferences it.
I'm not quite sure how this should be dealt with, so I'll just report it
rather than submit a patch. Happy bug fixing :-)
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: [PATCH] tcp: Increase the initial congestion window to 10.
From: Yuchung Cheng @ 2011-02-03 20:28 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110202.170750.229739784.davem@davemloft.net>
Thanks for doing this!
Acked-by: Yuchung Cheng <ycheng@google.com>
On Wed, Feb 2, 2011 at 5:07 PM, David Miller <davem@davemloft.net> wrote:
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>
> I've left the DCCP code to keep using RFC3390 logic, if they
> wish to adopt this change in their code they can do so by
> simply deleting the rfc33390_bytes_to_packets() function and
> using TCP_INIT_CWND in their assignment.
>
> include/net/tcp.h | 12 +++---------
> net/dccp/ccids/ccid2.c | 9 +++++++++
> net/ipv4/tcp_input.c | 2 +-
> 3 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 9179111..7118668 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -196,6 +196,9 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
> /* TCP thin-stream limits */
> #define TCP_THIN_LINEAR_RETRIES 6 /* After 6 linear retries, do exp. backoff */
>
> +/* TCP initial congestion window */
> +#define TCP_INIT_CWND 10
> +
> extern struct inet_timewait_death_row tcp_death_row;
>
> /* sysctl variables for tcp */
> @@ -799,15 +802,6 @@ static inline __u32 tcp_current_ssthresh(const struct sock *sk)
> /* Use define here intentionally to get WARN_ON location shown at the caller */
> #define tcp_verify_left_out(tp) WARN_ON(tcp_left_out(tp) > tp->packets_out)
>
> -/*
> - * Convert RFC 3390 larger initial window into an equivalent number of packets.
> - * This is based on the numbers specified in RFC 5681, 3.1.
> - */
> -static inline u32 rfc3390_bytes_to_packets(const u32 smss)
> -{
> - return smss <= 1095 ? 4 : (smss > 2190 ? 2 : 3);
> -}
> -
> extern void tcp_enter_cwr(struct sock *sk, const int set_ssthresh);
> extern __u32 tcp_init_cwnd(struct tcp_sock *tp, struct dst_entry *dst);
>
> diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c
> index e96d5e8..fadecd2 100644
> --- a/net/dccp/ccids/ccid2.c
> +++ b/net/dccp/ccids/ccid2.c
> @@ -583,6 +583,15 @@ done:
> dccp_ackvec_parsed_cleanup(&hc->tx_av_chunks);
> }
>
> +/*
> + * Convert RFC 3390 larger initial window into an equivalent number of packets.
> + * This is based on the numbers specified in RFC 5681, 3.1.
> + */
> +static inline u32 rfc3390_bytes_to_packets(const u32 smss)
> +{
> + return smss <= 1095 ? 4 : (smss > 2190 ? 2 : 3);
> +}
> +
> static int ccid2_hc_tx_init(struct ccid *ccid, struct sock *sk)
> {
> struct ccid2_hc_tx_sock *hc = ccid_priv(ccid);
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index eb7f82e..2f692ce 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -817,7 +817,7 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp, struct dst_entry *dst)
> __u32 cwnd = (dst ? dst_metric(dst, RTAX_INITCWND) : 0);
>
> if (!cwnd)
> - cwnd = rfc3390_bytes_to_packets(tp->mss_cache);
> + cwnd = TCP_INIT_CWND;
> return min_t(__u32, cwnd, tp->snd_cwnd_clamp);
> }
>
> --
> 1.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] wireless, wl1251: Fix potential NULL pointer dereference in wl1251_op_bss_info_changed()
From: Jesper Juhl @ 2011-02-03 20:14 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, linux-kernel, John W. Linville, Kalle Valo
In drivers/net/wireless/wl1251/main.c:wl1251_op_bss_info_changed() we make
a call to ieee80211_beacon_get() which may return NULL, but we do not
check the return value before dereferencing the pointer.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/wl1251/main.c b/drivers/net/wireless/wl1251/main.c
index 012e1a4..40372ba 100644
--- a/drivers/net/wireless/wl1251/main.c
+++ b/drivers/net/wireless/wl1251/main.c
@@ -1039,6 +1039,9 @@ static void wl1251_op_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_BEACON) {
beacon = ieee80211_beacon_get(hw, vif);
+ if (!beacon)
+ goto out_sleep;
+
ret = wl1251_cmd_template_set(wl, CMD_BEACON, beacon->data,
beacon->len);
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
From: Rafael J. Wysocki @ 2011-02-03 19:09 UTC (permalink / raw)
To: Takashi Iwai
Cc: Linus Torvalds, Carlos R. Mafra, Keith Packard, Dave Airlie,
Linux Kernel Mailing List, Maciej Rutecki, Florian Mickler,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <s5haaid3xos.wl%tiwai@suse.de>
On Thursday, February 03, 2011, Takashi Iwai wrote:
> At Thu, 3 Feb 2011 07:42:05 -0800,
> Linus Torvalds wrote:
> >
> > On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra <crmafra2@gmail.com> wrote:
> > > On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
> > >>
> > >> If you know of any other unresolved post-2.6.36 regressions, please let us know
> > >> either and we'll add them to the list. Also, please let us know if any
> > >> of the entries below are invalid.
> > >
> > > I'm sorry if I'm overlooking something, but as far as I can see the regression
> > > reported here:
> > >
> > > https://lkml.org/lkml/2011/1/24/457
> > >
> > > is not in the list (update on that report: reverting that commit on top of
> > > 2.6.37 fixes the issue).
> >
> > Ok, added Keith and Dave to the cc, since they are the signers of that commit.
> >
> > > After some time, I also ended up finding an earlier report in the kernel bugzilla
> > > which I think is the same regression (it was bisected to the same commit):
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=24982
> > >
> > > but I do not see it in the list either, even though it's marked as a
> > > regression in the bugzilla.
> > >
> > > The issue was also present in 2.6.38-rc2 last time I tested.
> >
> > Just to confirm, can you also check -rc3? I'm pretty sure nothing has
> > changed, but there were a few drm patches after -rc2, so it's alsways
> > good to double-check.
>
> The problem I reported in the bugzilla above is still present in
> 2.6.38-rc3. I'm pretty sure that's the same issue as Carlos' case.
I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
post-2.6.36 regressions for further tracking.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH 0/3] r8169 driver fixes
From: Ivan Vecera @ 2011-02-03 19:01 UTC (permalink / raw)
To: Francois Romieu; +Cc: davem, netdev, Hayes Wang
In-Reply-To: <20110203172557.GA9024@electric-eye.fr.zoreil.com>
On Thu, 2011-02-03 at 18:26 +0100, Francois Romieu wrote:
> The following series includes Ivan Rx fifo overflow fix and similar
> changes I did after testing with various 8168 chipsets.
>
> The series is available as
> git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git r8169-davem
>
> Distance from 'master' (2ba451421b23636c45fabfa522858c5c124b3673)
> -----------------------------------------------------------------
>
> 0331b3b022b9724019e4c42fded4a01eaa6946f5
> 407786ae1960eef585f97bfa7625a36512925de0
> e4b6fa3d3d3db4fac32904ae12efe199de8efed0
>
> Diffstat
> --------
>
> drivers/net/r8169.c | 41 ++++++++++++++++++++++++++++++++---------
> 1 files changed, 32 insertions(+), 9 deletions(-)
>
> Shortlog
> --------
>
> Francois Romieu (2):
> r8169: RxFIFO overflow oddities with 8168 chipsets
> r8169: prevent RxFIFO induced loops in the irq handler.
>
> Ivan Vecera (1):
> r8169: use RxFIFO overflow workaround for 8168c chipset
>
Looks good.
Ivan
^ permalink raw reply
* [PATCH] niu: fix SMP race protecting rx_rings and tx_rings
From: Flavio Leitner @ 2011-02-03 18:45 UTC (permalink / raw)
To: netdev; +Cc: Flavio Leitner
It's possible to trigger a crash if one CPU is opening
the device while another CPU gets its statistics.
It happens because niu_alloc_channels() called from
niu_open() sets num_tx/rx_rings before allocating the
ring, so the other thread crashes when accessing
np->tx_rings[i].tx_packets at niu_get_tx_stats().
Signed-off-by: Flavio Leitner <fleitner@redhat.com>
---
drivers/net/niu.c | 29 ++++++++++++++++++++++++++---
drivers/net/niu.h | 1 +
2 files changed, 27 insertions(+), 3 deletions(-)
Compile tested only because I don't have the hardware.
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index 2541321..bfa494e 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -4328,7 +4328,7 @@ static void niu_free_tx_ring_info(struct niu *np, struct tx_ring_info *rp)
}
}
-static void niu_free_channels(struct niu *np)
+static void __niu_free_channels(struct niu *np)
{
int i;
@@ -4355,6 +4355,13 @@ static void niu_free_channels(struct niu *np)
}
}
+static void niu_free_channels(struct niu *np)
+{
+ down_write(&np->rings_rwlock);
+ __niu_free_channels(np);
+ up_write(&np->rings_rwlock);
+}
+
static int niu_alloc_rx_ring_info(struct niu *np,
struct rx_ring_info *rp)
{
@@ -4485,7 +4492,7 @@ static void niu_size_rbr(struct niu *np, struct rx_ring_info *rp)
rp->rbr_sizes[3] = rp->rbr_block_size;
}
-static int niu_alloc_channels(struct niu *np)
+static int __niu_alloc_channels(struct niu *np)
{
struct niu_parent *parent = np->parent;
int first_rx_channel, first_tx_channel;
@@ -4558,10 +4565,21 @@ static int niu_alloc_channels(struct niu *np)
return 0;
out_err:
- niu_free_channels(np);
+ __niu_free_channels(np);
return err;
}
+static int niu_alloc_channels(struct niu *np)
+{
+ int ret;
+
+ down_write(&np->rings_rwlock);
+ ret = __niu_alloc_channels(np);
+ up_write(&np->rings_rwlock);
+
+ return ret;
+}
+
static int niu_tx_cs_sng_poll(struct niu *np, int channel)
{
int limit = 1000;
@@ -6249,6 +6267,7 @@ static void niu_get_rx_stats(struct niu *np)
int i;
pkts = dropped = errors = bytes = 0;
+ down_read(&np->rings_rwlock);
for (i = 0; i < np->num_rx_rings; i++) {
struct rx_ring_info *rp = &np->rx_rings[i];
@@ -6259,6 +6278,7 @@ static void niu_get_rx_stats(struct niu *np)
dropped += rp->rx_dropped;
errors += rp->rx_errors;
}
+ up_read(&np->rings_rwlock);
np->dev->stats.rx_packets = pkts;
np->dev->stats.rx_bytes = bytes;
np->dev->stats.rx_dropped = dropped;
@@ -6271,6 +6291,7 @@ static void niu_get_tx_stats(struct niu *np)
int i;
pkts = errors = bytes = 0;
+ down_read(&np->rings_rwlock);
for (i = 0; i < np->num_tx_rings; i++) {
struct tx_ring_info *rp = &np->tx_rings[i];
@@ -6278,6 +6299,7 @@ static void niu_get_tx_stats(struct niu *np)
bytes += rp->tx_bytes;
errors += rp->tx_errors;
}
+ up_read(&np->rings_rwlock);
np->dev->stats.tx_packets = pkts;
np->dev->stats.tx_bytes = bytes;
np->dev->stats.tx_errors = errors;
@@ -9680,6 +9702,7 @@ static struct net_device * __devinit niu_alloc_and_init(
np->msg_enable = niu_debug;
+ init_rwsem(&np->rings_rwlock);
spin_lock_init(&np->lock);
INIT_WORK(&np->reset_task, niu_reset_task);
diff --git a/drivers/net/niu.h b/drivers/net/niu.h
index a41fa8e..555bae1 100644
--- a/drivers/net/niu.h
+++ b/drivers/net/niu.h
@@ -3265,6 +3265,7 @@ struct niu {
const struct niu_ops *ops;
union niu_mac_stats mac_stats;
+ struct rw_semaphore rings_rwlock;
struct rx_ring_info *rx_rings;
struct tx_ring_info *tx_rings;
int num_rx_rings;
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH] NETFILTER module xt_hmark new target for HASH MARK
From: Hans Schillstrom @ 2011-02-03 17:40 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Pablo Neira Ayuso, Hans Schillstrom, kaber@trash.net,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.01.1102031731010.30984@obet.zrqbmnf.qr>
--
Mvh
Hasse Schillstrom
070-699 7150
On Thursday, February 03, 2011 17:32:07 Jan Engelhardt wrote:
>
> On Thursday 2011-02-03 17:08, Pablo Neira Ayuso wrote:
> >>> Hm, this is actually not straight forward to implement, you'll have to
> >>> use hook functions to avoid the module dependencies with conntrack and
> >>> that's pretty annoying.
> >>>
> >>> I don't come up with a good solution for this.
> >>
> >> If it loads conntrack always, there is the option to shovel it
> >> into xt_connmark.c.
> >
> >the problem is that Hans wants this not to depend on conntrack always.
>
> Well you porbably won't get around the nf_conntrack module dependency,
> but conntrack can still be disabled through CT --notrack
> if one does not like the runtime cost.
>
If you do put this in front of a bunch of load balancers,
there is probably a lot of traffic :-)
So that's the reason why I don't want do depend upon conntrack.
^ permalink raw reply
* Re: [PATCH] NETFILTER module xt_hmark new target for HASH MARK
From: Hans Schillstrom @ 2011-02-03 17:37 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Hans Schillstrom, kaber@trash.net, jengelh@medozas.de,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <4D4AD157.50707@netfilter.org>
On Thursday, February 03, 2011 17:01:27 Pablo Neira Ayuso wrote:
> On 03/02/11 16:42, Pablo Neira Ayuso wrote:
> > On 03/02/11 15:23, Hans Schillstrom wrote:
> >> On Thu, 2011-02-03 at 14:51 +0100, Pablo Neira Ayuso wrote:
> >>> On 03/02/11 14:34, Hans Schillstrom wrote:
> >>> this assumption is not valid in NAT handlings.
> >>
> >> That's true, because I want to avoid conntrack
> >>
> >>> If you want consistent hashing with NAT handlings you'll have to make
> >>> this stateful and use the conntrack source and reply directions of the
> >>> original tuples (thus making it stateful). That may be a problem because
> >>> some people may want to use this without enabling connection tracking.
> >>
> >> What about a compilation switch or a sysctl ?
> >
> > or better some option for iptables.
>
> Hm, this is actually not straight forward to implement, you'll have to
> use hook functions to avoid the module dependencies with conntrack and
> that's pretty annoying.
>
> I don't come up with a good solution for this.
A configuration switch might be OK.
>
> >>> Are you using this for (uplink) load balancing?
> >>
> >> Actually in both ways
> >> - in front of a bunch of ipvs
>
> to make some preliminary load-sharing between the load balancers?
Yes that's right
and in the payloads send the return traffic in the same path.
>
> >> - and in the payloads for outgoing traffic.
>
> and then to select the uplink, right?
>
Yes.
It also has the same role for cluster originated traffic to spread the load over multiple interfaces,
and catch the return traffic.
^ permalink raw reply
* [PATCH 3/3] r8169: prevent RxFIFO induced loops in the irq handler.
From: Francois Romieu @ 2011-02-03 17:26 UTC (permalink / raw)
To: davem; +Cc: netdev, Ivan Vecera, Hayes Wang
While the RxFIFO interruption is masked for most 8168, nothing prevents
it to appear in the irq status word. This is no excuse to crash.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Ivan Vecera <ivecera@redhat.com>
Cc: Hayes <hayeswang@realtek.com>
---
drivers/net/r8169.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 40dabe2..59ccf0c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -4650,6 +4650,15 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
goto done;
+ /* Testers needed. */
+ case RTL_GIGA_MAC_VER_17:
+ case RTL_GIGA_MAC_VER_19:
+ case RTL_GIGA_MAC_VER_20:
+ case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_23:
+ case RTL_GIGA_MAC_VER_24:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
/* Experimental science. Pktgen proof. */
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_25:
--
1.7.3.5
^ permalink raw reply related
* [PATCH 2/3] r8169: RxFIFO overflow oddities with 8168 chipsets
From: Francois Romieu @ 2011-02-03 17:26 UTC (permalink / raw)
To: davem; +Cc: netdev, Ivan Vecera, Hayes Wang
Some experiment-based action to prevent my 8168 chipsets locking-up hard
in the irq handler under load (pktgen ~1Mpps). Apparently a reset is not
always mandatory (is it at all ?).
- RTL_GIGA_MAC_VER_12
- RTL_GIGA_MAC_VER_25
Missed ~55% packets. Note:
- this is an old SiS 965L motherboard
- the 8168 chipset emits (lots of) control frames towards the sender
- RTL_GIGA_MAC_VER_26
The chipset does not go into a frenzy of mac control pause when it
crashes yet but it can still be crashed. It needs more work.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Ivan Vecera <ivecera@redhat.com>
Cc: Hayes <hayeswang@realtek.com>
---
drivers/net/r8169.c | 30 +++++++++++++++++++++---------
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9ab3b43..40dabe2 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -973,7 +973,8 @@ static void __rtl8169_check_link_status(struct net_device *dev,
if (pm)
pm_request_resume(&tp->pci_dev->dev);
netif_carrier_on(dev);
- netif_info(tp, ifup, dev, "link up\n");
+ if (net_ratelimit())
+ netif_info(tp, ifup, dev, "link up\n");
} else {
netif_carrier_off(dev);
netif_info(tp, ifdown, dev, "link down\n");
@@ -4640,13 +4641,24 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
break;
}
- /* Work around for rx fifo overflow */
- if (unlikely(status & RxFIFOOver) &&
- (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
- tp->mac_version == RTL_GIGA_MAC_VER_22)) {
- netif_stop_queue(dev);
- rtl8169_tx_timeout(dev);
- break;
+ if (unlikely(status & RxFIFOOver)) {
+ switch (tp->mac_version) {
+ /* Work around for rx fifo overflow */
+ case RTL_GIGA_MAC_VER_11:
+ case RTL_GIGA_MAC_VER_22:
+ case RTL_GIGA_MAC_VER_26:
+ netif_stop_queue(dev);
+ rtl8169_tx_timeout(dev);
+ goto done;
+ /* Experimental science. Pktgen proof. */
+ case RTL_GIGA_MAC_VER_12:
+ case RTL_GIGA_MAC_VER_25:
+ if (status == RxFIFOOver)
+ goto done;
+ break;
+ default:
+ break;
+ }
}
if (unlikely(status & SYSErr)) {
@@ -4682,7 +4694,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
(status & RxFIFOOver) ? (status | RxOverflow) : status);
status = RTL_R16(IntrStatus);
}
-
+done:
return IRQ_RETVAL(handled);
}
--
1.7.3.5
^ 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