* Re: [PATCH] net: Fix struct sock bitfield annotation
From: David Miller @ 2009-10-09 7:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: vegard.nossum, netdev, mingo
In-Reply-To: <4ACE8CEC.3020905@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 09 Oct 2009 03:07:56 +0200
> Point is we should not lose 8 bytes with kmemcheck on or off.
> I believe kmemcheck macros are fine as they are.
>
> When we have a structure with
>
> unsigned char sk_shutdown : 2,
> sk_no_check : 2,
> sk_userlocks : 4;
> unsigned char sk_protocol;
> unsigned short sk_type;
>
> Its pretty clear its *logically* a bitfield aggregation, or if you prefer :
I think from a practical standpoint, you are right.
But Vegard is right too, as we should be able to put the annotation
right next to the ":" statements.
So if you really want why don't you put the sk_protocol and
sk_type into the ":" block as you mentioned.
And then you can use Arnaldo's 'pahole' instead of the kludgy
offsetof() which doesn't work with bitfields :-)
I want the 8 bytes back just like you, but seperating the annotation
from the real C bitfields looks definitely wrong to me.
^ permalink raw reply
* [PATCH] irda/sa1100_ir: check return value of startup hook
From: Dmitry Artamonow @ 2009-10-09 7:25 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: netdev, Russell King, David S. Miller, linux-arm-kernel
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
---
drivers/net/irda/sa1100_ir.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/irda/sa1100_ir.c b/drivers/net/irda/sa1100_ir.c
index 38bf7cf..df5db2d 100644
--- a/drivers/net/irda/sa1100_ir.c
+++ b/drivers/net/irda/sa1100_ir.c
@@ -232,8 +232,11 @@ static int sa1100_irda_startup(struct sa1100_irda *si)
/*
* Ensure that the ports for this device are setup correctly.
*/
- if (si->pdata->startup)
- si->pdata->startup(si->dev);
+ if (si->pdata->startup) {
+ ret = si->pdata->startup(si->dev);
+ if (ret)
+ return ret;
+ }
/*
* Configure PPC for IRDA - we want to drive TXD2 low.
--
1.6.3.4
^ permalink raw reply related
* SRIOV driver for 82599
From: Satish Chowdhury @ 2009-10-09 7:03 UTC (permalink / raw)
To: netdev
Hi,
I want to test the SRIOV functionality of Intel 82599 based NIC card.
Is there a version of ixgbe driver with SRIOV functionality support
and is there a ixgbe VF driver?
Thanks
-Satish
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] ixgbe: Fix KR to KX fail over for Mezzanine cards
From: David Miller @ 2009-10-09 6:00 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, don.c.skidmore
In-Reply-To: <20091009013621.13495.66152.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 08 Oct 2009 18:36:22 -0700
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> This patch allows the recently added backplane device IDs that support KR
> to fail over to KX during link setup. This is accomplished by the new MAC
> link setup function ixgbe_setup_mac_link_smartspeed(). Comments were also
> updated to better document the reason for the delays chosen for KX, KX4, BX,
> BX4 and KR connections.
>
> Signed-off-by: Don Skidmore <don.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/2] ixgbe: add support for 82599 based Express Module X520-P2
From: David Miller @ 2009-10-09 6:00 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, donald.c.skidmore, peter.p.waskiewicz.jr
In-Reply-To: <20091009013530.13495.97717.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 08 Oct 2009 18:35:58 -0700
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> This patch will add the device ID for the 82599-based Ethernet
> Express Module X520-P2 SFI card.
>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH -next][resubmit] cdc_ether: additional Ericsson MBM PID's to the whitelist
From: David Miller @ 2009-10-09 6:00 UTC (permalink / raw)
To: torgny.johansson; +Cc: netdev
In-Reply-To: <E86B0C24322D8648AC7F41E7CDA658E903DDD5FD@esealmw114.eemea.ericsson.se>
From: "Torgny Johansson" <torgny.johansson@ericsson.com>
Date: Thu, 8 Oct 2009 16:20:48 +0200
> This is a new attempt to submit a patch that adds seven more PID's to the whitelist set of device. Been having some problems submitting patches with Outlook (yes I know that is a baaad idea :)) but hopefully this will get sent right.
>
> Devices added to the whitelist:
> - Ericsson Mobile Broadband variants (F3607gw and F3307)
> - Dell F3607gw variants
> - Toshiba F3607gw variants
>
> Regards
> Torgny Johansson
>
> Signed-off-by: Torgny Johansson <torgny.johansson@ericsson.com>
Your patch does not apply cleanly to Linus's current tree, it
produces rejects even with 'patch'.
Please respin your patch against current sources and resubmit,
thank you.
^ permalink raw reply
* Re: [PATCH][v2] ibm_newemac: Added 16K Tx FIFO size support for EMAC4
From: David Miller @ 2009-10-09 5:55 UTC (permalink / raw)
To: benh; +Cc: netdev, linuxppc-dev, dmitchell
In-Reply-To: <1255054502.2355.27.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 09 Oct 2009 13:15:02 +1100
> On Thu, 2009-10-08 at 11:32 -0500, Dave Mitchell wrote:
>> Some of the EMAC V4 implementations support 16K Tx FIFOs. This
>> patch adds support for this functionality and fixes typos in the
>> Tx FIFO size error messages.
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
>> Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
>> Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
>> Acked-by: Victor Gallardo <vgallardo@appliedmicro.com>
>> Acked-by: Loc Ho <lho@appliedmicro.com>
Applied to net-2.6, thanks!
^ permalink raw reply
* Re: [net-2.6 PATCH 0/7] qlge: Fixes for bonding, RSS and reset.
From: David Miller @ 2009-10-09 5:55 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1255031683-3912-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Thu, 8 Oct 2009 12:54:36 -0700
> More QLGE fixes for bonding, RSS and reset.
All applied to net-2.6, thank you.
^ permalink raw reply
* Re: [Patch-next] Fix the size overflow of addrconf_sysctl array
From: David Miller @ 2009-10-09 5:44 UTC (permalink / raw)
To: jin.dongming
Cc: linux-kernel, cratiu, opurdila, kaneshige.kenji, seto.hidetoshi,
netdev
In-Reply-To: <4ACEA207.7010208@np.css.fujitsu.com>
From: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Date: Fri, 09 Oct 2009 11:37:59 +0900
Please post networking patches always CC:'d to netdev@vger.kernel.org
so that it gets added to our networking patch tracking system at:
http://patchwork.ozlabs.org/project/netdev/list/
Thank you.
I've applied your fix, thanks!
> (This patch fixes bug of commit f7734fdf61ec6bb848e0bafc1fb8bad2c124bb50
> title "make TLLAO option for NA packets configurable")
>
> When the IPV6 conf is used, the function sysctl_set_parent is called and the
> array addrconf_sysctl is used as a parameter of the function.
>
> The above patch added new conf "force_tllao" into the array addrconf_sysctl,
> but the size of the array was not modified, the static allocated size is
> DEVCONF_MAX + 1 but the real size is DEVCONF_MAX + 2, so the problem is
> that the function sysctl_set_parent accessed wrong address.
>
> I got the following information.
> Call Trace:
> [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
> [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
> [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
> [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
> [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
> [<ffffffff810622d5>] __register_sysctl_paths+0xde/0x272
> [<ffffffff8110892d>] ? __kmalloc_track_caller+0x16e/0x180
> [<ffffffffa00cfac3>] ? __addrconf_sysctl_register+0xc5/0x144 [ipv6]
> [<ffffffff8141f2c9>] register_net_sysctl_table+0x48/0x4b
> [<ffffffffa00cfaf5>] __addrconf_sysctl_register+0xf7/0x144 [ipv6]
> [<ffffffffa00cfc16>] addrconf_init_net+0xd4/0x104 [ipv6]
> [<ffffffff8139195f>] setup_net+0x35/0x82
> [<ffffffff81391f6c>] copy_net_ns+0x76/0xe0
> [<ffffffff8107ad60>] create_new_namespaces+0xf0/0x16e
> [<ffffffff8107afee>] copy_namespaces+0x65/0x9f
> [<ffffffff81056dff>] copy_process+0xb2c/0x12c3
> [<ffffffff810576e1>] do_fork+0x14b/0x2d2
> [<ffffffff8107ac4e>] ? up_read+0xe/0x10
> [<ffffffff81438e73>] ? do_page_fault+0x27a/0x2aa
> [<ffffffff8101044b>] sys_clone+0x28/0x2a
> [<ffffffff81011fb3>] stub_clone+0x13/0x20
> [<ffffffff81011c72>] ? system_call_fastpath+0x16/0x1b
>
> And the information of IPV6 in .config is as following.
> IPV6 in .config:
> CONFIG_IPV6=m
> CONFIG_IPV6_PRIVACY=y
> CONFIG_IPV6_ROUTER_PREF=y
> CONFIG_IPV6_ROUTE_INFO=y
> CONFIG_IPV6_OPTIMISTIC_DAD=y
> CONFIG_IPV6_MIP6=m
> CONFIG_IPV6_SIT=m
> # CONFIG_IPV6_SIT_6RD is not set
> CONFIG_IPV6_NDISC_NODETYPE=y
> CONFIG_IPV6_TUNNEL=m
> CONFIG_IPV6_MULTIPLE_TABLES=y
> CONFIG_IPV6_SUBTREES=y
> CONFIG_IPV6_MROUTE=y
> CONFIG_IPV6_PIMSM_V2=y
> # CONFIG_IP_VS_IPV6 is not set
> CONFIG_NF_CONNTRACK_IPV6=m
> CONFIG_IP6_NF_MATCH_IPV6HEADER=m
>
> I confirmed this patch fixes this problem.
>
> Signed-off-by: Jin Dongming <jin.dongming@np.css.fujitsu.com>
> ---
> include/linux/ipv6.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> index ae74ede..5640425 100644
> --- a/include/linux/ipv6.h
> +++ b/include/linux/ipv6.h
> @@ -208,6 +208,7 @@ enum {
> DEVCONF_MC_FORWARDING,
> DEVCONF_DISABLE_IPV6,
> DEVCONF_ACCEPT_DAD,
> + DEVCONF_FORCE_TLLAO,
> DEVCONF_MAX
> };
>
> --
> 1.6.2.2
>
>
^ permalink raw reply
* RE: alt1c: ethernet driver bug
From: Jie Yang @ 2009-10-09 3:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091006161048.6b52b6be@nehalam>
Stephen Hemminger <shemminger@vyatta.com> wrote:
> Sent: Wednesday, October 07, 2009 7:11 AM
> To: Jie Yang
> Cc: netdev@vger.kernel.org
> Subject: alt1c: ethernet driver bug
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=14336
> >
> > Summary: [Pardus] Soft Lockup Problem with
> Attansic Ethernet
> > Card
> > Product: Networking
> > Version: 2.5
> > Kernel Version: 2.6.30.8
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: high
> > Priority: P1
> > Component: IPV4
> > AssignedTo: shemminger@linux-foundation.org
> > ReportedBy: badibere@gmail.com
> > Regression: No
> >
> >
> > I have soft lockup problem with attansic ethernet card while
> > activating eth0 interface.
> >
> > My ethernet card is 09:00.0 Ethernet controller: Attansic
> Technology Corp.
> > Device 1063 (rev c0)
> >
> > If I try to activate eth0 interface while network cable is
> pluged in,
> > then everything freezes.
> >
> > If I try to activate eth0 interface while network cable
> isn't pluged
> > in, then no problem. But, if i plug in, again freezes.
> >
> > My /var/log/syslog is in attachment.
> >
>
> this is what was in the bug attachment
>
> Oct 7 00:53:33 baDibere kernel: [ 16.162099] atl1c
> 0000:09:00.0: enabling device (0000 -> 0002)
> Oct 7 00:53:33 baDibere kernel: [ 16.162117] atl1c
> 0000:09:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> Oct 7 00:53:33 baDibere kernel: [ 16.162141] atl1c
> 0000:09:00.0: setting latency timer to 64
> Oct 7 00:53:33 baDibere kernel: [ 16.162247] atl1c
> 0000:09:00.0: PME# disabled
> Oct 7 00:53:33 baDibere kernel: [ 16.162266] atl1c
> 0000:09:00.0: PME# disabled
> Oct 7 00:53:33 baDibere kernel: [ 16.230835] atl1c
> 0000:09:00.0: version 1.0.0.1-NAPI
> Oct 7 00:55:57 baDibere kernel: [ 169.943463] atl1c
> 0000:09:00.0: Unable to allocate MSI interrupt Error: -22 Oct
> 7 00:55:57 baDibere kernel: [ 169.943576] atl1c
> 0000:09:00.0: atl1c: eth0 NIC Link is Up<100 Mbps Full Duplex>
>
when "pci_enable_msi" failed, I will also request_irq, so it should not be a problem.
the message "NIC Link is Up<100 Mbps Full Duplex>" demonstrate the atl1c interrupt has worked.
^ permalink raw reply
* Re: [PATCH][v2] ibm_newemac: Added 16K Tx FIFO size support for EMAC4
From: Benjamin Herrenschmidt @ 2009-10-09 2:15 UTC (permalink / raw)
To: Dave Mitchell; +Cc: netdev, linuxppc-dev
In-Reply-To: <1255019541-1974-1-git-send-email-dmitchell@appliedmicro.com>
On Thu, 2009-10-08 at 11:32 -0500, Dave Mitchell wrote:
> Some of the EMAC V4 implementations support 16K Tx FIFOs. This
> patch adds support for this functionality and fixes typos in the
> Tx FIFO size error messages.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
> Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
> Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
> Acked-by: Victor Gallardo <vgallardo@appliedmicro.com>
> Acked-by: Loc Ho <lho@appliedmicro.com>
> ---
> v1->v2: local date/time was out-of-sync and thus mail was as well
>
> drivers/net/ibm_newemac/core.c | 7 +++++--
> drivers/net/ibm_newemac/emac.h | 1 +
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
> index 89c82c5..c6591cb 100644
> --- a/drivers/net/ibm_newemac/core.c
> +++ b/drivers/net/ibm_newemac/core.c
> @@ -443,7 +443,7 @@ static u32 __emac_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_s
> ret |= EMAC_MR1_TFS_2K;
> break;
> default:
> - printk(KERN_WARNING "%s: Unknown Rx FIFO size %d\n",
> + printk(KERN_WARNING "%s: Unknown Tx FIFO size %d\n",
> dev->ndev->name, tx_size);
> }
>
> @@ -470,6 +470,9 @@ static u32 __emac4_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_
> DBG2(dev, "__emac4_calc_base_mr1" NL);
>
> switch(tx_size) {
> + case 16384:
> + ret |= EMAC4_MR1_TFS_16K;
> + break;
> case 4096:
> ret |= EMAC4_MR1_TFS_4K;
> break;
> @@ -477,7 +480,7 @@ static u32 __emac4_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_
> ret |= EMAC4_MR1_TFS_2K;
> break;
> default:
> - printk(KERN_WARNING "%s: Unknown Rx FIFO size %d\n",
> + printk(KERN_WARNING "%s: Unknown Tx FIFO size %d\n",
> dev->ndev->name, tx_size);
> }
>
> diff --git a/drivers/net/ibm_newemac/emac.h b/drivers/net/ibm_newemac/emac.h
> index 0afc2cf..d34adf9 100644
> --- a/drivers/net/ibm_newemac/emac.h
> +++ b/drivers/net/ibm_newemac/emac.h
> @@ -153,6 +153,7 @@ struct emac_regs {
> #define EMAC4_MR1_RFS_16K 0x00280000
> #define EMAC4_MR1_TFS_2K 0x00020000
> #define EMAC4_MR1_TFS_4K 0x00030000
> +#define EMAC4_MR1_TFS_16K 0x00050000
> #define EMAC4_MR1_TR 0x00008000
> #define EMAC4_MR1_MWSW_001 0x00001000
> #define EMAC4_MR1_JPSM 0x00000800
^ permalink raw reply
* Re: [PATCH] net: Fix struct sock bitfield annotation
From: Eric Dumazet @ 2009-10-09 1:46 UTC (permalink / raw)
To: David S. Miller
Cc: Vegard Nossum, Linux Netdev List, Ingo Molnar, Christoph Lameter
In-Reply-To: <4ACE8CEC.3020905@gmail.com>
Eric Dumazet a écrit :
>
> I am currently writing a tool to re-organize 'struct sock' fields,
> for net-next-2.6 using offsetof() macro, this is how I spot the problem.
>
For networking guys, here is the actual mess with "struct sock" on x86_64,
related to UDP handling (critical latencies for some people). We basically touch
all cache lines, in every paths, bad effects on SMP...
- rx softirq reception
- rx recvmsg() time
- tx sendto() time
- tx completion time
sizeof(struct sk_buff) =232 (0x e8)
sizeof(struct sock) =528 (0x210)
sizeof(struct inet_sock)=680 (0x2a8)
Following offsets in hexadecimal
offsetof(struct sock, sk_refcnt) = 10 (rw by reception of udp frame, __udp4_lib_lookup())
(unavoidable hot spot unfortunatly, but not anymore touched by sock_wfree())
offsetof(struct sock, sk_hash) = 14 (read rx softirq )
offsetof(struct sock, sk_family) = 18 (read " "
offsetof(struct inet_sock, daddr) =210 (read " "
offsetof(struct inet_sock, rcv_saddr) =214 (read " "
offsetof(struct inet_sock, dport) =218 (read " "
offsetof(struct inet_sock, mc_list) =240 (read " multicast reception
offsetof(struct sock, sk_bound_dev_if) = 1c (read rx softirq)
(First patch I'll submit is move daddr/rcv_saddr/dport to struct sock_common,
so that lookup() use one cache line instead of two per socket in hash chain)
offsetof(struct sock, sk_prot) = 30 (read by sk_has_account())
offsetof(struct sock, sk_rcvbuf) = 3c (read)
offsetof(struct sock, sk_protocol) = 39
offsetof(struct sock, sk_allocation) = e0 (read at send() time)
offsetof(struct sock, sk_flags) = f8 (read)
offsetof(struct sock, sk_lock) = 40 (rw by udp_sendmsg())
offsetof(struct sock, sk_dst_lock) = 90 (rw by udp_sendmsg() on connected socks)
offsetof(struct sock, sk_dst_cache) = 78 (read by udp_sendmsg() on connected socks)
offsetof(struct sock, sk_mark) =1d8 (read at sendto() time)
offsetof(struct sock, sk_write_queue) = c0 (rw by sendto())
offsetof(struct inet_sock, id) =232 (rw by sendto() on connected socks)
offsetof(struct sock, sk_wmem_alloc) = 98 (RW, both at sendto() and tx completion handler time)
offsetof(struct sock, sk_sndbuf) = a0 (read at tx completion time and sendto())
offsetof(struct sock, sk_sndmsg_page) =1b8 (rw by send())
offsetof(struct sock, sk_send_head) =1c0 (rw by send(), tcp)
offsetof(struct sock, sk_rmem_alloc) = 94 (RW, both when frame is received by softirq and dequeued at recvmsg() time)
offsetof(struct sock, sk_receive_queue)= a8 (RW, both when frame is received by softirq and dequeued at recvmsg() time)
offsetof(struct sock, sk_forward_alloc)= dc (rw rx softirq and recvmsg() time)
offsetof(struct sock, sk_drops) =134 (read when udp frame is received in softirq handler)
offsetof(struct sock, sk_stamp) =1a0 (write at recvmsg() time)
offsetof(struct sock, sk_sleep) = 70 (read by softirq handlers (rx/tx))
offsetof(struct sock, sk_filter) =160 (read when udp frame is received in softirq handler)
offsetof(struct sock, sk_socket) =1a8 (read)
offsetof(struct sock, sk_callback_lock)=128 (rw at softirq time
offsetof(struct sock, sk_data_ready) =1e8 (read)
offsetof(struct sock, sk_write_space) =1f0 (read at TX completion time)
used by TCP
offsetof(struct sock, sk_timer) =170
offsetof(struct sock, sk_ack_backlog) =138 (listen socks)
Almost never used
offsetof(struct sock, sk_lingertime) =100
offsetof(struct sock, sk_write_pending)=1cc
offsetof(struct sock, sk_prot_creator )=120
^ permalink raw reply
* [net-next-2.6 PATCH 2/2] ixgbe: Fix KR to KX fail over for Mezzanine cards
From: Jeff Kirsher @ 2009-10-09 1:36 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Don Skidmore, Jeff Kirsher
In-Reply-To: <20091009013530.13495.97717.stgit@localhost.localdomain>
From: Don Skidmore <donald.c.skidmore@intel.com>
This patch allows the recently added backplane device IDs that support KR
to fail over to KX during link setup. This is accomplished by the new MAC
link setup function ixgbe_setup_mac_link_smartspeed(). Comments were also
updated to better document the reason for the delays chosen for KX, KX4, BX,
BX4 and KR connections.
Signed-off-by: Don Skidmore <don.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_82599.c | 127 ++++++++++++++++++++++++++++++++++++++-
drivers/net/ixgbe/ixgbe_type.h | 10 +++
2 files changed, 134 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_82599.c b/drivers/net/ixgbe/ixgbe_82599.c
index ecb753b..ae27c41 100644
--- a/drivers/net/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ixgbe/ixgbe_82599.c
@@ -42,6 +42,10 @@ s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw *hw,
ixgbe_link_speed speed,
bool autoneg,
bool autoneg_wait_to_complete);
+static s32 ixgbe_setup_mac_link_smartspeed(struct ixgbe_hw *hw,
+ ixgbe_link_speed speed,
+ bool autoneg,
+ bool autoneg_wait_to_complete);
s32 ixgbe_start_mac_link_82599(struct ixgbe_hw *hw,
bool autoneg_wait_to_complete);
s32 ixgbe_setup_mac_link_82599(struct ixgbe_hw *hw,
@@ -64,7 +68,13 @@ static void ixgbe_init_mac_link_ops_82599(struct ixgbe_hw *hw)
/* Set up dual speed SFP+ support */
mac->ops.setup_link = &ixgbe_setup_mac_link_multispeed_fiber;
} else {
- mac->ops.setup_link = &ixgbe_setup_mac_link_82599;
+ if ((mac->ops.get_media_type(hw) ==
+ ixgbe_media_type_backplane) &&
+ (hw->phy.smart_speed == ixgbe_smart_speed_auto ||
+ hw->phy.smart_speed == ixgbe_smart_speed_on))
+ mac->ops.setup_link = &ixgbe_setup_mac_link_smartspeed;
+ else
+ mac->ops.setup_link = &ixgbe_setup_mac_link_82599;
}
}
@@ -480,7 +490,12 @@ s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw *hw,
hw->mac.autotry_restart = false;
}
- /* The controller may take up to 500ms at 10g to acquire link */
+ /*
+ * Wait for the controller to acquire link. Per IEEE 802.3ap,
+ * Section 73.10.2, we may have to wait up to 500ms if KR is
+ * attempted. 82599 uses the same timing for 10g SFI.
+ */
+
for (i = 0; i < 5; i++) {
/* Wait for the link partner to also set speed */
msleep(100);
@@ -568,6 +583,111 @@ out:
}
/**
+ * ixgbe_setup_mac_link_smartspeed - Set MAC link speed using SmartSpeed
+ * @hw: pointer to hardware structure
+ * @speed: new link speed
+ * @autoneg: true if autonegotiation enabled
+ * @autoneg_wait_to_complete: true when waiting for completion is needed
+ *
+ * Implements the Intel SmartSpeed algorithm.
+ **/
+static s32 ixgbe_setup_mac_link_smartspeed(struct ixgbe_hw *hw,
+ ixgbe_link_speed speed, bool autoneg,
+ bool autoneg_wait_to_complete)
+{
+ s32 status = 0;
+ ixgbe_link_speed link_speed;
+ s32 i, j;
+ bool link_up = false;
+ u32 autoc_reg = IXGBE_READ_REG(hw, IXGBE_AUTOC);
+
+ hw_dbg(hw, "ixgbe_setup_mac_link_smartspeed.\n");
+
+ /* Set autoneg_advertised value based on input link speed */
+ hw->phy.autoneg_advertised = 0;
+
+ if (speed & IXGBE_LINK_SPEED_10GB_FULL)
+ hw->phy.autoneg_advertised |= IXGBE_LINK_SPEED_10GB_FULL;
+
+ if (speed & IXGBE_LINK_SPEED_1GB_FULL)
+ hw->phy.autoneg_advertised |= IXGBE_LINK_SPEED_1GB_FULL;
+
+ if (speed & IXGBE_LINK_SPEED_100_FULL)
+ hw->phy.autoneg_advertised |= IXGBE_LINK_SPEED_100_FULL;
+
+ /*
+ * Implement Intel SmartSpeed algorithm. SmartSpeed will reduce the
+ * autoneg advertisement if link is unable to be established at the
+ * highest negotiated rate. This can sometimes happen due to integrity
+ * issues with the physical media connection.
+ */
+
+ /* First, try to get link with full advertisement */
+ hw->phy.smart_speed_active = false;
+ for (j = 0; j < IXGBE_SMARTSPEED_MAX_RETRIES; j++) {
+ status = ixgbe_setup_mac_link_82599(hw, speed, autoneg,
+ autoneg_wait_to_complete);
+ if (status)
+ goto out;
+
+ /*
+ * Wait for the controller to acquire link. Per IEEE 802.3ap,
+ * Section 73.10.2, we may have to wait up to 500ms if KR is
+ * attempted, or 200ms if KX/KX4/BX/BX4 is attempted, per
+ * Table 9 in the AN MAS.
+ */
+ for (i = 0; i < 5; i++) {
+ mdelay(100);
+
+ /* If we have link, just jump out */
+ hw->mac.ops.check_link(hw, &link_speed,
+ &link_up, false);
+ if (link_up)
+ goto out;
+ }
+ }
+
+ /*
+ * We didn't get link. If we advertised KR plus one of KX4/KX
+ * (or BX4/BX), then disable KR and try again.
+ */
+ if (((autoc_reg & IXGBE_AUTOC_KR_SUPP) == 0) ||
+ ((autoc_reg & IXGBE_AUTOC_KX4_KX_SUPP_MASK) == 0))
+ goto out;
+
+ /* Turn SmartSpeed on to disable KR support */
+ hw->phy.smart_speed_active = true;
+ status = ixgbe_setup_mac_link_82599(hw, speed, autoneg,
+ autoneg_wait_to_complete);
+ if (status)
+ goto out;
+
+ /*
+ * Wait for the controller to acquire link. 600ms will allow for
+ * the AN link_fail_inhibit_timer as well for multiple cycles of
+ * parallel detect, both 10g and 1g. This allows for the maximum
+ * connect attempts as defined in the AN MAS table 73-7.
+ */
+ for (i = 0; i < 6; i++) {
+ mdelay(100);
+
+ /* If we have link, just jump out */
+ hw->mac.ops.check_link(hw, &link_speed,
+ &link_up, false);
+ if (link_up)
+ goto out;
+ }
+
+ /* We didn't get link. Turn SmartSpeed back off. */
+ hw->phy.smart_speed_active = false;
+ status = ixgbe_setup_mac_link_82599(hw, speed, autoneg,
+ autoneg_wait_to_complete);
+
+out:
+ return status;
+}
+
+/**
* ixgbe_check_mac_link_82599 - Determine link and speed status
* @hw: pointer to hardware structure
* @speed: pointer to link speed
@@ -670,7 +790,8 @@ s32 ixgbe_setup_mac_link_82599(struct ixgbe_hw *hw,
if (speed & IXGBE_LINK_SPEED_10GB_FULL)
if (orig_autoc & IXGBE_AUTOC_KX4_SUPP)
autoc |= IXGBE_AUTOC_KX4_SUPP;
- if (orig_autoc & IXGBE_AUTOC_KR_SUPP)
+ if ((orig_autoc & IXGBE_AUTOC_KR_SUPP) &&
+ (hw->phy.smart_speed_active == false))
autoc |= IXGBE_AUTOC_KR_SUPP;
if (speed & IXGBE_LINK_SPEED_1GB_FULL)
autoc |= IXGBE_AUTOC_KX_SUPP;
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index 42232b1..1cab53e 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -2172,6 +2172,14 @@ enum ixgbe_fc_mode {
ixgbe_fc_default
};
+/* Smart Speed Settings */
+#define IXGBE_SMARTSPEED_MAX_RETRIES 3
+enum ixgbe_smart_speed {
+ ixgbe_smart_speed_auto = 0,
+ ixgbe_smart_speed_on,
+ ixgbe_smart_speed_off
+};
+
/* PCI bus types */
enum ixgbe_bus_type {
ixgbe_bus_type_unknown = 0,
@@ -2432,6 +2440,8 @@ struct ixgbe_phy_info {
enum ixgbe_media_type media_type;
bool reset_disable;
ixgbe_autoneg_advertised autoneg_advertised;
+ enum ixgbe_smart_speed smart_speed;
+ bool smart_speed_active;
bool multispeed_fiber;
};
^ permalink raw reply related
* [net-next-2.6 PATCH 1/2] ixgbe: add support for 82599 based Express Module X520-P2
From: Jeff Kirsher @ 2009-10-09 1:35 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Don Skidmore, Peter P Waskiewicz Jr, Jeff Kirsher
From: Don Skidmore <donald.c.skidmore@intel.com>
This patch will add the device ID for the 82599-based Ethernet
Express Module X520-P2 SFI card.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_82599.c | 1 +
drivers/net/ixgbe/ixgbe_main.c | 2 ++
drivers/net/ixgbe/ixgbe_type.h | 1 +
3 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_82599.c b/drivers/net/ixgbe/ixgbe_82599.c
index 34b0492..ecb753b 100644
--- a/drivers/net/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ixgbe/ixgbe_82599.c
@@ -337,6 +337,7 @@ static enum ixgbe_media_type ixgbe_get_media_type_82599(struct ixgbe_hw *hw)
media_type = ixgbe_media_type_backplane;
break;
case IXGBE_DEV_ID_82599_SFP:
+ case IXGBE_DEV_ID_82599_SFP_EM:
media_type = ixgbe_media_type_fiber;
break;
case IXGBE_DEV_ID_82599_CX4:
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index cbb143c..56da100 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -97,6 +97,8 @@ static struct pci_device_id ixgbe_pci_tbl[] = {
board_82599 },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_SFP),
board_82599 },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_SFP_EM),
+ board_82599 },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_KX4_MEZZ),
board_82599 },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_CX4),
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index ef4bdd5..42232b1 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -52,6 +52,7 @@
#define IXGBE_DEV_ID_82599_KX4_MEZZ 0x1514
#define IXGBE_DEV_ID_82599_CX4 0x10F9
#define IXGBE_DEV_ID_82599_SFP 0x10FB
+#define IXGBE_DEV_ID_82599_SFP_EM 0x1507
#define IXGBE_DEV_ID_82599_XAUI_LOM 0x10FC
#define IXGBE_DEV_ID_82599_COMBO_BACKPLANE 0x10F8
^ permalink raw reply related
* Re: [PATCH] net: Fix struct sock bitfield annotation
From: Eric Dumazet @ 2009-10-09 1:07 UTC (permalink / raw)
To: Vegard Nossum; +Cc: David S. Miller, Linux Netdev List, Ingo Molnar
In-Reply-To: <19f34abd0910081454v51455ee0p30ad6715b5ee31c0@mail.gmail.com>
Vegard Nossum a écrit :
> Hm, no, this looks wrong to me, because sk_protocol and sk_type
> _aren't_ in fact part of the bitfield.
What looks wrong to me is the original commit :)
>
> We don't want to affect the kernel _at all_ when CONFIG_KMEMCHECK=n,
> so I guess we should make the kmemcheck_bitfield_{begin|end}() macros
> empty instead for that case? (And for kmemcheck kernels, we don't
> really care about the lost 8 bytes anyway.)
Point is we should not lose 8 bytes with kmemcheck on or off.
I believe kmemcheck macros are fine as they are.
When we have a structure with
unsigned char sk_shutdown : 2,
sk_no_check : 2,
sk_userlocks : 4;
unsigned char sk_protocol;
unsigned short sk_type;
Its pretty clear its *logically* a bitfield aggregation, or if you prefer :
unsigned int sk_shutdown : 2,
sk_no_check : 2,
sk_userlocks : 4,
sk_protocol : 8,
sk_type : 16;
Only difference is that in the second form, you cannot use
offsetof(struct sock, sk_type)
I am currently writing a tool to re-organize 'struct sock' fields,
for net-next-2.6 using offsetof() macro, this is how I spot the problem.
Thanks
^ permalink raw reply
* Re: using huge numbers of queues
From: Herbert Xu @ 2009-10-09 1:02 UTC (permalink / raw)
To: Andrew Grover; +Cc: netdev
In-Reply-To: <c0a09e5c0910071459r2768f420lae87f7404dfbc054@mail.gmail.com>
On Wed, Oct 07, 2009 at 02:59:49PM -0700, Andrew Grover wrote:
>
> Thinking about this reminded me of VJ's 2006 netchannel concept, which
> although not adopted, was pretty interesting. Would having 1 queue per
> socket (or at least 1 per process) and hw that is able to filter
> individual flows (I think the Intel 82599 can do this now for up to
> 128) perhaps make netchannels workable? At least this would get all
> processing out of int/bh and into process context, if not userspace,
> no?
This is exactly right. Having one socket per queue would allow
the netchannel concept to become reality without compromising
features such as netfilter.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: David Miller @ 2009-10-09 1:01 UTC (permalink / raw)
To: mb-fseUSCV1ubazQB+pC5nmwQ
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200910090108.08838.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
From: Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
Date: Fri, 9 Oct 2009 01:08:06 +0200
> I was planning to do a better solution, but I didn't have the time, yet.
The change is harmless while we're twiddling our thumbs waiting
for you to implement the fix "properly."
Not having the fix in is a developer burdon because people turn
on the DMA API debugger and are going to keep reporting it's
complaints here and elsewhere.
Get over your Napoleon complex, and let reasonable working fixes
get into the tree even if you don't find them optimal. You can
always improve them later, "when you get around to it."
People put fixes in without my ACK in my areas of expertiece all
the time. I got over it a long time ago, it's OK, and not worth
stressing out over.
Thanks.
--
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
* Re: Kernel oops when clearing bgp neighbor info with TCP MD5SUM enabled
From: David Miller @ 2009-10-09 0:57 UTC (permalink / raw)
To: asinha; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0910081622400.18315@sleet.zeugmasystems.local>
From: Anirban Sinha <asinha@zeugmasystems.com>
Date: Thu, 8 Oct 2009 16:33:47 -0700 (PDT)
> Hi:
>
> Thanks for responding.
>
>> > We are noticing a kernel OOPS on 2.6.26 kernel when we issue the command
>> > "clear ip bgp <bgp-peer-ip>" on Quagga BGP routing software.
>>
>> You will need to update your kernel, there have been many TCP
>> MD5 bug fixes since 2.6.26
>>
>
> Sigh ... wish that were that easy!
Contact your vendor for support :-)
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: David Miller @ 2009-10-09 0:55 UTC (permalink / raw)
To: mb; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <200910090116.46513.mb@bu3sch.de>
From: Michael Buesch <mb@bu3sch.de>
Date: Fri, 9 Oct 2009 01:16:44 +0200
> And there's no reason to rush this fix into mainline.
I think it's worthwhile because people turn the DMA API debugger on
and it's going to spit out warnings that "don't matter" until you guys
fix this.
I looked at the patch you guys are so up in arms about, and frankly it
looks perfectly fine to me.
If you want to implement the fix "perfectly", and "to your standards",
then fine. But do it in net-next-2.6 as a follow-on patch to this
one.
I'm not undoing John's pull request just for this. :-)
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: David Miller @ 2009-10-09 0:52 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091008223454.GB2798-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Thu, 8 Oct 2009 18:34:54 -0400
> Here is another batch of fixes intended for 2.6.32. Most of them are
> short, self-contained and more-or-less obvious. Most of them have been
> baking in -next for several days.
>
> The b43 patch from Albert Herranz looks big, but most of it is moving a
> structure definition within a header file. It also changes some DMA
> buffers from stack to heap allocation.
>
> 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
* Re: [BUG net-2.6] bluetooth/rfcomm : sleeping function called from invalid context at mm/slub.c:1719
From: Dave Young @ 2009-10-09 0:44 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Oliver Hartkopp, Marcel Holtmann, Linux Netdev List,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Gustavo F. Padovan
In-Reply-To: <20091004180635.GA11272@vigoh>
On Sun, Oct 04, 2009 at 06:06:35PM +0000, Gustavo F. Padovan wrote:
>
> Hi all,
>
> * Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [2009-10-04 11:26:17 +0800]:
>
> >
> > I can reproduce the bug.
> >
> > It's probably caused by the l2cap changes by Gustavo F. Padovan
> > <gustavo-r7biftawOlEmmTcpzmvVSFAUjnlXr6A1@public.gmane.org>, I didn't see such problem after reverting
> > Gustavo's patch series.
>
> I can't reproduce the bug. I'm trying to reproduce it to figure out what of
> my changes cause it.
>
> I' running
>
> $ dund -snu -i 00:11:67:CD:0F:CB # to pretend to be dialup/telephone
>
> and on the other side
>
> $ rfcomm bind 0 00:11:67:CD:0F:CB 1
> $ wvdial # wvdial to /dev/rfcomm0
>
> Both sides are on the same machine. Do you see any real difference
> between my try and the call that get the bug?
>
Hi oliver
Could try following patch?
---
When shutdown ppp connection, lockdep waring about non-static key
will happen, it is caused by the lock is not initialized properly
at that time.
Fix with tuning the lock/skb_queue_head init order
[ 94.339261] INFO: trying to register non-static key.
[ 94.342509] the code is fine but needs lockdep annotation.
[ 94.342509] turning off the locking correctness validator.
[ 94.342509] Pid: 0, comm: swapper Not tainted 2.6.31-mm1 #2
[ 94.342509] Call Trace:
[ 94.342509] [<c0248fbe>] register_lock_class+0x58/0x241
[ 94.342509] [<c024b5df>] ? __lock_acquire+0xb57/0xb73
[ 94.342509] [<c024ab34>] __lock_acquire+0xac/0xb73
[ 94.342509] [<c024b7fa>] ? lock_release_non_nested+0x17b/0x1de
[ 94.342509] [<c024b662>] lock_acquire+0x67/0x84
[ 94.342509] [<c04cd1eb>] ? skb_dequeue+0x15/0x41
[ 94.342509] [<c054a857>] _spin_lock_irqsave+0x2f/0x3f
[ 94.342509] [<c04cd1eb>] ? skb_dequeue+0x15/0x41
[ 94.342509] [<c04cd1eb>] skb_dequeue+0x15/0x41
[ 94.342509] [<c054a648>] ? _read_unlock+0x1d/0x20
[ 94.342509] [<c04cd641>] skb_queue_purge+0x14/0x1b
[ 94.342509] [<fab94fdc>] l2cap_recv_frame+0xea1/0x115a [l2cap]
[ 94.342509] [<c024b5df>] ? __lock_acquire+0xb57/0xb73
[ 94.342509] [<c0249c04>] ? mark_lock+0x1e/0x1c7
[ 94.342509] [<f8364963>] ? hci_rx_task+0xd2/0x1bc [bluetooth]
[ 94.342509] [<fab95346>] l2cap_recv_acldata+0xb1/0x1c6 [l2cap]
[ 94.342509] [<f8364997>] hci_rx_task+0x106/0x1bc [bluetooth]
[ 94.342509] [<fab95295>] ? l2cap_recv_acldata+0x0/0x1c6 [l2cap]
[ 94.342509] [<c02302c4>] tasklet_action+0x69/0xc1
[ 94.342509] [<c022fbef>] __do_softirq+0x94/0x11e
[ 94.342509] [<c022fcaf>] do_softirq+0x36/0x5a
[ 94.342509] [<c022fe14>] irq_exit+0x35/0x68
[ 94.342509] [<c0204ced>] do_IRQ+0x72/0x89
[ 94.342509] [<c02038ee>] common_interrupt+0x2e/0x34
[ 94.342509] [<c024007b>] ? pm_qos_add_requirement+0x63/0x9d
[ 94.342509] [<c038e8a5>] ? acpi_idle_enter_bm+0x209/0x238
[ 94.342509] [<c049d238>] cpuidle_idle_call+0x5c/0x94
[ 94.342509] [<c02023f8>] cpu_idle+0x4e/0x6f
[ 94.342509] [<c0534153>] rest_init+0x53/0x55
[ 94.342509] [<c0781894>] start_kernel+0x2f0/0x2f5
[ 94.342509] [<c0781091>] i386_start_kernel+0x91/0x96
Reported-by: Oliver Hartkopp <oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Signed-off-by: Dave Young <hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/bluetooth/l2cap.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- linux-2.6.31.orig/net/bluetooth/l2cap.c 2009-10-09 08:32:46.000000000 +0800
+++ linux-2.6.31/net/bluetooth/l2cap.c 2009-10-09 08:33:57.000000000 +0800
@@ -555,12 +555,12 @@ static struct l2cap_conn *l2cap_conn_add
conn->feat_mask = 0;
- setup_timer(&conn->info_timer, l2cap_info_timeout,
- (unsigned long) conn);
-
spin_lock_init(&conn->lock);
rwlock_init(&conn->chan_list.lock);
+ setup_timer(&conn->info_timer, l2cap_info_timeout,
+ (unsigned long) conn);
+
conn->disc_reason = 0x13;
return conn;
@@ -783,6 +783,9 @@ static void l2cap_sock_init(struct sock
/* Default config options */
pi->conf_len = 0;
pi->flush_to = L2CAP_DEFAULT_FLUSH_TO;
+ skb_queue_head_init(TX_QUEUE(sk));
+ skb_queue_head_init(SREJ_QUEUE(sk));
+ INIT_LIST_HEAD(SREJ_LIST(sk));
}
static struct proto l2cap_proto = {
^ permalink raw reply
* Re: Kernel oops when clearing bgp neighbor info with TCP MD5SUM enabled
From: Anirban Sinha @ 2009-10-08 23:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091008.155429.02850661.davem@davemloft.net>
Hi:
Thanks for responding.
> > We are noticing a kernel OOPS on 2.6.26 kernel when we issue the command
> > "clear ip bgp <bgp-peer-ip>" on Quagga BGP routing software.
>
> You will need to update your kernel, there have been many TCP
> MD5 bug fixes since 2.6.26
>
Sigh ... wish that were that easy! Anyway, as far as I could, I have tried to
apply the upstream patches that seemed relevant to TCP MD5SUM. Am I missing
some other patches? It will be great if someone can point me to any patch that
I might be missing related to the TCP MD5SUM support.
I applied the following patches:
(a)
author Adam Langley <agl@imperialviolet.org>
Sat, 19 Jul 2008 07:01:42 +0000 (00:01 -0700)
committer David S. Miller <davem@davemloft.net>
Sat, 19 Jul 2008 07:01:42 +0000 (00:01 -0700)
commit 49a72dfb8814c2d65bd9f8c9c6daf6395a1ec58d
tree 38804d609f21503573bbdd8bb9af38df99275ff5 tree | snapshot
parent 845525a642c1c9e1335c33a274d4273906ee58eb commit | diff
tcp: Fix MD5 signatures for non-linear skbs
Currently, the MD5 code assumes that the SKBs are linear and, in the case
that they aren't, happily goes off and hashes off the end of the SKB and
into random memory.
Reported by Stephen Hemminger in [1]. Advice thanks to Stephen and Evgeniy
Polyakov. Also includes a couple of missed route_caps from Stephen's patch
in [2].
[1] http://marc.info/?l=linux-netdev&m=121445989106145&w=2
[2] http://marc.info/?l=linux-netdev&m=121459157816964&w=2
Signed-off-by: Adam Langley <agl@imperialviolet.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(b)
author YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Fri, 18 Apr 2008 03:45:16 +0000 (12:45 +0900)
committer YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Wed, 11 Jun 2008 18:46:30 +0000 (03:46 +0900)
commit 9501f9722922f2e80e1f9dc6682311d65c2b5690
tree ca8195e04ea63e8273801030ce26527fe5a8a7c7 tree | snapshot
parent 8d26d76dd4a4c87ef037a44a42a0608ffc730199 commit | diff
tcp md5sig: Let the caller pass appropriate key for
tcp_v{4,6}_do_calc_md5_hash().
As we do for other socket/timewait-socket specific parameters,
let the callers pass appropriate arguments to
tcp_v{4,6}_do_calc_md5_hash().
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
(c)
author YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Thu, 17 Apr 2008 04:19:16 +0000 (13:19 +0900)
committer YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Wed, 11 Jun 2008 17:38:20 +0000 (02:38 +0900)
commit 8d26d76dd4a4c87ef037a44a42a0608ffc730199
tree 884ff53a83e460aa3f1837cc336a5a34f364156e tree | snapshot
parent 076fb7223357769c39f3ddf900bba6752369c76a commit | diff
tcp md5sig: Share most of hash calcucaltion bits between IPv4 and IPv6.
We can share most part of the hash calculation code because
the only difference between IPv4 and IPv6 is their pseudo headers.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
(d)
author YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Thu, 17 Apr 2008 03:48:12 +0000 (12:48 +0900)
committer YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Wed, 11 Jun 2008 17:38:19 +0000 (02:38 +0900)
commit 076fb7223357769c39f3ddf900bba6752369c76a
tree db75c2af3bf71cda4d0cccd6ebcfa8d1a62c3620 tree | snapshot
parent 7d5d5525bd88313e6fd90c0659665aee5114bc2d commit | diff
tcp md5sig: Remove redundant protocol argument.
Protocol is always TCP, so remove useless protocol argument.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
(e)
author YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Thu, 17 Apr 2008 03:29:53 +0000 (12:29 +0900)
committer YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Wed, 11 Jun 2008 17:38:18 +0000 (02:38 +0900)
commit 7d5d5525bd88313e6fd90c0659665aee5114bc2d
tree 41517e753220261c8cc46d975977cfd711892f6c tree | snapshot
parent 81b302a321a0d99ff172b8cb2a8de17bff2f9499 commit | diff
tcp md5sig: Share MD5 Signature option parser between IPv4 and IPv6.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cheers,
Ani
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: Michael Buesch @ 2009-10-08 23:16 UTC (permalink / raw)
To: John W. Linville
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200910090108.08838.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
On Friday 09 October 2009 01:08:06 Michael Buesch wrote:
> On Friday 09 October 2009 00:34:54 John W. Linville wrote:
> > Albert Herranz (1):
> > b43: do not stack-allocate pio rx/tx header and tail buffers
>
> Come on, this is _not_ funny anymore. I did _not_ ack this patch, because I do _not_ like it.
> I was planning to do a better solution, but I didn't have the time, yet.
> Can you _please_ either:
> - Wait for my ack before you apply random b43 patches
> or
> - Remove me from MAINTAINERS
>
And there's no reason to rush this fix into mainline. We currently do not even
have a supported device which would require this fix. The Wii, which uses the SDIO bus,
does not require this fix. So the only supported device (as of now) does not need the fix
to work properly.
So it can as well go into the next merge window.
--
Greetings, Michael.
--
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
* Re: pull request: wireless-2.6 2009-10-08
From: Michael Buesch @ 2009-10-08 23:08 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091008223454.GB2798@tuxdriver.com>
On Friday 09 October 2009 00:34:54 John W. Linville wrote:
> Albert Herranz (1):
> b43: do not stack-allocate pio rx/tx header and tail buffers
Come on, this is _not_ funny anymore. I did _not_ ack this patch, because I do _not_ like it.
I was planning to do a better solution, but I didn't have the time, yet.
Can you _please_ either:
- Wait for my ack before you apply random b43 patches
or
- Remove me from MAINTAINERS
--
Greetings, Michael.
^ permalink raw reply
* Re: Kernel oops when clearing bgp neighbor info with TCP MD5SUM enabled
From: David Miller @ 2009-10-08 22:54 UTC (permalink / raw)
To: asinha; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0910081514050.18315@sleet.zeugmasystems.local>
From: Anirban Sinha <asinha@zeugmasystems.com>
Date: Thu, 8 Oct 2009 15:19:48 -0700 (PDT)
> We are noticing a kernel OOPS on 2.6.26 kernel when we issue the command
> "clear ip bgp <bgp-peer-ip>" on Quagga BGP routing software.
You will need to update your kernel, there have been many TCP
MD5 bug fixes since 2.6.26
^ 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