* Re: Suspending 802.11 drivers
From: Michael Buesch @ 2006-06-15 20:42 UTC (permalink / raw)
To: Florian Fainelli; +Cc: bcm43xx-dev, netdev
In-Reply-To: <200606152213.01631.florian@alphacore.net>
On Thursday 15 June 2006 22:12, Florian Fainelli wrote:
> Hello Michael,
>
> I think these are really interesting functions. Currently I scripted a bit to
> do module unloading/loading on suspend/resume requests plus supplicant
> context saving and restart.
>
> Of course, if the driver is able to manage this by itself, it's far better.
Well, if the _suspend() and _resume() semantics are actually implemented
in kernel or userspace is another question. I would say, it should be possible
to defer it to userspace, after the userspace MLME stuff is done.
But that does not really matter here to get my point. My point is:
ieee80211 subsystem should provide functions which save/restore the
whole state of the stack (Well, the state of running connections and
associations ,actually). How these functions are implemented internally
is another matter.
But I would also say that it sounds sane to put these semantics into
userspace, in the long term.
> Any news on the power management specifications ?
No. I think I will start another attempt to measure the power consumption
of the card, soon. Maybe this time I will be able to figure out the
meaning of the PS bits :) I think I forgot to set important bits
last time I checked.
--
Greetings Michael.
^ permalink raw reply
* Recent stuff Its the best thing you had ever seen!
From: Mack @ 2006-06-15 20:53 UTC (permalink / raw)
To: netdev
Good day to you bro!
Boost your manhood to astonishing levels Everything a real man would ever need.
You are just a couple of clicks away from our great prices and handy shipment
Hot deals on stuff produced by well-known brands from worldwide.
Find what you need: http://www.kyklopescf.com
Come on in and get it all very cheap!
^ permalink raw reply
* Re: [2/2] [BRIDGE]: Add support for NETIF_F_HW_CSUM devices
From: Stephen Hemminger @ 2006-06-15 20:55 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev
In-Reply-To: <20060613112543.GA13253@gondor.apana.org.au>
On Tue, 13 Jun 2006 21:25:43 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Hi:
>
> [BRIDGE]: Add support for NETIF_F_HW_CSUM devices
>
> As it is the bridge will only ever declare NETIF_F_IP_CSUM even if all
> its constituent devices support NETIF_F_HW_CSUM. This patch fixes this
> by supporting the first one out of NETIF_F_NO_CSUM, NETIF_F_HW_CSUM,
> and NETIF_F_IP_CSUM that is supported by all constituent devices.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Cheers,
Looks fine.
^ permalink raw reply
* Re: [patch] workaround zd1201 interference problem
From: Pavel Machek @ 2006-06-15 21:00 UTC (permalink / raw)
To: Daniel Drake; +Cc: Jiri Benc, linville, kernel list, netdev
In-Reply-To: <4489ECD0.1030908@gentoo.org>
Hi!
> Pavel Machek wrote:
> >if you plug zd1201 into USB, it starts jamming radio,
> >immediately. Enable/disable, or iwlist wlan0 scan, or basically any
> >operation unjams the radio. This patch works it around:
>
> Can we be any more specific?
>
> At which precise point does the interference start? Does it happen even
> without the driver loaded?
>
> Which operation is the one which stops the interference, the enable or
> the disable?
enable alone is enough to stop the interference, but leaving card
enabled after load seems like a dirty hack.
> Does this happen on every plug in, or just sometimes? Is it affected by
> usage patterns such as having the device plugged in throughout boot,
> reloading the module, etc?
If I remove the firmware file, interference does not start... that
should be close to "not having module loaded".
I think I've answered all the questions now? :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* What's new in wireless-dev?
From: John W. Linville @ 2006-06-15 21:10 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 3196 bytes --]
The following changes since commit bff7c0afa5a40acf518ae9fbf67e5f93ff9107bc:
John W. Linville:
Merge branch 'from-linus'
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
Jiri Benc:
d80211: deinit sysfs in case of an error
d80211: better sysfs registration of symlinks to wiphy
d80211: separate allocation of ieee80211_local
d80211: fix Oops when writing to add_ and remove_iface
d80211: wiphy sysfs attributes
d80211: network interface sysfs attributes
d80211: rename sta_info_relase to sta_info_put
d80211: sysfs attributes for associated stations
d80211: remove useless parameters
d80211: rate_control sysfs attributes
d80211: encryption keys sysfs attributes
d80211: remove procfs files
John W. Linville:
Merge git://git.kernel.org/.../jbenc/dscape
Michael Buesch:
bcm43xx: Port new locking scheme to d80211
bcm43xx: Port preemptible-periodic-work to d80211
bcm43xx: Port suspend-mac-in-long-pwork from d80211
bcm43xx: Port PIO fixes to d80211
drivers/net/wireless/d80211/bcm43xx/bcm43xx.h | 102 ++-
.../net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c | 33 +
drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.h | 8
drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c | 4
drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c | 287 +++++--
drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c | 9
drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c | 154 +++-
drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.h | 32 +
.../net/wireless/d80211/bcm43xx/bcm43xx_sysfs.c | 38 -
include/linux/netdevice.h | 1
net/d80211/Makefile | 2
net/d80211/ieee80211.c | 206 +++--
net/d80211/ieee80211_dev.c | 17
net/d80211/ieee80211_i.h | 45 +
net/d80211/ieee80211_iface.c | 43 +
net/d80211/ieee80211_ioctl.c | 213 +++---
net/d80211/ieee80211_key.h | 2
net/d80211/ieee80211_proc.c | 771 --------------------
net/d80211/ieee80211_proc.h | 45 -
net/d80211/ieee80211_scan.c | 10
net/d80211/ieee80211_sta.c | 68 +-
net/d80211/ieee80211_sysfs.c | 706 +++++++++++++++++-
net/d80211/ieee80211_sysfs_sta.c | 434 +++++++++++
net/d80211/rate_control.c | 55 +
net/d80211/rate_control.h | 57 +
net/d80211/sta_info.c | 132 ++-
net/d80211/sta_info.h | 16
net/d80211/wme.c | 26 -
28 files changed, 2110 insertions(+), 1406 deletions(-)
delete mode 100644 net/d80211/ieee80211_proc.c
delete mode 100644 net/d80211/ieee80211_proc.h
create mode 100644 net/d80211/ieee80211_sysfs_sta.c
Patch included as attachment due to size concerns.
--
John W. Linville
linville@tuxdriver.com
[-- Attachment #2: wireless-dev.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 33583 bytes --]
^ permalink raw reply
* Pull request for 'upstream' branch
From: Francois Romieu @ 2006-06-15 21:21 UTC (permalink / raw)
To: jeff; +Cc: netdev, palopezv, nacc
Please pull from branch 'upstream' to get the change below:
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
Patch applies both to jeff#upstream and jeff#upstream-fixes
Shortlog
--------
Pedro Alejandro López-Valencia:
sundance: PCI ID for ip100a
Patch
-----
diff --git a/drivers/net/sundance.c b/drivers/net/sundance.c
index 61eec46..f13b2a1 100644
--- a/drivers/net/sundance.c
+++ b/drivers/net/sundance.c
@@ -94,11 +94,13 @@
Version LK1.10 (Philippe De Muyter phdm@macqel.be):
- Make 'unblock interface after Tx underrun' work
+ Version LK1.11 (Pedro Alejandro Lopez-Valencia palopezv at gmail.com):
+ - Add support for IC Plus Corporation IP100A chipset
*/
#define DRV_NAME "sundance"
-#define DRV_VERSION "1.01+LK1.10"
-#define DRV_RELDATE "28-Oct-2005"
+#define DRV_VERSION "1.01+LK1.11"
+#define DRV_RELDATE "14-Jun-2006"
/* The user-configurable values.
@@ -287,6 +289,7 @@ static struct pci_device_id sundance_pci
{0x1186, 0x1002, 0x1186, 0x1040, 0, 0, 3},
{0x1186, 0x1002, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 4},
{0x13F0, 0x0201, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 5},
+ {0x13F0, 0x0200, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 6},
{0,}
};
MODULE_DEVICE_TABLE(pci, sundance_pci_tbl);
@@ -305,6 +308,7 @@ static const struct pci_id_info pci_id_t
{"D-Link DFE-530TXS FAST Ethernet Adapter"},
{"D-Link DL10050-based FAST Ethernet Adapter"},
{"Sundance Technology Alta"},
+ {"IC Plus Corporation IP100A FAST Ethernet Adapter"},
{NULL,}, /* 0 terminated list. */
};
^ permalink raw reply related
* A_D:ÄãÆóÒµ¹ÜÀíµÄÎÊÌâ,ÎÒÃÇͳͳ¿ÉÒÔ½â¾ö
From: NURQbOF92 @ 2006-06-15 21:33 UTC (permalink / raw)
To: KtyKlhAg
StartSoft( starterp.oicp.net ) ÏÖÔÚÒѾӵÓÐÁËÆóÒµ¹ÜÀí
È«Ãæ½â¾ö·½°¸.
ÈκÎÆóÒµ¶¼¿ÉÒÔÑ¡Ôñµ½ËûÃÇÐèÒªµÄÆóÒµ¹ÜÀíÈí¼þ.ÎÞÂÛÊÇÆóÒµ
×ÊÔ´¹ÜÀíERP,»¹ÊÇÍøÂç°ì¹«(OA),ÆóÒµ¹©Ó¦Á´(SCM),¿Í»§¹Øϵ
¹ÜÀí(CRM),ÆóÒµ·ÖÏúϵͳ(ͨÓÃÐÍ£¬µçÄÔÐÐÒµ£¬Í¨Ñ¶ÐÐÒµ£¬·þ×°
Ьҵ£©,¶¼ÓкܺõĽâ¾ö·½°¸.
ÿÌ×ϵͳ´ó¼Ò¿ÉÒÔÔÚÏß²âÊÔ,Èç¹û²»ÊÇb/s½á¹¹µÄ,Ò²ÓвâÊÔ°æ
±¾¿É¹©ÏÂÔØ.
ÒÔÉÏËùÓÐϵͳ½ÔÓÐÔ´ÂëÌṩ,¿ÉÒÔÐ޸ļ°¶þ´Î¿ª·¢.
ϵͳ¼Û¸ñÓÅ»Ý,»¶Ó×Éѯ:0 7 5 5 - 6 1 2 8 7 3 1 1 ²ÜÏÈÉú
E-mail: szcharis@hotmail.com
^ permalink raw reply
* Re: skge wake on lan failing
From: Stephen Hemminger @ 2006-06-15 21:38 UTC (permalink / raw)
To: Sitsofe Wheeler; +Cc: netdev
In-Reply-To: <pan.2006.06.14.21.10.25.592167@yahoo.com>
On Wed, 14 Jun 2006 22:10:26 +0100
Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> Hello,
>
> We have a bunch of PCI D-Link System Inc DGE-530T Gigabit Ethernet cards
> which use the skge driver. However, the link light for a given card goes
> off at the switch during a suspend to ram or power down even though an
> "ethtool -s eth0 wol g" has been issued.
>
> Can anyone shed any light on the problem?
The driver hasn't been tested with Wol. Since I can't get suspend to RAM
work on any of the systems with the board, it has been hard to test.
I'll get to it, but it hasn't been high priority.
^ permalink raw reply
* RE: [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver.
From: Caitlin Bestler @ 2006-06-15 21:45 UTC (permalink / raw)
To: Steve Wise, Bob Sharp; +Cc: openib-general, linux-kernel, netdev
netdev-owner@vger.kernel.org wrote:
> On Thu, 2006-06-15 at 08:41 -0500, Steve Wise wrote:
>> On Wed, 2006-06-14 at 20:35 -0500, Bob Sharp wrote:
>>
>>>> +void c2_ae_event(struct c2_dev *c2dev, u32 mq_index) {
>>>> +
>>
>> <snip>
>>
>>>> + case C2_RES_IND_EP:{
>>>> +
>>>> + struct c2wr_ae_connection_request *req =
>>>> + &wr->ae.ae_connection_request;
>>>> + struct iw_cm_id *cm_id =
>>>> + (struct iw_cm_id *)resource_user_context;
>>>> +
>>>> + pr_debug("C2_RES_IND_EP event_id=%d\n", event_id);
>>>> + if (event_id != CCAE_CONNECTION_REQUEST) {
>>>> + pr_debug("%s: Invalid event_id: %d\n",
>>>> + __FUNCTION__, event_id);
>>>> + break;
>>>> + }
>>>> + cm_event.event = IW_CM_EVENT_CONNECT_REQUEST;
>>>> + cm_event.provider_data = (void*)(unsigned
long)req->cr_handle;
>>>> + cm_event.local_addr.sin_addr.s_addr = req->laddr;
>>>> + cm_event.remote_addr.sin_addr.s_addr = req->raddr;
>>>> + cm_event.local_addr.sin_port = req->lport;
>>>> + cm_event.remote_addr.sin_port = req->rport;
>>>> + cm_event.private_data_len =
>>>> + be32_to_cpu(req->private_data_length);
>>>> +
>>>> + if (cm_event.private_data_len) {
>>>
>>>
>>> It looks to me as if pdata is leaking here since it is not tracked
>>> and the upper layers do not free it. Also, if pdata is freed after
>>> the call to cm_id->event_handler returns, it exposes an issue in
>>> user space where the private data is garbage. I suspect the iwarp
>>> cm should be copying this data before it returns.
>>>
>>
>> Good catch.
>>
>> Yes, I think the IWCM should copy the private data in the upcall. If
>> it does, then the amso driver doesn't need to kmalloc()/copy at all.
>> It can pass a ptr to its MQ entry directly...
>>
>
> Now that I've looked more into this, I'm not sure there's a
> simple way for the IWCM to copy the pdata on the upcall.
> Currently, the IWCM's event upcall, cm_event_handler(),
> simply queues the work for processing on a workqueue thread.
> So there's no per-event logic at all there.
> Lemme think on this more. Stay tuned.
>
> Either way, the amso driver has a memory leak...
>
Having the IWCM copy the pdata during the upcall also leaves
the greatest flexibility for the driver on how/where the pdata
is captured. The IWCM has to deal with user-mode, indefinite
delays waiting for a response and user-mode processes that die
while holding a connection request. So it makes sense for that
layer to do the allocating and copying.
^ permalink raw reply
* RE: [openib-general] [PATCH v2 1/7] AMSO1100 Low Level Driver.
From: Steve Wise @ 2006-06-15 21:58 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: Bob Sharp, openib-general, linux-kernel, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F15767E3@NT-SJCA-0751.brcm.ad.broadcom.com>
> > Now that I've looked more into this, I'm not sure there's a
> > simple way for the IWCM to copy the pdata on the upcall.
> > Currently, the IWCM's event upcall, cm_event_handler(),
> > simply queues the work for processing on a workqueue thread.
> > So there's no per-event logic at all there.
> > Lemme think on this more. Stay tuned.
> >
> > Either way, the amso driver has a memory leak...
> >
>
> Having the IWCM copy the pdata during the upcall also leaves
> the greatest flexibility for the driver on how/where the pdata
> is captured. The IWCM has to deal with user-mode, indefinite
> delays waiting for a response and user-mode processes that die
> while holding a connection request. So it makes sense for that
> layer to do the allocating and copying.
I've already coded and test this. The IWCM will copy the pdata...
Steve.
^ permalink raw reply
* Re: SO_REUSEPORT and multicasting
From: David Stevens @ 2006-06-15 22:29 UTC (permalink / raw)
To: Jason; +Cc: netdev
In-Reply-To: <20060615133132.43716.qmail@web53608.mail.yahoo.com>
If you can send me (or post) the program, I may be able to help.
+-DLS
^ permalink raw reply
* [PATCH 1/6][SCTP]: Limit association max_retrans setting in setsockopt
From: Sridhar Samudrala @ 2006-06-15 22:46 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
Dave,
Please apply the following 6 SCTP patches to 2.6 tree.
Thanks
Sridhar
---------------------------------------------------------------------
[SCTP]: Limit association max_retrans setting in setsockopt.
When using ASSOCINFO socket option, we need to limit the number of
maximum association retransmissions to be no greater than the sum
of all the path retransmissions. This is specified in Section 7.1.2
of the SCTP socket API draft.
However, we only do this if the association has multiple paths. If
there is only one path, the protocol stack will use the
assoc_max_retrans setting when trying to retransmit packets.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
net/sctp/socket.c | 26 +++++++++++++++++++++++++-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2530,8 +2530,32 @@ static int sctp_setsockopt_associnfo(str
/* Set the values to the specific association */
if (asoc) {
- if (assocparams.sasoc_asocmaxrxt != 0)
+ if (assocparams.sasoc_asocmaxrxt != 0) {
+ __u32 path_sum = 0;
+ int paths = 0;
+ struct list_head *pos;
+ struct sctp_transport *peer_addr;
+
+ list_for_each(pos, &asoc->peer.transport_addr_list) {
+ peer_addr = list_entry(pos,
+ struct sctp_transport,
+ transports);
+ path_sum += peer_addr->pathmaxrxt;
+ paths++;
+ }
+
+ /* Only validate asocmaxrxt if we have more then
+ * one path/transport. We do this because path
+ * retransmissions are only counted when we have more
+ * then one path.
+ */
+ if (paths > 1 &&
+ assocparams.sasoc_asocmaxrxt > path_sum)
+ return -EINVAL;
+
asoc->max_retrans = assocparams.sasoc_asocmaxrxt;
+ }
+
if (assocparams.sasoc_cookie_life != 0) {
asoc->cookie_life.tv_sec =
assocparams.sasoc_cookie_life / 1000;
^ permalink raw reply
* [PATCH 2/6][SCTP]: Reject sctp packets with broadcast addresses.
From: Sridhar Samudrala @ 2006-06-15 22:46 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
[SCTP]: Reject sctp packets with broadcast addresses.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
include/net/sctp/structs.h | 3 ++-
net/sctp/input.c | 3 ++-
net/sctp/ipv6.c | 6 ++++--
net/sctp/protocol.c | 8 +++++++-
net/sctp/socket.c | 2 +-
5 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -555,7 +555,8 @@ struct sctp_af {
int (*to_addr_param) (const union sctp_addr *,
union sctp_addr_param *);
int (*addr_valid) (union sctp_addr *,
- struct sctp_sock *);
+ struct sctp_sock *,
+ const struct sk_buff *);
sctp_scope_t (*scope) (union sctp_addr *);
void (*inaddr_any) (union sctp_addr *, unsigned short);
int (*is_any) (const union sctp_addr *);
diff --git a/net/sctp/input.c b/net/sctp/input.c
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -170,7 +170,8 @@ int sctp_rcv(struct sk_buff *skb)
* IP broadcast addresses cannot be used in an SCTP transport
* address."
*/
- if (!af->addr_valid(&src, NULL) || !af->addr_valid(&dest, NULL))
+ if (!af->addr_valid(&src, NULL, skb) ||
+ !af->addr_valid(&dest, NULL, skb))
goto discard_it;
asoc = __sctp_rcv_lookup(skb, &src, &dest, &transport);
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -523,7 +523,9 @@ static int sctp_v6_available(union sctp_
* Return 0 - If the address is a non-unicast or an illegal address.
* Return 1 - If the address is a unicast.
*/
-static int sctp_v6_addr_valid(union sctp_addr *addr, struct sctp_sock *sp)
+static int sctp_v6_addr_valid(union sctp_addr *addr,
+ struct sctp_sock *sp,
+ const struct sk_buff *skb)
{
int ret = ipv6_addr_type(&addr->v6.sin6_addr);
@@ -537,7 +539,7 @@ static int sctp_v6_addr_valid(union sctp
if (sp && ipv6_only_sock(sctp_opt2sk(sp)))
return 0;
sctp_v6_map_v4(addr);
- return sctp_get_af_specific(AF_INET)->addr_valid(addr, sp);
+ return sctp_get_af_specific(AF_INET)->addr_valid(addr, sp, skb);
}
/* Is this a non-unicast address */
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -365,12 +365,18 @@ static int sctp_v4_is_any(const union sc
* Return 0 - If the address is a non-unicast or an illegal address.
* Return 1 - If the address is a unicast.
*/
-static int sctp_v4_addr_valid(union sctp_addr *addr, struct sctp_sock *sp)
+static int sctp_v4_addr_valid(union sctp_addr *addr,
+ struct sctp_sock *sp,
+ const struct sk_buff *skb)
{
/* Is this a non-unicast address or a unusable SCTP address? */
if (IS_IPV4_UNUSABLE_ADDRESS(&addr->v4.sin_addr.s_addr))
return 0;
+ /* Is this a broadcast address? */
+ if (skb && ((struct rtable *)skb->dst)->rt_flags & RTCF_BROADCAST)
+ return 0;
+
return 1;
}
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -172,7 +172,7 @@ static inline int sctp_verify_addr(struc
return -EINVAL;
/* Is this a valid SCTP address? */
- if (!af->addr_valid(addr, sctp_sk(sk)))
+ if (!af->addr_valid(addr, sctp_sk(sk), NULL))
return -EINVAL;
if (!sctp_sk(sk)->pf->send_verify(sctp_sk(sk), (addr)))
^ permalink raw reply
* [PATCH 3/6][SCTP] Reset rtt_in_progress for the chunk when processing its sack.
From: Sridhar Samudrala @ 2006-06-15 22:46 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
[SCTP] Reset rtt_in_progress for the chunk when processing its sack.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
include/net/sctp/sctp.h | 2 +-
net/sctp/outqueue.c | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -255,7 +255,7 @@ #define SCTP_DEBUG_PRINTK(whatever...)
#define SCTP_DEBUG_PRINTK_IPADDR(whatever...)
#define SCTP_ENABLE_DEBUG
#define SCTP_DISABLE_DEBUG
-#define SCTP_ASSERT(expr, str, func)
+#define SCTP_ASSERT(expr, str, func) BUG_ON(!(expr))
#endif /* SCTP_DEBUG */
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -1262,6 +1262,7 @@ #endif /* SCTP_DEBUG */
if (!tchunk->tsn_gap_acked &&
!tchunk->resent &&
tchunk->rtt_in_progress) {
+ tchunk->rtt_in_progress = 0;
rtt = jiffies - tchunk->sent_at;
sctp_transport_update_rto(transport,
rtt);
^ permalink raw reply
* [PATCH 4/6][SCTP]: Don't do CRC32C checksum over loopback.
From: Sridhar Samudrala @ 2006-06-15 22:46 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
[SCTP]: Don't do CRC32C checksum over loopback.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
net/sctp/input.c | 3 ++-
net/sctp/output.c | 48 +++++++++++++++++++++++++++---------------------
2 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/net/sctp/input.c b/net/sctp/input.c
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -141,7 +141,8 @@ int sctp_rcv(struct sk_buff *skb)
__skb_pull(skb, skb->h.raw - skb->data);
if (skb->len < sizeof(struct sctphdr))
goto discard_it;
- if (sctp_rcv_checksum(skb) < 0)
+ if ((skb->ip_summed != CHECKSUM_UNNECESSARY) &&
+ (sctp_rcv_checksum(skb) < 0))
goto discard_it;
skb_pull(skb, sizeof(struct sctphdr));
diff --git a/net/sctp/output.c b/net/sctp/output.c
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -295,14 +295,14 @@ int sctp_packet_transmit(struct sctp_pac
struct sctp_transport *tp = packet->transport;
struct sctp_association *asoc = tp->asoc;
struct sctphdr *sh;
- __u32 crc32;
+ __u32 crc32 = 0;
struct sk_buff *nskb;
struct sctp_chunk *chunk, *tmp;
struct sock *sk;
int err = 0;
int padding; /* How much padding do we need? */
__u8 has_data = 0;
- struct dst_entry *dst;
+ struct dst_entry *dst = tp->dst;
SCTP_DEBUG_PRINTK("%s: packet:%p\n", __FUNCTION__, packet);
@@ -327,6 +327,19 @@ int sctp_packet_transmit(struct sctp_pac
*/
skb_set_owner_w(nskb, sk);
+ /* The 'obsolete' field of dst is set to 2 when a dst is freed. */
+ if (!dst || (dst->obsolete > 1)) {
+ dst_release(dst);
+ sctp_transport_route(tp, NULL, sctp_sk(sk));
+ if (asoc && (asoc->param_flags & SPP_PMTUD_ENABLE)) {
+ sctp_assoc_sync_pmtu(asoc);
+ }
+ }
+ nskb->dst = dst_clone(tp->dst);
+ if (!nskb->dst)
+ goto no_route;
+ dst = nskb->dst;
+
/* Build the SCTP header. */
sh = (struct sctphdr *)skb_push(nskb, sizeof(struct sctphdr));
sh->source = htons(packet->source_port);
@@ -350,7 +363,8 @@ int sctp_packet_transmit(struct sctp_pac
* Note: Adler-32 is no longer applicable, as has been replaced
* by CRC32-C as described in <draft-ietf-tsvwg-sctpcsum-02.txt>.
*/
- crc32 = sctp_start_cksum((__u8 *)sh, sizeof(struct sctphdr));
+ if (!(dst->dev->features & NETIF_F_NO_CSUM))
+ crc32 = sctp_start_cksum((__u8 *)sh, sizeof(struct sctphdr));
/**
* 6.10 Bundling
@@ -402,9 +416,14 @@ int sctp_packet_transmit(struct sctp_pac
if (padding)
memset(skb_put(chunk->skb, padding), 0, padding);
- crc32 = sctp_update_copy_cksum(skb_put(nskb, chunk->skb->len),
- chunk->skb->data,
- chunk->skb->len, crc32);
+ if (dst->dev->features & NETIF_F_NO_CSUM)
+ memcpy(skb_put(nskb, chunk->skb->len),
+ chunk->skb->data, chunk->skb->len);
+ else
+ crc32 = sctp_update_copy_cksum(skb_put(nskb,
+ chunk->skb->len),
+ chunk->skb->data,
+ chunk->skb->len, crc32);
SCTP_DEBUG_PRINTK("%s %p[%s] %s 0x%x, %s %d, %s %d, %s %d\n",
"*** Chunk", chunk,
@@ -427,7 +446,8 @@ int sctp_packet_transmit(struct sctp_pac
}
/* Perform final transformation on checksum. */
- crc32 = sctp_end_cksum(crc32);
+ if (!(dst->dev->features & NETIF_F_NO_CSUM))
+ crc32 = sctp_end_cksum(crc32);
/* 3) Put the resultant value into the checksum field in the
* common header, and leave the rest of the bits unchanged.
@@ -477,20 +497,6 @@ int sctp_packet_transmit(struct sctp_pac
}
}
- dst = tp->dst;
- /* The 'obsolete' field of dst is set to 2 when a dst is freed. */
- if (!dst || (dst->obsolete > 1)) {
- dst_release(dst);
- sctp_transport_route(tp, NULL, sctp_sk(sk));
- if (asoc->param_flags & SPP_PMTUD_ENABLE) {
- sctp_assoc_sync_pmtu(asoc);
- }
- }
-
- nskb->dst = dst_clone(tp->dst);
- if (!nskb->dst)
- goto no_route;
-
SCTP_DEBUG_PRINTK("***sctp_transmit_packet*** skb len %d\n",
nskb->len);
^ permalink raw reply
* [PATCH 5/6][SCTP]: Send only 1 window update SACK per message.
From: Sridhar Samudrala @ 2006-06-15 22:46 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
[SCTP]: Send only 1 window update SACK per message.
Right now, every time we increase our rwnd by more then MTU bytes, we
trigger a SACK. When processing large messages, this will generate a
SACK for almost every other SCTP fragment. However since we are freeing
the entire message at the same time, we might as well collapse the SACK
generation to 1.
Signed-off-by: Tsutomu Fujii <t-fujii@nb.jp.nec.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
net/sctp/ulpevent.c | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c
--- a/net/sctp/ulpevent.c
+++ b/net/sctp/ulpevent.c
@@ -51,6 +51,8 @@ #include <net/sctp/sm.h>
static void sctp_ulpevent_receive_data(struct sctp_ulpevent *event,
struct sctp_association *asoc);
static void sctp_ulpevent_release_data(struct sctp_ulpevent *event);
+static void sctp_ulpevent_release_frag_data(struct sctp_ulpevent *event);
+
/* Initialize an ULP event from an given skb. */
SCTP_STATIC void sctp_ulpevent_init(struct sctp_ulpevent *event, int msg_flags)
@@ -883,6 +885,7 @@ static void sctp_ulpevent_receive_data(s
static void sctp_ulpevent_release_data(struct sctp_ulpevent *event)
{
struct sk_buff *skb, *frag;
+ unsigned int len;
/* Current stack structures assume that the rcv buffer is
* per socket. For UDP style sockets this is not true as
@@ -892,7 +895,30 @@ static void sctp_ulpevent_release_data(s
*/
skb = sctp_event2skb(event);
- sctp_assoc_rwnd_increase(event->asoc, skb_headlen(skb));
+ len = skb->len;
+
+ if (!skb->data_len)
+ goto done;
+
+ /* Don't forget the fragments. */
+ for (frag = skb_shinfo(skb)->frag_list; frag; frag = frag->next) {
+ /* NOTE: skb_shinfos are recursive. Although IP returns
+ * skb's with only 1 level of fragments, SCTP reassembly can
+ * increase the levels.
+ */
+ sctp_ulpevent_release_frag_data(sctp_skb2event(frag));
+ }
+
+done:
+ sctp_assoc_rwnd_increase(event->asoc, len);
+ sctp_ulpevent_release_owner(event);
+}
+
+static void sctp_ulpevent_release_frag_data(struct sctp_ulpevent *event)
+{
+ struct sk_buff *skb, *frag;
+
+ skb = sctp_event2skb(event);
if (!skb->data_len)
goto done;
@@ -903,7 +929,7 @@ static void sctp_ulpevent_release_data(s
* skb's with only 1 level of fragments, SCTP reassembly can
* increase the levels.
*/
- sctp_ulpevent_release_data(sctp_skb2event(frag));
+ sctp_ulpevent_release_frag_data(sctp_skb2event(frag));
}
done:
^ permalink raw reply
* [PATCH 6/6][SCTP]: Fix persistent slowdown in sctp when a gap ack consumes rx buffer.
From: Sridhar Samudrala @ 2006-06-15 22:46 UTC (permalink / raw)
To: davem; +Cc: netdev, lksctp-developers
[SCTP]: Fix persistent slowdown in sctp when a gap ack consumes rx buffer.
In the event that our entire receive buffer is full with a series of
chunks that represent a single gap-ack, and then we accept a chunk
(or chunks) that fill in the gap between the ctsn and the first gap,
we renege chunks from the end of the buffer, which effectively does
nothing but move our gap to the end of our received tsn stream. This
does little but move our missing tsns down stream a little, and, if the
sender is sending sufficiently large retransmit frames, the result is a
perpetual slowdown which can never be recovered from, since the only
chunk that can be accepted to allow progress in the tsn stream necessitates
that a new gap be created to make room for it. This leads to a constant
need for retransmits, and subsequent receiver stalls. The fix I've come up
with is to deliver the frame without reneging if we have a full receive
buffer and the receiving sockets sk_receive_queue is empty(indicating that
the receive buffer is being blocked by a missing tsn).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
---
net/sctp/sm_statefuns.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -5293,10 +5293,18 @@ static int sctp_eat_data(const struct sc
* seems a bit troublesome in that frag_point varies based on
* PMTU. In cases, such as loopback, this might be a rather
* large spill over.
+ * NOTE: If we have a full receive buffer here, we only renege if
+ * our receiver can still make progress without the tsn being
+ * received. We do this because in the event that the associations
+ * receive queue is empty we are filling a leading gap, and since
+ * reneging moves the gap to the end of the tsn stream, we are likely
+ * to stall again very shortly. Avoiding the renege when we fill a
+ * leading gap is a good heuristic for avoiding such steady state
+ * stalls.
*/
if (!asoc->rwnd || asoc->rwnd_over ||
(datalen > asoc->rwnd + asoc->frag_point) ||
- rcvbuf_over) {
+ (rcvbuf_over && (!skb_queue_len(&sk->sk_receive_queue)))) {
/* If this is the next TSN, consider reneging to make
* room. Note: Playing nice with a confused sender. A
^ permalink raw reply
* Question: Virtual device error return is mangled
From: Mark Huth @ 2006-06-15 23:33 UTC (permalink / raw)
To: netdev
Why does net/core/dev.c: dev_queue_transmit not pass back the actual
status from hard_start_xmit in the case of a virtual device, and why is
an error return considered a critical kernel error?
ie why:
if (!dev->hard_start_xmit(skb, dev)) {
...
rc = -ENETDOWN;
...
return rc;
instead of :
if (!rc = dev->hard_start_xmit(skb, dev)) {
...
...
return rc;
In the case of a real device, a qdisc error gets returned up the stack,
while in the case of say a bonding device enslaving the real device and
encountering the same error, success gets returned up the stack. The
various virtual devices seem to return success whatever happens, but it
seems like this behavior is chosen due to the fact that the real status
cannot be passed back, even if the virtural device manages the skb ref
count correctly, as dev_queue_transmit will turn it into -ENETDOWN.
Thanks,
Mark Huth
^ permalink raw reply
* Re: [Ubuntu PATCH] Broadcom wireless patch, PCIE/Mactel support
From: Arjan van de Ven @ 2006-06-15 15:41 UTC (permalink / raw)
To: Randy Dunlap; +Cc: lkml, netdev, mb, akpm
In-Reply-To: <44909A3F.4090905@oracle.com>
On Wed, 2006-06-14 at 16:22 -0700, Randy Dunlap wrote:
> From: Matthew Garrett <mjg59@srcf.ucam.org>
>
> Broadcom wireless patch, PCIE/Mactel support
>
> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f4422ddea00929c8a4cc
>
> This patch adds support for PCIE cores to the bcm43xx driver. This is
> needed for wireless to work on the Intel imacs. I've submitted it to
> bcm43xx upstream.
who's signing off on these patches??
^ permalink raw reply
* Question: query for Interface MIB "ifInNUcastPkts "
From: Wei Dong @ 2006-06-16 3:36 UTC (permalink / raw)
To: netdev
Cc: linux.nics, scott.feldman, jesse.brandeburg, john.ronciak,
auke-jan.h.kok, auke
Hi, All
Now I want to test interface MIB(according to RFC1213), and found that
ifInNUcastPkts doesn't exist in Linux kernel. The kernel maintain a
structure "net_device_stats", but it just contain a member named "multicast"
to show how many multicast packets are received, but no member to show how
many broadcast packets are received. Also, I think ifInNUcastPkts should
equal to broadcast + multicast. Or there is some other statistic value to
show "ifInNUcastPkts"?
RFC1213
INTERNET CONTROL MESSAGE PROTOCOL
ifInNUcastPkts OBJECT-TYP
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of non-unicast (i.e., subnetwork-
broadcast or subnetwork-multicast) packets
delivered to a higher-layer protocol."
::= { ifEntry 12 }
Any help is grateful and thanks in advance.
Regards
Wei Dong
^ permalink raw reply
* Re: [RFC] [patch 0/6] [Network namespace] introduction
From: Eric W. Biederman @ 2006-06-16 4:23 UTC (permalink / raw)
To: dlezcano; +Cc: serue, haveblue, clg, dlezcano, linux-kernel, netdev
In-Reply-To: <20060609210202.215291000@localhost.localdomain>
My apologies for not looking at this earlier I had an email
hickup so I'm having to recreate the context from email archives,
and you didn't copy me.
Have you seen my previous work in this direction?
I know I had a much much more complete implementation. The only part
I had not completed was iptables support and that was about a days
more work.
> The following patches create a private "network namespace" for use
> within containers. This is intended for use with system containers
> like vserver, but might also be useful for restricting individual
> applications' access to the network stack.
>
> These patches isolate traffic inside the network namespace. The
> network ressources, the incoming and the outgoing packets are
> identified to be related to a namespace.
>
> It hides network resource not contained in the current namespace, but
> still allows administration of the network with normal commands like
> ifconfig.
>
> It applies to the kernel version 2.6.17-rc6-mm1
A couple of comments.
> ------------
> - do unshare with the CLONE_NEWNET flag as root
> - do echo eth0 > /sys/kernel/debug/net_ns/dev
> - use ifconfig or ip command to set a new ip address
>
> What is missing ?
> -----------------
> The routes are not yet isolated, that implies:
>
> - binding to another container's address is allowed
>
> - an outgoing packet which has an unset source address can
> potentially get another container's address
>
> - an incoming packet can be routed to the wrong container if there
> are several containers listening to the same addr:port
I haven't looked at the patches in enough detail to see how the network
isolation is being done exactly. But some of these comments and some
of the other pieces I have seen don't give me warm fuzzies.
In particular I did not see a provision for multiple instance of
the loopback device.
As a general rule network sockets and network devices should be attached
to the network namespaces, which basically preserves all of the existing
network stack logic.
Basically this means that the only operations that get more expensive
are reads of global variables, which take a necessary extra indirection.
As a general rule I found that it usually makes sense to add an additional
namespace field to hash tables so they can still use the boot time
memory allocator. Although if you already have a network device as
part of your hash table key that isn't necessary for the network
stack.
Eric
^ permalink raw reply
* Re: [Ubuntu PATCH] Broadcom wireless patch, PCIE/Mactel support
From: Randy Dunlap @ 2006-06-16 5:39 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: lkml, netdev, mb, akpm
In-Reply-To: <1150386115.2987.7.camel@laptopd505.fenrus.org>
Arjan van de Ven wrote:
> On Wed, 2006-06-14 at 16:22 -0700, Randy Dunlap wrote:
>> From: Matthew Garrett <mjg59@srcf.ucam.org>
>>
>> Broadcom wireless patch, PCIE/Mactel support
>>
>> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f4422ddea00929c8a4cc
>>
>> This patch adds support for PCIE cores to the bcm43xx driver. This is
>> needed for wireless to work on the Intel imacs. I've submitted it to
>> bcm43xx upstream.
>
>
> who's signing off on these patches??
Well, this particular one isn't going anywhere AFAIK, so it doesn't matter here.
For most of them, Ben Collins or someone else at Ubuntu has signed-off on them
(although not so on this one).
Let's continue the general discussion on the "reviewing" thread.
~Randy
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-16 5:47 UTC (permalink / raw)
To: Francois Romieu
Cc: Grant Grundler, Jeff Garzik, Valerie Henson, Andrew Morton,
netdev
In-Reply-To: <20060615203017.GA6724@electric-eye.fr.zoreil.com>
On Thu, Jun 15, 2006 at 10:30:17PM +0200, Francois Romieu wrote:
> Afaik free_irq() on a shared irq does not touch the hardware and
> irqs are anything but synchronous. If free_irq() is issued before
> the device is idle and its irq are not acked, it's wrong.
Correct. Before calling free_irq(), patch V3 masks interrupts on tulip
and guarantees the tulip will not generate new interrupts before that call.
grant
^ permalink raw reply
* [ETHTOOL]: Fix UFO typo
From: Herbert Xu @ 2006-06-16 6:39 UTC (permalink / raw)
To: David S. Miller, netdev
[-- Attachment #1: Type: text/plain, Size: 395 bytes --]
Hi Dave:
[ETHTOOL]: Fix UFO typo
The function ethtool_get_ufo was referring to ETHTOOL_GTSO instead of
ETHTOOL_GUFO.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: ufo-typo.patch --]
[-- Type: text/plain, Size: 637 bytes --]
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 3f269e4..151dd98 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -589,7 +589,7 @@ static int ethtool_set_tso(struct net_de
static int ethtool_get_ufo(struct net_device *dev, char __user *useraddr)
{
- struct ethtool_value edata = { ETHTOOL_GTSO };
+ struct ethtool_value edata = { ETHTOOL_GUFO };
if (!dev->ethtool_ops->get_ufo)
return -EOPNOTSUPP;
@@ -598,6 +598,7 @@ static int ethtool_get_ufo(struct net_de
return -EFAULT;
return 0;
}
+
static int ethtool_set_ufo(struct net_device *dev, char __user *useraddr)
{
struct ethtool_value edata;
^ permalink raw reply related
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Jeff Garzik @ 2006-06-16 7:32 UTC (permalink / raw)
To: Grant Grundler; +Cc: Francois Romieu, Valerie Henson, Andrew Morton, netdev
In-Reply-To: <20060616054711.GA28524@colo.lackof.org>
Grant Grundler wrote:
> On Thu, Jun 15, 2006 at 10:30:17PM +0200, Francois Romieu wrote:
>> Afaik free_irq() on a shared irq does not touch the hardware and
>> irqs are anything but synchronous. If free_irq() is issued before
>> the device is idle and its irq are not acked, it's wrong.
>
> Correct. Before calling free_irq(), patch V3 masks interrupts on tulip
> and guarantees the tulip will not generate new interrupts before that call.
Incorrect -- it does not guarantee that tulip will not generate new
interrupt events.
Jeff
^ 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