* Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
From: Evgeniy Polyakov @ 2010-04-21 0:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ben Greear, David Miller, Gaspar Chilingarov, netdev
In-Reply-To: <1271808314.7895.614.camel@edumazet-laptop>
On Wed, Apr 21, 2010 at 02:05:14AM +0200, Eric Dumazet (eric.dumazet@gmail.com) wrote:
> I believe the bsockets 'optimization' is a bug, we should remove it.
>
> This is a stable candidate (2.6.30+)
>
> [PATCH net-next-2.6] tcp: remove bsockets count
>
> Counting number of bound sockets to avoid a loop is buggy, since we cant
> know how many IP addresses are in use. When threshold is reached, we try
> 5 random slots and can fail while there are plenty available ports.
To return back to exponential bind() times you need to revert the whole
original patch including magic 5 number, not only bsockets.
But actual problem is not in this digit, but in a deeper logic.
Previously we scanned the whole table, now we have 5 attempts to
find out at least one bucket (without conflict) we will insert
new socket into. Apparently for large number of addresses it is possible
that all 5 times we will randomly select those buckets which conflicts.
As dumb solution we can increase 'attempt' number to infinite one, or
fallback to whole-table-search after several random attempts, which is a
bit more clever I think.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
From: Evgeniy Polyakov @ 2010-04-21 0:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Gaspar Chilingarov, netdev
In-Reply-To: <1271806945.7895.581.camel@edumazet-laptop>
Hi.
On Wed, Apr 21, 2010 at 01:42:25AM +0200, Eric Dumazet (eric.dumazet@gmail.com) wrote:
> If you want to check source, its in file net/ipv4/inet_connection_sock.c
>
> function inet_csk_get_port()
>
> you can remove the
>
> if (atomic_read(&hashinfo->bsockets) > (high - low) + 1) {
> spin_unlock(&head->lock);
> snum = smallest_rover;
> goto have_snum;
> }
>
> It will solve your problem (but bind() will probably be slow)
Netcat uses SO_REUSEADDR, so its the code path which generates an error,
but this part actually returns a port number not en error. I suppose
what happend is 'attempts' check faired and thus system failed to find
a small enough bucket which does not conflict. To test this we can
remove 'smallest_size = tb->num_owners;' assignment, but bind() can be
damn slow in this case indeed.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: Mikulas Patocka @ 2010-04-21 0:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber
In-Reply-To: <20100420.171525.200010343.davem@davemloft.net>
On Tue, 20 Apr 2010, David Miller wrote:
> From: Mikulas Patocka <mpatocka@redhat.com>
> Date: Tue, 20 Apr 2010 20:12:45 -0400 (EDT)
>
> > Why is it using GSO on bridging?
>
> Unlike LRO, GRO and GSO are completely valid in bridging and
> routing situations.
>
> In fact, in virtualization environments it is essential for
> good performance.
I know it may be used for bridging. But it doesn't explain how it happened
in my case.
I have two NICs, each with 1500 MTU. The stack trace indicates that a
packet was received by one NIC and bridged to the other. The stack trace
also indicates that it went through GSO code path. The question is why?
How could a forwarded packet be so large to use GSO?
Mikulas
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: David Miller @ 2010-04-21 1:02 UTC (permalink / raw)
To: mpatocka; +Cc: netdev, kaber
In-Reply-To: <Pine.LNX.4.64.1004202018100.16302@hs20-bc2-1.build.redhat.com>
From: Mikulas Patocka <mpatocka@redhat.com>
Date: Tue, 20 Apr 2010 20:23:57 -0400 (EDT)
> I have two NICs, each with 1500 MTU. The stack trace indicates that a
> packet was received by one NIC and bridged to the other. The stack trace
> also indicates that it went through GSO code path. The question is why?
> How could a forwarded packet be so large to use GSO?
GRO automatically accumulates packets together, accumulating them into
larger super-packets. This is done regardless of input device feeding
it.
Can you understand this now? In software, we accumulate all incoming
packets for a TCP stream into larger super-packets. Just because it's
a bridging scenerio doesn't mean we disable GRO.
These super-packets are being bridged, then forwarded out your
destination device and GSO has to de-segment these GRO frames.
GRO is done unconditionally, all the time, for all packets.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-04-20
From: David Miller @ 2010-04-21 1:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100420183013.GC6472@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 20 Apr 2010 14:30:14 -0400
> Here are a few more intended for 2.6.34, mostly from the iwlwifi team.
> They fix a couple of potential crashes, an incorrect EEPROM offset
> related to regulatory information, and a connectivity failure relating
> to 802.11n and the 4965. The "iwlwifi: fix scan races" seems a little
> long, but much of it is the fallout from renaming a goto label.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH] can: Fix possible NULL pointer dereference in ems_usb.c
From: David Miller @ 2010-04-21 1:05 UTC (permalink / raw)
To: wg; +Cc: hjk, netdev, socketcan-core
In-Reply-To: <4BCE04D9.2030601@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Tue, 20 Apr 2010 21:47:37 +0200
> Hans J. Koch wrote:
>> In ems_usb_probe(), a pointer is dereferenced after making sure it is NULL...
>>
>> This patch replaces dev_err() with printk() to avoid this.
>>
>> Signed-off-by: "Hans J. Koch" <hjk@linutronix.de>
>> ---
>> drivers/net/can/usb/ems_usb.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: linux-2.6.34-rc/drivers/net/can/usb/ems_usb.c
>> ===================================================================
>> --- linux-2.6.34-rc.orig/drivers/net/can/usb/ems_usb.c 2010-04-20 15:32:25.000000000 +0200
>> +++ linux-2.6.34-rc/drivers/net/can/usb/ems_usb.c 2010-04-20 15:33:20.000000000 +0200
>> @@ -1006,7 +1006,7 @@
>>
>> netdev = alloc_candev(sizeof(struct ems_usb), MAX_TX_URBS);
>> if (!netdev) {
>> - dev_err(netdev->dev.parent, "Couldn't alloc candev\n");
>> + printk(KERN_ERR "ems_usb: Couldn't alloc candev\n");
>> return -ENOMEM;
>> }
>
> I think "dev_err(&intf->dev, ...)" should be used before
> SET_NETDEV_DEV(netdev, &intf->dev) is called. I see two "dev_err()"
> calls which need to be fixed.
Agreed.
^ permalink raw reply
* Re: [PATCH] gianfar: Wait for both RX and TX to stop
From: David Miller @ 2010-04-21 1:06 UTC (permalink / raw)
To: timur.tabi; +Cc: galak, afleming, netdev
In-Reply-To: <o2oed82fe3e1004200801n98683cdalb2898c879b93f8fd@mail.gmail.com>
From: Timur Tabi <timur.tabi@gmail.com>
Date: Tue, 20 Apr 2010 10:01:48 -0500
> On Mon, Apr 19, 2010 at 11:43 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
>> spin_event_timeout doesn't make sense for this. The patch is fine.
>
> Can you please elaborate on that? I don't understand why you think
> that. spin_event_timeout() takes an expression and a timeout, and
> loops over the expression calling cpu_relax(), just like this loop
> does.
Indeed it does, Kumar this request seems reasonable.
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: Mikulas Patocka @ 2010-04-21 1:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber
In-Reply-To: <20100420.180253.159346294.davem@davemloft.net>
On Tue, 20 Apr 2010, David Miller wrote:
> From: Mikulas Patocka <mpatocka@redhat.com>
> Date: Tue, 20 Apr 2010 20:23:57 -0400 (EDT)
>
> > I have two NICs, each with 1500 MTU. The stack trace indicates that a
> > packet was received by one NIC and bridged to the other. The stack trace
> > also indicates that it went through GSO code path. The question is why?
> > How could a forwarded packet be so large to use GSO?
>
> GRO automatically accumulates packets together, accumulating them into
> larger super-packets. This is done regardless of input device feeding
> it.
>
> Can you understand this now? In software, we accumulate all incoming
> packets for a TCP stream into larger super-packets. Just because it's
> a bridging scenerio doesn't mean we disable GRO.
>
> These super-packets are being bridged, then forwarded out your
> destination device and GSO has to de-segment these GRO frames.
>
> GRO is done unconditionally, all the time, for all packets.
I see, but GRO is turned off on my interfaces, according to ethtool.
Mikulas
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: David Miller @ 2010-04-21 1:14 UTC (permalink / raw)
To: mpatocka; +Cc: netdev, kaber
In-Reply-To: <Pine.LNX.4.64.1004202108240.27476@hs20-bc2-1.build.redhat.com>
From: Mikulas Patocka <mpatocka@redhat.com>
Date: Tue, 20 Apr 2010 21:10:04 -0400 (EDT)
> I see, but GRO is turned off on my interfaces, according to ethtool.
GRO is just a flag bit, so it's possible that if your kernel is too
old ethtool will always show that it's off.
If you haven't turned off GRO explicitly, then it's a good bet that
this is why it looks like it's off. And GRO is on by default.
I still contend, therefore, that it's completely normal to see GSO
packet processing in the TX code path, even with bridging, and
therefore seeing the GSO code path get taken is not indicative of some
bug wrt. ->ndo_start_xmit() return value flag bit handling.
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: David Miller @ 2010-04-21 1:16 UTC (permalink / raw)
To: mpatocka; +Cc: netdev, kaber
In-Reply-To: <20100420.181434.35828504.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 20 Apr 2010 18:14:34 -0700 (PDT)
> From: Mikulas Patocka <mpatocka@redhat.com>
> Date: Tue, 20 Apr 2010 21:10:04 -0400 (EDT)
>
>> I see, but GRO is turned off on my interfaces, according to ethtool.
>
> GRO is just a flag bit, so it's possible that if your kernel is too
> old ethtool will always show that it's off.
Actually, looking back at your original report, are you confusing
"large-receive-offload" as reported by ethtool with GRO?
They are completely seperate things.
"large-receive-offload" is LRO, whereas GRO is something done
in software and something entirely different.
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: Mikulas Patocka @ 2010-04-21 1:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber
In-Reply-To: <20100420.181434.35828504.davem@davemloft.net>
On Tue, 20 Apr 2010, David Miller wrote:
> From: Mikulas Patocka <mpatocka@redhat.com>
> Date: Tue, 20 Apr 2010 21:10:04 -0400 (EDT)
>
> > I see, but GRO is turned off on my interfaces, according to ethtool.
>
> GRO is just a flag bit, so it's possible that if your kernel is too
> old ethtool will always show that it's off.
>
> If you haven't turned off GRO explicitly, then it's a good bet that
> this is why it looks like it's off. And GRO is on by default.
I have kernel 2.6.34-rc4, ethtool 2.6.33 and GRO is off. I haven't turned
it off, I left it on default.
> I still contend, therefore, that it's completely normal to see GSO
> packet processing in the TX code path, even with bridging, and
> therefore seeing the GSO code path get taken is not indicative of some
> bug wrt. ->ndo_start_xmit() return value flag bit handling.
Mikulas
^ permalink raw reply
* Re: [PATCH] bridge: add a missing ntohs()
From: David Miller @ 2010-04-21 1:21 UTC (permalink / raw)
To: herbert; +Cc: eric.dumazet, netdev
In-Reply-To: <20100420133016.GA21788@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 20 Apr 2010 21:30:16 +0800
> On Tue, Apr 20, 2010 at 03:20:05PM +0200, Eric Dumazet wrote:
>> Found by code review and sparse endianness warning, I am not sure this
>> patch is valid.
>>
>> Thanks
>>
>> [PATCH] bridge: add a missing ntohs()
>>
>> grec_nsrcs is in network order, we should convert to host horder in
>> br_multicast_igmp3_report()
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Good catch Eric.
Note that this means that most igmpv3_grec entries get ignored
on little-endian because the greg_nsrcs will look "real big"
and thus the pskb_may_pull() will fail.
Anyways I'll apply this to net-2.6, thanks.
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: Mikulas Patocka @ 2010-04-21 1:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber
In-Reply-To: <20100420.181648.183008607.davem@davemloft.net>
On Tue, 20 Apr 2010, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 20 Apr 2010 18:14:34 -0700 (PDT)
>
> > From: Mikulas Patocka <mpatocka@redhat.com>
> > Date: Tue, 20 Apr 2010 21:10:04 -0400 (EDT)
> >
> >> I see, but GRO is turned off on my interfaces, according to ethtool.
> >
> > GRO is just a flag bit, so it's possible that if your kernel is too
> > old ethtool will always show that it's off.
>
> Actually, looking back at your original report, are you confusing
> "large-receive-offload" as reported by ethtool with GRO?
>
> They are completely seperate things.
>
> "large-receive-offload" is LRO, whereas GRO is something done
> in software and something entirely different.
Posting once more. Both LRO and GRO are off. And it is default.
Mikulas
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: David Miller @ 2010-04-21 1:22 UTC (permalink / raw)
To: mpatocka; +Cc: netdev, kaber
In-Reply-To: <Pine.LNX.4.64.1004202116570.29631@hs20-bc2-1.build.redhat.com>
From: Mikulas Patocka <mpatocka@redhat.com>
Date: Tue, 20 Apr 2010 21:20:09 -0400 (EDT)
>
>
> On Tue, 20 Apr 2010, David Miller wrote:
>
>> From: Mikulas Patocka <mpatocka@redhat.com>
>> Date: Tue, 20 Apr 2010 21:10:04 -0400 (EDT)
>>
>> > I see, but GRO is turned off on my interfaces, according to ethtool.
>>
>> GRO is just a flag bit, so it's possible that if your kernel is too
>> old ethtool will always show that it's off.
>>
>> If you haven't turned off GRO explicitly, then it's a good bet that
>> this is why it looks like it's off. And GRO is on by default.
>
> I have kernel 2.6.34-rc4, ethtool 2.6.33 and GRO is off. I haven't turned
> it off, I left it on default.
See my follow-up, what ethtool output makes you think GRO is
off? "large-receive-offload" is not GRO
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: David Miller @ 2010-04-21 1:24 UTC (permalink / raw)
To: mpatocka; +Cc: netdev, kaber
In-Reply-To: <Pine.LNX.4.64.1004202120180.29631@hs20-bc2-1.build.redhat.com>
From: Mikulas Patocka <mpatocka@redhat.com>
Date: Tue, 20 Apr 2010 21:21:36 -0400 (EDT)
> Posting once more. Both LRO and GRO are off. And it is default.
Weird, ok thanks for posting this information.
Maybe whatever sets up your bridge turns off GRO, but that's extremely
unfortunate since the whole point of GRO was so that we could keep it
enabled even with bridging or forwarding enabled.
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: Mikulas Patocka @ 2010-04-21 1:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kaber
In-Reply-To: <20100420.182215.179278537.davem@davemloft.net>
> > On Tue, 20 Apr 2010, David Miller wrote:
> >
> >> From: Mikulas Patocka <mpatocka@redhat.com>
> >> Date: Tue, 20 Apr 2010 21:10:04 -0400 (EDT)
> >>
> >> > I see, but GRO is turned off on my interfaces, according to ethtool.
> >>
> >> GRO is just a flag bit, so it's possible that if your kernel is too
> >> old ethtool will always show that it's off.
> >>
> >> If you haven't turned off GRO explicitly, then it's a good bet that
> >> this is why it looks like it's off. And GRO is on by default.
> >
> > I have kernel 2.6.34-rc4, ethtool 2.6.33 and GRO is off. I haven't turned
> > it off, I left it on default.
>
> See my follow-up, what ethtool output makes you think GRO is
> off? "large-receive-offload" is not GRO
generic-receive-offload: off
Mikulas
^ permalink raw reply
* Re: crash with bridge and inconsistent handling of NETDEV_TX_OK
From: David Miller @ 2010-04-21 2:01 UTC (permalink / raw)
To: mpatocka; +Cc: netdev, kaber
In-Reply-To: <20100420.182407.174368203.davem@davemloft.net>
I looked more at your crash report.
You shouldn't even be in this code path for other reasons, namely
skb->next should be NULL. But it's not in your case. skb->next would
only be non-NULL for GSO frames, which we've established we should not
be seeing here.
Given that skb->next is non-NULL and the fraglists of this SKB are
corrupted (next pointer is 0x18), I think we're getting memory
corruption from somewhere else. This also jives with the fact that
this is not readily reproducable.
The whole ->ndo_start_xmit() return value stuff is unrelated to this
issue, we shouldn't even be in this code path. In fact, if reverting
that TX flags handling commit makes your crashes go away it would be a
huge surprise.
^ permalink raw reply
* Re: A possible bug in reqsk_queue_hash_req()
From: Li Yu @ 2010-04-21 2:02 UTC (permalink / raw)
To: Eric Dumazet, netdev, linux-kernel
In-Reply-To: <1271775681.7895.21.camel@edumazet-laptop>
Eric Dumazet 写道:
> Le mardi 20 avril 2010 à 21:21 +0800, Li Yu a écrit :
>
>> In my word, write lock also means mutual exclusion among all writers,
>> is it right?
>>
>
> Yes, generally speaking.
>
> But not on this use case.
>
> This is documented in an include file, if you search for syn_wait_lock
>
>>> All callers of this reqsk_queue_hash_req() must have the socket locked
>> See. If we always assumed the caller should hold the locked socket
>> first, this is not a bug, but I think we'd better add a comment at
>> header file.
>
> It is documented, as a matter of fact :)
>
>
Great, this isn't a bug, you are right here :)
I just found out these comments about syn_wait_lock, it seem that we need to crossed reference documents for kernel API, a newbie like me, may confused at such similar problems.
>
^ permalink raw reply
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Ben Gamari @ 2010-04-21 2:02 UTC (permalink / raw)
To: Rafael J. Wysocki, Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <deuQKFRcc0B.A.3EG.BRSzLB@tosh>
On Tue, 20 Apr 2010 05:15:57 +0200 (CEST), "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message contains a list of some regressions from 2.6.33,
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 2.6.33, 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 have recently reported this suspend regression on my Dell laptop hardware.
References: http://lkml.org/lkml/2010/4/18/20
Bug-report: https://bugzilla.kernel.org/show_bug.cgi?id=15820
Thanks,
- Ben
^ permalink raw reply
* Re: PROBLEM: Linux kernel 2.6.31 IPv4 TCP fails to open huge amount of outgoing connections (unable to bind ... )
From: David Miller @ 2010-04-21 2:04 UTC (permalink / raw)
To: zbr; +Cc: eric.dumazet, greearb, gasparch, netdev
In-Reply-To: <20100421003022.GA3107@ioremap.net>
From: Evgeniy Polyakov <zbr@ioremap.net>
Date: Wed, 21 Apr 2010 04:30:22 +0400
> To return back to exponential bind() times you need to revert the whole
> original patch including magic 5 number, not only bsockets.
Indeed, if we keep that '5' thing there it's just going to still fail
similarly.
> But actual problem is not in this digit, but in a deeper logic.
> Previously we scanned the whole table, now we have 5 attempts to
> find out at least one bucket (without conflict) we will insert
> new socket into. Apparently for large number of addresses it is possible
> that all 5 times we will randomly select those buckets which conflicts.
> As dumb solution we can increase 'attempt' number to infinite one, or
> fallback to whole-table-search after several random attempts, which is a
> bit more clever I think.
If random number generator is not too terrible, just using infinite
limit would be roughly equivalent.
^ permalink raw reply
* Re: [PATCH] cxgb3: fix linkup issue
From: David Miller @ 2010-04-21 2:06 UTC (permalink / raw)
To: h-shimamoto; +Cc: netdev, linux-kernel, divy
In-Reply-To: <4BCD0424.8030501@ct.jp.nec.com>
From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Date: Tue, 20 Apr 2010 10:32:20 +0900
> From: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
>
> I encountered an issue that not to link up on cxgb3 fabric.
> I bisected and found that this regression was introduced by
> 0f07c4ee8c800923ae7918c231532a9256233eed.
>
> Correct to pass phy_addr to cphy_init() at t3_xaui_direct_phy_prep().
>
> Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
CXGB3 maintainers, please review.
> ---
> drivers/net/cxgb3/ael1002.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/cxgb3/ael1002.c b/drivers/net/cxgb3/ael1002.c
> index 5248f9e..35cd367 100644
> --- a/drivers/net/cxgb3/ael1002.c
> +++ b/drivers/net/cxgb3/ael1002.c
> @@ -934,7 +934,7 @@ static struct cphy_ops xaui_direct_ops = {
> int t3_xaui_direct_phy_prep(struct cphy *phy, struct adapter *adapter,
> int phy_addr, const struct mdio_ops *mdio_ops)
> {
> - cphy_init(phy, adapter, MDIO_PRTAD_NONE, &xaui_direct_ops, mdio_ops,
> + cphy_init(phy, adapter, phy_addr, &xaui_direct_ops, mdio_ops,
> SUPPORTED_10000baseT_Full | SUPPORTED_AUI | SUPPORTED_TP,
> "10GBASE-CX4");
> return 0;
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Fix various endianness glitches
From: David Miller @ 2010-04-21 2:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1271769504.7895.13.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Apr 2010 15:18:24 +0200
> Sparse can help us find endianness bugs, but we need to make some
> cleanups to be able to more easily spot real bugs.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Since this already helped you find a bug in the bridging
igmp snooping code, how can I not apply this? :-)
Applied, thanks Eric.
^ permalink raw reply
* [PATCH net-next-2.6 1/2] niu: Enable GRO by default.
From: David Miller @ 2010-04-21 2:08 UTC (permalink / raw)
To: netdev
This was merely an oversight when I added the napi_gro_receive()
calls.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/niu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index ef94022..493e25c 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -9838,7 +9838,7 @@ static int __devinit niu_pci_init_one(struct pci_dev *pdev,
}
}
- dev->features |= (NETIF_F_SG | NETIF_F_HW_CSUM);
+ dev->features |= (NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GRO);
np->regs = pci_ioremap_bar(pdev, 0);
if (!np->regs) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next-2.6 2/2] tg3: Enable GRO by default.
From: David Miller @ 2010-04-21 2:08 UTC (permalink / raw)
To: netdev
This was merely an oversight when I added the *_gro_receive()
calls.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/tg3.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0fea685..7724d7e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -12993,6 +12993,7 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
tp->dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
if (tp->tg3_flags3 & TG3_FLG3_5755_PLUS)
tp->dev->features |= NETIF_F_IPV6_CSUM;
+ tp->dev->features |= NETIF_F_GRO;
}
/* Determine TSO capabilities */
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] ehea: error handling improvement
From: David Miller @ 2010-04-21 2:16 UTC (permalink / raw)
To: osstklei; +Cc: raisch, themann, linux-kernel, linuxppc-dev, netdev
In-Reply-To: <4BCC47AB.2090600@de.ibm.com>
From: Thomas Klein <osstklei@de.ibm.com>
Date: Mon, 19 Apr 2010 14:08:11 +0200
> Reset a port's resources only if they're actually in an error state
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
> ---
>
> Patch created against 2.6.34-rc4
There are several problems with these patches:
1) They are corrupted by your email client, lines unchanged
begin with one space character instead of two. Therefore
even 'patch' wouldn't accept these changes.
2) The double slash in the patch file paths make git not
accept the change. Please don't put double-slashes in
your patch paths as that canonically means "/".
3) These are not appropriate for net-2.6 as we are deep in
the -rcX series at this point and only the most diabolical
bug fixes are appropriate. Therefore, please generate these
against net-next-2.6, thanks.
^ permalink raw reply
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