* Re: [PATCH 3/6] new pcmcia IDs for hostap - NETGEAR MA701
From: Jeff Garzik @ 2006-05-16 14:38 UTC (permalink / raw)
To: Marcin Juszkiewicz; +Cc: netdev, Jouni Malinen, Pavel Roskin
In-Reply-To: <200605161621.22459.linux-arm@hrw.one.pl>
Marcin Juszkiewicz wrote:
> One more Prism2 card which works with HostAP.
Please roll these into a single patch. There's no need to split it up
such that there is one ID per patch.
Jeff
^ permalink raw reply
* [PATCH] Enabling standard compliant behaviour in the Linux TCP implementation
From: Angelo P. Castellani @ 2006-05-16 14:24 UTC (permalink / raw)
To: netdev; +Cc: francesco, andrea.baiocchi
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]
Hi all,
I'm a student doing a thesis about TCP performance over high BDP links
and so about congestion control in TCP.
To do this work I've built a testbed using the latest Linux release (2.6.16).
Anyway I've came across the fact that Linux TCP implementation isn't
fully standard compliant.
Even if the choices made to be different from the standards have been
wisely thought, I think that should be possible to disable these
Linuxisms.
Surely this can help all the people using Linux to evaluate a
"standard" environment.
Moreover it permits to compare the pros&cons of the Linux
implementation against the standard one.
So I've disabled the first two Linux-specific mechanisms I've found:
- rate halving
- dynamic reordering metric (dynamic DupThresh)
These're disabled as long as net.ipv4.tcp_standard_compliant=1 (default: 0).
However I don't exclude that there're more non-standard details, so I
hope that somebody can point some more differences between Linux and
the RFCs.
Moreover NewReno is implemented in the Impatient variant (resets the
retransmit timer only on the first partial ack), with
net.ipv4.tcp_slow_but_steady=1 (default: 0) you can enable the
Slow-but-Steady variant (resets the retransmit timer every partial
ack).
Hoping that this can be useful, I attach the patch.
Regards,
Angelo P. Castellani
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: std-compl.diff --]
[-- Type: text/x-patch; name="std-compl.diff", Size: 3772 bytes --]
diff -urd ../linux-2.6.16-orig/include/linux/sysctl.h ./include/linux/sysctl.h
--- ../linux-2.6.16-orig/include/linux/sysctl.h 2006-05-16 14:53:02.000000000 +0200
+++ ./include/linux/sysctl.h 2006-05-16 14:54:50.000000000 +0200
@@ -397,6 +397,8 @@
NET_TCP_CONG_CONTROL=110,
NET_TCP_ABC=111,
NET_IPV4_IPFRAG_MAX_DIST=112,
+ NET_TCP_STANDARD_COMPLIANT,
+ NET_TCP_SLOW_BUT_STEADY,
};
enum {
diff -urd ../linux-2.6.16-orig/include/net/tcp.h ./include/net/tcp.h
--- ../linux-2.6.16-orig/include/net/tcp.h 2006-05-16 14:53:02.000000000 +0200
+++ ./include/net/tcp.h 2006-05-16 14:55:43.000000000 +0200
@@ -219,6 +219,8 @@
extern int sysctl_tcp_moderate_rcvbuf;
extern int sysctl_tcp_tso_win_divisor;
extern int sysctl_tcp_abc;
+extern int sysctl_tcp_standard_compliant;
+extern int sysctl_tcp_slow_but_steady;
extern atomic_t tcp_memory_allocated;
extern atomic_t tcp_sockets_allocated;
diff -urd ../linux-2.6.16-orig/net/ipv4/sysctl_net_ipv4.c ./net/ipv4/sysctl_net_ipv4.c
--- ../linux-2.6.16-orig/net/ipv4/sysctl_net_ipv4.c 2006-05-16 14:53:02.000000000 +0200
+++ ./net/ipv4/sysctl_net_ipv4.c 2006-05-16 14:57:23.000000000 +0200
@@ -664,6 +664,22 @@
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+ {
+ .ctl_name = NET_TCP_STANDARD_COMPLIANT,
+ .procname = "tcp_standard_compliant",
+ .data = &sysctl_tcp_standard_compliant,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
+ {
+ .ctl_name = NET_TCP_SLOW_BUT_STEADY,
+ .procname = "tcp_slow_but_steady",
+ .data = &sysctl_tcp_slow_but_steady,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec,
+ },
{ .ctl_name = 0 }
};
diff -urd ../linux-2.6.16-orig/net/ipv4/tcp_input.c ./net/ipv4/tcp_input.c
--- ../linux-2.6.16-orig/net/ipv4/tcp_input.c 2006-05-16 14:53:02.000000000 +0200
+++ ./net/ipv4/tcp_input.c 2006-05-16 14:52:43.000000000 +0200
@@ -81,6 +81,7 @@
int sysctl_tcp_dsack = 1;
int sysctl_tcp_app_win = 31;
int sysctl_tcp_adv_win_scale = 2;
+int sysctl_tcp_standard_compliant = 0;
int sysctl_tcp_stdurg;
int sysctl_tcp_rfc1337;
@@ -854,7 +855,7 @@
const int ts)
{
struct tcp_sock *tp = tcp_sk(sk);
- if (metric > tp->reordering) {
+ if (!sysctl_tcp_standard_compliant && metric > tp->reordering) {
tp->reordering = min(TCP_MAX_REORDERING, metric);
/* This exciting event is worth to be remembered. 8) */
@@ -2039,6 +2040,8 @@
if (!(flag&FLAG_ECE))
tp->prior_ssthresh = tcp_current_ssthresh(sk);
tp->snd_ssthresh = icsk->icsk_ca_ops->ssthresh(sk);
+ if (sysctl_tcp_standard_compliant)
+ tp->snd_cwnd = tp->snd_ssthresh; // tp->reordering segments should've been already added to sacked_out
TCP_ECN_queue_cwr(tp);
}
@@ -2049,7 +2052,8 @@
if (is_dupack || tcp_head_timedout(sk, tp))
tcp_update_scoreboard(sk, tp);
- tcp_cwnd_down(sk);
+ if (!sysctl_tcp_standard_compliant || icsk->icsk_ca_state == TCP_CA_CWR)
+ tcp_cwnd_down(sk);
tcp_xmit_retransmit_queue(sk);
}
diff -urd ../linux-2.6.16-orig/net/ipv4/tcp_output.c ./net/ipv4/tcp_output.c
--- ../linux-2.6.16-orig/net/ipv4/tcp_output.c 2006-05-16 14:53:02.000000000 +0200
+++ ./net/ipv4/tcp_output.c 2006-05-16 14:52:43.000000000 +0200
@@ -51,6 +51,9 @@
*/
int sysctl_tcp_tso_win_divisor = 3;
+/* Enables the Slow-but-Steady variant of NewReno (cfr. RFC2582 Ch.4) */
+int sysctl_tcp_slow_but_steady = 0;
+
static void update_send_head(struct sock *sk, struct tcp_sock *tp,
struct sk_buff *skb)
{
@@ -1604,7 +1607,7 @@
else
NET_INC_STATS_BH(LINUX_MIB_TCPSLOWSTARTRETRANS);
- if (skb ==
+ if (sysctl_tcp_slow_but_steady || skb ==
skb_peek(&sk->sk_write_queue))
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
inet_csk(sk)->icsk_rto,
^ permalink raw reply
* [PATCH 6/6] new pcmcia IDs for hostap - U.S. Robotics
From: Marcin Juszkiewicz @ 2006-05-16 14:21 UTC (permalink / raw)
To: netdev; +Cc: Jouni Malinen, Pavel Roskin
From: Jochen Friedrich <jochen@scram.de>
Yet another card known to work OK with hostap_cs:
# pccardctl ident
Socket 0:
no product info available
Socket 1:
product info: "U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02", ""
manfid: 0x0156, 0x0002
function: 6 (network)
Signed-off-by: Marcin Juszkiewicz <openembedded@hrw.one.pl>
---
drivers/net/wireless/hostap/hostap_cs.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===================================================================
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:09:29.000000000 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:09:29.000000000 +0200
@@ -935,6 +935,9 @@
PCMCIA_DEVICE_PROD_ID123(
"Pretec", "CompactWLAN Card 802.11b", "2.5",
0x1cadd3e5, 0xe697636c, 0x7a5bfcf1),
+ PCMCIA_DEVICE_PROD_ID1234(
+ "U.S. Robotics", "IEEE 802.11b PC-CARD", "Version 01.02", ""
+ 0xc7b8df9d, 0x1700d087, 0x4b74baa0, 0x00000000),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
This may seem a bit weird, but that's okay, because it is weird.
-- Perl documentation
^ permalink raw reply
* [PATCH 3/6] new pcmcia IDs for hostap - NETGEAR MA701
From: Marcin Juszkiewicz @ 2006-05-16 14:21 UTC (permalink / raw)
To: netdev; +Cc: Jouni Malinen, Pavel Roskin
One more Prism2 card which works with HostAP.
Platform: Sharp Zaurus SL-5500 running 2.4.18 + hostap_cs 0.4.7
root@collie:~# cardctl ident
Socket 0:
product info: "NETGEAR", "MA701 Wireless CF Card", ""
manfid: 0xd601, 0x0002
function: 6 (network)
root@collie:~# iwconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:0F:B5:DE:41:CE
inet addr:135.82.8.139 Bcast:135.82.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:56 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7449 (7.2 KiB) TX bytes:7250 (7.0 KiB)
Interrupt:35
Signed-off-by: Marcin Juszkiewicz <openembedded@hrw.one.pl>
---
drivers/net/wireless/hostap/hostap_cs.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===================================================================
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16
16:09:26.000000000 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16
16:10:35.000000000 +0200
@@ -927,6 +927,8 @@
0x78fc06ee, 0x45a50c1e, 0xa57adb8c, 0x00000000),
PCMCIA_DEVICE_PROD_ID12("D-Link", "DCF-660W",
0x1a424a1c, 0xe78b6dcc),
+ PCMCIA_DEVICE_PROD_ID12("NETGEAR", "MA701 Wireless CF Card",
+ 0x9aa79dc3, 0xd9ec98e),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
Press any key to continue... No, no, NOT *THAT* ONE!
^ permalink raw reply
* [PATCH 4/6] new pcmcia IDs for hostap - PLANEX GW-CF11X
From: Marcin Juszkiewicz @ 2006-05-16 14:21 UTC (permalink / raw)
To: netdev; +Cc: Jouni Malinen, Pavel Roskin
Platform: Sharp Zaurus SL-C3100 running 2.6.16 + pcmciautils 013
root@spitz:~# pccardctl ident
Socket 0:
product info: "HITACHI", "microdrive", "", ""
manfid: 0x0319, 0x0000
function: 4 (fixed disk)
Socket 1:
product info:"PLANEX COMMUNICATION INC","PLANEX GW-CF11X Wireless CF Card", "", ""
manfid: 0xd601, 0x0010
function: 6 ( network )
Signed-off-by: Marcin Juszkiewicz <openembedded@hrw.one.pl>
---
drivers/net/wireless/hostap/hostap_cs.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===================================================================
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:09:27.000000000 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:10:34.000000000 +0200
@@ -929,6 +929,9 @@
0x1a424a1c, 0xe78b6dcc),
PCMCIA_DEVICE_PROD_ID12("NETGEAR", "MA701 Wireless CF Card",
0x9aa79dc3, 0xd9ec98e),
+ PCMCIA_DEVICE_PROD_ID12("PLANEX COMMUNICATION INC",
+ "PLANEX GW-CF11X Wireless CF Card",
+ 0x4703cf68, 0xfad7318d),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
Today is the first day of the rest of your life.
^ permalink raw reply
* [PATCH 2/6] new pcmcia IDs for hostap - D-Link DCF-660W
From: Marcin Juszkiewicz @ 2006-05-16 14:21 UTC (permalink / raw)
To: netdev; +Cc: Jouni Malinen, Pavel Roskin
I use D-Link DCF-660W card with WPA protected network. By default
orinoco_cs was loaded for my card so I was not able to connect. This patch
make my card working with hostap_cs (like it was when I used pcmcia-cs).
Card was used with hostap_cs during last year in two Zaurus models (2.4.18
on one and 2.6.11 - 2.6.16 on another).
Platform: Sharp Zaurus C760 running 2.6.16 and pcmciautils 013.
root@c7x0:~# pccardctl ident
Socket 0:
product info: "D-Link", "DCF-660W", "", ""
manfid: 0xd601, 0x0005
function: 6 (network)
root@c7x0:~# iwconfig wlan0
wlan0 IEEE 802.11b ESSID:"test"
Mode:Master Frequency:2.422 GHz Access Point: 00:80:C8:2C:09:3F
Bit Rate:11 Mb/s Sensitivity=1/3
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Signed-off-by: Marcin Juszkiewicz <openembedded@hrw.one.pl>
---
drivers/net/wireless/hostap/hostap_cs.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===================================================================
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:09:25.000000000 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:10:37.000000000 +0200
@@ -925,6 +925,8 @@
0x273fe3db, 0x32a1eaee),
PCMCIA_DEVICE_PROD_ID1234("ASUS", "802_11B_CF_CARD_25", "Version 01.00", "",
0x78fc06ee, 0x45a50c1e, 0xa57adb8c, 0x00000000),
+ PCMCIA_DEVICE_PROD_ID12("D-Link", "DCF-660W",
+ 0x1a424a1c, 0xe78b6dcc),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
You don't have to be crazy to live in this planet, but it helps.
^ permalink raw reply
* [PATCH 5/6] new pcmcia IDs for hostap - Pretec
From: Marcin Juszkiewicz @ 2006-05-16 14:21 UTC (permalink / raw)
To: netdev; +Cc: Jouni Malinen, Pavel Roskin
I use two Zaurus palmtops - one run 2.4.18 kernel (it's sl-5500) and second
run 2.6.16. Both are running under control of OpenZaurus distribution
(I'm Release Manager of it).
When I use pcmcia-cs then my Pretec WiFi card is handled by hostap driver
and everything is working fine. Recently I switched to pcmciautils and after
card insert orinoco modules are loaded. I prefer to use hostap modules
because they work the same under 2.4 and 2.6 kernels (with orinoco I have to
use 0.13e ones because never ones does not work under 2.4/arm).
This patch adds definition of my card to hostap_cs cardlist. It was tested on
Sharp Zaurus C760 palmtop running 2.6.16 + pcmciautils 010 + udev 084
Signed-off-by: Marcin Juszkiewicz <openembedded@hrw.one.pl>
---
drivers/net/wireless/hostap/hostap_cs.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===================================================================
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:09:28.000000000 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:10:32.000000000 +0200
@@ -932,6 +932,9 @@
PCMCIA_DEVICE_PROD_ID12("PLANEX COMMUNICATION INC",
"PLANEX GW-CF11X Wireless CF Card",
0x4703cf68, 0xfad7318d),
+ PCMCIA_DEVICE_PROD_ID123(
+ "Pretec", "CompactWLAN Card 802.11b", "2.5",
+ 0x1cadd3e5, 0xe697636c, 0x7a5bfcf1),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
You can close your eyes to reality, but not to memories.
^ permalink raw reply
* [PATCH 1/6] new pcmcia IDs for hostap - ASUS WL-110
From: Marcin Juszkiewicz @ 2006-05-16 14:21 UTC (permalink / raw)
To: netdev; +Cc: Jouni Malinen, Pavel Roskin
Here's another card that would benefit from a hostap driver:
Platform: HP Ipaq hx4700 running 2.6.16-hh
root@ipaq-pxa270:~# pccardctl ident
Socket 0:
product info: "ASUS", "802_11B_CF_CARD_25", "Version 01.00", ""
manfid: 0x02aa, 0x0002
function: 6 (network)
root@ipaq-pxa270:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:0C:6E:F0:DA:CD
inet addr:172.20.0.3 Bcast:172.20.255.255 Mask:255.255.0.0
inet6 addr: 2001:610:600:93:20c:6eff:fef0:dacd/64 Scope:Global
inet6 addr: fe80::20c:6eff:fef0:dacd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:158 errors:0 dropped:0 overruns:0 frame:0
TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:17978 (17.5 KiB) TX bytes:11424 (11.1 KiB)
Interrupt:92
Signed-off-by: Marcin Juszkiewicz <openembedded@hrw.one.pl>
---
drivers/net/wireless/hostap/hostap_cs.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux/drivers/net/wireless/hostap/hostap_cs.c
===================================================================
--- linux.orig/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:08:25.000000000 +0200
+++ linux/drivers/net/wireless/hostap/hostap_cs.c 2006-05-16 16:10:38.000000000 +0200
@@ -923,6 +923,8 @@
PCMCIA_DEVICE_PROD_ID12(
"ZoomAir 11Mbps High", "Rate wireless Networking",
0x273fe3db, 0x32a1eaee),
+ PCMCIA_DEVICE_PROD_ID1234("ASUS", "802_11B_CF_CARD_25", "Version 01.00", "",
+ 0x78fc06ee, 0x45a50c1e, 0xa57adb8c, 0x00000000),
PCMCIA_DEVICE_NULL
};
MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
I do not fear computers. I fear the lack of them.
-- Isaac Asimov
^ permalink raw reply
* Re: Patches from Marcin Juszkiewicz
From: John W. Linville @ 2006-05-16 13:18 UTC (permalink / raw)
To: Marcin Juszkiewicz; +Cc: netdev, Pavel Roskin, David Gibson
In-Reply-To: <200605152300.45411.linux-arm@hrw.one.pl>
On Mon, May 15, 2006 at 11:00:43PM +0200, Marcin Juszkiewicz wrote:
> Dnia poniedziałek, 15 maja 2006 22:06, John W. Linville napisał:
> > On Fri, May 12, 2006 at 04:43:30PM -0400, Pavel Roskin wrote:
> > > As a co-maintainer of Orinoco driver, I'd like to ask the netdev team
> > > not to apply any patch from Marcin Juszkiewicz touching the Orinoco
> > > driver without my or David's explicit approval.
> >
> > I plan to honor this request.
>
> > Are there any objections?
>
> Not from my side - I updated all hostap patches to not touch orinoco
> driver and can update them to be applied to current netdev git (without
> Pavel Roskin 24_hostap_cs_id.diff patch).
OK. I guess I saw that, but it wasn't clear to me...
Could you resend your current patch series?
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re:
From: Arnaldo Carvalho de Melo @ 2006-05-16 12:34 UTC (permalink / raw)
To: Chris Boot; +Cc: kernel list, netdev, grsecurity
In-Reply-To: <EA629E23-98F8-4CB0-96B0-259C2A30BDFF@bootc.net>
On 5/16/06, Chris Boot <bootc@bootc.net> wrote:
> Hi,
>
> I've just seen the following assertions pop out of one of my servers
> running 2.6.16.9 with grsecurity. I've searched the archives of LKML
> and netdev and I've only found posts relating to 2.6.9, after which
> some related bugs were fixed... It looks like these bugs are related
> to e1000, which is the driver I'm using. The system was running 24
> days before these appeared and it's still running absolutely fine.
>
> May 16 09:15:12 baldrick kernel: [6442250.504000] KERNEL: assertion (!
> sk->sk_forward_alloc) failed at net/core/stream.c (283)
> May 16 09:15:12 baldrick kernel: [6442250.513000] KERNEL: assertion (!
> sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (150)
>
> baldrick bootc # ethtool -k eth0
> Offload parameters for eth0:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp segmentation offload: on
I guess just disable TSO or use latest kernel from git, it has a fix for this.
- Arnaldo
^ permalink raw reply
* [-mm patch] make drivers/net/forcedeth.c:nv_update_pause() static
From: Adrian Bunk @ 2006-05-16 12:16 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Manfred Spraul, linux-kernel, jgarzik, netdev
This patch makes the needlessly global nv_update_pause() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc4-mm1-full/drivers/net/forcedeth.c.old 2006-05-16 13:03:01.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/net/forcedeth.c 2006-05-16 13:03:08.000000000 +0200
@@ -2221,7 +2221,7 @@
spin_unlock_irq(&np->lock);
}
-void nv_update_pause(struct net_device *dev, u32 pause_flags)
+static void nv_update_pause(struct net_device *dev, u32 pause_flags)
{
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
^ permalink raw reply
* Controlling TCP window size
From: Andy Furniss @ 2006-05-16 11:06 UTC (permalink / raw)
To: netdev
I've been doing some testing of my new wan connection and noticed that
when I specify a window with ip route it still changes after a while.
Using 2.6.16.11 and latest iproute2.
ip ro del default
ip ro add default via 192.168.0.1 window 28000
ip ro ls
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3
default via 192.168.0.1 dev eth0 window 28000
timestamps and window scaling are off using reno.
Downloading a 5 meg file I advertise the correct window - the whole
multiple of my mss below 28000 = 27322.
After about 1300 lines of the dump the window creeps back up to 32767.
001959 IP 81.31.115.186.80 > 192.168.0.3.42305: . 1051979:1053417(1438)
ack 123 win 57520
000011 IP 192.168.0.3.42305 > 81.31.115.186.80: . ack 1053417 win 27322
002030 IP 81.31.115.186.80 > 192.168.0.3.42305: . 1053417:1054855(1438)
ack 123 win 57520
001962 IP 81.31.115.186.80 > 192.168.0.3.42305: . 1054855:1056293(1438)
ack 123 win 57520
000011 IP 192.168.0.3.42305 > 81.31.115.186.80: . ack 1056293 win 27322
003020 IP 81.31.115.186.80 > 192.168.0.3.42305: . 1056293:1057731(1438)
ack 123 win 57520
001968 IP 81.31.115.186.80 > 192.168.0.3.42305: . 1057731:1059169(1438)
ack 123 win 57520
000012 IP 192.168.0.3.42305 > 81.31.115.186.80: . ack 1059169 win 30198
002024 IP 81.31.115.186.80 > 192.168.0.3.42305: . 1059169:1060607(1438)
ack 123 win 57520
000012 IP 192.168.0.3.42305 > 81.31.115.186.80: . ack 1060607 win 32767
001980 IP 81.31.115.186.80 > 192.168.0.3.42305: . 1060607:1062045(1438)
ack 123 win 57520
000011 IP 192.168.0.3.42305 > 81.31.115.186.80: . ack 1062045 win 32767
Andy.
^ permalink raw reply
* Re: KERNEL: assertion (!sk->sk_forward_alloc) failed at net/* (again)
From: Ingo Oeser @ 2006-05-16 11:01 UTC (permalink / raw)
To: Chris Boot; +Cc: kernel list, netdev, grsecurity
In-Reply-To: <16537920-30DB-4FF7-BD51-DC8517BF4321@bootc.net>
Hi Chris,
here are some steps to narrow it down.
1. try the latest kernel first (2.6.16.16). This BUG should be fixed there.
2. try without grsecurity patch
3. if it still persists:
Please provide more information about your setup before
submitting a bug.
lspci -vvv and your .config would be the minimum
some ethtool outputs (ethtool -k ethX) would help here.
4. If you like to have it resolved very fast, please try git-bisect.
This can take a lot of time (several recompiles and reboots needed!).
Happy Bug hunting!
Regards
Ingo Oeser
^ permalink raw reply
* Re: KERNEL: assertion (!sk->sk_forward_alloc) failed at net/* (again)
From: Chris Boot @ 2006-05-16 10:53 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: kernel list, netdev, grsecurity
In-Reply-To: <20060516105121.GA18677@2ka.mipt.ru>
On 16 May 2006, at 11:51, Evgeniy Polyakov wrote:
> On Tue, May 16, 2006 at 11:38:38AM +0100, Chris Boot
> (bootc@bootc.net) wrote:
>> May 16 09:15:12 baldrick kernel: [6442250.504000] KERNEL:
>> assertion (!
>> sk->sk_forward_alloc) failed at net/core/stream.c (283)
>> May 16 09:15:12 baldrick kernel: [6442250.513000] KERNEL:
>> assertion (!
>> sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (150)
>>
>> tcp segmentation offload: on
>
> This bug was fixed in .10 in stack and .12 in e1000 driver
> (probably unrelated to your problem, if you do not have packet plit
> option enabled).
Aha, right. Well, I've got an upgrade to .16 ready to go and
scheduled for Friday. What's interesting is that I never saw this
problem come up before, and I've gone through each major interation
of the kernel since 2.6.9...
Cheers,
Chris
--
Chris Boot
bootc@bootc.net
http://www.bootc.net/
^ permalink raw reply
* Re: KERNEL: assertion (!sk->sk_forward_alloc) failed at net/* (again)
From: Evgeniy Polyakov @ 2006-05-16 10:51 UTC (permalink / raw)
To: Chris Boot; +Cc: kernel list, netdev, grsecurity
In-Reply-To: <16537920-30DB-4FF7-BD51-DC8517BF4321@bootc.net>
On Tue, May 16, 2006 at 11:38:38AM +0100, Chris Boot (bootc@bootc.net) wrote:
> May 16 09:15:12 baldrick kernel: [6442250.504000] KERNEL: assertion (!
> sk->sk_forward_alloc) failed at net/core/stream.c (283)
> May 16 09:15:12 baldrick kernel: [6442250.513000] KERNEL: assertion (!
> sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (150)
>
> tcp segmentation offload: on
This bug was fixed in .10 in stack and .12 in e1000 driver
(probably unrelated to your problem, if you do not have packet plit
option enabled).
> Many thanks,
> Chris
--
Evgeniy Polyakov
^ permalink raw reply
* KERNEL: assertion (!sk->sk_forward_alloc) failed at net/* (again)
From: Chris Boot @ 2006-05-16 10:38 UTC (permalink / raw)
To: kernel list, netdev; +Cc: grsecurity
Hi,
Sorry, no subject last time!
I've just seen the following assertions pop out of one of my servers
running 2.6.16.9 with grsecurity. I've searched the archives of LKML
and netdev and I've only found posts relating to 2.6.9, after which
some related bugs were fixed... It looks like these bugs are related
to e1000, which is the driver I'm using. The system was running 24
days before these appeared and it's still running absolutely fine.
May 16 09:15:12 baldrick kernel: [6442250.504000] KERNEL: assertion (!
sk->sk_forward_alloc) failed at net/core/stream.c (283)
May 16 09:15:12 baldrick kernel: [6442250.513000] KERNEL: assertion (!
sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (150)
baldrick bootc # ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
Many thanks,
Chris
PS: I'm not subscribed to netdev.
--
Chris Boot
bootc@bootc.net
http://www.bootc.net/
^ permalink raw reply
* (unknown),
From: Chris Boot @ 2006-05-16 10:34 UTC (permalink / raw)
To: kernel list, netdev; +Cc: grsecurity
Hi,
I've just seen the following assertions pop out of one of my servers
running 2.6.16.9 with grsecurity. I've searched the archives of LKML
and netdev and I've only found posts relating to 2.6.9, after which
some related bugs were fixed... It looks like these bugs are related
to e1000, which is the driver I'm using. The system was running 24
days before these appeared and it's still running absolutely fine.
May 16 09:15:12 baldrick kernel: [6442250.504000] KERNEL: assertion (!
sk->sk_forward_alloc) failed at net/core/stream.c (283)
May 16 09:15:12 baldrick kernel: [6442250.513000] KERNEL: assertion (!
sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (150)
baldrick bootc # ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
Many thanks,
Chris
PS: I'm not subscribed to netdev.
--
Chris Boot
bootc@bootc.net
http://www.bootc.net/
^ permalink raw reply
* We are one of the world leading legal sources for male impotence treatments.
From: Isolde Leon @ 2006-05-16 10:11 UTC (permalink / raw)
To: netdev
Inflame your passion... Tonight!
http://ogbrzvs.a0yif1fxypx0sas3faslfaaa.tullianhf.com/?vktjm
^ permalink raw reply
* [PATCH] reno sacked_out count fix
From: Angelo P. Castellani @ 2006-05-16 9:24 UTC (permalink / raw)
To: netdev; +Cc: francesco, andrea.baiocchi
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Using NewReno, if a sk_buff is timed out and is accounted as lost_out,
it should also be removed from the sacked_out.
This is necessary because recovery using NewReno fast retransmit could
take up to a lot RTTs and the sk_buff RTO can expire without actually
being really lost.
left_out = sacked_out + lost_out
in_flight = packets_out - left_out + retrans_out
Using NewReno without this patch, on very large network losses,
left_out becames bigger than packets_out + retrans_out (!!).
For this reason unsigned integer in_flight overflows to 2^32 - something.
Regards,
Angelo P. Castellani
[-- Attachment #2: reno-fix.diff --]
[-- Type: text/x-patch, Size: 548 bytes --]
diff -urd ../linux-2.6.16-orig/net/ipv4/tcp_input.c ./net/ipv4/tcp_input.c
--- ../linux-2.6.16-orig/net/ipv4/tcp_input.c 2006-05-15 15:42:39.000000000 +0200
+++ ./net/ipv4/tcp_input.c 2006-05-16 11:18:21.000000000 +0200
@@ -1676,6 +1676,8 @@
if (!(TCP_SKB_CB(skb)->sacked&TCPCB_TAGBITS)) {
TCP_SKB_CB(skb)->sacked |= TCPCB_LOST;
tp->lost_out += tcp_skb_pcount(skb);
+ if (IsReno(tp))
+ tcp_remove_reno_sacks(sk, tp, tcp_skb_pcount(skb) + 1);
/* clear xmit_retrans hint */
if (tp->retransmit_skb_hint &&
^ permalink raw reply
* Setting TCP_NODELAY doesn't disable Nagle's alg. on loopback
From: Radko Mihal @ 2006-05-16 8:50 UTC (permalink / raw)
To: netdev
Hi,
We are facing strange problem with disabling the Nagle's algorithm via setting the TCP_NODELAY flag on server socket (setsockopt), where server is communication with client via loopback.
After the first segment (of the response) is sent by server side, server is waiting for ACK instead of continuing sending next segments (as it should use sliding window principle). The client sends ACK after 40 ms, only then server sends the rest of responses packed into one segment. The 40 ms is a big delay and causes reponse processing to be 10 times slower.
The thing doesn't happen, if we move client to another host. In that case the server don't wait for ACK, don't pack responses and also response processing is much faster.
It seems, like on loopback the Nagle's alg. is still acting (citate from alg. description says:"a first segment is sent immediately, while further data on the sender side is buffered until either a full maximum segment can be sent or an acknowledgement for the first segment is received)
I found some descriptions of the same problem, but with no solution!
Is there a bug in setsockopt()? We are using 2.6.5 kernel.
Regards,
Mihal
^ permalink raw reply
* Re: [1/1] netchannel subsystem.
From: Evgeniy Polyakov @ 2006-05-16 7:15 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, kelly, rusty
In-Reply-To: <20060516.000631.12029052.davem@davemloft.net>
On Tue, May 16, 2006 at 12:06:31AM -0700, David S. Miller (davem@davemloft.net) wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Tue, 16 May 2006 10:59:23 +0400
>
> > And what if we use ESP which would place it's hashed sequence number as
> > port?
>
> If it makes you happy put something like:
>
> case TCP:
> case UDP:
> case SCTP:
> case DCCP:
> ...
>
> default:
> ...
That makes sence, but from the other point we loose ability to drop
packet early while checking it's header for correct checksum, sizes and
so on...
--
Evgeniy Polyakov
^ permalink raw reply
* user information reminder
From: Melvin Kurtz @ 2006-05-16 8:11 UTC (permalink / raw)
To: netdev
-S'ensationall revoolution in m'edicine!
-E'n'l'a'r'g'e your p''enis up to 10 cm or up to 4 inches!
-It's herbal solution what hasn't side effect, but has 100% guaranted results!
-Don't lose your chance and but know wihtout doubts, you will be impressed with results!
Clisk here: http://jljgj.info
betoken brunt coagulable abase congolese rut constrictor tasmania acquittal ira
globe doze comprehensible urn cartilage accountant gesture cringe scary
observatory aboveboard cantilever oriental madstone downdraft opacity impress foci daley forklift
appointe chaotic stargaze cardboard elfin harriman reek ky
hattiesburg marrietta backpack ditch prosopopoeia argot cavalry presumption
rectifier preponderate uruguay vincent lippincott borderland abelian radii
^ permalink raw reply
* Re: [1/1] netchannel subsystem.
From: David S. Miller @ 2006-05-16 7:06 UTC (permalink / raw)
To: johnpol; +Cc: netdev, kelly, rusty
In-Reply-To: <20060516065923.GA8649@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Tue, 16 May 2006 10:59:23 +0400
> And what if we use ESP which would place it's hashed sequence number as
> port?
If it makes you happy put something like:
case TCP:
case UDP:
case SCTP:
case DCCP:
...
default:
...
^ permalink raw reply
* Re: [1/1] netchannel subsystem.
From: Evgeniy Polyakov @ 2006-05-16 7:07 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, kelly, rusty
In-Reply-To: <20060516065923.GA8649@2ka.mipt.ru>
On Tue, May 16, 2006 at 10:59:23AM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> On Mon, May 15, 2006 at 11:57:12PM -0700, David S. Miller (davem@davemloft.net) wrote:
> > From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> > Date: Tue, 16 May 2006 10:19:09 +0400
> >
> > > +static int netchannel_convert_skb_ipv4(struct sk_buff *skb, struct unetchannel *unc)
> > > +{
> > ...
> > > + switch (unc->proto) {
> > > + case IPPROTO_TCP:
> > ...
> > > + case IPPROTO_UDP:
> > ...
> >
> > Why do people write code like this?
> >
> > Port location is protocol agnostic, there are always 2
> > 16-bit ports at beginning of header without exception.
> >
> > Without this, ICMP would be useless :-)
>
> And what if we use ESP which would place it's hashed sequence number as
> port?
Actually it should be one big hash, no matter if it is ipv4/tcp or
ipv6/esp, src/dst/sport/dport/proto were created just to allow easier
debug in ipv4 environment.
Attached patch for userspace copy:
--- /tmp/netchannel.1 2006-05-16 10:33:17.000000000 +0400
+++ /tmp/netchannel.2 2006-05-16 11:23:44.000000000 +0400
@@ -35,10 +35,10 @@
diff --git a/include/linux/netchannel.h b/include/linux/netchannel.h
@@ -100,6 +100,7 @@
+
+ struct page * (*nc_alloc_page)(unsigned int size);
+ void (*nc_free_page)(struct page *page);
++ int (*nc_read_data)(struct netchannel *, unsigned int *len, void __user *arg);
+
+ struct sk_buff_head list;
+};
@@ -228,10 +229,10 @@
ret = deliver_skb(skb, pt_prev, orig_dev);
diff --git a/net/core/netchannel.c b/net/core/netchannel.c
--- /dev/null
+++ b/net/core/netchannel.c
-@@ -0,0 +1,583 @@
+@@ -0,0 +1,649 @@
+/*
+ * netchannel.c
+ *
@@ -578,6 +579,40 @@
+ return err;
+}
+
++/*
++ * Actually it should be something like recvmsg().
++ */
++static int netchannel_copy_to_user(struct netchannel *nc, unsigned int *len, void __user *arg)
++{
++ unsigned int copied;
++ struct sk_buff *skb;
++ struct iovec to;
++ int err = -EINVAL;
++
++ to.iov_base = arg;
++ to.iov_len = *len;
++
++ skb = skb_dequeue(&nc->list);
++ if (!skb)
++ return -EAGAIN;
++
++ copied = skb->len;
++ if (copied > *len)
++ copied = *len;
++
++ if (skb->ip_summed==CHECKSUM_UNNECESSARY) {
++ err = skb_copy_datagram_iovec(skb, 0, &to, copied);
++ } else {
++ err = skb_copy_and_csum_datagram_iovec(skb,0, &to);
++ }
++
++ *len = (err == 0)?copied:0;
++
++ kfree_skb(skb);
++
++ return err;
++}
++
+static int netchannel_create(struct unetchannel *unc)
+{
+ struct netchannel *nc;
@@ -612,6 +647,8 @@
+ atomic_set(&nc->refcnt, 1);
+ memcpy(&nc->unc, unc, sizeof(struct unetchannel));
+
++ nc->nc_read_data = &netchannel_copy_to_user;
++
+ hlist_add_head_rcu(&nc->node, &bucket->head);
+
+out_unlock:
@@ -658,6 +695,30 @@
+ return 0;
+}
+
++static int netchannel_recv_data(struct unetchannel_control *ctl, void __user *data)
++{
++ int ret = -ENODEV;
++ struct netchannel_cache_head *bucket;
++ struct netchannel *nc;
++
++ bucket = netchannel_bucket(&ctl->unc);
++
++ mutex_lock(&bucket->mutex);
++
++ nc = netchannel_check_full(&ctl->unc, bucket);
++ if (!nc)
++ nc = netchannel_check_dest(&ctl->unc, bucket);
++
++ if (!nc)
++ goto out_unlock;
++
++ ret = nc->nc_read_data(nc, &ctl->len, data);
++
++out_unlock:
++ mutex_unlock(&bucket->mutex);
++ return ret;
++}
++
+asmlinkage int sys_netchannel_control(void __user *arg)
+{
+ struct unetchannel_control ctl;
@@ -677,10 +738,16 @@
+ case NETCHANNEL_REMOVE:
+ ret = netchannel_remove(&ctl.unc);
+ break;
++ case NETCHANNEL_READ:
++ ret = netchannel_recv_data(&ctl, arg + sizeof(struct unetchannel_control));
++ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
++
++ if (copy_to_user(arg, &ctl, sizeof(struct unetchannel_control)))
++ return -ERESTARTSYS;
+
+ return ret;
+}
--
Evgeniy Polyakov
^ permalink raw reply
* YOU WANT SOME OUTRIGHT SEX - DON'T YOU?
From: Pat Conrad @ 2006-05-16 6:59 UTC (permalink / raw)
To: netdev
The Best Place To Find The Cheapest Medicine.
http://juwv.pxvxugcuv4cf77p0c77iuppp.tullianhf.com/?esuhn
^ 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