* Re: [PATCH] UDPCP Communication Protocol
From: Jesper Juhl @ 2011-01-10 22:53 UTC (permalink / raw)
To: stefani; +Cc: linux-kernel, akpm, davem, netdev
In-Reply-To: <1293787785-3834-1-git-send-email-stefani@seibold.net>
stefani@seibold.net wrote:
+static int udpcp_xmit(struct sock *sk, struct udpcp_dest *dest)
+{
+ struct udpcp_sock *usk = udpcp_sk(sk);
+ int ret;
+
+ ret = _udpcp_xmit(sk, dest);
+
+ if (dest->xmit_wait) {
+ dest->tx_time = jiffies;
+
+ if (!timer_pending(&usk->timer))
+ udpcp_timer(sk, dest->tx_time + usk->tx_timeout);
+ }
+ return ret;
+}
Wouldn't this be slightly nicer as
static int udpcp_xmit(struct sock *sk, struct udpcp_dest *dest)
{
int ret = _udpcp_xmit(sk, dest);
if (dest->xmit_wait) {
struct udpcp_sock *usk = udpcp_sk(sk);
dest->tx_time = jiffies;
if (!timer_pending(&usk->timer))
udpcp_timer(sk, dest->tx_time + usk->tx_timeout);
}
return ret;
}
??
--
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: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
From: Dave, Tushar N @ 2011-01-10 23:11 UTC (permalink / raw)
To: Chris Rankin, e1000-devel@lists.sourceforge.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <913138.52057.qm@web121710.mail.ne1.yahoo.com>
Chris,
Sorry to hear that you have the issue.
Does the issue appears only when you add a bridge?
Thanks.
-Tushar
-----Original Message-----
From: Chris Rankin [mailto:rankincj@yahoo.com]
Sent: Saturday, January 08, 2011 4:54 AM
To: e1000-devel@lists.sourceforge.net
Cc: netdev@vger.kernel.org
Subject: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
Hi,
I've just booted 2.6.36.3 on my old router box (which contains one single e100 card, and one dual-port e100 card), and have discovered this rather scary message in the dmesg log:
e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100 0000:00:0f.0: PME# disabled
e100 0000:00:0f.0: eth0: addr 0xffbeb000, irq 10, MAC addr 00:90:27:76:d0:ec
e100 0000:01:04.0: PME# disabled
e100 0000:01:04.0: eth1: addr 0xff0fe000, irq 11, MAC addr 00:03:47:3b:29:5c
e100 0000:01:05.0: PME# disabled
e100 0000:01:05.0: eth2: addr 0xff0ff000, irq 10, MAC addr 00:03:47:3b:29:5d
...
device eth1 entered promiscuous mode
ADDRCONF(NETDEV_UP): eth1: link is not ready
e100 0000:01:04.0: eth1: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
device eth2 entered promiscuous mode
ADDRCONF(NETDEV_UP): eth2: link is not ready
br0: port 1(eth1) entering learning state
br0: port 1(eth1) entering learning state
ifconfig: page allocation failure. order:6, mode:0x8020
Pid: 3716, comm: ifconfig Not tainted 2.6.36.3 #1
Call Trace:
[<c104b2a9>] ? __alloc_pages_nodemask+0x477/0x4a6
[<c106177d>] ? __slab_alloc+0x1eb/0x396
[<c1004ca6>] ? dma_generic_alloc_coherent+0x4e/0xac
[<c105fb5c>] ? dma_pool_alloc+0xe5/0x1d9
[<c1004c58>] ? dma_generic_alloc_coherent+0x0/0xac
[<c58f97f3>] ? e100_rx_alloc_skb+0x87/0x122 [e100]
[<c58f9883>] ? e100_rx_alloc_skb+0x117/0x122 [e100]
[<c58f98dc>] ? e100_alloc_cbs+0x4e/0xfa [e100]
[<c58fb370>] ? e100_up+0x1b/0xf1 [e100]
[<c58fb45d>] ? e100_open+0x17/0x3b [e100]
[<c1121630>] ? __dev_open+0x7c/0xa0
[<c11217ed>] ? __dev_change_flags+0x8b/0x100
[<c11218c3>] ? dev_change_flags+0x10/0x3b
[<c1159880>] ? devinet_ioctl+0x25a/0x532
[<c11146d2>] ? sock_ioctl+0x1a8/0x1ca
[<c111452a>] ? sock_ioctl+0x0/0x1ca
[<c106e061>] ? do_vfs_ioctl+0x464/0x4a2
[<c1014ce0>] ? do_page_fault+0x2d2/0x2ea
[<c1014cc8>] ? do_page_fault+0x2ba/0x2ea
[<c10636f6>] ? sys_faccessat+0x144/0x151
[<c106e0cc>] ? sys_ioctl+0x2d/0x49
[<c1177dd5>] ? syscall_call+0x7/0xb
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: hi: 6, btch: 1 usd: 0
active_anon:280 inactive_anon:808 isolated_anon:0
active_file:1384 inactive_file:9672 isolated_file:0
unevictable:0 dirty:77 writeback:0 unstable:0
free:753 slab_reclaimable:499 slab_unreclaimable:1393
mapped:375 shmem:643 pagetables:59 bounce:0
DMA free:1492kB min:248kB low:308kB high:372kB active_anon:0kB inactive_anon:12kB active_file:288kB inactive_file:12548kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15864kB mlocked:0kB dirty:48kB writeback:0kB mapped:28kB shmem:0kB slab_reclaimable:312kB slab_unreclaimable:884kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 47 47
Normal free:1520kB min:764kB low:952kB high:1144kB active_anon:1120kB inactive_anon:3220kB active_file:5248kB inactive_file:26140kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:48768kB mlocked:0kB dirty:260kB writeback:0kB mapped:1472kB shmem:2572kB slab_reclaimable:1684kB slab_unreclaimable:4688kB kernel_stack:176kB pagetables:236kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 51*4kB 23*8kB 3*16kB 3*32kB 7*64kB 4*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1492kB
Normal: 260*4kB 26*8kB 1*16kB 0*32kB 0*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1520kB
11715 total pagecache pages
16 pages in swap cache
Swap cache stats: add 44, delete 28, find 72/72
Free swap = 2179532kB
Total swap = 2179596kB
16383 pages RAM
826 pages reserved
10736 pages shared
5361 pages non-shared
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100 0000:00:0f.0: eth0: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
br0: port 1(eth1) entering forwarding state
Should I be concerned, please? All three e100 devices still appear to be working, but something nasty seems to have happened anyway.
The lspci output for these devices is:
00:0f.0 0200: 8086:1229 (rev 08)
Subsystem: 8086:000c
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 10
Region 0: Memory at ffbeb000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at ef00 [size=64]
Region 2: Memory at fef00000 (32-bit, non-prefetchable) [size=1M]
[virtual] Expansion ROM at 04000000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: e100
Kernel modules: e100
01:04.0 0200: 8086:1229 (rev 05)
Subsystem: 8086:10f0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ff0fe000 (32-bit, prefetchable) [size=4K]
Region 1: I/O ports at fcc0 [size=32]
Region 2: Memory at ff700000 (32-bit, non-prefetchable) [size=1M]
[virtual] Expansion ROM at ff100000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: e100
Kernel modules: e100
01:05.0 0200: 8086:1229 (rev 05)
Subsystem: 8086:10f0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 10
Region 0: Memory at ff0ff000 (32-bit, prefetchable) [size=4K]
Region 1: I/O ports at fce0 [size=32]
Region 2: Memory at ff900000 (32-bit, non-prefetchable) [size=1M]
[virtual] Expansion ROM at ff200000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: e100
Kernel modules: e100
Thanks,
Chris
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH] cxgb3i: fixed connection problem with iscsi private ip
From: kxie @ 2011-01-10 23:15 UTC (permalink / raw)
To: netdev, linux-scsi, open-iscsi; +Cc: kxie, davem, James.Bottomley, michaelc
[PATCH] cxgb3i: fixed connection problem with iscsi private ip
From: Karen Xie <kxie@chelsio.com>
fixed the connection problem when the private iscsi ipv4 address is provisioned on the interface.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb3i/cxgb3i.h | 18 ++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
index 5f5e339..bed14db 100644
--- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
+++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
@@ -24,10 +24,20 @@
extern cxgb3_cpl_handler_func cxgb3i_cpl_handlers[NUM_CPL_CMDS];
-#define cxgb3i_get_private_ipv4addr(ndev) \
- (((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr)
-#define cxgb3i_set_private_ipv4addr(ndev, addr) \
- (((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr) = addr
+static inline unsigned int cxgb3i_get_private_ipv4addr(struct net_device *ndev)
+{
+ return ((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr;
+}
+
+static inline void cxgb3i_set_private_ipv4addr(struct net_device *ndev,
+ unsigned int addr)
+{
+ struct port_info *pi = (struct port_info *)netdev_priv(ndev);
+
+ pi->iscsic.flags = addr ? 1 : 0;
+ pi->iscsi_ipv4addr = addr;
+ if (addr)
+ memcpy(pi->iscsic.mac_addr, ndev->dev_addr, ETH_ALEN);
+}
struct cpl_iscsi_hdr_norss {
union opcode_tid ot;
^ permalink raw reply related
* [PATCH] caif: don't set connection request param size before copying data
From: Dan Rosenberg @ 2011-01-10 23:36 UTC (permalink / raw)
To: Sjur Braendeland, David S. Miller; +Cc: netdev
The size field should not be set until after the data is successfully
copied in.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
---
net/caif/caif_socket.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index 1bf0cf5..8184c03 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -740,12 +740,12 @@ static int setsockopt(struct socket *sock,
if (cf_sk->sk.sk_protocol != CAIFPROTO_UTIL)
return -ENOPROTOOPT;
lock_sock(&(cf_sk->sk));
- cf_sk->conn_req.param.size = ol;
if (ol > sizeof(cf_sk->conn_req.param.data) ||
copy_from_user(&cf_sk->conn_req.param.data, ov, ol)) {
release_sock(&cf_sk->sk);
return -EINVAL;
}
+ cf_sk->conn_req.param.size = ol;
release_sock(&cf_sk->sk);
return 0;
^ permalink raw reply related
* RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
From: Chris Rankin @ 2011-01-10 23:41 UTC (permalink / raw)
To: e1000-devel@lists.sourceforge.net, Tushar NDave; +Cc: netdev@vger.kernel.org
In-Reply-To: <F675EE07F28A0A4E933E5F9DD28672FB01197E08E2@orsmsx508.amr.corp.intel.com>
--- On Mon, 10/1/11, Dave, Tushar N <tushar.n.dave@intel.com> wrote:
> Does the issue appears only when you add a bridge?
Tushar,
I'm not sure what you mean by "add a bridge". I've been using this box ever since the late 1990s, and have had the 3 e100 port since the early 2000s, so I can't say that I "do" anything with it apart from use it.
The PCI configuration remains as it always has, and the box get rebooted only to receive stable kernel updates. Looking back through old dmesg logs, it looks like this issue also happened in 2.6.33.6 too without me ever realising. Hence I am suspecting that this problem has been happening intermittently for ages...
Is there anything else I can tell you about this ropey old P200 MMX PC before Indiana Jones finds it and tries putting it in his museum ;-)?
Cheers,
Chris
^ permalink raw reply
* [RFC] sched: CHOKe packet scheduler (v0.4)
From: Stephen Hemminger @ 2011-01-10 23:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1294667210.3491.7.camel@edumazet-laptop>
This implements the CHOKe packet scheduler based on the existing
Linux RED scheduler based on the algorithm described in the paper.
The core idea is:
For every packet arrival:
Calculate Qave
if (Qave < minth)
Queue the new packet
else
Select randomly a packet from the queue
if (both packets from same flow)
then Drop both the packets
else if (Qave > maxth)
Drop packet
else
Admit packet with proability p (same as RED)
See also:
Rong Pan, Balaji Prabhakar, Konstantinos Psounis, "CHOKe: a stateless active
queue management scheme for approximating fair bandwidth allocation",
Proceeding of INFOCOM'2000, March 2000.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
0.3 version from Eric uses table for queue.
0.4 allows classification with TC filters
fixes crash when peek_random() finds a hole
net/sched/Kconfig | 11 +
net/sched/Makefile | 1
net/sched/sch_choke.c | 527 ++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 539 insertions(+)
--- a/net/sched/Kconfig 2011-01-10 09:17:25.328637817 -0800
+++ b/net/sched/Kconfig 2011-01-10 12:11:40.489701227 -0800
@@ -205,6 +205,17 @@ config NET_SCH_DRR
If unsure, say N.
+config NET_SCH_CHOKE
+ tristate "CHOose and Keep responsive flow scheduler (CHOKE)"
+ help
+ Say Y here if you want to use the CHOKe packet scheduler (CHOose
+ and Keep for responsive flows, CHOose and Kill for unresponsive
+ flows). This is a variation of RED which trys to penalize flows
+ that monopolize the queue.
+
+ To compile this code as a module, choose M here: the
+ module will be called sch_choke.
+
config NET_SCH_INGRESS
tristate "Ingress Qdisc"
depends on NET_CLS_ACT
--- a/net/sched/Makefile 2011-01-10 09:17:25.336639744 -0800
+++ b/net/sched/Makefile 2011-01-10 12:11:40.489701227 -0800
@@ -32,6 +32,7 @@ obj-$(CONFIG_NET_SCH_MULTIQ) += sch_mult
obj-$(CONFIG_NET_SCH_ATM) += sch_atm.o
obj-$(CONFIG_NET_SCH_NETEM) += sch_netem.o
obj-$(CONFIG_NET_SCH_DRR) += sch_drr.o
+obj-$(CONFIG_NET_SCH_CHOKE) += sch_choke.o
obj-$(CONFIG_NET_CLS_U32) += cls_u32.o
obj-$(CONFIG_NET_CLS_ROUTE4) += cls_route.o
obj-$(CONFIG_NET_CLS_FW) += cls_fw.o
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ b/net/sched/sch_choke.c 2011-01-10 12:40:32.802282618 -0800
@@ -0,0 +1,527 @@
+/*
+ * net/sched/sch_choke.c CHOKE scheduler
+ *
+ * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
+ * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/skbuff.h>
+#include <linux/reciprocal_div.h>
+#include <net/pkt_sched.h>
+#include <net/inet_ecn.h>
+#include <net/red.h>
+
+/* CHOKe stateless AQM for fair bandwidth allocation
+ =================================================
+
+ CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
+ unresponsive flows) is a variant of RED that penalizes misbehaving flows but
+ maintains no flow state. The difference from RED is an additional step
+ during the enqueuing process. If average queue size is over the
+ low threshold (qmin), a packet is chosen at random from the queue.
+ If both the new and chosen packet are from the same flow, both
+ are dropped. Unlike RED, CHOKe is not really a "classful" qdisc because it
+ needs to access packets in queue randomly. It has a minimal class
+ interface to allow overriding the builtin flow classifier with
+ filters.
+
+ Source:
+ R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
+ Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
+ IEEE INFOCOM, 2000.
+
+ A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
+ Characteristics", IEEE/ACM Transactions on Networking, 2004
+
+ */
+
+struct choke_sched_data {
+/* Parameters */
+ u32 limit;
+ unsigned char flags;
+
+ struct red_parms parms;
+ struct red_stats stats;
+
+/* Variables */
+ struct tcf_proto *filter_list;
+ unsigned int head;
+ unsigned int tail;
+ unsigned int holes;
+ unsigned int tab_mask; /* size - 1 */
+
+ struct sk_buff **tab;
+};
+
+static inline unsigned int choke_len(const struct choke_sched_data *q)
+{
+ return (q->tail - q->head) & q->tab_mask;
+}
+
+/* deliver a random number between 0 and N - 1 */
+static inline u32 random_N(unsigned int N)
+{
+ return reciprocal_divide(random32(), N);
+}
+
+
+/* Select a packet at random from the queue in O(1) and handle holes */
+static struct sk_buff *choke_peek_random(struct choke_sched_data *q,
+ unsigned int *pidx)
+{
+ struct sk_buff *skb;
+ int retrys = 3;
+
+ do {
+ *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
+ skb = q->tab[*pidx];
+ if (skb)
+ return skb;
+ } while (--retrys > 0);
+
+ /* queue is has lots of holes use the head which is known to exist */
+ return q->tab[*pidx = q->head];
+}
+
+/* Is ECN parameter configured */
+static inline int use_ecn(const struct choke_sched_data *q)
+{
+ return q->flags & TC_RED_ECN;
+}
+
+/* Should packets over max just be dropped (versus marked) */
+static inline int use_harddrop(const struct choke_sched_data *q)
+{
+ return q->flags & TC_RED_HARDDROP;
+}
+
+/* Move head pointer forward to skip over holes */
+static void choke_zap_head_holes(struct choke_sched_data *q)
+{
+ while (q->holes && q->tab[q->head] == NULL) {
+ q->head = (q->head + 1) & q->tab_mask;
+ q->holes--;
+ }
+}
+
+/* Move tail pointer backwards to reuse holes */
+static void choke_zap_tail_holes(struct choke_sched_data *q)
+{
+ while (q->holes && q->tab[q->tail - 1] == NULL) {
+ q->tail = (q->tail - 1) & q->tab_mask;
+ q->holes--;
+ }
+}
+
+/* Drop packet from queue array by creating a "hole" */
+static void choke_drop_by_idx(struct choke_sched_data *q, unsigned int idx)
+{
+ q->tab[idx] = NULL;
+ q->holes++;
+
+ if (idx == q->head)
+ choke_zap_head_holes(q);
+ if (idx == q->tail)
+ choke_zap_tail_holes(q);
+}
+
+/* Classify flow using either:
+ 1. pre-existing classification result in skb
+ 2. fast internal classification
+ 3. use TC filter based classification
+*/
+static inline unsigned int choke_classify(struct sk_buff *skb,
+ struct Qdisc *sch, int *qerr)
+
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct tcf_result res;
+ int result;
+
+ *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
+
+ if (TC_H_MAJ(skb->priority) == sch->handle &&
+ TC_H_MIN(skb->priority) > 0)
+ return TC_H_MIN(skb->priority);
+
+ if (!q->filter_list)
+ return skb_get_rxhash(skb);
+
+ result = tc_classify(skb, q->filter_list, &res);
+ if (result >= 0) {
+#ifdef CONFIG_NET_CLS_ACT
+ switch (result) {
+ case TC_ACT_STOLEN:
+ case TC_ACT_QUEUED:
+ *qerr = NET_XMIT_SUCCESS | __NET_XMIT_STOLEN;
+ case TC_ACT_SHOT:
+ return 0;
+ }
+#endif
+ return TC_H_MIN(res.classid);
+ }
+
+ return 0;
+}
+
+static int choke_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct red_parms *p = &q->parms;
+ unsigned int hash;
+ int uninitialized_var(ret);
+
+ hash = choke_classify(skb, sch, &ret);
+ if (unlikely(!hash)) {
+ if (ret & __NET_XMIT_BYPASS)
+ sch->qstats.drops++;
+ kfree_skb(skb);
+ return ret;
+ }
+
+ /* XXX add hash to qdisc_skb_cb? */
+ *(unsigned int *)(qdisc_skb_cb(skb)->data) = hash;
+
+ /* Compute average queue usage (see RED) */
+ p->qavg = red_calc_qavg(p, choke_len(q) - q->holes);
+ if (red_is_idling(p))
+ red_end_of_idle_period(p);
+
+ /* Is queue small? */
+ if (p->qavg <= p->qth_min)
+ p->qcount = -1;
+ else {
+ struct sk_buff *oskb;
+ unsigned int idx;
+
+ /* Draw a packet at random from queue */
+ oskb = choke_peek_random(q, &idx);
+
+ /* Both packets from same flow ? */
+ if (*(unsigned int *)(qdisc_skb_cb(oskb)->data) == hash) {
+ /* Drop both packets */
+ choke_drop_by_idx(q, idx);
+ qdisc_drop(oskb, sch);
+ goto congestion_drop;
+ }
+
+ if (p->qavg > p->qth_max) {
+ p->qcount = -1;
+
+ sch->qstats.overlimits++;
+ if (use_harddrop(q) || !use_ecn(q) ||
+ !INET_ECN_set_ce(skb)) {
+ q->stats.forced_drop++;
+ goto congestion_drop;
+ }
+
+ q->stats.forced_mark++;
+ }
+
+ if (++p->qcount) {
+ if (red_mark_probability(p, p->qavg)) {
+ p->qcount = 0;
+ p->qR = red_random(p);
+
+ sch->qstats.overlimits++;
+ if (!use_ecn(q) || !INET_ECN_set_ce(skb)) {
+ q->stats.prob_drop++;
+ goto congestion_drop;
+ }
+
+ q->stats.prob_mark++;
+ }
+ } else
+ p->qR = red_random(p);
+ }
+
+ /* Admit new packet */
+ if (likely(choke_len(q) < q->limit)) {
+ q->tab[q->tail] = skb;
+ q->tail = (q->tail + 1) & q->tab_mask;
+
+ sch->qstats.backlog += qdisc_pkt_len(skb);
+ __qdisc_update_bstats(sch, qdisc_pkt_len(skb));
+ return NET_XMIT_SUCCESS;
+ }
+
+ q->stats.pdrop++;
+ sch->qstats.drops++;
+ kfree_skb(skb);
+ return NET_XMIT_DROP;
+
+ congestion_drop:
+ qdisc_drop(skb, sch);
+ return NET_XMIT_CN;
+}
+
+static struct sk_buff *choke_dequeue(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct sk_buff *skb;
+
+ if (q->head == q->tail) {
+ if (!red_is_idling(&q->parms))
+ red_start_of_idle_period(&q->parms);
+ return NULL;
+ }
+ skb = q->tab[q->head];
+ q->tab[q->head] = NULL; /* not really needed */
+ q->head = (q->head + 1) & q->tab_mask;
+ choke_zap_head_holes(q);
+ sch->qstats.backlog -= qdisc_pkt_len(skb);
+
+ return skb;
+}
+
+static unsigned int choke_drop(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ unsigned int len;
+
+ len = qdisc_queue_drop(sch);
+
+ if (len > 0)
+ q->stats.other++;
+ else {
+ if (!red_is_idling(&q->parms))
+ red_start_of_idle_period(&q->parms);
+ }
+
+ return len;
+}
+
+static void choke_reset(struct Qdisc* sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+
+ red_restart(&q->parms);
+}
+
+static const struct nla_policy choke_policy[TCA_RED_MAX + 1] = {
+ [TCA_RED_PARMS] = { .len = sizeof(struct tc_red_qopt) },
+ [TCA_RED_STAB] = { .len = RED_STAB_SIZE },
+};
+
+
+static void choke_free(void *addr)
+{
+ if (addr) {
+ if (is_vmalloc_addr(addr))
+ vfree(addr);
+ else
+ kfree(addr);
+ }
+}
+
+static int choke_change(struct Qdisc *sch, struct nlattr *opt)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct nlattr *tb[TCA_RED_MAX + 1];
+ struct tc_red_qopt *ctl;
+ int err;
+ struct sk_buff **old = NULL;
+ unsigned int mask;
+
+ if (opt == NULL)
+ return -EINVAL;
+
+ err = nla_parse_nested(tb, TCA_RED_MAX, opt, choke_policy);
+ if (err < 0)
+ return err;
+
+ if (tb[TCA_RED_PARMS] == NULL ||
+ tb[TCA_RED_STAB] == NULL)
+ return -EINVAL;
+
+ ctl = nla_data(tb[TCA_RED_PARMS]);
+
+ mask = roundup_pow_of_two(ctl->limit + 1) - 1;
+ if (mask != q->tab_mask) {
+ struct sk_buff **ntab = kcalloc(mask + 1, sizeof(struct sk_buff *),
+ GFP_KERNEL);
+ if (!ntab)
+ ntab = vzalloc((mask + 1) * sizeof(struct sk_buff *));
+ if (!ntab)
+ return -ENOMEM;
+ sch_tree_lock(sch);
+ old = q->tab;
+ if (old) {
+ unsigned int tail = 0;
+
+ while (q->head != q->tail) {
+ ntab[tail++] = q->tab[q->head];
+ q->head = (q->head + 1) & q->tab_mask;
+ }
+ q->head = 0;
+ q->tail = tail;
+ }
+ q->tab_mask = mask;
+ q->holes = 0;
+ } else
+ sch_tree_lock(sch);
+ q->flags = ctl->flags;
+ q->limit = ctl->limit;
+
+ red_set_parms(&q->parms, ctl->qth_min, ctl->qth_max, ctl->Wlog,
+ ctl->Plog, ctl->Scell_log,
+ nla_data(tb[TCA_RED_STAB]));
+
+ if (q->head == q->tail)
+ red_end_of_idle_period(&q->parms);
+
+ sch_tree_unlock(sch);
+ choke_free(old);
+ return 0;
+}
+
+static int choke_init(struct Qdisc* sch, struct nlattr *opt)
+{
+ return choke_change(sch, opt);
+}
+
+static int choke_dump(struct Qdisc *sch, struct sk_buff *skb)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct nlattr *opts = NULL;
+ struct tc_red_qopt opt = {
+ .limit = q->limit,
+ .flags = q->flags,
+ .qth_min = q->parms.qth_min >> q->parms.Wlog,
+ .qth_max = q->parms.qth_max >> q->parms.Wlog,
+ .Wlog = q->parms.Wlog,
+ .Plog = q->parms.Plog,
+ .Scell_log = q->parms.Scell_log,
+ };
+
+ sch->q.qlen = choke_len(q) - q->holes;
+ opts = nla_nest_start(skb, TCA_OPTIONS);
+ if (opts == NULL)
+ goto nla_put_failure;
+
+ NLA_PUT(skb, TCA_RED_PARMS, sizeof(opt), &opt);
+ return nla_nest_end(skb, opts);
+
+nla_put_failure:
+ nla_nest_cancel(skb, opts);
+ return -EMSGSIZE;
+}
+
+static int choke_dump_stats(struct Qdisc *sch, struct gnet_dump *d)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct tc_red_xstats st = {
+ .early = q->stats.prob_drop + q->stats.forced_drop,
+ .pdrop = q->stats.pdrop,
+ .other = q->stats.other,
+ .marked = q->stats.prob_mark + q->stats.forced_mark,
+ };
+
+ return gnet_stats_copy_app(d, &st, sizeof(st));
+}
+
+static void choke_destroy(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+
+ tcf_destroy_chain(&q->filter_list);
+ choke_free(q->tab);
+}
+
+static struct Qdisc *choke_leaf(struct Qdisc *sch, unsigned long arg)
+{
+ return NULL;
+}
+
+static unsigned long choke_get(struct Qdisc *sch, u32 classid)
+{
+ return 0;
+}
+
+static void choke_put(struct Qdisc *q, unsigned long cl)
+{
+}
+
+static unsigned long choke_bind(struct Qdisc *sch, unsigned long parent,
+ u32 classid)
+{
+ return 0;
+}
+
+static struct tcf_proto **choke_find_tcf(struct Qdisc *sch, unsigned long cl)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+
+ if (cl)
+ return NULL;
+ return &q->filter_list;
+}
+
+static int choke_dump_class(struct Qdisc *sch, unsigned long cl,
+ struct sk_buff *skb, struct tcmsg *tcm)
+{
+ tcm->tcm_handle |= TC_H_MIN(cl);
+ return 0;
+}
+
+static void choke_walk(struct Qdisc *sch, struct qdisc_walker *arg)
+{
+ if (!arg->stop) {
+ if (arg->fn(sch, 1, arg) < 0) {
+ arg->stop = 1;
+ return;
+ }
+ arg->count++;
+ }
+}
+
+static const struct Qdisc_class_ops choke_class_ops = {
+ .leaf = choke_leaf,
+ .get = choke_get,
+ .put = choke_put,
+ .tcf_chain = choke_find_tcf,
+ .bind_tcf = choke_bind,
+ .unbind_tcf = choke_put,
+ .dump = choke_dump_class,
+ .walk = choke_walk,
+};
+
+static struct Qdisc_ops choke_qdisc_ops __read_mostly = {
+ .id = "choke",
+ .priv_size = sizeof(struct choke_sched_data),
+
+ .enqueue = choke_enqueue,
+ .dequeue = choke_dequeue,
+ .peek = qdisc_peek_head,
+ .drop = choke_drop,
+ .init = choke_init,
+ .destroy = choke_destroy,
+ .reset = choke_reset,
+ .change = choke_change,
+ .dump = choke_dump,
+ .dump_stats = choke_dump_stats,
+ .owner = THIS_MODULE,
+};
+
+static int __init choke_module_init(void)
+{
+ return register_qdisc(&choke_qdisc_ops);
+}
+
+static void __exit choke_module_exit(void)
+{
+ unregister_qdisc(&choke_qdisc_ops);
+}
+
+module_init(choke_module_init)
+module_exit(choke_module_exit)
+
+MODULE_LICENSE("GPL");
^ permalink raw reply
* [PATCH] rt2x00: Don't leak mem in error path of rt2x00lib_request_firmware()
From: Jesper Juhl @ 2011-01-10 23:47 UTC (permalink / raw)
To: linux-wireless
Cc: users, linux-kernel, netdev, Gertjan van Wingerde,
John W. Linville, Ivo van Doorn
We need to release_firmware() in order not to leak memory.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
rt2x00firmware.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rt2x00/rt2x00firmware.c b/drivers/net/wireless/rt2x00/rt2x00firmware.c
index f0e1eb7..be0ff78 100644
--- a/drivers/net/wireless/rt2x00/rt2x00firmware.c
+++ b/drivers/net/wireless/rt2x00/rt2x00firmware.c
@@ -58,6 +58,7 @@ static int rt2x00lib_request_firmware(struct rt2x00_dev *rt2x00dev)
if (!fw || !fw->size || !fw->data) {
ERROR(rt2x00dev, "Failed to read Firmware.\n");
+ release_firmware(fw);
return -ENOENT;
}
--
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] caif: don't set connection request param size before copying data
From: David Miller @ 2011-01-11 0:01 UTC (permalink / raw)
To: drosenberg; +Cc: sjur.brandeland, netdev
In-Reply-To: <1294702597.2125.74.camel@dan>
From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Mon, 10 Jan 2011 18:36:37 -0500
> The size field should not be set until after the data is successfully
> copied in.
>
> Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.4)
From: Eric Dumazet @ 2011-01-11 0:00 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110110154414.53f33916@nehalam>
Le lundi 10 janvier 2011 à 15:44 -0800, Stephen Hemminger a écrit :
> This implements the CHOKe packet scheduler based on the existing
> Linux RED scheduler based on the algorithm described in the paper.
>
> The core idea is:
> For every packet arrival:
> Calculate Qave
> if (Qave < minth)
> Queue the new packet
> else
> Select randomly a packet from the queue
> if (both packets from same flow)
> then Drop both the packets
> else if (Qave > maxth)
> Drop packet
> else
> Admit packet with proability p (same as RED)
>
> See also:
> Rong Pan, Balaji Prabhakar, Konstantinos Psounis, "CHOKe: a stateless active
> queue management scheme for approximating fair bandwidth allocation",
> Proceeding of INFOCOM'2000, March 2000.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
You beat me, I found the bug I had in _change()
> +
> +static int choke_change(struct Qdisc *sch, struct nlattr *opt)
> +{
> + struct choke_sched_data *q = qdisc_priv(sch);
> + struct nlattr *tb[TCA_RED_MAX + 1];
> + struct tc_red_qopt *ctl;
> + int err;
> + struct sk_buff **old = NULL;
> + unsigned int mask;
> +
> + if (opt == NULL)
> + return -EINVAL;
> +
> + err = nla_parse_nested(tb, TCA_RED_MAX, opt, choke_policy);
> + if (err < 0)
> + return err;
> +
> + if (tb[TCA_RED_PARMS] == NULL ||
> + tb[TCA_RED_STAB] == NULL)
> + return -EINVAL;
> +
> + ctl = nla_data(tb[TCA_RED_PARMS]);
> +
> + mask = roundup_pow_of_two(ctl->limit + 1) - 1;
> + if (mask != q->tab_mask) {
> + struct sk_buff **ntab = kcalloc(mask + 1, sizeof(struct sk_buff *),
> + GFP_KERNEL);
> + if (!ntab)
> + ntab = vzalloc((mask + 1) * sizeof(struct sk_buff *));
> + if (!ntab)
> + return -ENOMEM;
> + sch_tree_lock(sch);
> + old = q->tab;
> + if (old) {
> + unsigned int tail = 0;
> +
> + while (q->head != q->tail) {
> + ntab[tail++] = q->tab[q->head];
> + q->head = (q->head + 1) & q->tab_mask;
> + }
> + q->head = 0;
> + q->tail = tail;
> + }
> + q->tab_mask = mask;
Here we missed :
q->tab = ntab;
> + q->holes = 0;
> + } else
> + sch_tree_lock(sch);
> + q->flags = ctl->flags;
> + q->limit = ctl->limit;
> +
> + red_set_parms(&q->parms, ctl->qth_min, ctl->qth_max, ctl->Wlog,
> + ctl->Plog, ctl->Scell_log,
> + nla_data(tb[TCA_RED_STAB]));
> +
> + if (q->head == q->tail)
> + red_end_of_idle_period(&q->parms);
> +
> + sch_tree_unlock(sch);
> + choke_free(old);
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [patch v2] phonet: some signedness bugs
From: David Miller @ 2011-01-11 0:06 UTC (permalink / raw)
To: error27; +Cc: remi.denis-courmont, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <20110110140658.GB2721@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Mon, 10 Jan 2011 17:06:58 +0300
> Dan Rosenberg pointed out that there were some signed comparison bugs
> in the phonet protocol.
>
> http://marc.info/?l=full-disclosure&m=129424528425330&w=2
>
> The problem is that we check for array overflows but "protocol" is
> signed and we don't check for array underflows. If you have already
> have CAP_SYS_ADMIN then you could use the bugs to get root, or someone
> could cause an oops by mistake.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] net: Allow allocating different number RX and TX mqs
From: David Miller @ 2011-01-11 0:06 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <alpine.DEB.2.00.1101092123340.3137@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Sun, 9 Jan 2011 21:36:25 -0800 (PST)
> Add functions so that a different number of TX and RX queues can be
> allocated in a netdevice. Second patch modifies mlx4 driver to call
> this function which is an example of a driver that allocates different
> numbers for TX and RX queues.
Both applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH] net_sched: factorize qdisc stats handling
From: David Miller @ 2011-01-11 0:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, jarkao2, xiaosuo, fabio, netdev, rizzo
In-Reply-To: <1294597854.2709.850.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 09 Jan 2011 19:30:54 +0100
> [PATCH v2] net_sched: factorize qdisc stats handling
>
> HTB takes into account skb is segmented in stats updates.
> Generalize this to all schedulers.
>
> They should use qdisc_bstats_update() helper instead of manipulating
> bstats.bytes and bstats.packets
>
> Add bstats_update() helper too for classes that use
> gnet_stats_basic_packed fields.
>
> Note : Right now, TCQ_F_CAN_BYPASS shortcurt can be taken only if no
> stab is setup on qdisc.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> v2: constify some methods, and make sure qdisc_skb_cb(skb)->pkt_len is
> set in the TCQ_F_CAN_BYPASS shortcut in __dev_xmit_skb()
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 3/5] NET: IPV4: ARP: allow to invalidate specific ARP entries
From: David Miller @ 2011-01-11 0:11 UTC (permalink / raw)
To: maximlevitsky
Cc: eric.dumazet, linux1394-devel, stefanr, netdev, kuznet, jmorris,
kaber
In-Reply-To: <1294531032.25396.11.camel@maxim-laptop>
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Sun, 09 Jan 2011 01:57:12 +0200
> NET: IPV4: ARP: allow to invalidate specific ARP entries
>
> IPv4 over firewire needs to be able to remove ARP entries
> from the ARP cache that belong to nodes that are removed, because
> IPv4 over firewire uses ARP packets for private information
> about nodes.
>
> This information becomes invalid as soon as node drops
> off the bus and when it reconnects, its only possible
> to start takling to is after it responded to an ARP packet.
> But ARP cache prevents such packets from being sent.
>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] CAIF: Fix IPv6 support in receive path for GPRS/3G
From: David Miller @ 2011-01-11 0:12 UTC (permalink / raw)
To: sjurbren; +Cc: netdev, kumar.sanghvi, sjur.brandeland
In-Reply-To: <1294401428-2085-1-git-send-email-sjurbren@stericsson.com>
From: Sjur Brændeland <sjurbren@stericsson.com>
Date: Fri, 07 Jan 2011 12:57:08 +0100
> From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
>
> Checks version field of IP in the receive path for GPRS/3G data
> and appropriately sets the value of skb->protocol.
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] net/r8169: Update the function of parsing firmware
From: David Miller @ 2011-01-11 0:14 UTC (permalink / raw)
To: hayeswang; +Cc: romieu, netdev, linux-kernel
In-Reply-To: <1294661245-2191-1-git-send-email-hayeswang@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 10 Jan 2011 20:07:25 +0800
> Update rtl_phy_write_fw function. The new function could
> parse the complex firmware which is used by RTL8111E and later.
> The new firmware may read data and do some operations, not just
> do writing only.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2] net: ppp: use {get,put}_unaligned_be{16,32}
From: David Miller @ 2011-01-11 0:13 UTC (permalink / raw)
To: xiaosuo; +Cc: paulus, harvey.harrison, linux-ppp, netdev
In-Reply-To: <1294357056-25889-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Fri, 7 Jan 2011 07:37:36 +0800
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] net: Allow allocating different number RX and TX mqs
From: Tom Herbert @ 2011-01-11 0:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110110.160642.146350621.davem@davemloft.net>
On Mon, Jan 10, 2011 at 4:06 PM, David Miller <davem@davemloft.net> wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Sun, 9 Jan 2011 21:36:25 -0800 (PST)
>
>> Add functions so that a different number of TX and RX queues can be
>> allocated in a netdevice. Second patch modifies mlx4 driver to call
>> this function which is an example of a driver that allocates different
>> numbers for TX and RX queues.
>
> Both applied, thanks Tom.
>
Thanks. By the way I didn't see a maintainer for the mlx drivers in
the MAINTAINERS files. Who maintains these?
^ permalink raw reply
* Re: [e100] Page allocation failure warning(?) in 2.6.36.3
From: Dave, Tushar N @ 2011-01-11 0:37 UTC (permalink / raw)
To: Chris Rankin, e1000-devel@lists.sourceforge.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <688142.89079.qm@web121707.mail.ne1.yahoo.com>
Chris,
The reason I asked you about bridge is because I have noticed "br0: port 1(eth1) entering learning state" in the dmesg log you sent.
I am trying to figure out exactly what sequence of commands you run that produce this message " br0: port 1(eth1) entering learning state" in log.
Also if you let me know output of
#cat /etc/network/interface
#ifconfig -a
Thanks.
-Tushar
-----Original Message-----
From: Chris Rankin [mailto:rankincj@yahoo.com]
Sent: Monday, January 10, 2011 3:42 PM
To: e1000-devel@lists.sourceforge.net; Dave, Tushar N
Cc: netdev@vger.kernel.org
Subject: RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
--- On Mon, 10/1/11, Dave, Tushar N <tushar.n.dave@intel.com> wrote:
> Does the issue appears only when you add a bridge?
Tushar,
I'm not sure what you mean by "add a bridge". I've been using this box ever since the late 1990s, and have had the 3 e100 port since the early 2000s, so I can't say that I "do" anything with it apart from use it.
The PCI configuration remains as it always has, and the box get rebooted only to receive stable kernel updates. Looking back through old dmesg logs, it looks like this issue also happened in 2.6.33.6 too without me ever realising. Hence I am suspecting that this problem has been happening intermittently for ages...
Is there anything else I can tell you about this ropey old P200 MMX PC before Indiana Jones finds it and tries putting it in his museum ;-)?
Cheers,
Chris
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH v2] cxgb3i: fixed connection problem with iscsi private ip
From: kxie @ 2011-01-11 0:45 UTC (permalink / raw)
To: netdev, linux-scsi, open-iscsi; +Cc: kxie, davem, James.Bottomley, michaelc
[PATCH v2] cxgb3i: fixed connection problem with iscsi private ip
From: Karen Xie <kxie@chelsio.com>
The last one seems to have some formatting problem. Regenerated the patch.
fixed the connection problem when the private iscsi ipv4 address is provisioned on the interface.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb3i/cxgb3i.h | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
index 5f5e339..20593fd 100644
--- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
+++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
@@ -24,10 +24,21 @@
extern cxgb3_cpl_handler_func cxgb3i_cpl_handlers[NUM_CPL_CMDS];
-#define cxgb3i_get_private_ipv4addr(ndev) \
- (((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr)
-#define cxgb3i_set_private_ipv4addr(ndev, addr) \
- (((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr) = addr
+static inline unsigned int cxgb3i_get_private_ipv4addr(struct net_device *ndev)
+{
+ return ((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr;
+}
+
+static inline void cxgb3i_set_private_ipv4addr(struct net_device *ndev,
+ unsigned int addr)
+{
+ struct port_info *pi = (struct port_info *)netdev_priv(ndev);
+
+ pi->iscsic.flags = addr ? 1 : 0;
+ pi->iscsi_ipv4addr = addr;
+ if (addr)
+ memcpy(pi->iscsic.mac_addr, ndev->dev_addr, ETH_ALEN);
+}
struct cpl_iscsi_hdr_norss {
union opcode_tid ot;
^ permalink raw reply related
* Re: [PATCH] UDPCP Communication Protocol
From: Hagen Paul Pfeifer @ 2011-01-11 0:49 UTC (permalink / raw)
To: stefani; +Cc: linux-kernel, akpm, davem, netdev
In-Reply-To: <1293787785-3834-1-git-send-email-stefani@seibold.net>
find_dest() via new_dest() may return NULL
* stefani@seibold.net | 2010-12-31 10:29:45 [+0100]:
>+static int udpcp_sendmsg(struct kiocb *iocb, struct sock *sk,
>+ struct msghdr *msg, size_t len)
>+{
>+ struct inet_sock *inet = inet_sk(sk);
>+ struct udpcp_sock *usk = udpcp_sk(sk);
>+ struct ipcm_cookie *ipc;
>+ struct rtable *rt = NULL;
>+ int free = 0;
>+ int connected = 0;
>+ __be32 daddr, faddr, saddr;
>+ __be16 dport;
>+ u8 tos;
>+ int err = 0;
>+ int corkreq = usk->udpsock.corkflag || msg->msg_flags & MSG_MORE;
>+ int (*getfrag) (void *, char *, int, int, int, struct sk_buff *);
>+ struct udpcp_dest *dest;
>+
>+ if (len > UDPCP_MAX_MSGSIZE)
>+ return -EMSGSIZE;
>+
>+ /*
>+ * Check the flags.
>+ */
>+ if (msg->msg_flags & MSG_OOB)
>+ return -EOPNOTSUPP;
>+
>+ /*
>+ * check if socket is binded to a port
>+ */
>+ if (!(sk->sk_userlocks & SOCK_BINDPORT_LOCK) || !inet->inet_num)
>+ return -ENOTCONN;
>+
>+ /*
>+ * Get and verify the address.
>+ */
>+ if (msg->msg_name) {
>+ struct sockaddr_in *usin = (struct sockaddr_in *)msg->msg_name;
>+ if (msg->msg_namelen < sizeof(*usin))
>+ return -EINVAL;
>+ if (usin->sin_family != AF_INET) {
>+ if (usin->sin_family != AF_UNSPEC)
>+ return -EAFNOSUPPORT;
>+ }
>+
>+ daddr = usin->sin_addr.s_addr;
>+ dport = usin->sin_port;
>+ } else {
>+ if (sk->sk_state != TCP_ESTABLISHED)
>+ return -EDESTADDRREQ;
>+ daddr = inet->inet_daddr;
>+ dport = inet->inet_dport;
>+ /* Open fast path for connected socket.
>+ Route will not be used, if at least one option is set.
>+ */
>+ connected = 1;
>+ }
>+
>+ if (dport == 0)
>+ return -EINVAL;
>+
>+ dest = find_dest(sk, daddr, dport);
if (!dest)
return -ENOBUFS;
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.4)
From: Stephen Hemminger @ 2011-01-11 1:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1294704031.4148.2.camel@edumazet-laptop>
OK, put that in.
>
> Here we missed :
>
> q->tab = ntab;
>
--
^ permalink raw reply
* Re: panic in tg3 driver
From: Matt Carlson @ 2011-01-11 2:00 UTC (permalink / raw)
To: Stephen Clark
Cc: Matthew Carlson, Linux Kernel Network Developers, Michael Chan
In-Reply-To: <4D2B6652.7040607@earthlink.net>
On Mon, Jan 10, 2011 at 12:04:34PM -0800, Stephen Clark wrote:
> On 01/10/2011 02:22 PM, Matt Carlson wrote:
> > On Sun, Jan 09, 2011 at 02:30:50PM -0800, Stephen Clark wrote:
> >
> >> On 01/04/2011 09:54 AM, Stephen Clark wrote:
> >>
> >>> Hello,
> >>>
> >>>
> >>> The hardware is an Acrosser AR-M0898B micro box.
> >>> lspci
> >>> 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> >>> Host Bridge
> >>> 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> >>> Host Bridge
> >>> 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> >>> Host Bridge
> >>> 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
> >>> 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> >>> Host Bridge
> >>> 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
> >>> Host Bridge
> >>> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237/VX700 PCI Bridge
> >>> 00:0f.0 IDE interface: VIA Technologies, Inc. VT8251 Serial ATA
> >>> Controller (rev
> >>> 20)
> >>> 00:0f.1 IDE interface: VIA Technologies, Inc.
> >>> VT82C586A/B/VT82C686/A/B/VT823x/A/
> >>> C PIPC Bus Master IDE (rev 07)
> >>> 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> >>> Controller
> >>> (rev 91)
> >>> 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> >>> Controller
> >>> (rev 91)
> >>> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> >>> Controller
> >>> (rev 91)
> >>> 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> >>> Controller
> >>> (rev 91)
> >>> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
> >>> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8251 PCI to ISA Bridge
> >>> 00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
> >>> 00:13.0 Host bridge: VIA Technologies, Inc. VT8251 Host Bridge
> >>> 00:13.1 PCI bridge: VIA Technologies, Inc. VT8251 PCI to PCI Bridge
> >>> 02:08.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
> >>> (rev 02)
> >>> 02:09.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
> >>> (rev 02)
> >>> 80:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
> >>> 80:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port
> >>> 81:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
> >>> Fast Ethernet
> >>> PCI Express (rev 02)
> >>> 82:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M
> >>> Fast Ethernet
> >>> PCI Express (rev 02)
> >>>
> >>> Kernel 2.6.36-2.el5.elrepo on an i686
> >>>
> >>> When I try to ifconfig either of the BCM5906M ports the system panics.
> >>>
> >>> Ideas, fixes ?
> >>>
> >>> [root@Z1010 ~]# modprobe tg3
> >>> [root@Z1010 ~]# ifconfig eth2 2.2.2.2/24
> >>> ------------[ cut here ]------------
> >>> kernel BUG at drivers/net/tg3.c:4365!
> >>> invalid opcode: 0000 [#1] PREEMPT SMP
> >>> last sysfs file: /sys/class/net/eth3/address
> >>> Modules linked in: tg3 xt_tcpudp ipt_LOG xt_limit xt_state
> >>> iptable_mangle af_ke]
> >>>
> >>> Pid: 20303, comm: kworker/0:2 Not tainted 2.6.36-2.el5.elrepo #1
> >>> CN700-8251/
> >>> EIP: 0060:[<e1c62f19>] EFLAGS: 00010202 CPU: 0
> >>> EIP is at tg3_tx_recover+0x1e/0x53 [tg3]
> >>> EAX: deece4c0 EBX: dfa9c000 ECX: deece4c0 EDX: ffffffff
> >>> ESI: deece4c0 EDI: deece500 EBP: c1801f38 ESP: c1801f30
> >>> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> >>> Process kworker/0:2 (pid: 20303, ti=c1801000 task=df0105d0
> >>> task.ti=dee62000)
> >>> Stack:
> >>> dfa9c000 00000000 c1801f6c e1c630be c1801f6c deece4c0 00000840 00000000
> >>> <0> df251cc0 00000005 00000000 df979800 deece500 deece4c0 00000040
> >>> c1801f94
> >>> <0> e1c661e5 00000000 00000040 c1801f88 e09df1d2 00000000 deece500
> >>> dfab4000
> >>> Call Trace:
> >>> [<e1c630be>] ? tg3_tx+0x157/0x1a2 [tg3]
> >>> [<e1c661e5>] ? tg3_poll_work+0x2b/0x10b [tg3]
> >>> [<e09df1d2>] ? ssb_write32+0x11/0x14 [b44]
> >>> [<e1c662f9>] ? tg3_poll+0x34/0x9a [tg3]
> >>> [<c0674058>] ? net_rx_action+0x7e/0x11c
> >>> [<c04409c9>] ? __do_softirq+0x85/0x10c
> >>> [<c0440944>] ? __do_softirq+0x0/0x10c
> >>> <IRQ>
> >>> [<c04404ef>] ? _local_bh_enable_ip+0x68/0x87
> >>> [<c044051b>] ? local_bh_enable_ip+0xd/0xf
> >>> [<c046593b>] ? __raw_spin_unlock_bh+0x1c/0x1e
> >>> [<c06fa4f2>] ? _raw_spin_unlock_bh+0xd/0xf
> >>> [<e1c6281f>] ? spin_unlock_bh+0xd/0xf [tg3]
> >>> [<e1c62cbe>] ? tg3_full_unlock+0x10/0x12 [tg3]
> >>> [<e1c664c7>] ? tg3_reset_task+0xd7/0xe3 [tg3]
> >>> [<c044ec37>] ? process_one_work+0x10b/0x1bc
> >>> [<e1c663f0>] ? tg3_reset_task+0x0/0xe3 [tg3]
> >>> [<c044fd41>] ? worker_thread+0x77/0xf9
> >>> [<c0453048>] ? kthread+0x60/0x65
> >>> [<c044fcca>] ? worker_thread+0x0/0xf9
> >>> [<c0452fe8>] ? kthread+0x0/0x65
> >>> [<c040337e>] ? kernel_thread_helper+0x6/0x10
> >>> Code: f0 e8 88 ff ff ff 8d 65 f8 5b 5e 5d c3 55 89 e5 56 53 0f 1f 44
> >>> 00 00 f6 8
> >>> EIP: [<e1c62f19>] tg3_tx_recover+0x1e/0x53 [tg3] SS:ESP 0068:c1801f30
> >>> ---[ end trace 82381e9b93e397ad ]---
> >>> Kernel panic - not syncing: Fatal exception in interrupt
> >>> Pid: 20303, comm: kworker/0:2 Tainted: G D
> >>> 2.6.36-2.el5.elrepo #1
> >>> Call Trace:
> >>> [<c043b3cd>] panic+0x62/0x15d
> >>> [<c06fb7d1>] oops_end+0x99/0xa8
> >>> [<e1c62f19>] ? tg3_tx_recover+0x1e/0x53 [tg3]
> >>> [<c0405a62>] die+0x58/0x5e
> >>>
> >>> Thanks,
> >>> Steve
> >>>
> >>>
> >> Additonal info I compiled the latest kernel 2.6.37-rc8+ and still have the problem.
> >> Also boot with noapic I see this in the dmesg log and interrupts are increasing
> >> like crazy:
> >> tg3.c:v3.115 (October 14, 2010)
> >> tg3 0000:81:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
> >> tg3 0000:81:00.0: setting latency timer to 64
> >> tg3 0000:81:00.0: PCI: Disallowing DAC for device
> >> tg3 0000:81:00.0: eth2: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
> >> ress 00:02:b6:36:d1:39
> >> tg3 0000:81:00.0: eth2: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
> >> [0])
> >> tg3 0000:81:00.0: eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> >> tg3 0000:81:00.0: eth2: dma_rwctrl[76180000] dma_mask[32-bit]
> >> tg3 0000:82:00.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
> >> tg3 0000:82:00.0: setting latency timer to 64
> >> tg3 0000:82:00.0: PCI: Disallowing DAC for device
> >> tg3 0000:82:00.0: eth3: Tigon3 [partno(BCM95906) rev c002] (PCI Express) MAC add
> >> ress 00:02:b6:36:d1:3a
> >> tg3 0000:82:00.0: eth3: attached PHY is 5906 (10/100Base-TX Ethernet) (WireSpeed
> >> [0])
> >> tg3 0000:82:00.0: eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> >> tg3 0000:82:00.0: eth3: dma_rwctrl[76180000] dma_mask[32-bit]
> >> tg3 0000:81:00.0: irq 40 for MSI/MSI-X
> >> tg3 0000:81:00.0: eth2: No interrupt was generated using MSI. Switching to INTx
> >> mode. Please report this failure to the PCI maintainer and include system chipse
> >> t information
> >> ADDRCONF(NETDEV_UP): eth2: link is not ready
> >> [root@Z1010 ~]# cat /proc/interrupts
> >> CPU0
> >> 0: 162 XT-PIC-XT-PIC timer
> >> 1: 2 XT-PIC-XT-PIC i8042
> >> 2: 0 XT-PIC-XT-PIC cascade
> >> 3: 1 XT-PIC-XT-PIC
> >> 4: 4863 XT-PIC-XT-PIC serial
> >> 6: 2 XT-PIC-XT-PIC floppy
> >> 7: 5 XT-PIC-XT-PIC ehci_hcd:usb1, uhci_hcd:usb3
> >> 8: 0 XT-PIC-XT-PIC rtc0
> >> 9: 0 XT-PIC-XT-PIC acpi
> >> 10: 2334234 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
> >>
> >> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
> >> 10: 18388914 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
> >> [root@Z1010 ~]# cat /proc/interrupts |grep eth2
> >> 10: 18901627 XT-PIC-XT-PIC uhci_hcd:usb2, eth0, eth2
> >>
> >> --
> >>
> >> "They that give up essential liberty to obtain temporary safety,
> >> deserve neither liberty nor safety." (Ben Franklin)
> >>
> >> "The course of history shows that as a government grows, liberty
> >> decreases." (Thomas Jefferson)
> >>
> > I think drivers/net/tg3.c:4365 is at the line that reads
> > "spin_lock(&tp->lock);" in tg3_tx_recover. Can you verify?
> >
> >
>
>
> tg3_readphy(tp, MII_TG3_DSP_RW_PORT, &phy2);
>
> in static void tg3_serdes_parallel_detect(struct tg3 *tp)
>
> The driver version is:
> #define DRV_MODULE_NAME "tg3"
> #define TG3_MAJ_NUM 3
> #define TG3_MIN_NUM 115
That doesn't look right. The line number I quoted came from the kernel
panic output from 2.6.36-2.el5.elrepo. I'm guessing you quoted me the
sources from the tg3.c file in 2.6.37-rc8+. If you don't have the
2.6.36-2.el5.elrepo sources readily available, can you give me the line
the kernel panic specifies from the tg3.c file from your 2.6.37-rc8+
sources?
It looks like there are a lot of devices on IRQ 10. Does the interrupt
count drop if you bring down eth0 (which I'm guessing is the b44 device)?
Can you tell me if you saw the following message in the syslogs?
"The system may be re-ordering memory-mapped I/O cycles to the network
device, attempting to recover. Please report the problem to the driver
maintainer and include system chipset information."
^ permalink raw reply
* Re: [PATCH v2] cxgb3i: fixed connection problem with iscsi private ip
From: Mike Christie @ 2011-01-11 2:19 UTC (permalink / raw)
To: open-iscsi; +Cc: kxie, netdev, linux-scsi, davem, James.Bottomley
In-Reply-To: <201101110045.p0B0j7vv016416@localhost6.localdomain6>
On 01/10/2011 06:45 PM, kxie@chelsio.com wrote:
> [PATCH v2] cxgb3i: fixed connection problem with iscsi private ip
>
> From: Karen Xie<kxie@chelsio.com>
>
> The last one seems to have some formatting problem. Regenerated the patch.
>
> fixed the connection problem when the private iscsi ipv4 address is provisioned on the interface.
>
> Signed-off-by: Karen Xie<kxie@chelsio.com>
> ---
> drivers/scsi/cxgbi/cxgb3i/cxgb3i.h | 19 +++++++++++++++----
> 1 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
> index 5f5e339..20593fd 100644
> --- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
> +++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
> @@ -24,10 +24,21 @@
>
> extern cxgb3_cpl_handler_func cxgb3i_cpl_handlers[NUM_CPL_CMDS];
>
> -#define cxgb3i_get_private_ipv4addr(ndev) \
> - (((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr)
> -#define cxgb3i_set_private_ipv4addr(ndev, addr) \
> - (((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr) = addr
> +static inline unsigned int cxgb3i_get_private_ipv4addr(struct net_device *ndev)
> +{
> + return ((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr;
> +}
> +
> +static inline void cxgb3i_set_private_ipv4addr(struct net_device *ndev,
> + unsigned int addr)
> +{
> + struct port_info *pi = (struct port_info *)netdev_priv(ndev);
> +
> + pi->iscsic.flags = addr ? 1 : 0;
> + pi->iscsi_ipv4addr = addr;
> + if (addr)
> + memcpy(pi->iscsic.mac_addr, ndev->dev_addr, ETH_ALEN);
> +}
>
> struct cpl_iscsi_hdr_norss {
> union opcode_tid ot;
>
Looks ok to me, and it fixes my setup here. Thanks.
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
^ permalink raw reply
* rtt calculation when retransmissions occur during handshake
From: Josh Hunt @ 2011-01-11 2:52 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2578 bytes --]
I was wondering if someone could explain the following behavior I'm
seeing on my web server. I've instrumented the kernel to look at the
RTT during TCP handshake. I am seeing the RTTs reported by the kernel
when my initial SYN/ACK is lost to be calculated based on the original
SYN/ACK. Is this behavior correct? Below I have two cases I've seen on
my system. The first shows the client replying to the retransmitted
SYN/ACK but giving an RTT of 900 instead of around 252. The second
shows the client replying to the original SYN/ACK and reports an RTT
of 913. I have tcp_no_metrics_save enabled so there should be no RTT
caching. This is on kernel 2.6.32.20.
(I've attached these trace snippets as it might be tough to read in a
mail client)
* Reported RTT: 900 - looks like RTT should be ~252:
1294443792.878373 IP 1.2.3.4.49174 > 5.6.7.8.80: Flags [S], seq
2495182093, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val
759815989 ecr 0,sackOK,eol], length 0
1294443792.878379 IP 5.6.7.8.80 > 1.2.3.4.49174: Flags [S.], seq
4249681570, ack 2495182094, win 5792, options [mss 1460,sackOK,TS val
760394055 ecr 759815989,nop,wscale 5], length 0
1294443793.656624 IP 5.6.7.8.80 > 1.2.3.4.49174: Flags [S.], seq
4249681570, ack 2495182094, win 5792, options [mss 1460,sackOK,TS val
760394834 ecr 759815989,nop,wscale 5], length 0
1294443793.908897 IP 1.2.3.4.49174 > 5.6.7.8.80: Flags [.], ack 1, win
65535, options [nop,nop,TS val 759816000 ecr 760394834], length 0
* Reported RTT: 913 - looks correct since it's replying to the original syn/ack:
1294443634.012920 IP 2.3.4.5.62987 > 5.6.7.8.80: Flags [S], seq
1397298575, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val
576497055 ecr 0,sackOK,eol], length 0
1294443634.012931 IP 5.6.7.8.80 > 2.3.4.5.62987: Flags [S.], seq
1761430826, ack 1397298576, win 5792, options [mss 1460,sackOK,TS val
760235190 ecr 576497055,nop,wscale 5], length 0
1294443634.656625 IP 5.6.7.8.80 > 2.3.4.5.62987: Flags [S.], seq
1761430826, ack 1397298576, win 5792, options [mss 1460,sackOK,TS val
760235834 ecr 576497055,nop,wscale 5], length 0
1294443634.925970 IP 2.3.4.5.62987 > 5.6.7.8.80: Flags [.], ack 1, win
33304, options [nop,nop,TS val 576497064 ecr 760235190], length 0
>From what I can tell it appears that once the ACK to establish the
connection is received tcp_ack_update_rtt() is called from
tcp_rcv_state_process(). That will eventually compute the initial srtt
using tcp_time_stamp and the value in rcv_tsecr. Am I missing a
codepath because these are retransmissions?
Thanks for any help you can provide.
Josh
[-- Attachment #2: tcpdump-snippet --]
[-- Type: application/octet-stream, Size: 1484 bytes --]
* Reported RTT: 900 - looks like RTT should be ~252:
1294443792.878373 IP 1.2.3.4.49174 > 5.6.7.8.80: Flags [S], seq 2495182093, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 759815989 ecr 0,sackOK,eol], length 0
1294443792.878379 IP 5.6.7.8.80 > 1.2.3.4.49174: Flags [S.], seq 4249681570, ack 2495182094, win 5792, options [mss 1460,sackOK,TS val 760394055 ecr 759815989,nop,wscale 5], length 0
1294443793.656624 IP 5.6.7.8.80 > 1.2.3.4.49174: Flags [S.], seq 4249681570, ack 2495182094, win 5792, options [mss 1460,sackOK,TS val 760394834 ecr 759815989,nop,wscale 5], length 0
1294443793.908897 IP 1.2.3.4.49174 > 5.6.7.8.80: Flags [.], ack 1, win 65535, options [nop,nop,TS val 759816000 ecr 760394834], length 0
* Reported RTT: 913 - looks correct since it's replying to the original syn/ack:
1294443634.012920 IP 2.3.4.5.62987 > 5.6.7.8.80: Flags [S], seq 1397298575, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 576497055 ecr 0,sackOK,eol], length 0
1294443634.012931 IP 5.6.7.8.80 > 2.3.4.5.62987: Flags [S.], seq 1761430826, ack 1397298576, win 5792, options [mss 1460,sackOK,TS val 760235190 ecr 576497055,nop,wscale 5], length 0
1294443634.656625 IP 5.6.7.8.80 > 2.3.4.5.62987: Flags [S.], seq 1761430826, ack 1397298576, win 5792, options [mss 1460,sackOK,TS val 760235834 ecr 576497055,nop,wscale 5], length 0
1294443634.925970 IP 2.3.4.5.62987 > 5.6.7.8.80: Flags [.], ack 1, win 33304, options [nop,nop,TS val 576497064 ecr 760235190], length 0
^ permalink raw reply
* RE: [PATCH net-next-2.6 v3 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Bhupesh SHARMA @ 2011-01-11 4:13 UTC (permalink / raw)
To: Wolfgang Grandegger, Oliver Hartkopp
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Marc Kleine-Budde, David Miller,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4D29C8F6.5030806-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hi Oliver and Wolfgang,
> From: Wolfgang Grandegger [mailto:wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org]
> Hi Oliver,
>
> On 01/09/2011 12:01 PM, Oliver Hartkopp wrote:
> > On 06.01.2011 21:08, Wolfgang Grandegger wrote:
> >> Hi Marc,
> >>
> >> On 01/06/2011 08:44 PM, Marc Kleine-Budde wrote:
> >
> >>> If this driver will be merged, we'll have two drivers for the same
> can
> >>> core in the tree. The other one is the pch_can. What do you think
> should
> >>> be the mid term perspective for ccan based hardware?
> >>
> >> Yes, I know. Unfortunately, we did realize rather late the the PCH
> >> controller is a C_CAN clone and the OKI/Intel ppls did not tell us
> >> either. Therefore I asked Bhupesh to provide a SJA1000-a-like
> interface
> >> for the C_CAN, which would allow us to provide an alternative PCI
> driver
> >> "pch_pci.c" for the PCH. If that driver works well on the PCH
> hardware
> >> as well, we should merge the best of both, if necessary, and then
> >> finally remove the pch_can driver. Would that be a reasonable
> proposal.
> >
> > At least for me this looks great. The idea to have a similar approach
> as we
> > successfully implemented for the sja1000 will solve future hardware
> > implementations based on the ccan controller core.
>
> A common driver for c_can based devices will stabilize more quickly and
> does also especially reduce the maintanance effort significantly.
>
> > BTW. for the next submission of Bhupeshs patchset, i would propose to
> name the
> > driver 'ccan' instead of 'c_can', so that we have a
> >
> > linux/drivers/net/can/ccan/...
> >
> > path.
>
> You are late ;-). Bosch named the controller *C_CAN* and therefore I
> asked Bhupesh some time ago to change the file name and variable name
> prefix from ccan to c_can.
Actually V1 of this patchset used the naming convention ccan.
But as was rightly pointed out by Wolfgang and Mark, Bosch
has officially named this core as C_CAN and the naming convention
is kept as C_CAN throughout their user-manual and technical articles.
IMHO, `c_can` seems to represent this Bosch core in a better way
than ccan.
> > Checking directory names in linux/drivers with
> >
> > find . -type d | grep '_'
> >
> > driver names with underscores are pretty unusual and mostly selected
> without
> > fortune:
> >
> > ./staging/olpc_dcon
> > ./staging/wlags49_h2
> > ./staging/wlags49_h2/man
> > ./staging/serqt_usb2
> > ./staging/intel_sst
> > ./staging/quatech_usb2
> > ./staging/asus_oled
> > ./staging/wlags49_h25
> > ./staging/ath6kl/hif/sdio/linux_sdio <- Ugh!
> > ./staging/ath6kl/hif/sdio/linux_sdio/src
> > ./staging/ath6kl/hif/sdio/linux_sdio/include
> > ./net/pch_gbe
> > ./net/fs_enet
> > ./net/wireless/libertas_tf
> > ./net/ibm_newemacds
> >
> > For that reason i would prefer 'ccan' to name this driver core.
>
> Well, not really a strong argument. But well, if other people do
> *prefer* ccan I would not object against it. Bhupesh, what's your
> opinion.
I also prefer c_can :), because it makes the driver name similar to the
core name. Please let me know if you agree for the same.
Regards,
Bhupesh
^ 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