* [PATCH 2/2] e1000: Use deferrable timer for watchdog
From: Auke Kok @ 2007-12-20 18:51 UTC (permalink / raw)
To: jeff; +Cc: netdev, parag.warudkar
In-Reply-To: <20071220185125.21903.44752.stgit@localhost.localdomain>
From: Parag Warudkar <parag.warudkar@gmail.com>
Reduces wakeups from idle per second.
Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000/e1000_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 599153d..6af86fa 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1066,7 +1066,7 @@ e1000_probe(struct pci_dev *pdev,
adapter->tx_fifo_stall_timer.function = &e1000_82547_tx_fifo_stall;
adapter->tx_fifo_stall_timer.data = (unsigned long) adapter;
- init_timer(&adapter->watchdog_timer);
+ init_timer_deferrable(&adapter->watchdog_timer);
adapter->watchdog_timer.function = &e1000_watchdog;
adapter->watchdog_timer.data = (unsigned long) adapter;
^ permalink raw reply related
* Re: [PATCH 2/2] net: neighbor timer power saving
From: Parag Warudkar @ 2007-12-20 18:16 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, David Miller, netdev, akpm
In-Reply-To: <20071220091005.310ab2f8@deepthought>
On Dec 20, 2007 12:10 PM, Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
> Thinking about it more, this looks like a case for just using round_jiffies().
> The GC timer needs to run to clean up under DoS attack, and deferring it probably
> isn't a good idea.
But what are the chances that a DoSed machine will be idling which
will prevent the GC timer to run? I would think there would be lot of
other activities going on (including non-deferrable timers running)
that will avoid this situation?
Parag
^ permalink raw reply
* Re: [PATCH] sky2: Use deferrable timer for watchdog
From: Parag Warudkar @ 2007-12-20 18:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, akpm, linux-kernel
In-Reply-To: <20071220095121.7859c023@deepthought>
On Dec 20, 2007 12:51 PM, Stephen Hemminger
<shemminger@linux-foundation.org> wrote:
>
> Quit top-posting!
>
> If this is the case then the whole usage of round_jiffies() is bogus. All users of round_jiffies()
> should just be converted to deferrable?? I am a bit concerned that if deferrable gets used everywhere
> then a strange situation would occur where all timers were waiting for some other timer to finally
> happen, kind of a wierd timelock situation. Like the old chip/dale cartoon:
> "you first, no you first, after you mister chip, no after you mister dale,..."
>
Haha - I thought about this too. I think there should be mechanism
where the machine does not idle infinitely even if there are no
non-deferrable timers. Something like an affordable QoS for non
deferrable timers - the kernel wakes up after that interval and runs
all deferrable timers even if nothing non-deferrable is set to run.
So we still get advantage of not having to wake individually for each
timer and the non-deferrable timers do get all run in reasonable
amount of time.
Who knows Thomas/Ingo already built in something of that nature or effect?!
Parag
^ permalink raw reply
* Re: [PATCH] e1000e: Use deferrable timer for watchdog
From: Parag Warudkar @ 2007-12-20 17:56 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, linux-kernel, akpm
In-Reply-To: <476AA0C3.2080503@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
On Dec 20, 2007 12:05 PM, Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>
> I can't even apply this patch and the e1000 one... not only is it whitespace
> damaged it is also not properly formatted as patch at all. If you want me to take
> these patches seriously, then please fix the formatting issues.
Sigh - I use Pine, follow Documents/email-clients.txt for the
recommended settings and obviously the pathces are not generated with
whitespace damage at my end as I test those before sending out.
So although I hate to see this happen there is nothing at this moment
that I can do - except for attaching the patch instead of inlining it.
Since they have already been reviewed inline, please see if the
attached patches work for you.
[parag@mini linux-2.6]$ scripts/checkpatch.pl --no-tree
../../Patches/e1000_main.c.patch
total: 0 errors, 0 warnings, 8 lines checked
Your patch has no obvious style problems and is ready for submission.
[parag@mini linux-2.6]$
[parag@mini linux-2.6]$ vim drivers/net/e1000/e1000_main.c
[parag@mini linux-2.6]$ patch -p1 < ../../Patches/e1000_main.c.patch
patching file drivers/net/e1000/e1000_main.c
[parag@mini linux-2.6]$ scripts/checkpatch.pl --no-tree
../../Patches/e1000e-netdev.c.patch
total: 0 errors, 0 warnings, 8 lines checked
Your patch has no obvious style problems and is ready for submission.
[parag@mini linux-2.6]$ patch -p1 < ../../Patches/e1000e-netdev.c.patch
patching file drivers/net/e1000e/netdev.c
Thanks
Parag
[-- Attachment #2: e1000_main.c.patch --]
[-- Type: application/octet-stream, Size: 587 bytes --]
Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
--- linux-2.6/drivers/net/e1000/e1000_main.c 2007-12-07 10:04:39.000000000 -0500
+++ linux-2.6-work/drivers/net/e1000/e1000_main.c 2007-12-18 20:38:38.000000000 -0500
@@ -1030,7 +1030,7 @@
adapter->tx_fifo_stall_timer.function = &e1000_82547_tx_fifo_stall;
adapter->tx_fifo_stall_timer.data = (unsigned long) adapter;
- init_timer(&adapter->watchdog_timer);
+ init_timer_deferrable(&adapter->watchdog_timer);
adapter->watchdog_timer.function = &e1000_watchdog;
adapter->watchdog_timer.data = (unsigned long) adapter;
[-- Attachment #3: e1000e-netdev.c.patch --]
[-- Type: application/octet-stream, Size: 472 bytes --]
Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
--- linux-2.6/drivers/net/e1000e/netdev.c 2007-12-07 10:04:39.000000000 -0500
+++ linux-2.6-work/drivers/net/e1000e/netdev.c 2007-12-18 20:45:59.000000000 -0500
@@ -3899,7 +3899,7 @@
goto err_eeprom;
}
- init_timer(&adapter->watchdog_timer);
+ init_timer_deferrable(&adapter->watchdog_timer);
adapter->watchdog_timer.function = &e1000_watchdog;
adapter->watchdog_timer.data = (unsigned long) adapter;
^ permalink raw reply
* Re: [PATCH] sky2: Use deferrable timer for watchdog
From: Stephen Hemminger @ 2007-12-20 17:51 UTC (permalink / raw)
To: parag.warudkar; +Cc: netdev, akpm, linux-kernel
In-Reply-To: <823114761-1198171803-cardhu_decombobulator_blackberry.rim.net-937108990-@bxe019.bisx.prod.on.blackberry>
On Thu, 20 Dec 2007 17:29:23 +0000
>
> -----Original Message-----
> From: Stephen Hemminger <shemminger@linux-foundation.org>
>
> Date: Thu, 20 Dec 2007 09:16:03
> To:parag.warudkar@gmail.com
> Cc:netdev@vger.kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] sky2: Use deferrable timer for watchdog
>
>
> On Tue, 18 Dec 2007 20:13:28 -0500 (EST)
> Parag Warudkar <parag.warudkar@gmail.com> wrote:
>
> >
> > sky2 can use deferrable timer for watchdog - reduces wakeups from idle per
> > second.
> >
> > Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
> >
> > --- linux-2.6/drivers/net/sky2.c 2007-12-07 10:04:39.000000000 -0500
> > +++ linux-2.6-work/drivers/net/sky2.c 2007-12-18 20:07:58.000000000 -0500
> > @@ -4230,7 +4230,10 @@
> > sky2_show_addr(dev1);
> > }
> >
> > - setup_timer(&hw->watchdog_timer, sky2_watchdog, (unsigned long) hw);
> > + hw->watchdog_timer.function = sky2_watchdog;
> > + hw->watchdog_timer.data = (unsigned long) hw;
> > + init_timer_deferrable(&hw->watchdog_timer);
> > +
> > INIT_WORK(&hw->restart_work, sky2_restart);
> >
> > pci_set_drvdata(pdev, hw);
>
> Does it really reduce the wakeup's or only change who gets charged by powertop?
> The system is going to wakeup once a second anyway. Looks to me that if the
> timer is using round_jiffies(), that setting deferrable just changes the accounting.
>
> My interpretation of the api is:
> * round_jiffies() - timer wants to wakeup but isn't precise about when so schedule
> on next second when system will wake up anyway;
> e.g why meetings are usually scheduled on the hour
>
> * deferrable - timer doesn't have to really wakeup but wants to happen near
> a particular time. e.g. "I'll meet you at the pub around 8pm"
>
> Therefore doing deferrable is unnecessary for timers using round_jiffies unless system
> is so good at doing timers that it is going to skip doing timer once per second.
>
parag.warudkar@gmail.com wrote:
> NO_HZ kernels don't do timers every second - if you do round_jiffies() the kernel will wakeup and run the timer at that time no matter what.
>
> The reason deferrable was introduced is to avoid waking up the kernel just for this one timer that can be called when the CPU is not idle for some reason other than this timer.
>
> In other words let's say there were two timers - one non-deferrable expiring in 3 seconds and other deferrable, expiring in 1.5 seconds. The kernel will not wake up twice - once for 1.5 second and other for 3 second - it will wake up once at expiry of 3 second timer and execute both the 1.5 second and 3 second timers.
>
> And this is not just powertop accounting thing - like I said the total num of wakeups per second go down with this patch.
>
> Parag
>
> Sent via BlackBerry from T-Mobile
Quit top-posting!
If this is the case then the whole usage of round_jiffies() is bogus. All users of round_jiffies()
should just be converted to deferrable?? I am a bit concerned that if deferrable gets used everywhere
then a strange situation would occur where all timers were waiting for some other timer to finally
happen, kind of a wierd timelock situation. Like the old chip/dale cartoon:
"you first, no you first, after you mister chip, no after you mister dale,..."
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH] e1000e: Use deferrable timer for watchdog
From: Kok, Auke @ 2007-12-20 17:05 UTC (permalink / raw)
To: parag.warudkar; +Cc: netdev, linux-kernel, akpm
In-Reply-To: <Pine.LNX.4.64.0712182046560.3616@mini.warudkars.net>
Parag Warudkar wrote:
>
> Reduce wakeups from idle per second.
>
> Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
>
> --- linux-2.6/drivers/net/e1000e/netdev.c 2007-12-07
> 10:04:39.000000000 -0500
> +++ linux-2.6-work/drivers/net/e1000e/netdev.c 2007-12-18
> 20:45:59.000000000 -0500
> @@ -3899,7 +3899,7 @@
> goto err_eeprom;
> }
>
> - init_timer(&adapter->watchdog_timer);
> + init_timer_deferrable(&adapter->watchdog_timer);
> adapter->watchdog_timer.function = &e1000_watchdog;
> adapter->watchdog_timer.data = (unsigned long) adapter;
I can't even apply this patch and the e1000 one... not only is it whitespace
damaged it is also not properly formatted as patch at all. If you want me to take
these patches seriously, then please fix the formatting issues.
Auke
^ permalink raw reply
* Re: [PATCH] sky2: Use deferrable timer for watchdog
From: Stephen Hemminger @ 2007-12-20 17:16 UTC (permalink / raw)
To: parag.warudkar; +Cc: netdev, akpm, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0712182008160.3616@mini.warudkars.net>
On Tue, 18 Dec 2007 20:13:28 -0500 (EST)
Parag Warudkar <parag.warudkar@gmail.com> wrote:
>
> sky2 can use deferrable timer for watchdog - reduces wakeups from idle per
> second.
>
> Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
>
> --- linux-2.6/drivers/net/sky2.c 2007-12-07 10:04:39.000000000 -0500
> +++ linux-2.6-work/drivers/net/sky2.c 2007-12-18 20:07:58.000000000 -0500
> @@ -4230,7 +4230,10 @@
> sky2_show_addr(dev1);
> }
>
> - setup_timer(&hw->watchdog_timer, sky2_watchdog, (unsigned long) hw);
> + hw->watchdog_timer.function = sky2_watchdog;
> + hw->watchdog_timer.data = (unsigned long) hw;
> + init_timer_deferrable(&hw->watchdog_timer);
> +
> INIT_WORK(&hw->restart_work, sky2_restart);
>
> pci_set_drvdata(pdev, hw);
Does it really reduce the wakeup's or only change who gets charged by powertop?
The system is going to wakeup once a second anyway. Looks to me that if the
timer is using round_jiffies(), that setting deferrable just changes the accounting.
My interpretation of the api is:
* round_jiffies() - timer wants to wakeup but isn't precise about when so schedule
on next second when system will wake up anyway;
e.g why meetings are usually scheduled on the hour
* deferrable - timer doesn't have to really wakeup but wants to happen near
a particular time. e.g. "I'll meet you at the pub around 8pm"
Therefore doing deferrable is unnecessary for timers using round_jiffies unless system
is so good at doing timers that it is going to skip doing timer once per second.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH 2/2] net: neighbor timer power saving
From: Stephen Hemminger @ 2007-12-20 17:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: parag.warudkar, David Miller, netdev, akpm
In-Reply-To: <4768C6FF.2090909@cosmosbay.com>
On Wed, 19 Dec 2007 08:23:43 +0100
Eric Dumazet <dada1@cosmosbay.com> wrote:
> Stephen Hemminger a écrit :
> > The neighbor GC timer runs once a second, but it doesn't need to wake
> > up the machine.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > --- a/net/core/neighbour.c 2007-12-18 07:46:07.000000000 -0800
> > +++ b/net/core/neighbour.c 2007-12-18 07:47:36.000000000 -0800
> > @@ -270,7 +270,7 @@ static struct neighbour *neigh_alloc(str
> > n->nud_state = NUD_NONE;
> > n->output = neigh_blackhole;
> > n->parms = neigh_parms_clone(&tbl->parms);
> > - init_timer(&n->timer);
> > + init_timer_deferrable(&n->timer);
> > n->timer.function = neigh_timer_handler;
> > n->timer.data = (unsigned long)n;
> >
> > @@ -740,7 +740,7 @@ static void neigh_timer_handler(unsigned
> >
> > state = neigh->nud_state;
> > now = jiffies;
> > - next = now + HZ;
> > + next = round_jiffies(now + HZ);
> >
> > if (!(state & NUD_IN_TIMER)) {
> > #ifndef CONFIG_SMP
> > @@ -1372,7 +1372,7 @@ void neigh_table_init_no_netlink(struct
> > get_random_bytes(&tbl->hash_rnd, sizeof(tbl->hash_rnd));
> >
> > rwlock_init(&tbl->lock);
> > - init_timer(&tbl->gc_timer);
> > + init_timer_deferrable(&tbl->gc_timer);
> > tbl->gc_timer.data = (unsigned long)tbl;
> > tbl->gc_timer.function = neigh_periodic_timer;
> > tbl->gc_timer.expires = now + 1;
>
> I wonder if this deferrable timer thing is the right way to go.
>
> (like read_mostly thing if you want :) )
>
> We are going to convert 99% timers to deferrable.
>
> Maybe the right move should be to have the reverse attribute, to mark a timer
> as non deferrable...
>
> Also, why use round_jiffies() on a deferrable timer ? That sounds unecessary ?
Thinking about it more, this looks like a case for just using round_jiffies().
The GC timer needs to run to clean up under DoS attack, and deferring it probably
isn't a good idea.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: James Nichols @ 2007-12-20 16:37 UTC (permalink / raw)
To: Glen Turner; +Cc: Jan Engelhardt, Eric Dumazet, linux-kernel, Linux Netdev List
In-Reply-To: <1198161695.6154.47.camel@andromache>
> But I'd be very surprised if the router is acting as anything more
> that a network-layer device. It might perhaps have some soft connection
> state being used for generating accounting records. Being Cisco
> it's probably a switch-router, so it might carry some per-port hard
> state for validating source IP addresses and ARPs on each port.
>
> The firewall is much more likely to be carrying per-flow Sack
> state. The Cisco PIX had a bug with SACK handling (CSCse14419,
> fixed in 7.0(7), 7.1(2.34), 7.2(2.2), 8.0(0.141) but perhaps it
> has regressed). A simple trace either side of the firewall will
> show the inconsistency between the TCP sequence number (which
> gets randomised) and the Sack sequence number (which didn't).
> You could disable the TCP Sequence Number Randomisation feature
> and see if the fault reoccurs.
I do have TCP Sequence # Randomization enabled on my router. However,
if this was causing an issue, wouldn't it always occur and cause
connection issues, not just after 38 hours of correct operation? I
can look into turning this off, but I'll likely have to jump through
several hoops which will be challenging if I don't have a very clear
definitive reason why this is causing this issue. Plus, I've had this
problem with at least 2 other sets of network switches over the past 4
years. I'm actually running 7.0(6), which doesn't have the fix you
mentioned. If it really is possible that this issue wouldn't always
cause problems, but only after hours of succesful operation, then I
could probably motivate the upgrade. I can try to setup a trace, but
this is a lot of work for other people in my organization, so it will
take quite some time.
> You'd probably should also investigate the Linux kernel,
> especially the size and locks of the components of the Sack data
> structures and what happens to those data structures after Sack is
> disabled (presumably the Sack data structure is in some unhappy
> circumstance, and disabling Sack allows the data to be discarded,
> magically unclaging the box).
>
> In the absence of the reporter wanting to dump the kernel's
> core, how about a patch to print the Sack datastructure when
> the command to disable Sack is received by the kernel?
> Maybe just print the last 16b of the IP address?
Given the fact that I've had this problem for so long, over a variety
of networking hardware vendors and colo-facilities, this really sounds
good to me. It will be challenging for me to justify a kernel core
dump, but a simple patch to dump the Sack data would be do-able.
^ permalink raw reply
* Please pull 'upstream-davem' branch of wireless-2.6
From: John W. Linville @ 2007-12-20 15:53 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 4313 bytes --]
Dave,
These are destined for 2.6.25. The patches fall mostly into two
categories: a new rate control algorithm for mac80211, and some
cfg80211 enhancements (including mac80211 patches to use them).
Also there are some small hits in the iwlwifi drivers related to
rate control. I'll CC Jeff since his tree has a lot of iwlwifi symbol
renames and those patches will conflict (or break the build, or both)
when your tree and his finally come together.
Let me know if there are any problems!
John
P.S. I have a few more related to the cfg80211 changes, but the
patches are cross-dependent on both your tree and Jeff's. I will
probably send those to akpm in the meantime, and push them after
Linus has pulled both your tree and Jeff's in the 2.6.25 merge window.
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem
---
The following changes since commit adc292d3280278282d7b0e0813ccda711e739b5f:
Herbert Xu (1):
[IPSEC]: Do xfrm_state_check_space before encapsulation
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-davem
Johannes Berg (13):
mac80211: clean up eapol frame handling/port control
mac80211: clean up eapol handling in TX path
mac80211: make ieee80211_rx_mgmt_action static
mac80211: allow easier multicast/broadcast buffering in hardware
cfg80211/nl80211: introduce key handling
mac80211: support adding/removing keys via cfg80211
mac80211: support getting key sequence counters via cfg80211
cfg80211/nl80211: add beacon settings
cfg80211/nl80211: station handling
cfg80211/nl80211: implement station attribute retrieval
mac80211: implement station stats retrieval
mac80211: move tx crypto decision
mac80211: don't read ERP information from (re)association response
Mattias Nissler (4):
mac80211: clean up rate selection
mac80211: add PID controller based rate control algorithm
rc80211-pid: add debugging
rc80211-pid: export tuning parameters through debugfs
Ron Rindjunsky (1):
mac80211: pass in PS_POLL frames
Stefano Brivio (4):
mac80211: make PID rate control algorithm the default
rc80211-pid: add rate behaviour learning algorithm
rc80211-pid: add sharpening factor
doc: fix typo in feature-removal-schedule
Documentation/feature-removal-schedule.txt | 10 +-
drivers/net/wireless/iwlwifi/iwl-3945-rs.c | 44 +--
drivers/net/wireless/iwlwifi/iwl-4965-rs.c | 46 +--
include/linux/nl80211.h | 154 ++++++
include/net/cfg80211.h | 167 +++++++
include/net/mac80211.h | 17 +-
net/mac80211/Kconfig | 63 +++-
net/mac80211/Makefile | 16 +-
net/mac80211/cfg.c | 202 ++++++++-
net/mac80211/debugfs_netdev.c | 27 +-
net/mac80211/ieee80211.c | 21 +-
net/mac80211/ieee80211_i.h | 24 +-
net/mac80211/ieee80211_iface.c | 1 -
net/mac80211/ieee80211_rate.c | 59 +++-
net/mac80211/ieee80211_rate.h | 76 ++--
net/mac80211/ieee80211_sta.c | 35 +-
net/mac80211/rc80211_pid.h | 261 ++++++++++
net/mac80211/rc80211_pid_algo.c | 510 +++++++++++++++++++
net/mac80211/rc80211_pid_debugfs.c | 223 +++++++++
net/mac80211/rc80211_simple.c | 64 +--
net/mac80211/rx.c | 144 +++---
net/mac80211/tx.c | 171 ++++---
net/mac80211/util.c | 24 +-
net/mac80211/wep.c | 10 -
net/mac80211/wpa.c | 14 -
net/wireless/core.c | 3 +
net/wireless/nl80211.c | 737 ++++++++++++++++++++++++++++
27 files changed, 2692 insertions(+), 431 deletions(-)
create mode 100644 net/mac80211/rc80211_pid.h
create mode 100644 net/mac80211/rc80211_pid_algo.c
create mode 100644 net/mac80211/rc80211_pid_debugfs.c
Omnibus patch attached as 'upstream-davem.patch.bz2' due to size concerns.
--
John W. Linville
linville@tuxdriver.com
[-- Attachment #2: upstream-davem.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 27020 bytes --]
^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-12-20 15:54 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel
Jeff,
Here are a few more for 2.6.24...please let me know if there are any
problems!
Thanks,
John
P.S. The rtl8187 USB ID is already in your upstream branch -- I'm sure
it would seem like a fix if it was the ID for your wireless stick. :-)
---
Individual patches are available here:
http://www.kernel.org//pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik
---
The following changes since commit 82d29bf6dc7317aeb0a3a13c2348ca8591965875:
Linus Torvalds (1):
Linux 2.6.24-rc5
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Matthias Mueller (1):
rtl8187: Add USB ID for Sitecom WL-168 v1 001
Michael Wu (1):
p54: add Kconfig description
Reinette Chatre (1):
ipw2200: prevent alloc of unspecified size on stack
Zhu Yi (1):
iwlwifi: fix possible priv->mutex deadlock during suspend
drivers/net/wireless/Kconfig | 51 +++++++++++++++++++++++++++
drivers/net/wireless/ipw2200.c | 13 ++++++-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 18 +++-------
drivers/net/wireless/iwlwifi/iwl4965-base.c | 18 +++-------
drivers/net/wireless/rtl8187_dev.c | 2 +
5 files changed, 75 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 2b733c5..7bdf9da 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -586,15 +586,66 @@ config ADM8211
config P54_COMMON
tristate "Softmac Prism54 support"
depends on MAC80211 && WLAN_80211 && FW_LOADER && EXPERIMENTAL
+ ---help---
+ This is common code for isl38xx based cards.
+ This module does nothing by itself - the USB/PCI frontends
+ also need to be enabled in order to support any devices.
+
+ These devices require softmac firmware which can be found at
+ http://prism54.org/
+
+ If you choose to build a module, it'll be called p54common.
config P54_USB
tristate "Prism54 USB support"
depends on P54_COMMON && USB
select CRC32
+ ---help---
+ This driver is for USB isl38xx based wireless cards.
+ These are USB based adapters found in devices such as:
+
+ 3COM 3CRWE254G72
+ SMC 2862W-G
+ Accton 802.11g WN4501 USB
+ Siemens Gigaset USB
+ Netgear WG121
+ Netgear WG111
+ Medion 40900, Roper Europe
+ Shuttle PN15, Airvast WM168g, IOGear GWU513
+ Linksys WUSB54G
+ Linksys WUSB54G Portable
+ DLink DWL-G120 Spinnaker
+ DLink DWL-G122
+ Belkin F5D7050 ver 1000
+ Cohiba Proto board
+ SMC 2862W-G version 2
+ U.S. Robotics U5 802.11g Adapter
+ FUJITSU E-5400 USB D1700
+ Sagem XG703A
+ DLink DWL-G120 Cohiba
+ Spinnaker Proto board
+ Linksys WUSB54AG
+ Inventel UR054G
+ Spinnaker DUT
+
+ These devices require softmac firmware which can be found at
+ http://prism54.org/
+
+ If you choose to build a module, it'll be called p54usb.
config P54_PCI
tristate "Prism54 PCI support"
depends on P54_COMMON && PCI
+ ---help---
+ This driver is for PCI isl38xx based wireless cards.
+ This driver supports most devices that are supported by the
+ fullmac prism54 driver plus many devices which are not
+ supported by the fullmac driver/firmware.
+
+ This driver requires softmac firmware which can be found at
+ http://prism54.org/
+
+ If you choose to build a module, it'll be called p54pci.
source "drivers/net/wireless/iwlwifi/Kconfig"
source "drivers/net/wireless/hostap/Kconfig"
diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index 54f44e5..38ce8ee 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -1233,9 +1233,19 @@ static ssize_t show_event_log(struct device *d,
{
struct ipw_priv *priv = dev_get_drvdata(d);
u32 log_len = ipw_get_event_log_len(priv);
- struct ipw_event log[log_len];
+ u32 log_size;
+ struct ipw_event *log;
u32 len = 0, i;
+ /* not using min() because of its strict type checking */
+ log_size = PAGE_SIZE / sizeof(*log) > log_len ?
+ sizeof(*log) * log_len : PAGE_SIZE;
+ log = kzalloc(log_size, GFP_KERNEL);
+ if (!log) {
+ IPW_ERROR("Unable to allocate memory for log\n");
+ return 0;
+ }
+ log_len = log_size / sizeof(*log);
ipw_capture_event_log(priv, log_len, log);
len += snprintf(buf + len, PAGE_SIZE - len, "%08X", log_len);
@@ -1244,6 +1254,7 @@ static ssize_t show_event_log(struct device *d,
"\n%08X%08X%08X",
log[i].time, log[i].event, log[i].data);
len += snprintf(buf + len, PAGE_SIZE - len, "\n");
+ kfree(log);
return len;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 4bdf237..5c67b5b 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -6243,8 +6243,6 @@ static void __iwl_down(struct iwl_priv *priv)
/* Unblock any waiting calls */
wake_up_interruptible_all(&priv->wait_command_queue);
- iwl_cancel_deferred_work(priv);
-
/* Wipe out the EXIT_PENDING status bit if we are not actually
* exiting the module */
if (!exit_pending)
@@ -6319,6 +6317,8 @@ static void iwl_down(struct iwl_priv *priv)
mutex_lock(&priv->mutex);
__iwl_down(priv);
mutex_unlock(&priv->mutex);
+
+ iwl_cancel_deferred_work(priv);
}
#define MAX_HW_RESTARTS 5
@@ -8577,10 +8577,9 @@ static void iwl_pci_remove(struct pci_dev *pdev)
IWL_DEBUG_INFO("*** UNLOAD DRIVER ***\n");
- mutex_lock(&priv->mutex);
set_bit(STATUS_EXIT_PENDING, &priv->status);
- __iwl_down(priv);
- mutex_unlock(&priv->mutex);
+
+ iwl_down(priv);
/* Free MAC hash list for ADHOC */
for (i = 0; i < IWL_IBSS_MAC_HASH_SIZE; i++) {
@@ -8639,12 +8638,10 @@ static int iwl_pci_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct iwl_priv *priv = pci_get_drvdata(pdev);
- mutex_lock(&priv->mutex);
-
set_bit(STATUS_IN_SUSPEND, &priv->status);
/* Take down the device; powers it off, etc. */
- __iwl_down(priv);
+ iwl_down(priv);
if (priv->mac80211_registered)
ieee80211_stop_queues(priv->hw);
@@ -8653,8 +8650,6 @@ static int iwl_pci_suspend(struct pci_dev *pdev, pm_message_t state)
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
- mutex_unlock(&priv->mutex);
-
return 0;
}
@@ -8712,8 +8707,6 @@ static int iwl_pci_resume(struct pci_dev *pdev)
printk(KERN_INFO "Coming out of suspend...\n");
- mutex_lock(&priv->mutex);
-
pci_set_power_state(pdev, PCI_D0);
err = pci_enable_device(pdev);
pci_restore_state(pdev);
@@ -8727,7 +8720,6 @@ static int iwl_pci_resume(struct pci_dev *pdev)
pci_write_config_byte(pdev, 0x41, 0x00);
iwl_resume(priv);
- mutex_unlock(&priv->mutex);
return 0;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index 8f85564..ed148ea 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -6598,8 +6598,6 @@ static void __iwl_down(struct iwl_priv *priv)
/* Unblock any waiting calls */
wake_up_interruptible_all(&priv->wait_command_queue);
- iwl_cancel_deferred_work(priv);
-
/* Wipe out the EXIT_PENDING status bit if we are not actually
* exiting the module */
if (!exit_pending)
@@ -6674,6 +6672,8 @@ static void iwl_down(struct iwl_priv *priv)
mutex_lock(&priv->mutex);
__iwl_down(priv);
mutex_unlock(&priv->mutex);
+
+ iwl_cancel_deferred_work(priv);
}
#define MAX_HW_RESTARTS 5
@@ -9171,10 +9171,9 @@ static void iwl_pci_remove(struct pci_dev *pdev)
IWL_DEBUG_INFO("*** UNLOAD DRIVER ***\n");
- mutex_lock(&priv->mutex);
set_bit(STATUS_EXIT_PENDING, &priv->status);
- __iwl_down(priv);
- mutex_unlock(&priv->mutex);
+
+ iwl_down(priv);
/* Free MAC hash list for ADHOC */
for (i = 0; i < IWL_IBSS_MAC_HASH_SIZE; i++) {
@@ -9233,12 +9232,10 @@ static int iwl_pci_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct iwl_priv *priv = pci_get_drvdata(pdev);
- mutex_lock(&priv->mutex);
-
set_bit(STATUS_IN_SUSPEND, &priv->status);
/* Take down the device; powers it off, etc. */
- __iwl_down(priv);
+ iwl_down(priv);
if (priv->mac80211_registered)
ieee80211_stop_queues(priv->hw);
@@ -9247,8 +9244,6 @@ static int iwl_pci_suspend(struct pci_dev *pdev, pm_message_t state)
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
- mutex_unlock(&priv->mutex);
-
return 0;
}
@@ -9306,8 +9301,6 @@ static int iwl_pci_resume(struct pci_dev *pdev)
printk(KERN_INFO "Coming out of suspend...\n");
- mutex_lock(&priv->mutex);
-
pci_set_power_state(pdev, PCI_D0);
err = pci_enable_device(pdev);
pci_restore_state(pdev);
@@ -9321,7 +9314,6 @@ static int iwl_pci_resume(struct pci_dev *pdev)
pci_write_config_byte(pdev, 0x41, 0x00);
iwl_resume(priv);
- mutex_unlock(&priv->mutex);
return 0;
}
diff --git a/drivers/net/wireless/rtl8187_dev.c b/drivers/net/wireless/rtl8187_dev.c
index e454ae8..bd1ab3b 100644
--- a/drivers/net/wireless/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl8187_dev.c
@@ -38,6 +38,8 @@ static struct usb_device_id rtl8187_table[] __devinitdata = {
{USB_DEVICE(0x0846, 0x6a00)},
/* HP */
{USB_DEVICE(0x03f0, 0xca02)},
+ /* Sitecom */
+ {USB_DEVICE(0x0df6, 0x000d)},
{}
};
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Re: [PATCH] [IPROUTE]: A workaround to make larger rto_min printed correctly
From: Satoru SATOH @ 2007-12-20 16:21 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20071220091230.GB1924@ff.dom.local>
i see. HZ can be < 1000.. i should be wrong.
however, i got the following,
[root iproute2.org]# ./ip/ip route change 192.168.140.0/24 dev eth1 rto_min 4s
[root iproute2.org]# gdb -q ./ip/ip
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) br iproute.c:512
Breakpoint 1 at 0x804fc8d: file iproute.c, line 512.
(gdb) r route show dev eth1
Starting program: /root/iproute2.org/ip/ip route show dev eth1
Breakpoint 1, print_route (who=0xbfb9854c, n=0xbfb94528, arg=0x6404c0)
at iproute.c:512
512 unsigned val =
*(unsigned*)RTA_DATA(mxrta[i]);
(gdb) l 512,522
512 unsigned val =
*(unsigned*)RTA_DATA(mxrta[i]);
513
514 val *= 1000;
515 if (i == RTAX_RTT)
516 val /= 8;
517 else if (i == RTAX_RTTVAR)
518 val /= 4;
519 if (val >= hz)
520 fprintf(fp, " %ums", val/hz);
521 else
522 fprintf(fp, " %.2fms",
(float)val/hz);
(gdb) p hz
$1 = 1000000000
(gdb) n
514 val *= 1000;
(gdb) p val
$2 = 4000000000
(gdb) p val/ (hz / 1000)
$3 = 4000
(gdb) n
515 if (i == RTAX_RTT)
(gdb) p val
$4 = 1385447424
(gdb) c
Continuing.
192.168.140.0/24 scope link rto_min lock 1ms
Program exited normally.
(gdb)
Thanks,
Satoru SATOH
2007/12/20, Jarek Poplawski <jarkao2@gmail.com>:
> On 20-12-2007 04:31, Satoru SATOH wrote:
> > "ip route show" does not print correct value when larger rto_min is
> > set (e.g. 3sec).
> >
> > This problem is because of overflow in print_route() and
> > the patch below is a workaround fix for that.
> >
> ...
> > --- a/ip/iproute.c
> > +++ b/ip/iproute.c
> > @@ -510,16 +510,16 @@ int print_route(const struct sockaddr_nl *who,
> > struct nlmsghdr *n, void *arg)
> > fprintf(fp, " %u",
> > *(unsigned*)RTA_DATA(mxrta[i]));
> > else {
> > unsigned val = *(unsigned*)RTA_DATA(mxrta[i]);
> > + unsigned hz1 = hz / 1000;
> ...
> > + if (val >= hz1)
> > + fprintf(fp, " %ums", val/hz1);
> ...
>
> Probably I miss something or my iproute sources are too old, but:
> does this work with hz < 1000?
>
> Regards,
> Jarek P.
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: James Nichols @ 2007-12-20 16:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jan Engelhardt, linux-kernel, Linux Netdev List
In-Reply-To: <47695CEF.4090908@cosmosbay.com>
> I still dont understand.
>
> "tcpdump -p -n -s 1600 -c 10000" doesnt reveal User data at all.
>
> Without any exact data from you, I am afraid nobody can help.
Oh, I didn't see that you specified specific options. I'll still have
to anonymize 2000+ IP addresses, but I think there is an open source
tool that will do this for you.
> >> 2) Are you sure you are not using connection tracking, and hit a limit on it ?
> >
> > I'm using ip_conntrack, but the limit I have for max entries is 65K.
> > The most I've seen in there are a couple thousand- that was one of the
> > first things I monitored very closely.
>
> Now please try without conn tracking module. I saw many failures in the past
> that were trigered by conntrack.
>
> Do you have some firewall rules, using some netfilter modules like hashlimit ?
I will have to look into this.
^ permalink raw reply
* Re: TSO trimming question
From: John Heffner @ 2007-12-20 16:02 UTC (permalink / raw)
To: David Miller; +Cc: ilpo.jarvinen, netdev, herbert
In-Reply-To: <20071220.035621.147230372.davem@davemloft.net>
David Miller wrote:
> From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Thu, 20 Dec 2007 13:40:51 +0200 (EET)
>
>> [PATCH] [TCP]: Fix TSO deferring
>>
>> I'd say that most of what tcp_tso_should_defer had in between
>> there was dead code because of this.
>>
>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>
> Yikes!!!!!
>
> John, we've been living a lie for more than a year. :-/
>
> On the bright side this explains a lot of small TSO frames I've been
> seeing in traces over the past year but never got a chance to
> investigate.
Ouch. This fix may improve some benchmarks.
Re-checking this function was on my list of things to do because I had
also noticed some TSO frames that seemed a bit small. This clearly
explains it.
-John
^ permalink raw reply
* Please pull 'upstream-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-12-20 15:54 UTC (permalink / raw)
To: jeff-o2qLIJkoznsdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 5125 bytes --]
Jeff,
More for 2.6.25...Mr. Woodhouse continues his savage assault on
libertas, the b43legacy version of the rfkill led patch is here
(b43legacy rfkill stuff is not in 2.6.24), and there are a couple of
iwlwifi patches as well.
Let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-jgarzik
---
The following changes since commit b503d38b01bf313e4f1250c4ded89fc10a1d3da0:
Ramkrishna Vepa (1):
S2io: Fixes to enable multiple transmit fifos
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-jgarzik
David Woodhouse (38):
libertas: don't exit worker thread until kthread_stop() is called
libertas: stop attempting to reset devices on unload
libertas: clean up if_usb driver
libertas: kill whitespace at end of lines
libertas: kill unused wait_option field in struct cmd_ctrl_node
libertas: rename and clean up DownloadcommandToStation
libertas: don't use __lbs_cmd() with empty callback in if_usb.c
libertas: remove some pointless checks for cmdnode buffer being present
libertas: introduce and use lbs_complete_command() for command completion
libertas: don't re-initialise cmdnode when taking it off the free queue
libertas: kill cleanup_cmdnode()
libertas: let __lbs_cmd() free its own cmdnode
libertas: kill pdata_buf member of struct cmd_ctrl_node
libertas: store command result in cmdnode instead of priv->cur_cmd_retcode
libertas: add __lbs_cmd_async() for asynchronous command submission
libertas: ensure response buffer size is always set for lbs_cmd_with_response
libertas: handle command timeout in main thread instead of directly in timer
libertas: kill 'addtail' argument to lbs_queue_cmd() and make it static
libertas: fix return from lbs_update_channel()
libertas: add SLEEP_PERIOD and FW_WAKE_METHOD command definitions
libertas: fix buffer handling of PS_MODE commands and responses
libertas: don't clear priv->dnld_sent after sending sleep confirm
libertas: handle HOST_AWAKE event by sending WAKEUP_CONFIRM command
libertas: allow for PS mode to be disabled when firmware doesn't support it
libertas: Check for PS mode support on USB devices
libertas: reduce explicit references to priv->cur_cmd->cmdbuf
libertas: use priv->upld_buf for command responses
libertas: discard DEFER responses to commands; let the timeout trigger
libertas: make lbs_submit_command always 'succeed' and set command timer
libertas: submit RSSI command on tx timeout, to check whether module is dead
libertas: convert RADIO_CONTROL to a direct command
libertas: convert INACTIVITY_TIMEOUT to a direct command
libertas: convert SLEEP_PARAMS to a direct command
libertas: convert SET_WEP to a direct command
libertas: convert ENABLE_RSN to a direct command
libertas: change inference about buffer size in lbs_cmd()
libertas: convert SUBSCRIBE_EVENT to a direct command
libertas: remove check for driver_lock in lbs_interrupt()
Larry Finger (1):
b43legacy: Fix rfkill radio LED
Zhu Yi (2):
iwlwifi: proper monitor support
iwlwifi: skip mac80211 conf during a hardware scan and replay it afterwards
drivers/net/wireless/b43legacy/leds.c | 4 +
drivers/net/wireless/b43legacy/main.c | 20 +-
drivers/net/wireless/b43legacy/rfkill.c | 133 ++++---
drivers/net/wireless/iwlwifi/iwl-3945.c | 120 +++++-
drivers/net/wireless/iwlwifi/iwl-3945.h | 38 +--
drivers/net/wireless/iwlwifi/iwl-4965.c | 120 ++++++-
drivers/net/wireless/iwlwifi/iwl-4965.h | 26 +--
drivers/net/wireless/iwlwifi/iwl3945-base.c | 139 +------
drivers/net/wireless/iwlwifi/iwl4965-base.c | 122 +------
drivers/net/wireless/libertas/assoc.c | 61 ++--
drivers/net/wireless/libertas/cmd.c | 565 +++++++++++----------------
drivers/net/wireless/libertas/cmd.h | 29 ++-
drivers/net/wireless/libertas/cmdresp.c | 162 +++-----
drivers/net/wireless/libertas/debugfs.c | 350 ++++++++---------
drivers/net/wireless/libertas/decl.h | 9 +-
drivers/net/wireless/libertas/dev.h | 19 +-
drivers/net/wireless/libertas/host.h | 8 +
drivers/net/wireless/libertas/hostcmd.h | 47 ++-
drivers/net/wireless/libertas/if_cs.c | 10 +-
drivers/net/wireless/libertas/if_sdio.c | 10 +-
drivers/net/wireless/libertas/if_usb.c | 470 ++++++++++-------------
drivers/net/wireless/libertas/if_usb.h | 95 ++---
drivers/net/wireless/libertas/main.c | 92 +++--
drivers/net/wireless/libertas/tx.c | 4 +-
drivers/net/wireless/libertas/wext.c | 7 +
25 files changed, 1200 insertions(+), 1460 deletions(-)
Omnibus patch attached is 'upstream-jgarzik.patch.bz2' due to size concerns.
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
[-- Attachment #2: upstream-jgarzik.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 30113 bytes --]
^ permalink raw reply
* Please pull 'fixes-davem' branch of wireless-2.6
From: John W. Linville @ 2007-12-20 15:52 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Dave,
A few more stragglers for 2.6.24...let me know if there are any
problems!
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-davem
---
The following changes since commit 82d29bf6dc7317aeb0a3a13c2348ca8591965875:
Linus Torvalds (1):
Linux 2.6.24-rc5
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-davem
Johannes Berg (2):
mac80211: round station cleanup timer
mac80211: warn when receiving frames with unaligned data
net/mac80211/rx.c | 13 +++++++++++++
net/mac80211/sta_info.c | 7 +++++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 00f908d..a7263fc 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1443,6 +1443,7 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb,
struct ieee80211_sub_if_data *prev = NULL;
struct sk_buff *skb_new;
u8 *bssid;
+ int hdrlen;
/*
* key references and virtual interfaces are protected using RCU
@@ -1472,6 +1473,18 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb,
rx.fc = le16_to_cpu(hdr->frame_control);
type = rx.fc & IEEE80211_FCTL_FTYPE;
+ /*
+ * Drivers are required to align the payload data to a four-byte
+ * boundary, so the last two bits of the address where it starts
+ * may not be set. The header is required to be directly before
+ * the payload data, padding like atheros hardware adds which is
+ * inbetween the 802.11 header and the payload is not supported,
+ * the driver is required to move the 802.11 header further back
+ * in that case.
+ */
+ hdrlen = ieee80211_get_hdrlen(rx.fc);
+ WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
+
if (type == IEEE80211_FTYPE_DATA || type == IEEE80211_FTYPE_MGMT)
local->dot11ReceivedFragmentCount++;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index e849155..cfd8ee9 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -14,6 +14,7 @@
#include <linux/slab.h>
#include <linux/skbuff.h>
#include <linux/if_arp.h>
+#include <linux/timer.h>
#include <net/mac80211.h>
#include "ieee80211_i.h"
@@ -306,7 +307,8 @@ static void sta_info_cleanup(unsigned long data)
}
read_unlock_bh(&local->sta_lock);
- local->sta_cleanup.expires = jiffies + STA_INFO_CLEANUP_INTERVAL;
+ local->sta_cleanup.expires =
+ round_jiffies(jiffies + STA_INFO_CLEANUP_INTERVAL);
add_timer(&local->sta_cleanup);
}
@@ -345,7 +347,8 @@ void sta_info_init(struct ieee80211_local *local)
INIT_LIST_HEAD(&local->sta_list);
init_timer(&local->sta_cleanup);
- local->sta_cleanup.expires = jiffies + STA_INFO_CLEANUP_INTERVAL;
+ local->sta_cleanup.expires =
+ round_jiffies(jiffies + STA_INFO_CLEANUP_INTERVAL);
local->sta_cleanup.data = (unsigned long) local;
local->sta_cleanup.function = sta_info_cleanup;
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply related
* Re: [PATCH/.24] [NET] fs_enet: check for phydev existence in the ethtool handlers
From: Vitaly Bordug @ 2007-12-20 14:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Anton Vorontsov, netdev, linuxppc-dev
In-Reply-To: <20071220135923.GA28772@localhost.localdomain>
On Thu, 20 Dec 2007 16:59:23 +0300
Anton Vorontsov wrote:
> Otherwise oops will happen if ethernet device has not been opened:
>
> Unable to handle kernel paging request for data at address 0x0000014c
> Faulting instruction address: 0xc016f7f0
> Oops: Kernel access of bad area, sig: 11 [#1]
> MPC85xx
> NIP: c016f7f0 LR: c01722a0 CTR: 00000000
> REGS: c79ddc70 TRAP: 0300 Not tainted (2.6.24-rc3-g820a386b)
> MSR: 00029000 <EE,ME> CR: 20004428 XER: 20000000
> DEAR: 0000014c, ESR: 00000000
> TASK = c789f5e0[999] 'snmpd' THREAD: c79dc000
> GPR00: c01aceb8 c79ddd20 c789f5e0 00000000 c79ddd3c 00000000 c79ddd64
> 00000000 GPR08: 00000000 c7845b60 c79dde3c c01ace80 20004422 200249fc
> 000002a0 100da728 GPR16: 100c0000 00000000 00000000 00000000 20022078
> 00000009 200220e0 bfc85558 GPR24: c79ddd3c 00000000 00000000 c02e0e70
> c022fc64 ffffffff c7845800 bfc85498 NIP [c016f7f0]
> phy_ethtool_gset+0x0/0x4c LR [c01722a0] fs_get_settings+0x18/0x28
> Call Trace:
> [c79ddd20] [c79dde38] 0xc79dde38 (unreliable)
> [c79ddd30] [c01aceb8] dev_ethtool+0x294/0x11ec
> [c79dde30] [c01aaa44] dev_ioctl+0x454/0x6a8
> [c79ddeb0] [c019b9d4] sock_ioctl+0x84/0x230
> [c79dded0] [c007ded8] do_ioctl+0x34/0x8c
> [c79ddee0] [c007dfbc] vfs_ioctl+0x8c/0x41c
> [c79ddf10] [c007e38c] sys_ioctl+0x40/0x74
> [c79ddf40] [c000d4c0] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 81630000 800b0030 2f800000 419e0010 7c0803a6 4e800021 7c691b78
> 80010014 7d234b78 38210010 7c0803a6 4e800020 <8003014c> 7c6b1b78
> 38600000 90040004
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
Jeff: this fix is important and should be merged if possible.
> ---
> drivers/net/fs_enet/fs_enet-main.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/fs_enet/fs_enet-main.c
> b/drivers/net/fs_enet/fs_enet-main.c index f2a4d39..23fddc3 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -897,14 +897,21 @@ static void fs_get_regs(struct net_device *dev,
> struct ethtool_regs *regs, static int fs_get_settings(struct
> net_device *dev, struct ethtool_cmd *cmd) {
> struct fs_enet_private *fep = netdev_priv(dev);
> +
> + if (!fep->phydev)
> + return -ENODEV;
> +
> return phy_ethtool_gset(fep->phydev, cmd);
> }
>
> static int fs_set_settings(struct net_device *dev, struct
> ethtool_cmd *cmd) {
> struct fs_enet_private *fep = netdev_priv(dev);
> - phy_ethtool_sset(fep->phydev, cmd);
> - return 0;
> +
> + if (!fep->phydev)
> + return -ENODEV;
> +
> + return phy_ethtool_sset(fep->phydev, cmd);
> }
>
> static int fs_nway_reset(struct net_device *dev)
--
Sincerely, Vitaly
^ permalink raw reply
* Re: After many hours all outbound connections get stuck in SYN_SENT
From: Glen Turner @ 2007-12-20 14:41 UTC (permalink / raw)
To: Jan Engelhardt
Cc: James Nichols, Eric Dumazet, linux-kernel, Linux Netdev List
In-Reply-To: <Pine.LNX.4.64.0712191857270.12329@fbirervta.pbzchgretzou.qr>
[speculation by network engineer -- not kernel hacker -- follows]
> The router could be sooo crappy that it drops all packets from
> TCP streams that have SACK enabled and the client has opened
> 200+ SACK connections previously... something like that?
As far as any third party is concerned the existing TCP connections
continue to have negotiated "SACK Permitted". Only new connections
will not negotiate this. So "router crappiness" promptly disappearing
doesn't seem too likely (a way I could see this happening is if the
Linux box sends a Ack for each connection and this clears out Sack
datastructures on the third party).
But I'd be very surprised if the router is acting as anything more
that a network-layer device. It might perhaps have some soft connection
state being used for generating accounting records. Being Cisco
it's probably a switch-router, so it might carry some per-port hard
state for validating source IP addresses and ARPs on each port.
The firewall is much more likely to be carrying per-flow Sack
state. The Cisco PIX had a bug with SACK handling (CSCse14419,
fixed in 7.0(7), 7.1(2.34), 7.2(2.2), 8.0(0.141) but perhaps it
has regressed). A simple trace either side of the firewall will
show the inconsistency between the TCP sequence number (which
gets randomised) and the Sack sequence number (which didn't).
You could disable the TCP Sequence Number Randomisation feature
and see if the fault reoccurs.
You'd probably should also investigate the Linux kernel,
especially the size and locks of the components of the Sack data
structures and what happens to those data structures after Sack is
disabled (presumably the Sack data structure is in some unhappy
circumstance, and disabling Sack allows the data to be discarded,
magically unclaging the box).
In the absence of the reporter wanting to dump the kernel's
core, how about a patch to print the Sack datastructure when
the command to disable Sack is received by the kernel?
Maybe just print the last 16b of the IP address?
Best wishes, Glen
^ permalink raw reply
* Re: TSO trimming question
From: Herbert Xu @ 2007-12-20 14:00 UTC (permalink / raw)
To: David Miller; +Cc: ilpo.jarvinen, netdev
In-Reply-To: <20071220.040037.48002365.davem@davemloft.net>
On Thu, Dec 20, 2007 at 04:00:37AM -0800, David Miller wrote:
>
> In the most ideal sense, tcp_window_allows() should probably
> be changed to only return MSS multiples.
>
> Unfortunately this would add an expensive modulo operation,
> however I think it would elimiate this problem case.
Well you only have to divide in the unlikely case of us being
limited by the receiver window. In that case speed is probably
not of the essence anyway.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH/.24] [NET] fs_enet: check for phydev existence in the ethtool handlers
From: Anton Vorontsov @ 2007-12-20 13:59 UTC (permalink / raw)
To: Jeff Garzik, Vitaly Bordug; +Cc: netdev, linuxppc-dev
Otherwise oops will happen if ethernet device has not been opened:
Unable to handle kernel paging request for data at address 0x0000014c
Faulting instruction address: 0xc016f7f0
Oops: Kernel access of bad area, sig: 11 [#1]
MPC85xx
NIP: c016f7f0 LR: c01722a0 CTR: 00000000
REGS: c79ddc70 TRAP: 0300 Not tainted (2.6.24-rc3-g820a386b)
MSR: 00029000 <EE,ME> CR: 20004428 XER: 20000000
DEAR: 0000014c, ESR: 00000000
TASK = c789f5e0[999] 'snmpd' THREAD: c79dc000
GPR00: c01aceb8 c79ddd20 c789f5e0 00000000 c79ddd3c 00000000 c79ddd64 00000000
GPR08: 00000000 c7845b60 c79dde3c c01ace80 20004422 200249fc 000002a0 100da728
GPR16: 100c0000 00000000 00000000 00000000 20022078 00000009 200220e0 bfc85558
GPR24: c79ddd3c 00000000 00000000 c02e0e70 c022fc64 ffffffff c7845800 bfc85498
NIP [c016f7f0] phy_ethtool_gset+0x0/0x4c
LR [c01722a0] fs_get_settings+0x18/0x28
Call Trace:
[c79ddd20] [c79dde38] 0xc79dde38 (unreliable)
[c79ddd30] [c01aceb8] dev_ethtool+0x294/0x11ec
[c79dde30] [c01aaa44] dev_ioctl+0x454/0x6a8
[c79ddeb0] [c019b9d4] sock_ioctl+0x84/0x230
[c79dded0] [c007ded8] do_ioctl+0x34/0x8c
[c79ddee0] [c007dfbc] vfs_ioctl+0x8c/0x41c
[c79ddf10] [c007e38c] sys_ioctl+0x40/0x74
[c79ddf40] [c000d4c0] ret_from_syscall+0x0/0x3c
Instruction dump:
81630000 800b0030 2f800000 419e0010 7c0803a6 4e800021 7c691b78 80010014
7d234b78 38210010 7c0803a6 4e800020 <8003014c> 7c6b1b78 38600000 90040004
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/fs_enet/fs_enet-main.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..23fddc3 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -897,14 +897,21 @@ static void fs_get_regs(struct net_device *dev, struct ethtool_regs *regs,
static int fs_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
+
+ if (!fep->phydev)
+ return -ENODEV;
+
return phy_ethtool_gset(fep->phydev, cmd);
}
static int fs_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
- phy_ethtool_sset(fep->phydev, cmd);
- return 0;
+
+ if (!fep->phydev)
+ return -ENODEV;
+
+ return phy_ethtool_sset(fep->phydev, cmd);
}
static int fs_nway_reset(struct net_device *dev)
--
1.5.2.2
^ permalink raw reply related
* [PATCH] Re: Nested VLAN causes recursive locking error
From: Jarek Poplawski @ 2007-12-20 13:52 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Patrick McHardy, Netdev
In-Reply-To: <476851DB.5080107@redhat.com>
On 19-12-2007 00:03, Chuck Ebbert wrote:
> From:
> https://bugzilla.redhat.com/show_bug.cgi?id=426164
>
>
> kernel version is 2.6.24-0.107.rc5.git3.fc9
>
> From boot log on serial console:
> (full log attached)
>
> Added VLAN with VID == 2 to IF -:eth0.1568:-
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.24-0.107.rc5.git3.fc9 #1
> ---------------------------------------------
> ifconfig/15011 is trying to acquire lock:
> (&vlan_netdev_xmit_lock_key){-+..}, at: [<c05d9450>] dev_mc_sync+0x1c/0x102
>
> but task is already holding lock:
> (&vlan_netdev_xmit_lock_key){-+..}, at: [<c05d51bd>] dev_set_rx_mode+0x14/0x3c
>
> other info that might help us debug this:
> 2 locks held by ifconfig/15011:
> #0: (rtnl_mutex){--..}, at: [<c05de4f7>] rtnl_lock+0xf/0x11
> #1: (&vlan_netdev_xmit_lock_key){-+..}, at: [<c05d51bd>] dev_set_rx_mode+0x14/0x3c
...
Subject: [PATCH] nested VLAN: fix lockdep's recursive locking warning
Allow vlans nesting other vlans without lockdep's warnings (max. 8 levels).
Reported-by: Benny Amorsen
Tested-by: Benny Amorsen (?) NEEDS TESTING!
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
diff -Nurp linux-2.6.24-rc5-/net/8021q/vlan.c linux-2.6.24-rc5+/net/8021q/vlan.c
--- linux-2.6.24-rc5-/net/8021q/vlan.c 2007-12-17 13:29:19.000000000 +0100
+++ linux-2.6.24-rc5+/net/8021q/vlan.c 2007-12-20 14:21:02.000000000 +0100
@@ -307,12 +307,15 @@ int unregister_vlan_device(struct net_de
return ret;
}
+#ifdef CONFIG_LOCKDEP
/*
* vlan network devices have devices nesting below it, and are a special
* "super class" of normal network devices; split their locks off into a
* separate class since they always nest.
*/
static struct lock_class_key vlan_netdev_xmit_lock_key;
+static int subclass; /* vlan nesting vlan */
+#endif
static const struct header_ops vlan_header_ops = {
.create = vlan_dev_hard_header,
@@ -349,7 +352,14 @@ static int vlan_dev_init(struct net_devi
dev->hard_start_xmit = vlan_dev_hard_start_xmit;
}
- lockdep_set_class(&dev->_xmit_lock, &vlan_netdev_xmit_lock_key);
+#ifdef CONFIG_LOCKDEP
+ if ((real_dev->priv_flags & IFF_802_1Q_VLAN) &&
+ subclass < MAX_LOCKDEP_SUBCLASSES - 1)
+ subclass++;
+
+ lockdep_set_class_and_subclass(&dev->_xmit_lock,
+ &vlan_netdev_xmit_lock_key, subclass);
+#endif
return 0;
}
^ permalink raw reply
* Re: A short question about net git tree and patches
From: Sam Ravnborg @ 2007-12-20 13:39 UTC (permalink / raw)
To: David Miller; +Cc: dshwatrz, netdev
In-Reply-To: <20071220.032258.265124532.davem@davemloft.net>
On Thu, Dec 20, 2007 at 03:22:58AM -0800, David Miller wrote:
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Thu, 20 Dec 2007 10:55:10 +0100
>
> > net-2.6.25.git <= patches for current kernel release (only fixes)
> > net-2.6.git <= patches for next kernel relase and planned to be
> > applied in next merge window
> >
> > So net-2.6.git is the correct choice for bleeding edge.
>
> You reversed them, net-2.6.25.git is for bleeding edge
> stuff, net-2.6.git is for bug fixes only.
Sorry - thanks for clarifying it.
Sam - who should refrain from thinking too much in current crappy condition
^ permalink raw reply
* neigh: timer & !nud_in_timer
From: John Sigler @ 2007-12-20 13:35 UTC (permalink / raw)
To: netdev, linux-kernel, linux-rt-users
Hello,
I noticed the following message in my kernel log.
kernel: neigh: timer & !nud_in_timer
(Might be due to a race condition.)
I'm running a UP Linux version 2.6.22.1-rt9
( http://rt.wiki.kernel.org/index.php )
The following /proc entries might be relevant.
/proc/sys/net/ipv4/conf/all/arp_accept
0
/proc/sys/net/ipv4/conf/all/arp_announce
2
/proc/sys/net/ipv4/conf/all/arp_filter
0
/proc/sys/net/ipv4/conf/all/arp_ignore
1
I also lowered the priority of softirq-timer/0 to 10 which means
it can be interrupted by other IRQ handlers.
Regards.
^ permalink raw reply
* Re: TSO trimming question
From: Ilpo Järvinen @ 2007-12-20 12:35 UTC (permalink / raw)
To: David Miller; +Cc: Netdev, Herbert Xu
In-Reply-To: <20071220.040037.48002365.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1190 bytes --]
On Thu, 20 Dec 2007, David Miller wrote:
> From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Thu, 20 Dec 2007 13:40:51 +0200 (EET)
>
> > That's not the only case, IMHO if there's odd boundary due to
> > snd_una+snd_wnd - skb->seq limit (done in tcp_window_allows()), we don't
> > consider it as odd but break the skb at arbitary point resulting
> > two small segments to the network, and what's worse, when the later skb
> > resulting from the first split is matching skb->len < limit check as well
> > causing an unnecessary small skb to be created for nagle purpose too,
> > solving it fully requires some thought in case the mss_now != mss_cache
> > even if non-odd boundaries are honored in the middle of skb.
>
> In the most ideal sense, tcp_window_allows() should probably
> be changed to only return MSS multiples.
That's what Herbert suggested already, I'll send a patch later
on... :-)
> Unfortunately this would add an expensive modulo operation,
> however I think it would elimiate this problem case.
Yes. Should we still call tcp_minshall_update() if split in the middle of
wq results in smaller than MSS tail (occurs only if mss_now != mss_cache)?
--
i.
^ permalink raw reply
* Re: [PATCH] One more XFRM audit fix
From: Paul Moore @ 2007-12-20 12:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-audit
In-Reply-To: <20071220.000009.173158004.davem@davemloft.net>
On Thursday 20 December 2007 3:00:09 am David Miller wrote:
> From: Paul Moore <paul.moore@hp.com>
> Date: Wed, 19 Dec 2007 14:29:31 -0500
>
> > The following patch is backed against David's net-2.6 tree and is pretty
> > trivial. I know we're late in the 2.6.24 cycle but I think this is worth
> > merging, if you guys don't feel that way let me know and I'll resubmit it
> > for 2.6.25.
>
> Where is that patch? Or do you mean the fix you emailed
> seperately today (which I will apply, thanks)?
Yes, it was the patch you applied, "XFRM: Audit function arguments
misordered". I was using stacked-git to post the patch and it apparently
doesn't annotate the cover email's subject line with "0/1" when you only send
one patch.
Sorry about that.
> > As a side note, I'm unable to actually test the patch because I can't get
> > the kernel to compile (M=net/xfrm works just fine). The problem I keep
> > seeing is below:
> >
> > make[3]: *** No rule to make target \
> > `/blah/kernels/net-2.6_xfrm-auid-secid-fix/include/linux/ticable.h', \
> > needed by \
> > `/blah/kernels/net-2.6_xfrm-auid-secid-fix/usr/include/linux/ticable.h'.
> > \ Stop.
>
> Remove ticable.h from include/linux/Kbuild
>
> This is already cured in Linus's tree.
Noted, thanks.
--
paul moore
linux security @ hp
^ 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