* Re: Suspending 802.11 drivers
From: Ivo van Doorn @ 2006-06-15 20:14 UTC (permalink / raw)
To: Michael Buesch; +Cc: Jiri Benc, John W. Linville, netdev, bcm43xx-dev
In-Reply-To: <200606152158.10079.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]
Hi,
> I am currently thinking about the best way to correctly
> implement PM suspending for wireless drivers.
> Currently, the 802.11 stack is not suspend aware (if I talk
> about "stack" here, I mostly mean devicescape).
> For example, if we suspend the bcm43xx driver, we don't
> notify the stack before doing so. That's a bug.
Similar in rt2x00. The basic approach in there is calling
netdev->open() and netdev->stop() which is not the most clean
or correct thing to do.
> I would say, we should have two functions, which are called
> from the driver suspend and resume callbacks.
> Let's call them
> ieee80211_suspend() and ieee80211_resume() for now.
> The suspend would save all status information, for example
> to which AP we are associated and so on. After that it would
> cleanly disassociate from the AP and do other cleanups which
> are needed.
> The resume function would try to re-esablish the connection.
> Of course, that will not always be possible (the notebook
> owner traveled around half the world between suspend and
> resume ;) ). But that does not matter. We simply return silently
> without a new association (Do a new scan, or whatever).
>
> Are such functions generally desireable?
Absolutely, I have been looking into this some time ago as well,
but due to lack of time haven't managed to get anything done.
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] bcm43xx-d80211: fix sending of fragments
From: Jiri Benc @ 2006-06-15 20:27 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, netdev
In-Reply-To: <200606151855.11953.mb@bu3sch.de>
Thu, 15 Jun 2006 18:55:11 +0200, Michael Buesch pise:
> Please also merge the other patch. It is too hard to figure out
> the dependencies for me now. So simply merge it and I will submit
> a fixup patch later, after you pushed it out.
> The Subject was:
> [incomplete 2/5] bcm43xx-d80211: per-queue TX flow control
There is no need to hurry. Let's wait with all my d80211 patches to next
week so people have enough time to go through them and comment. If there
are no objections by start of the next week, I will send a pull request.
Michael, I set up a 'devel' branch in my git repository for you
(git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git); it's
without the bcm43xx patch.
I'm going away now and won't be available till Monday.
> It's not so much of trouble, if we break wireless-dev for one or
> two days, so this is easiest.
> Please notify me after you pushed the stuff to public repository,
> so I can pull and fix it.
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Francois Romieu @ 2006-06-15 20:30 UTC (permalink / raw)
To: Grant Grundler; +Cc: Jeff Garzik, Valerie Henson, Andrew Morton, netdev
In-Reply-To: <20060614223021.GB13212@colo.lackof.org>
Grant Grundler <grundler@parisc-linux.org> :
[shared irq]
> I thought we've worked through that already:
> http://www.spinics.net/lists/netdev/msg05902.html
>
> Patch v3 takes care of that problem.
> The first step in the sequence is to mask IRQs on the tulip.
> The "neighbor" device sharing the IRQ will not see any interrupts from
> the tulip after that.
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.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 5/5] bcm43xx-d80211: fix sending of fragments
From: Michael Buesch @ 2006-06-15 20:35 UTC (permalink / raw)
To: Jiri Benc; +Cc: John W. Linville, netdev
In-Reply-To: <20060615222701.10dddb98@logostar.upir.cz>
On Thursday 15 June 2006 22:27, Jiri Benc wrote:
> Thu, 15 Jun 2006 18:55:11 +0200, Michael Buesch pise:
> > Please also merge the other patch. It is too hard to figure out
> > the dependencies for me now. So simply merge it and I will submit
> > a fixup patch later, after you pushed it out.
> > The Subject was:
> > [incomplete 2/5] bcm43xx-d80211: per-queue TX flow control
>
> There is no need to hurry. Let's wait with all my d80211 patches to next
> week so people have enough time to go through them and comment. If there
> are no objections by start of the next week, I will send a pull request.
>
> Michael, I set up a 'devel' branch in my git repository for you
> (git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git); it's
> without the bcm43xx patch.
Oh, nice. Thanks. I will cook a patch against it.
> I'm going away now and won't be available till Monday.
>
> > It's not so much of trouble, if we break wireless-dev for one or
> > two days, so this is easiest.
> > Please notify me after you pushed the stuff to public repository,
> > so I can pull and fix it.
>
>
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH 1/2] e1000: fix netpoll with NAPI
From: Mitch Williams @ 2006-06-15 20:45 UTC (permalink / raw)
To: John W. Linville
Cc: Williams, Mitch A, Neil Horman, Jeff Moyer, Kok, Auke-jan H,
Matt Mackall, Garzik, Jeff, netdev, Brandeburg, Jesse, Kok, Auke
In-Reply-To: <20060615124355.GA32582@tuxdriver.com>
Andy Grover <andrew.grover@intel.com> is the guy. I'm not sure when he'll
be working on this; it's somewhere in his TODO pile.
On Thu, 15 Jun 2006, John W. Linville wrote:
>
> On Wed, Jun 14, 2006 at 04:44:56PM -0700, Mitch Williams wrote:
>
> > One of our engineers (on the I/O AT team) has been tasked with modifying
> > the Linux kernel to properly support multiple hardware queues (both TX and
> > RX). We'll make sure that he looks at the netpoll interface as part of
> > that process.
>
> Might I ask who this is? I might like to ping him/her on this topic.
> There is potentially some overlap with wireless, at least on the
> transmit side.
>
> John
> --
> John W. Linville
> linville@tuxdriver.com
>
>
>
^ permalink raw reply
* Re: [patch] workaround zd1201 interference problem
From: Pavel Machek @ 2006-06-15 20:47 UTC (permalink / raw)
To: John W. Linville; +Cc: Daniel Drake, Jiri Benc, kernel list, netdev
In-Reply-To: <20060615201024.GD32582@tuxdriver.com>
Hi!
> > > Which operation is the one which stops the interference, the enable or
> > > the disable?
> >
> > Disable alone was not enough to stop interference.
>
> I'm going to drop this patch for now, in the hopes that with Daniel's
> ZyDas contacts you can devise a more palatable solution.
I'd actually like you to keep it, it does not seem ZyDas contacts are
going anywhere.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* 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
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